Intuition Is the New Headcount

For the last decade, building software meant assembling specialists. Front-end engineers, back-end engineers, mobile developers, QA testers, project managers, product managers, designers — each one carrying a narrowly defined piece of the puzzle. The more complex the project, the larger the team. That was the formula.

That formula is dead.

It didn’t die slowly. It tipped over in about three months. Somewhere between late 2025 and now, the cost of execution specificity collapsed. The things that once required six or seven distinct roles — writing code across platforms, designing interfaces, testing edge cases, managing scope — can now be expressed in English and executed by AI. The specific skill of doing the thing is no longer scarce. What’s scarce is knowing which thing to do and why.

This changes everything about how teams should be built, how projects should be staffed, and how companies should be started. I’ve been thinking about this deeply, because at Variant Systems, clients ask us every week: what does the right team look like?

Here’s my answer. It’s three people.

The death of headcount, the rise of judgment

The old model sold hours and bodies. Need a mobile app? That’s two mobile engineers, a back-end engineer, a designer, a PM, and a QA — six people minimum, probably more. The value proposition was: we have people who can do things you can’t.

That value proposition has evaporated. AI can now wear every one of those hats. Not perfectly, not without guidance — but competently enough that the gap between “specialist on your team” and “AI with good direction” has narrowed to almost nothing for a huge surface area of execution work.

So what’s left? What can’t be replaced?

Intuition.

Not knowledge — AI has more of that than any human. Not skill — AI can write, design, test, and ship. What AI cannot do is carry fifteen years of scar tissue. It hasn’t lived through the production outage at 2 AM that taught you never to trust that particular abstraction. It hasn’t watched a beautifully designed product fail because nobody thought about the user’s second visit. It hasn’t seen a perfectly scoped roadmap collapse because the team built features in the wrong order.

Intuition — the kind earned through years of building, breaking, and rebuilding — is now the highest-value asset in software. And you need exactly three kinds of it.

The Architect: engineering intuition

The first person is a seasoned software engineer. Not someone who can write code — AI writes code. This is someone who knew engineering before it became accessible through natural language. Someone who understands what’s happening under the hood and, more importantly, has a feel for what’s going to go wrong.

Their superpower isn’t technical skill. It’s foresight built on hindsight.

Fifteen years of shipping software gives you something no model can replicate: a pattern library of failures. You’ve seen the database design that looked clean but couldn’t scale. You’ve seen the microservice architecture that created more problems than it solved. You’ve seen the “quick fix” that became permanent infrastructure.

The Architect’s job is to set technical direction with the confidence that comes from experience. They’re the person who says “don’t do it that way” and is right often enough that the team trusts the instinct even when the reasoning isn’t fully articulated yet. In a world where AI can generate any solution, knowing which solutions are actually good is the differentiator.

Who fits here: Senior and staff engineers with 10+ years of shipping production systems. The kind of person who’s been on-call, who’s debugged cascading failures, who’s inherited someone else’s architecture and had to live with it. Full-stack generalists outperform deep specialists in this role — because the job isn’t to be the best at any one technology, it’s to see the whole board.

How to get in: Stop optimising for knowing more frameworks and start building a catalogue of decisions and consequences. Document the architectural calls you’ve made and what happened. Develop opinions about systems design that you can defend from experience, not theory. The engineers who will thrive as Architects are the ones who can explain why something failed, not just how to fix it.

The Designer: experience intuition

The second person is a product designer — but not in the way that role has traditionally been defined.

Design, like engineering, has been commoditised at the execution layer. AI can produce interfaces, generate wireframes, build in Figma. The act of designing is now expressible in English. So what’s the designer’s role?

Here’s the reframe: design was never about Figma. Figma was the medium. The real skill — the one that survives every tool change — is taking a problem and making the solution feel intuitive. It’s understanding friction, delight, and flow at a level that goes beyond pixels.

But here’s what most people miss: tools unlock access. Taste turns access into something worth experiencing.

Everyone now has access to the same AI-powered execution. Everyone can generate screens, components, layouts. The differentiator isn’t who can produce the most — it’s who can feel when something isn’t right and know how to fix it. That’s taste. And taste is earned, not prompted.

Because taste dictates execution, it fundamentally changes when design happens in the development process. At Variant Systems, we flipped the traditional cycle entirely:

• UI design is the last step, not the first. Spec-complete products get built in days, backed by test suites that make iteration cheap.
• Everyone uses the product early — clients included. Feedback isn’t a phase; it’s continuous.
• Only when the product feels right do we move into polished UI. The AI already understands every screen and workflow by then.
• Collaboration evolves into a design system, a component library, shared patterns. Agent swarms parallelise implementation.

This is why designers remain essential even in a world moving beyond traditional UI. If every interaction becomes agentic — humans talking to AI, agents talking to agents — someone still needs to imagine the journey. Someone needs to define what “arriving at the destination” feels like. That’s design thinking, and it’s independent of any tool or medium.

Who fits here: Designers who’ve always cared more about why something works than how it looks. People who prototype in code, who get restless with static mockups, who think in systems and flows rather than individual screens. The best candidates often come from interaction design, service design, or UX research backgrounds — anywhere the focus was on understanding human behaviour rather than pushing pixels.

How to get in: Learn to build. Not to become an engineer, but to close the gap between imagining and making. Get comfortable with AI coding tools — they’re your new production pipeline. More importantly, develop your taste. Use products obsessively. Articulate why something feels right or wrong. The designers who win in this era are the ones who can say “this isn’t it yet” and be consistently right about what to change.

The Agentic PM: prioritisation intuition

The third person might be the most important, and they come from the most unexpected background: software testing.

Here’s the logic. We are now in an era of execution abundance. Imagine having 10,000 capable people who could build 10,000 things for you simultaneously. That’s what AI tooling represents — Claude, Codex, and the rest of the ecosystem. The bottleneck is no longer can we build it? The bottleneck is should we build it, and in what order?

Prioritisation becomes the highest-leverage activity in a world of infinite execution capacity. And the people best equipped for this aren’t traditional product managers. They’re people who spent years in QA and testing, who have now evolved into what I’d call Agentic PMs.

Why QA? Because testers developed a cognitive habit that’s extraordinarily valuable: they look at something and instinctively ask, how does this break? They approach problems with a fundamentally different eye than builders. They stress-test assumptions. They find the failure modes that optimistic builders miss.

This isn’t theory. At Variant Systems, hiring QA professionals and helping them transition into PM roles has been our quiet cheat code for two years. While the industry debated whether product management was dying, we were watching former testers thrive — because the same instinct that made them exceptional at finding bugs made them exceptional at finding flaws in strategy. They don’t just ask “what should we build?” They ask “what breaks if we build this first?” and “what are we assuming that we haven’t validated?” That adversarial clarity, applied to roadmaps and go-to-market decisions, is devastatingly effective.

Combine that intuition with first-principles thinking about what to build, when to build it, and how to go to market — and you get someone uniquely suited to direct massive execution capacity. They own the entire execution strategy: what to build, what to skip, when to ship, how to sequence. They are the person who prevents the team from building the wrong thing really efficiently.

Who fits here: QA engineers and test leads who’ve always thought beyond test cases — the ones who questioned requirements, pushed back on specs, and understood the product better than anyone on the team. Also: technical project managers, scrum masters, and delivery leads who found themselves gravitating toward what to build rather than just how to ship it. The common thread is adversarial thinking combined with product empathy.

How to get in: Start owning outcomes, not just outputs. If you’re in QA, begin framing your bug reports as product insights — not “this button is broken” but “this flow doesn’t account for the user who arrives from X.” Learn to write specs, not just test plans. Study go-to-market strategy. The gap between “I found the problem” and “here’s what we should do about it” is exactly the gap you need to close.

Why three is the number

This isn’t about minimalism for its own sake. Three works because of what it eliminates.

No handoffs. The old model was plagued by information loss at every transition — PM to designer, designer to engineer, engineer to QA. Each handoff was a game of telephone. Three people with overlapping awareness and shared context means nothing gets lost in translation.

No coordination overhead. Brooks’s Law told us decades ago that adding people to a project makes it slower. Communication channels grow quadratically. Three people can sit in a room — or a bar — and make every decision in real time.

Maximum judgment density. Instead of spreading experienced people thin across a large team, you concentrate the deepest possible intuition into the smallest possible group, amplified by AI’s execution capacity. Every person on the team is operating at the highest level of their domain.

A three-person team with AI tooling doesn’t just match a traditional team of ten. In many cases, it outperforms one — because the judgment is more concentrated, the communication is tighter, and there’s no dilution of vision.

The founding archetype

Zoom out, and this isn’t just a team structure for client projects. It’s a founding archetype for the next generation of companies.

The old startup formula was two engineers and a business person in a garage. The new one is an Architect, a Designer, and an Agentic PM walking into a bar. Each carries a decade or more of pattern-matched intuition. Each can now execute at a scale that previously required raising a seed round and hiring fifteen people.

Three people with deep judgment, a shared vision, and access to AI-powered execution. That’s a company.

This is the era we’ve entered. Not the era of bigger teams with more tools. The era of smaller teams with better instincts.