Six months ago I was firmly in the sceptic camp. I’d tried using LLMs for development work and the results were interesting but not really useful. Impressive party tricks, not practical tools. I still have not got Gemini to complete a single task satisfactorily.
So what changed? Orchestrators.
I refuse to call this AI
Before I go any further, let me get this out of the way. I’m not going to call this “AI”. An LLM is a type of AI, sure, but “AI” carries a much wider connotation. It implies intelligence, agency, understanding. An LLM is a tool. A remarkably powerful tool, but a tool nonetheless. Calling it AI confuses us into thinking about it wrong, and names matter. When you call a hammer “AI” you start expecting it to know where the nails go.
I use LLMs. I don’t have an AI. Let’s move on.
Developers are lazy, and that’s the point
Good developers have always been lazy. Not “doesn’t do the work” lazy; “refuses to do the same thing twice” lazy. We write scripts to automate tasks. We build abstractions to avoid repetition. We spend three hours writing a tool that saves us twenty minutes, because the twenty minutes was boring and the three hours was interesting.
LLMs are the ultimate expression of developer laziness. I’d estimate that 90% of the time I’ve spent actually writing code over the years has been writing the same REST CRUD backend API for yet another website. There are plenty of frameworks that promise to help with this, but none of them actually save time by the time I’ve crawled up the learning curve, and most involve vast amounts of magic (looking at you, Rails) that shrivels my soul. Getting an LLM to write the boring bits is saving me from doing this yet a-fucking-gain.
And that’s genuinely good. Not because it makes me faster, although it does. Because it lets me focus on what actually matters.
What to build, not how to build it
I’ve spent 30+ years focusing on how to build software products. Because that was the bit that only I could do, and making bad choices when doing that could cost me weeks or even months of time. I’ve mostly followed along when deciding what to build, and that’s been a huge mistake a few times. I worked on good architecture, on making sure we had the right amount of tech debt. Of validating other people’s PRs and making sure they were doing what I would have done. Days spent arguing about whether the repository pattern was actually saving us time, or just a pointless thing we did because we “should” do it.
Not looking at the code has been really hard. Throwing away all that experience and knowledge is difficult. Moving from “I own the code” to “the LLM owns the code, I verify the product” has been a nightmare. But good. I don’t check that the compiler turns my Go code into the proper machine code. I now don’t check that the LLM turns my product spec into the proper Go code. Trust but verify; check that it does what it should be doing, and if not get it to go back and rewrite. Make sure it keeps the test suite up to date. Make sure it actually runs the fucking tests.
But also freeing. I don’t have to worry about the architecture any more. I can focus on what I’m building, and why.
It’s not about code, it’s about orchestration
Here’s where my thinking has changed most. Six months ago, I was evaluating LLMs as code-writing tools. Could ChatGPT write a React component? Could Claude build an API endpoint? Sometimes yes, sometimes no, often with subtle bugs that took longer to find than writing it myself would have.
That framing has changed. It’s no longer about an LLM writing code. It’s about an orchestration tool coordinating teams of LLM agents. One writes code. Another tests it. Another verifies it against the spec. Another reviews it. The orchestrator manages the workflow, catches failures, retries with better context.
I’ve been using two orchestrators that actually work for me, so far: Superpowers and Ralph. Both take fundamentally different approaches but both deliver the same thing: a coordinated workflow where multiple LLM instances collaborate on a task, checking each other’s work.
This is the piece that turned me from sceptic to convert. A single LLM writing code is hit-and-miss, and I need to manage it like I’d manage a junior dev; I need to manage the context, make sure it’s not overwhelmed, make sure the task is clearly defined, check that the result tests OK, and that it matches the spec. It’s a lot of work that I have to do in there. A coordinated team of LLMs, with feedback loops and verification steps, is more manageable. I give it a whole thing to do, it goes and does it. I check that the thing is complete and does what I wanted it to do.
The afternoon rewrite
Here’s a concrete example. For my day job at Cogsflow, I needed a cashflow modelling tool for ecommerce merchants. I wrote the MVP myself in late 2023. It took me six weeks. It worked. It was fine. Pretty ugly, because I have zero design skills, but it was kinda cool: I compiled the calculation code into WASM using TinyGo, and called it from the website JS. It even created a graph SVG from raw Go code and passed that to the JS to embed in the HTML page. Like I said, it was cool. Kinda ugly, but really fast :)
I used both Superpowers and Ralph to rewrite it. Each one took an afternoon. And both produced versions that were better than mine. Less cool; just raw vanilla JS, no bells and whistles with WASM or tech. Both write SVG graphs into the HTML, because that’s a neat thing that you can do with vanilla HTML/JS/CSS. But not as cool as WASM. The designs for both were much, much, better than I can do.
Both of them were much more fit for purpose than my 6-week “cool” project. Not one of my prospective users gives a single shit about how cool WASM is, but they like the nice colours and spacing on the LLM versions. One of the versions even animates the graph drawing, and that attracted a specific positive comment. Users are magpies, they like the shiny things.
Am I a worse coder than an LLM? Obviously not. I wrote much better code. Am I a worse software product developer than an LLM? Maybe. I spent much longer writing a much worse version of the thing that the business needed. This is not up for debate; my version was technically better, but practically worse, than the LLM version.
Of course, there might be mistakes in the LLM version that I haven’t spotted yet, and it might have hallucinated whole chunks of functionality that I haven’t checked. But that’s also true of my code. And so far, so good. No obvious mistakes yet. And I’m pretty sure I can get the orchestrator to fix the project if we do find mistakes.
The full rewrite is now the best path
This leads to what might be the most counterintuitive shift. Every experienced developer has been burned by the full rewrite. It’s the thing you learn to avoid. Joel Spolsky wrote about it twenty years ago. You don’t rewrite from scratch; you iterate, you refactor, you improve incrementally.
That calculus has changed. I have never rewritten projects so many times from scratch as I have in the last few months. And it’s the right call almost every time. LLMs are spectacularly good at greenfield projects. Give them a clear spec and a blank canvas and they’ll produce something solid. Ask them to understand and modify an existing codebase and the results are much more mixed. This has a lot to do with context management and how LLMs operate, but to tell the truth every dev feels like this. A developer’s nightmare job is being handed an existing complex code base and being told to add or change a feature. The difference now is that a full rewrite takes an afternoon not three months. I can get the LLM to rewrite the whole system in a fraction of the time it would take me to understand where the last one went wrong.
So the workflow has become: build it, use it, figure out what’s wrong with the approach, and then rewrite it from scratch with better requirements. The insight gained from the first version is the valuable part. The code is disposable. This is fucking life-changing. I’m treating the prompt like I’d treat source code. Compile it, see where it breaks, change it, recompile it. And the prompt looks like a product spec, with a few scattered architectural and technical hints thrown in.
No more dependency hell
Here’s another piece of conventional wisdom that’s due for a rethink. Modern development has built up a massive ecosystem of packages and libraries, for every language, that provide ready-made tested code that can be imported to save time. There’s a whole meme about modern JavaScript developers being plumbers, just piping chunks of pre-built code together.
But dependencies are a liability. Every one is a supply-chain attack vector. Every one is a maintenance burden, a version to keep current, a breaking change waiting to happen. As a Go developer I was always seeking to minimise them because that’s idiomatic for Go; every dependency is treated as a problem, and gophers only use them if we must.
With an LLM writing the code, dependencies don’t save time any more. It’s just as easy for the LLM to write the actual functionality as it is for it to work out how to call a third-party library correctly. And the code it writes has no supply chain. No transitive dependencies. No maintainer who might lose interest or inject malware.
I deliberately specify “no external dependencies” in my prompts now. I think this is going to be significant for the industry. That huge pile of slowly-rotting open-source code on GitHub? Increasingly irrelevant. Not because it’s bad, but because the economics that created it, saving developer time, no longer apply when the developer isn’t writing the code.
Spotting when things go wrong
The skill that matters now isn’t writing code. It’s reading it. Specifically, it’s spotting when things have gone wrong.
LLMs are super confident. They produce plausible-looking code that compiles, runs, and passes the tests they wrote for it. But sometimes that code is subtly wrong, or it’s solving the wrong problem, or it’s taken an architectural path that will cause pain later. The orchestrators help, because verification steps catch a lot of this. But not all of it.
The job has shifted from writing to reviewing. From creating to curating. It’s understanding what good looks like so it’s obvious when this isn’t it. The experience doesn’t become irrelevant; it gets applied differently. And knowing if this iteration can be rescued; can I just fix this with a single prompt afterwards, or is it a rewrite with a better prompt as a start?
This month’s paradigm
Obviously this is a point-in-time observation, not a settled opinion. My views on LLMs were very different six months ago. They’ll probably be different again six months from now. The tooling is moving so fast that any strong claim about “how things are” is really just a claim about “how things are this month”.
But right now, in February 2026, this is where I’m at: this is the largest change in software development I’ve seen in my 30+ years doing this professionally. This changes everything. Using an LLM as a spicy autocomplete to help a single person write code is not the way. Using an orchestrator to manage teams of LLMs is the way. Prompts are the new source code.
Ask me again in another six months. I’ll probably tell you something completely different. But I know one thing will not change: I am never, ever, going back to writing fucking CRUD REST APIs by hand.