← Back to context

Comment by ruszki

7 days ago

That’s true, however the current vibe coding ecosystem is clearly not written in this mindset. You will have a hard time to dive into anything if you previously generated 2k LOC/hour, which is absolutely possible. Typing was never the bottleneck, understanding, and knowing that you did something well was always the real bottleneck. LLMs make this even worse. You can move Jira tickets to done faster with it, but even bad developers can do that many times compared to better ones, because for example they mindlessly copy-paste StackOverflow answers whose half of the code is absolutely not necessary, but they don’t care, because “it works”… until it doesn’t.

>LLMs make this even worse

Not in my experience

Better documentation, more test cases, and an NLP interface to query the code

Less cognitive load, more complete mental models

>even bad developers can do that many times compared to better ones, because for example they mindlessly copy-paste StackOverflow answers whose half of the code is absolutely not necessary

Maybe LLMs, much like StackOverflow, make good devs better and bad devs worse

Like a force multiplier for good practices and bad practices

  • The exact people who said to me that I’m using LLMs wrongly, and showed their code, showed me bad code. So let’s say, that “more documentation, which is unnecessary most time, ie noise, more test cases, which test not necessarily what they should, and an NLP interface which lies from time-to-time”, and we agree. LLM generated code is noisy as hell, for no good reason. Maybe, it’s good for you, and your type of work. I need to provide way better code than that. I don’t know why we pretend that “good code”, “good documentation”, “good tests” etc are the same for everybody.

    • >LLM generated code is noisy as hell, for no good reason

      You can direct it to generate code/docs in whatever format or structure you want, prioritising the good practices and avoiding bad practices, and then manually edit as needed

      For example with documentation I direct it to:

      *Goal:* Any code you generate must lower cognitive load and be backed by accurate, minimal, and maintainable documentation

      1. *Different docs answer different questions* — don’t duplicate; *link* instead.

      2. *Explain _why_, not just what.* Comments carry rationale, invariants, and tradeoffs.

      3. *Accurate or absent.* If you can’t keep a doc truthful, remove it and add a TODO + owner.

      4. *Progressive disclosure.* One‑screen summaries first; details behind links/sections.

      5. *Examples beat prose.* Provide minimal, runnable examples close to the API.

      6. *Consistency > cleverness.* Uniform structure, tone, and placement.

      I also give it a note to refuse the prompt if it cannot satisfy these conditions

      >I don’t know why we pretend that “good code”, “good documentation”, “good tests” etc are the same for everybody

      Of course code, docs, tests are all subjective and maybe even closer to an art than a science

      But there's also objectively good habits, and objectively bad habits, and you can steer an LLM pretty well