Agentic engineering
Coding agents are becoming shared infrastructure
An assistant on one laptop helps one engineer. An agent that a whole organization shares needs context, permissions, checks and a record. That set of things is the engineering harness. This page is how I see it, and where I think software delivery is heading.
What changed
The constraint moved from typing to deciding
On the teams I run, coding agents write most first drafts now. That changed where the time goes, and it changed very little about what makes a release safe.
Drafting got cheap
An agent produces a working first draft in minutes. The draft was rarely the expensive part. A wrong decision costs the same whether a person or an agent typed it.
Review became the constraint
How fast a team ships now depends on how much it can review well. Adding an engineer adds review bandwidth and judgement.
The spec became the unit of work
If nobody can write the spec, nobody understands the work yet. Faster drafting doesn't fix that, and it hides it for a while.
Where it is heading
Seven shifts I see, and what is still unsettled
Agents get an owner and a registry.
An agent that many teams use needs an owner, a status and a scope, the way a service does. Port's documentation describes a registry of agents with ownership, and a second registry of the skills, prompts and tool servers a team is allowed to use. GitHub gives enterprise administrators a control plane, with audit logging, for the agents that run in their repositories.
Sources: Port, agent management, GitHub changelog, February 2026
The software catalog becomes the agents' context.
A developer portal used to be a place where people looked things up. The same catalog is now served to agents. Port calls its version a context lake. Backstage exposes its registered actions to agents as tools over the Model Context Protocol. Thoughtworks placed context engineering in the Adopt ring of its Technology Radar.
Sources: Port, Backstage, MCP Actions, Thoughtworks Technology Radar, volume 34
Instructions become shared and versioned.
What used to be one person's prompting habit is turning into a file that the team reviews. AGENTS.md is an open format for instructions to coding agents, and its site says that more than 60,000 open-source projects use it. Cursor's team rules take precedence over an individual's rules. Thoughtworks lists curated shared instructions for software teams under Adopt.
Sources: AGENTS.md, Cursor, rules, Thoughtworks Technology Radar, volume 34
Policy is set once, by the organization.
Vendors of coding agents have converged on settings that an administrator delivers to every user. Claude Code documents managed settings that an organization can deliver. Harness describes agents that run on scoped, short-lived tokens tied to the person who triggered them.
Sources: Claude Code, settings, Harness, identity and permissions for agents
Agents move off the laptop.
Large engineering organizations describe agents that run in the background on shared infrastructure. A run starts from a chat message or a ticket and ends in a pull request. Stripe reports more than a thousand merged pull requests a week from its agents, each reviewed by a person. Spotify reported more than 1,500 merged pull requests from its background agent in November 2025. Shopify reports that one in eight merged pull requests is co-authored by its shared agent.
Sources: Stripe, Spotify, part 1, Shopify
Checks run before a person looks.
Spotify describes a loop of independent verifiers, followed by a judge that vetoes about a quarter of agent sessions. Birgitta Böckeler describes a harness as guides that steer the agent and sensors that check its work. At QCon London, Spotify's engineers said that review had become the bottleneck, and code generation no longer was.
Sources: Spotify, part 3, Böckeler, harness engineering, InfoQ, March 2026
The conventions move to neutral ground.
In December 2025 the Linux Foundation formed the Agentic AI Foundation. Anthropic contributed the Model Context Protocol, Block contributed goose, and OpenAI contributed AGENTS.md. A convention that no single vendor owns is one a harness can depend on for longer than a product cycle.
Source: Linux Foundation, December 2025
The speedup isn't measured yet
METR's trial from early 2025 found that tasks took 19% longer with AI. In February 2026 METR wrote that developers are likely faster now, and that its newer data is only weak evidence of how much.
Source: METR
More change can mean less stability
In the 2025 DORA report, 90% of respondents use AI at work and 30% have little or no trust in the code it writes. Adoption of AI still has a negative relationship with delivery stability.
Source: DORA 2025
The leaders built their own
Stripe, Spotify and Shopify each describe a platform they built themselves. The published evidence supports the pattern. It doesn't yet show that buying a platform gets a team to the same place.
A count of pull requests is an output
None of these accounts reports the effect on defects or on customers. I read the numbers as evidence that the pattern runs at scale, and as nothing more than that.
The harness
What sits around the agents
A harness is everything around the model that makes its output safe to ship. The model is one dependency in it, and I expect to replace that dependency several times a year.
A written statement of the outcome, the constraints and the acceptance checks.
Acceptance is written down before the work starts.
What any agent may read about the organization's software.
Who owns a service, what it depends on, how it is deployed, and the conventions of its repository.
An agent set up for one kind of work, with its own instructions and its own tools.
Data engineering, backend, web, data science, DevOps.
A procedure that several agents share, written once.
How to write a migration. How to verify a change in a browser.
What an agent may read, write and call, decided per agent and per task.
A review agent can comment on a change. It can't merge one.
A test, an evaluation or a policy that a change has to pass.
The same checks apply whether a person or an agent wrote the change.
What a change leaves behind.
The spec, the plan, the check results, and who approved the release.
In production
The harness our teams deliver with
At Egen I led the design of the agentic engineering harness. The platform team built it, and our delivery teams moved onto the agentic SDLC that runs on it. This is the version that ships client work today.
Work starts from a written spec. Role-based coding agents for data engineering, backend, web, data science and DevOps draft the code and the tests. A review agent checks each change against the plan and against the repository's controls.
Engineers make the product calls and the release calls. The release pipeline requires review, test and evaluation gates on each change. Data pipelines go through the same gates as services.
The same workflow ran the analysis of the existing services ahead of the Azure cloud digitization. Analysis here means reading each service and writing up what the digitization has to carry over. The digitization itself is engineering work with its own timeline.
Checks
A check that only advises gets ignored
Agents raise the volume of change. The checks are what keep the volume from becoming risk, and they only work if they can stop a release.
Checks block
Every check has an owner and a list of what it stops. Under a deadline, a warning is read as permission.
The same checks for people and agents
The checks don't move when an agent wrote the change. Data pipelines pass the same checks as services.
A waiver is a record with an expiry
A waiver names its owner, its reason and the date it ends. A waived check never counts as a passing check.
Quality bar
Eight rules we hold each change to
Generated code has to read like a senior engineer wrote it and pass a reviewer who has never seen it. These rules are the checklist, for people and for agents.
Lint is truth
Run the configured linter before calling anything done. A linter that is configured and can't run is itself a finding.
No silent failures
Every degraded outcome either raises with the cause and the workaround, or is an explicit behavior with a test.
Deterministic output
Wherever order leaks into output, sort at the source. A claim of determinism gets a test.
Comments state constraints
A comment says why something must hold. A docstring states the contract. Neither repeats what the next line does.
Tests assert behavior
Tests describe what the system does for its caller. Every fixed bug gets a regression test with a name.
Verify by running it
Run the suites of every repository the change touches. For a screen, open it in a browser, use it once and read the console.
A second reader before commit
A reviewer that didn't write the change reads it for correctness, craft and security. Critical findings are reproduced before they are fixed.
Focused commits
One change per commit, in the repository's own voice. Unrelated refactors travel separately.
What the team learns goes back in
When an agent gets something wrong, the fix goes into the shared instructions, so the next run starts from it. Only what was verified goes in, and a note that turns out wrong is removed.
Report what happened
If a test failed, the report says so and shows the output. If a step was skipped, the report says that. An agent that reports success it didn't verify is worse than one that reports a failure.
The organization
What changes for the people
I lead application, data and AI engineering teams, and I run the hiring loop. The harness changed what I look for and what I measure.
I hire for judgement.
I look for two things. Can this person review a change they didn't write and find what is wrong with it? Can they write a spec that another person, or an agent, could build from?
The reviews are the same on every team I run.
Design reviews, code reviews and pull requests apply to all of my teams and to each change. Who drafted the change has no effect on which reviews it gets.
The KPIs are due for a rewrite.
The delivery KPIs I set two years ago measured output. Output is now cheap. I'm moving toward the quality of the spec, the share of changes that pass the checks first time, review latency and escaped defects.
Engineers need room to try things.
I run workshops and bootcamps for our teams, and I leave time for engineers to try new models and techniques. A team that only uses the harness will not improve it.