← Back to Blog

AI didn't make engineering optional

Team Alvin

You can build a working version of a software idea in an afternoon now. Describe the workflow, get an interface, click through it, show it to someone. No spec, no wireframes, no six-week discovery phase. That's real, and it's good news. It killed a stage of this business that was mostly ceremony.

The follow-up question usually arrives a couple of weeks later: what would it take to give this to the whole team? That's where our job starts, and it's the same job it was five years ago.

Making software got easier. Being responsible for it didn't.

The demo is the easy half

A prototype has one job: convince a person in a room. It runs once, on a clean database, with a single user, on the laptop of whoever built it. Nothing about it has to survive a bad Tuesday.

Software a company runs on has a longer list. What happens when two people edit the same record at once. What happens when the API it depends on goes dark for forty minutes mid-shift. Who is allowed to see whose data, and who decided that. Where the backups are and whether anyone has ever restored one. Whether it still builds in three years, after four framework versions, for someone who has never met the person who wrote it.

None of those are AI questions. They're ordinary engineering questions, and someone has to sit down and answer them on purpose. Nobody has ever answered them by accident.

What we hand to a model

Most of it. We're not precious about this — a large share of the code we ship starts as generated code. Models are fast at the parts of this work that were always just typing: CRUD endpoints, test fixtures, migration drafts, glue between two APIs that were never meant to meet, the fourth version of a screen when we don't yet know which layout is right.

They're even better at reading. Point one at forty thousand lines of undocumented code somebody wrote in 2016, ask where the invoice total gets calculated, and you've saved a day. That alone changed how we take on legacy work.

What we don't

Auth and permissions. Anything that moves money or produces a number a client will invoice against. Anything destructive — migrations, deletes, cleanup jobs that run at 2am with nobody watching.

Not because a model can't write them. Because it writes them plausibly. Bad code that looks bad gets caught in review in ten seconds. Bad code that reads like a careful engineer wrote it is the expensive kind, and it tends to surface in production, on a weekend. So on that short list a human reads every line and owns the outcome. Everything else is negotiable.

The rewrite we talked a client out of

A machinery manufacturer came to us with an iPad app their operation depended on. Old stack, hard to support, and several firms had already passed on it. The obvious move was a clean rewrite: modern tools, fresh architecture, finally do it properly.

That would have been the wrong call. Their people had built their working day around that app for years, and the real risk wasn't the aging codebase. It was a month of everyone relearning their job. So we rebuilt it to behave the same way it always had, connected it to their accounting system, and moved them over without a disruption. What the VP of Operations said afterwards: "the new app works as great as the old one, which was the main goal for us."

That's the entire job in one sentence, and there's no prompt for it. (The full story is here.)

"Build us an app"

That's still how most projects arrive, and it's almost never the real request. The real one is underneath it. Two systems that don't talk, so someone retypes orders every morning. A spreadsheet four people fight over. A report that takes a day to assemble and is stale by the time it lands in an inbox.

Finding that means sitting with a business long enough to see how it actually runs, then building something small and putting it in front of real users fast — which is roughly what our two-week sprint exists to do. It's the least automatable part of this work and it decides whether the software was worth building at all.

So we use AI everywhere it earns its place, which is most places. We just don't let it decide when something is done.

Start a project

Tell us what you need and we will come back with next steps, not a sales sequence.

What do you need?

Timeline

Budget range (optional)

We reply to every project inquiry within one business day.

Talk to us

A question, a second opinion, or just seeing if we are a fit — all welcome.

We usually reply within one business day.