Ask HN: How can I get better at using AI for programming?
Tooling and Model Choices
- Many recommend IDE-integrated agents like Cursor or Claude Code for their UI, diff views, and context handling; some prefer lighter tools like Aider or Junie to avoid “fully agentic” complexity.
- Opus 4.5 is widely praised as a step change in code quality and adherence, though cost/latency are concerns; Sonnet, GPT‑5.2, Gemini 3, and others are compared with mixed results per language/stack.
- Some prefer open-source + local or cheaper stacks (Zed + Gemini/Qwen, Aider + Claude/Gemini), especially for privacy or performance.
- Svelte/SvelteKit is seen as a weak spot for models (especially Svelte 5/runes) compared to React.
Effective Workflows and Planning
- Strong emphasis on planning: write a concise spec/plan.md, architecture/ARCHITECTURE.md, and then implement in small, verifiable steps.
- Use planning modes or DIY planning docs: let the model propose a plan, iterate on it, then execute step-by-step, often in fresh sessions.
- Break work into tiny, testable tasks; avoid “one-shot” large features or letting agents freely roam a large repo.
- For migrations/refactors: first do a mechanical translation that preserves behavior (plus tests), then a second “quality” pass to make code idiomatic.
Prompting, Context, and Interaction Style
- Be extremely specific: define “idiomatic code” with concrete good/bad examples; describe conventions, allowed libraries, and test expectations.
- Long, rich prompts and “context engineering” (including CLAUDE.md/AGENTS.md, example commits, rules files) significantly improve results, but overlong or conflicting instructions degrade them.
- Voice-to-text is popular for fast, detailed prompts; many use desktop dictation tools and then paste into agents.
- Treat the model like a junior dev or thinking partner: discuss architecture, ask it to restate requirements, and refine designs before coding.
Guardrails, Testing, and Code Quality
- Consensus: you must have verification. Common guardrails:
- TDD/BDD, cucumber-style tests, or external test harnesses.
- Linters, type-checkers, project-specific prebuild scripts enforcing style/architecture rules.
- Browser automation (Playwright/Puppeteer) or other tools the agent can run to check its work.
- Many report AI-written code is often sloppy, inconsistent, or subtly wrong; careful review of every line is still required, especially for security-critical code.
- Some advise never trying to “train” the model mid-session beyond a point—start a new chat, reload key context, and avoid context rot.
Where AI Helps vs Where It Fails
- Works well for:
- Repetitive transformations (many similar routes/components, metrics wiring, boilerplate, tests, refactors).
- “Software carpentry”: file moves, API wrappers, basic data processing, summaries, commit messages.
- Explaining unfamiliar code or libraries and brainstorming alternative designs.
- Struggles with:
- Novel, architecture-heavy problems; large, messy legacy codebases; tasks requiring deep domain understanding.
- Some languages/frameworks (reports of poor Java and Svelte support, model-dependent).
- Long, autonomous agent runs without tight constraints or tests.
Debates on Adoption, Skills, and Reliability
- Some claim 5–20x productivity boosts in specific, repetitive scenarios; others see only modest gains and significant review/maintenance burden.
- Strong split between:
- Those who use AI mainly as a high-level thinking partner and targeted helper.
- Those trying to offload whole features to agents, often ending up with brittle, poorly understood code.
- Concerns include skill atrophy, overreliance on non-deterministic tools, unstable “best practices,” and lack of evidence of large, high-quality AI-driven OSS contributions.
- A minority advises not using AI unless required, arguing that strong foundational skills + later adoption will age better than early “vibe coding” habits.