Engineered, not generated

Anyone can generate a CRUD app this year. Type a prompt, get a screen, wire it to a table. The demo looks fine. The trouble starts in month four, when someone has to change it — and nobody, including the person who generated it, can say why it works the way it does.

That is the difference between software that exists and software a team can rely on.

Our rule

We use AI heavily while building Usable. What we don't do is ship code that no human has understood. Every module we release has to pass a plain test:

Could a competent developer who has never seen this code maintain it — without asking an AI what it does?

If the answer is no, it isn't finished. Not because generated code is bad by definition, but because software you can't reason about is software you can't fix under pressure. And business software is exactly the kind that breaks under pressure: on a Monday morning, in the middle of a shift, when a customer is waiting.

What that looks like in practice

• Every module carries its own documentation — written to be read by the people using it, and by whoever maintains it next.
• Boring, explicit code beats clever code. The database schema says what it means. The permissions are readable in one file.
• We delete more than we generate. Most of the work is deciding what not to build.

None of this is visible in a demo. All of it is visible the day something goes wrong — which is, honestly, the only day that counts.