>Provide detailed specifications for the work to be done

I've been playing around with vibe coding for a few months and my experience doesn't really match this advice.

I used to think this was the correct way and based on that was creating some huge prompts for every feature. It took the form of markdown files with hundred of lines, specifying every single detail about the implementation. It seems to be an effective technique at the start, but when things get more complex it starts to break down.

After some time I started cutting down on prompt size and things seem to have improved. But I don't really have any hard data on this.

If you want to explore this topic one thing you can do is to ask you LLM to "create a ticket" for some feature you already have, and try to play around with the format it gives you.

Everytime I see these tips and tricks, it reinforces my viewpoint thag it would be more productive to actually learn the abstractions of your framework and your tooling. Instead of wrestling with a capricious agent.

Thinking is always the bottleneck, so what you need most are:

- A reduction of complexity in your system.

- Offloading trivial and repetitive work to automated systems (testing, formatting, and code analysis)

- A good information system (documentation, clear tickets, good commits,…)

Then you can focus on thinking, instead of typing or generating copious amount of code. Code is the realisation of a solution that can be executed by machines. If the solution is clear, the code is trivial.

I have found it better to have stronger scope for 2nd and 3rd iteration feature sets in mind.. refactoring because you didn't think you'd be adding a certain kind of feature or filter or database scope is worse than knowing ahead of time that's where you were going.

A little different than "spec", but one-shotting things works great if that's going to get you as far as you want to go. If you're adding neat-o features after that, it can get a little messy because the initial design doesn't bend to the new idea.

Even something like adding anti-DDOS libraries towards the end, and then having to scope those down from admin features. Much better to spec that stuff at the outset.

I have found putting the spec together with a model, having it to try find blindspots and write done the final take in clear and concise language, useful.

A good next step is to have the model provide a detailed step by step plan to implement the spec.

Both steps are best done with a strong planning model like Claude Opus or ChatGPT5, having it write "for my developer", before switching to something like Claude Code.

This approach also breaks down for the same reasons the Waterfall model doesn't work. A lot of information is discovered during development, which causes specs to be outdated or wrong. At that point the LLM context is deeply poisoned, whether from the specs themselves, or from the rest of the codebase. You can try to update the specs or ask for major refactors, but that often introduces new issues. And as the context grows, the chances of producing working code diminish significantly. The only way forward at that point is to dive in yourself, reviewing, fixing, and refactoring the traditional way, and wondering whether this workflow has really made you any more productive.

Couldn't agree with this sentiment more.

I think it might have something to do with context rot that all LLMs experience now. Like each token used degrades the token after it, regardless of input/output.

How does it break down? Is it because the LLM didn't follow what you wrote down?

That's how I've been doing it as well. There's no guarantee that the LLM will follow your minute, detailed, description, and dumping it all at once at the start of a session has made it perform worse in my case.

And, you know, LLMs are mostly dumb typists, but sometimes they do dump something better than what I had in mind, and I feel that I lose that if I try to constrain them.