In brief
I spent fourteen years in quality, several of them doing dimensional inspection in the hydroelectric sector, before I wrote my first serious line of code. Today, on my own, I have built a coherent suite of trade-specific software for machine shops. This is not a programmer's feat. It is a feat of framing.
AI let me move fast. But AI left to its own devices produces the plausible, not the reliable — and in quality, the plausible does not pass the audit. What made the result solid was the discipline imposed around it: written rules, strict limits, verification at every step. Here is how, and above all what it reveals about what a small manufacturer can now afford.
I come from the shop floor, not from software
I need to say this up front, because it changes everything that follows. I am not a developer who discovered manufacturing. I am a quality practitioner who ended up writing his own tools.
For fourteen years, my days were made of dimensions, first-article inspections, nonconformities to document, inspection reports to deliver to the customer. I inspected parts where a mistake cannot be walked back. I lived through management review, internal audit, the broken traceability you discover three months too late. I know the real weight of a missed calibration.
That lived experience is not a biographical footnote. It is the foundation of everything. Quality software built by someone who has never filled out a first-article report by hand will always be software that looks like what you need without ever quite fitting. The details that make the difference — the exact order of the quality chain, what an auditor wants to see, what costs a machinist an hour — cannot be invented. They have to be lived first.
I am not a developer who discovered manufacturing. I am a quality practitioner who ended up writing his own tools.
AI on its own does nothing reliable
Many owners imagine that today you simply "ask the AI" to build software and out comes a ready-to-use application. That is not how it works, and we owe it to ourselves to be honest about that.
Generative AI is remarkable at quickly producing something that looks right. That is also precisely its danger. It does not know the difference between "correct" and "credible". Left without a frame, it invents one data structure today, proposes another tomorrow, blends two ideas that must stay separate, and leaves you with an assembly that runs, that demos well, and that collapses on the first real case.
In quality, that kind of fragility is disqualifying. Take the chain every quality manager knows: a nonconformity (clause 8.7) attaches to a process; a corrective action (clause 10.2) attaches to a nonconformity; prevention comes from actions to address risks (clause 6.1). These links are not decorative. They are the very logic of the system. An AI asked to "build me a nonconformity module" without rigorous framing will, sooner or later, attach a corrective action to a risk instead of to a nonconformity. In the moment, nobody sees it. In an audit, it costs you your certification.
This is the heart of everything I learned building Asterion: AI is only useful when it is held. The trade-specific software is the frame. The AI works inside it, not in its place.
Discipline before speed
In practice, framing the AI means imposing on it the same rules you would impose on a very fast junior employee who has no trade judgment yet. You do not let it decide the architecture. You give it written, non-negotiable instructions, and you check its work at every step.
So I wrote rules before I wrote code. Simple rules, held to, re-read at every intervention. A few examples of what governs every line of the system:
| Rule imposed | What it prevents |
|---|---|
| Break every piece of the software into small, short parts — never giant blocks | The unmanageable tangle where no one understands what is happening, or how to fix it |
| Name and check every piece of data, never tolerating a rough approximation | The silent errors that pass the demo and break in real work |
| Automatic checks before and after every change | Fixing one thing while quietly breaking another without noticing |
| A piece of business data entered once, never re-copied from one application to another | Double entry and inconsistencies between modules |
| Documentation updated at the same time as the software | The drift between what the software does and what we think it does |
These rules do not make the work faster in the short term. They make it deliberately slower. That is the point I want owners to take away: the value is not in the speed of the AI, it is in the rigour of what surrounds it. A fast AI inside a disciplined frame produces solid software. A fast AI with no frame produces debt you pay later, often at the worst moment.
At every intervention, the same mechanics repeat: read and understand what already exists before touching it, make a minimal and targeted change, verify that nothing else moved, summarize what was done. It is not glamorous. It is exactly the discipline you expect from a good quality system: traceable, verifiable, with no grey zones.
There is a legitimate objection an owner raises when facing a tool built by a single person: "and if that person disappears, what happens to my software?" That is precisely what all this rigour is for. Software whose parts are short, clearly named, documented as you go, and governed by written procedures is not a mysterious object locked in one head. It is readable, findable, resumable. The same demand for traceability we impose on a quality file — that anyone can retrace what, why and how — applies to the software itself. That is what makes a tool live beyond the person who wrote it: not one person's promise, but the documented structure that lets others carry it on. For a buyer, that is a guarantee of durability, not a bet on an individual.
A coherent ecosystem, not a pile of tools
The result of this discipline is something you do not build by accident: a suite of applications that genuinely talk to each other.
Each application covers a real trade of the shop — dimensional inspection, quality management, metrology, planning. But the list is not the point. The point is that they share a single identity, a single source of truth for master data, a single way of thinking. A work order entered once travels from one trade to the next without being re-entered. A nonconformity caught in inspection feeds the quality system. An instrument tracked in metrology is offered at the right place during inspection.
This coherence is only possible because a single frame governs the whole. The same structural rules, the same demand for traceability, the same compliance — in Quebec, that means data hosted and processed here, an architectural choice owned from the very first line, not a patch bolted on afterwards. Data sovereignty, to me, is not a fear argument. It is a question of control and ownership: your customers' drawings, the history of your nonconformities — these are your assets. They must stay under your control, and that is decided in the architecture, early.
A set of tools cobbled together separately would never have held that coherence. It is the discipline imposed on every brick that lets the whole form a system rather than a stack.
80 % to the machine, 20 % to the human — and never the reverse
Where framed AI gives its best is on repetitive work. Extracting dimensions from a drawing, comparing documents against requirements, preparing a file, flagging a deadline that is approaching: these are tasks where the machine, well held, does the bulk of the effort. It prepares.
But it does not sign off. The release of products (clause 8.6), the closure of a corrective action, the decision that commits the company's responsibility: that stays, 100 %, in the hands of a qualified human. Well-built software does not try to automate judgment. It augments it. It presents clear information, highlights what is missing or what is wrong, proposes — and lets the competent person decide.
This boundary is not a technical limit we will lift one day. It is a principle. Responsibility does not automate. A system that claims otherwise lies to its user, and leaves them alone on audit day. The AI that prepares well and the human who decides: that is the right split, and it is the one the frame must protect.
What this reveals for a small manufacturer
Here is the part that should interest any owner, beyond my own path.
Only a few years ago, building a coherent software suite for a specific trade took a team, a budget, months — often years. It was reserved for the big players. A small manufacturer had only two options: pay dearly for an off-the-shelf suite it would use at half capacity, or live with its spreadsheets and binders.
What my experience shows is that a third path now exists. A person who truly knows their trade, if they know how to frame AI rather than trust it blindly, can build in a few months tools cut exactly for their ground. Not because the AI does the work for them — it does not — but because it dramatically shortens the distance between "knowing what you need" and "building it".
The skill that matters is no longer knowing how to program. It is knowing what to build, and having the discipline to keep the AI on the rails while it helps build it. In other words: trade expertise takes back first place. The person who knows the dimension, the nonconformity, the calibration and the management review now has the means to turn that knowledge into a tool, without becoming a software specialist.
For a small manufacturer, the lesson is direct. The question is no longer "can we afford custom software?" It becomes: "do we know our own trade precisely enough to say what we really need?" And for a supplier, the question is: does he come from your world, or does he watch it from a distance?
In closing: the frame, more than the tool
If I had to sum up these behind-the-scenes in one sentence, it would be this: it is not the AI that built this software, it is the discipline around it. The AI was a powerful accelerator. The frame — the rules, the verification, the demand for traceability, the refusal to automate judgment — is what made the result worthy of an environment where a mistake has a price.
This opens questions I find more interesting than the answers. If trade expertise becomes the scarce resource and the tool becomes accessible, what does good quality software look like when built by those who live the trade rather than those who describe it? How many shops carry, in the heads of their best people, tools that are only waiting to exist? And how far do we trust a machine that prepares admirably, as long as a human keeps a hand on what commits the company?
I do not have all the answers. But I know one thing, having built it: AI framed by structured trade-specific software does not replace the quality professional. It finally gives them back the place that is theirs.
The principles described in this article are the ones that guided the development of Asterion Solutions, a suite of trade-specific software designed for small manufacturers who want to structure their quality without multiplying administrative tasks.