AI Babysitting Is Eroding Engineering Culture

I’ve been hearing talented engineers talk about leaving the software industry. They’re questioning whether they still enjoy the work, or whether there will be a meaningful role for them in a few years.

I understand the anxiety. I feel it too. But I’m also optimistic about the future of software engineering. There is more I want to build than ever, and more of it now feels within reach.

What worries me is how organizations are adopting AI tools, and how little attention some are giving to the role they want engineers to play.

Writing code has taken up much of an engineer’s time, but it has never been the whole responsibility of engineering. Some companies seem to see the faster delivery that agent harnesses give individual developers as the end goal, with little reason to keep investing in their engineering culture.

The culture of unblocking the harness

Consider a workflow that may feel familiar.

An engineer gives a coding agent a task. The agent investigates, chooses an approach, and begins implementing. It encounters a problem: missing access, a failing test, an unavailable tool, or an environment it cannot use.

The engineer removes the blocker. The agent continues. Another blocker appears. The engineer removes that one too.

Eventually, the agent reports that the work is complete.

I’ve fallen into this pattern myself. It is tempting to keep an agent moving, especially when it appears to be making progress. Watching it produce a working result can be satisfying.

But what have we built beyond the software itself?

Can the system test and release another change? Can it detect a failure, investigate the cause, and verify a fix? Have the decisions and interventions become part of its tools, documentation, and automated checks?

Or does the next change depend on someone returning to the conversation and guiding the agent through the same problems?

Removing blockers can be valuable engineering work. What matters is whether the intervention improves how future work gets done. A completed task may leave us with working software that still depends on the same manual attention to maintain it.

Engineering the system that does the work

Now consider the same task with a different workflow.

The engineers begin by designing the system that will build and maintain the software. They work through architecture and code quality, verification and testing, security, delivery, and operations, then build those practices into the factory’s tools, environment, documentation, and feedback loops.

The agents execute within that system: implementing changes, running tests and evaluations, deploying, and monitoring the results.

The agents may do most of the coding. The engineers are designing how that work gets done, how its quality is evaluated, and how the software will continue to be maintained.

The organization is developing a capability it can understand, evaluate, and improve. This is the gap I see between building these systems and relying on engineers to produce code through separate, personally maintained workflows.

Unblock the loop, not the agent

Suppose agents repeatedly get blocked by authentication when testing an API. An engineer can provide access each time. Or the engineer can build a tool that issues short-lived test credentials in an isolated environment, making those tests available to future runs.

Both interventions let the current agent continue. The second also improves the loop through which future work gets tested.

In production, an agent might investigate an error spike, reproduce the failure, and prepare a fix with a regression test. What it learns can also reveal missing diagnostics, gaps in the test environment, or an evaluation that failed to catch the problem.

The feedback improves both the software and the process that produced it.

This is where my interest in cybernetics comes in: how systems use feedback to regulate their behavior and adapt. Some loops correct a change. Others improve the tools and evaluations. Others help the engineers reconsider what they are asking the system to achieve.

The engineering work extends beyond building a piece of software. It includes building and maintaining the system that produces, operates, and improves that software.

Agents, loops, memory, and traces belong to the company

A workflow that exists only in one engineer’s local harness, conversation history, and personal configuration may produce impressive results. But the company has not necessarily gained a system it can operate and maintain. The issue is whether that workflow is maintained as company infrastructure, wherever it runs.

The company needs control over the agents’ configuration, instructions, tools, documentation, evaluations, permissions, and environment.

That includes the experience accumulated through the work. Execution traces record what happened; agent memory carries selected knowledge into future work. If those records remain inaccessible to the company, whether on individual laptops or inside a provider’s service, it loses the material it needs to diagnose failures, build evaluations, and improve its feedback loops.

What excites me about this work

I don’t think our software infrastructure is ready for systems that continuously build and maintain other systems. There is still a lot to build: tools to diagnose agents, improve their memory, and monitor and evaluate factories as they change.

I’m interested in how cybernetics can help us understand and build those systems, particularly how feedback, memory, and control work together. That is work I’m excited to do.

Ultimately, I want some of the same things as the engineers I’ve been talking to. I want to stay in the industry, enjoy the work, and have my time back. I don’t want to spend my days waiting for the next agent to need something from me.

When I work on the loops instead of just unblocking an agent to finish a task, the system starts handling more without my intervention. I get some time back, and some of the anxiety eases.

Unblock the loop, not the agent. Build something that gives you time back.