- AI
- Development
Two years of AI-powered software development: what held up and what shifted
November 4 — 2026
In November 2024, we published a piece taking a bold stance at Mirego: rolling out generative AI development tools across all our projects and for every single client. A year later, in October 2025, we took stock of what we had learned, the results we were seeing, and where we saw things heading.
Fast-forward to November 2026, and the landscape has shifted yet again. Over the past two years, we’ve taken some pretty firm public positions on how we intend to use AI. Now, it’s time for a reality check.
Let’s get one thing out of the way: we don’t have all the answers. Just like the rest of the industry, we’re still figuring out what software development will truly look like a few years down the road. But we aren’t waiting around for someone else to hand us the playbook: we’re out there writing it ourselves.
Looking back at our past claims
Three statements from our previous articles are worth revisiting:
2024
“These tools don’t replace our development team members, they amplify their capabilities.”
2024
“Every line of code [in a project] is submitted by a developer, whether working with AI assistance or not.”
2025
“Rather than envisioning a future where developers act as ‘AI agent managers’ who coordinate a fleet of agents working in parallel […], our vision is more akin to that of surgeons.”
The first statement still holds up today. The second and third, however, have been seriously challenged this year. More on that shortly.
First, though, let’s address a topic we almost completely overlooked in our first two pieces.
A new challenge: the true cost of AI
In 2024 and 2025, we identified two main challenges: protecting the confidentiality of our clients' data and source code, and the risk of compromising the quality of what we deliver. Both still apply today. But in 2026, a third challenge has become impossible to ignore: the true cost of AI.
For a long time, cost was easy to overlook (and some still do). Subscriptions were flat-rate and often heavily subsidized by providers, while token usage remained marginal. With the rise of agents capable of handling tasks from A to Z (burning through millions of tokens along the way), those days are over.
We’ve learned an important lesson: cost per token doesn’t mean much. What really matters is cost per task.
A model that is half the price, but takes three iterations, makes questionable decisions, and requires an extra hour of code review isn’t half as expensive. It ends up costing far more. The flip side is also true: using the most powerful model on the market just to rename a variable or generate a config file is pure waste.
The true cost of a task includes:
the tokens consumed (including failed iterations);
the human time spent crafting the technical game plan;
the human time spent reviewing, fixing, and fine-tuning the output;
the comprehension debt that builds up when no one truly owns or understands the resulting code.
The example we shared in 2025 (spending six hours writing a game plan to generate the equivalent of fifteen days of development, only to spend another ten days fixing it manually) illustrates this perfectly: the token cost was negligible, but the true cost certainly wasn't.
The right model for the right task
Our 2024 article opened with the following statement: “We firmly believe that exceptional products are built using best-in-class tools.” We still stand behind that statement today. In 2026, however, the tool decision that has the biggest impact is no longer the code editor or even the agent. It’s the model selected for each task, paired with the harness built around it.
This is known as model routing. Instead of relying on a single model for everything, we route each task to the most appropriate model based on its complexity, criticality, and constraints:
Frontier models for planning, architecture, complex code analysis, and drafting technical game plans, where reasoning quality directly impacts everything downstream.
Faster, more cost-effective models for executing well-defined tasks: implementing a detailed plan, generating tests from existing examples, running migrations, and handling mechanical refactors.
Locally-run models hosted on our own machines or on-premises in our offices for clients with strict data sovereignty requirements, just as we mentioned back in 2024.
The surge in popularity, performance, and cost-efficiency of open-weight frontier models like GLM, DeekSeek, Qwen and Kimi has also significantly expanded our toolkit.
The recent emergence of System 1 models such as Jev, Clef and Clairic has also unlocked new ways to embed AI across our systems and workflows, in places where a full-scale LLM used to be too heavy or inefficient.
In short, the more options we have, the better equipped we are to make the right call.
Less human-in-the-loop, less ownership?
In 2026, the concept of a software factory (pipelines of agents capable of going from a spec to a pull request, or even all the way to deployment, with minimal human intervention) has moved from novelty to reality. We’ve started rolling it out across our projects. Despite our 2025 stance favoring the “surgeon” model, we would have been remiss not to explore it seriously.
Our findings so far are nuanced. For certain types of tasks (boilerplate code, repetitive migrations, dependency updates, test coverage), these approaches work remarkably well. For others, they raise questions we still don’t have definitive answers to.
Comprehension debt
Back in 2024, when discussing the redesign of La Ruche's platform, we explained how AI had helped us by “rapidly developing code ownership.”
Today, we’re facing the exact opposite question: the more we hand off end-to-end tasks to agents, the greater the risk of shipping code that works and passes every test, yet no one on the team truly understands. At the micro level (implementation), that’s probably negligible. But at the macro level (architecture), it’s a potential long-term issue, both technically and functionally.
Code review as a bottleneck
When writing code is no longer the constraint, human capacity to validate it becomes the bottleneck. Reviewing 2,000 lines of code generated in a matter of minutes doesn’t hold the same value as reviewing 200 lines written with clear intent.
Our SDLC processes backed by deterministic tools (static analysis, vulnerability scanning, automated testing) are more critical than ever, yet they are no substitute for true understanding.
We’re actively rethinking our code review principles to make sure every bit of effort (whether human or machine) is spent where it counts, and to figure out which trade-offs we can make to boost velocity without compromising the quality of what we ship.
The next generation of developers
In 2025, we pointed out that a developer’s judgment is becoming more valuable than ever. That brings up a question that weighs on us: how do early-career developers build that judgment if they are writing and reading less and less code themselves?
We don’t have a satisfying answer yet, but we refuse to pretend the question isn't there.
A renewed commitment
Our 2024 statement (“every line of code is submitted by a developer”) was true at the time. Today, it misses the bigger picture. Whether a piece of code was typed by a human or generated by an agent matters far less than this question: does a human understand it and stand behind it?
✦ The question is no longer who wrote the code, but who is accountable for it.
So here is our 2026 commitment for our client projects: every single change shipped in a Mirego project has a human who is accountable for it. We’re comfortable taking humans out of certain execution steps. We refuse to take them out of architecture, security, and product decisions.
Always learning
If the past two years have made one thing clear, it’s that no one (not us, not our peers, not even the model providers themselves) knows exactly where all of this is heading. Anyone who claims otherwise is probably trying to sell you something.
What we do know, though, is how we want to move forward: by innovating through experimentation. Innovation has always been what drives Mirego, and it needs to stay that way.
That means testing out new approaches, even when they challenge our past positions. It means putting them to work on real projects, taking the time to measure their true impact (both the upsides and the trade-offs), and having the humility to course-correct when the results aren't there.
✦ Two steps forward, assess the situation, one step back. Then do it all over again.
That’s exactly what we did this year with software factories and code reviews. And it’s what we’ll keep doing next year with whatever comes next.
Always towards the future
Today, in November 2026, our “surgeon” analogy still holds up, though it has evolved. Surgeons never work alone: they rely on a team around them to prep, assist, and take care of the steps that don’t require their specific expertise. Agents are now part of that team. The developer’s role still isn’t to manage them like a fleet, but to stay at the helm for the decisions that truly matter.
Through all the changes of the past two years, one thing hasn’t budged: our non-negotiable principle. We build high-quality products (both in terms of UI/UX and code maintainability) that make an impact.
No tool, model, or software factory should ever call this principle into question.
Subscribe to our newsletter
Get insights on tech trends, AI and development perspectives, plus our monthly digital news roundup.
