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

Please for once answer the question being asked without replacing both the question and the stated intention with something else. I was willing to give you the benefit of doubt, but I am now really wondering where does your motivation for these vaguely constructed "analogies" coming from, is the LLM industry that desperate? We were all "positive" about LLM possibilities once. I am asking you, when will LLMs be so reliable that they can be used in place of service dogs for blind people ? Do you believe that this technology will ever be that safe. Have you ever actually seen a service dog? I don't think you can distract a service dog with a steak - did you know they start their training basically from year one of age and it takes up to two years to train them. Do you think they spend those two years learning to fetch properly? Also I never said people should not be allowed to "try" a technology. But like with drugs, the tools for impaired, sick etc. also undergo a verification and licensing process, I am surprised you did not know that. So I am asking you again, can you ever imagine an LLM passing those high regulatory hurdles, so that they can be safely used for assisting the impaired people? Service dogs must be doing something right, if so many of them are safely assisting so many people today, don't they ?

I spend a lot of time teaching people AI by having them bring their own idea that we build it over a three-hour workshop. [1]

The workshop starts off with a very simple premise. I ask people to write their idea down in a Google Doc with all the details they need to hand it off to an AI, so the AI can build it autonomously.

What people discover is that communicating your idea is MUCH harder than they thought. They often write a few sentences or a paragraph, and I plainly ask them "if you gave this to a junior developer do you think they'd be able to build your idea?" They say of course not, and we try again.

We do a v2, a v3, a v4, and so on, while we talk through their ideas, develop new ideas ideas to improve their prompt, and I teach them about how AI can make this process easier. The workshop goes on and on and on like this, until we have a page or two of context. Finally we can hand the idea off to AI, and boom — a few minutes later they either have their idea or they have something we can quickly mold into their vision.

This part of the process is where I think most people struggle. People think they're good communicators, but they only realize how much work it is to communicate their ideas once they are faced with the prospect of clearly describing their problem and writing it down in front of another person.

I say this not to try to shill my workshops, but to say that the results are spectacular for a simple reason. Describing the problem well is 80% of the work, but once you do that and do it well — AI can take over and do a genuinely excellent job.

I often joke at the end of my workshops that I call these AI workshops, but it's effectively a three hour workshop on communication. Most software developers wouldn't pay much for a communication workshop even if it makes them more effective at using tools like Claude Code, Codex, or even vibe coding, so I wrap everything up in a neatly AI sandwich. :)

[1] https://build.ms/ai

> I see it as a competent software developer but one that doesn't know the code base.

I know what you mean, but the thing I find windsurf (which we moved to from copilot) most useful (except writing opeanapi spec files) is asking it questions about the codebase. Just random minutiae that I could find by grepping or following the code, but would take me more than the 30s-1m it takes it. For reference, this is a monorepo of a bit over 1M LoC (and 800k YAML files, because, did I mention I hate API specs?), so not really a small code base either.

> I will break down the tasks to the same size as if I was implementing it. But instead of doing it myself, I roughly describe the task on a technical level (and add relevant classes to the context) and it will ask me clarifying questions. After 2-3 rounds the plan usually looks good and I let it implement the task.

Here I disagree, sort of. I almost never ask it to do complex tasks, the most time consuming and hardest part is not actually typing out the code, describing it to an AI takes me almost as much time as implementing for most things. One thing I did find very useful is the supertab feature of windsurf, which, at a high level, looks at the changes you started making and starts suggesting the next change. And it's not only limited to repetitive things (like . in vi), if you start adding a parameter to a function, it starts adding it to the docs, to the functions you need below, and starts implementing it.

> For me this method allows me to focus on the architecture and overall structure and delegate the plumbing to Copilot.

Yeah, a coworker said this best, I give it the boring work, I keep the fun stuff for myself.

I don't think that long, but yeah, I give it five years.

Two years and 3/4 will be not needed anymore

I'm a day late and I see so much advice here, but I see little mention of what made the most difference to me: lean into TDD.

Building tests first has always been a strong methodology, but with AI support its both far less work AND you get double dividends, because your test becomes the spec the AI needs to follow but it's an executable, verifiable one. So as you give it more requirements, it's automatically finding and fixing its mistakes along the way.

In terms of having it code how you like: nothing beats putting examples into AGENTS.md / CLAUDE.md etc. Give it some examples of how you like it, and say this is how the code is written. Make remarks about why as well, put the design philosophy in too.