When AI Lets One Person Be PM, Designer, and Engineer, Who Pushes Back?

In February, I could not use a terminal, the command-line interface on a computer. After twelve days working with Claude, I had built a four-language website and a complete automation system. Work that would previously have required a dedicated engineer, I could now take on myself. (The record of those twelve days.)

But being able to build something raised a separate question: who would tell me if I was building in the wrong direction?

During those twelve days, I cut half of the first draft Claude wrote. I overturned the database structure it suggested twice. Every one of those decisions was mine. Being able to catch the errors you already understand, though, is not the same as being able to see the problems in territory you have never explored.

Among Thorsten Ball’s predictions about the future of software development, one stands out: the division of labor among product manager, designer, and engineer will disappear. It called to mind my own working pattern over these past months, with engineering, design, and product decisions increasingly handled by me and AI together.

His reasoning makes sense to me. But when three roles collapse into one, the person who used to sit across the table and push back may disappear along with them.

So who pushes back?

Can One Person Also Own All the Product Judgment?

On September 19, 2026, Thorsten Ball published sixteen beliefs about the future of software development.

The table below summarizes each point in order, preserving his tone about different predictions. These are his observations and judgments as of September 2026, not established industry conclusions.

This essay focuses on points 4, 5, and 10, shown in bold: the division of labor may change, product judgment still matters, and requirements themselves can be wrong.

Reading him carefully, I think the judgment he values has not disappeared. It is just that the person building the software now has to carry it alone. His other prediction is worth watching even more closely: in the future, many errors will come from asking for the wrong thing in the first place.

That made me realize: as one person can accomplish more, the responsibilities that used to be distributed across different people concentrate on that one person. From my own experience, some work genuinely no longer needs three people to hand off in sequence. But that is not yet enough evidence to say how much the three distinct roles will shrink across the industry.

What concerns me more: when the same person writes the proposal, does the building, and passes the judgment, what remains to signal that the direction is wrong?

What Were PM, Designer, and Engineer Each Blocking?

In The Four Big Risks, product advisor Marty Cagan divides product risk into four types, each carried primarily by one of the three roles. The PM covers two questions: whether anyone needs the product and whether it makes business sense. In plain terms:

• The PM asks: Will anyone use this, or pay for it? Does this make business sense?
• The designer asks: Can users understand it and figure out how to operate it?
• The engineer asks: Can we actually build this within the available time, with the technology and skills we have?

These four risks do not shrink just because the team does. A product that someone needs and that is easy to use may still collapse under maintenance costs too high to sustain.

There is another value in the division of labor, as I see it: different people advocate for different problems. An engineer may think it is buildable, but the designer points out users will not understand it. Once both are satisfied, the PM still has to ask: is it worth the investment?

When three seats become one, these arguments move inside a single head. It is hard to lose an argument against yourself. What tends to lose is the side you know least well, because the errors you do not understand are the ones you are least likely to speak up for.

If the Code Works, Why Can the Product Still Be Wrong?

Imagine you use AI to build a booking system. Dates are selectable, data is saved, notifications go out. Those features work as specified.

But customers may not want to create an account and choose to call instead. In that case, every feature works correctly, yet the product may still fail to solve the user’s actual problem.

Software engineering uses a distinction between verification and validation for exactly these two kinds of checks. Verification asks whether the product meets its specifications. Validation asks whether it meets the real need it was built to serve. Passing the first does not guarantee passing the second.

I have OpenAI’s Codex, xAI’s Grok, and Google’s Antigravity review Claude’s output, paired with testing, and I verify important facts against primary sources. I wrote about this workflow and the hard lessons behind it in Bigger AI Ambitions Need Error-Catching Infrastructure First. Multi-model review helps surface errors, but several models agreeing still does not make the result correct.

This is especially true for evaluating need. In a 2023 study, Anthropic found that five AI assistants it tested showed sycophantic behavior across four text-generation tasks, adjusting their outputs toward what the user seemed to want. That finding does not directly describe how any model performs today, but it is a reminder not to treat model agreement as evidence that a need is real.

When I wrote Beyond Man-Days in April, I put the AI collaboration assessment framework through adversarial debate across several models over three rounds of stress testing. The debate caught gaps in the argument. It could not answer whether anyone actually wanted to use it. That answer still had to come from users.

How Does “Pushback” Become a Real Test?

Proverbs 27:17 says: “Iron sharpens iron, and one person sharpens another.” We need others to sharpen us. But someone disagreeing does not mean they are right. The value of disagreement is that it surfaces problems worth examining.

Writing this, I think of Popper’s principle of falsifiability. For an idea to deserve belief, it must be exposed to the possibility of being refuted by reality.

Inviting pushback is not enough by itself. I need to first state clearly: who do I believe this product will help, with what problem? What result, if it appeared, would make me admit I was wrong? Then I release the work, let users try it, and let the results come back.

AI can help me generate more ideas and help me design tests. But when results fall short of expectations, deciding whether to change course remains my responsibility.

In the excerpt from Conjectures and Refutations available here, Popper discusses how scientific theories face testing. The attitude I carry into product work is this: state clearly what result would challenge your claim, take it seriously, and go test it. Not being refuted yet does not mean being right forever.

For example: if I believe a tool will let people complete a task faster, I should have users compare it against their existing method, counting time spent on learning and correcting errors. If it is not actually faster, I need to examine which assumption I got wrong. One poor test does not necessarily mean the entire direction is wrong, but it also cannot become an occasion to rationalize the original idea every time.

How Can One Person Keep Three Checks in Place?

Translated into day-to-day work, I start at three moments. Each time I write down the original judgment, what I observed, and what I will change next.

Before Building: Confirm the Problem Is Real

Write one sentence first: who am I helping, in what situation, with what difficulty? Then find someone who has genuinely encountered this problem and ask how they handled it last time, and where the friction was.

“Do you think this idea is good?” tends to invite polite encouragement. “How did you handle this last time you ran into it?” is more likely to bring back specific experience. If the person has never actually had this difficulty, adjust the need or the target user first. Do not rush to add features. AI can help organize interview notes, but the interviewee’s experience cannot be filled in by a model.

After the Minimal Version: Let Users Operate It Themselves

Get the product to the point where it can complete the one most important task. Confirm that it can operate safely within acceptable time and cost, then ask a user to try it. After describing the task, hold back the step-by-step instructions and watch where they pause, misread something, or give up.

This step stands in for the questions a designer would originally have raised: does the flow that seems obvious to you actually make sense to someone else? Where they get stuck, fix that spot, then ask someone to try again. Keep records of both functional testing and what you observe during real use.

Before Investing Further: Step Back and Ask Whether It Is Worth Continuing

Before the trial, decide what results you will observe and over what timeframe. Depending on what the product does, you might watch whether task time decreases, whether users return to it when the need comes up again, and, if this is a business, whether anyone actually pays and whether service and maintenance costs are sustainable.

Bring those results to someone not involved in building it, someone willing to point out problems, and ask them to press you: “Is the current evidence enough to justify investing more?” They do not need to make the decision for you, but they can help you notice when you are quietly moving the goalposts and framing missed targets as unimportant.

If the evidence is thin, narrow the scope and test again. If the need proves not to exist, change direction or stop. These three checks provide a basis for adjustment. They do not guarantee the product will succeed.

My Own Flag in the Ground

Thorsten put his predictions in public writing, leaving them for the future to answer. I want to leave a record of my working principle at this moment: the more one person can accomplish, the more I need to build in chances for my own judgment to be overturned.

AI makes it easier for me to turn an idea into something real. I owe it to myself to preserve the chance to discover that the idea may not have been worth building.

You can also browse the Intelligence and Order topic page for other articles in this series.