Opus Babies

The first genetic adaptation of the modern organisation is here. What effect will it have?

We started work on Rig in October 2025. For a few weeks, we worked in Cursor, using a mix of models, with plenty of manual editing of agent code. Occasionally we set two cursor agents running in parallel on short, well-scoped tasks. Then came the magnum opus. Claude’s Opus 4.5 appeared on November 24th. We have since completed 18 months’ of ‘old world’ development in 3 months. If you knew exactly what you wanted up front, you could compress 18 months into 18 days. If you aren’t in this world, and you think I’m exaggerating, I am not.

Our startup is amongst the first Opus Babies. That’s my term for the breed of startups born around the arrival of Opus 4.5. It fired the starter’s gun on practical AGI: a general intelligence that can independently execute complex work in a specific area. Where GPT-4 babies were AI-native, opus babies are AGI-native.

Opus babies will be the first major genetic adaptation of the modern organisation. They will think differently about almost every aspect of how we build our companies. The arrival of the desktop computer and the internet haven’t shifted the nature of an org chart. Since the dawn of time agile, startups coalesced into a divisional structure with 5-8 person product squads (PM, designer, devs, QA, analyst), dotted lines into engineering managers and VPs, large sales and marketing departments, and backoffice teams doing HR, Finance, and everything else (’Ops’). A corporate office today looks the same as the office in Mad Men, as Benedict Evans often points out - but minus the typists’ pool. As startups grow, they all fall foul of the scourge of all progress: “stakeholder management”, where you have to loop in various people from all these functions every time you want to add a webpage or change a price. Why? Because you’re reliant on 8 people who work on 5 different things to all be aware of the idea, ‘buy in’ (ie do some startup LARPing where you move post-its around a virtual whiteboard, claiming you deeply care about the ad-hoc ideas of every person present), and agree to help deliver the idea. Then you wait while they do all the joined-up work of CRM notifications, website changes, backend adjustments, blog posts and so on that are required for your price change.

Things feel different this time round. At Rig we’re working on a platform that helps people build agents that understand complex internal data. Automations are easy-ish, but understanding complex internal data is really hard. Even OpenAI find it hard, and had to tackle it in a novel way. We’ve spent a lot of time solving some of the hard parts of this on very large data warehouses in our careers, and now with our clients through Rig. We have a sense of how to tackle the problem.

But AI is moving fast. I recently read a blog post proclaiming (another) “better way” of orchestrating AI agents. There are many such posts, often from well-regarded developers. In the past, to test out an alternative technique to a technical problem, I’d have had to ask someone in my team to work on it, then wait a few weeks or months. I’m pretty technical, but would be the worst software developer on most teams if you read my code. But when I saw the blog, I put it into Claude Code, gave it a new branch to work on, and asked it to replace our orchestrator with the one proposed in the blog, then run both against a set of evaluation questions from a complex client dataset. I went to bed. The next morning I had a detailed side by side report. (Our agent won. On very simple questions, both were correct, but data context is an unsolvable problem for generalised agents.)

I felt this technical test was also a good marketing opportunity: side by side comparisons of technical approaches to problems are interesting! I wanted to share it. In the past, the domains were separate: a marketer or copywriter would have tried hard to understand what happened, but not be able to read the code. A developer might have tried to write it up in a technical blog, but not had time or appetite for the writing. So often, good internal engineering blogs dry up as companies get busy. And so, stakeholder alignment and quarterly planning and glue-people emerge to bridge these gaps. And from painful experience I can say they come fast, early, and make everything internally feel like some glue got into the system.

But Opus Babies don’t need much stakeholder management, or much glue. Having written the code, I also got Claude to draft a technical blog post detailing the two approaches and the results. It could even draw diagrams to include in the post to explain the architecture. Hell, it can animate them if I ask it to, then publish that post for me. I can now play the architect: conceive or discover the idea, give feedback, edit the piece, add tone of voice. That is fun, productive, energising work. It’s also a single-threaded, full-stack project, delivered by one person.

I’m not saying this to illustrate that Opus Babies will write software faster because they have Claude Code. They will. But everyone will. Older orgs will be slower to shift. A few die-hards will hang onto the idea of hand-writing code for a few months. Coding cargo cults and artisanal coding movements will spring up. I salute you! Maybe handcoding will become a hobby, like chess or knitting. But the last ship has sailed on an era of handwritten software. What I do believe is that the shape of the organisation will shift meaningfully, because the nature of matching talent to tasks is transforming. That genetic shift will be structurally obvious. Opus babies will be the Darwin’s finches of this era, adapting to the nature of their environment such that two startups working in two different industries will look less alike than the homogenous pre-AI generation.

Anyone who has led a product team knows the frustration of things not moving quickly, even in a small startup. Until now, engineering capacity was the ur-excuse for this: ‘we only have 12 points available’, ‘Backend dev Sarah is on AL’, ‘We need 47 points to add that button, it’s more complicated than you think’. I’m being glib, but if you know, you know. At the same time, we have all walked around startup offices watching people with their proverbial feet up. Product teams are often the chief offenders. They love ping pong. In my previous startup, to get an idea into reality, I would move it through what felt like an army assault course:

• Work with a designer to build a very simple no-code prototype.

• A user researcher would scrabble a few users together to poke at. No technical capacity was available.

• If ‘validated’, whatever that meant, move into the design and PRD phase. Here even in startups, ideas get crushed by committee; tech rules out X, design rules out Y, and suddenly you’re at 20% of the vision because it’s ‘in scope’

• 4 weeks becomes 6 weeks, and then 8 weeks later you have a slimmed down, incomplete version of the cool idea everyone started with

• Now something else has come up and the MVP lives on in the codebase forever, the vision has died

Everyone in that funnel was doing their job well. Tech resource always was limited. The PM usually had good reasons to cut back on an idea - if they didn’t, it would never see the light of day. And ‘CEO bombs’ - random ideas from the founder - can be catastrophic and must often be managed out of existence for the sake of focus. But historically, the inventions of highest quality and inventiveness came from single minds, or tightly-connected pairs. The PM-Designer-Dev team squad will soon become the oxbow lake of organisational design. Suddenly, the productivity is not blocked by the devs. The excuses are gone. Technical debt will grow, but agents can crush technical debt too, especially on startup-scale codebases. Once some technical debt is cleared and CIOs and CTOs let Claude Code and Cursor rip, momentum or lack thereof will now only have one blocker: indecision.

Opus babies have a much higher chance of survival as conditions change and new AI models burst the banks of our cognitive norms: the speed to pivot is much higher, pain to pivot much lower. Darwin’s finches evolved variously within their breed to enable efficient feeding on the range of cacti and plants on each of their islands. If older organisations without extremely strong brand or network effects want to make it, they need to cut a lot of fat and turn into finches. Otherwise they’re dodos.

Being a GPT-4 baby or a Sonnet baby, it’s probably fairly easy to rebirth yourself as an Opus baby, but even having a few employees in place who are not part of the Opus baby generation could make that transition challenging. It might even involve rebuilding the team again, but hiring truly AI-first workers. You’ll recognise them because, like my co-founder Jakub, they’ll be working from the command line in ways that sometimes look deranged. Need some slides? Command line. Need a contract? Command line. The command line may not end up being the right place to make slides - good UI takes away the hard work of explaining things to a chat box. But it’s indicative of the nature of an employee who will cut it in the Opus baby era.

Now think about how hard this genetic shift looks for a large organisation or enterprise. Maybe you work for one, and feel it. In every large enterprise there will be individuals automating away their work to spend more time on pleasure or the brave few automating work and then showcasing that internally to drive change. There will also be plentiful execs who put “AI leader” on their LinkedIn, but don’t drive the fundamental change needed to adapt. And it’s hard to do. The sheer anti-gravitational force required to transition a large enterprise into truly AGI-native work, the massive changes in the workforce, re-skilling, redundancies, and hiring of a new generation of talent who have built their skills AI-first, will be too shocking for most to endure.

It’ll sound callous, but the massive rounds of redundancies coming, when we look back, will seem like the managed burn of the Third Industrial Revolution, clearing old brush to allow more fire-adapted plants to grow. Some fire-resistant old trees will survive through it, too. I’m optimistic that it’ll also drive a new wave of economic growth - at least in nations that allow the burn. Some of that will be new digital roles. Some of that will be a transfer of workers into critical shortage roles in the community like teaching and care. Today, the U.S. are ahead of the world on this. Their talent moves fast in and out of companies, driving the twin benefits of cross-pollination of skills and ideas, and flexibility to hire marginal roles. For Europe, I’m fearful. Labour laws are already tight. The UK’s have recently tightened. I now weigh more heavily every hire, and will be more cautious and hire fewer people than we might in a looser labour environment. But there is a big opportunity for Europe too. Capital requirements for Opus Babies are much lower, because the largest cost item for any startup is heading to zero. We have a large, technically-inclined graduate base. Our economies are highly diversified.

But European nations, Britain included, need to now bite the bullet on matching or beating the flexibility of the labour market in the US. For Opus Babies, every incremental hire is a choice, not a necessity. In the ZIRP/Covid era, boasting about headcount was all the rage. Suddenly, it’s become trendier to boast about revenue per employee.

Barney, CEO of one of our early design partners, Cleo, shared their version of the chart recently. I’ll end on this, because he’s framed the opportunity for Opus Babies well. It’s easy to close one’s eyes to this, or to sit around saying that AI models will eat every task and job on earth. But while you do, Opus Babies have begun building.