Tools: What a Hilariously Wrong Time Estimate Taught Me About the Future of Organizations

The Funniest Bug in AI ## The Training Data Paradox ## When Hours Replace Weeks, Everything Changes ## The Death of Technical Debt ## Dynamic Systems Need Dynamic Orchestration ## The Self-Accelerating Feedback Loop ## The Elephant in the Room ## The Organisational Consequence Here's something that made me laugh out loud last week. I asked an LLM to plan the upgrade of a legacy application — Frontend AngularJS 1.8 and Backend Java 11 — to a more modern stack: Angular 21 and Java 21 LTS. A bread-and-butter modernisation task I've seen dozens of times in banking and enterprise projects over the past five years. As any experienced vibe engineer would, I started with a deep analysis: mapping dependencies, creating nested AGENTS.md files throughout the codebase, feeding the LLM the full dependency graph and project structure until it understood the system as well as I did. The resulting migration plan was solid — breaking changes identified, a clear path from each AngularJS controller to standalone Angular components, Java module system accounted for, testing strategy included. Then I asked it to estimate how long this would take. Nine to twelve months, it said. With a dedicated team of three to four engineers. I almost spat out my coffee. Nine months? The tool that produced this plan could execute most of it autonomously — in weeks, not quarters. It was like asking a Formula 1 car how long it takes to cross town and getting an answer calibrated for a horse-drawn carriage. This isn't a bug. It's a time capsule. And it reveals something far more profound than a bad estimate. Large Language Models are trained on the accumulated knowledge of a world that didn't have Large Language Models. Every sprint retrospective, every Jira ticket, every project post-mortem in the training corpus reflects a reality where humans wrote every line of code, manually debugged every issue, and spent weeks on tasks that now take hours. When an LLM estimates a timeline, it's performing archaeology. It's averaging over thousands of human project histories where an AngularJS-to-Angular migration genuinely did take nine months or more — because we're talking about 100,000+ lines of plain JavaScript that need to become TypeScript, hundreds of modules rewritten from scratch, an entirely different component model, a Java runtime upgrade with breaking API changes, and a test suite that has to be rebuilt from the ground up. Anyone who's lived through one of these migrations knows: nine months is optimistic. The AI doesn't know it is the paradigm shift. It's a time traveller projecting the productivity of the past into the present. And that gap — between what the model estimates and what the model enables — is perhaps the most telling metric for the speed of transformation we're living through. This observation might seem like a curiosity, an amusing anecdote for a conference talk. But follow the logic for a moment. If a task that took three weeks now takes three hours, what happens to the nature of the output? Software that required weeks of engineering was precious. You maintained it. You refactored it. You accumulated technical debt because replacing it was too expensive. Entire consulting industries — modernisation, legacy migration, refactoring — exist because software was built to last and then outlived its usefulness. But what happens when building software costs roughly the same as describing what you want it to do? Software becomes disposable. Not in the pejorative sense — in the liberating sense. Software starts to behave less like architecture and more like language. When I say a sentence, I don't maintain it. I don't refactor it. I say what I need, it serves its purpose, and it's gone. If I need to say something different tomorrow, I say something different. This is the trajectory we're on. Software with a half-life of days, not decades. Applications that are conjured when needed and dissolved when they're not. Not all software, not yet — but an increasingly large share of it. Here's the radical consequence that most people haven't fully absorbed: if software is ephemeral, technical debt ceases to exist. Think about it. Technical debt is a metaphor borrowed from finance — you take shortcuts now and pay interest later through maintenance, bugs, and declining velocity. But debt only makes sense for assets you intend to keep. You don't accumulate "conversation debt" from a phone call last Tuesday. You don't worry about the architectural integrity of a Post-it note. When software has a half-life of days, the entire concept of technical debt becomes anachronistic. And with it, the billion-dollar industry built around managing it: legacy modernisation programmes, refactoring sprints, architectural review boards, the endless debates about whether to rewrite or migrate. This isn't speculation. I've seen it in practice. In a recent banking project, instead of spending weeks refactoring a problematic data pipeline — the kind of task I've spent years doing on OpenShift and Kubernetes platforms — we described the desired behaviour to an AI system and had a clean replacement running the same afternoon. The old pipeline wasn't migrated — it was replaced. Not because the old code was bad, but because describing what we wanted was cheaper than understanding and fixing what we had. When creation becomes cheaper than maintenance, you stop maintaining. You start describing. Now extend this logic beyond a single application. Imagine an organisation where not just individual scripts, but entire workflows, integrations, and business processes can be generated, tested, deployed, and retired in days rather than months. Such an organisation doesn't have a fixed IT landscape. It has a fluid one. Its software adapts to changing customer demands, market conditions, and regulatory requirements in near real-time. The competitive advantage isn't the software itself — it's the speed at which software can be created, deployed, and replaced. But here's the critical point: humans can't orchestrate systems that move this fast. When your software landscape reconfigures itself weekly, no human team can keep pace with approvals, reviews, and manual oversight. The orchestration layer must itself be intelligent, adaptive, and autonomous. The same way we don't manually manage TCP/IP packets or CPU scheduling, we won't manually manage the lifecycle of ephemeral software components. This has a fascinating implication for how we think about quality and trust. In the current world, we trust specific artefacts. This particular codebase has been reviewed by multiple engineers. This deployment passed 2,000 unit tests. This architecture has been battle-tested for three years. Trust is attached to the thing. In the disposable software world, you can't trust the artefact — it didn't exist yesterday and won't exist tomorrow. Instead, trust shifts to the generator. You trust the system that produces software, the same way you trust a compiler. Nobody reads machine code to verify that GCC did its job correctly. You trust the compiler because it has been validated against a rigorous test suite, and its output is predictable within known parameters. The question is no longer "Is this code good?" but "Is the system that produces this code reliable?" The companies that understand this will invest in quality gates, automated testing, monitoring, and validation of the AI system itself — not of its individual outputs. The ones that don't will find themselves running yesterday's software at tomorrow's pace. There's one more dimension to this that keeps me up at night — in a good way. Remember the original observation? LLMs estimate poorly because they were trained on pre-AI data. But what happens when the next generation of models is trained on data generated with AI assistance? Tasks that took weeks in the training data will take hours. The new models will calibrate accordingly. They'll estimate more accurately, work faster, and generate new training data that's even more compressed in time. This is a self-accelerating cycle. Each generation of AI tools produces data that makes the next generation faster, which produces data that makes the next generation faster still. We're not on a linear improvement curve — we're on an exponential one. And the funny time estimates we see today are simply the artefact of being at the inflection point, where the old world's data still dominates the new world's capabilities. "But wait," I hear the sceptics say. "If AI trains on AI-generated data, won't it just regurgitate mediocrity? Isn't synthetic data a dead end?" We've seen the answer to this question before — and it was decisive. In 2016, DeepMind's AlphaGo defeated world champion Lee Sedol at Go, trained on thousands of years of recorded human games. Impressive. Then in 2017, AlphaGo Zero was trained on nothing — no human games, only the rules. Within three days it rediscovered strategies that took humanity millennia to develop. Within forty days it surpassed every previous version. When it played against the version of AlphaGo that had defeated Lee Sedol — the one trained on all of human history — it won 100 games to 0. The system that learned from itself obliterated the system that learned from us. The common fear that AI training on AI output leads to degradation assumes human-generated data is the ceiling. AlphaGo Zero proved it's the floor. When a system understands the rules of a domain and can explore autonomously, it discovers solutions humans never considered. Current LLMs are still mostly in the AlphaGo phase — trained on the internet, on our collective history of doing things the slow way. But the transition to the AlphaGo Zero phase is already underway. Models that generate synthetic training data, evaluate their own outputs, and learn from self-play are no longer research papers — they're shipping products. Within a few training cycles, the funny time estimates won't just disappear. The AI won't just match our expectations — it will render them quaint. I can already hear the objection: "Sure, disposable software works for a dashboard. But what about banking? Healthcare? Critical infrastructure?" I've spent five years building ML platforms for the banking sector — under GDPR, BSI standards, and DORA. I don't take this objection lightly. I take it personally. And the honest answer is: even there. But the question isn't whether AI-generated software can be trusted in critical systems. The question is whether our current trust model — humans reviewing every artefact, signing off on every deployment — can keep pace with what's coming. It can't. And pretending otherwise doesn't protect anyone. It just ensures the transformation happens without governance. You don't make fire safe by pretending it doesn't exist. You build fire codes. The shift is from prescriptive regulation to goal-based regulation. Today's frameworks ask what you did: "Explain how this system made this decision." Tomorrow's must ask how you operate: "Demonstrate that your system reliably produces correct outcomes — and that you detect it when it doesn't." As a physicist, the mental model is clear to me. Boltzmann showed that you don't need to trace every molecule to understand a gas — you measure temperature, pressure, entropy. The same applies here: you certify the generator, not the generated. You monitor the system, not every output. You audit the process, not the artefact. This is what I tried to explain in an article published at heise.de. Regulation that prescribes the what will always lag behind the technology. Regulation that defines the goal and demands you demonstrate how you achieve it can evolve as fast as the systems it governs. One approach protects. The other becomes the bottleneck that holds an entire economy back. If software becomes disposable, why not organisational structures? Departments, teams, hierarchies, reporting lines — these are all static artefacts designed for a world where change was expensive. When change becomes nearly free, the rigidity of traditional org charts becomes a liability, not an asset. The AI-First organisation of the near future might not have a permanent IT department that waits six months for a project mandate. It might have fluid, purpose-driven structures that form around objectives and dissolve when the objective is met — just like its software. The humans in this organisation won't be defined by their role in a hierarchy, but by their ability to set direction, define intent, and orchestrate intelligent systems. We're already seeing this. A new generation of AI-First companies is reaching many millions in annual revenue with teams that would fit in a single conference room. The economics are staggering — and the numbers keep doubling before the ink dries on any article that tries to cite them. They don't have the headcount to maintain large codebases because they don't need to. Their software is as fluid as their teams. The only reason traditional, static organisations still dominate the landscape is inertia. We've built decades of trust, contracts, regulatory frameworks, and career paths around the assumption that change is expensive. That assumption is evaporating. The question isn't whether static organisations will adapt — it's whether they'll adapt before the inertia runs out. What happens after that, is even more intesting, buts that's a topic for the next sci-fi inspired article. The gap between what AI estimates and what AI enables is closing fast. When it closes, the world on the other side won't look like a faster version of this one. It will look like something genuinely new — where software is described, not built; where trust lives in systems, not artefacts; where the organisations that thrive are the ones fluid enough to keep up with their own tools. And if you're still sceptical: ask an LLM to estimate how long it would take to write this article. It'll probably say a week. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse