We gave an AI agent its own account in our project tracker

There’s a moment in every project tracker where you pick a name from a dropdown and hand someone a piece of work. On one of our current engagements, in ClickUp, that dropdown has an AI coding agent in it.

It’s a named account with its own email address, sitting in the assignee list between two human engineers. It gets assigned tickets and moves them through the board, and a few times now it has opened tickets of its own.

Most of what we learned came from the preparation. Before the agent could have that account, we had to fix a set of things about our own workflow that we’d been carrying for years.

An agent in the assignee list raises an immediate and slightly uncomfortable question: which tickets is it allowed to have?

Our answer is a tag. A ticket can’t go to the agent until a human has explicitly marked it ready. Nothing else about the ticket changes – it keeps its priority and its template, and it gets a label that means one specific thing:

This specification is complete enough that generated code can be trusted against it.

That’s the whole policy, and it sounds like process theatre until you try to apply it to a real backlog, at which point it becomes the most useful thing in the workflow. Think of it as the address label on a parcel. The courier doesn’t care what’s inside the box, but they won’t take it off your hands without a full address on the front. The first time you go to tag a ticket and find you can’t, you’ve learned something concrete about your own backlog that no retrospective would have surfaced.

A ticket that says “improve the upload flow” can’t be tagged. Neither can one whose acceptance criteria are a few bullets of intent rather than a checklist you could tick, or one that silently depends on a decision nobody has written down, because the agent will make that decision for you, plausibly, and you won’t notice until much later.

So the tag became a filter on specification quality. Tickets that fail it go back to be written properly instead of being handed to a human, which is what should have happened anyway.

The other thing that had to change was the input.

The agent works from the same material the humans work from: architectural decision records that state which decisions were made and why, a glossary held in the repo that binds the vocabulary across client, designers, producers and engineers, house voice rules for anything the user will read, and an acceptance-criteria checklist that defines done in terms a reviewer can verify.

That material existed before the agent showed up, because a twenty-year engineering practice knows what happens when you skip it. What the agent did was make the cost of skipping it immediate rather than deferred. A missing ADR used to cost you an argument in month four. Now it costs you a generated implementation that looks coherent and well formatted, and is quietly built on an assumption nobody agreed to.

Work is sequenced the same way it was before: tracer-bullet tickets that cut the thinnest complete path through every layer, with explicit blocking edges between them, grouped under umbrella epics whose descriptions say plainly that they’re containers rather than units of work. (That last note exists because both humans and agents will otherwise try to “do” an epic, and neither should.)

Every change the agent produces goes through human code review before it lands. The board is to-do, in progress, code review, completed, and the agent has no path around the third column. There’s no configuration in which agent work merges itself.

The part that surprised us was the agent filing its own tickets.

Some of them were routine. Several were cleanup work that a human team would have kept walking past: stale copy still referencing a flow that had been replaced, docstrings describing behaviour the function no longer had, and tests that asserted nothing, the green ones, the ones that would pass whether the code was right or wrong.

It’s the maintenance bill every engineering team is carrying and mostly declines to itemise. What changed was that something in the system was reading the whole codebase with no stake in the previous decisions, and no social cost attached to pointing out that a test was decorative.

Stack Overflow’s 2025 developer survey is the most useful reading on this, because it measures the mood rather than the output. Across roughly 49,000 respondents, 84% use AI tools or plan to. 3.1% say they highly trust the accuracy of what comes back, and 45.7% actively distrust it (Stack Overflow).

That’s near-universal adoption sitting on a trust level that rounds to nothing. It looks irrational until you notice how few workflows have a gate in them, and then it looks like an accurate read of the situation by people who have been burned.

The figure that describes our board best is a different one from the same survey. The top frustration, named by 66%, is “AI solutions that are almost right, but not quite”, and 45% say debugging AI-generated code takes more time than they expect.

Code that’s plainly wrong gets caught by a test, or by a reviewer glancing at the diff. Almost right is the expensive kind, because it passes both and surfaces in month four, in a part of the system nobody connects to the change that caused it. The tag and the review column don’t make the output better. They put a person in the path of almost right twice: once before, where a specification written properly leaves it fewer places to hide, and once after, where somebody checks.

The other half is the part we’d actually stand behind: the categories of work where handing the agent a ticket is the wrong call. We’ve learned most of them by getting our hands dirty.

Specifying can cost more than building. Some work takes twenty minutes to do and two hours to describe precisely enough to be tagged: a gnarly one-off data correction, a fiddly integration against an API that behaves differently from its documentation, anything where the shape of the answer only becomes clear while you’re in the code. Writing that specification is waste. An engineer just does the work and moves on.

Some decisions have no right answer. A meaningful share of engineering decisions have no correct option, only a set of trade-offs someone has to choose between and then be accountable for. Which of two defensible data models to commit to. What to do when the client’s stated requirement and their actual workflow disagree. Whether a break is worth taking now to avoid a compatibility shim that lives forever. An agent will make these decisions confidently, which is the problem, because decisions with consequences need a human name attached to them – someone still around in year three to explain why.

Some work crosses a boundary the agent can’t see. Context windows have edges, and systems have things that live outside them: an undocumented downstream consumer, a client-side assumption in a different repository, an operational constraint that exists only in someone’s head or in a conversation last Tuesday. The agent only knows what’s in its context window, so it fails quietly instead of loudly.

The one we watch closest is a plausible passing test over a wrong implementation. This is the most dangerous output in the whole workflow, because it’s indistinguishable from success on every dashboard. Green suite, closed ticket, and an implementation that’s wrong in a way the test was never written to catch. It’s why review stays mandatory and why we audit for vacuous tests on purpose. “The tests pass” doesn’t win arguments on this project.

We’d struggle to tell you whether we close more tickets per week now. That wasn’t the point – the account was a forcing function.

Once an agent has to be assigned a ticket, the ticket has to be good enough to assign. Once generated code gets reviewed against a checklist, the checklist has to be real. And a decision that something without judgement has to respect needs to be written down somewhere. Everything that made the agent effective is ordinary good engineering practice: precise acceptance criteria, decisions recorded as records, a glossary that binds, a review gate with teeth. Teams have always known about these and mostly skipped them, because skipping is cheap in the short term and every team lives in the short term.

The agent took away the option of skipping. The people who benefit from that are the humans.

We could try to end this with a number about how much faster we got, but the measurement is harder than it looks and we don’t trust the one we could produce. What we can say is that the project now has a system in it – the gate, the records, the checklists, the review – and it would be in better shape than before even if you took every agent out of it tomorrow.

We built the surroundings in which the agent does the engineering we’d want, and then we check. If you’re thinking about giving an agent a seat on your board, start with the tag and see how many of your tickets can carry it. If that turns out to be an uncomfortable number, our Production Readiness Review is one way to work through it – ping us.