If You’re Going to Vibe Code, Vibe Responsibly!

We’re writing more code than ever thanks to AI - but remembering how it all works a year later is quickly becoming the real hard problem.

Thanks to LLMs, developers are getting a serious productivity boost. With vibe coding – telling AI what you want in plain language and letting it generate the code while you review and tweak it – we’re producing more code than ever.

It only makes sense that, compared to just a few years ago, we’re now expected to maintain far more repositories.

It used to be that developers wrote their own code and, through debugging and researching solutions, learned and memorized how it worked in depth. With AI-generated code, this happens less often. Since we’re not the ones writing it from scratch, it’s easy to forget where things are and how they function.

So what’s the issue?

After some time has passed, when we need to revisit a service or repository, it takes a while to remember how the details actually work.

Making AI code easy to work with

To make life easier, we’ve relied on design principles that improve code readability and make it more scalable and maintainable. These include:

KISS (Keep It Simple, Stupid)
DRY (Don’t Repeat Yourself)
YAGNI (You Aren’t Gonna Need It)
Separation of Concerns (SoC)

In a year or two, when most of our code is AI-generated, debugging and expanding the codebase will become significantly harder. That’s because we likely never explored the generated code in depth – we focused on making sure it worked, ran efficiently, and looked right.

If you can’t explain it, it’s too complex

So, how do we address this?

In my opinion, two principles are becoming more important than the rest: Readable Code is Better than Clever Code and KISS (Keep It Simple, Stupid).

Being able to open a codebase and start working immediately is going to be crucial for developers. So how do we make our services more accessible? When reviewing pull requests, one key question should guide every new feature or component:

Is this simple enough that I can read it like a notebook, without having to dig through the code?

And as always, documentation and testing remain essential. One perhaps controversial opinion:

Don’t use AI to generate docs or tests, at least not the first draft.

Rephrasing is fine, but if you can’t explain the code in your own simple words or write straightforward unit and integration tests, the service is either too complex, or you’ve “vibed” a little too hard.

Ask the LLM to generate meaningful metrics and logs

Additionally, when generating code, make sure to prompt the LLM to include meaningful metrics and logs, ones that let you pinpoint issues without even diving into the codebase. Use logs sparingly, but make debug logs detailed and informative.

Imagine opening a repository you’ve never touched before, needing to implement a change or fix a bug. What kind of logs and graphs would make it easy for you to debug the service quickly?

When balancing code simplicity and performance, remember this: while keeping code performant is important, overly complex solutions can hurt future developers (especially juniors) who may need to maintain or fix it later.

Less code, more value

Another key principle is the Pareto principle, or the 80/20 rule, which is widely used across industries, including software development. The idea is that 20% of a developer’s time produces 80% of the value.

Applied to code, you could say that 80% of the code delivers only 20% of the value. So how does this tie into vibe coding?

Sometimes an LLM might “hallucinate” a call to a library that doesn’t exist. A natural next step would be to implement that library yourself – but by then, you may have already gone too far.

I like to think of the Pareto principle in this context, as the Grug-Brained Developer puts it: “80 want with 20 code.” The solution might not have every bell-and-whistle the project manager imagined; it might even be a little rough around the edges, but it works, delivers most of the value, and keeps unnecessary complexity in check. Avoiding extra code like this helps keep the codebase more readable and maintainable in the long run.

Code fast, secure… faster!

With the rise of LLM usage, security leaks have surged – but why?

When coding with LLMs, are you giving them the real context of your application’s deployment – just letting them write code in a test playground? Most developers aren’t.

We’ve seen a YoY increase in shared API keys and other sensitive data on GitHub, and it’s pretty clear there’s a correlation.