We no longer treat the AI chat window as the operating model. We run AI work through a release pipeline with scoped jobs, structured results and human-controlled state.
There is a point in most teams’ use of AI coding tools where the conversation starts to break down.
At first, the workflow is simple. Open the repository in an IDE, ask an agent to investigate something, review what it changes and move on. That works well for a bug, a small feature or a contained refactor. It breaks down when the job is to review 36 modules, understand the role of each one, identify repeated quality and security issues, fix them consistently and leave behind a release record that another person can understand.
And do all of that while applying the team’s own architecture principles, implementation patterns and application goals.
The problem is not that the model suddenly becomes incapable. The problem is that a chat session is carrying responsibilities it was never designed to carry. It has to hold the scope, remember the architecture, follow the review process, decide how to report results and somehow update the team’s understanding of the release. If the session ends, much of that operating context ends with it. If another agent takes over, the team has to reconstruct the same instructions again.
The Coded Ventures team reached that point while building our multi-tenant commerce platform. We tried the familiar approaches: repository Markdown files, reusable instructions and Plan Mode. Each helped, but the process still broke down somewhere along the chain.
So we stopped treating the AI conversation as the workflow and built a workflow around the AI.
The pipeline is the operating model
We still use Cursor. We also run unattended agents through an SDK. Both are useful execution environments. But neither one owns the process.
The process sits in a local release dashboard that we use to prepare and ship a version of our software. It holds the release configuration, module registry, architecture principles, feature briefs, audit state and the later release stages such as container builds, end-to-end testing, live security, customer documentation and publishing.
It is closer to an AI-focused version of release planning than a coding assistant. It gives us—and the agents—a shared sequence of roles, checks and decisions required to ship a software version, rather than simply generate more code. For release preparation, our AI-assisted work happens inside that process. It does not sit beside it as an unrelated chat history.
For each module, the pipeline can:
Work from a master architecture brief defining the application landscape, our engineering goals and expected implementation patterns.
Maintain living module-level architecture briefs that give agents concise working context.
Run a code-quality audit against one module at a time.
Run a security audit against predefined security and trust boundaries.
Import the findings as structured release state.
Dispatch selected findings to a cloud agent for background remediation, Cursor for guided work, Linear for later action, or record them as expected behaviour.
Ingest implementation results and update the affected findings to close the workflow loop.
Generate developer documentation once the module is in a useful state.
That sounds procedural, because it is. The interesting part is not that an agent can review code. The interesting part is that the review has a defined place to start, a bounded job to perform and a controlled way to finish.
Audit first, change second
We deliberately separate auditing from implementation. An audit agent is asked to report what it finds. It is not allowed to begin tidying the code as it goes. That gives us a stable review point between observation and action.
The distinction matters. If an agent reviews and modifies the same area in one pass, the team can lose sight of what was originally found, which changes addressed it and which findings were left unresolved. It also becomes harder to compare similar issues across modules because the first few may already have been altered by the time the wider pattern becomes clear. Our audit results are written as structured findings. Each finding has an identity and enough information to be triaged, grouped and assigned later.
The release dashboard then becomes the place where a human decides what happens:
Fix sends the finding to a cloud agent for unattended remediation. This works well for simple, bounded fixes.
Send to Cursor opens a scoped job in the IDE for work requiring guidance, planning or feedback.
Expected records that the behaviour is intentional.
Send to Linear moves the finding into the backlog rather than expanding the current release.
AI does the high-volume inspection. It does not quietly decide what the product is meant to do.
One module at a time, or the whole platform overnight
Operators can run that loop for one module while working through a specific area. They can also select modules and stages and send the ordered work through an overnight batch. The batch runner is where this begins to feel different from prompting.
We are not opening 36 chat windows and pasting the same request into each one. The pipeline knows which modules are registered, which architecture briefs are current and which steps are required. It dispatches jobs in the required order and expects the same result contract from each run. By the next morning, the useful outcome is not a collection of transcripts. It is a set of imported findings tied to modules and release state.
That is much closer to a batch engineering workload than an interactive assistant.
The second pass matters as much as the first
Per-module auditing creates another problem: good agents often identify the same underlying issue in several places. A weak public type may appear in a storefront module, an experience API and a shared contract. A tenant-boundary assumption may be repeated across several workers. An old implementation pattern may exist in every module created during the same phase of the platform.
Fixing those findings independently is wasteful and can produce several slightly different solutions.
So the pipeline has a second pass. Once findings have been imported, an agent reviews the open set across modules and proposes clusters based on shared root causes. Operators can then address the pattern as one job while still tracking every individual instance. The cluster does not erase the findings beneath it. The implementation result must say which instances were fixed and which were skipped.
That gives us the efficiency of a cross-cutting fix without losing the audit trail at module level.
Agents return results; they do not rewrite release history
One of our firm rules is that agents do not hand-edit pipeline state. They write results in defined formats and finish with completion markers. The release server reads those outputs, validates them and performs the state transition.
This may sound like a minor implementation choice. It is actually one of the main governance boundaries in the system. If an agent can both perform the work and directly declare the release state, it can accidentally hide an incomplete result, overwrite another job or mark a finding as resolved without leaving usable evidence.
Our agents report what happened. The pipeline decides how that report changes the release record.
This is not autonomous shipping
We are not trying to remove people from the release process. Human judgment remains most important where the answer depends on product intent, architecture or risk. Someone still decides whether a finding is real, whether it should be fixed now, whether the proposed approach fits the platform and whether an accepted behaviour is actually acceptable.
The role of AI is to scale work that becomes expensive when performed manually across a modular codebase:
Building first-pass architectural context.
Inspecting many modules consistently.
Finding repeated patterns.
Preparing bounded remediation.
Returning results in a form the release process can consume.
The role of the pipeline is to keep that work ordered, inspectable and connected to the release. That is the shift we have found useful.
The important unit is no longer the prompt. It is the job contract: what the agent can see, what it is responsible for, what it must not touch, how it verifies the work and how the result comes back.
Once we made that shift, the IDE became one client of the process rather than the place where the process lived.