On Saturday morning I burned through my entire Claude Design usage limit in three hours. In that time I built a presentable PowerPoint, two ready-to-go website redesigns, and an app mockup that would have passed as a launch announcement if I’d posted it.
While Claude was Designing, I ended up reading Toby Ord’s article about the “Hourly Costs for AI Agents” from December last year. His argument: at certain complexities, having an AI do what a human would do in an hour costs more than paying the human for the hour. The obvious reading is that AI is expensive labour. But cost-per-hour was never the full price of the human option.
Brooks’ The Mythical Man-Month from 1975 made the claim that adding people to a late software project makes it later, because communication overhead scales faster than the capacity you added. Adding a human isn’t just their hourly cost. It’s their hourly cost plus the coordination tax. For a team of one, that tax is zero. Even at per-hour price parity, an AI-leveraged hour and a human-team hour aren’t the same unit of labour. One carries coordination overhead. The other doesn’t.
This is a new thing. A team of one that produces at team scale has never meaningfully existed before. Solo founders were always bottlenecked by their own hands. Scale required more people, which meant Brooks’s tax. That tradeoff is becoming optional for a specific band of work.
What the hour contained
Pick any piece of work you do in a day and ask: does more time produce a better outcome?
Some work is time-elastic. More thinking, more iteration, more taste, and the result gets better up to a ceiling. Strategic framing. Design composition. Editorial judgment. Architectural choices. Sitting longer on a problem pays off.
Other work is time-inelastic. Once the quality bar is set, the output at 30 seconds is the same as the output at 30 minutes. Implementing a component to a spec. Turning out a first draft of something whose shape is already decided. Spending more time on execution doesn’t improve the output, it just takes longer.
Real work alternates between the two, often within the same task. With Claude Design, my loop had a lot in common with one I’d run with a human designer. I describe what I want. Claude builds. I look at it and think. I give comments. Claude iterates. I adjust. The thinking parts are time-elastic, and they take as long as they take. The building parts used to take hours of a designer’s day. With Claude they take a few minutes, and the output is just as useful.
The comparison isn’t clean. A designer would push back, have ideas, calibrate their taste against mine. Claude, especially in its Design iteration, does less of that, so the elastic work that used to be shared is now all mine.
Most of my hour with Claude Design was spent thinking. Claude’s time was spent on what used to fill a designer’s day.
That’s the test. Apply it to anything you do.
The 10x engineer of the AI era
This inevitably gets you thinking about the product trio, the most common shape for building software. A PM, a designer, an engineer, working together on one bet. The PM decides what to build, then writes the PRD. The designer makes taste calls, then produces mock-ups. The engineer chooses an architecture, then writes code.
AI increasingly removes the execution bits. You dictate the PRD, Claude drafts it. You describe the mock-up, Claude builds it. You direct the architecture, Claude writes the code.
This compresses the time each role spends on execution and removes the craft barrier between the roles. You can get a mock-up without knowing Figma, working code without knowing how to programme, a PRD without having drafted one before. What matters is judgment: whether the design is good, whether the architecture hangs together, whether this is what the customer actually needs. Everything shifts toward being the editor rather than the author.
For the right person, that opens up a new role. One person with enough taste, judgment and knowledge across PM, design, and engineering to direct AI output across all three, shipping at the scale a trio used to. People are calling it the super IC, and it is increasingly becoming the dream employee at a lot of companies, who imagine whole teams of individuals shipping by themselves, if you can call that a team.
These people exist, but they’re the 10x engineer of the AI era. Where the original was deep in one domain, the super IC is competent across three and orchestrates AI across them. Real, rare, high-leverage, and not a company-wide strategy. Most people aren’t 10x engineers either, and that’s mostly been fine.
More importantly, the super IC works best where the work is self-contained. Solo operators and founders. Small teams each on focused bets. A lot of day-to-day product work inside larger companies: redesigning an onboarding flow, launching a new feature within an existing product. Clean scope, one owner, not much cross-team entanglement.
The walls you hit
The team-of-one trick only works when the work actually fits one person. Most organisational work doesn’t. The moment you need multiple teams, coordination comes back, and with it, Brooks’s tax.
It’s coordinating with teams that have different priorities, working inside legacy code, getting political cover for decisions that affect people outside your team. None of that shrinks when one person can do more execution, and the super IC model loses steam the moment the work stops being self-contained.
The super IC also hits real individual limits. Director bandwidth is the first. One person directing parallel AI output across PM, design, and engineering work runs out of coherent context quickly. You lose the thread, taste drifts, decisions stop agreeing with each other. The Linear or JIRA equivalent for managing AI-directed work doesn’t exist yet, and most people can’t hold that much in their head at once.
The skill floor is the second. AI amplifies taste; it doesn’t create it. Without calibrated taste, the output will look fine to you and be mediocre, with no way to push it toward better. The bar to operate as a super IC isn’t “knows how to prompt.” It’s senior-level taste in two of PM, design, and engineering, plus enough judgment in the third to recognise bad output. The gap between “looks fine” and “is actually good” widens for anyone without the judgment to tell them apart.
The super IC has a gap to close on their own. The trio structure provides adversarial calibration by default: three tastes arguing, an idea forced to survive multiple perspectives before it ships. In super IC mode, you have to seek that calibration out, from colleagues, managers, anyone with the standing and the taste to push back usefully. A trio doesn’t necessarily produce better work. It produces different work. A single person with a strong opinion can drive something excellent; three people negotiating often produce something median. But nobody breaks out of their own local maxima alone.
The super IC also has to replace the team’s implicit error-catching with explicit process. A trio caught bugs through mutual review: different eyes on the same code, spec, and design. The super IC has to build those checks on purpose. Test-driven development, good reference documentation, using one AI to check another’s output. What the trio provided as a side effect of being a trio, the super IC has to engineer.
The quieter shift
Some companies will find super ICs and get an edge. Most won’t. Most of what product work actually is, the coordination and negotiation and legacy and stakeholder work, doesn’t change because the super IC exists. That’s fine.
But even in companies where the trios remain, the work inside them will change. PMs will draft their own mock-ups. Designers will code prototypes. Engineers will try their hand at rough design. The craft barrier dissolves not just for the solo super IC; it dissolves for anyone who wants to reach one step into an adjacent role.
What my Saturday morning with Claude Design actually showed was what AI does when the work is self-contained: a clean problem, one person’s judgment, no stakeholders in the loop. The super IC effect is real on that band of work. It quietly disappears where it isn’t. The mythical man-month is still mythical. Brooks is still right. You just get to dodge him on the narrow band of work where one person is actually enough.