Hello Curious Coders,

Before talking about how to work with AI in a structured way, let me show you why so many people fall in love with vibe coding.

Bruce asked Claude to build a complete application using Phoenix LiveView: Conway’s Game of Life, with controls, pattern library, and interface. It took 30 minutes from idea to working code.

Gliders moving across the screen, speed controls, randomization, ready-made pattern library, clean interface. Worked on the first try.

The Process Looks Like Magic

Claude started by asking questions. Which version of Phoenix? Going to use a database? What kind of controls do you want? Then it entered planning mode and created a complete task list. It wasn’t improvising – it was structuring the work before starting.

Then came the implementation: files, functions, tests. Ten minutes later, a working application.

Fifteen more minutes passed and features I hadn’t even asked for started appearing. A canvas editor for drawing custom patterns. Auto-configuration of grid size based on screen. Smooth animations.

And here’s the problem: it worked too well.

The Pressure of “Yes”

During the process, Claude kept asking:

“Want me to add speed controls?” “Can I create a ready-made pattern library?” “Should I implement a visual editor?”

Each question seems reasonable. Each feature makes sense. And when you’re watching code appear on the screen in real-time, it’s very easy to say yes.

Bruce calls this the “yes loop”. You enter a cycle where each addition seems small, each suggestion sounds useful, and you keep accepting because the momentum is seductive. When you let AI make scope decisions, it will always tend to add – not out of malice, but because language models are trained to be helpful, complete, impressive.

The canvas editor? Wasn’t in the initial brief, but… Claude thought it would be useful and implemented it. Turned out good, works perfectly. The grid auto-configuration? Didn’t ask for that either.

In another context, we’d say: “At least it shows initiative!” But when you’re building a system that’s going to grow, unsolicited features are technical debt disguised as kindness – not because they’re bad, but because you didn’t plan how they fit in. You only said yes because it was fast and seemed reasonable.

Why It Works So Well (and Why That’s a Problem)

This approach works because Phoenix has clear conventions. LiveView has defined structure. Elixir has strong principles and a well-documented public codebase.

When you ask Claude to build a Phoenix application, it’s not improvising from scratch. It’s using patterns it’s seen thousands of times. It knows where to put files, how to structure a LiveView, which libraries to use.

For a simple application like this? It works very well.

What you don’t see in the first thirty minutes is what happens when the application stops being simple. When you need to add authentication, optimize performance, refactor because the business changed. That’s when the bill comes due.

“Vibing is fantastic for prototypes. It’s poison for systems you intend to maintain.” — Bruce Tate

In that thirty-minute moment, you’re not thinking about six months in the future. You’re not thinking about the next developer who’s going to read this code or how to debug it when something breaks. You’re thinking: “This works. This is amazing. Why would I stop now?”

The trap isn’t using vibe coding. Bruce uses vibe coding too – for prototypes, experiments, testing ideas quickly. The trap is not realizing when you’ve left prototype territory and entered system territory. Because a prototype is disposable by design. A system needs architecture.

And when you’re vibing, you don’t notice when you’ve crossed that line.

What Now?

Claude can build a complete Phoenix LiveView application in thirty minutes. The question isn’t whether it works. It’s whether you’ll be able to maintain it six months from now.

In the next post, I’ll open up the code and show what really came out of those thirty minutes. Not as criticism, but as analysis. Because if you’re going to work with AI in Elixir, you need to know how to distinguish “works now” from “works in six months”.

And that distinction doesn’t appear at the moment of creation. It only becomes clear when you find the first feature that nobody remembers why it exists.

See you in the next chapter.

– Paulo & Bruce