The observation
For the last year, every team I have worked with has had the same bottleneck: the developer. Not because the developer is slow, but because the developer is the only person who can turn "I wish this worked differently" into a line of code that ships. Sales leads have ideas. Operations leads know exactly which field is in the wrong place. They write it down. It lands in a Notion. The developer triages, asks three questions, gets a half-answer, builds it two weeks later, and the asker has already forgotten what they asked for.
The interesting thing is — the asker is usually right. The requirement is usually small. The reason it does not ship is not the work. It is the pipeline.
What I am trying
In the AI Agent era, the pipeline is no longer the bottleneck. The bottleneck is the handoff. So I am rebuilding the handoff, end to end, with agents.
The loop, as I am running it now:
1. A frontline user — a sales lead, an operations lead — opens a module in our internal tool and files a requirement. Not in free text. In a structured form. "When X happens, I want this field to behave like Y." The form is opinionated on purpose, so the user is nudged into thinking about edge cases, not just happy paths. They iterate on it inside the module until the requirement actually reads the way they mean it.
2. A higher-tier agent reads the requirement. It checks the existing system model, the data schema, the extension points we already left open. If the requirement is feasible as stated, it drafts a confirmation. If it is not, it does not say no. It says — "here are three ways to interpret what you mean, pick one, or describe a fourth." The conversation stays in the user's language, not the engineer's.
3. Once aligned, the requirement is handed to a coding agent. The coding agent writes the change in a sandboxed branch, runs the test suite, and opens a PR. The PR description is written for the original asker, not for the reviewer — so they can still recognize what they asked for, two weeks later.
4. A human architect reviews the PR. Not for the requirement — the agent and the user already aligned on that. The architect reviews for system-level concerns: does this break an extension point? Does it bleed into another module? Does it leave the schema in a state the next agent will misread?
5. Merge. Deploy. Loop.
The whole thing lives in Git logic. The requirement, the conversation, the diff, the review — every step is a traceable artifact. The non-dev user does not need to know what a branch is. They just need to know that their idea is now a thing, with a number, that they can watch go from draft to live.
Why now
Two reasons.
First — the cost of running an agent through a single requirement is finally lower than the cost of the human meeting that used to triage it. A year ago this was science fiction. Today, a moderately capable agent can hold a schema in context, write a diff, and open a PR that is good enough to review. The remaining work — the part that needs a human — is the part the human is uniquely good at. The architect. The original asker. The two ends of the loop, not the middle.
Second — the people closest to the problem are not the developers. They are the sales lead watching a customer churn because a quote PDF is wrong. They are the operations lead noticing that 30% of returned items share a mis-categorized field. They know the problem. They do not need to know how to code to file it correctly. They only need the right door.
What I am not doing
I am not letting non-developers push to main. I am not replacing the architect. I am not assuming the agent is right.
I am also not building this in a week. I am doing it step by step, with a small group of frontline management — the ones who already file requirements well, the ones who push back when something is unclear. If it does not work for them, it will not work for anyone. If the review agent is annoying to them, it is annoying. Full stop.
Where I am now
The first version is up. We have a structured form. We have a review agent. We have a coding agent. We have an architect on call. In the last month, we have shipped 11 PRs this way. Six of them were filed by people who have never written a line of code.
It is not faster than the old pipeline. It is slower, in fact, for the first three requirements. By the eleventh, the conversation between the user and the review agent was under four minutes. That is the curve I am watching.
I do not know if this scales. I do not know if it survives contact with a real customer emergency at 11pm. I do not know what happens when a sales lead files something the system model was never designed to express. But the alternative — waiting for a developer to have time — is not a system. It is a queue.
I would rather build a small, careful loop that works, than a grand one that does not.