Two years of AI on the same project: what really changed in the way we build software

Accounts of “AI that writes code” rarely lack enthusiasm and often lack figures. We have the ground to do the opposite: BuyStep, a B2B energy marketplace whose platform we have been building since summer 2024. The Git repository keeps a record of everything that happened in it, including the way AI assistance entered the project. Here is what that record tells us, without the hype.

The ground: 1,706 commits, three stacks, two databases #

Between 23 July 2024 and 5 September 2026, the repository holds 1,706 commits and 140 merges into the production branch. The platform changed its foundations three times: a Blazor Server monolith on MySQL and .NET 8, then .NET 9, then a monorepo with a .NET 10 API, a Next.js 16 portal and PostgreSQL. The database migrations were reset four times. In other words, this is not a demo project: it is a business application that has lived.

One simple indicator sums up the trajectory: the number of commits per month. It ranges between 25 and 70 during the first year. It rises to 274 in October 2025, then to 341 in April 2026. These two peaks are not coincidences: each one matches a change of method.

Paradigm 1: the assistant that completes (2024 → mid-2025) #

During the first year, AI is a typing aid. It suggests lines, sometimes methods, never an architecture. The repository contains no trace of it: no instructions, no generated report, commit messages written by hand, in French, often in a hurry (“Problème d'update de folder résolu”, folder update problem fixed; “Changement de PC pour continuer à bosser”, switching PCs to keep working).

The pace is that of a single developer on a product still looking for its shape. In June 2025, a commit cancels “unmaintained” tests: the classic sign of a team moving faster than its guardrails. We note it without judging it, because it is precisely what the next paradigm corrected.

Paradigm 2: the repository becomes shared context (October 2025) #

In October 2025, three things appear in the repository in the same week: an instructions file for the assistant (CLAUDE.md), a configuration folder for it, and a series of analysis reports written by it (API services, client-side migration, product tests). The same month, configuration moves entirely to environment variables, the application is dockerised, the migrations are rebuilt from scratch and a seed data set is written.

Volume goes from 66 commits in September to 274 in October. But the important change is not the volume: it is that documenting for the AI amounts to documenting for the team. Conventions, build commands and the expected architecture are now written down, versioned and read at every session. The project has become readable by someone who did not write it, human or not.

Paradigm 3: the specification before the code (March 2026) #

Spring 2026 is when execution becomes cheap. A folder of versioned specifications (supplier audit, scoring, buyer and supplier journeys) comes before the code. A plan to restructure the repository is written on 26 March and carried out the same day: shared libraries go into libs/, applications into apps/, the old monolith into legacy/. Two days later, the database moves from MySQL to PostgreSQL and the framework from .NET 9 to .NET 10. The next day, the integration tests drop the in-memory database for a real, ephemeral PostgreSQL, and architecture tests check that the layers are not crossed.

The Next.js portal was born on 18 March with a commit titled “Add base react homepage rebuild”. A month later, it was serving the catalogue, the supplier pages, authentication and payment.

When writing code costs less, value moves up to two places: intent (what exactly do we want?) and executable guardrails (how will we know it is wrong?). Tests on a real database and architecture tests did not arrive by chance just as the volume of generated code exploded: they are the condition for accepting that volume.

Paradigm 4: throughput, and what it demands (April 2026) #

April 2026: 341 commits, merges to production almost every day, conventional commit messages in English, an entire feature removed “because it is no longer used”, AutoMapper mappings replaced by code generated at compile time, the Blazor administration replaced by a Next.js application, and the legacy code deleted on 12 April. A month of work that would have taken four or five two years earlier.

The risk of this throughput is well known: review can no longer keep up. Our answer was mechanical rather than heroic: short pull requests, unit tests that run in two seconds, integration tests in thirty, a five-stage pipeline that blocks anything that breaks. And a rule of conduct for the assistant: report faithfully. If a test fails, say so with the output; if a step was skipped, say that too.

Paradigm 5: agents that orchestrate agents (September 2026) #

To write this article, we built a tool that rebuilds old BuyStep commits in Docker containers (.NET 8, 9 or 10 SDK depending on the period, MariaDB or PostgreSQL), applies the migrations of the time, seeds data, starts the application and takes screenshots of its pages. It was written in one session by a team of agents: five implementing in parallel, one reviewer per module tasked with challenging the work, and one integrator who actually ran the whole thing. Eleven thousand lines in an hour.

Then we ran it on real commits. Four defects appeared that no review had caught: a page that scrolled inside an internal container and came out truncated, a migration that required an EF factory that did not exist at that time, an indexing service that stopped the application when Elasticsearch was missing, and a port already taken by another project. Each was fixed in a few minutes, because the diagnosis was done on a running application. Verification by execution is still the only kind that counts, and it is still the work of an assisted human, not of an agent alone.

What we take away #

• The contract before the code. A document that sets the interfaces, data formats and rules of conduct does more for quality than any prompt.
• Guardrails must run. Tests on a real database, architecture tests, a blocking pipeline: whatever is not automated ends up giving way under the volume.
• Documenting for the AI means documenting for the team. Both audiences have the same needs: explicit conventions, reproducible commands, dated decisions.
• Throughput is paid for in review and in tokens. Assigning models according to the task and shortening pull requests is not optional.
• Nothing replaces execution. An agent can write and review; it is by running the system that you find what is missing.

We apply this method on the projects we run, in .NET as well as Next.js. 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 honestly when it brings nothing.