The thread on Hacker News centers on a tolki.dev post titled ´the current state of LLM-driven development´ and the author´s conclusion after roughly four weeks of experimenting with various tools. Commenters pushed back hard. Many argued the essay reflected a narrow, individual trial rather than a community-level assessment, and several people pointed out specific omissions or configuration mistakes that undercut the author´s claims.
Discussion split along familiar lines: some say using LLMs in a coding workflow is trivial to begin and easy to dismiss if they don´t immediately fit; others insist that achieving reliable, repeatable productivity requires non-trivial practice. Contributors described a variety of concrete factors that matter: per-codebase ramp time, differences between models and client integrations, IDE versus terminal workflows, repomap or LSP navigation versus ad hoc grep, and agentic setups that can conflict when run in parallel. Popular tools named in the thread included Copilot, Claude Code, Gemini, Opus and various CLIs, with examples showing that one model may discover different parts of a codebase than another.
Practical use cases emerged from the conversation. Several users reported strong wins on greenfield scaffolding and repetitive tasks like generating k8s manifests, docker files, README and deployment stubs. Others emphasised that tests and running toolchains dramatically reduce hallucination and scope errors; telling an assistant to write a test, run it, then implement to satisfy it was called out as a particularly effective loop. At the same time, contributors warned that LLMs struggle with bespoke business logic, large complex codebases and tasks not well represented in training data.
Broader themes threaded the thread: difficulty of measuring gains because of non-determinism; corporate hype and virtue signalling versus on-the-ground practice; price and environmental quibbles about expensive models; and the recurring advice to adapt workflows. Commenters recommended bringing ´taste and critical thinking´, packaging up up-to-date context for prompts, using repomap/LSP where helpful, and preferring a stub-plus-review approach. The consensus was that LLMs are powerful but not magical, they can raise the floor for many tasks, and they demand process changes and experience to be reliably useful rather than replacing software engineering fundamentals.