David Tattersall
AI coding agents are transforming software development - but they still don’t understand how systems actually behave in production. This post explores why system-level context is becoming the missing layer in AI-driven engineering and what changes when code, runtime and infrastructure are connected.
Over the last year, I’ve watched something extraordinary unfold.
Engineers who used to spend days scaffolding services are now generating them in minutes. Refactors that once felt risky are executed confidently by agents that never get tired. Migration plans appear instantly. Even I've caught the bug and started coding again with Claude - it's magical.
There’s no denying it - AI has changed software development. But I keep coming back to the same question:
What happens when all of that code hits production? Because that’s where things get real.
If you spend time in developer forums right now, you’ll see a split reaction to AI coding. Some believe it’s the future of engineering. Others try it briefly and conclude that it “doesn’t work” because it keeps producing changes that break things.
Both reactions miss something important.
AI coding agents are very good at reasoning over source files. They can follow function definitions, refactor logic and generate clean abstractions - but a repository is not the same thing as a running system.
A real system includes service dependencies, infrastructure topology, runtime behaviour under load, historical incidents, configuration quirks and decisions that were made months or years ago for reasons that aren’t obvious from the code alone.
When AI proposes a change without awareness of that broader context, the result can look correct while being subtly wrong. That’s often the source of the frustration people describe. It’s not that the model is incapable. It’s that it’s operating with partial visibility.
AI is increasing the rate at which change enters production systems. Features are built faster. Refactoring happens more frequently. Experiments are cheaper to run.
But production systems don’t get simpler as velocity increases. They become more interconnected and more sensitive to small changes.
When a developer opens a pull request, the meaningful questions aren’t just whether the code compiles or whether the unit tests pass. The real questions are about impact. What depends on this path? What happens under real traffic? Has this part of the system failed before? Is there an operational pattern here that isn’t obvious from the implementation?
The answers rarely live in one place. They’re distributed across logs, traces, infrastructure definitions, dashboards, tickets and tribal knowledge. Reconstructing that context takes time and experience.
Humans struggle to piece it together under pressure. AI tools typically don’t have access to it at all.
The core issue isn’t model size or prompt engineering. It’s context.
Today’s AI development tools can see the repository and perhaps some documentation. They cannot see how services interact in production. They don’t understand actual traffic patterns. They don’t know which endpoints generate the highest error rates, or which shared utility sits on a critical execution path serving thousands of requests per second.
Without that system-level context, AI is reasoning in the dark.
What’s missing is a connected model of how the system actually behaves, linking code, services, infrastructure, deployments, runtime telemetry and change history into something coherent and queryable.
When that layer exists, the nature of engineering work begins to shift.
A support engineer can trace a log message through real service dependencies rather than guessing at ownership. A developer reviewing a pull request can see likely blast radius before merging. Similar services can be compared structurally to understand why one behaves differently. Infrastructure decisions can be informed by observed usage rather than convention.
Remediation is one outcome of that context. So are better investigations, more confident development and clearer architectural reasoning.
Context doesn’t just help you fix problems. It helps you avoid creating them.
We’ve been building observability solutions for years. Observability gave us visibility into distributed systems and that was a major step forward - but observability tools were designed primarily for human interpretation.
AI changes the equation.
If machines are participating in generating change, they need structured access to the environment they are changing. Otherwise we accelerate complexity without increasing understanding.
This is often what sits behind the skepticism you see in developer communities. Someone tries AI coding, deploys the result and encounters unexpected behaviour in production. The conclusion is that AI isn’t ready.
In many cases, the model was capable. The system context was missing.
We are entering a period where AI will generate more code than any individual can reasonably understand line by line.
Major industry analysts are already forecasting that a significant portion of new enterprise software will soon be built using AI-native engineering techniques. If that trend holds, the volume and velocity of change inside production systems will increase dramatically over the next few years.
That doesn’t reduce the need for engineering discipline. It increases the need for system awareness.
When more software is generated through AI-assisted workflows, the limiting factor won’t be how quickly code can be written. It will be how well its consequences are understood once deployed.
AI doesn’t just need access to code. It needs structured access to how the system actually behaves - across services, infrastructure, and runtime.
That’s the layer we’re building at OpenTrace: a connected model of system reality that both humans and machines can reason over.
AI coding isn’t failing. It’s operating in the dark. Give it visibility and the conversation changes.
—
David Tattersall
CEO, OpenTrace
