The other day, I watched someone try to fix an error with an AI coding agent.
\nThe agent made a change.\nThe same error came back.\nSo they copied the error message and pasted it back into the agent.
\nThe agent made another change.\nThe same error came back again.
\nSo they copied it again.
\nAt some point, I thought: we are not debugging anymore.\nWe are trying to start an infinite loop with an AI coding agent.
\nIt was funny.\nBut it also made me think about something more serious.
\nWho is leading the product development here?
\nThe human?\nOr the agent?
\nAgents are very good at making things happen.
\nThey 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.\nSometimes they give you ten options before you have properly understood the first one.
\nThat kind of speed feels powerful.\nAnd it is powerful.
\nBut speed also has a strange side effect.\nIt can make activity look like progress.
\nYou see files changing.\nYou see commits appearing.\nYou see a new screen in the browser.\nEverything feels alive.
\nThen you ask a simple question:
\nWhy are we building this?
\nAnd suddenly the room gets a little quiet.
\nThat is the moment I think matters most.
\nBecause an agent can be very confident about how to build something without knowing whether the thing is worth building in the first place.
\nIt can create a beautiful settings page.\nIt can add a workflow with six states.\nIt can refactor half the application to make the architecture look cleaner.
\nBut it does not sit with the customer when the product is confusing.\nIt does not have to explain a missed deadline.\nIt does not feel the pain when the team has to maintain a clever solution six months later.
\nWe do.
\nI do not see agents as little developers that we hand tickets to and forget about.
\nI see them more like extremely fast collaborators.
\nThey are great at exploring ideas, taking care of repetitive work, and helping us move through the boring parts faster.\nThey can give us a first draft when a blank page would have slowed us down.
\nBut a first draft is not a direction.
\nSomeone still has to decide what good looks like.
\nSomeone has to understand the customer problem well enough to say no to a feature that sounds smart but solves nothing.\nSomeone has to notice when a technically correct solution makes the user experience worse.\nSomeone has to protect the simple version of the product when the agent keeps offering a more “complete” one.
\nThat is human work.
\nNot because humans are better at typing code.\nHonestly, agents are already removing a lot of that work from the job.
\nHumans lead because product development is mostly judgment under uncertainty.\nThere is no error message for a feature that nobody wants.
\nThere is a debate about whether developers should review agent-written code line by line.
\nI think that debate is a little too narrow.
\nOf course, quality matters.\nTests matter.\nCode review matters.\nLogs, alerts, and security checks matter too.
\nBut the deeper responsibility is understanding the system well enough to reason about it.
\nYou should know:
\nThat does not mean reading every line with a magnifying glass.\nIt means staying close enough to the intent that the implementation never becomes a mystery.
\nAgents can write the code.\nWe still own the system.
\nThat is the line for me.
\nI think a lot of developers are still measuring their value by how much code they can write in a day.
\nThat made sense for a long time.\nWriting code was the bottleneck.
\nNow, more often, the bottleneck is knowing what to ask for and knowing whether the answer is actually good.
\nThe work moves upward.
\nLess time is spent manually wiring every small detail together.\nMore time is spent making the problem clear, setting boundaries, checking tradeoffs, and cleaning up the mess when an experiment goes too far.
\nThis is not less technical.\nIn some ways, it is more technical.
\nYou need enough product context to direct the agent well.\nYou need enough engineering context to spot a risky shortcut.\nAnd you need enough taste to know when the output is impressive but wrong.
\nThat last part is underrated.
\nAn agent can build something that works perfectly and still should not exist.
\nThere is another part of this that I find interesting.
\nMost agent workflows are designed like a tiny magic trick:
\nThat is great for a demo.\nIt is also useful for small, isolated tasks.
\nBut product work is not usually that clean.
\nThe 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.\nThose things are not clutter.\nThey are part of the memory of the product.
\nI want agents to have a durable workspace where that memory can compound.
\nNot a mysterious black box.\nNot a disposable environment that forgets everything after one task.
\nA place the team understands and controls.
\nThat 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.\nThe exact setup will change.\nBut I think the principle will stay the same:
\nGood agents need a good home.
\nI have heard that teams like Anthropic use internal environments where agents can work inside a persistent sandbox instead of starting from zero every time.
\nThat idea stayed with me.
\nSo 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.
\nThe goal is not to create a machine that builds products without me.\nThe 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.
\nI can still come back, review the direction, and make the decisions that need human context.\nBut the machine does not need to stop just because I closed the lid.
\nIt is still early, and I do not want to pretend I have found the perfect architecture.\nI am testing what should stay persistent, what should be isolated, and how much context is genuinely useful without becoming noise.
\nOnce I am confident this is a setup I would recommend, I will share the details.
\nI am very optimistic about AI coding agents.
\nThey make it easier to explore.\nThey give small teams more leverage.\nThey can help turn an idea into something testable before the excitement disappears.
\nBut I do not want to become the person who blindly copies the next error message into the machine and waits for a miracle.
\nI want to understand the problem.\nI want to lead the product direction.\nI want to know why we are shipping something, not only whether the test is green.
\nThe best teams will not be the ones that let agents make the most changes.
\nThey will be the ones that stay responsible for the meaning of those changes.
\nThe agent can move fast.\nThe human still needs to lead.
","timeToRead":6,"frontmatter":{"title":"Agents Can Write Code. You Still Own The System.","description":"A story about AI coding agents, product direction, and why the human still needs to lead","date":"2026-08-11T00:00:00.000Z","updated":null,"slug":"/blog/agents-can-write-code-you-still-own-the-system","tags":["AI","Engineering","Product","Culture"]}}},"pageContext":{}}, "staticQueryHashes": ["1672341955","2009693873","2077189868","3505212370","3825832676"]}