Hacker News Reader

Comment by nzach | Hacker News Reader

>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.

View on HN

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.

You can do both

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?

It is mostly because it creates code that is way more complex than it needs to.

One, admittedly silly, example is Claude trying to put a light/dark theme switcher when you are trying to refactor the style of your small webapp.

I'm not against a theme switcher, but it is certainly not a trivial feature to implement. But Claude doesn't seem to understand that. And by having simpler prompts I feel it gets easier to steer the LLM in the right direction.

You created markdown files with hundreds of lines and this was the result? I let it create task lists in md files, and review regularly. Works well for me as the scope of the tasks is well defined. Sure, sometimes it still does bad things, but I consider it just another junior dev, but with vast knowledge.

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.

Reply on news.ycombinator.com