For many years, software development was largely synonymous with coding. Sprint planning revolved around coding tasks, team sizes were calculated based on coding capacity and career paths were mostly mapped out with the goal of becoming a “better coder”. Yet software development was never solely about coding. Analysis, architectural design, testing, deployment—these were equally critical parts of the same cycle.

But saying this was easy; getting it accepted was hard. Because for years, coding was the most visible and measurable part of this cycle: how many lines were written, how many tickets were closed, what the sprint velocity was. The rest of the system—defining the problem correctly, setting up the architecture properly, establishing constraints from the start—was always considered the stuff in the background.

“Are you a programmer or an engineer?” I’d ask. They’re not the same thing. They never were.

I’ve been in this industry for seventeen years—long before AI became such a hot topic—and I’ve said the same thing at every opportunity: Don’t just be someone who writes code. Conduct thorough analysis, design an architecture that fits your analysis and don’t touch the keyboard until you’ve properly defined the problem. Be a true engineer.

How is the acceleration of coding changing things?

With AI-powered tools, coding times are shrinking dramatically. The skeleton of a module that used to take a team weeks to build can now be produced in a matter of hours. This increase in speed makes the remaining stages of the software development cycle more visible and more critical.

Think of it this way: You’re building a house. In the past, laying the bricks was the longest phase. A machine came along and started laying the bricks for you very quickly. But if the foundation is laid incorrectly, or the structural calculations are off, the machine is simply laying bricks in the wrong place at high speed. Speed cannot replace direction.

If the right analysis had been done at the beginning, AI could have coded that correct architecture at the same speed. The result would have been both correct and fast.

Where is the value shifting?

In the software economy, value is shifting from coding capacity to analysis and architectural competence. This shift isn’t gradual; it’s structural. It’s now possible to deliver more products with fewer engineers. But this phrase “fewer engineers” is misleading. There’s actually less coding to do and more responsibility to build the right thing.

Defining the right problem, choosing the right technology, determining how the system will scale, where it will break and under which constraints it will operate—these have always been the essence of the job. The difference is that now, the cost of skipping these steps emerges much faster and much more heavily.

If only thirty minutes had been spent at the beginning asking, “How will this system behave with 100,000 users?” the architecture would have been different and those six months would have been saved. AI could have written the code quickly, but writing the wrong decision faster doesn’t solve the problem—it amplifies it.

The engineer as an orchestra conductor

This is where a new role emerges, one that largely overlaps with the concept of a “true engineer” that I’ve been trying to define for decades. The engineer is no longer the person who writes the code; they are the one who directs the AI, coordinates it and evaluates its output. Like an orchestra conductor.

The conductor doesn’t have to play the violin. But they must know which part enters when, how the sounds blend, where the tempo changes and what meaning the whole piece conveys. AI is a powerful instrument. But without a conductor, it produces noise.

Communication as an engineering skill

Another skill that is becoming much more critical, both for directing AI and for producing value within the organization, is communication. And I’m not talking about this in the narrow sense of giving presentations or writing emails.

Being able to ask the right questions to truly understand a need, to extract the real problem behind what stakeholders are saying, to clearly convey the architecture you’ve designed to both a non-technical manager and a technical team and to express the context you’re giving to AI completely, accurately and correctly. These are no longer “nice-to-haves”; they are essential parts of engineering.

The observation of many years has not changed

Engineers who have built their careers solely on writing code may feel this transformation painfully. This feeling is understandable, but it’s focused on the wrong thing. The threat isn’t coming from AI. The threat comes from the fact that we can no longer postpone the transformation we’ve been delaying for years.

If you have the ability to think systematically, analyze problems, design architectures and express them clearly, this period is not a threat to you; it’s a time when your value is finally rising to where it deserves to be. AI makes good engineers stronger. It makes bad engineers faster at being wrong.

AI has learned to write code. But knowing what to build, why and how—and expressing that knowledge clearly enough to transfer it to a tool—is still a human job.

To be an orchestra conductor, you must first understand the music deeply. Who will design the system, who will direct the AI, who will evaluate the output? The engineer who can analyze, think architecturally, communicate and orchestrate all of these.

I’ve been saying this for a very long time. Now I don’t need to say it; AI itself is proving it.