AI-driven tech layoffs suck, but might lead to certification

The advent of AI coding, combined with the cost of building out AI infrastructure, is shredding tech industry employment. Tech companies have already laid off almost 200,000 people so far this year. Earlier this week, Microsoft announced that it is offering buyouts to 60,000 employees, fully 27% of the company. 

Whatever you think of the ethics of how LLMs were built, AI coding efficiency not just hype designed to boost big-tech stock prices. Consider one of the dads of my younger son’s soccer team, the head of engineering at a small company. He told me that he’s creating more code himself than he has in years, and could easily cut his 10-person team down to three or four. He’s focusing on finding them other useful work inside the company rather than laying them off, but that’s a positive exception, not the norm.

In addition to the immediate human cost of all those layoffs, AI coding is generating a lot of angst about the future of the profession. If senior engineers like Soccer Dad can use AI to build software without a team, will they stop hiring entry-level engineers? If there aren’t any entry-level engineers today, there won’t be any senior engineers tomorrow, and the industry will hit a wall as it’s populated by dead-eyed AI prompters generating huge volumes of garbage code that they don’t understand.

We should all care about this, because the safety of the software we use depends on engineers with years of hands-on experience down to the smallest components of the code. Junior engineers right out of school are given low-risk starter projects like bug fixes or minor features. As they prove their skills at coding and testing, they are gradually entrusted with bigger projects and more complex problems like system design. The only major fork in the path is whether to stay an individual contributor or jump over to management, to supervise the next generation of junior engineers. No junior engineers → no path to expertise → the death of trust.

How do other professions develop senior practitioners without making them start at the very bottom and learn everything on the way up? Junior architects don’t start out by hand-building a back-yard shed or applying drywall in a renovation. They need to collaborate with construction companies who turn their plans into reality. I spoke to a good friend who co-leads an architecture practice in Philadelphia, to learn about an different sort of apprenticeship-based career path.

As he explained, architecture is fundamentally a teaching profession. Junior architects are a cost center for the early years of their development – they don’t earn the firm nearly as much as it costs to employ them and continue their education. They begin by carrying out work that leverages what they learned in school, such as analysis and visualization, that doesn’t require the precision of detailed blueprints (“contractual documents”). They are exposed to the more detailed, rigorous work gradually by licensed architects, who review and coach them at every step of the process until they’re ready to take direct responsibility, and train up the next generation of junior engineers.

This sounded to me like an inversion of the traditional software path. Instead of learning the guts first and then building on it, junior architects start on the edge of the project and work their way into the critical details. How, then, does the profession know if a junior engineer is ready, if they haven’t in effect built a bunch of small buildings first? This is where licensing comes in. Architecture is heavily regulated at the state and municipal level. To become a licensed architect who can stamp plans in the US, you need an architecture degree, must pass a huge test with six sub-divisions, and often need documented years of experience as well. It usually takes over a decade from starting college to receiving your license.

All despite never picking up a hammer or laying down a course of brick.

Steve McConnell made the architect-vs-carpenter analogy way back in 1999 in After the Gold Rush (see my piece from last week). The future of software engineering looks similar to me, except that the carpenters are changing from junior coders to AI coding agents. We need to figure out how to train and certify software engineers who can handle the rigor of system design and architecture without spending years hand-writing code first.

Just as architects need to develop blueprints that can be understood and built in the real world, future engineers will need to know how to write specifications and prompts that will not lead AI agents astray, and review their work for correctness. Today’s senior engineers are learning to do this on the fly as AI improves. The new education challenge is documenting their best practices into a body of knowledge that can be taught to the next generation.

The power of one engineer to build a whole system with agents also means the educational stakes are higher. Giving a junior engineer access to a bunch of coding agents will let them wreak exponentially more havoc than having them hand-code a few minor bug fixes. Certification and licensing lets the industry set a standard for the knowledge and experience someone needs to be entrusted with this power.

This makes sense at an industry level, but it doesn’t solve the layoff problem. There are only 123,000 licensed architects in the US, less than a tenth of the current population of 1.7 million software developers. A select group of trained and certified software engineers piloting fleets of coding agents might be good for the industry, but it won’t help the armies of current professionals who may not have a job in a few years.

I can think of one more optimistic path that might support a larger number of licensed senior engineers. The parallel phenomenon to engineering productivity inside tech firms is the rise of vibe-coding among the much larger population of non-engineers. I am regularly approached by old colleagues from sales or product management who are building new startups based on products they developed themselves with AI. While the ideas are promising, their lack of knowledge about whether they’ve built something safe and secure makes me nervous.

Trained, certified software engineers could start a new practice of reviewing and signing off on vibe-coded apps. This could happen near the end, like a building inspection before occupancy. But I would prefer to see it move upstream and become a requirement at the design phase, like having architects stamp plans before construction begins.

A future world where software engineers are extensively trained and certified to use AI agents to build and review software for security and correctness won’t stop every bug or vulnerability, of course. But I think that a shift away from hand-coding apprenticeships toward professional qualification would set higher standards that end up being better for all of us in the long run.

Ideas? Feedback? Criticism? I want to hear it, because I am sure that I am going to get a lot of things wrong along the way. I will share what I learn with the community as we go. Reach out any time at [email protected].