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.