Engineering-Backed Vibe Coding

A client asked me to build her app by hand. I had to explain why I wouldn't.

A potential client asked me to build her app "by hand." She meant it as a specification. Not generated by AI, no vibe coding. Instead written by a person, line by line, the way software "used to" get made.

Three years ago I would have understood her perfectly, because there was no other reliable way. Over my 15 years as an engineer I’ve learned Ruby on Rails, then Python, JavaScript, and countless libraries to support them. I learned to turn an idea into instructions a computer would follow. And here I was, preparing to explain to a potential client why, if I did this job well, I would not personally write much, if any, of her code.

Sit with the absurdity for a second. After over a decade of honing a skill, my pitch had become: I will build this without typing it.

What I had to explain was that she wasn't hiring me to type. She was hiring me to know what should be typed, what should never be typed, how the pieces fit together, and how to avoid producing something with the shape of working software and none of the substance.

That there was a difference between artifact with the expertise.

Is generating code is building software?

Vibe coding, means describing what you want in ordinary language and letting an AI produce the software. With it you can get something running in an afternoon that might once have taken a team weeks or months.

The thing is, an application is more than a set of screens that behaved once. It has to remember things between visits. It depends on other services, and those services go down. It decides who is allowed to see what. It holds customer information someone would like to steal. It slows down as more people use it. Someone maintains it for years after launch. And users will do something nobody anticipated by Thursday.

That app you made in an afternoon is closer to a demo than production-ready software.

The bottleneck moved. It used to sit at production, where the limit was how fast a competent person could turn intent into working software. Now it sits at judgment, where the limit is knowing what to ask for and recognizing when what came back is wrong.

Most of the argument about AI and engineering skips this. One side says the machine writes the code now, so engineers are finished. The other side says the output is garbage, so nothing has changed. Both are describing the artifact. Neither is describing the work.

Knowing the difference between something that runs and something that actually works becomes more valuable when generation gets cheap, not less.

What I mean by engineering-backed vibe coding

I have started calling what I do engineering-backed vibe coding. It isn't an industry term. It's my shorthand for a working method.

Vibe coding is: build me a gardening app.

Engineering-backed vibe coding is: here is the system we're building. Here is how the information is organized. Here is what has to behave identically every single time. Here is what the AI gets to decide. Here is what it never decides. Here is how we will know it works. Now build this piece, please.

The difference is not how much code a human types. In both cases, the answer may be close to none. The difference is whether anyone set the constraints before generation started, and whether someone qualified to evaluate the result is looking at it.

The engineer holds the structure, the limits, the testing, the security, and the judgment. The AI handles the writing. The writing is real work and it matters, but it has become an output of the process rather than the center of it.

The decisions that stayed with the human

Take away the typing and look at what fills the day.

The engineer still has to decide what should be built and what shouldn't be built at all, which is often the harder question and one clients rarely want to hear. They have to think about how the system should be organized, what the AI needs to know, what it is allowed to touch, and what it must never touch, like payment records. They have to plan for what happens when it gets something wrong, because it will, and how you'll know something has broken before a customer tells you. And they have to recognize when a plain, predictable piece of software is still better than anything clever.

And underneath all of them is the one with no shortcut: how do you tell when something that looks right is wrong?

The AI returns something with a tidy structure and sensible names. It runs. Catching the problem takes having been burned before by the exact category of mistake it made. You are not proofreading. You are checking the result against a model of the system you carry in your head, and building that model took years.

Not everything needs an engineer

This is where the argument can start to sound like a professional protecting her career, so let me make something clear.

I do believe someone with no engineering background should absolutely vibe code an internal tool, a personal site, a prototype, a calculator, a weekend project. They should do it without hiring anyone and without apologizing.

AI genuinely opened software creation to people who were locked out of it. That is a good outcome, and I am not interested in pretending otherwise.

As software gets more consequential, less of the difficulty lives in producing it. The difficulty moves into everything around it: handling money, storing personal information, supporting a team whose work depends on the thing staying up, running for years, and connecting to systems you don't control.

The question worth asking is not whether you need an engineer.

It is what professional engineering becomes once producing the code stops being the scarce part.

She arrived at it herself

So what happened with that potential client who reached out?

She built the first version herself using vibe coding. It worked, the way first versions work, and I think she was right to try. Then she reached the part that comes after the MVP, and the problems stopped being about producing screens.

Her conclusion was that she needed a full-time engineer who could work this way: using AI to handle much of the production while bringing actual engineering judgment to everything around it.

And as for me, I have spent fifteen years getting better at building software.

The strange part of this moment is that the better I get at engineering, the less it matters whether I write the code.

That doesn't feel like the end of software engineering to me.

It feels like the beginning of a much different definition of what an engineer does.

__________________

This is the first in a series about what AI changes beyond productivity. Next: The Engineer Who Doesn't Code.