Congratulations, your CEO is now the designer

Congratulations, your CEO is now the designer. Also the devops engineer, the support desk, the copywriter and, on a good week, the brand team. Nobody got fired. The roles just quietly moved into one person's browser tab, and the org chart got a lot tidier.

This is the pattern I keep running into this year, and I want to be precise about what is wrong with it, because the lazy version of this argument is a designer defending designers against AI. That is not this.

The pull is real

I understand the appeal completely. I run an AI workflow on everything I take on. One person really can now produce a landing page, a database schema, a deploy config and a brand system in an afternoon. The output is real. That part is not a trick, and anyone who tells you it is has not tried it recently.

So the question is not whether one person can produce all of those things. They can. The question is whether one person can tell which of them are any good.

Two skills, and only one got cheap

Producing an artifact and being able to judge it are two different skills. For most of the history of software they arrived together, because the only way to produce a database schema was to be someone who understood databases. The production cost was the filter.

That filter is gone. Production got cheap. Judgement did not.

Generated right and generated wrong come back looking equally finished. Nothing on the screen distinguishes a decision from the most common pattern in the training data. A schema that will fall over at ten thousand rows looks exactly as tidy as one that will not. A checkout flow that quietly breaks a legal requirement is just as well-aligned as one that meets it. The only thing that separates them is the expertise you skipped in order to move this fast.

A developer used to get stuck on the missing screen and ask someone. An assistant does not get stuck. It proceeds, confidently, and hands you something that looks done.

Where the work goes

So the work does not disappear. It moves.

It shows up later as the flow that fights the business it was built for. The record that turns out not to be legally sufficient. The config that works until the day it does not. Then it goes to a specialist to fix, at a worse price than doing it properly would have cost, and quite often to the very person who was told the role was not needed.

Nobody books that cost against the decision that caused it. It arrives months later, filed under something else.

Roles, not people

To be precise about the target: this is not an argument against AI, and it is not an argument for headcount. Removing a person is not the same as removing a role.

I run my own engagements through named roles rather than named people. On a recent build, the work ran through six charters: project management, UX, UI, copy, frontend, and an adversarial QA reviewer. Each one had its own scope, its own required reading, and an explicit instruction never to invent project facts.

The QA charter is the one that matters. Its only job is to send work back. It reviews across all the other roles at once and files severity-ranked issues to whichever one owns the problem. On that project it took three rounds to close at zero blockers, zero majors and zero minors, and every automated check it relied on had to be shown failing on a deliberately broken build before it was trusted. The project had already shipped one check that could not fail, which is worse than having none, because it reads as coverage.

A tool can hold a role. It cannot hold accountability.

Even with all of that in place, the most useful lesson from that project was about the limit. A check can make a problem visible, detectable and cheap to undo. It cannot make the call. Somebody still has to own the decision, and on that project, one of them was the client's, recorded with my objection attached.

A test for anyone doing six jobs

If you have absorbed several functions into yourself or into one tool, here is a quick test. For each one, answer two questions.

Who, or what, is able to tell you no? Not "who could, in theory, review it". What in your current setup will actually stop a bad output before it ships?

And when did it last do so? A reviewer that never objects is not a reviewer. It is a formality with a calendar invite.

If the answer to the first question is "me", for five of the six, you do not have leverage. You have a single point of failure with excellent output.

What is being called leverage

That is what is being called leverage right now, and it is not leverage. It is one judgement covering six functions, with nothing left in the system that can tell it no.

The fix is not to hire everyone back. It is to keep the roles, even when there is no longer a person in each one, and to make sure at least one of them exists purely to disagree with you.