Hello Curious Coders,

Before we talk about building features, it helps to step back and name a problem most people run into when they start using AI for coding.

You start a new feature in a Phoenix app. You open a chat and explain what you want. The model gives you some code, you copy it in, and it mostly works. But then you need to add a test. You have to explain the setup again. Then you need to check for linting errors. You explain the project structure again. By the third or fourth turn, the conversation feels heavy. You’re repeating yourself, and if you start a new chat, you do it all over again.

Your development process lives only in the current conversation. It isn’t durable, it isn’t repeatable, and it definitely isn’t versioned. But what if it could be treated like code?

The Elixir Macro Analogy

If you’ve been writing Elixir long enough, you know what José’s decision to write Elixir in Elixir felt like. Macros were code that wrote code, and that doubling of expressive power is part of what let the language grow as fast as it did.

Bruce had a similar recognition while building the Groxio AI course. “One of the things that accelerated the development of Elixir,” he said in class, “was the idea that you could use Elixir to write macros and the language could be written in the language itself. The same thing is happening today.”

What he was pointing at is the meta workflow generator: a prompt that, when you run it against your project, produces the prompts that will manage your development process.

Structure That Builds Structure

The meta workflow generator is a slash command that interviews Claude about your project and then creates a set of customized workflow commands stored in .claude/commands/. The commands it produces are /research, /plan, /implement, /qa, and /one-shot.

Each command encodes one stage of development. Research explores the codebase and answers questions before any code is written. Plan works through design decisions with you and produces a document. Implement builds what was planned. QA runs Credo, format checks, dialyzer, and tests, customized to the checks that actually matter for your project.

These are not generic templates. They are generated by examining your project, asking what matters to you, and producing commands that reflect your actual workflow. Because they live as plain files in your project directory, you can open them in an editor and change anything that doesn’t fit. The generator does not impose a workflow. It makes your workflow visible.

“We are using prompts that write prompts. In this kind of acceleration, when you’re building building blocks in the language that you’re working with itself, in this case, pure English, you can start to build the structure that builds the structure.”

— Bruce Tate

When One-Shot Is and Isn’t the Answer

The fifth generated command is /one-shot, and understanding when to reach for it matters more than the command itself.

One-shot runs everything in sequence: research, plan, implement, and QA with minimal interruption. For a simple, well-understood task, that can be exactly right. If you need a straightforward endpoint or a small validation rule where you already know what the model will produce, one-shot saves time.

Here is a simple rule you can try today: if a task has more than one unknown, don’t use /one-shot. If you’re adding a user stats endpoint and already know the schema and response shape, /one-shot is fine. If you’re changing a billing flow and still need to confirm edge cases or data ownership, run /research, review the plan, and only then move to /implement.

Bruce warns that pushing one-shot too far gets dangerously close to vibing. Not because the command is broken, but because reaching for it on complex or uncertain work is how you stop thinking. The workflow is not a substitute for judgment. It’s a structure inside which judgment operates.

Your Process Is Infrastructure

Here is what the meta workflow generator proves: your development process is not a series of impulses. It’s structure. Structure can be written down, stored in version control, and refined the same way code can.

When you move decisions out of chat and into artifacts that live beside the codebase, you stop babysitting the model and start collaborating with it. The shift from “how do I prompt this?” to “how do I structure my process?” is where AI stops feeling like a fight and starts feeling like a tool.

Having the workflow is the setup. The real value comes from what happens inside the stages, especially planning. A bad plan only automates mistakes more efficiently. A good plan gives the rest of the workflow something solid to follow.

In the next post, we’ll look at the most critical stage of this new workflow: the planning phase. We’ll show a real example of catching a security mistake during a plan review that would have been a disaster if we had just let the AI “one-shot” the implementation.

See you in the next chapter.

— Paulo & Bruce