To vibe code, or not to vibe code?

Tough choice

I know how to write proper code. I have 15+ year of hands-on experience behind me. I was also an early adopter of Github Copilot and have continued using AI generative tools daily ever since (currently including Antigravity, Kiro, Codex, Junie, ChatGPT, and still Copilot).

I’ve seen LLMs generate increasingly better code and become more useful for day-to-day tasks. Models have become so good that they can generate browser or C compiler from scratch, and people reportedly shift to vibe coding more and more.

Not a member yet? *Read it here for free.*

However, I still spend 85% of my programming time (which is about 50% of my total work time) reading and writing the code rather that AI prompts. Why don’t I vibe code all the time? I’ve been thinking about it for a while and finally came up with a simple decision rule:

Will I have to support the project in the future?

By “support,” I don’t just mean adding more code. I mean managing the entire project lifecycle — scaling it, evolving it, integrating it with other services, handling production incidents, explaining features, reasoning about its guarantees, and so on.

There are plenty of cases where you don’t have to support the code you ship, for example:

• You are creating a PR to an OSS repository or to a neighboring team’s repository (I’ll expand this point below)
• You are trying out an idea for a new startup
• You are investigating what is possible and what isn’t
• You are doing freelance work
• You work for an outsourcing company
• You are leaving your current company in a month
• You need a one-off tool for the particular task
• You need to show something cool to your clients or investors

All those cases have the something in common — you get short-term gains without long-term responsibility.

You might ask: why could vibe-coding be harmful in the long term?

The answer lies in how we interact with LLMs and agents — we give them tasks. Modern agents are smart and can decide to divide task into sub-tasks, but the idea remains — agents solve tasks, they don’t have product vision. Once the task is complete, their job is done.

What are the consequences?

1. You don’t know how your code works. You might think that you can figure it out during review, but you will almost certainly miss some important details — details you wouldn’t have missed if you had written the code yourself. This creates cognitive debt, which can be even worse than traditional technical debt.
2. The code often remains mediocre. In 95% of cases (by my own estimation) the code can be improved further. But once the task is done, the AI agent stops. Because you didn’t write the code, you don’t really know how good it is. You don’t know what shortcuts the model may have taken. You don’t know whether the logic should be generalized. You don’t know whether all edge cases are covered. You don’t feel that code should be refactored. So the generated code often stays “good enough,” but not excellent.
3. Your ability to guide AI degrades. As your understanding of the project decreases, your ability to create precise tasks for models decreases as well. The quality progressively degrades.

None of this really matters if you don’t need to support the code long term. The next owner may not be happy — but they can’t stop you from using AI.

OSS: a double-edged sword. On one hand, AI allows non-experts (and experts) to fix issues that sat untouched for decades, but on the other hand, reviewing large numbers of AI-generated PRs becomes a burden for maintainers. Code becomes almost free, but its review becomes even more expensive, so I expect the number of popular free OSS projects to gradually decrease over time. Automated AI reviews do help eliminate small bugs, but they still lack vision, so they can’t replace human review anytime soon. As an active OSS maintainer I don’t want to see raw LLM output (such PRs will be immediately rejected), I want to see that contributor has filtered it through theirs brain, that they fully understand the changes and can reason about them.

The code has structure

SDD (Spec-Driven-Development) is gaining popularity. Its main premise is that it’s easier to read and write specifications than to read and write code. That may be true for project managers and business analysts, but not for me. Why?

• My main language is F#, it is one of the most readable programming languages ever created. F# allows describing domain models concisely and cleanly, compare it to an English description.

Users in our system should be identified either by numeric id
or by their login.

type UserId =
    | Id of int
    | Login of string

• Static type checking forces you to consider cases you might otherwise ignore:

There should be exist a function that creates magic link by user idendifier.

let getMagicLink userId =
    match userId with
    | Id x -> $"http://mysite.com/restore/{x}" 
    // compiler warning, login case is not handled

• Code has a single, unambiguous meaning, plain language does not. Consider this requirement: “At transfer time, take a flat fee of 10 cents from user”. The description might feel fine, but it doesn’t say whether the fee should be added on top of the transfer amount, or deducted from it, it’s up to LLM to decide. You might only discover what it decided when customers start complaining. At the same time, when writing code yourself, you are forced to make that decision explicitly.
• Code refactoring is much easier than spec refactoring (if you have a proper IDE), and I usually refactor a lot. It’s rare for me to get everything right at the first shot, second shot isn’t usually the last either, so I do change business logic, infrastructure and even architecture. And I can safely change it, because I the F# compiler helps me a lot.
• When writing code manually, I always feel progress over time. With AI agents it’s often a gamble: will it find a solution? Often yes, sometimes no. And when it fails, it’s stressful. The time has passed and you haven’t progressed at all, so you need to apply your worsening programming skills under time pressure. Prompt engineering is highly non-deterministic — and that can be exhausting.

Low-hanging fruits

Despite the downsides of the vibe coding, I must admit that there are cases where it‘s beneficial to use LLM even for the code you are going to support long term.

• Following the pattern. Sometimes additional abstraction adds no value, — for example, in unit tests. AI can generate dozens of similar unit tests in a blink of an eye, covering more cases than you would manually (but avoid generating tests without defining a pattern first). Overall, prompts like “Do X in the same way as Y is done” work quite well for me and have surprisingly many usages.
• Finding bugs. I find it the most useful application whatsoever, since almost none of the code is generated. It works best when you know the approximate location of the bug, but can’t spot it right away, LLMs are often helpful in such situations.
• Patching your knowledge gaps. You can’t be expert in everything, but LLMs can on a decent level. If the LLM produces code that — while imperfect — is still better than what you would write in that domain, use it, but still learn from it. If you don’t learn, get ready to shift your career.
• Tasks with the known desired output. For example, when you know you need to use a specific library but don’t know its API. Or you somehow receive a thorough specification that truly covers all the cases and won’t change (though I’ve never seen that in real life).
• Small in-context generations. This is where Copilot started and modern tools like Cursor or Antigravity have taken it to the next level. What I like about this mode is that it doesn’t negatively affect cognition, small completions are perceived as your own code.

I also use LLMs at work for a many other non-code purposes, like working with PDF documents, validating product and architectural ideas, researching particular topics and more, which speeds up the other 50% of my work time, but it’s the working code that I’m paid for.

Final thoughts

The more accountable and involved you are in a project— the less you should rely on vibe coding. Will such an intimate bond be needed in the long-term? I believe so, at least until we reach a crucial point where AI decides what is right and what is wrong, and I hope that moment doesn’t come soon, because at that point, developers will no longer be needed.