Your model is choosing your workflow

Frontier models increasingly arrive with an implicit way of building software. If organizations do not own the agent development lifecycle outside the model, choosing the intelligence may also choose the workflow, the economics, and the limits of what can be changed.

Git did not give software teams a development workflow. It gave them an open-source content tracker with a distributed history. It did not prescribe issues, pull requests, approval chains, protected branches, CI pipelines, or the sequence a change should follow before reaching production.

GitHub and GitLab built those workflows around Git because teams needed a way to coordinate work that the underlying source-control primitive did not represent. That made sense. The platforms connected planning, implementation, review, testing, and release through a common operating model that millions of developers could understand.

I spent years watching the tradeoff that followed. Every project inherited some variation of the same workflow, whether it was a weekend experiment, an internal R&D project, or a highly regulated application. Teams could add required reviewers, security scans, deployment approvals, and compliance gates. They could also remove some of that ceremony. But configuration mostly changed the strictness of the workflow, not its underlying shape.

We are now at risk of repeating that history one layer deeper, except this time the common workflow may not be visible in a platform configuration. It may be learned by the model itself.

How does model choice become workflow choice?

An AI coding model brings learned assumptions about how software work should be planned, executed, evaluated, and completed.

A frontier model can receive a GitHub issue and produce a credible software change without being given an explicit development lifecycle. It explores the repository, creates a plan, edits files, runs tests, reconsiders failures, and decides when the work is complete. That looks like general intelligence applied to software development, but it may also reflect a deeply learned operating model.

The model has seen enormous amounts of software work represented through issues, tasks, commits, pull requests, test runs, and review conversations. Post-training and product evaluations then reward behavior that is reliable enough for broad commercial use. The result is not necessarily a deliberate attempt by a model vendor to impose a particular software-development lifecycle. It is a model with strong assumptions about how competent software work should proceed.

That distinction matters because a model with stronger priors is not simply more capable. It may also be more opinionated. When an external harness asks it to work differently, the harness is no longer directing a neutral reasoning engine. It is negotiating with a model that can privately reconstruct its own workflow from the task.

The new form of vendor lock-in begins there. An organization chooses a model because it performs well, then adapts its prompts, tools, evaluations, and operating practices to the way that model prefers to work. Eventually, changing the model means changing the workflow around it. The dependency is no longer limited to an API or the location of the data. It exists in the training, behavior, and runtime assumptions that shape how the model turns a request into a change.

This is more difficult to see than the platform workflows that came before it. A protected branch rule is inspectable. A CI pipeline can be read. A required approval can be traced to a configuration. A learned workflow is probabilistic and implicit. Teams discover it through behavior: how the model decomposes work, which tools it prefers, when it expands scope, what it considers sufficient evidence, and when it decides that the change is done.

That opacity becomes consequential because no single agent development lifecycle is appropriate for every kind of software.

A hobby project may need a fast path from intent to a tested patch with almost no ceremony. An R&D project may need to preserve hypotheses, experiments, discarded approaches, and what was learned even when no patch is accepted. A change to authentication in a regulated application may require authorized scope, independent review, signed attestations, provenance thresholds, and evidence that specific controls were satisfied. These are not simply light, medium, and heavy versions of one universal task sequence. They are different conditions under which a software change should be allowed to progress.

Because the learned workflow is implicit, the mismatch can run in either direction. The hobbyist may inherit enterprise-shaped behavior they never requested, spending tokens on planning, reconsideration, documentation, and procedural completeness that add little value to the project. A highly regulated application may inherit the lightweight workflow of a hobbyist or open-source project, moving quickly from issue to patch while omitting the audit trail, separation of duties, evidence requirements, and compliance gates the organization is obligated to preserve.

Even when the model imitates the language of review and compliance, the organization may still lack durable proof that its policy was followed or that a reviewer evaluated the exact state that reached production. Enterprise-shaped behavior is not the same as an enterprise-controlled lifecycle.

Why isn't more model reasoning enough?

More reasoning can improve a coding agent's answer, but it cannot give an organization durable control over the lifecycle that produced the answer.

The default response to an unreliable coding agent has been to use a stronger model or increase its reasoning effort. That can improve difficult work, but it also asks the model to reconstruct more of the development lifecycle inside private inference: understanding the problem, organizing the work, finding relevant context, evaluating the result, and deciding when it is finished. The organization pays for that reconstruction on every issue, attempt, and session, while whatever the model learned disappears unless another system records it.

Chad Fowler has been developing this distinction through his Phoenix Architecture. His argument that better shapes beat better prompts locates the real leverage in systems whose boundaries and constraints make generated code easier to trust. In Relocating Rigor, he makes the corresponding control argument: probabilistic generation only works when intent, invariants, and evaluation move into explicit structures outside the generator.

A prompt can describe that architecture, and a reasoning model can try to simulate it, but both approaches reconstruct the discipline inside another probabilistic run. A better harness makes the discipline durable. Intent, acceptance criteria, code intelligence, project policy, evidence requirements, provenance, and review can be represented once, improved over time, and applied across changes and models.

That makes Boris Cherny's description of how Anthropic rebuilds Claude Code around each frontier release especially revealing. His team removed roughly 80 percent of the system prompt for Opus 5 because the model had learned behaviors that previously required explicit instruction, and he recommends that customers periodically delete their CLAUDE.md, skills, and hooks to discover what a new model can do without them.

As product engineering, the ablation makes sense: obsolete instructions consume tokens, constrain new capabilities, and can conflict with a model whose behavior has changed. But when an instruction disappears because the model now performs it implicitly, the workflow has not disappeared. It has moved from an inspectable harness into weights the customer cannot inspect, version, or govern.

Fowler's design places durable rigor in the system around probabilistic generation; the frontier-model trajectory moves more operational behavior into the generator itself. The question is no longer only whether the model is more capable. It is who is in charge of the workflow that capability now performs.

What did the Atomic coding-agent benchmark show?

In a directional ten-issue benchmark, an explicit external lifecycle improved the same open-weight model's quality score by 52 percent and allowed it to outperform a more expensive raw frontier configuration.

We tested that distinction in a controlled Atomic benchmark across ten real issues from the Jest repository. Each run began from the same repository state, and the resulting changes were scored blind by an independent reviewer model that did not know which configuration produced them. The raw arms received the GitHub issue and worked directly against the repository. The Atomic arms used an explicit lifecycle connecting intent, code intelligence, criterion-tracked execution, and provenance-backed triage review.

The raw open-weight model reached 46.6 percent of the maximum quality score. Inside the full Atomic workflow, the same model reached 71 percent, a 52 percent improvement. It slightly exceeded the best raw frontier configuration at 67.2 percent while costing about $0.10 per task compared with $0.61 for the frontier configuration. Increasing frontier-model reasoning to its maximum setting did not produce the best result.

The benchmark was directional rather than definitive: ten issues, one run per arm, and noisy per-tier samples. It does not prove that frontier vendors intentionally train models to reject external workflows, nor that open-weight models are universally more steerable. What it does show is that model capability alone did not determine quality or cost.

On the hardest issues, the raw open-weight model failed to produce viable fixes, while the Atomic workflow raised its result to frontier quality. On medium issues, intent and code intelligence turned broken fixes into credible ones. On easy issues, triage review improved already viable changes into the highest-scoring results in the benchmark. The lifecycle contributed differently depending on the work, providing focus before execution, structural context during it, and targeted review afterward.

The full lifecycle also introduced a wall-time tradeoff because the system was creating and evaluating durable state instead of compressing the process into private inference. That tradeoff looks different when the economic unit is an accepted software change rather than the speed of a single response.

Reasoning tokens are purchased again with every attempt. A reusable lifecycle can improve the probability that those attempts become acceptable changes while preserving what the organization learned about producing them. In this benchmark, investing in that external structure allowed cheaper inference to outperform a more expensive model configuration without requiring the lifecycle to remain hidden inside the model.

Why should the lifecycle belong to the change?

The requirements and risks of an individual change—not the selected model or repository platform—should determine the lifecycle it must satisfy.

Open-weight models resemble open-source infrastructure in an important way. An open-source project may provide most of the general capability while leaving the organization to supply the domain model, integrations, policy, and operational structure that make it fit the business. That unfinished portion is not necessarily a defect. It is where organizational control and differentiation live.

We should be precise about what the benchmark supports: Atomic did not fine-tune the open-weight model or modify its weights. The advantage came from composability at the system level, with the model supplying general reasoning capability and Atomic supplying the development lifecycle around it.

Frontier models increasingly offer something closer to a finished application. They can reconstruct a capable workflow from a GitHub issue, which is convenient and often fast, but that apparent completeness may include the vendor's assumptions about planning, sequencing, tool use, repository state, and completion. The missing twenty percent has already been filled in, and it may not be filled in for your project.

Open-weight models give organizations room to define the operating model around the intelligence, but using that room well requires more than reproducing GitHub Flow in an external harness. The lifecycle should not be selected once for a platform, repository, or model. It should emerge from the requirements of the particular change.

This is why Atomic uses Petri-net micro-pipelines around software change. A predetermined task sequence assumes the lifecycle can be known in advance and applied uniformly. An event-driven model asks which conditions are true now, which evidence has become available, which dependencies are satisfied, which risks have appeared, and which transitions are therefore enabled. A failed verification can reopen the affected part of the work without forcing the entire change through one linear cycle again.

The project and the change determine the necessary rigor. A documentation correction may need a patch and lightweight verification. An authorization change may activate security evidence, independent review, provenance, and policy transitions. Both can exist in the same repository without inheriting the same path merely because they share a model or platform.

Atomic makes the lifecycle explicit through durable intent, acceptance criteria, tasks, patches, evidence, provenance, review, and verifiable state. The model participates in that lifecycle, but it does not own it. Models can change without discarding the operating model, and the operating model can change without waiting for a vendor to retrain the model.

Git gave us an open primitive with no prescribed workflow. Platforms filled that gap with a common lifecycle and eventually taught nearly every project to conform to its shape. We should learn from that history before the next workflow disappears inside the intelligence itself.

If the lifecycle remains inside the model, organizations will keep paying for higher reasoning to reconstruct it one session at a time. If it lives in the system, they can improve it once, apply it across models, and measure its contribution to every accepted change.

The model should provide capability, while the organization decides how that capability becomes software.