The Discipline Behind Building with Agents
Faster code, harder thinking.
In the first part, I argued that the specification is starting to look more like the programming language than the code itself.
If that’s true, then a lot of familiar instincts stop working.
This was the part that surprised me most.
Once you get past the initial thrill of watching an agent work, you run into a harder truth: speed doesn’t remove responsibility, it concentrates it. Working with agents is not easier. It’s different.
Explicitness is no longer optional
The single most important thing I’ve learned is this: you have to be painfully explicit.
Working with an agent is like working with a super-compliant, high-initiative person. They will run with whatever direction you give them - confidently, quickly, and at scale. That means you don’t just need to say what you want - you need to define the constraints around it.
If you want checkpoints or reviews, you have to say so. If you want clarifying questions, you have to explicitly request them.
One example that kept coming up for me was type handling. The architecture required dates to exist in two specific primitives, but the agent would occasionally convert them to strings for convenience. Each change looked harmless, but over time the system drifted away from the constraints the product depended on. Until I wrote the rule down explicitly, the problem kept coming back.
When things go wrong - and they will - it’s almost always because something obvious lived only in your head. The agent is extremely literal about ideas you never actually wrote down.
Agents don’t read minds. They read specs.
Specs are living documents, not contracts
Early on, I treated specifications like something you “finish” before implementation. That’s how we’ve been trained to think about them. That model doesn’t hold up here.
The real work happens in discussion - first before implementation, then again when implementation reveals new constraints.
I often spend time having the agent rewrite or reorganize the specification before asking it to change the code. This feels backwards for about a week, and then inevitable.
The spec stops being a plan and becomes a description of the system as you understand it today.
The agent amplifies everything
One of the most important mental models to internalize is that agents amplify everything.
Clear intent scales. Ambiguity scales. Bad assumptions scale. Architectural mistakes scale.
The old rule was garbage in, garbage out. This is closer to garbage pile in, garbage pile out.
In one case a data structure assumption slipped through early because I wasn’t yet sure if it was correct. The system happily built around it. By the time I revisited the decision, it had propagated everywhere. Fixing it was fast - understanding its spread wasn’t.
Speed doesn’t prevent mistakes. It industrializes them.
Collaboration works best when it goes both ways
One surprisingly effective tactic is to explicitly ask the agent to ask you questions.
Left alone, an agent will often make reasonable assumptions and move forward. Sometimes that’s exactly what you want. Other times, it’s a fast path to subtle misalignment.
Making the interaction bidirectional improves the output dramatically. When it works well, it stops feeling like command-and-control and starts feeling like a real working relationship.
Architecture does not take care of itself
Speed can be deceptive. When code appears quickly, it’s tempting to assume the system is organizing itself. It isn’t. It’s just becoming confidently wrong faster.
You have to actively steward the architecture. Agents tend to anchor in whatever structure exists today, even when a deeper rethink would be healthier.
I once asked the agent to analyze a processing pipeline that felt off. The explanation immediately showed how the design had veered from my earlier intent.
The system was internally consistent.
It just wasn’t the system I meant to build.
When things break, resist the urge to dive right into code
As systems grow, regressions appear.
My instinct used to be to dive straight into the code. Now, I first ask the agent to explain what it believes exists - not what it tried to build, but what it thinks is there now.
Seeing the system described back to you reveals the mismatch quickly - and often the part you misunderstood first.
This takes patience. But it works.
A different economics of building
Historically, product development has been about careful addition. Building was expensive, so you spent most of your time deciding what not to build.
With agents, that constraint loosens. Instead of choosing one idea and hoping it was right, you can try several and remove the ones that don’t work. Seeing something exist is more informative than debating it in the abstract.
Ideas alone are cheap. Reality is decisive.
The agent does not share your emotional attachment to effort. It’s a little like the first time you write a for-loop and realize the computer doesn’t get tired.
The hidden cost: decision fatigue
There is, however, a cost that’s easy to underestimate.
Execution used to create thinking time. Now the system keeps up with every decision you make, and you spend less time implementing and more time deciding - continuously.
The computer is no longer tired. You are.
This can feel exhausting in a different way. If you find yourself overwhelmed despite moving faster than ever, that’s not a failure mode - it’s a sign that you’re now operating at the level where judgment matters most.
Someone recently told me they were occasionally relieved when they hit their daily token limit because it forced them to stand up and take a walk.
That felt accurate.
Stay informed, but don’t chase the shiny things
This space is moving fast, and it’s worth paying attention.
But progress doesn’t come from constantly switching tools or chasing every new plugin. It comes from learning how to work effectively with the agent you already have.
Depth beats novelty here.
Where this leads
At this point, a lot of people ask the same question: OK, but how do you actually do this well?
That’s where things get interesting.
In the next part, I’ll go deeper into the craft - how I structure specifications, how I keep agents aligned over time, and how to steer complex systems without losing the thread.
Once the spec becomes the programming language, how you shape it becomes the craft.