What Your Coding Agent Can't See in the Code - Tom Moor, Linear

Linear started around 2019 because its founders wanted an issue tracker they enjoyed using. The tools they knew were slow, buggy and hard to use. Within the life of that product, the engineer picking up an issue went from accepting an AI-assisted tab completion in 2021 to steering an early coding agent in 2024. Tom Moor sees a consequential step after that one. When an engineer directs a local agent, they can explain a decision as the work unfolds. When several agents run automatically in the cloud, that explanation has to reach them some other way.

How much cheaper might it get to hand work to an agent? Moor illustrates the trend with a chart comparing the cost of a level of model capability over three years, from $100 to five cents. He uses that comparison to imagine a future in which generating a feature’s worth of code takes about as long as snapping your fingers. The chart concerns model capability. The cost of getting a particular feature ready to ship is a different question.

The other change is how long an agent can work between interventions. Moor describes runs lasting hours or days, though he questions how much code from the much-discussed weekend runs actually ships. If agents can work cheaply for that long, manually delegating, starting and stopping each run becomes an awkward way to coordinate them. More of the work moves into the outer loop — deciding what to hand an agent, what it needs to know and how to judge what comes back.

Consider a settings page. Each request to add one more option can make sense on its own. Fulfill enough of them and the result starts to resemble Moor’s deliberately overstuffed illustration. Implementation has become cheap enough that the harder decision is which settings deserve to exist together. Consistency and restraint come from many small decisions that reinforce one another.

Reading the implementation tells an agent how a feature works. The reason a customer needs it, the compromise that shaped its design and the way it should feel in use may live elsewhere. So may the information that another team is changing it, that a product lead owns the decision, or that someone reverted a similar change two weeks ago. Linear’s approach is to collect that context while investigating the original idea and carry it through planning, implementation and review.

A support request, a chat message, a product idea from the CEO and a monitoring alert can all become incoming work. Linear collects them in triage. Its triage agent labels and assigns issues, groups them into themes, closes duplicates and routes work to the relevant team or person. When the report leaves a consequential question open, the agent flags the decision that needs more input.

The agent also investigates and leaves its findings on the issue for the next person or agent. A terse crash report can acquire a stack trace and associated logs. Internal tools connected through MCP can supply account information. Customer history can reveal that a high-value customer has asked for the same thing three times in a month. Related issues can explain what the team decided the last time it touched this area. Each addition answers a different practical question, from where to start debugging to how much the request matters.

Why did video captions keep turning on? Finding the setting would tell an engineer where the preference lived. Reproducing the bug revealed something more specific. The browser performed an action automatically, and the product interpreted that action as a choice the user had made. The triage agent left that distinction on the issue. Moor credits the diagnosis with making an automated fix possible.

A second request raised a different question. Had the product lost behavior it used to support? The investigation found similar work that had already shipped and ruled out a regression. It identified the customers associated with the request, recognized its value and pointed to a likely starting place in the code. The handoff gave the implementer both a reason to pick up the work and somewhere to begin.

When triage judges a bug small enough, Linear starts the fix automatically. A person can also initiate the work, using the issue context locally through MCP or running the agent remotely. The choice of who starts the job is separate from where it runs. In either case, the coding agent begins with the investigation.

Two things matter once the agent makes a change. It needs a way to verify its work, and failures from continuous integration (CI) need to reach the agent so it can act on them. The issue explains the intended behavior. The failing check gives the implementer fresh evidence about the proposed fix. Moor reports that this combination worked well for his team and points to reusable verification skills as one way to give an agent that capability.

A code reviewer working from the repository can catch plenty of logical errors. Linear dispatches a review agent with a second question to answer. Given what the customer needed and what the team knows about this part of the product, is this the right change? The agent starts with the original issue, including the customer context and intent that triage recorded.

What can review look up that triage could only anticipate? By the time a pull request exists, the reviewer knows which code actually changed. That narrows the search for earlier decisions, reverts, regressions and incidents. It also gives the agent a reason to revisit related issues. Minutes or weeks may have passed since intake, and another change may now overlap or conflict with this one.

The reviewer can also read the full coding session. A one-shot implementation and a long exchange with a human can end in a similar diff, but the exchange may explain a critical choice. Ownership information answers a separate question about who still needs to weigh in. A product lead or the CEO may own the tradeoff even when someone else usually reviews the code.

• An open database transaction. The review agent found changes from six and seven months earlier that identified holding a database transaction open as an incident risk. A reviewer could recognize the risk from the code alone, but Codex missed it on this change. The earlier records gave Linear’s agent a specific reason to flag it.

• Icons the team had removed. A year earlier, Linear dropped some iconography because it made the interface look busy. A new pull request proposed bringing back icons the team had rejected several times. The review agent recovered that design decision and put it in a review comment. The comment went straight back to the coding agent, giving it the reason those icons were missing in the first place.

• The order of two kinds of labels. Should workspace labels appear below team labels? The proposed change appeared to put them in that order. Linear lists labels in many places, with no single piece of code defining the convention across the product. A previous revert and a related issue gave the reviewer grounds to flag the ordering. Reading either list in isolation would do little to explain why its order mattered.

These findings also have a human destination. Linear built a review interface that guides a person through the changes and brings earlier decisions to their attention where a judgment call is needed. Knowing why the team removed an icon gives the reviewer something concrete to consider when deciding whether it belongs this time.

After a merge, the code contains the outcome. The issue and pull request still contain the discussion that explains it. Once a day, a Linear automation scans the day’s merged work for actionable lessons. It looks for places where a review comment led to a change or where a revert happened. That gives it a way to select feedback that affected the product and write the lesson into the repository’s agent instructions or the relevant documentation.

Daily is a choice that fits Linear’s pull request volume. Another team could run the job more or less often, using its own automation tooling. The extraction prompt takes experimentation, too. A reviewer’s correction should be available to the next implementer, but continually appending every lesson would eventually leave an agent with an enormous instruction file to read. Choosing what deserves to stay is part of the work.

Moor’s aim is fewer avoidable changes and less rework. At intake, the customer’s intent can redirect an investigation before anyone builds the wrong fix. At review, an old decision or another team’s ongoing work can change whether a pull request should ship. A human who makes that call has already done the expensive part. Keeping the reason gives the next agent a chance to act on it before someone has to make the same correction twice.