For several months I have been writing software without writing any compilable code. Most of it has been in Go but there has been plenty of SQL, JavaScript, HTML and a smattering of other languages. The code is not bad either. Claude writes most of it for me, and this is no longer an unusual or emerging pattern — it is simply how software gets built now.
This brings a new problem: trust. When you aren't the one writing the code, how do you know it's doing what you think it's doing? How do you know it's not quietly accumulating debt in every corner? How do you know the thing you shipped last Tuesday isn't misbehaving in some edge case you haven't hit yet?
In fact, it's not a new problem at all.
Senior leaders in organisations have been grappling with exactly this for a very long time. If you aren't making the widgets, how can you be sure the widgets coming off the production line are actually what you want? A factory floor manager doesn't stand at every lathe. A CFO doesn't reconcile every ledger entry. They rely on dashboards, reports, exceptions, and the occasional deep dive. The signal that something is wrong comes from the numbers, not from intuition built by doing the work themselves.
Software engineers are now in exactly the same position.
The observability stack — metrics, traces, logs, dashboards, alerts — is no longer just infrastructure plumbing for the ops team. It is the primary way an engineer understands what their software is actually doing. When an agent writes a database query that looks reasonable but performs terribly under load, you won't always catch that by reading the code. You'll catch it in a slow query log or a latency spike on a dashboard. When a background job is silently failing on edge cases, the first sign won't be a code review comment — it'll be a metric that's off or an alert that fires at 2am. The engineer who can read those signals quickly, trace them to a cause, and steer the agent to fix them is the one who ships reliable software.
Like any good manager, the software engineer will review finished work, conduct post-incident reviews, guide agents along the way, and occasionally get close to the code. Some will even write the occasional bit themselves. But the machine does it far, far more efficiently, so the nature of the job has fundamentally shifted. You are now the accountable party, not the implementer.
Software engineering in its traditional form is not a credible long-term career path. Software production management — owning the outcome, reading the signals, steering the agents — will boom over the next few years. And the foundational skill underneath all of it is observability.
If you can't see inside the machine, you can't manage it.