The current generation of coding agents has already moved the conversation past “can AI write code?” The more useful question now is what the next few model generations may change, and what those changes could mean for engineering work. I have argued before that AI is already reshaping the new engineering roles and forcing teams to stop measuring motion and start measuring value. This article looks one or two steps further ahead.
Not just completing functions or generating tests, but taking on broader tasks: understanding the repo, planning the change, using tools, validating the result, and recovering from mistakes.
But this is not only about the model.
A coding agent is not a model floating in space. It is a model inside a harness: repo access, tools, context retrieval, memory, permissions, orchestration, validation, work tracking, and feedback loops.
That is the assumption behind this article: future progress may not come only from smarter models, but from stronger models embedded in better harnesses. Together, they may change how engineering work is defined, delegated, executed, reviewed, measured, and trusted.
This Is an Assumption, Not a Prediction
I am not claiming that a specific future model named Claude Opus 5, Codex 6, GPT-5.5, or anything else will definitely unlock a specific capability on a specific date.
The model names are placeholders for the next few steps in the capability curve.
The assumption is simpler:
If frontier models continue improving in reasoning, coding, tool use, context handling, and long-running task execution, and if their harnesses improve around them, then the biggest impact may not be “more code faster.” It may be a redesign of how work is defined, delegated, executed, reviewed, measured, and trusted.
That assumption could be wrong in timing. It could be wrong in magnitude. It could be uneven across companies, codebases, and domains.
But it is still useful because it points to preparation work teams can do now, without waiting for the next model announcement.
It Is Not Just the Model. It Is the Harness Around It.
When people talk about future models, they often compress many improvements into the word “smarter”: better reasoning, stronger coding ability, more reliable tool use, longer-horizon execution, better error recovery, stricter instruction following, and larger usable context.
That matters, but it is only part of the story.
The practical impact will come from the combination of the model and the harness around it: the tools it can use, the context it can retrieve, the permissions it has, the workflows it participates in, and the validation loops that catch its mistakes.
A coding agent is not just a model. It is a system.
That system may include:
| Harness layer | What it changes |
|---|---|
| Repo access | Lets the agent inspect real code instead of isolated snippets |
| Tool use | Lets it run tests, search logs, call APIs, inspect configs, and validate assumptions |
| Context retrieval | Gives it relevant specs, tickets, ADRs, incidents, docs, and prior PRs |
| Memory | Preserves project decisions and repeated patterns across tasks |
| Permissions | Controls what the agent can edit, execute, deploy, or access |
| Orchestration | Splits work across implementation, test, security, docs, and review agents |
| Validation gates | Forces tests, linting, security scans, human approval, and rollout checks |
| Work tracking | Connects AI activity to Jira, GitHub, cost, reasoning, and business value |
| Feedback loops | Teaches the system which outputs were accepted, corrected, reverted, or caused incidents |
This is why the next phase should not be understood as “Claude Opus 5 writes better code” or “Codex 6 is smarter.”
The better framing is:
What happens when stronger models are embedded in better execution harnesses?
That combination is what may change the work.
A model with no repo access cannot safely own a real task.
A model with no test execution cannot prove its change works.
A model with no ticket context cannot understand value.
A model with no permission boundaries is risky.
A model with no feedback loop keeps repeating the same mistakes.
A model with no work tracking creates invisible automation.
The harness determines whether the model becomes a useful teammate, a risky intern, or a very expensive autocomplete system.
Smarter Does Not Just Mean Larger Context
It is tempting to treat “smarter model” and “larger context window” as the same thing.
They are not.
Larger context is one part of model progress, but it is not the whole story. A future model may improve across several dimensions at once:
| Improvement area | What it means for engineering work |
|---|---|
| Reasoning quality | Better planning, decomposition, tradeoff analysis, and contradiction spotting |
| Coding ability | Better implementation, refactoring, debugging, test generation, and pattern matching |
| Tool use | Better decisions about when to search, run tests, inspect logs, call APIs, or verify assumptions |
| Long-horizon execution | Better ability to stay on task across many steps without drifting |
| Error recovery | Better at noticing failure, diagnosing cause, and trying a better path |
| Instruction following | Better at respecting constraints, non-goals, style rules, and “do not touch” areas |
| Context handling | Better at using more information without being confused by noise |
| Calibration | Better at knowing uncertainty, asking for help, or stopping before risky actions |
The phrase “larger usable context” matters.
A bigger context window is not automatically better context. The model also needs to identify the relevant parts, ignore stale or noisy information, and apply the right evidence to the task.
This is where model capability and harness quality meet.
The model may be able to process more information. But the harness decides what information it sees, which sources are authoritative, what permissions it has, and which validation steps must happen before the result is trusted.
The future is not just larger prompts.
It is better reasoning inside better systems.
The Shift Has Already Started
The role change is not waiting for future models.
Current models already help engineers explain unfamiliar code, generate tests, debug issues, write implementation drafts, inspect logs, summarize pull requests, and compare solution options.
Current harnesses already let agents inspect repositories, edit files, run commands, open pull requests, connect to issue trackers, and participate in development workflows.
The next phase will not introduce AI-assisted engineering from zero. It will likely be shaped by several dimensions at once:
- Model capability: better reasoning, coding, planning, instruction following, and recovery from mistakes.
- Harness quality: better tools, permissions, context retrieval, memory, orchestration, validation, and feedback loops.
- Scale: larger chunks of work can be delegated.
- Autonomy: agents can run longer with less steering.
- Context: agents can reason across more of the repo, history, specs, and operational evidence.
- Quality: output can become less locally correct and more system-aware.
- Speed: teams may reduce rework and improve time-to-trusted-output, even if individual agent runs become heavier.
- Accountability: humans become responsible for better framing, constraints, validation, and value judgment.
That distinction matters.
If we say “AI will change engineering roles,” we are already late. It has.
The better question is:
What happens if model-and-harness systems can safely own larger units of work?
That is where the next phase begins.
The Model Number Is Less Important Than the Capability Pattern
“Claude Opus 5” and “Codex 6” are useful shorthand, not magic product names.
The important trend is not one version number. It is the steady movement from assistant to agent to delegated work system.
| Stage | System behavior | Human bottleneck |
|---|---|---|
| AI autocomplete | Suggests code fragments | Syntax and implementation speed |
| AI pair programmer | Helps with functions, tests, debugging | Prompting and review |
| Coding agent | Works across files and tools | Task framing and validation |
| Project agent | Owns larger tickets or feature slices | Specs, architecture, context, and risk control |
| Multi-agent system | Implementation, testing, security, docs, and ops agents collaborate | Governance and value judgment |
| Organization-scale AI work system | Many business functions become partially executable by agents | Strategy, prioritization, trust, and accountability |
The current frontier is somewhere between coding agent and early project agent.
That does not mean models are ready to safely run entire engineering organizations. They are not.
It means the direction is visible enough that engineering leaders should stop treating AI as only an individual productivity tool.
The interesting question is no longer:
Can AI write useful code?
It can.
The more important question is:
Can the organization define work clearly enough, and build the harness carefully enough, for AI to execute safely?
That question gets more important with every stronger model.
Version +1: From “Help Me Code” to “Own This Task”
The next major generation of model-and-harness systems may make the biggest visible difference in task ownership.
Today, many AI coding workflows still look like this:
Help me implement this function.
Explain this error.
Write a test for this class.
Refactor this file.
Review this PR.
That is already useful. But it keeps the human close to the loop.
The next step looks more like this:
Take this Jira ticket, inspect the repo, retrieve relevant context, identify risks, propose a plan, implement the change, update tests, run validation, and explain the tradeoffs.
That is a major shift.
Not because the model writes code. Current models already write code.
The shift is that the system owns a larger work unit.
At that point, a Jira ticket stops being a tracking artifact. It becomes an executable contract. This is the same shift I explored in Agile SDLC with Vibe Engineering: when execution gets cheap, the spec becomes the load-bearing part of the process.
That is where many companies may feel pain.
A lot of tickets were never written to define work clearly. They were written to remind humans of conversations they already had.
“Fix onboarding bug” might really mean:
Preserve enterprise SSO behavior, do not touch the legacy migration path, avoid changing billing flags, and check with Priya before modifying tenant provisioning.
A human teammate may know that from context. An AI agent probably does not, unless the harness retrieves and supplies that context.
With stronger model-and-harness systems, bad tickets become more dangerous because the AI becomes capable enough to act on them.
Weak intent becomes executable.
That is not productivity. That is risk with better formatting.
Version +2: From Task Owner to Project Collaborator
After task ownership comes longer-horizon collaboration.
This is where newer systems may become better at maintaining context across branches, specs, previous design decisions, tests, documentation, and deployment requirements.
The agent does not just make a patch. It participates in the project.
That changes the center of gravity from code to specs, context, and validation.
In traditional engineering, specs are often alignment documents. In AI-assisted engineering, specs become runtime inputs.
A good AI-era spec needs to explain:
| Spec element | Why it matters |
|---|---|
| Value hypothesis | Prevents the agent from optimizing meaningless work |
| Scope | Prevents unnecessary expansion |
| Non-goals | Tells the agent what not to solve |
| System constraints | Reduces architectural damage |
| Risk areas | Focuses human review |
| Required context | Tells the harness what evidence to retrieve |
| Validation plan | Defines what “done” actually means |
| Rollback or migration plan | Makes execution safer |
| Cost and effort expectations | Helps measure whether the work was worth doing |
This is the hidden preparation many teams are not doing.
They are buying better models, but leaving the work definition layer vague and the execution harness under-designed.
That may work for small tasks. It breaks down when agents can operate across larger parts of the system.
The better the model, the more important the input contract becomes.
The better the harness, the more important it becomes to decide what context, tools, and permissions the agent should actually have.
Larger Context May Change Quality, Not Just Speed
One of the most important assumptions about newer systems is not just that models will be smarter. It is that agents may work with larger and more useful context.
That context may come from a larger model window, but also from the harness around the model: retrieval, indexing, memory, issue tracker integration, source graph analysis, documentation search, logs, incidents, and previous pull requests.
That matters because many failures in today’s AI coding workflows are not pure reasoning failures. They are context failures.
The model sees the file, but not the architecture. It sees the ticket, but not the previous incident. It sees the implementation, but not the migration constraint. It sees the test, but not the customer behavior that actually matters.
With larger and better-managed context, future agents may produce better output because they can reason with more of the evidence humans usually carry in their heads.
A better harness could allow an agent to inspect the ticket, related Jira history, previous pull requests, architecture decision records, service ownership, logs and incidents, dashboards, test failures, deployment history, customer reports, and coding standards.
That may change the quality bar.
Today, an AI-generated change may be locally correct but globally naive.
With better context, the output may become more system-aware. The agent may be better at understanding why the existing code looks strange, why a migration path still exists, why a feature flag cannot be removed yet, or why a test that looks redundant is actually protecting an enterprise customer flow.
The quality shift is not only about generating “better code.” It is about generating work that fits the system.
| Quality dimension | What current systems often do well | What larger-context systems may improve |
|---|---|---|
| Syntax and API usage | Generate reasonable code quickly | Use project-specific conventions more consistently |
| Local implementation | Solve bounded problems | Avoid changes that conflict with adjacent systems |
| Tests | Create basic coverage | Generate tests aligned to real behavior and prior incidents |
| Architecture | Follow visible nearby patterns | Respect broader service boundaries and ADRs |
| Migration safety | Often needs human guidance | Better understand rollout and compatibility constraints |
| Product intent | Can follow explicit requirements | Better connect implementation to value and non-goals |
| Operational readiness | May miss logs, metrics, alerts | Include observability and rollback expectations |
| Maintainability | Can be plausible but overbuilt | Better preserve existing simplicity if context is clear |
The speed story is also more nuanced than “larger context means faster work.”
Individual agent runs may become slower and more expensive because there is more context to process, more tools to use, and more validation to perform.
But the total workflow may become faster if larger context and better harnesses reduce rework.
Less time correcting misunderstood requirements. Less time discovering missing constraints late. Less time asking why the agent changed the wrong file. Less time rewriting generated tests. Less time reverting plausible but wrong implementations.
The best outcome is not just faster first drafts.
It is fewer bad first drafts.
That is why the better metric is not time-to-code or time-to-PR.
It is time-to-trusted-output.
How long does it take to get from intent to a result that humans trust enough to ship, use, or act on? Trust is the part where most AI rollouts quietly stall — see How Teams Learn to Trust AI and From Execution Speed to Adoption Limits for why faster generation rarely translates into faster delivery on its own.
Current models often improve time-to-first-draft. Newer model-and-harness systems may improve time-to-trusted-output by reducing rework and increasing first-pass alignment.
That applies beyond engineering too.
For a legal memo, trusted output means reviewed and safe. For a support response, trusted output means accurate and customer-ready. For a financial analysis, trusted output means traceable and defensible. For a product spec, trusted output means aligned and actionable.
The future productivity story is not just speed.
It is speed plus trust.
But larger context does not automatically mean better output.
Dumping the whole company into the prompt is not strategy. It is a new kind of mess.
The model may have more information, but not necessarily the right information. It may over-attend to irrelevant details, follow outdated docs, misread stale decisions, or treat noisy context as authoritative.
So the next discipline is not just “give the model more context.”
It is context engineering.
Teams will need to decide:
- what context should be included,
- what context should be excluded,
- what sources are authoritative,
- what information is outdated,
- what constraints override others,
- and what the agent must verify before acting.
A larger context window is only useful if the context is curated and the harness knows how to retrieve the right evidence.
Otherwise, the model gets a bigger haystack and still has to find the needle.
Worse, it may confidently use the wrong needle.
Version +3: From One Agent to Many Agents
The following step may not be just a smarter model. It may be multiple specialized agents working together inside a shared harness.
One agent implements.
One writes tests.
One reviews architecture.
One checks security.
One validates observability.
One updates documentation.
One reviews cost and migration risk.
One summarizes the change for humans.
This is where engineering starts to look less like “developer plus AI assistant” and more like “human orchestrating a constrained delivery system.”
That does not remove engineers.
It changes what engineering leverage means.
The best engineers become better at decomposing work, setting boundaries, creating validation loops, and catching plausible but wrong outputs.
The weakest teams automate confusion.
A team with unclear ownership, poor architecture boundaries, weak tests, messy tickets, no context discipline, and no shared definition of value will not become high-performing because Codex 6 exists.
It will become a faster producer of plausible changes.
And plausible is the dangerous word.
What Further Changes for Engineering Roles
The impact on engineering roles is already here — I wrote about the current state in The New Engineering Roles with AI. The next systems may change the scale.
Current models changed how individuals work.
Newer model-and-harness systems may change where responsibility sits.
Junior Engineers: From Implementation Practice to Judgment Practice
Junior engineers already use AI to explain code, generate tests, scaffold implementations, and answer questions that previously required waiting for a senior engineer.
That can be great.
It can also be risky.
A junior engineer can now produce working code without fully understanding why it works.
With newer systems, this may get more intense. If agents can take full tickets, inspect repositories, retrieve context, make changes, update tests, and explain the result, then the traditional junior learning path gets weaker.
Many engineers learned by doing small implementation tasks directly. Those tasks may increasingly be handled by agents.
| Old learning path | Newer learning path |
|---|---|
| Implement small tasks manually | Review and challenge AI-generated implementations |
| Ask seniors for explanations | Interrogate models, then verify independently |
| Learn by fixing simple bugs | Learn by debugging agent mistakes |
| Write basic tests | Judge whether generated tests prove the right behavior |
| Follow existing patterns | Compare multiple possible patterns and explain tradeoffs |
The junior role does not disappear.
But it becomes less about typing the first version of the code and more about developing engineering taste through review, investigation, and guided ownership.
The danger is a generation of engineers who can operate agents but cannot reason independently.
The opportunity is a generation of engineers who learn faster because they can compare many approaches, ask unlimited questions, and see implementation patterns on demand.
The difference will come down to management, mentorship, and review culture.
Mid-Level Engineers: From Task Delivery to Work Decomposition
Mid-level engineers may see the biggest day-to-day change.
Today, a strong mid-level engineer can take a well-scoped task and deliver it with moderate independence.
With better systems, that same engineer may increasingly become the person who decomposes work for agents.
Their value shifts from:
I can complete this ticket.
to:
I can split this problem into safe, reviewable, AI-executable chunks.
| Responsibility | Why it grows in importance |
|---|---|
| Work decomposition | Agents need bounded tasks |
| Context packaging | The harness needs the right constraints and evidence upfront |
| Risk identification | Not all files and systems are equally safe |
| Validation design | Passing tests is not always enough |
| Review sequencing | Humans should review the riskiest decisions, not every keystroke |
| Cost awareness | More automation can also mean more token, tool, and infrastructure spend |
A mid-level engineer who can reliably orchestrate AI work may deliver at the level of a much larger team.
But a mid-level engineer who delegates vague work to agents without understanding the system may create hidden maintenance debt very quickly.
The next generation of systems will reward engineers who think in systems, boundaries, context, and verification loops.
Senior Engineers: From Expert Implementers to System Stewards
Senior engineers are already moving away from pure implementation leverage. Newer systems push this further.
As agents become better at producing locally correct changes, senior engineers become more valuable for things models still struggle with:
- architectural direction,
- long-term maintainability,
- cross-system tradeoffs,
- migration strategy,
- operational risk,
- security posture,
- context quality,
- and knowing when not to build.
A future agent may generate five plausible implementations. The senior engineer decides which one preserves the system.
A future agent may pass every test. The senior engineer asks whether the tests prove the right thing.
A future agent may propose a clean abstraction. The senior engineer recognizes that the abstraction will confuse the team for the next two years.
So the senior role shifts from being the best person at producing code to being the person who protects the system from fast, plausible mistakes.
That is a different kind of seniority.
It is less about being the hero who solves the hardest ticket personally and more about creating the conditions where humans and agents can safely contribute.
Staff and Principal Engineers: From Architecture Authors to AI Operating-System Designers
Staff and principal engineers will face an even larger shift.
In classic organizations, they design architecture, guide technical strategy, review major decisions, and influence across teams.
With stronger AI agents, they also need to design the operating environment in which AI work happens.
| Operating-system layer | Examples |
|---|---|
| Architecture boundaries | Service ownership, module boundaries, dependency rules |
| Agent permissions | What agents may edit, inspect, run, or deploy |
| Review triggers | Sensitive files, security changes, migration scripts |
| Standards | Coding patterns, API conventions, observability expectations |
| Context systems | ADRs, diagrams, specs, ownership maps, runbooks |
| Validation gates | Test requirements, security checks, performance checks |
| Escalation rules | When agents must stop and ask a human |
| Feedback loops | How accepted, rejected, reverted, or incident-causing outputs improve the system |
In other words, they become designers of the engineering system, not just the software system.
A principal engineer may spend less time writing the cleverest implementation and more time making the codebase, documentation, and delivery workflow legible to both humans and machines.
That may become a new sign of high-quality technical leadership:
Can controlled automation safely work inside this system?
The best architecture will not only be elegant. It will be agent-operable.
Engineering Managers: From Delivery Tracking to AI Work Governance
Engineering managers already need to understand how AI affects delivery.
Newer systems make casual measurement dangerous.
When agents can produce more work with less effort, activity metrics become even noisier. PR count, story points, commit volume, and cycle time may all improve while value, quality, or maintainability gets worse. That is the trap Stop Measuring Motion was written about, and stronger agents make it worse, not better.
The manager’s role shifts further toward governing the work system.
| Management question | Why it matters |
|---|---|
| Is AI work connected to clear customer or business value? | Prevents automation theater |
| Are agents being used on the right tasks? | Not all work should be delegated |
| Is the harness giving agents the right context and permissions? | Prevents unsafe or misaligned execution |
| Are engineers reviewing deeply or rubber-stamping? | Prevents shallow acceptance |
| Are we tracking AI cost against value delivered? | Makes automation economically visible |
| Are we creating more complexity than we remove? | Protects long-term maintainability |
| Are junior engineers still learning fundamentals? | Avoids skill hollowing |
| Are incidents linked back to AI-assisted changes? | Creates feedback loops |
| Are specs improving over time? | Improves future agent performance |
This is where AI-era engineering management becomes less about “Are people busy?” and more about:
Is the human-agent system producing valuable, safe, maintainable outcomes?
The manager becomes accountable for the workflow, not just the team.
This is also where tracking AI work becomes important. If a Claude skill, Codex workflow, or internal agent can connect every AI-assisted change to a Jira ticket, capture the value hypothesis, record reasoning, check prerequisites, estimate token cost, and note which harness steps were used, that is not bureaucracy.
That is accounting for autonomous work.
If AI work is not connected to intent, context, cost, and outcome, it becomes untraceable automation.
Product Managers: From Prioritization to Value Precision
Product managers are already affected because AI reduces implementation friction.
Newer systems amplify that.
When engineering can build more ideas faster, weak prioritization becomes more expensive. Teams can create more product surface area, more experiments, more configuration, and more edge cases than customers actually need.
So PM work shifts from:
Write requirements for engineering.
to:
Define value precisely enough that cheap execution does not create expensive complexity.
PMs will need sharper definitions of customer evidence, value hypothesis, success metrics, non-goals, scope boundaries, kill criteria, and tradeoffs between speed, simplicity, and long-term product coherence.
The PM’s job becomes harder in one specific way:
They can no longer rely on engineering scarcity to filter weak ideas.
When building is cheaper, saying no becomes more important.
QA and Test Engineers: From Manual Validation to Agent Validation Design
Better coding agents will produce more code, more tests, and more fixes.
That does not automatically mean better quality.
QA and test engineers may shift from manually validating every behavior toward designing validation systems that agents can run and humans can trust.
| Future QA focus | Why it matters |
|---|---|
| Scenario libraries | Gives agents realistic validation targets |
| Regression strategy | Prevents repeated AI-induced breakage |
| Test quality review | Avoids meaningless generated tests |
| Edge-case modeling | Catches cases agents miss |
| Release gates | Keeps AI-generated work from bypassing discipline |
| Production feedback loops | Connects defects back to generation, harness design, and review patterns |
A future model may write tests.
A strong QA engineer ensures those tests actually protect the customer.
DevOps, SRE, and Platform Engineers: From Infrastructure Support to Automation Safety
For platform and SRE teams, newer systems increase both leverage and risk.
Agents will be able to modify deployment configs, troubleshoot incidents, analyze logs, propose infrastructure changes, and possibly execute remediation workflows.
That sounds powerful.
It is also terrifying if unconstrained.
These roles shift toward:
- defining safe automation permissions,
- creating rollback-first workflows,
- limiting agent access in production,
- building observability that agents can reason over,
- designing runbooks for human-agent collaboration,
- and deciding which operational actions require human approval.
The future SRE question becomes:
What can the agent safely do at 3 a.m. without making the incident worse?
That is not just a tooling question.
It is an engineering governance question.
Security Engineers: From Reviewers to Policy and Constraint Designers
Security teams will not be able to manually review every AI-generated change if code volume increases dramatically.
Their work shifts toward encoding security expectations into the development system itself:
- secure coding rules,
- automated threat modeling,
- dependency policies,
- secrets detection,
- permission boundaries,
- sensitive-code review triggers,
- and agent restrictions around risky files or systems.
Security becomes less of a late-stage review function and more of a set of constraints that agents must operate within.
A stronger model may be better at finding vulnerabilities.
It may also be better at generating risky integrations faster.
Security teams become designers of the guardrails, not just reviewers of the output.
The New Bottleneck: Value Definition
The biggest mistake companies can make is assuming that better models and better harnesses mostly improve engineering throughput.
They do, but that is not the whole story.
If execution gets cheaper, value definition becomes more important.
In a world where implementation is expensive, weak ideas often die naturally. They are too costly to build.
In a world where implementation is cheap, weak ideas survive longer. They become features, settings, workflows, internal tools, dashboards, automations, and technical debt.
AI lowers the cost of creation.
It does not lower the cost of complexity.
This is why value-driven development becomes more important in the AI era, not less.
| Question | Why it matters |
|---|---|
| What customer or business outcome does this work support? | Prevents motion without value |
| What evidence suggests this work matters? | Avoids opinion-driven automation |
| What is the smallest useful version? | Limits complexity |
| What should not be built? | Protects product coherence |
| How will we measure impact? | Connects delivery to outcomes |
| What will we stop doing if this does not work? | Creates kill criteria |
| What did AI cost to produce this work? | Makes automation economically visible |
| Which harness steps were used? | Shows whether the result was validated or merely generated |
Without that discipline, newer systems will help organizations build more things they do not need.
Very efficiently.
The New Engineering Artifact: The AI-Executable Ticket
In the next phase, the humble ticket becomes much more important.
Not because Jira is exciting. Let’s not get carried away.
The ticket becomes important because it may become the primary handoff between human intent and machine execution.
A good AI-executable ticket should include:
## Goal
What outcome are we trying to create?
## User or business value
Why does this matter?
## Scope
What should be changed?
## Non-goals
What should not be changed?
## Relevant context
Links to specs, designs, incidents, logs, dashboards, ADRs, prior PRs, or customer reports.
## Constraints
Architecture, security, compliance, performance, compatibility, migration, or ownership constraints.
## Suggested approach
Optional. Include only if useful.
## Validation
What tests, checks, metrics, or manual verification prove this is done?
## Risks
What could go wrong?
## Human approval required
What decisions must not be made by the agent alone?
## AI work tracking
Model used, agent workflow, harness steps, token cost estimate, reasoning summary, and generated artifacts.This kind of structure may feel heavy for small tasks. It does not need to be.
But for larger AI-delegated work, it becomes essential.
The future of engineering process may be less about sprint ceremony and more about work definition quality.
The Architecture Impact: Codebases Must Become Legible to Agents
Better model-and-harness systems will likely make codebases bigger faster.
That is not automatically good.
If implementation gets cheaper, teams will be tempted to add more features, abstractions, generated tests, configuration, dashboards, internal tools, migration scripts, and integration glue.
Some of that will be useful.
Some of it will be future pain.
The architecture challenge becomes less about producing code and more about resisting unnecessary code.
AI agents need architectural guardrails:
| Guardrail | Purpose |
|---|---|
| Clear module boundaries | Reduces accidental cross-system changes |
| Ownership maps | Tells agents who owns what |
| Dependency rules | Prevents architectural erosion |
| ADRs | Preserves decision context |
| Test strategy | Clarifies validation expectations |
| Observability standards | Makes production behavior understandable |
| Security constraints | Prevents unsafe shortcuts |
| Migration patterns | Keeps change reversible |
| “Do not touch” zones | Protects sensitive systems |
The best teams will not only adopt better models.
They will make their systems easier for agents to safely operate inside.
That means code structure, documentation, tests, specs, runbooks, and operational data all become part of the AI interface.
What Enterprises Can Improve Now
Model versions will change. Tools will change. Agent frameworks will change. Some vendor promises will age badly before the next procurement cycle finishes.
But several company capabilities will stay valuable across model generations.
These are the things enterprises can improve now, before the next major model release, because they compound no matter which model wins.
Better Work Definition
The most important constant is the quality of work definition.
If a company cannot clearly describe what needs to be done, why it matters, what constraints apply, and how success will be validated, then better models will not fix the problem. They will execute the ambiguity faster.
Enterprises can improve this now by making tickets and specs more explicit:
| Work definition element | Why it matters |
|---|---|
| Goal | Gives the agent a target |
| Value hypothesis | Connects work to customer or business impact |
| Scope | Prevents uncontrolled expansion |
| Non-goals | Tells the agent what not to solve |
| Constraints | Protects architecture, security, compliance, and compatibility |
| Validation | Defines what “done” means |
| Risk areas | Focuses human review |
| Required context | Helps the harness retrieve the right evidence |
This is model-independent.
Every future model benefits from clearer intent.
Trusted Context
Enterprises already have huge amounts of context: Jira tickets, Confluence pages, Slack threads, incident reports, pull requests, architecture diagrams, dashboards, runbooks, customer escalations, support tickets, and tribal knowledge.
The problem is not that context does not exist.
The problem is that it is scattered, stale, contradictory, and hard to trust.
Companies can start improving context quality now:
| Context improvement | Why it helps |
|---|---|
| Mark authoritative docs | Agents need to know what source wins |
| Archive stale docs | Prevents outdated guidance from becoming executable |
| Link tickets to specs and incidents | Improves task understanding |
| Maintain ADRs | Preserves architectural reasoning |
| Keep ownership maps current | Helps agents route questions and avoid unsafe changes |
| Improve runbooks | Makes operational work more automatable |
| Connect customer evidence to work | Keeps AI output tied to real value |
Larger context windows will not help much if the enterprise context is garbage.
The constant is not more context.
The constant is trusted context.
Stronger Validation Loops
Every model generation will still need validation.
That validation may become more automated, but it will not disappear.
Enterprises can invest now in meaningful automated tests, integration and contract tests, security scans, linting and static analysis, performance checks, deployment gates, observability, rollback paths, release health dashboards, and incident feedback loops.
This matters because the more work agents produce, the more important automated validation becomes.
Without validation, AI adoption scales risk.
With validation, AI adoption scales learning.
The constant is:
Faster execution only helps if the organization can verify outcomes.
Clear Permission Boundaries
Enterprises should decide now what agents are allowed to do.
Not every action should require the same level of approval.
A useful permission model might look like:
| Agent action | Default posture |
|---|---|
| Read documentation | Allowed |
| Read code | Allowed with access controls |
| Propose code changes | Allowed |
| Run local tests | Allowed |
| Open draft PRs | Allowed |
| Modify sensitive services | Human approval required |
| Change infrastructure | Human approval required |
| Access production data | Restricted |
| Deploy to production | Strongly gated |
| Modify security policy | Strongly gated |
This is not just about safety. It is about speed.
When permissions are unclear, teams either block everything or allow too much.
Both slow adoption.
The constant is bounded autonomy: agents move faster when everyone knows where the guardrails are.
AI Work Tracking
Enterprises should start tracking AI-assisted work now.
Not in a surveillance way. In an operating-system way.
Useful tracking includes:
| Tracking item | Why it matters |
|---|---|
| Which work was AI-assisted | Makes adoption visible |
| Which model or agent was used | Helps compare approaches |
| What context was provided | Helps debug bad outputs |
| What validation was run | Separates generated from trusted |
| Token and tool cost | Makes economics visible |
| Human review effort | Shows whether AI reduced or shifted work |
| Outcome quality | Connects usage to value |
| Reverts, defects, incidents | Creates feedback loops |
This prepares the company for future models because it creates a baseline.
Without a baseline, every model release becomes vibes:
It feels faster.
Maybe. But where? For whom? At what cost? With what quality? “Vibes” is not a budget line.
The constant is measurement that connects AI usage to actual outcomes.
Review Culture
As models improve, review becomes more important, not less.
But the review target changes.
Humans should not review AI work only by scanning the diff. They should review the problem framing, assumptions, selected approach, ignored alternatives, validation evidence, risks, long-term maintainability, and whether the work should exist at all.
This requires a stronger review culture.
A team that rubber-stamps AI-generated PRs will accumulate risk quickly. “LGTM” is not a code review when the code wrote itself.
A team that reviews AI work as a reasoning artifact will improve faster.
The constant is judgment quality.
Architecture Legibility
Enterprises can make their systems easier for both humans and agents to understand.
That means clearer module boundaries, better service ownership, fewer hidden dependencies, stronger API contracts, up-to-date diagrams, ADRs for major decisions, consistent patterns, documented migration paths, and clear deprecation rules.
This is valuable even without AI.
With AI, it becomes more valuable.
Agents perform better in legible systems. They perform worse in systems where everything depends on tribal knowledge, implicit rules, and “don’t touch that file unless you know why.”
The constant is:
Systems that are easier to understand are easier to automate safely.
Human Skill Development
Enterprises should not assume better models remove the need to train engineers.
They change what training should emphasize.
Teams can start training engineers now on:
| Skill | Why it matters |
|---|---|
| Spec writing | Turns intent into executable work |
| Agent task decomposition | Makes delegation safer |
| AI output review | Prevents shallow acceptance |
| Debugging generated code | Builds real understanding |
| Context curation | Improves model performance |
| Validation design | Defines trust |
| Cost awareness | Prevents waste |
| Architectural judgment | Protects long-term system health |
The constant is human judgment.
Better models increase the leverage of good judgment. They also increase the blast radius of poor judgment.
Value Discipline
This may be the most important enterprise constant.
If implementation gets cheaper, prioritization gets more important.
Companies should improve how work connects to value:
- What customer problem does this solve?
- What business outcome does it support?
- What evidence says it matters?
- What is the smallest useful version?
- What complexity does it add?
- What metric will prove it helped?
- When would we stop or roll it back?
Better models can produce more output. That does not mean the company should accept more output.
The constant is value discipline.
AI makes motion cheaper. It does not make value automatic.
Human-Agent Operating Model
Enterprises should define how humans and agents work together.
This includes:
| Operating question | Why it matters |
|---|---|
| Which tasks are agent-suitable? | Avoids using AI everywhere blindly |
| Which tasks require human ownership? | Protects high-risk decisions |
| What must be in a ticket before delegation? | Improves output quality |
| What validation is mandatory? | Creates trust |
| What requires approval? | Controls risk |
| How are outputs reviewed? | Prevents rubber-stamping |
| How are failures learned from? | Improves the system over time |
The constant is not a specific tool.
The constant is a repeatable work system.
The Enterprise Constant: Better Inputs, Better Boundaries, Better Feedback
New models change capability. Enterprises control readiness.
The things enterprises can improve now are surprisingly stable:
- Better work definition.
- Trusted context.
- Strong validation.
- Clear permissions.
- AI work tracking.
- Review culture.
- Architecture legibility.
- Human skill development.
- Value discipline.
- A repeatable human-agent operating model.
These do not become obsolete when the next model arrives.
They become more valuable.
A company with vague tickets, stale docs, weak tests, unclear ownership, and no value tracking will not suddenly become AI-native because it gets access to a better model.
A company with clear specs, trusted context, strong validation, and disciplined review will be able to adopt each new model generation faster.
That is the compounding advantage.
Not:
We picked the right model.
But:
We built a company that can absorb better models quickly and turn them into trusted value.
What Changes Outside Engineering
The same pattern may hit every knowledge-work function.
Legal teams may use agents to draft and review contracts. Finance teams may use agents to investigate spend. Sales teams may use agents to generate account strategies. Support teams may use agents to diagnose customer issues. HR teams may use agents to analyze feedback and draft policy. Operations teams may use agents to monitor workflows and trigger actions.
The common theme is not “AI writes text.”
We passed that stage.
The common theme is:
AI turns loosely structured intent into operational output.
That means every function may need the same operating discipline engineering is now discovering:
- better inputs,
- clearer constraints,
- stronger review,
- traceability,
- cost visibility,
- value measurement,
- permission boundaries,
- validation loops,
- and escalation rules.
The companies that benefit most may not be the ones with the most AI tools.
They may be the ones that redesign work around human intent and machine execution.
What Will Not Change
Even with Claude Opus 5, Codex 6, GPT-5.5, or whatever comes next, some things remain stubbornly human.
Someone still needs to decide what matters.
Someone needs to understand customers.
Someone needs to choose tradeoffs between speed, quality, trust, cost, and risk.
Someone needs to say no.
Someone needs to notice when the organization is optimizing for activity instead of outcomes.
Someone needs to protect the system from plausible nonsense.
The fantasy version of AI says better models remove ambiguity.
The real version says they may make unmanaged ambiguity more expensive.
A vague strategy plus powerful agents equals high-speed confusion.
How to Prepare for the Next Model
The best way to prepare for the next model is not to wait for it.
It is to fix the parts of the work system that better model-and-harness systems would amplify.
| Area | Preparation question |
|---|---|
| Tickets | Are they clear enough for an agent to execute without tribal knowledge? |
| Specs | Do they describe value, constraints, and validation? |
| Context | Do agents receive the right evidence, not just more evidence? |
| Harness | Are tools, permissions, memory, and validation designed intentionally? |
| Architecture | Is the system legible enough for safe automated changes? |
| Tests | Do tests prove meaningful behavior or just preserve coverage metrics? |
| Observability | Can humans and agents understand production behavior? |
| Review | Are humans reviewing reasoning and tradeoffs, not just diffs? |
| Governance | Do agents know what they can and cannot do? |
| Metrics | Can we distinguish value from motion? |
| Cost | Do we know what AI-assisted work costs? |
| Learning | Are junior engineers still developing fundamentals? |
This is the unglamorous work.
It is also the work that compounds.
If stronger models arrive inside better harnesses, teams with clear specs, strong architecture boundaries, curated context, good tests, useful documentation, and value-driven workflows will experience them as leverage.
Teams without those things may experience them as noise.
The Next Model Will Not Save Weak Process
Claude Opus 5 may be remarkable. Codex 6 may be remarkable. GPT-5.5 or the model after that may be ridiculous.
But the most important question is not:
How smart will the next model be?
The better question is:
Is our organization ready for a world where execution gets cheaper and judgment becomes the bottleneck?
Because that is where this might be going.
Every new generation of models and harnesses may make it easier to produce code, documents, analysis, workflows, and decisions.
It may also make it easier to produce the wrong things faster, with more confidence, more polish, and better formatting.
The next systems may change a lot.
They may change how engineers work.
They may change how managers measure.
They may change how PMs prioritize.
They may change how companies structure knowledge work.
They may change what technical leadership means.
But they will not remove the need for leadership.
They may make leadership more visible.
And probably more expensive to fake.