I've trained models, shipped them, and been the one paged when they drifted. Three different things get called “AI” and they deserve separating: what goes in the product, what runs the data behind it, and how the software itself gets written.
A model earns its place in a product by removing work a person would otherwise do by hand, not by being the feature.
At YEPA that means a classifier that sorts free-text input into the categories the platform reasons about, so the rest of the system can stay ordinary code with predictable behaviour. It's a small supervised model, not a hosted general-purpose one: it's cheap to run, it can be evaluated against a held-out set, and when it's wrong it's wrong in ways I can measure and retrain against.
My thesis, SAFE, was the same instinct at research scale: extract temporal scope, sentiment and finer-grained emotion from financial news, then check separability before believing any of it. It scored 6/6 and is published in full.
The interesting use of a large model isn't answering questions. It's being one operator among several in a pipeline that has to run again next month and produce the same thing. Each stage is numbered, each writes its output to disk, each can be re-run alone.
Regex and rules first. Anything a deterministic pass can fix should not cost a model call.
The LLM only handles what the rules couldn't: malformed entries, mixed languages, broken encodings.
Drop what cleaning emptied. A cleaning step that silently deletes content is a cleaning step you don't notice.
Detect names, places, institutions; rephrase around them so the classifier learns the shape, not the person.
Fix the schema before generating. Typed in, typed out.
Generate variants for the thin classes only, measured against the class balance, not applied blindly.
One embedding pass over the final set, cached, so training is cheap to repeat.
The output is a Keras classifier small enough to retrain on a laptop. The expensive part was never the training. It was making the data honest.
I build with coding agents daily. That only works because the constraints are written down and the gates are real.
“Vibe coding” is accepting output you haven't read. What I do is closer to running a codebase that documents its own conventions well enough that a competent newcomer (human or not) can follow them, and then reviewing the result like any other contribution.
The repo's CLAUDE.md sets size limits per file type (200 lines for a page, 150 for a component, 100 for a hook) and says outright that they're guidelines. A cohesive 210-line component is fine; a 150-line one doing three unrelated things is not.
Recurring work becomes a written skill the agent follows. The one for extracting a feature into the shared package encodes the pitfalls from four real migrations: extract to shared, wire the second app, rewire the first as a thin wrapper, and keep every shared change additive so the app already on it can't break.
Agent work lands on its own branches and gets read before it merges. Same review as any other contributor's.
Deployments are human-approved, full stop. It's the first rule in the file. Staging is never automatic, and secrets are never staged by an agent.
The same approach built Atelier, my own video-production suite, and the site you're reading.
If a regex settles it, a model shouldn't be asked. Cheaper, and it fails in ways you can read.
A separability check before training. A held-out set after. A number I'd defend to a supervisor.
Nothing reaches production because a machine was confident. Deployment is a decision someone makes.