It's Almost Like You Need an Actual Programmer

Vibe coding ain’t what it used to be.

Back in the old days (2 years ago), we conjured up apps with our own programming language.

Turns out, it does work, but more for prototypes. If you want an actual working production app, you need that thing from before. How do the old timers call it? Ah yes. Code.

So our builder says to the genie: “Code me this”.
And the genie does build this. Mostly.

When we’ve got a prototype and it’s working, two things happen. The first thing is management thinks they have an actual product. In our case, it’s the builder that thinks “code me this” is simply a translation layer.

But then, another thing happens – we now have to take care of our puppy. I mean the code.

As long as we don’t need to touch it, it doesn’t matter what it looks like. But then we do.

So what does our hero think? What worked before, will work again. He tells his favorite code agent – “build me my greatest feature yet”.

But then weird things start happening. Bugs that weren’t there. Multiple tries of code changes – costly ones, mind you. Performance slows down.

It’s almost like you need an actual programmer to do the work.
And you do. You know what helps developers? And coding agents?

Clean code. Readable, maintainable code. The classics are still with us.

Now, coding agents are getting better at producing code. However, they are only as good as the code they are trained on. Now think – what do you think the average level of code out there is?

Exactly. That’s what you’re getting.

So if you are on a transition from prompts to code, it may look like continuing vibing is the shortest way to more features. Yet, the first thing you need is a good platform to grow your code.

Now it’s time to take control.

Read the code.

You’ll do this first anyway. The code is the only truth you have. The prompts you used before are scattered across forty chat sessions and there were never any docs.

Just know what you’re up against. Agents drop a lot of code, and after ten files your eyes glaze over. You won’t read all of it, but try to understand the important bits.

Write down what it should do.

Ask the agent to derive documentation from the codebase. It’s fast and it beats no docs at all.

But know what you got. Those docs describe what the code does, not what it should do. If there’s a bug in there, it appears as a requirement. Review and sieve out the wrong stuff.

If you can find them, collect your prompts. They were the intent for building the app.

Review both, and drop everything that doesn’t add up. Now you have a documented system.

Now write tests. Against the requirements.

It’s tempting to generate tests for what’s already there. And for legacy apps, I recommend capturing existing behavior of undocumented knowledge built up for ten years.

But here? You’re better set. The intent is still around. Capture what the code does today and you’ve just made every mistake a requirement.

Then you can change it.

Including asking the genie to change it for you – which is the part everyone wants to skip to.

But now, with documentation and tests in place, now it’s a lot safer to make changes.

Next you need to understand the principles of Clean Code. If you don’t, you may ask the genie to change the code for you, but you’ll get more of the same. We don’t want more of that mess.

Exactly like programming. Who knows, maybe you’ll become one eventually.

So what do you say – Are you ready for clean up?

---

Originally published at testingil.com.

I'm Gil Zilberfeld. I teach API testing and test automation, and I write about what AI-generated code does to quality.