Over the past few months, I’ve noticed an odd pattern in engineering job descriptions.

Many of the newer AI-first roles are nominally software engineering positions, yet a surprising amount of the qualification section has very little to do with programming. The tooling changes from company to company, but the underlying requirements sound remarkably similar: break down complex problems, coordinate multiple streams of work, evaluate competing solutions, review generated output, and maintain quality while moving quickly.

The references to Claude, Cursor, Copilot, or ChatGPT tend to get the attention. The rest of the description is often more interesting. Read past the tooling requirements and many of these positions start sounding less like traditional programming roles and more like technical leadership roles.

That observation stayed with me because it appears to contradict one of the more common assumptions about AI-assisted development. If software is becoming easier to generate, shouldn’t implementation matter more than ever?

For decades, software engineering was constrained by production. Turning ideas into working software required engineers, time, coordination, and often a surprising amount of patience. Most of the industry’s tools, practices, and processes evolved around that reality. We invested heavily in making software easier to produce because producing it was the bottleneck.

AI changes that equation.

A single engineer can now generate prototypes, integrations, scaffolding, tests, documentation, and increasingly substantial pieces of production code in a fraction of the time it would have taken only a few years ago. Multiple agents can work simultaneously. Entire categories of routine implementation are becoming dramatically cheaper.

Most discussions about AI focus on how much software can now be generated. Far fewer ask how much software an organization can realistically absorb, and the gap between those two numbers may matter more than the models themselves.

Software has never struggled to accumulate complexity. Teams struggle to understand it, maintain it, evolve it, and keep it aligned with the original intent. Increasing the rate of production does not remove those challenges. In many cases, it amplifies them.

As implementation becomes cheaper, coherence becomes more expensive.

The first time I used multiple agents on the same problem, I assumed generation would be the difficult part. It turned out to be the easiest.

Producing answers was never the issue. Producing code wasn’t either. The challenge was keeping the outputs aligned. Each agent carried a slightly different understanding of the problem, a different interpretation of the constraints, and a different view of what success looked like. Useful work appeared almost immediately. Reconciling assumptions, resolving contradictions, and deciding which direction to trust took considerably longer.

The situation felt familiar.

Architecture is often described as a technical discipline, but much of the work revolves around coordination. Architects spend an enormous amount of time deciding where responsibilities should live, how systems should communicate, and which boundaries should exist. The diagrams matter, but the deeper challenge is maintaining coherence across independently evolving parts of a system.

The same pattern appears inside organizations. A good engineering manager is rarely the person producing the most code, and a technical lead rarely spends all day implementing features. Their value comes from creating alignment between people, priorities, and systems that would otherwise drift apart. They clarify goals, establish ownership, remove ambiguity, reconcile competing constraints, and help independent contributors move toward a shared outcome.

Working with multiple agents turns out to involve many of the same concerns. Once several of them can contribute simultaneously, the work begins shifting away from implementation and toward coordination. Someone still needs to decide what problem is being solved, how the work should be divided, where responsibilities begin and end, and how conflicting outputs should be reconciled.

Whether the contributor is a person or an agent changes surprisingly little. The need for ownership, boundaries, integration, and clear contracts remains. The medium changes, but the coordination problem remains remarkably familiar.

Some of the emerging AI terminology feels less foreign than it first appears.

Context windows behave a lot like organizational memory. Tool contracts resemble API contracts. MCP servers expose capabilities in much the same way stakeholders expose information, constraints, and domain expertise. Neither owns the final outcome. Both participate through clearly defined interfaces, and both become far more effective when expectations are explicit.

The parallels are not perfect, but they point toward something interesting. Many of the skills traditionally associated with senior engineers and engineering managers transfer naturally into AI-assisted development because they were never fundamentally about coding. They were about maintaining coherence across a growing system whose parts evolve independently.

The more I worked with multiple agents, the more those job descriptions started making sense.

At first I assumed the emphasis on AI tooling reflected a new category of engineering work. What surprised me was how quickly the challenges began resembling ones I had already seen elsewhere. The specifics were different, but the pattern was familiar: independent participants operating with incomplete context, moving at different speeds, and occasionally pulling in different directions.

The work itself arrived quickly.

Keeping it pointed at the same destination took far more effort.

Looking back, that is probably what many of these roles are actually trying to identify. Not familiarity with a particular tool, but the ability to maintain direction as the number of moving parts increases.

Software teams have always needed people who could do that.

The fact that some of those moving parts are now agents does not change the requirement nearly as much as I expected.