Why AI revolutionised software development: anatomy of a three-week turn

The AI revolution in software development is often presented as a matter of typing speed. That is the most visible angle, and the least interesting. What has really changed fits in one sentence: the cost of change has collapsed, and when the cost of change collapses, it is not productivity that moves, it is the architecture of decisions.

We have a dated demonstration of it, on a project we have been running for two years: the BuyStep platform. Between 24 March and 12 April 2026, it changed its framework, its database, its front end and its back office. Three weeks. Two years earlier, the same project had taken four months to get rid of a purchased e-commerce theme. Here is what separates the two.

Before: the cost of change dictated the architecture #

BuyStep's first year looks like many first years. Commits are written by hand, in French, often in a hurry. The timestamps speak for themselves: thirty-five of the thirty-nine commits in December 2024 were pushed between 10 pm and 6 am; twenty-four out of twenty-nine in January 2025; forty-three out of eighty-three in March 2025.

Traces of what a change costs are everywhere. The database migrations are reset four times between December 2024 and October 2025; the fourth deletes 54 files in one go. In June 2025, a test suite is removed from the repository because it is “no longer maintained”. In January 2026, the tests and the quality analysis are temporarily disabled in the pipeline. Each of these decisions is rational taken on its own; together, they describe a team paying a high price for change and cutting corners wherever it can.

Three dated markers of AI entering the repository #

AI does not arrive with an announcement but through files. Three dates, all verifiable in the history:

• June 2025: a .cursorrules file. The first visible AI tooling. At this stage, assistance is a typing aid: it suggests lines, never an architecture. The repository contains nothing else from it.
• October 2025: an instructions file, a configuration folder, a first agent. The repository gains a CLAUDE.md, a .claude/ directory and a first specialised agent (unit-test-fixer). The same month, configuration moves to environment variables, the application is dockerised, the migrations are rebuilt from scratch and a seed data set is written.
• March 2026: versioned specifications before the code. Supplier audit, scoring engine, buyer and supplier journeys: the document comes before the implementation, and it lives in the repository.

The most important fact on this list is not technical. In October 2025, writing for the assistant forced the team to write, full stop: conventions, build commands, expected architecture, rules not to be broken. Documenting for the AI amounts to documenting for the team, and the project became readable by someone who did not write it, human or not.

The turn: three weeks, and half the core changes #

On 24 March 2026, a commit receives the tag V3-PRE-REFONTE. It is the only tag in the entire history, and it sits on a screen strictly identical to the one from late February, even though 626 files changed under the bonnet. What follows comes in three acts:

1. 26 March: the restructuring. A plan to reorganise the repository is written and carried out the same day: shared libraries into libs/, applications into apps/, the old monolith into legacy/.
2. 28 March: the technical switch-over. MySQL is replaced by PostgreSQL (two migrations on the same day, including merging the file database into the main database), every project moves to .NET 10 and Entity Framework Core 10, and Swashbuckle gives way to native OpenAPI, after a round trip reverted within the day.
3. 12 April: the deletion. The Blazor administration is removed from the repository, admin-next becomes the only back office, AutoMapper is replaced by a code generator, file storage moves to S3-compatible object storage with a CDN, and the migration history is squashed into a single migration.

The two analysis windows covering late March and April 2026 add up to 311 commits and 32 merged pull requests. The day before the Blazor admin was deleted, commits were still fixing its navigation: the code was repaired, then deleted the next day. It is the most revealing gesture of the whole episode: you do not maintain what you are about to throw away, except when throwing away has become cheap.

What the turn demanded in return #

The point enthusiastic accounts leave out: this speed is not free, it is paid in advance. The guardrails do not arrive after the volume, they arrive with it, in the same window.

• Integration tests leave the in-memory database for a real, ephemeral PostgreSQL started in a container and reset between tests. An in-memory database replays neither the migrations nor engine-specific SQL: it hides exactly the bugs that a large migration produces.
• Architecture tests check on every build that the layers are not crossed. That is what makes it possible to replace a core without rewriting the domain.
• 291 tests across 25 services, split into unit and integration tests, plus a layer of tests covering every controller.
• A five-stage pipeline that blocks anything that breaks, with container images tagged by commit hash.

What did not move, and explains everything else #

The March 2026 turn was possible for a reason that has nothing to do with AI: the domain model laid down in August 2024 was not touched. The “one entity, one translations table” pattern that carries the six languages, the Domain / Application / Infrastructure separation, the business entities: all of it survived three technology stacks, two database engines and two presentation frameworks.

In other words, AI did not make architecture optional. It made it decisive: it is the only part of the system that cannot be regenerated cheaply, and it determines what can be replaced around it. A badly structured project also speeds up with an assistant; it speeds up towards the wall.

The limits, as they appear in the history #

We want to name them, because the same repository shows them. In January 2026, nine agents and five internal analysis reports are deleted from the repository, along with a .env file that should never have been there: AI tooling produces debt too, and it has to be pruned. On 14 April 2026, a revert restores the image build after an attempt to simplify the pipeline. On 24 August 2026, a billing fix is reverted within the day and replaced by a more modest approach: showing an amount as an estimate rather than claiming to fix it.

Three reverts in two years, all on the same day: that is not a bad figure, it is a sign that the detection loop works. But none of these three problems was found by a review. They were found by running the code. This is the hardest limit of assisted development, and it does not move: a model can write and review, but only a running system tells the truth.

What we do with it for our clients #

Nothing magical, four habits. A conventions document kept up to date in the repository, readable by the team as well as by the assistant. Tests that hit the real database rather than a substitute. Short pull requests, because review has become the bottleneck. And assigning models according to the task (the most capable for design and synthesis, the others for implementation and fixes), because throughput is also paid for in tokens.

The details of this method, paradigm by paradigm, are in our first lessons-learned article on BuyStep. The screenshots cited here come from the illustrated retrospective of the project.

If you are wondering what AI can bring to your team without turning it into a black box, our approach is described here, and we will tell you frankly when it brings nothing. First conversation free.