I trusted an LLM, now I'm on day 4 of an afternoon project
Large language models used as coding assistants are likened to overconfident junior developers: fast and useful for boilerplate, research, and well-trodden problems, but prone to subtle bugs and confident hallucinations that can waste days if not closely supervised. Many engineers report major productivity gains when they already understand the domain and use AI for scaffolding or translation-like tasks, while others find it slower than traditional search for anything niche, hardware-related, or conceptually complex. A recurring theme is that these tools amplify existing skill: experienced developers can wield them as powerful accelerators, whereas less experienced coders risk over-reliance, weakened learning, and messy codebases.
Role of LLMs: Junior Dev, Tool, or Copilot?
- Many frame LLMs as “junior devs faking competence” or “cocky grads”: can be productive but require heavy supervision.
- Others say that’s the wrong framing: LLMs don’t learn or build trust over time; the human is the one who improves at “AI wrangling.”
- Several argue they’re closer to power tools or nail guns than coworkers: massive leverage if you’re in control, dangerous if you aren’t.
- Some push back on “we’re not expecting a copilot” because commercial products are explicitly marketed as such.
Where They Work Well
- Boilerplate, scaffolding, repetitive translation (e.g., SDKs across languages, Rust no_std setups, WASM SIMD optimizations).
- Acting as an “augmented search engine” or fluent interface to docs/Stack Overflow: surfacing concepts, APIs, package options, RFC details.
- Placeholder or mundane code (tests, endpoints, simple screens), code completion/autocomplete, and research on common topics.
- Learning aid for some: interactive tutoring, synthesizing tutorials and Wikipedia-like content, generating questions from notes.
Where They Fail or Mislead
- Niche, hardware, and low-level work (Raspberry Pi/Arduino, Linux device trees, USB quirks, C alignment rules) where training data is noisy or sparse.
- Subtle logic, TS generics, UI/UX details, multi-component interactions, and “second-order” issues.
- Hallucinated APIs/behaviors, plausible but wrong math, and inability to admit ignorance.
- Long conversations accumulating context drift; repeated “fixes” that reproduce the same bug; 99%-right code that hides a brutal 1% error.
Effective Usage Patterns
- Seniors or people with strong fundamentals benefit more: they can say “this is obviously wrong” and use LLMs for acceleration, not substitution.
- Strategies:
- Maintain explicit specs/CONVENTIONS and feed them in each time.
- Use LLMs to generate tests/boilerplate, then do refactoring and design yourself.
- Restart chats when the model gets stuck; load specific docs instead of relying on generic knowledge.
- Use adversarial/custom prompts to fight sycophancy and force self-critique.
Broader Concerns and Disagreements
- Split between users who find LLMs transformational for side projects and those who waste days in “wild goose chase” debugging.
- Worry that juniors will become dependent and never build deep skills, while seniors get even more leverage (“LLM paradox”).
- Skepticism about hype that frames LLMs as imminent job-killers; many see them instead as mess-creators demanding more human oversight.