So, what now?

Not to be dramatic, but it may be over.

In my lifetime, there has only been one other phenomenon that has changed how we live and work so drastically: widespread availability of the internet.

If you love writing code, whether you consider yourself a programmer, an engineer, a developer, or a bit of a hack who really enjoys getting your hands dirty and making things work (no judgement here—I've been called worse), you might start considering it more of a passion than an occupation.

We all know the tweet. The tweet that gave a viral term to the changes that are happening:

There's more to this tweet than the preview may show. Click through to read the whole thing.

I'm not an expert on the matter, but from what I understand, the main precepts of the movement are as follows:

• Develop by explaining.
• Interact as little as possible with the code.
• Don't be sentimental about the current state of your code.
• Iterate without restraint as you work with the agent to approach your final product.

And this concept of vibe coding embodies the divisive nature of everything that's been happening regarding machine learning. There are a lot of valid reasons to be resistant to the art, music, articles, and other content that is being generated by AI now. I strongly believe that when you remove the human element from the arts, you lose the art. When you remove the person from the expression, you lose the soul that is inherent in the small or large imperfections of our communication with each other.

I don't use AI as a therapist. I don't use it to refine conversations with my friends and loved ones. I don't fully trust it to gave me a definitive answer to something I google. And I don't use AI to write this blog. That's just my personal opinion—some spaces in my life are sacred, because we have a human need to be authentic. Or at least to feel authentic.

In the months that I've been hearing people talk about vibe coding, I grew increasingly skeptical. There is an implication that anyone can create software this way, and that is cemented by the idea that soon, if not right now, it may be possible to create and deploy a complete product without ever writing code. Another implication piggybacks on that: why would you even need to understand the code?

How could this be manageable? As the complexity of your project grows, you would have to write increasingly complex prompts for your agent. Your agent would 'hallucinate' (read: screw up) more and more, and the conflict between your intent and your product would become extremely aggravating. How can an LLM manage this complexity in a way that allows you to work?

This was partially confirmed by some initial attempts I made to build simple web applications in the web demos for Replit and Claude. Shortly into each attempt, I would encounter a fatal error that the agent seemed unable to correct. I would make suggestions for small changes that the agent performed inaccurately. It would make my changes and add some bonus changes of its own. Thanks for the help, but stop helping!

But my frustrations weren't enough to convince me I was right. I'm not a luddite. I'm hardly a traditionalist (I have spent most of my developing experience using TypeScript and React).

And the only way for me to be sure was to really commit. There are many tools fighting to be ahead right now, and this ecosystem will be changing weekly, but I kept hearing about Claude Code, and I wanted to confirm whether this tool was ready to do what's on the label.

Vibe vs Agentic

Say what you want about vibe coding. I'll probably agree with your criticism. I'll probably accept your hype. Blindly creating software with no fundamental understanding is probably never going to be the best idea, but I support tools that enable people to put their ideas into action. You could argue that software is art, but to me that's a stretch. The idea is art. The presentation is art. The user interface? I'd concede that it could be art. The code is code.

None of this is black and white. That's kind of the whole idea. We're discarding the idea of syntactic code and just talking to our agent. But there are deeper layers. When you use the tools properly, you have the opportunity to stop shouting at your laptop and start dispatching team members and delegating tasks. We'll explore things like subagents and MCP as we progress through our project. How do we go from vibe coder to agentic developer? How do we get good at this?

A plan without a plan

I've had an idea for an app on the back burner for a while now. Between work and family, I just haven't had time to seriously tackle it. What better candidate for an agentic approach? Maybe Claude can help us develop something that would just take too long otherwise.

As I considered my approach to this exploration, I formulated some guidelines based on the vibe coding mindset I listed earlier:

1. Start from a naive understanding. Begin by asking questions. Build on our strategy as we go.
2. Let the agent help us plan.
3. Use the agent for every task it is capable of.
4. Only edit the code with intent—either to test the agent's ability to collaborate or to correct an issue the agent seems stuck on.
5. Follow the steps we reasonably would in a single-author software project: utilize a Gitflow branching strategy, make regular commits, ensure the code remains readable, linted, tested, and documented.
6. Document as much of the process as possible.

Once I had these notes, I followed the thread...