Agentic Coding in Practice – Diverge · Decide · Converge

In my private work, I experiment quite deliberately with different models and reasoning levels. Not out of academic curiosity, but because I feel the difference immediately. A large but largely mechanical refactoring can work extremely well with a strong high-reasoning model and at the same time consume a surprisingly large share of a limited weekly allowance.

That is why I now often choose lower reasoning levels deliberately for tasks like these. Not because I consider those models inherently better or because powerful models are not worth their price. Especially for requirements engineering, architecture questions, or difficult analysis, I currently would hardly want to give up a strong frontier model. But for routine work I now ask a different question: Do I really need the same amount of model intelligence for this?

In a company context, that feedback is often weaker. Token consumption, credits, and API costs are paid centrally, so individual developers only see them indirectly. That is understandable, but it can easily lead to a way of working in which model intelligence is barely routed consciously. You use the strongest model available because it is available. In private use, you notice much faster when a dull refactoring suddenly consumes a substantial part of your weekly allowance.

That has changed how I think about agentic coding.

The strongest model available is not automatically the most sensible model for every task.

So for me, the more interesting question is no longer: Which model is the best? It is:

How much model intelligence does this specific task still need at this particular point in its execution?

The answer depends surprisingly little on whether we label the activity requirements, architecture, coding, or testing. Something else matters more: How many relevant decisions are still open?

The open decision space

It would be tempting to divide agentic work into two rough classes: requirements and architecture go to a large model, coding and tests to a smaller one. That is simple, but technically too crude.

Coding can be highly exploratory. If you are looking for a hard-to-reproduce bug in an unfamiliar legacy system, reconstructing architectural boundaries, or trying to develop a viable refactoring strategy, you are working with code while still operating inside a large decision space. Conversely, requirements may already have converged substantially. If an existing domain contract merely needs an exactly specified field added, there may be very little left to decide.

The more useful axis for me is therefore the open decision space:

The further up we are, the more useful variance we need. We want to see alternatives, challenge assumptions, discover relationships, and sometimes have solutions proposed that we would not have thought of ourselves. The smaller the decision space becomes, the less desirable variance remains.

That changes not only the task. It also changes the role the model should play in that task.

Diverge: variance is desirable

A large part of my work today does not begin with a clear implementation instruction. Tickets are incomplete. Requirements are sometimes only implicit in existing behavior. A legacy system does not explain its architecture; it forces me to reconstruct it from code, dependencies, and historical decisions. With bugs, the cause is initially unknown. Larger changes often have several plausible variants with different trade-offs.

In situations like these, I want exploration. I give the problem to a strong planning or reasoning model and first ask it to investigate what the domain problem actually is, which implicit requirements are hidden in the existing behavior, which parts of the system are affected, which alternatives exist, and what consequences different architectural variants would have. It is particularly important to me that the model also attacks my own assumptions. Sometimes I deliberately say only: Surprise me.

Especially in requirements engineering, I currently work almost exclusively with a strong frontier model. That is not a statement about which model is objectively the best requirements model. It simply describes my current practice. For me, the main value is not just better language, but the ability to explore a solution space together that is deliberately not yet closed.

A POC belongs in this category for me as well. Its purpose is often precisely to answer an open technical question. The fact that code is produced does not automatically make the activity a converged implementation task. The same applies to legacy analysis, unknown root causes, or a refactoring question where I first want to understand several possible cuts.

In this phase, creativity really is a capability. It is desirable because we do not yet know which solution is the right one.

Decide: uncertainty must not silently flow into the code

Exploration alone does not produce good software. At some point, possible solutions have to become concrete decisions. This is where I see an important difference between an agent as a sparring partner and an agent as an autonomous decision-maker.

A model can develop options, explain trade-offs, criticize my preferred variant, and make alternative consequences visible. But responsibility for what is actually built remains with the responsible engineering team.

In practice, Decide therefore means much more than selecting a variant. Analysis results are assessed, reflected back through a strong model, sharpened, and finally translated into an explicit implementation brief. That may take several rounds.

The point is not to turn every minor detail into a formal Architecture Decision Record. What matters is that the relevant decisions become visible before mechanical implementation begins.

This continues the logic of the previous articles in this series. Requirements engineering reduces domain ambiguity. Architecture constrains the structural solution space. Information protection constrains an agent’s context and capabilities. Within those boundaries, Decide answers the next question: Which of the remaining open decisions do we actually want to make now?

The more of those decisions enter a coding task unresolved, the more the agent has to decide for itself. That can work well and even look impressively plausible. But then we have implicitly delegated part of our software design to code generation.

Moving code is not yet refactoring

A small example from my own work made this boundary very clear to me.

A coding agent had implemented business orchestration inside a UI component. To me, that was an immediately visible architecture smell. The component was coordinating things that, according to our architectural understanding, did not belong there.

So I explained to the agent that this business orchestration had to leave the UI. Its reaction was formally correct: it moved the logic into the facade.

Unfortunately, that did not solve the problem.

The responsibility was now located in another file, but the orchestration was still structurally cut in the wrong place. The agent had followed my visible instruction without resolving the underlying architectural decision again.

This is exactly where the difference between code production and software engineering becomes particularly visible.

Recognizing an architecture smell is often easy. Deriving a better structure from it is the actual engineering work.

At that point I deliberately go back into analysis and planning. Instead of issuing another prompt that merely requests the next move, I give the relevant context back to a strong reasoning model, have it examine responsibilities and dependencies, review the result myself, and then decide again.

This also makes clear that Diverge · Decide · Converge is not a linear pipeline. An implementation can create new information. A smell can reveal that a decision we thought had already been made was not actually resolved well enough.

Then the decision space has to be opened again.

Converge: maximum boredom

Once the essential decisions have actually been made, my expectations of a coding agent change fundamentally. At that point, I no longer want surprises.

The task defines the scope. Agent files explain the rules. Skills or project-specific instructions provide known procedures. Layering and slicing are defined. Patterns exist. Tests, linters, architecture rules, and other verification mechanisms constrain the result.

My ideal for the generated code can then be summarized quite simply:

Maximum boredom.

No new pattern nobody asked for. No extra abstraction because it might somehow look more elegant. No spontaneous reinterpretation of an architectural boundary and no creative generalization of a problem that is intentionally supposed to remain local.

For a sufficiently converged task, creativity is not necessarily a capability. It can be drift.

Typical candidates are mappers, DTO conversions, simple adapters, moves and renames, mechanical refactorings, clearly specified CRUD pieces, or unit tests that follow an already established pattern. But even that must not become another rigid rule.

A unit test can be almost mechanical: Implement the tests analogously to the existing tests for this use case. Another task can be: Analyze this unfamiliar algorithm, identify its relevant invariants, and derive a robust testing strategy from them. Both produce unit tests. The decision space is completely different.

The same applies to refactoring. Renaming and moving structures that have already been clearly identified is different from deciding which structure would make sense from a domain and architectural perspective.

For me, the task type is therefore at most a proxy.

The real question is not which file type or artifact we are creating, but how much exploration, judgment, and verification the remaining task actually requires.

Model routing follows the decision space

A smaller, faster, or cheaper model becomes interesting to me when the relevant decisions have already been made, the existing pattern is clear, the task remains manageable, and the result can be checked well.

A strong model becomes more important as soon as several domain-plausible solutions exist, causes are unknown, architecture is being changed, large parts of a system must be understood, or complex trade-offs have to be evaluated.

This explicitly does not mean that smaller models are deterministic. They can hallucinate, miss rules, misunderstand a simple task, or head in the wrong direction despite good instructions. A smaller decision space does not change the nature of the model. It changes the demands placed on its work.

A small decision space reduces the amount of exploration and judgment a task requires.

A cheap model therefore does not become economical because we let it handle difficult decisions badly. It becomes economical when we remove the difficult decisions from its task beforehand.

For me, that includes another rule: stop instead of guessing.

If an agent encounters a necessary architectural decision during implementation that has not yet been made, I do not want it to guess the most likely option. If a contract is unclear, I do not want an invented contract. And if two existing patterns compete and the task does not say which one should be continued, that is new information in itself.

The correct next step is then no longer Converge. The decision space has opened again. That applies regardless of whether a small or a large model is currently working.

My workflow is a loop

In practice, my work now looks different from only a few years ago.

I was a passionate developer for a long time. Even as a tech lead and later as a software architect, I always implemented things myself. Coding was never merely the necessary means of making architecture visible to me. It was part of what I enjoyed about software development.

Today I write surprisingly little code myself. Instead, I spend a lot of time understanding problems, clarifying requirements, analyzing solution spaces, making architectural decisions, formulating constraints, defining work orders, having agents implement them, and understanding and reviewing the results.

A real task for me now typically consists of several loops. First, I try to understand the ticket and the domain problem myself and turn that into an analysis brief. A strong model analyzes the system and the problem. I assess the result, feed it back, and refine it until robust work orders emerge. Only then does a coding agent implement them.

The process does not end after implementation either. I assess the result myself and feed every significant result back to a strong model. This is followed by domain and technical review, a correction brief if necessary, renewed implementation, and verification. Only after that loop has been completed cleanly do I commit.

One detail matters to me: I do not send results back to the strong model only after I have already found a problem. I do it at every significant result step.

I review the work myself and then use the model as an additional review channel. The reason is banal: even after many years of software development and architecture, I miss things. And strong models miss things too.

Human review does not replace model review. Model review does not replace human review.

I am not claiming that this is a scientifically optimal way of working. It is my current workflow. But it is a direct consequence of a problem that already appeared in the article Convincingly Wrong in this series: plausibility is not verification.

A diff can look reasonable and still be wrong in domain terms. A model review can sound convincing and still miss something. An experienced developer can understand a patch and still overlook an interaction. For me, quality therefore increasingly emerges from several independent control mechanisms: my own understanding, model review, tests, static rules, and, wherever possible, reproducible domain verification.

Good architecture shortens the prehistory of a change

At this point, a connection becomes visible that I notice more and more strongly in my daily work: a simple CRUD feature is not automatically a simple agent task.

Take a domain-trivial comment feature. In a greenfield system with a clear boundary, known layering, an established slice, existing CRUD patterns, and unambiguous contracts, the task can genuinely converge quickly. The agent does not first have to reconstruct where the feature belongs or which of several existing patterns happens to be the right one.

In a grown legacy system, the same domain feature often starts much earlier. First, we have to determine which existing part of the system is responsible at all. Then competing structures appear, dependencies have to be reconstructed, and at the same time the new feature should not continue even more legacy. In some cases, we first have to find a boundary at which the existing structures can be contained.

In my own practice, this part can take hours. Not because the later CRUD is complicated, but because a sufficiently robust decision space has to be created before implementation can even begin.

That is personal experience first. I have placed the adjacent research on repository structure and context retrieval, including its limits, in Article 08 – Architecture as a Constraint. For Diverge · Decide · Converge, the operative question is what matters: which structural decisions still have to be clarified before the task can move into implementation?

Good architecture does not make the agent smarter. It can reduce the work required before meaningful implementation can begin.

Ownership, boundaries, layering, contracts, tests, and architecture rules are therefore not only maintainability tools for humans. They provide orientation. And orientation reduces the part of the work in which an agent first has to reconstruct what we actually meant.

Time is at least as interesting here as tokens. A long analysis loop consumes agent runtime, context, model usage, reading, reviews, refinement, and human attention. The most expensive part of a poorly defined task may therefore not be code generation at all, but the work required before it is even clear which code should be created.

The full economic analysis deserves its own article. For this one, it is enough to note that an open decision space is not only a quality issue. It is also a cost factor.

Model routing becomes economically relevant

A quick look at current pricing structures already shows how large the differences can be.

As of September 2026, OpenAI lists, for example, GPT-5.6 Luna for ChatGPT Work and Codex at $0.20 per million input tokens and $1.20 per million output tokens, GPT-5.6 Sol at $4 and $20 respectively as a time-limited promotional price, and GPT-6 Astra at $10 and $50. Within the same product ecosystem, the differences between model classes are therefore large enough to become economically relevant under heavy agent usage. OpenAI: Enterprise Rate Card; see also the Sol model page with the promotion notice.

Anthropic shows the same principle. Its current API price list ranges, among other examples, from Claude Haiku 4.5 at $1/$5 per million input/output tokens, through Claude Sonnet 5 at $2/$10, to Claude Fable 5.1 at $10/$50. These figures are snapshots as of September 10, 2026, not a quality ranking and certainly not a durable recommendation for particular tasks. Anthropic: API pricing.

Reasoning is also more nuanced than a simple price multiplier. In the cited enterprise pricing structure, OpenAI charges the same price per token for different GPT-5.6 reasoning levels. That does not mean different reasoning levels generate the same total consumption. GitHub explicitly notes in its current Copilot documentation that higher reasoning levels can consume more tokens and therefore more credits. Unit price and actual consumption are two different things.

I feel exactly this mechanism directly in private use. For a single mechanical task, the difference may seem trivial. With heavy agent usage, it eventually determines whether an allowance is exhausted after two days or lasts the week.

And the industry is already beginning to respond.

GitHub Copilot now includes automatic model selection with Task Optimization. According to GitHub, the router considers factors including task complexity and current model availability and tries to reserve more expensive reasoning models for tasks that need the additional capacity, while routing simpler tasks to faster and cheaper models.

GitHub’s own recommendations now even explicitly move toward research, plan, then implement: planning with stronger reasoning, followed by focused execution with a model suited to implementation. GitHub also recommends cheaper models for tightly scoped subagents and notes that precise instructions and repository maps can reduce unnecessary exploration.

Model routing is therefore no longer a purely theoretical future idea. Even so, I would not confuse this automation with my actual Decide step.

A router can estimate from a prompt how complex a task appears. That does not mean it knows which architectural decision is allowed in my company, whether two existing patterns are historical baggage or deliberately different variants, or whether a deviation from the existing pattern is desirable. Nor does it reliably know which relevant decision has already been made if that decision is not visible as context or constraint.

Automatic model routing does not replace defining the decision space.

It optimizes within what we make visible to the system.

Local models expand the solution space

Model routing becomes even more interesting when locally runnable models become relevant alongside cloud models.

A current example is Qwen3.8-27B, which Alibaba released on August 14, 2026, as an open-weight model. The dense model has 27 billion language-model parameters, supports different reasoning settings, and is available under Apache 2.0.

The coding benchmarks published by the vendor are notable. On its model card, Qwen reports, for example, 61.7 percent on SWE-bench Pro and 73.0 on Terminal-Bench 2.1 under the stated evaluation conditions. These are vendor benchmarks and should be read exactly as such.

Independent measurements from Artificial Analysis are now available as well. There, too, Qwen3.8-27B ranks among the stronger models in its open-weight size class. At the same time, the evaluation shows a trade-off that is particularly interesting for model routing: the maximum-reasoning variant produces a large amount of reasoning output and is significantly slower and more verbose by comparison. More reasoning is therefore not a free abstraction even with a locally available model.

I do not yet have robust practical experience of my own with Qwen3.8-27B. I therefore follow the current hype with interest and a degree of skepticism. Models in this class at least show that locally runnable systems have reached a performance category in which their use for well-bounded software tasks can be discussed seriously. I would not infer more than that at this point.

In particular, local does not mean free. The official model card describes a dense model with around 28 billion parameters in BF16 and also points to available quantizations. That alone makes clear that we are not talking about trivial standard developer infrastructure. High-performance local inference requires memory and compute; operation also brings hardware acquisition, electricity, cooling, maintenance, updates, and utilization into the equation.

Local therefore shifts the cost structure rather than eliminating it.

Hardware, operations, and utilization, as well as the question of when each option pays off, are covered in Article 13 – The Economics of Agentic Work.

A specification does not automatically close the decision space

At this point, an obvious misunderstanding presents itself. If a small decision space makes implementation easier, one might derive a very old software idea in new clothing: write a large specification document, give it to the agent, and get the finished product out the other end.

That does not work.

A specification can be very large and still be full of open decisions. Between a domain description and a functioning system, architecture, ownership, data model, UX, error behavior, security, operational behavior, integration strategy, and testing strategy may all remain unresolved. Those decisions do not disappear because the requirements document is one hundred pages long. If nobody makes them explicitly, they will be made during implementation – by the agent.

A large specification is not automatically a small decision space.

For me, spec-driven development therefore does not mean pouring uncertainty into a larger document and then hoping for deterministic code generation. A good specification reduces decisions where those decisions have actually been made. Architecture constraints reduce further decisions. Contracts reduce further decisions. Tests and verification rules reduce further decisions.

Only then does the task converge.

This is exactly where the previous articles in this series meet. Requirements engineering constrains the domain solution space. Architecture constrains the structural solution space. Information protection constrains context and possible actions. And within this increasingly defined space, we consciously decide when we want to create variance and when we want to reduce it.

When code production gets cheaper

My own shift in role may be the part I have had to get used to most.

I enjoy writing code. I built a large part of my professional identity around being able to implement difficult technical problems myself. That is why I can understand why many developers react to the automation of code production differently than they would to a new refactoring tool in the IDE. If you have invested twenty years in becoming especially good at writing code, it is not a completely neutral experience when exactly that activity becomes increasingly automatable.

I still do not think a decline narrative about developers is useful. My personal observation is different:

Code production is increasingly shifting from humans to agents. As a result, the relative value of the actual software-engineering disciplines is increasing.

Problem understanding, requirements engineering, architecture, modeling, testing, security, verification, and technical decision-making are not new activities. For a long time, we were simply able to confuse them with the most visible activity in our field: writing code.

Perhaps we need to learn a little more software engineering again and be a little less proud of how quickly we can produce code. Because when code production gets cheaper, the relative value of the capabilities that decide which code should exist at all increases.

For me, agentic coding today therefore does not mean simply handing coding over to a model. It means consciously steering the decision space: allowing exploration where we need it, making decisions where responsibility is required, and reducing variance where the decision has already been made.

And if a new relevant uncertainty appears during implementation, we go back. The loop starts again.

Software engineering needs different amounts of variance at different points in time.

Diverge when you do not yet know what the right solution is. Decide before that uncertainty flows into the code. Converge once the decision has been made.

Coding is increasingly delegable. Software engineering remains the discipline that decides what should be created, which boundaries apply, and whether the result is actually good.

Sources and context

• GitHub Copilot – Auto Model Selection and Efficiency Guidance: As of September 2026, GitHub documents production routing based on task complexity, cost, and availability considerations and recommends different model capacities and reasoning levels for tasks with different degrees of openness and difficulty. This product logic shows that model routing is already being used in practice; it does not automatically know the domain and architectural decisions of a specific company.
• OpenAI and Anthropic – current model pricing: The official price lists show substantial differences between model classes. The price lists and model pages linked above were retrieved on September 10, 2026. GPT-5.6 Sol is listed as a promotion, according to OpenAI at least until November 21, 2026. The prices are not long-term stable relationships.
• Qwen3.8-27B: Release, architecture, license, and the cited coding benchmarks come from official Qwen materials; the coding scores should therefore be classified as vendor benchmarks. Artificial Analysis provides additional independent measurements and, besides high performance, highlights the high reasoning-token volumes of the maximum-reasoning configuration. This article is not based on the author’s own practical experience with the model.