Engineering Is Now More Planning Than Coding. Here's How We Shifted Our Process.

For most of my career the math on software was simple. Ideas were free. Building was expensive. So you got picky about ideas, because every one of them cost you a quarter of engineering time, and picking wrong was how you lost a year.

That math broke. Building is cheap now. And it turns out the other half of the job, the part where a group of people decide what is worth building, never got any easier at all.

The Agreement Bottleneck

Nobody warned us about this part. When a feature takes three months, you get three months of forced alignment for free. People argue in the meeting. The spec gets written. Someone raises the objection about the queue, and there is time to deal with it, because there is time for everything.

When a feature takes an afternoon, all of that disappears. The code shows up before the conversation does.

We hit this hard at Cotera over the last year, and we hit it because of something that went right. We made big parts of our codebase genuinely good to work on with AI. Integrations, schematics, our agent control plane. In those areas you can describe what you want, let the agent write it, and our test suite tells you within a few minutes whether you were right. Prompt to production, actually working, not as a demo.

That was great. It was also a problem.

People who had never shipped to production started shipping to production. Our forward-deployed team sits with customers all day and sees bugs before anyone else does. Their old instinct was to file a ticket and wait for engineering. Their new instinct is to go fix it themselves. For a lot of bugs that instinct is correct, and I would much rather have that instinct on the team than not.

For the rest of the bugs, it created something worse than the original wait.

The Review Tax

If you are an engineer you already know this feeling. Someone vibe codes a fix. The PR lands in your queue. It is 900 lines. It works, technically. It also introduced a second way of doing something the codebase already had one way of doing, and now you are the person who has to explain, politely, why that pattern cannot stay.

Reviewing that costs more than writing it would have. And it is miserable work, because you are reverse engineering a decision that a model already made at two in the morning.

We spent a while treating this as a code quality problem. It is not one. The code was usually fine. The real problem is that a decision got made without the person who owns that part of the system, and a pull request is a terrible place to have that argument. By the time there is a diff, everyone is invested, the work is done, and saying "start over" costs you a person's whole afternoon and some goodwill.

We Moved the Argument Earlier

So we changed the order of operations. For anything outside the zones where we let agents run free, the process now starts with a plan instead of a diff.

1. Someone writes the ticket in Linear and describes the problem properly.
2. They kick off a coding agent from that ticket. The agent's first job is not to fix anything. Its job is to propose how it would fix it.
3. We tag whoever owns that piece of the architecture.
4. The two of them argue about the proposal in the ticket comments. Sometimes that takes four minutes. Sometimes the answer is that we are not doing this at all.
5. Once the plan survives, the agent implements it and ships it.

All of it happens in the ticket. No context stranded in somebody's terminal.

What surprised me is how much better the arguing gets when there is something concrete to argue with. "How should we fix this?" gets you a meeting. "Here is the plan, it touches these four files and adds a queue" gets you a real answer in a comment thread, usually within the hour. Senior engineers are good at spotting a bad plan in thirty seconds. They are much slower at spotting a bad plan hidden inside 900 lines of working code.

The senior engineer's time now goes to reviewing a plan. That is the part that needed them.

The Agent Also Watches What It Shipped

The piece we added most recently: once the PR merges, the same agent goes and checks our logging dashboards, and it reports back on the same ticket.

It pulls the metrics for whatever it touched. Did error rates move? Did latency go sideways? Did we quietly take out a service that nobody was watching? This has already caught things, and finding out from a comment on the ticket is a lot cheaper than finding out from a customer.

So the ticket is the unit of work now. Problem statement, plan, argument, implementation, and the check afterward all live in one place. The branch is just an artifact of the middle part.

Why Use an Agent For This

So far this has been a story about coding agents. That is the part I care about least.

Most tickets do not stall on code. They stall on "is this hitting anyone big?" and on "how many people even go through this flow?" A coding agent cannot answer either one. It reads your repo and nothing else. Those answers live in your CRM, your support queue, and your product analytics, and a model that only sees source files will never find them.

That is the thing we fixed. You can point a Cotera agent at a Linear ticket and have it pull the real context in. A PostHog agent that reports how many accounts hit the broken flow. A support agent that digs up the four tickets already filed about it. A research agent that reads what competitors do here before anyone scopes the work. It posts what it found on the issue, and then you scope off that instead of off whoever argued hardest in the meeting.

This is also how the non-engineers stay in it. Our forward-deployed team does not need to write the patch to be useful. They need to attach the customer reality to the ticket, and now they can do that from the tool they already have open. Want it on a schedule instead? The Linear Issue Triage Agent takes the first pass on labels and priority, and the Linear Sprint Status Reporter pulls the board state so nobody has to.

We're Launching With Linear This Week

Coco by Cotera is live in Linear's agents directory, and you can read what it does on the Linear integration page. Coding is one use of it. Bringing your company's actual context into an engineering ticket is the one I care about more.

Engineers here are going to spend more time managing how the product gets built and less time building it. That sounds like a downgrade. It isn't. More of the team gets to build software, and the people who know the system best spend their day on decisions rather than cleanup. We're glad to be doing this one with Linear.

Two things if you want to go deeper. We wrote up the infrastructure behind our coding agents in Cotera Code. The economics of splitting work across many agents are in AI Workflows vs. AI Agents.

Ideas are still cheap. Building is cheap now too. Agreement is the expensive part, so we moved it to the front, where it belongs.

Try These Agents

• Linear Issue Triage Agent — sets priority, labels, and assignment on new issues automatically
• Linear Sprint Status Reporter — completion rates, blocked tickets, and overdue issues without opening the board
• Linear Slack Standup Generator — daily standup built from real issue data
• Linear Backlog Grooming Agent — finds stale issues and flags what needs re-prioritizing