AI agents can write production code. But can they prove it actually works?
That question gradually changed how I approach AI-native software engineering.
Over several months, I used OpenAI Codex extensively while building a platform for managing MetaTrader plugins. The system involved distributed runtime workers, licensing services, configuration management, and integrations with trading infrastructure: the kind of system where “it compiles” is a long way from “it's safe to run”.
Generating code got easier. Confidence didn't.
As I delegated more engineering tasks to agents, one thing became clear:
Generating code was becoming easier. Establishing confidence in that code wasn't.
An agent can produce a convincing implementation quickly. Whether that implementation behaves correctly when a dependency fails, a network drops or a configuration is invalid is a different question, and the code alone doesn't answer it.
Example: a runtime synchronization feature
Consider a worker that synchronizes its configuration from a backend. An agent can implement the API, the synchronization logic and the error handling. The questions that matter come next:
- What happens when the backend becomes unavailable?
- Can the worker safely fall back to its Last Known Good configuration?
- Can the agent verify that behavior, rather than assume the implementation is correct?
That's where my focus started shifting: from writing better prompts to engineering better environments around agents.
Better environments, not better prompts
An agent is only as reliable as the environment it works in. The environment I aim for has five properties:
Architectural boundaries and system contracts are explicit
If module boundaries, API contracts and invariants only live in someone's head, an agent will cross them without noticing. Written contracts give it something to respect and something to be checked against.
Engineering decisions survive individual agent sessions
Each agent session starts with limited memory. Decisions recorded in the repository, such as architecture decision records, conventions and known constraints, mean the next session doesn't relitigate what was already settled.
Isolated execution environments enable reproducible testing
When several agent workflows run at once, they must not share state they can corrupt. Isolated environments make test results reproducible and keep one task's experiment from breaking another's.
Closed feedback loops
Agents need to observe failures, validate fixes and verify actual system behavior: run the tests, read the logs, reproduce the failure scenario. Without that loop, “done” is a claim, not an observation.
Defined verification gates
Changes pass explicit gates before reaching production. The gate doesn't care whether a person or an agent wrote the change.
What harness engineering is, and isn't
This is what makes harness engineering particularly interesting to me. It's not about giving agents more instructions, or unlimited autonomy. It's about designing the tools, context, constraints and feedback loops that let them operate reliably.
| Prompt-first | Harness-first | |
|---|---|---|
| Main lever | Better instructions | A better environment |
| Knowledge | Restated in every session | Lives in the repository and contracts |
| Correctness | Assumed from the output | Observed through tests and real scenarios |
| Autonomy | All or nothing | Scoped by tools, permissions and gates |
Agents as first-class platform consumers
I see a natural connection to platform engineering. We've spent years building Internal Developer Platforms to improve developer experience through Golden Paths, automation and standardized workflows.
What if the next generation of these platforms treats AI agents as first-class consumers?
The governance side of that picture, meaning who may approve what, is the subject of the follow-up note Capability Is Not Authority.
Where the advantage will come from
I believe the next competitive advantage in AI-native engineering won't come from code generation speed alone.
It will come from how reliably we can turn generated code into verified software.
We're getting better at building agents that write code. Are we getting equally better at building systems that can verify their work? Join the discussion on LinkedIn, or see how I design agent-based systems.
Quick answers
What is harness engineering?
Designing the tools, context, constraints and feedback loops around an AI agent so it can work reliably: explicit contracts, decisions that persist between sessions, isolated environments, the ability to observe failures, and verification gates before production.
How is harness engineering different from prompt engineering?
Prompting shapes a single instruction. A harness shapes the environment the agent works in, so behavior can be checked against evidence rather than assumed from the instruction.
What is a Last Known Good configuration?
The most recent configuration a component validated and stored locally. If the backend becomes unavailable, the component can keep running on it safely instead of failing or running unconfigured.
How can an AI agent verify its own changes?
By working in an environment where it can run tests, reproduce failure scenarios such as an unavailable dependency, read the resulting logs and state, and submit changes through defined gates, rather than declaring success from the code alone.