<![CDATA[uRadical - Medium]]> https://medium.com/uradical?source=rss----8c79471753f4---4 https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.png uRadical - Medium https://medium.com/uradical?source=rss----8c79471753f4---4 Medium Wed, 20 May 2026 13:47:04 GMT <![CDATA[The Moat Is Gone]]> https://medium.com/uradical/the-moat-is-gone-06117e0e254a?source=rss----8c79471753f4---4 https://medium.com/p/06117e0e254a Mon, 18 May 2026 09:49:00 GMT 2026-05-18T09:48:59.931Z

Every software technology cycle has had an exploitation window — a period where inventors extract margin before commoditisation arrives. The window for centralised AI lasted less than three years. The commentators telling you this is all hype aren’t being cautious. They’re getting in the way.

The shape of the bet

  • $252B — global corporate AI investment in 2024, 13× higher than a decade ago. (Stanford HAI, 2025 AI Index)
  • 37.4% — of US workers now using GenAI at work; adoption ahead of PCs at the same stage. (St. Louis Fed, Nov 2025)
  • ~90% — cost reduction available running open-source models vs closed proprietary APIs. (California Management Review, Jan 2026)

The Window Is Closing Faster Than Anyone Expected

Every major software technology cycle follows the same arc. A genuine capability emerges. Early movers extract significant margin while barriers to replication are high. Then the window closes — open-source alternatives appear, the underlying capability commoditises, and pricing power collapses. The survivors aren’t the inventors. They’re the ones who used the window to build something at the application layer that couldn’t simply be forked.

What the current AI debate almost universally misses is how measurably that window has been shrinking with each cycle.

  • ~15 years — Windows Server licensing monopoly. Microsoft extracted extraordinary margin on server OS licensing from the late 1980s through the mid-2000s. It took Linux over a decade of steady improvement to make the pricing unjustifiable — and even then Microsoft survived only by pivoting to Azure, selling services on top of the commoditised layer.
  • ~5 years — Cloud pricing power. AWS built a dominant position post-2006, but meaningful price compression from Azure and GCP arrived within five years. The moat was software and operations expertise, not hardware distribution. Lower friction to replicate meant a shorter window.
  • ❤ years — Centralised AI. Already closing. DeepSeek matched frontier model performance at a fraction of training cost in early 2025. OpenAI publicly admitted it had been “on the wrong side of history” and released open weights by August 2025. Three years in. The window is closing in real time.

[Chart: The Shrinking Exploitation Window. Approximate years of meaningful pricing power before competitive commoditisation, per major software technology cycle. Each cycle is shorter than the last. Source: uRadical synthesis based on documented market history.]

This pattern is structural, not coincidental. Each new layer of commoditised technology becomes the foundation on which the next disruption moves faster. The baseline rises. The friction of replication falls. The window shrinks. Anyone betting on a 15-year AI moat is not analysing technology history — they’re extrapolating from a world that no longer exists.

For software, monetising invention is over. The replication cost has hit practical zero. AI-assisted development has compressed time-to-replication further still. No legal or technical moat outruns this. Durable value now lives entirely at the application layer.

Open Source Has Already Proved It

In January 2025, DeepSeek released R1 — open-source, MIT licensed, trained at a claimed fraction of frontier model costs, performing at or near OpenAI’s best offerings. Nvidia recorded a single-day market cap loss that made global headlines. Not because the technology failed. Because it worked so well, so cheaply, that the assumption of sustained centralised pricing power looked structurally unsound overnight.

By mid-2025, open-source models offered 70–90% cost reductions versus closed proprietary APIs across a wide range of tasks. The California Management Review drew directly on Christensen’s disruption framework: open-source LLMs are following the classic pathway — entering on cost advantage, improving rapidly through community innovation, and offering data sovereignty that closed models structurally cannot match.

[Chart: Closed vs Open-Source AI — Cost Per Million Output Tokens (logarithmic scale). Open-source deployment on owned hardware reduces marginal inference cost to near zero once hardware is amortised. This is the Linux dynamic repeating: not better on day one — cheaper enough, good enough, and infinitely forkable. Source: California Management Review, Jan 2026.]

OpenAI’s concession on open source in August 2025 is the Microsoft moment. The question now is whether they can find their Azure — a services and application business built on top of the commoditised capability — before the window closes entirely.

The Linux parallel is the right one and it runs deeper than most analysts acknowledge. Linux won. The kernel became ubiquitous infrastructure — free, community-maintained, and the actual profit surface moved entirely to the layers above and below it. Nobody charges for Linux. Everyone charges for what runs on or around Linux. The model weights are already out. You cannot un-open-source them. Llama, Mistral, Qwen, Gemma — these are already the kernel. The door is coming off its hinges.

The hardware layer is where that parallel becomes instructive about where durable profit actually lands. Red Hat took the money from Linux. IBM took Red Hat. But the more structurally interesting winners were the hardware manufacturers who built the machines Linux ran on. The same dynamic is forming now. Apple’s M-series chips are not incidentally suited to local inference — the unified memory architecture directly addresses the memory bandwidth constraint that kills LLM performance on conventional hardware. Apple largely solved that problem as a side effect of building chips for their own reasons. Combined with a billion-plus device distribution network, an installed user base that already trusts them with sensitive data, and a credible privacy story — on-device inference delivered without the user ever thinking about it — Apple is quietly one of the best-positioned companies in this entire transition. Not because they’re building frontier models. Because they’re building the substrate those models run on, in the hands of the people who will use them.

The Narrative Machine Is Running Hot

In April 2026, OpenAI published a 13-page paper titled “Industrial Policy for the Intelligence Age,” calling for a rethink of everything from the tax system to the working week to prepare for superintelligence. Sam Altman compared it to the New Deal in a subsequent interview. Critics called it what it is: comms work providing cover for regulatory nihilism.

Read the timing. The paper landed the same day The New Yorker published the results of an 18-month investigation into OpenAI that raised direct questions about Altman’s trustworthiness on AI safety. The juxtaposition was not accidental — someone with access timed the publication deliberately. The policy paper was the counter-programme.

OpenAI is the most interested party in how the regulatory conversation turns out. The proposals it advances shape an environment in which it operates with significant freedom under constraints it has largely helped define. A former Senate AI policy advisor noted that the “share prosperity broadly, mitigate risks, democratize access” framing has been the foundation of every major AI governance conversation since ChatGPT launched in 2022. It was said in Senate committee rooms in 2023. It was in OECD framework documents before that. None of it is new. The problem is not the ideas — it is the gap between naming solutions and building mechanisms to achieve them, combined with the fact that OpenAI has simultaneously been lobbying against the very safety legislation it now claims to support.

This is what the for-profit conversion actually signals. That was not a governance decision — it was a funding necessity. The capital structure required for a viable IPO does not exist inside a non-profit. The “New Deal” paper is pre-IPO narrative construction dressed as policy thinking.

Marc Andreessen claiming AGI has arrived is the investor-side version of the same problem. Andreessen has no technical standing to make that call. AGI has a contested definition that working researchers cannot agree on after decades of serious engagement with the question. Andreessen does not engage with that literature and does not need to — the financial press will not push back, and the claim serves the portfolio. His entire post-GPT-3 thesis was built on “AI is the last platform shift and we own the infrastructure layer.” That was a defensible bet in 2021. The problem is he has been adding to that position — financially, reputationally, politically — at every stage since. He cannot afford to be wrong. Declaring AGI is not analysis. It is collateral protection.

The political dimension makes it materially worse. Operating inside the current administration’s orbit means the AGI claim is no longer just investor narrative — it is policy-adjacent. If enough people with enough power accept that framing, regulatory frameworks get shaped around it, and the companies that shaped the premise benefit from the resulting environment. That is what regulatory nihilism looks like in practice — not absence of rules, but rules written by the people who needed them to be permissive.

The Hype Cycle Was the Real Damage

The bubble debate — is AI investment rational — is a legitimate question but it misses the more immediate damage. The hype cycle did not just inflate valuations. It actively poisoned the adoption curve.

Ordinary people and businesses heard “AGI is coming,” “your job is gone,” “superintelligence in 18 months” — repeatedly, from people with megaphones and apparent authority — and the rational response to that level of declared uncertainty is to wait and see. To not commit. To treat the entire category with suspicion. That scepticism is now load-bearing for the technology’s critics. Every legitimate use case gets tarred with the same brush as the circus around it.

The organic path would have been healthier and faster. Researchers and engineers quietly shipping things that worked. Capability improving incrementally. Trust building through demonstrated usefulness rather than declared civilisational importance. That is how databases matured. How the web matured. How containerisation matured. Nobody needed to claim Docker was a civilisational inflection point to get adoption — it solved a problem people actually had, and word spread.

Instead, the people who wrote the cheques and cultivated the access and manufactured the consensus — without building the substrate, without running the systems, without shipping a line of production code — ran the SoftBank playbook. Flood the zone with capital. Manufacture urgency. Corner the narrative. Extract before the cycle turns. It works for them financially while leaving wreckage behind.

The wreckage: real tools that genuinely help people are now culturally and politically contaminated. Enterprises that should be quietly integrating useful inference are running AI ethics committees that exist mainly to manage reputational exposure from the hype. Developers building real things have to disclaim and caveat constantly. And the workforce fear — amplified relentlessly because fear drives engagement — created genuine anxiety in people who had no tools to evaluate the claims. That is not a side effect. That is what happens when you weaponise a technology’s potential for investor narrative purposes, at scale, over years.

The tools are valid. They were always going to find their way into everyday life. The hype merchants made that journey longer and harder than it needed to be. Their obsessive self-serving was their own undoing — and an unnecessary tax on everyone else.

The Bubble Debate Is a Distraction

Yes, the financial risk is real. AI investment now represents a larger share of the economy than internet-related investment did at the dot-com peak. A correction is possible. But conflating financial bubble with technically invalid is the central error. The dot-com crash wiped out 78% of NASDAQ’s value. It did not wipe out the internet. Amazon fell 90% and became one of the most valuable companies in history.

Great technologies and great investments are not always the same thing, especially at euphoric valuations. The dot-com crash didn’t end the internet. It ended the companies that had no reason to exist.
— Edelweiss Capital, Dot-Com Bubble vs. the AI Boom, 2025

[Chart: The Dot-com Arc — Financial Crash, Technology Survived. NASDAQ Composite indexed with Amazon trajectory, 1995–2010. The companies with genuine application-layer value survived and compounded for decades. Source: Historical NASDAQ Composite data.]

If an AI financial correction comes, the open-source models, the trained engineers, the accumulated institutional knowledge — none of that disappears. The only question is who is positioned to use it.

The Adoption Data Is Not Ambiguous

GenAI work adoption reached 37.4% of US workers by late 2025 — already running ahead of PC adoption at the equivalent point in the 1980s. Workers using it save an average of 5.4% of work hours weekly; frequent users save over nine hours per week. Industries with higher AI time savings are recording 2.7 percentage points higher productivity growth versus their pre-pandemic trend.

[Chart: AI Adoption vs Historical Technology Diffusion. Percentage of workers using each technology for work, from mass-market launch. Generative AI is already running ahead of both PCs and the internet at the same point in their diffusion curves. Source: St. Louis Fed Real-Time Population Survey, Nov 2025.]

The macro GDP data is lagging, as it always does during foundational technology transitions. Robert Solow named this in 1987 — “you can see the computer age everywhere except in the productivity statistics.” The PC productivity revolution took another decade to appear in GDP data after he said that. The measurement problem is not the same as the capability problem. Every serious economist knows this. Most AI sceptics ignore it, because it removes their most cited data point.

The companies building institutional AI knowledge now — proprietary training data, fine-tuned models, integrated workflows, upskilled engineers — are compounding an advantage that won’t appear in any quarterly report until it’s too late for competitors to close the gap.

What This Means in Practice

The capability question has been answered. You are not evaluating whether AI is real — that debate is over. You are evaluating how quickly your organisation can move from the invention layer, where the moat is gone, to the application layer, where the moat is built on domain knowledge, customer understanding, and accumulated workflow intelligence that no open-source release can replicate overnight.

The profit surface in the next decade is clear: hardware that runs inference locally — Apple and whoever builds the next generation of edge silicon — and focused vertical applications with domain-specific training. Not general-purpose chat interfaces competing on benchmark scores. A solicitor’s tool trained on case law. A diagnostics assistant trained on clinical guidelines. A safety compliance platform that understands IEC 62443 and PUWER natively, not generically. The model is a component. The domain knowledge, the workflow integration, the trust built with a specific user base — that is the product. The API middlemen who built businesses on being the only door to capable models are watching that door come off its hinges.

We know this from building it, not just analysing it. Music Bingo Live — a real-time venue entertainment platform developed under the uRadical umbrella — would not have been financially viable without AI-assisted development. The platform required simultaneous depth across audio encoding and DRM, a real-time multiplayer sync engine, a venue-facing dashboard, music licensing integration, and a DJ-facing toolchain. Without AI, covering that surface area would have required a team too large and a timeline too long for the revenue model to work. The opportunity had a window. We built it with a fraction of the headcount that window would previously have demanded. That is not a productivity statistic. It is a product that exists because of a capability shift that makes certain things economically possible that simply weren’t before.

The real question for your organisation. It isn’t “is AI overhyped?” It’s: what would you build if the engineering headcount constraint was no longer the binding constraint? The answer to that question is where your application-layer moat starts. The organisations asking it now are 24 months ahead of the ones still reading bubble commentary — or waiting for Sam Altman’s New Deal to arrive.

[Chart: Global Corporate AI Investment — The Scale of the Bet. Global private AI investment 2014–2024. 13× growth in a decade. The window between invention and commoditisation is shrinking. Source: Stanford HAI, 2025 AI Index Report.]

The organisations that do this well in the next 24 months will be genuinely difficult to compete with in 2028. Not because they will own a model. Because they will own workflows, data, and institutional judgment that took two years to build.

On Ed Zitron

Ed Zitron runs a newsletter called “Where’s Your Ed At.” His background is public relations. He has built a large, profitable media operation by being the loudest and most consistent voice arguing that AI is an overhyped fraud perpetuated by tech industry grifters.

His PR background explains both his strengths and his hard limits. He is genuinely skilled at identifying narrative mechanics — how hype cycles are constructed, the incentive structures that produce breathless coverage, the pattern of tech industry promises that don’t land. These are real observations worth taking seriously on their own terms.

What a PR background does not qualify you to assess: whether a specific agentic coding workflow changes what a team of five engineers can ship in a sprint. Whether running a fine-tuned open-source model on your own infrastructure changes your cost structure. Whether the exploitation window for centralised AI is closing faster than the investment cycle assumes. These require being inside the work — running systems, measuring outputs, watching what actually changes when you remove the bottleneck of mechanical implementation.

The deeper problem is structural. Zitron’s audience wants confirmation that nothing needs to change. That’s what the product consistently delivers. The mechanism is identical to what he critiques in AI coverage — an engagement-optimised content operation calibrated to audience expectation rather than accurate prediction. His thesis is also conveniently unfalsifiable: if AI succeeds, it’s a bubble that will pop later; if it stumbles, he was right. This is not analysis. It is a position designed to never be threatened by evidence.

uRadical builds distributed systems, real-time platforms, and AI-integrated architecture for teams who have stopped debating whether AI is real and started asking what to build with it.
— uradical.io

If you’re a CTO, VP Engineering, or founder sitting on a product opportunity that was too expensive to build eighteen months ago — that constraint may already be gone. The window to build your application-layer advantage is open now. It will not stay open indefinitely. Start the conversation.

References

  1. Stanford HAI, “2025 AI Index Report,” 2025. hai.stanford.edu/ai-index/2025-ai-index-report
  2. Bick, Blandin, Deming, “The State of Generative AI Adoption in 2025,” Federal Reserve Bank of St. Louis, November 2025. stlouisfed.org
  3. Li, C., “The Coming Disruption: How Open-Source AI Will Challenge Closed-Model Giants,” California Management Review, January 2026. cmr.berkeley.edu
  4. Historical NASDAQ Composite data. Peak 5,048.62 on March 10, 2000; trough 1,114.11 by October 9, 2002.
  5. Quartz, “From Pets.com to Amazon: Companies That Died and Survived the Dot-Com Bubble,” March 2025.
  6. Barron’s, “Burning Up,” March 2000.
  7. Fortune, “AI Dot-Com Bubble Parallels History Explained,” September 2025. fortune.com
  8. Janus Henderson Investors, “AI vs. the Dotcom Bubble,” October 2025. janushenderson.com
  9. Al Jazeera, “IMF Says AI Investment Bubble Could Burst,” October 2025. aljazeera.com
  10. Dallas Federal Reserve, “Advances in AI Will Boost Productivity,” June 2025. dallasfed.org
  11. Penn Wharton Budget Model, “The Projected Impact of Generative AI on Future Productivity Growth,” September 2025. budgetmodel.wharton.upenn.edu
  12. Penn Wharton Budget Model, AI investment as share of GDP vs dot-com era comparison, September 2025.
  13. CNBC, “DeepSeek’s Breakthrough Emboldens Open-Source AI Models,” February 2025. cnbc.com
  14. FabriXAI, “OpenAI’s Open-Source Revolution,” 2025. Sam Altman “wrong side of history” from Reddit Q&A, August 2025. fabrixai.com

Originally published at uradical.io.

The Moat Is Gone was originally published in uRadical on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Slaying the Hydra: Why PM, PjM, and Engineer Was Always a Bureaucracy Engine — And AI Finally Kills…]]> https://medium.com/uradical/slaying-the-hydra-why-pm-pjm-and-engineer-was-always-a-bureaucracy-engine-and-ai-finally-kills-8b835b84d713?source=rss----8c79471753f4---4 https://medium.com/p/8b835b84d713 Wed, 13 May 2026 19:57:50 GMT 2026-05-13T19:57:49.495Z

Slaying the Hydra: Why PM, PjM, and Engineer Was Always a Bureaucracy Engine — And AI Finally Kills It

Slaying the Hydra: Why PM, PjM, and Engineer Was Always a Bureaucracy Engine — And AI Finally Kills It

And why the product-minded engineer is the only role that survives intact.

Product managers. Project managers. Engineers. Three roles, three headcounts, three calendars full of alignment meetings — and in the age of AI-assisted development, an increasingly hard structure to justify.

Here’s the uncomfortable truth the industry doesn’t want to hear: the product-minded engineer is the only role that survives the AI era intact. At uRadical, we’ve already made this bet — and we’re helping our clients do the same.

The Old World Made Sense (Once)

The traditional split existed for a reason. When shipping software meant months of coordinated effort across large teams, you needed someone to figure out what to build (product manager), someone to keep the trains running (project manager), and someone to actually build it (engineer). Each role required deep specialisation, and the interfaces between them — PRDs, Jira tickets, standups, retros — were the cost of doing business.

But that model was designed for a world where the bottleneck was engineering throughput. Writing code was slow, expensive, and required absolute focus. You couldn’t reasonably expect the person deep in a concurrent data pipeline to also be thinking about churn metrics and user onboarding flows.

That world is disappearing fast.

The Numbers Tell the Story

The data on how engineers actually spend their time is striking — and it reveals why the old role boundaries are ripe for collapse.

According to an IDC report published in early 2025, developers spend only 16% of their time on application development. The rest goes to operational tasks, security, CI/CD, monitoring, and everything else that isn’t writing code. Atlassian’s 2025 State of Developer Experience survey paints an even starker picture: 50% of developers report losing 10+ hours per week to non-coding tasks, and 90% lose 6 or more hours, largely due to organisational inefficiencies — not technical ones.

Meanwhile, Software.com’s Code Time Report, based on data from 250,000+ developers, found that the average developer actively writes code for just 52 minutes per day. That’s less than an hour of actual coding in an eight-hour workday.

  • 52 minutes — actual coding time per day (Software.com, 250K+ developers)
  • 16% — developer time spent on application development (IDC 2025)
  • 10+ hours — lost weekly to non-coding tasks for 50% of developers (Atlassian 2025)

So what are engineers doing with the other seven hours? Meetings. Slack. Jira. Waiting for approvals. Context switching. Translating product requirements. Aligning with PMs. Updating stakeholders. The organisational machinery that exists precisely because we’ve split product thinking from technical execution into separate roles.

Here’s the critical insight: AI coding tools don’t just speed up the 52 minutes of coding. They compress it so dramatically that the other seven hours become the real opportunity for transformation.

What AI Actually Changes

The AI productivity data is maturing fast, and the picture is nuanced but directional.

The 2025 Stack Overflow Developer Survey reports that 84% of developers are using or planning to use AI tools, up from 76% the prior year. 51% of professional developers now use AI tools daily. JetBrains’ 2025 Developer Ecosystem survey, covering over 24,000 developers, found that 85% regularly use AI tools for coding, with nearly nine out of ten saving at least an hour per week, and one in five saving eight or more hours — the equivalent of an entire working day.

  • 41% — of all code is now AI-generated (industry surveys, 2025)
  • 25% — of Google’s code is AI-assisted (Sundar Pichai, 2025)
  • 126% — more projects per week with GitHub Copilot

On the output side, 41% of all code written in 2025 is now AI-generated or AI-assisted. Google’s CEO Sundar Pichai has stated that 25% of Google’s code is AI-assisted. GitHub Copilot users report completing 126% more projects per week than those coding manually.

But here’s where it gets interesting. A rigorous randomised controlled trial by METR, published in July 2025, found that experienced open-source developers actually took 19% longer on tasks when using AI tools — despite believing they were 20% faster. The extra time came from reviewing, debugging, and correcting AI-generated code.

This isn’t a contradiction. It’s the whole point.

AI doesn’t eliminate the need for engineering skill — it shifts where that skill matters. The mechanical act of typing code is being automated. What remains — and what AI makes more important — is the ability to design systems, evaluate trade-offs, review output critically, and make judgment calls about what to build and why. These are precisely the skills that sit at the intersection of product thinking and technical architecture.

When you can describe an architecture to an agent and have it produce a working implementation in minutes rather than days, the bottleneck moves from “can we build this?” to “should we build this, and have we designed it correctly?”

And if that sounds like a product manager’s job description crossed with an architect’s, that’s exactly the point.

The Great Role Convergence Is Already Happening

This isn’t a theoretical prediction. The industry is already moving.

Airbnb’s restructure was the opening salvo. In 2023, CEO Brian Chesky announced that Airbnb had “gotten rid of the classic product management function,” merging PM with product marketing and elevating designers to equal partners with engineers. Chesky’s rationale was blunt: too many layers between strategy and execution create a game of telephone. Research backs this up — studies suggest that as few as 7% of employees can articulate their company’s strategic initiatives.

Shopify’s AI-first mandate took it further. In April 2025, CEO Tobi Lütke sent a company-wide memo declaring that “reflexive AI usage is now a baseline expectation at Shopify.” The headline policy: teams must now prove why AI can’t handle a task before requesting additional headcount. Lütke reported that employees leveraging AI have achieved “100X the work” on previously implausible tasks. AI competency is now formally part of Shopify’s performance reviews.

Microsoft’s May 2025 layoffs hit product management hard — 373 PM roles cut from Redmond alone, alongside 817 software engineering roles, as the company explicitly focused on “reducing managers.” This wasn’t a cost-cutting exercise in a struggling company; it came weeks after Microsoft reported sales and profits that beat expectations.

The pattern is clear: companies are cutting coordination roles and betting on fewer, more capable people augmented by AI.

The Uncomfortable Middle: Where PMs and PjMs Both Get Squeezed

Let’s be direct about what happens to traditional product managers and project managers in this new world.

The project manager faces the most obvious problem. When one product-minded engineer with AI tooling can do the work that previously required a team of three or four, there’s simply less to coordinate. The project manager is reduced to managing a person who is managing an agent — overhead on top of overhead.

The product manager faces a subtler but equally existential challenge. A PM who can’t engage with system design and technical trade-offs becomes an intermediary between the customer’s problem and the technical solution — writing requirements documents that an engineer then translates into prompts and architectural decisions. Every handoff is a lossy compression. The PM understands the user’s pain but can’t evaluate whether the proposed technical approach actually addresses it well. The engineer understands the constraints but has to rely on the PM’s interpretation of what the user needs. Two people, both holding half the picture, burning cycles on alignment.

Both roles end up in the same place: a layer of indirection between the problem and the solution.

Tom Smykowski, Office Space (1999) — inadvertently making the case for product-minded engineers since before it was a job title.

A single product-minded engineer holding the full picture? They can talk to a customer, understand the problem, sketch an architecture, guide an agent to implement it, and evaluate whether the result actually solves what it needed to solve. No handoff. No lossy translation. No alignment meeting.

The developer-to-PM ratio tells the story of where this is headed. Andrew Ng has suggested the ratio could soon flip to 2:1 (developers to PMs), compared to the previous norm of 1 PM to every 4–6 engineers. But that framing still assumes the roles remain separate. The more radical — and we’d argue correct — reading is that the ratio collapses entirely for small teams: one product-minded engineer replaces what previously required a PM, a project manager, and two to three additional engineers.

The Rise of the Lean AI-Native Team

The evidence for ultra-lean teams is no longer anecdotal — it’s structural.

  • Midjourney — ~$200M ARR with 11 employees
  • Cursor — ~$100M ARR with ~20 engineers, in under a year
  • Solo founders — 38% of US startups in 2024 (up from 22% in 2015)

Midjourney reached an estimated $200 million ARR with just 11 employees. Cursor, the AI code editor, soared to $100 million ARR in under a year with approximately 20 engineers. Sam Altman has publicly predicted the first “one-person billion-dollar company.” In 2024, 38% of US startups were founded by solo entrepreneurs, up from 22% in 2015, and an impressive 52.3% of successful startup exits were achieved by solo founders.

These aren’t flukes. They represent a structural shift in how much a single technically capable person can achieve when augmented by AI.

The rise of lean, AI-native startups hitting $10 million to over $100 million ARR with tiny teams isn’t a blip — it’s a structural shift. AI has replaced scale with smarts.
— Jaspreet Bindra, CEO, AI&Beyond

The World Economic Forum’s 2025 Jobs Report found that 41% of employers expect to downsize their workforce by 2030 due to technology. The companies that thrive won’t be the ones that simply cut headcount. They’ll be the ones that replace bloated role hierarchies with fewer, more capable people who own problems end-to-end.

What a Product-Minded Engineer Actually Looks Like

This isn’t about turning every engineer into a junior PM with commit access. It’s about recognising that the most effective people in AI-era software development combine capabilities that were previously spread across three roles:

They understand the problem space. They talk to users. They read support tickets. They grasp the business model. They know why something matters, not just what’s been specified. As Mixpanel Technical Lead Manager Sonya Park puts it: “The crux of being a product engineer is synthesising customer input to create a solution, while still maintaining a good return on investment.”

They design systems, not just features. They think in architectures, data flows, and failure modes. They make trade-offs between complexity and capability. They know when to build and when to buy. This is the skill that no PM and no AI agent can replace — the ability to hold a complete system model in your head and reason about its behaviour.

They guide AI effectively. This is the new craft. The METR study showed that experienced developers got slower with AI — not because AI is useless, but because they hadn’t yet optimised their workflow around it. The developers who thrive are those who know how to decompose problems, specify constraints, review AI-generated code critically, and iterate toward production-quality solutions. This requires more technical depth, not less.

They ship and evaluate. They deploy, measure, learn, iterate. They own the outcome end-to-end, not just the implementation. They don’t throw code over the wall to a PM to validate — they validate it themselves because they understand both the technical and product dimensions.

The Project Manager Was Already on Borrowed Time

Project management as a standalone role in small-to-medium software teams has been under pressure for years. Agile was supposed to distribute project management across the team. In practice, it often just renamed the project manager to “scrum master” and carried on.

But with AI compressing timelines and reducing team sizes, the coordination overhead that justified a dedicated project manager shrinks dramatically. When one person can do the work that previously required three or four engineers, there’s simply less to coordinate. The remaining coordination — prioritisation, stakeholder communication, timeline management — is well within the remit of a competent engineer who understands the product.

JetBrains’ 2025 survey data reinforces this: developers themselves highlight that 62% of non-technical factors are critical to their performance — internal collaboration, communication, and clarity. The best engineers are already doing this work. Giving them permission (and the title) to own it formally is the logical next step.

The Counterargument (And Why It’s Weakening)

The strongest argument for keeping roles separate is specialisation. A dedicated PM can spend all day on customer research, competitive analysis, and strategic thinking. An engineer splitting time between product thinking and implementation supposedly does both worse.

This was valid when implementation consumed 80% of an engineer’s time. But when AI handles increasing portions of implementation — 41% of code is already AI-generated, developers save 30–60% of their time on coding, testing, and documentation tasks — the engineer has the time for product thinking. The constraint that forced specialisation is dissolving.

The other argument is that some people are simply better at customer empathy and communication than at technical work (and vice versa). True — but this is an argument for hiring well-rounded people, not for structuring your org around the assumption that these skills can’t coexist in one person.

Developers spend only 20–40% of their time coding. The rest is spent analysing software problems and dealing with customer feedback, product strategy, and administrative tasks.
— Jue Wang, Partner, Bain & Company

These aren’t distractions from the engineering role — they are the engineering role, or at least they should be.

How uRadical Operates (And How We Can Help You Get There)

At uRadical, we didn’t arrive at this model through theory. We built it out of necessity and conviction.

Our team operates as product-minded engineers. We don’t employ separate product managers or project managers. Every person who works on a client project understands the customer problem, designs the technical solution, guides AI agents through implementation, and owns the outcome. We’ve built products like MyWelcomeBook.com (a multi-tenant SaaS for guest houses), envctl (a peer-to-peer secrets management tool with post-quantum encryption), and Music Bingo Live — each conceived, architected, and shipped by product engineers, not by committees.

The results speak for themselves: faster delivery, lower costs, and products that actually solve the problem they were designed to solve — because the person building them was never more than zero handoffs from the customer.

We help organisations make this transition. Whether you’re a startup that’s about to make your first hires, a scale-up drowning in coordination overhead, or an enterprise team that’s been told to “do more with less,” we can help you:

  • Restructure teams around product-minded engineers rather than role-based silos
  • Implement AI-augmented workflows that actually deliver on the productivity promise (not just install Copilot and hope)
  • Upskill existing engineers to think in product terms — customer empathy, business models, outcome measurement
  • Architect systems that are designed for AI-assisted development from the ground up
  • Reduce handoff overhead by designing processes where the person closest to the problem is empowered to solve it

We’re not selling a framework or a certification. We’re a technical partnership. We’ve done this ourselves, we’re doing it right now, and we can help you do it too.

The Bottom Line

The AI era doesn’t need more role specialisation. It needs fewer, more capable people who can hold the full picture: customer need, technical architecture, and implementation — all in one head.

Product managers who can’t engage technically will find themselves increasingly sidelined — reduced to managing people who are managing agents. Project managers in small teams will find their coordination overhead hard to justify when there’s less to coordinate. But engineers who understand their users, who can design systems and guide AI agents to build them, who can own outcomes end-to-end — they’ll be more valuable than ever.

The Hydra is dying. Every head you cut — every role you add — just grows two more coordination problems. Stop feeding it. The data confirms the alternative works. The market is pricing it in. The companies that adapt fastest will win.

Long live the product engineer.

uRadical builds products with product-minded engineers. We help organisations navigate the shift from role-based silos to lean, AI-augmented teams that ship faster and closer to the customer. Get in touch to talk about how we can help your team make the transition.

Sources & Further Reading

Originally published at uradical.io.

Slaying the Hydra: Why PM, PjM, and Engineer Was Always a Bureaucracy Engine — And AI Finally Kills… was originally published in uRadical on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>