Ask HN: How can I get better at using AI for programming?

That $200 a month is getting me $2000 a month in API equivalent tokens.

I used to spend $200+ an hour on a single developer. I'm quite sure that benevolence was a factor when they submitted me an invoice, since there is no real transparency if I was being overbilled or not or that the developer acted in my best interest rather than theirs.

I'll never forget that one contractor who told me he took a whole 40 hours to do something he could have done in less than that, specifically because I allocated that as an upperbound weekly budget to him.

I take these early reports (less than a week or two after a major model release) with a grain of salt. It takes time to get to know a model, and maybe there's some selection bias in who's posting within 1-2 days of getting access.

(Although in this particular case, the very different knowledge cutoff makes it a lot easier to believe)

first off, drop the idea of coding "agents" entirely. semi-async death valley is not worth it, you will never get into the flow state with an "agent" that takes less than an hour to spin, and we did not learn how to make true async agents that run for this long while maintaining coherence yet. OpenAI is the closest in that regard, but they are still at a 20-minute mark, so I am not dropping the quotes for now.

another argument against letting LLM do the bulk of the job is that they output code that's already legacy, and you want to avoid tech debt. for example, Gemini still thinks that Kotlin 2.2 is not out, hence misses out on context parameters and latest Swift interoperability goodies. you, a human being, are the only one who will ever have the privilege of learning "at test time", without separate training process.

replace coding "agents" with search tools. they are still non-deterministic, but hey, both Perplexity and Google AI Mode are good at quick lookup of SvelteKit idioms and whatnot. plus, good old Lighthouse can point out a11y issues - most of them stem from non-semantic HTML. but if you really want to do it without leaving a terminal, I can recommend Gemini CLI with some search-specific prompting. it's the only CLI "agent" that has access to the web search to my knowledge. it's slower than Perplexity or even ChatGPT Search, but you can attach anything as a context.

this is the true skill of "how to use AI" - only use it where it's worth it. and let's be real, if Google Search was not filled with SEO crap, we would not need LLMs.

concise answers are the best, and I agree with that one.

I am still curious, why? I have my own set of why's and want to hear yours

Automated code checks. Either custom linter rules (like ESLint) or prebuild scripts to enforce whatever architectural or style rules you want, basically all of the stuff that you'd normally flag in code review that can be codified into an automatic check but hasn't been before due to developers either not finding it worth their time to do it, or not having enough time or skill to do that - use the AI to write as many of these as needed, just like:

  node prebuild/prebuild.cjs

which will then run all the other checks you've defined like:

  prebuild/ensure-router-routes-reference-views-not-regular-components.cjs
  prebuild/ensure-custom-components-used-instead-of-plain-html.cjs
  prebuild/ensure-branded-colors-used-instead-of-tailwind-ones.cjs
  prebuild/ensure-eslint-disable-rules-have-explanations.cjs
  prebuild/ensure-no-unused-translation-strings-present.cjs
  prebuild/ensure-pinia-stores-use-setup-store-format.cjs
  prebuild/ensure-resources-only-called-in-pinia-stores.cjs
  prebuild/ensure-api-client-only-imported-in-resource-files.cjs
  prebuild/ensure-component-import-name-matches-filename.cjs
  prebuild/disallow-deep-component-nesting.cjs
  prebuild/disallow-long-source-files.cjs
  prebuild/disallow-todo-comments-without-jira-issue.cjs
  ...

and so on. You might have tens of these over the years of working on a project, plus you can write them for most things that you'd conceivably want in "good code". Examples above are closer to a Vue codebase but the same principles apply to most other types of projects out there - many of those would already be served by something like ESLint (you probably want the recommended preset for whatever ruleset exists for the stack you work with), some you'll definitely want to write yourself. And that is useful regardless of whether you even use AI or not, so that by the time code is seen by the person doing the review, hopefully all of those checks already pass.

If "good code" is far too nebulous of a term to codify like that, then you have a way different and frankly more complex problem on your hands. If there is stuff that the AI constantly gets wrong, you can use CLAUDE.md as suggested elsewhere or even better - add prebuild script rules specifically for it.

Also, a tech stack with typing helps a bunch - making wrong code harder to even compile/deploy. Like, with TypeScript you get npm run type-check (tsc) and that's frankly lovely to be able to do, before you even start thinking about test coverage. Ofc you still should have tests that check the functionality of what you've made too, as usual.