Vibe coding, applied to a factory
'Vibe coding' means describing what you want and accepting what the AI produces, iterating by feel. It is a real and useful way to make software. It is also a bad way to make the software a plant runs on, for specific reasons that can be fixed.
Why plain vibe coding fails on a plant floor
- It invents structure. Asked for 'downtime by shift', a general model makes up shifts, reason codes and machine names. A plant has real ones, and apps that don't use them are wrong from the first row.
- It computes KPIs its own way. Five vibe-coded apps give five OEE numbers, because each one re-implements the formula. A plant has one definition and needs every screen to agree.
- It doesn't know the rules. 'Line 2 can't take material over 2 mm' lives in a veteran's head; a vibe-coded scheduler will put the part on line 2.
- It shows zero when it means unknown. A missing file becomes '0 minutes downtime' on a board, and someone makes a decision on it.
- Nobody can say where a number came from. Trust on a plant floor is provenance: which file, which row, who entered it.
What to keep from vibe coding
The speed, and the fact that a production supervisor can describe the screen they want without a ticket. That part is right. The fix is not to slow it down; it is to constrain what the AI builds against.
What SubAssembly AI adds
- A plant model built once — hierarchy, objects, parts, BOM, routings, shifts, reason codes, operators, units — so the AI builds against real things and is told not to invent names.
- Metric definitions as objects: OEE, availability, scrap rate, on-time delivery defined in a Metrics Studio and evaluated by one engine for every app, report and phone answer.
- Knowledge and constraints in plain English, structured by the AI and confirmed by a person, enforced in apps with the reason and the author.
- Tri-state values: a number is a value, unknown, or not applicable, and apps are told to render 'no data' rather than zero.
- Provenance on every record and an explain on every answer.
- A Build Advisor and a Deep Build audit that check a build against the model before it ships, and assumption receipts that list what the AI decided on its own.
Examples
- 'Build a downtime tracker by shift with the top five reasons' → an app using the plant's real shift calendar and reason codes, with planned/unplanned decided by the plant's own definition.
- 'Add a changeover column to the line board' → the existing app is edited, QA re-runs, the link stays the same.
- 'Scheduler for the stamping area' → assignment screens that refuse a part on a line whose recorded capabilities don't meet the part's requirements, and say why.
- 'Which lines can run PN123456?' asked on the phone → eligible lines, blocked lines with the reason, and lines whose capability isn't recorded yet, in that order.
What it still can't do
- It can't make a bad spreadsheet good. If the plant's downtime log has no durations, no app can compute availability from it; the readiness view says so.
- It can't guarantee a build is right. It makes the AI's choices visible so a person can check them in a minute instead of discovering them in a month.
- It isn't a validated system for regulated production. It holds traceability data and answers on it; it does not replace a validated MES.
Questions
Is vibe coding safe for production software?
Plain vibe coding isn't, for the reasons above. Constrained by a plant model, shared definitions, rules, provenance and audits — and with a human reviewing builds — it is a fast and reasonable way to build plant-floor applications that are not safety-critical.
Who does the describing?
Usually a supervisor, engineer or plant manager. No developer is needed; a builder role in the account is enough.
What if the AI gets it wrong?
The build shows its assumptions; you change one in a sentence and it rebuilds. Every number can be traced to its records and definition.