Hello Curious Coders,

Before we talk about how to plan with AI, it helps to step back and watch how the trap works.

You open Claude. You describe a Phoenix project. You ask for research first, then a plan. The model interviews you, asks reasonable questions, produces a clean architecture document. The functional core is laid out. The contexts have boundaries. There is even a registry for pluggable games. You scroll through it and it looks right.

If you stop reading there and tell Claude to start implementing, you have vibed. The output looked correct, the conversation felt productive, and the work moved forward. That is the trap. The plan was generated, but it was never reviewed. Until someone reads it with the eye of an Elixir architect, the plan is just text that sounds reasonable.

Research Is an Interview, Not a Prompt

The research stage starts the way it should, as a conversation. When Bruce kicks off /research for the word games project, he describes the system in pieces: pluggable games, an authentication progression from unauthenticated to subscribed, a functional core that follows the CRC pattern. Then he asks Claude to interview him.

Claude responds with clarifying questions about validation behavior, game tiers, test scope, and Phoenix features. Bruce answers each one, and along the way he pushes back. When Claude offers to add validation inside the functional core, Bruce shuts it down. Validation belongs at a different tier. The functional core stays pure.

He keeps shaping. Pluggable games become a behavior, not a protocol. State lives in LiveView assigns, not in a separate GenServer that would duplicate what LiveView already does. The Phoenix context becomes the API boundary, with no logic embedded in LiveView callbacks. By the time the architecture document is generated, Bruce has already made every important decision out loud. The document is just a record of those decisions.

“The further you and Claude are able to break things down, the better you’re going to understand and the better Claude’s going to understand what it is that you’re building.”

– Bruce Tate

A prompt asks the model to produce. An interview asks the model to question, so that you produce.

The Catch That Changes Everything

After the research document is written, Bruce reads it carefully. Most of it is good. Then he hits the authentication section.

Claude designed the system around a user. The user gets loaded from the session and passed into the context, where routing and access decisions happen. That sounds correct. It is wrong.

In Phoenix 1.8, mix phoenix.gen.auth produces an authentication system built around a scope, not a user. The scope represents the capabilities of a user, including subscription state and access tiers. The Phoenix team chose this pattern because broken access control is an OWASP top-ten issue, and routing decisions through a scope make the boundary explicit. A system built around user looks fine until someone with a free-tier scope reaches an endpoint that should require a paid one.

Bruce caught this not because the model failed, but because he knew what to look for. The architecture would have compiled, passed its tests, and shipped.

“This is the first time that we’ve gone beyond vibing. We’ve caught Claude in a pretty serious mistake that would have security implications.”

– Bruce Tate

A vibing developer would not have caught it. An Elixir architect did.

The Checklist as a Checkpoint System

Once a flaw is caught, the wrong response is to fix it conversationally and keep going. That correction would dissolve the moment the chat ran long enough.

The right response is what Bruce does next. He opens a plans/to-do.md file and writes a checklist. The first item updates the research document to use authentication scopes. The second confirms that LiveViews, contexts, and subscriptions all take scopes into account. Other items group the wordle variants together, define dictionary strategies, and mark which planning tasks must be completed before any implementation begins.

The checklist is not a feature list. It is a checkpoint system, and it does three things at once. It primes any future Claude session by pointing at the architecture document and the to-do list. It lets Bruce ask Claude to pause for acceptance after each item, instead of charging through fixes blindly. When the conversation grows long, /context can clear the working memory so the next session resumes from the files, not from a fading chat.

The architecture document and the to-do list become the project’s shared brain. They survive the conversation. The Elixir developer’s judgment lives in those files, not in chat history that will be summarized away.

Where the Developer Adds the Most Value

There is a tempting story where Claude does the architecture and the developer cleans up syntax. The story is wrong. Claude can produce a credible architecture document in minutes, but it cannot tell you that Phoenix 1.8 introduced scopes, decide that pluggable games warrant a behavior over a protocol, or insist that validation belongs outside the functional core. Those are judgment calls, and they are exactly where you, the Elixir developer, justify your seat.

“This point right here is what makes the difference between an AI Viber and the full Elixir developer that uses AI.”

– Bruce Tate

Vibing produces code. Disciplined planning produces architecture. The place you add the most value is not at the keyboard. It is in the review, in the decomposition, and in the architectural calls that an interview will surface only if you push back hard enough.

Now that we have an architecture we trust, we can give Claude the tools to build it well. In the next post, we start where every good Elixir application starts: the functional core, and why pure functions make Claude a cheaper and more reliable partner.

See you in the next chapter.

— Paulo & Bruce