A team working through a ticket makes all sorts of decisions that nobody would normally bother naming as decisions.
They choose an implementation pattern, work around an awkward API, decide how to structure a function and move on.
An if-else versus case choice is ordinary implementation work. If an agent is already doing the implementation, there is little reason to preserve that decision as human work.
Things get less obvious a little earlier in the process.
Say a ticket asks for a change to an existing service. There’s enough information to start, the repository contains similar work, and the agent produces a perfectly plausible plan. The problem is that the plan adds another responsibility to a service the engineering team has been trying to move away from.
The repository might not tell you that. In fact, it’ll probably point in the opposite direction. Years of existing code can make an old architecture look like the preferred one long after the team has decided to stop extending it.
METR’s 2025 randomized trial found that experienced open-source developers working on repositories they already knew took 19% longer when allowed to use early-2025 AI tools.
Someone who understands where the wider system is heading can change that part of the plan and then leave. They don’t need to spend the afternoon following the implementation just because their judgment was needed for ten minutes near the beginning.
This is where some of the discussion around “human in the loop” gets too simple. It makes the human sound like an approval mechanism attached to an otherwise autonomous workflow. In practice, the useful intervention may be much narrower than approving the work at all.
A database choice can be like this. So can an unresolved product behavior. Once the choice has been made, there may be hours of work that an agent can handle without much help.
What needed experience was choosing the direction, not carrying out every step that followed.
The codebase won't answer every question
Some missing decisions only become visible after the work has already started.
A bug might arrive with a good description and nothing particularly suspicious about it. While tracing the behavior, the agent finds two services handling the same condition differently. Both implementations have been there for years. Neither looks broken and you didn’t get a helpful comment explaining why they diverged.
This is a normal state for an old codebase.
One service may have been migrated and the other wasn't. The difference could be intentional or somebody changed their mind halfway through and the cleanup never happened.
The agent has plenty of information to continue coding and not enough information to know what the team actually wants.
We would rather see that uncertainty come back than discover three weeks later that the agent picked one implementation and accidentally established it as the pattern for new work. By this point it’s already found the relevant code and narrowed down what is unclear, so the engineer coming in isn’t restarting the ticket.
They’re answering the question the repository couldn’t.
Not every interruption deserves that treatment. Sometimes the agent will ask about something an engineer considers trivial and, after seeing it happen a few times, the team will decide it should just carry on next time.
Sometimes the reverse happens. A choice that looked harmless during implementation turns out to matter much more in review.
Some ambiguity should be caught before implementation starts. Other gaps only become visible once the agent has inspected the system. The more important pattern is when the ticket was reasonable and the gap is somewhere in the engineering environment.
Every few runs, an engineer has to explain that one pattern in the repository is old and should not be copied anymore.
After a while, the question becomes less about the latest ticket and more about why that explanation is still required.
Some of the engineering work moves outside the pull request
Software teams get surprisingly far with knowledge that lives almost entirely in people's heads. There may be an internal integration that still works and still appears throughout older repositories, but the platform team stopped recommending it after a difficult migration.
Unless somebody documented that decision properly, an agent searching the codebase has good reason to think the integration is still a normal choice.
Documentation has the same problem. A page can remain the official architecture guide while everyone who actually works on the system knows that one section is obsolete.
Nobody fixes it because the people who need the information already know which part to ignore and humans patch over those gaps without really noticing. They remember what happened during an incident or why something that looks reasonable in GitHub disappeared from new projects two years ago.
That works less well when more execution is handed to systems that only have the context made available to them.
An engineer can correct the resulting pull request, of course. If it happens again, there’s other work worth doing.
That correction burden is already familiar to developers. In Stack Overflow’s 2025 survey, 66% said one of their biggest frustrations was AI output that was almost right but not quite. 45% said debugging AI-generated code could take longer than writing it themselves.
The skill may be stale, or the agent may be getting architecture information from the wrong place through an MCP.
That kind of knowledge can be turned into a reusable Skill rather than copied into every agent or prompt.
Orq.ai Skills can also be referenced directly inside agent instructions using the documented {{skill.key}} syntax:
{{skill.architecture-guidelines}} |
If that skill is updated later, every reference picks up the change automatically. Sometimes there’s no technical fix because the team never wrote the convention down in the first place.
Writing it down doesn’t always produce a nice clean answer either. Two teams can sit down to document the “standard” and discover that they have been following different versions of it for months. At least now the disagreement is visible.
This is where some senior engineering work starts to move outside the pull request.
Part of the work is still architecture and difficult implementation. Another part is noticing the same exception for the third time and deciding whether the factory is missing something that the team already knows.
The boundary of human work keeps moving
You don't want to turn every odd bug into a reusable capability. If an unusual failure is unlikely to happen again, opening the repository and fixing it may take an hour. Changing the workflow around that failure could take half a day and buy you nothing.
Repeated work gives you a different calculation. The fifth explanation of the same architectural convention is probably more expensive than putting that convention somewhere the next run can use it.
It can also change your view of which work belongs in the factory. A class of bugs that looked repetitive on a spreadsheet may very well turn out to depend on unwritten product decisions every few tickets.
Something else that looked technically harder might run with very little help once the agent has the right context. You only really learn that after putting work through the system for a while.
What needs an experienced engineer will change with it.
Some architecture or requirements decisions that look firmly human today will become ordinary implementation work later. Others will take their place.
On some days, none of that will be especially futuristic. A senior engineer will correct a plan, update some stale context because the same mistake appeared twice that week, and then spend the afternoon in the repository debugging something horrible by hand.
If you’re working out which decisions should stay with engineers and which can move into the factory, see how Orq.ai helps teams operationalize that boundary.
