Part of The Ego Tax series — stories on how overconfidence and inexperience quietly bankrupt software projects.

A few years ago, the credential everyone suddenly needed was a Scrum certification. Companies that had never run a single sprint were requiring it in job postings for roles that had nothing to do with software delivery. Consultants built entire practices around teaching organizations to hold better standups. For a while, "Agile-certified" functioned less like a skill and more like a password — say it, and you were let into the room.

That fad faded, the way they do. It didn't fade because Agile was worthless. It faded because most of what it promised was never really about the certification in the first place.

The new password is AI.

"Write Code Using Only AI"

Last year, a small medical company — maybe five to ten people if you count the board and investors — posted a role looking for someone to write their flagship product's code using AI, and only AI. Not "someone comfortable leveraging AI tools." Not "AI-assisted development experience preferred." The requirement, as written, was that the code should be produced by AI, full stop, as if that were itself the qualification.

I looked into the company a bit further. What I found was a familiar shape: a real idea, real funding, and almost no internal expertise in how software actually gets built. Nobody in leadership had shipped a product before. Nobody could evaluate whether the code this hypothetical AI-only engineer produced was secure, whether it would scale, or whether it met the regulatory bar a medical product needs to clear. They didn't need someone who understood software. They needed someone who could operate the machine that would, they assumed, understand it for them.

This is the same instinct that drove the Scrum certification rush, wearing a new outfit. Then, the belief was: if we adopt the right process, we don't need to develop real judgment about how our team builds software. Now, the belief is: if we adopt the right tool, we don't need to develop real judgment about how software gets built at all.

Junior Title, Senior Expectations, Zero Technical Grounding

This same pattern shows up constantly in postings for junior and mid-level engineering roles right now: companies wanting "senior-level AI experience" from candidates they're offering junior-level pay, to build what the posting inevitably describes as a product that will "take the world by storm." I've seen this from founders and hiring managers who, by their own description of the role, clearly do not understand what the technology they're demanding actually does, or doesn't do.

This is worth sitting with, because it's a different flavor of ego than the one we covered in the last piece in this series. That story was about a technical team overestimating its own competence. This is leadership demanding expertise they have no ability to evaluate, from people they're not paying to have it, to build something they've already decided, sight unseen, will be extraordinary.

At least a team that overestimates its own skill has some skill to overestimate. A founder who can't tell competent AI-assisted engineering from a junior developer copy-pasting whatever the model outputs has no basis for judging the work at all — which means every technical decision in that company is effectively being made on faith.

The Fad Changes. The Underlying Problem Never Does.

Agile certifications didn't fail companies because process is bad. AI adoption won't fail companies because the technology is bad. Both fail for the same reason: leadership reaching for a credential, a tool, or a buzzword as a substitute for developing the judgment to actually evaluate what's being built, by whom, and why.

A company that couldn't tell whether its team was actually agile just adopted the vocabulary and called meetings "sprints." A company that can't tell whether its team is using AI well just adopts the requirement and calls the result innovation. Neither company has actually solved the problem the fad claimed to fix. They've just found a new way to feel confident about a decision they were never equipped to evaluate.

What This Costs

Circle back to that medical company. A regulated product, built by whoever could satisfy an "AI-only" job requirement, reviewed by leadership with no ability to independently assess whether the code was sound, secure, or appropriate for the domain it was entering. That's not a hypothetical risk. That's the exact setup that produces the kind of expensive, sometimes dangerous failures regulated industries are supposed to be structured to prevent.

Multiply that by every small company currently hiring for "AI-only" development, or demanding senior-level AI judgment from junior-level hires, and you get a quieter, slower-moving version of the same billions-of-dollars failure pattern this series keeps returning to. It doesn't announce itself as a crisis. It just quietly ships products nobody with real expertise ever actually vetted.

What Actually Fixes This

The fix was never going to be a better certification, and it isn't going to be a more sophisticated AI tool either. It's leadership — technical or not — developing enough real judgment to know what questions to ask before a hire is made, before a requirement is written, before a product ships. A non-technical founder doesn't need to learn to code. They need to learn enough to recognize when a job posting they've written doesn't actually describe the problem they're trying to solve, and when "the AI will handle it" is a plan or just a hope wearing a plan's clothing.

That's a trainable skill. It's just never the skill anyone reaches for first, because reaching for the current buzzword feels like progress, and admitting you don't yet know enough to evaluate your own hiring requirements doesn't.