A 17-year-old with no technical background just exfiltrated 7 million records. Alone. No standups. No sprint planning. No delivery manager. The software industry has spent thirty years building process to manage coordination at scale. The scale is leaving. The process is staying. That's the problem.
Learn From the Crooks
This isn't a celebration. It's an autopsy. Because the most instructive case studies in small-team AI productivity right now aren't coming from Y Combinator or the pages of a business book — they're coming from police reports.
A 17-year-old with no coding background breached Kaikatsu Club, Japan's largest internet café chain. He extracted the personal data of over 7 million users. He did it alone. His motivation: Pokémon cards. His methodology: none.
Three teenagers — aged 14, 15, and 16 — with no coding background used ChatGPT to build a tool that hammered Rakuten Mobile's systems 220,000 times. They spent the proceeds on gaming consoles. No team lead. No retrospective. No blocked tickets.
A single actor using agentic AI ran an extortion campaign against 17 organisations in one month. He developed malicious code, organised stolen files, analysed financial records to calibrate demands, and drafted the extortion emails. One person. One month. Seventeen targets. What would that have required in 2019? A team. Specialists. Coordination. Time.
The business literature wants its heroes to have suffered nobly — preferably while quoting Wu-Tang. Ben Horowitz performing street credibility from a Patagonia vest is the genre at its most honest. What it won't do is point at a teenager with no CS degree and say: he just demonstrated something your $4 million Agile transformation couldn't.
So let's do that instead.
The Historical Accident
Waterfall wasn't stupidity. It was a rational response to a real problem: software teams were getting larger and needed sequenced handoffs to function. You can't have fifty engineers committing to the same codebase without coordination. You need phases, gates, sign-offs. Waterfall solved for that. It was clunky, but it was solving the right problem.
Agile was a rational response to Waterfall's brittleness when requirements changed mid-flight. It loosened the sequencing, broke work into smaller cycles, and introduced ceremonies to keep larger groups aligned continuously rather than at phase gates. Sensible. For the context it was designed for.
Here's what nobody said out loud: every Agile ceremony is a coordination protocol, not a productivity tool. The daily standup exists because without it, a team of twelve will diverge. Sprint planning exists because otherwise nobody knows what the other eight people are working on. The retrospective exists because at scale, problems compound silently before they surface. Scrum isn't a development framework. It's a distributed team communication system dressed up as one.
This distinction matters enormously because it means the entire methodology stack is load-bearing on one assumption: that you need many developers to build complex software. That assumption is cracking. Not at the edges — at the foundation.
The Coordination Tax Has a Due Date
Your engineering organisation has been paying a coordination tax for decades and calling it process. Standups, sprint planning, backlog grooming, story pointing, retrospectives, quarterly planning, PI planning if you're truly suffering — this is overhead. Necessary overhead, when you have fifteen engineers who would otherwise have no shared understanding of what's being built or why.
But overhead is only justified by the problem it solves. Shrink the problem and the overhead doesn't automatically shrink with it. It calcifies. It becomes culture. It acquires defenders. It gets a certification programme.
The Certified Scrum Master exists because large organisations need people to manage the coordination layer at scale. The SAFe framework — a baroque monument to the idea that enterprise Agile just needs more process — exists because the default response to coordination failure is more coordination infrastructure. Nobody in that industry has a financial incentive to tell you that the answer might be a smaller team.
The criminals didn't have a coordination layer. They had intent and tooling and they shipped. What took them days would have taken a professional team weeks — not because the professionals are less capable, but because the professionals are embedded in a system designed for a team size that no longer makes sense.
A lot of what we called engineering culture was coordination infrastructure with better branding. No-ship Fridays. Change advisory boards. The two-week sprint. The definition of done. Ceremonies with enough ritual to make the Vatican look improvised. They weren't evil. They were solving for scale. The scale is going. The ceremony is not.
The Product-Minded Engineer Wins
What replaces it isn't a new framework. It's a different kind of engineer.
A lot of what a product manager does is translation. Business intent arrives in one language, technical constraints exist in another, and someone has to bridge the gap — because the engineers weren't expected to hold business context, and the business people couldn't read technical risk. That translation layer required people, meetings, documents, and sign-offs.
A small team of engineers who own the product thinking don't need that translation layer. They're already holding both sides of the problem. They know why the thing exists, what it costs to operate, who it's for, and where the technical bodies are buried. The product manager role doesn't disappear because it was useless — it disappears because it's been absorbed.
This is the engineer that survives and thrives in the next decade. Not the specialist who knows one layer of the stack deeply and needs five other specialists to ship anything. The engineer who can go from problem to production with minimal help, who has taste and judgment, who understands the user, the economics, and the infrastructure simultaneously. AI handles the execution gap. Judgment remains human. And when people cite the AI horror stories — the deleted production database, the agent that went rogue — they're almost always misdiagnosing the problem. That's not an AI failure. That's a permissions failure, an environment isolation failure, an engineering hygiene failure that was always there. AI just executes faster, so the consequences arrive sooner. A product-minded engineer who thinks about blast radius and rollback doesn't make those mistakes with AI tooling any more than they'd make them without it.
Two or three people who respect each other and share a goal don't need Scrum to stay aligned. They talk. They adjust. They make decisions in the time it takes to type a message. The standup is the conversation they're already having. The retrospective is the ten-minute debrief after something breaks. The backlog is the running list in someone's head or a document nobody has to groom.
The implicit assumption behind every named methodology is that humans left to their own devices will fail to coordinate effectively — so you need a system to compensate. That assumption scales with team size. It does not apply universally. Small groups of capable people who've chosen to work together have always been able to self-organise without a system telling them how.
What small teams need isn't a framework. It's psychological safety to make decisions without three layers of approval. It's trust that the person next to you has the judgment to act without a process wrapper around every choice. It's the freedom to work the way humans actually work — asynchronously, messily, iteratively — without being forced to translate that into story points and velocity metrics for a dashboard nobody reads.
The most productive working relationships most engineers have ever had didn't look like Scrum. They looked like two people who understood a problem deeply, trusted each other's judgment, and had the freedom to move. That's not a methodology. That's just working well with people you respect. Let teams find their own flow. Be human about it.
The Roles That Go First
Let's be honest about what this means for employment, because the hand-holding and the Kumbaya isn't helping anyone. The argument that AI won't replace jobs — only change them — is a comfort blanket being sold by people with a financial interest in you not thinking too hard about it. Some jobs will go. The question is which ones and in what order.
The first to compress are the coordination roles. Not because the people in them are less capable, but because the structural need that created those roles is shrinking at the same rate that team sizes shrink. You cannot have a delivery manager delivering for a team of two. The math doesn't work.
The Scrum Master exists to manage ceremonies for large teams. Remove the large team and you've removed the job. Not reformed it — removed it. The Delivery Manager coordinates handoffs across specialists; when those specialists collapse into one or two people, there are no handoffs to coordinate. The Programme Manager manages coordination across multiple teams; fewer teams, smaller teams, less programme to manage. The Product Manager translates between business and engineering; a product-minded engineer who holds both domains simultaneously makes that translation role structurally redundant — not because the person was useless, but because the gap they were bridging has closed.
These aren't predictions. They're descriptions of what happens mechanically when you reduce team size. The roles were created by the problem. Solve the problem differently and the roles don't transform — they dissolve.
What survives is depth that can't be replicated by a model with a good prompt. Engineers who understand failure modes in regulated systems. People who can read a domain — energy, finance, healthcare — and know which constraints are legal, which are physical, and which are political. Architects who've seen enough production systems collapse to know what the diagram isn't showing. People who can identify what to build, not just execute the building of it. That's the defensible ground. Everything else is on notice.
The comfortable job — enough ceremony that you could coast on process compliance, enough people around you that accountability was diffuse, enough coordination overhead that nobody could tell exactly who produced what — that job is going. Not because employers are cruel, but because the structural conditions that created it are dissolving.
The New World Doesn't Wait
The criminals aren't waiting for the industry to catch up. The 17-year-old in Osaka didn't file a request to use AI tooling. He didn't wait for his organisation's AI governance policy to be ratified. He didn't attend a workshop on responsible adoption. He had intent, he had access, and he shipped — 7 million records, alone, for Pokémon cards. The single actor who ran extortion campaigns across 17 organisations in a month wasn't coordinating a team. He was executing with a focus and speed that most professional engineering organisations, buried in their own process, couldn't match on their best day.
That is the productivity floor. Set by people with no training, no domain knowledge, no legitimate infrastructure, and no methodology whatsoever. If that's what the floor looks like, what does the ceiling look like for a small team with deep domain expertise, real judgment, and the freedom to work without ceremony?
Nobody knows yet. But we're about to find out — and the organisations still running PI planning and SAFe transformations and six-week change advisory board cycles are not going to be the ones who discover it.
The coordination layer is not coming back. The ceremonies are over. The comfortable diffusion of accountability across large teams — enough people around you that nobody could tell exactly who produced what, enough process that velocity was always someone else's problem — that's gone. What replaces it is smaller, faster, and unambiguously accountable.
You wanted to know where the development jobs were going. Watch what the criminals are already doing. They got there first.