L'usine logicielle

Le codage agentique transforme l'unité de production logicielle : le développeur conçoit, supervise et améliore de plus en plus une usine de systèmes connectés pour construire, auditer, déployer et exploiter.

Most technological revolutions are easier to understand after the fact. We give them names, draw clean timelines, and pretend the direction was obvious. But for the people living inside them, they probably felt much messier: new tools, awkward workflows, inflated claims, real breakthroughs, bad products, and a slow change in what work even meant.

As a software developer, I have mostly lived inside revolutions that had already happened. The internet was already there when I started building. Open source, cloud infrastructure, smartphones, app stores, APIs, and SaaS were already part of the landscape. They changed my work, of course, but I did not feel the ground move beneath the job itself.

Agentic coding feels different. I do not know what historians will call it, and I do not want to pretend that every new tool is a civilizational break. But from inside software development, this does not feel like another autocomplete improvement. It feels like a change in the basic unit of production. The question is no longer only how fast one developer can write code. It is how a developer can organize machines that write, test, review, deploy, and monitor code.

The industrial revolution was not only the story of machines replacing human muscle. It was the story of humans learning how to organize machines.

Before industrial production, a person made the thing, or a large part of the thing, directly. Skill lived in the hand, the eye, the habit, the workshop. The arrival of powered machines did not make human judgment irrelevant. It changed where that judgment was applied.

A drill is a simple example. When I use a drill, I am still responsible for the hole. I choose where it should be, why it should exist, whether it is the right size, and whether the result is acceptable. But I am no longer supplying the rotation myself. The machine does that part.

The deeper change came later, when machines were composed into factories. The important invention was not only the machine, but the system around the machine: handoffs, quality control, maintenance, scheduling, management, logistics, safety. The companies that won were not simply the ones that owned one better tool. They were the ones that learned how to organize many tools into a production system.

I think software is entering its version of that transition.

Until very recently, most software was implemented by hand. Even when we had excellent tools, the developer still performed the implementation directly: opening files, writing code, running tests, reading errors, editing again. We had better drills, but our job was still to hold the drill all day.

Coding agents change the shape of the work. They are not magic. They are not autonomous companies. They make mistakes, get stuck, overfit to weak instructions, miss context, and sometimes produce plausible nonsense. But they do change the mechanical part of software development. A human can now describe a bounded outcome and have a machine explore the codebase, make edits, run tests, hit failures, fix them, and return with a candidate result.

That is a big change by itself. The bigger change is the factory that becomes possible around the agent.

Du codage à la production

The first temptation is to think of agentic coding as "faster coding". That is true, but too small.

The more interesting question is: what would an application factory look like? Not a code generator. Not a scaffold. A real factory for turning product intent into running software: shaped, implemented, reviewed, tested, deployed, observed, and improved.

This is very different from what people often call vibe coding.

Vibe coding is what happens when you have an idea on Friday night, open an agent, push through the rough edges, and end the weekend with something that works well enough to show. I like that mode. It is real, useful, and creatively important. It makes small tools possible. It lets you follow curiosity without first justifying a roadmap.

But vibe coding is not factory operation.

A factory is slower, at least locally. It adds friction on purpose. A feature does not go straight from idea to code to production. It goes through product shaping, architecture, implementation, adversarial review, browser QA, security checks, deployment, and monitoring. Different features may take different paths: a copy change should not require the same machinery as a billing migration, and a prototype should not pretend to be production software. But the principle is the same. The factory is not optimized for the thrill of making something exist quickly. It is optimized for making many things exist reliably.

That distinction matters. Agentic coding makes weekend prototypes much easier. Agentic factories make durable software operations possible.

At Pyratz, we have been moving in that direction, although we did not name it that way at first. The pieces started separately because the problems appeared separately. How do we turn a vague feature idea into scoped work? How do we review agent-written code without trusting it blindly? How do we deploy and operate more applications without reinventing infrastructure every time? How do I, as one person, stay in control of all this without becoming the bottleneck for every mechanical step?

Those questions lead to different tools. But underneath the tools is one ideology: software production should become an operated system.

There is a build loop, where an idea becomes a feature, a feature becomes an architecture plan, and the plan becomes implementation work. There is an audit loop, where the output is reviewed adversarially, exercised in a browser, and checked for security and regression risk. There is a deployment loop, where the application is provisioned, configured, published, and later observed. And then there is the factory manager: the layer that coordinates the other machines, knows which one should run next, and brings decisions back to the human.

In our stack, Business Builder is becoming the build loop. Code Voucher is becoming the audit loop. Pyratz Apps is becoming the deployment harness. MrChief is the candidate for the factory manager.

That last part matters. I do not want MrChief to be "the agent that writes all the code". That would be the wrong abstraction. I want it to be closer to a super secretary, or a semi-autonomous CTO for the mechanical parts of the company. It should connect to the other pieces through MCPs, APIs, CLIs, or whatever communication layer is appropriate. It should know when a feature needs product clarification, when an audit is blocking deployment, when a staging environment is unhealthy, and when I need to make a decision.

In that model, I am not the worker and I am not even the factory manager. I am closer to the CEO. I set direction, accept risk, decide priorities, and judge whether the product is good. MrChief manages the factory floor.

L'usine logicielle forme une boucle : construire, auditer, déployer, exploiter, puis réinjecter la réalité dans le cycle de construction suivant.

This is the point where the industrial analogy becomes useful. A factory is not a single machine. It is a system of machines with handoffs, checks, buffers, operators, safety procedures, and feedback loops.

Software needs the same thing.

Le pont entre les machines

The projects above are useful independently. But an actual factory requires them to be connected.

If the build system, QA system, deployment system, monitoring system, and operator interface all have separate state, separate concepts, and separate memories, the human remains the integration layer. That is better than writing all the code by hand, but it is still not a factory. It is a collection of power tools on a bench.

The factory appears when these tools share enough structure to hand work to one another reliably.

That means a feature should have a durable identity across the entire lifecycle. The product brief, architecture proposal, implementation tasks, commits, review findings, QA screenshots, deployment target, monitoring alerts, and follow-up tickets should all be connected to the same object. The system should know that this Sentry regression came from that deployment, which came from this feature, which came from that product decision.

It also means every stage needs a contract. Business Builder should not hand Code Voucher a vague "please review this". It should hand over a feature artifact with scope, acceptance criteria, risk classification, expected routes, test strategy, and commit range. Code Voucher should not hand deployment a blob of prose. It should produce structured approval, blocking findings, artifacts, and residual risks. The deployment harness should not simply say "done". It should report what version was deployed, where, with which environment, and how to verify it. Monitoring should not create noise. It should create typed signals that can become new work.

The bridge is not only API integration. It is a shared language for work.

I think the core objects are something like:

• an idea;

• a feature;

• a repository;

• an environment;

• a run;

• an artifact;

• a finding;

• a deployment;

• an incident;

• a decision.

Once those objects exist across the system, the operator can ask higher-level questions:

• What is blocking this feature from production?

• Which findings are still unresolved?

• What changed since the last successful deployment?

• Which user-visible workflows did QA actually test?

• Which incidents should become product work?

• Which agent needs to run next?

That is the bridge that turns separate applications into a factory.

This also connects to the argument from extensible software. Extensible programs matter more in the agentic age because they give agents real surfaces to work with: APIs, hooks, structured state, commands, events, and self-documenting concepts. A factory is what happens when that idea is applied not only inside one application, but across the applications that build and run software.

There is a difference, though. In the extensible-programs argument, the user extends the program through surfaces the program already exposes. Emacs is the obvious example: commands, hooks, variables, modes, documentation. In the software factory, we go one level deeper. I may not merely extend the application. As the creator of the application, I can modify the application itself.

That is not the same power a normal end user should have. A random user should not be able to rewrite Business Builder because they want a button. But I, as the builder and operator of the factory, should be able to change the factory itself through the factory.

For example, suppose I want Business Builder to add a feature where, after implementation, I can chat with an agent about the finished work to make sure we did not forget anything. That request should not remain a loose prompt in a chat window. It should become a feature conversation, a scope, repository context, an architecture plan, implementation tasks, review, QA, and eventually deployment. If the feature changes how review artifacts are stored, the system should know which tests and QA paths matter. If deployment fails, that failure should become structured work rather than a forgotten terminal log.

Now add MrChief on top. I may not even want to start inside Business Builder. I may want to tell MrChief from my phone: "Improve Business Builder so I can debrief with an agent after implementation." MrChief should know which factory machine owns that work, start the right process, come back when human judgment is needed, and keep the chain of evidence intact. The point is not that one assistant does everything. The point is that the assistant becomes the operator interface for a network of specialized, inspectable tools.

L'opérateur devient le plan de contrôle : l'intention entre par une interface unique, puis des agents et outils spécialisés l'acheminent vers la production.

The end state I care about is not "an agent writes code". It is that a person can operate an application from anywhere. From a phone, you should be able to state a need, shape it, let the system build it, inspect the review, approve the deployment, and receive monitoring feedback later. Not for every category of software, and not without judgment, but for a large class of ordinary application work.

That sounds small until you think about what becomes possible.

Today, a district poker club app is probably not worth building. A small association may want member signup, event scheduling, dues collection, table management, announcements, and a few admin workflows. But hiring a team, setting up infrastructure, writing the app, securing it, maintaining it, and operating it is too expensive. So the need remains underserved, or it gets solved with a spreadsheet and a group chat.

In a software-factory world, that changes. The app may still need human product judgment. It may still need legal and payment review. It may still need someone to care about users. But the mechanical cost of producing and operating the software drops enough that more niche software becomes viable.

That is why I do not believe this kills software work. Factories did not eliminate production; they expanded it. They made it possible to make more things, at lower cost, with more consistency. They also created new jobs around design, maintenance, logistics, process, safety, quality, and management.

I expect the same in software. We will build far more software, not less. The job changes from doing every motion by hand to designing, supervising, and improving the production system.

Une usine logicielle a besoin de contrats explicites et de garde-fous partout où ses machines se transmettent du travail.

Les dangers de l'usine

But anyone who wants to operate a factory has to respect its dangers.

The other face of the coin is that agentic software factories can fail at machine speed. A single developer making a mistake by hand is limited by the speed of their hands. A badly designed factory can produce bad changes, misleading reviews, insecure deployments, and noisy remediations much faster than a human team can understand them.

Prompt injection is one obvious risk. If agents read issues, documentation, websites, logs, emails, or user content, they are reading hostile input. A malicious instruction hidden in a page should not be able to make the agent exfiltrate secrets, weaken tests, approve its own work, or change deployment policy. The factory needs hard boundaries between untrusted content and trusted instructions. It needs tool permissions, provenance, sandboxing, and publication controls. Agents should not get write credentials merely because they can produce fluent text.

The problem gets worse when the apps are bridged. If Business Builder can start implementation, Code Voucher can publish review results, Pyratz Apps can deploy, and MrChief can orchestrate all of them, then a prompt-injection failure in one place can try to become an operational failure everywhere. The bridge therefore has to carry authority information, not just data. A QA finding is not a deploy approval. A deployment log is not a product requirement. A user comment is not a trusted instruction. Every artifact needs provenance, permissions, and an allowed set of next actions.

Maintainability is another risk. A factory that optimizes only for throughput will create software debt at industrial scale. Agents are very good at adding one more file, one more abstraction, one more compatibility layer, one more almost-duplicate helper. Without architectural memory and review, the codebase can become a landfill of locally plausible decisions. That is why the build loop has to care about reuse, ownership boundaries, migrations, tests, and whether new abstractions deserve to exist.

This is where factory discipline differs again from vibe coding. In a weekend prototype, a little duplication or an awkward abstraction may be fine. The point is to learn. In production, that same habit compounds. If every feature adds its own almost-correct pattern, the factory becomes less capable every time it runs. The output may still look fast, but the underlying system becomes harder to change, harder to review, and harder to trust.

There is also the risk of false confidence. A passing test suite is not proof that the product works. A browser QA report is not proof that every workflow was tested. A security scan is not proof that the system is secure. A deployment success message is not proof that users are happy. Every stage produces evidence, not truth. The operator must know the difference.

Knuth's old warning feels strangely relevant here: "Beware of bugs in the above code; I have only proved it correct, not tried it." The problem is slightly different, but the shape is the same. A formal proof, a test run, a QA report, a scan, or an agent summary can all be valuable. None of them is the thing itself.

The factory also needs auditability. If an agent changed a billing workflow, who asked for it? What scope was approved? Which files changed? Which review findings were waived? Which tests ran? Which environment received the deployment? Which monitoring signal later showed the regression? Without that chain, the factory cannot be trusted.

And finally, there is the human risk: the temptation to stop thinking. The factory should remove toil, not responsibility. The more powerful the system becomes, the more important it is that the human operator remains accountable for product judgment, risk acceptance, and taste.

The right mental model is not "agents all the way down". It is an industrial system with safety rails:

• least-privilege agents;

• isolated runners;

• explicit approval gates;

• structured artifacts;

• adversarial review;

• private raw evidence and sanitized publication;

• deployment records;

• monitoring feedback;

• reversible changes;

• human accountability.

Factories are powerful because they are disciplined. A software factory without discipline is just an automated mess.

L'entreprise qui apprend à piloter l'usine

The first companies to master this will have a meaningful advantage.

Not because they will have one magic coding agent. Everyone will have coding agents. The advantage will come from the production system around them: the contracts, orchestration, review loops, deployment harnesses, monitoring, and organizational habits that let a small team move many pieces of software without losing control.

This is why the topic feels important to me. It is not a productivity hack. It is a change in the unit of software production.

There are several questions I want to explore next. What should the interface for this kind of factory actually feel like? Is it an evolution of the tools we already know, like Linear for intent, Sentry for production signals, GitLab for change control, and deployment dashboards for operations? Or does the factory need a different kind of interface altogether: something closer to MrChief, a manager that sits above the tools, understands their state, and lets the human operate the system through conversation, review, and explicit decisions?

There is also the question of autonomy. Which steps should run automatically? Which ones should pause for approval? Which risks should the system be allowed to take on its own, and which ones must always come back to the operator? The answer will probably not be one fixed level of autonomy. It will depend on the application, the environment, the maturity of the factory, and the cost of being wrong. That design space deserves its own treatment, because the UX of agentic software factories may matter as much as the agents themselves.

The developer used to be the person turning the crank. Increasingly, the developer is the person designing the machine, feeding it useful work, checking its output, maintaining it, and deciding what should be produced next.

The best builders will not be the ones who merely ask agents for code. They will be the ones who learn to operate the whole factory.