There is a scene that is becoming more and more common in software development right now.
You have one AI coding agent refactoring something.
Another one is writing tests.
A third is handling some annoying migration you did not want to touch yourself.
You are bouncing between terminals, checking progress, answering questions, approving changes, and generally supervising a tiny army of extremely enthusiastic robot developers.
And then the thought hits you:
I could open another terminal.
I have absolutely done this.
The problem is not that running multiple agents is automatically bad. Parallel work can be incredibly useful. The problem is that the second AI gives us more capacity, our first instinct is often to immediately fill that capacity with even more AI work.
Instead of asking, “What should I do with the time this just gave me?” we ask, “How much more stuff can I cram into this workflow?”
That works for a while.
Then things start getting weird.
AI Coding Tools Really Do Make You Faster
I do not think there is much point pretending otherwise.
AI coding tools can make development dramatically faster, especially for certain kinds of work.
Boilerplate that used to take half an hour can appear in seconds. Setting up basic project scaffolding is almost trivial. Stupid syntax mistakes disappear faster. Tests, utility functions, repetitive components, documentation, migrations, and all kinds of boring little tasks can be delegated.
So naturally, developers start doing more.
That feature you were going to put off until next week? Might as well do it now.
That weird side project idea? Fire up another agent.
That one annoying task nobody wants to do? Toss it at the AI.
Suddenly the amount of work you can start feels almost unlimited.
The amount of work you can actually understand, review, and maintain is another story.
Speed Creates Its Own Problems
If you generate code five times faster, you can also lose track of what the hell is happening five times faster.
One of the strangest signs of this is when you find yourself reading an AI-generated summary of a change just to remember what your own project is doing.
I have caught myself doing this.
The agent finishes some task, gives me a neat little summary, and I am reading it thinking, “Oh right. That is what we were changing.”
That is probably not a great sign.
At that point, you are no longer really engineering the system. You are managing a queue of things being engineered around you.
And that becomes dangerous when the mistake is not obvious.
Imagine you ask an agent to implement a permission system.
The code looks clean.
The naming matches the rest of the project.
The tests pass.
Nothing immediately looks broken, so you approve it and move on.
Except maybe your prompt never clearly defined how restrictive the permissions were supposed to be. The model filled in the missing details itself and chose something more permissive than you intended.
The tests still pass because they only verify that permissions work.
They do not verify that the permissions match the security model you had in your head.
That distinction matters a lot:
Passing tests does not automatically mean the software is doing what you actually intended.
AI Did Not Remove the Bottleneck
It moved it.
For a long time, one of the slowest parts of programming was simply turning an idea into working code.
You had to write the implementation yourself, debug it, fix syntax errors, wire everything together, and slowly turn the design into something executable.
AI can now blast through a lot of that work.
Great.
But now we have a different bottleneck.
Understanding and verification.
The faster code gets generated, the more code somebody has to review.
And generated code still needs review.
Heavy AI adoption among developers correlates with significantly longer PR review times. That makes sense. If everyone suddenly starts producing dramatically more code, human review capacity does not magically increase along with it.
This gets even more interesting with experienced developers working in large, complicated codebases.
AI can feel faster because you are typing less, while actually making the overall task slower because you now have to carefully inspect a bunch of generated code interacting with years of existing architecture.
That is one of the things I think gets lost in a lot of AI productivity discussions.
AI is amazing at some kinds of development.
Small isolated features? Great.
Boilerplate? Fantastic.
A giant legacy system where changing one innocent-looking function somehow breaks seven unrelated things and awakens a forgotten service from 2014?
Different story.
And this creates a strange contradiction.
AI is writing more and more production code, while developers still regularly report hallucinations, incorrect output, and limited trust in what the models produce.
We are delegating faster than we are learning how to verify.
That creates verification debt.
You save time during generation, but some of that time has not really disappeared.
It has just been moved somewhere else.
Maybe into code review.
Maybe into debugging.
Maybe into production incidents six weeks later when somebody finally discovers the assumption the model quietly made.
Why Do We Keep Opening More Agents?
Part of this is technical.
Part of it is also very human.
There is a weird little dopamine hit that comes from watching AI agents crank through tasks.
Feature finished.
Another PR.
Another commit.
Another task crossed off the list.
Visible output feels productive.
Meanwhile, spending two hours understanding an architecture diagram or reading framework documentation might produce exactly zero commits.
Even if it saves you ten hours later.
There is also a measurement problem.
It is easy to count closed PRs.
It is harder to measure “developer now understands the system well enough to prevent three terrible architectural decisions.”
And then there is the career anxiety around AI.
A lot of developers are understandably wondering what all of this means for their jobs.
That creates pressure to become the person running more agents, producing more code, and moving faster.
Almost like we need to prove we can keep up with the machines by becoming extremely efficient machine supervisors.
The irony is that blindly maximizing AI output may make us worse at the exact skills we are going to need most.
So What Should We Do With the Time AI Gives Us?
This is the part I think matters most.
If AI saves you two hours, you do not necessarily need to spend those two hours generating another two hours worth of code.
Use some of that time for the stuff developers never had enough time for before.
Actually Read the Documentation
Not skim it looking for the one code snippet that solves your immediate problem.
Actually read it.
Understand how the framework works.
Read the architecture docs.
Look at the edge cases.
Understand why the API behaves the way it does.
The better your mental model of the system is, the better your prompts become too.
AI works a hell of a lot better when the person steering it understands what they are steering.
Write Better Specs Before You Generate Anything
This is probably one of the biggest workflow improvements you can make.
Before launching an agent, clearly define what the thing should do.
Also define what it should not do.
Write down important constraints.
Define security boundaries.
Mention the ugly edge cases.
Tell the model what must remain unchanged.
A prompt like:
Add a permission system.
leaves a massive amount of room for interpretation.
A specification that explains permission scopes, forbidden wildcard access, role inheritance, failure behavior, expected tests, and review requirements leaves considerably less.
Models are very good at filling gaps.
Unfortunately, they do not always fill them with what you meant.
Talk to Humans
Wild concept, I know.
Sometimes the best thing you can do with your newly reclaimed development time is talk to the product person, designer, teammate, user, or whoever actually understands the requirement you are about to implement.
AI can generate twenty implementations of an unclear requirement.
It cannot magically make the requirement less unclear.
Keep Useful Technical Documentation
Architecture decisions.
Important tradeoffs.
Why something was implemented a certain way.
What absolutely should not be changed without understanding some weird dependency.
This stuff becomes even more valuable when AI agents are touching the codebase.
Good documentation gives both humans and agents better context.
And unlike yet another generated feature, it keeps paying off later.
The basic idea is pretty simple:
The time AI gives you is often more valuable when you spend it doing things AI cannot do well than when you immediately throw another agent at another task.
A Few Rules I Have Started Thinking About
I do not think there is one perfect AI coding workflow, but there are a few principles that make a lot of sense to me.
1. If you cannot explain the feature, do not prompt it yet
If the requirement is fuzzy in your own head, the model is going to fill in the blanks.
Sometimes it will guess correctly.
Sometimes it absolutely will not.
Figure out the boundaries first.
2. Do not merge code you cannot explain
You do not need to memorize every line.
But if an agent gives you a giant diff and you cannot explain what it changed, why it changed it, and how the important pieces work, that is probably not ready to merge.
“Tests passed” is not enough.
3. Be extremely suspicious around high-risk code
Authentication.
Authorization.
Payments.
Database mutations.
Encryption.
Permission systems.
Anything where a mistake could expose data or seriously break something deserves much more careful review.
Those are not great places for the old:
“Looks good from here.”
4. Stop treating maximum parallelism as the goal
Sometimes one agent working on one clearly defined problem is better than four agents generating four separate review queues.
Every additional task has a context cost.
Eventually you become the bottleneck.
5. Count review time as part of the task
If an agent writes something in four minutes and you spend forty minutes verifying it, the task did not take four minutes.
It took forty-four.
That does not make AI useless.
It just means we should stop measuring productivity by generation speed alone.
6. Ask the AI why
Do not only ask for code.
Ask why it chose that approach.
Ask what alternatives it considered.
Ask what assumptions it made.
Ask where the implementation might fail.
Ask what part it is least confident about.
Using AI as something you interrogate is very different from using it as a code vending machine.
7. Still write code yourself sometimes
I am very pro-AI coding tools, obviously.
But I also think there is value in occasionally turning them off and actually building something yourself.
You need enough hands-on understanding to recognize when generated code is bullshit.
That skill gets harder to maintain if you never exercise it.
We Have Been Through This Kind of Shift Before
Software development is basically a long history of building abstractions on top of other abstractions.
Assembly languages gave way to higher-level languages.
Infrastructure became cloud services.
Libraries replaced mountains of custom implementation.
Frameworks automated huge parts of application development.
Every time this happens, somebody announces that programmers are about to become obsolete.
Instead, the job changes.
Developers stop spending as much time on one layer and start working at another.
AI looks like another massive abstraction layer.
The ability to manually type code is becoming less important than it used to be.
But knowing what code should exist, how systems fit together, what tradeoffs matter, and whether the implementation is actually correct becomes more important.
That is not less engineering.
It is engineering happening at a different level.
Maybe You Do Not Need Another Terminal
I started noticing that when I reduced the number of parallel AI sessions I was running, I actually felt more in control of my projects.
I spent more time defining what I wanted before generating it.
I read more of the code afterward.
I documented decisions.
I caught more questionable assumptions.
Did that sometimes make the first thirty minutes of a task slower?
Yep.
But the software usually came out better.
And more importantly, I actually understood what I had built.
AI gives developers an absurd amount of leverage.
I love that.
But leverage works in both directions.
It can help you build faster, or it can help you create an enormous pile of code you barely understand at record speed.
There will always be another terminal you can open.
Another agent you can launch.
Another task you can parallelize.
The harder skill might be recognizing when you already have enough code being generated and the most productive thing you can do is stop generating for a minute and actually think.
Top comments (1)
This hits very close to how my own workflow has evolved.
I used to think the dangerous moment was when an AI agent produced bad code. I don’t anymore. Bad code is often easy to catch.
The dangerous moment is when it produces plausible code, plausible tests, a plausible explanation, and a green pipeline — all based on the same wrong assumption.
That’s why I especially like your term verification debt. Parallel agents don’t just create more code; they can create more claims that someone eventually has to prove.
One thing I’ve started doing is separating “implementation complete” from “claim proven.” An agent saying 42 tests passed proves very little if the agent also wrote the tests, chose the assertions, interpreted the requirement, and summarized the result. That’s one reasoning chain congratulating itself. 😄
So yes, maybe the scarce resource in AI-assisted engineering isn’t code anymore.
It’s independent attention.
And unfortunately, I still haven’t found a way to open another terminal for that.
Great piece, Jessica.