Agents Can Write Code. You Still Own The System.
6 min read#AI#Engineering#Product#Culture
The other day, I watched someone try to fix an error with an AI coding agent.
The agent made a change. The same error came back. So they copied the error message and pasted it back into the agent.
The agent made another change. The same error came back again.
So they copied it again.
At some point, I thought: we are not debugging anymore. We are trying to start an infinite loop with an AI coding agent.
It was funny. But it also made me think about something more serious.
Who is leading the product development here?
The human? Or the agent?
When fast looks like progress
Agents are very good at making things happen.
They can read a codebase, create a plan, write a feature, run tests, and open a pull request while you are still thinking about what to have for lunch. Sometimes they give you ten options before you have properly understood the first one.
That kind of speed feels powerful. And it is powerful.
But speed also has a strange side effect. It can make activity look like progress.
You see files changing. You see commits appearing. You see a new screen in the browser. Everything feels alive.
Then you ask a simple question:
Why are we building this?
And suddenly the room gets a little quiet.
That is the moment I think matters most.
Because an agent can be very confident about how to build something without knowing whether the thing is worth building in the first place.
It can create a beautiful settings page. It can add a workflow with six states. It can refactor half the application to make the architecture look cleaner.
But it does not sit with the customer when the product is confusing. It does not have to explain a missed deadline. It does not feel the pain when the team has to maintain a clever solution six months later.
We do.
The agent is not the product lead
I do not see agents as little developers that we hand tickets to and forget about.
I see them more like extremely fast collaborators.
They are great at exploring ideas, taking care of repetitive work, and helping us move through the boring parts faster. They can give us a first draft when a blank page would have slowed us down.
But a first draft is not a direction.
Someone still has to decide what good looks like.
Someone has to understand the customer problem well enough to say no to a feature that sounds smart but solves nothing. Someone has to notice when a technically correct solution makes the user experience worse. Someone has to protect the simple version of the product when the agent keeps offering a more “complete” one.
That is human work.
Not because humans are better at typing code. Honestly, agents are already removing a lot of that work from the job.
Humans lead because product development is mostly judgment under uncertainty. There is no error message for a feature that nobody wants.
We still own what ships
There is a debate about whether developers should review agent-written code line by line.
I think that debate is a little too narrow.
Of course, quality matters. Tests matter. Code review matters. Logs, alerts, and security checks matter too.
But the deeper responsibility is understanding the system well enough to reason about it.
You should know:
- which user problem a change is trying to solve
- what parts of the product it can affect
- what the agent assumed while it was working
- how you will tell if it helped or harmed the experience
- where you would look if something breaks later
That does not mean reading every line with a magnifying glass. It means staying close enough to the intent that the implementation never becomes a mystery.
Agents can write the code. We still own the system.
That is the line for me.
The work changes shape
I think a lot of developers are still measuring their value by how much code they can write in a day.
That made sense for a long time. Writing code was the bottleneck.
Now, more often, the bottleneck is knowing what to ask for and knowing whether the answer is actually good.
The work moves upward.
Less time is spent manually wiring every small detail together. More time is spent making the problem clear, setting boundaries, checking tradeoffs, and cleaning up the mess when an experiment goes too far.
This is not less technical. In some ways, it is more technical.
You need enough product context to direct the agent well. You need enough engineering context to spot a risky shortcut. And you need enough taste to know when the output is impressive but wrong.
That last part is underrated.
An agent can build something that works perfectly and still should not exist.
Agents need context that can grow
There is another part of this that I find interesting.
Most agent workflows are designed like a tiny magic trick:
- start a clean sandbox
- give the agent a task
- get a result
- throw the environment away
That is great for a demo. It is also useful for small, isolated tasks.
But product work is not usually that clean.
The useful context is often scattered across half-finished experiments, product notes, old decisions, local scripts, and the weird things the team learned after talking to customers. Those things are not clutter. They are part of the memory of the product.
I want agents to have a durable workspace where that memory can compound.
Not a mysterious black box. Not a disposable environment that forgets everything after one task.
A place the team understands and controls.
That could be a machine that is always available, a persistent project workspace, or a shared system that keeps the right context close to the work. The exact setup will change. But I think the principle will stay the same:
Good agents need a good home.
What I am trying now
I have heard that teams like Anthropic use internal environments where agents can work inside a persistent sandbox instead of starting from zero every time.
That idea stayed with me.
So I started experimenting with my own version: a computer in an online data center where an AI coding agent can run pretty much full-time.
The goal is not to create a machine that builds products without me. The goal is to give the agent a stable place to investigate, test, document, and move work forward while I am not sitting in front of my laptop.
I can still come back, review the direction, and make the decisions that need human context. But the machine does not need to stop just because I closed the lid.
It is still early, and I do not want to pretend I have found the perfect architecture. I am testing what should stay persistent, what should be isolated, and how much context is genuinely useful without becoming noise.
Once I am confident this is a setup I would recommend, I will share the details.
My takeaway
I am very optimistic about AI coding agents.
They make it easier to explore. They give small teams more leverage. They can help turn an idea into something testable before the excitement disappears.
But I do not want to become the person who blindly copies the next error message into the machine and waits for a miracle.
I want to understand the problem. I want to lead the product direction. I want to know why we are shipping something, not only whether the test is green.
The best teams will not be the ones that let agents make the most changes.
They will be the ones that stay responsible for the meaning of those changes.
The agent can move fast. The human still needs to lead.