Every executive conversation I have starts the same way. Tooling budgets. Adoption dashboards. Training roadmaps. All of it oriented around the technology. None of it oriented around the people.

Anywhere from twenty minutes in to the relationship or 20 months, someone asks the real question.

How do we know our people can actually do this?

Not “how do we train them.” The question underneath that one. Can our engineers actually engineer?

—

These Are People’s Careers

Before I answer that question, let me say something important. These are people who spent years, sometimes decades, building expertise in a system that rewarded certain behaviors and did not require others. They showed up. They did what was asked. The game changed underneath them and that is not their fault.

Be kind about that. Be patient with people genuinely trying to adapt.

But kindness is not pretending the change is not happening. You cannot produce software in a pre-AI fashion in the age of AI. Organizations that externalize knowledge, direct agents effectively and ship at AI-native velocity will outrun you. Not by a little. By miles. The gap compounds every quarter.

This qualification is not designed to eliminate people. It creates clarity. Where the gaps are, who needs training, who is ready to lead, who needs support. You owe your people that clarity. What you do not owe them is pretending the standard has not moved.

—

The Workforce Has to Change

AI does not fix subpar engineering. It amplifies whatever is already there. Strong engineer plus agent equals dramatically more output. Subpar engineer plus agent equals the same confused output, faster. The agent is a force multiplier. Multiply by zero and you get zero.

The engineers who thrive already understood software at a fundamental level. They could design systems on a whiteboard, reason about coupling and cohesion, explain why they chose an interface over an abstract class. AI did not give them these capabilities. It removed the mechanical work so those capabilities could run at full speed.

The engineers who struggle built careers on pattern matching. Copy, paste, modify until it compiles. That worked when we threw bodies at problems. It does not work when the bottleneck is understanding.

The Externalization Problem

A lot of engineers can write code that works. Ask them to explain what they built and they cannot. Ask why they structured it this way and they shrug. Ask them to write down requirements before starting and they freeze. The knowledge lives in their head. It never needed to exist anywhere else.

That was fine when the only consumer of your intent was your own hands on a keyboard. An agent is not your hands. An agent is a coworker starting from zero on your context. You have to externalize. Take what is in your head and put it into words, specifications, clearly articulated context. The same way you would onboard a strong junior engineer. You would not say “fix the payment thing.” You would explain what the system does, where the problem is, what constraints exist.

Engineers who never externalized their thinking struggle most with agents. Not because they are bad. Some are quite good in isolation. But isolation is no longer the job. The job is to think clearly enough to direct another intelligence, and that is a skill our industry never selected for.

The good news: externalization is learnable. A practice, not a talent. But it has to be revived.

—

Less Handoffs. Less Bureaucracy. More Shipping.

While we are talking about people, let’s talk about how they are organized. I am not forecasting a flat organization. That word carries too much baggage. I am forecasting fewer handoffs, less process theater, less organizational scar tissue from decades of not trusting the people closest to the work.

It is astonishing what an empowered team of eight can do with the right risk management framework. I have watched teams like this ship in weeks what traditional organizations take quarters to deliver. Not smarter people. Fewer stops. No context translation between the person who understands the problem and the person who builds the solution. They are the same person. Every management layer is translation. Every approval gate is a queue. Every handoff is information loss.

Everyone Needs to Be an Engineer Again

Here is what is happening in the organizations pulling ahead. Everyone in the technical organization is putting their hands on code. Not just ICs. Everyone.

Managers ship production code. Directors ship production code. CTOs ship production code. Not because someone told them to. Because agents made it fun again. The drudgery that drove these people into management is gone. The part they loved, design, problem-solving, the satisfaction of watching something work, is back.

These are qualified engineers who accumulated rust while sitting in planning meetings. The agents help them dust it off. What is underneath is still good. They stopped building because the organizational model said their value was coordination, not creation. That model is over.

The implication: everyone who touches decisions about what gets built needs to pass this qualification. ICs. Managers. Directors. VPs. If you cannot pass a fundamental engineering assessment, you have no business directing an agent to build software.

—

So How Do You Qualify Them?

We have talked about the people. We have talked about what they need to be able to do and how they need to be organized. Now let’s talk about how you actually measure it.

Not just a hiring interview, although it works there. A qualification standard for your existing technical organization. Anyone making decisions about software your customers depend on.

None of this is new. Written exams and whiteboard sessions have been standard in engineering interviews for decades. The only change is Phase Three: the take-home is now done with agents, so it takes six hours instead of weeks of unpaid evenings.

Everything here is what you would expect from a fresh CS graduate walking across the stage this spring. They can explain data structures. Design a system on a whiteboard. Build working software with an agent. A twenty-two-year-old meets this baseline on day one. Why is it not the standard for your team? Your org? Your leaders?

Phase One: The Written Exam

One hour. Written. Closed-book. No AI.

Old-fashioned. Deliberately so.

Array versus hash table. Linked lists. Performance characteristics. If you cannot explain these on paper, you do not understand them. You have been copying them.

Coupling. Cohesion. SOLID. GRASP. Triangle testing. The testing pyramid. These determine whether agent-generated code is maintainable or a liability the moment someone else touches it.

Interface versus abstract class. Functional versus OOP versus procedural. Not because there is a right answer. Because a qualified engineer articulates the tradeoffs. If you cannot reason about these choices, you cannot evaluate whether an agent made a good one.

One hour. No tools. Just you and what you know. What you would expect from a new college graduate.

Phase Two: The Whiteboard

Ninety minutes to two hours. Whiteboard. In-person. No AI.

A real problem. Payment system for an auto loan company. Ticketing platform for a concert venue. Common domains you have seen before.

Ten minutes of clarifying questions, then you are on your own. Full application. Web interface. Data model. Service boundaries. Integration points.

At the end we talk. Not to grade. To explore. Why this boundary? Why this data model? What changes at ten times the load?

I do not care if you spelled a library name wrong. I care whether you think in systems. Can you identify boundaries, reason about complexity, make tradeoff decisions and explain them?

Can you acknowledge what you do not know? In ninety minutes you cannot fully specify a production system. I want the engineer who says “I need to understand the regulatory requirements first” or “this assumes a volume pattern I would validate.” That gap awareness separates someone who directs an agent from someone who confidently ships garbage.

Phase Three: Build It with Your Agent

Six hours. Your agent of choice. Full autonomy.

Next day. Take the system you designed. Pick your agent. Six hours. Build it.

This is the only genuinely new part. Three years ago a take-home meant weeks of unpaid evenings. Disrespectful and everyone knew it. Good candidates refused. Agents changed the math. Six hours builds a meaningful system: working endpoints, reasonable data model, real tests, deployable artifact. If using this externally, pay them for it.

Then we explore the code together. Why this tradeoff? When the agent produced something, did you read it? Understand it? Could you explain what this function does?

Is it deployable? Where did the agent help? Where did it hurt? Where did you override it?

This is where everything converges. Fundamentals. Design thinking. And the ability to ship with an agent. Can you direct it, evaluate its output, catch its mistakes, understand the security implications?

The constraint shifts constantly when working with an agent. Sometimes the agent is bottlenecked on your incomplete specification. Sometimes you are bottlenecked on evaluating its output. Engineers who read that flow and adjust in real time are the ones who ship.

—

The Clock Is Running

The industry spent twenty years throwing bodies at problems. Everyone knew it did not work. Fred Brooks explained why in 1975. Adding people to a late project makes it later. Fifty years ago. Your peers did not read it. They hired anyway because headcount looked good on paper, because it felt like progress, because requesting ten more engineers was easier than asking why fifty could not ship.

That era is over. Now you need to perform. Your competitors will. This is an abrupt change in how you lead, how you ship and how you govern. The old way will not survive.

Within eighteen months, the expectation that everyone in a technical organization actually practices engineering will be the norm. The era of the manager who has not touched code in a decade is ending. Not because we decided it should. Because the economics no longer support it. A leader who builds alongside their team is worth five who read dashboards.

Cannot pass a written exam on data structures? You cannot evaluate agent-generated code. You will accept whatever it produces because you lack the knowledge to critique it. That is not engineering. That is hope.

Cannot design a system on a whiteboard? You cannot direct an agent to build one. You will give it fragments and pray.

Cannot ship working software with an agent? Then what exactly is your role?

Maybe the clock runs out this year. Maybe next. Nobody knows exactly when. But there is a countdown timer on your organization and it ticks faster every day. And the timer is not on your technology. You have the tools. The timer is on your people.

That was always the real question.