I use AI as a pairing buddy who can lookup APIs and algorithms very quickly, or as a very smart text editor that understands refactoring, DRY, etc. but I still decide the architecture and write the tests. Works well for me.

Apparently what the article talks against is using it like software factory - give it a prompt of what you want and when it gets it wrong, iterate on the prompt.

I understand why this can be a waste of time: if programming is a specification problem [1], just shifting from programming language to natural language doesn’t solve it.

1. https://pages.cs.wisc.edu/~remzi/Naur.pdf

currently on HN's front page we have write the damn code, and write the stupid code, but we don't have write the good code.

Yup. It's not the learning AI or prompt engineering is bad in anyway. A similar writeup https://news.ycombinator.com/item?id=45405177 mentions the problem I see: when AI does most of the work, I have to work hard to understand what AI wrote.

In your model, I give enough guidance to generally know what AI is doing, and AI is finishing what you started.

I kinda agree with the author — as a person with more than enough coding experience I don't get much value (and, certainly, much enjoyment) from using AI to write code for me. However it's invaluable when you're operating in even a slightly unfamiliar environment — essentially, by providing (usually incorrect or incomplete) examples of the code that can be used to solve the problem it allows to overcome the main "energy barrier" for me — helping to navigate e.g. the vast standard library of a new programming language, or provide idiomatic examples of how to do things. I usually know _what_ I want to do, but I don't know exactly the syntax to express it in a certain framework or language

I think about 2 months ago my company got a license for Cursor/claude ai access.

At first it was really cool getting an understanding of what it can do. It can be really powerful, especially for things like refactoring.

Then, I found it to be in the way. First, I had to rebind the auto-insert from TAB to ctrl+space because I would try tabbing code over and blamo: lines inserted, resulting in more work deleting them.

Second, I found that I'd spend more time reading the ai generated autocomplete that pops up. It would pop up, I'd shift focus to read what it generated, decide if it's what I want, then try to remember what the hell I was typing.

So I turned it all off. I still have access to context aware chats, but not the autocomplete thing.

I have found that I'm remembering more and understanding the code more (shocking). I also find that I'm engaging with the code more: taking more of an effort to understand the code

Maybe some people have the memory/attention span/ability to context switch better than me. Maybe younger people more used to distractions and attention stealing content.

Precisely. That's the most optimal way to use AI code assistants right now.

If you keep on refining the prompts, you are just eating the hype that is designed to be sold to C Suite.

AI is pretty good on CRUD web app for me. I worked out a web page for create something and if the next page is similar. i just told AI to use the previous page as template. it cut down a lot of typing.

AI is just another tool, use it or turn it off. it shouldn't matter much to a developer.

IMO no one is taking even the first bit of software development advice with Llms.

Today my teammate laughed off generating UI components to quickly solve a ticket. Knowing full well no one will review the ticket now that it’s Llm generated and that it will probably make our application slower because of the unreviewed code gets merged. The consensus is that anything they make worse, they can push off to fix onto me because I’m the expert on our small team. I have been extremely vocal about this. However It is more important to push stuff through for release and make my life miserable than make sure the code is right.

Today I now refuse to fix anymore problems on this team and might quit tomorrow. This person tells me weekly they always want to spend more time writing and learning good code and then always gets upset when I block a PR merge.

Today I realized I might hate my current job now. I think all Llms have done is enabled my team to collect a pay check and embrace disinterest.

Unless you're solving the same old problem for the Nth time for a new customer, you don't really understand the problem fully until you write the code.

If it's a new problem, you need to write the code so that you discover all the peculiar corner cases and understand them.

If it's the (N+M)th time, and you've been using AI to write the code for the last M times, you may find you no longer understand the problem.

Fair warning. Write the damn code.

The approach of treating the LLMs like a junior engineer that is uninterested in learning seems to be the best advice, and correctly leverages the existing intuitions of experienced engineers.

Spend more time on interfaces and test suites. Let the AI toil away making the implementation work according to your spec. Not implementing the interface is a wrong answer, not passing the tests is a wrong answer.

If you've worked in software long enough you will have encountered people who are uninterested in learning or uncoachable for whatever reason. That is all of the LLMs too. If the LLM doesn't get it, don't waste your time; it will probably never get it. You need to try a different model or get another human involved, same as you would for an incompetent and uncoachable human.

As an aside: my advice to junior engineers is to show off your wetware, demonstrate learning and adaptation at runtime. The models can't do that yet.

> Ask AI for an initial version and then refactor it to match your expectations.

> Write the initial version yourself and ask AI to review and improve it.

> Write the critical parts and ask AI to do the rest.

> Write an outline of the code and ask AI to fill the missing parts.

So well put. I'm writing these on a post it note and putting it above my monitor. I held off on using agents to generate code for a long time and finally was forced to really make use of them and this is so in line with my experience.

My biggest surprises have been how much the model doesn't seem to matter (?) when I'm making the prompts appropriately narrow. Also surprised at how hard it is to pair program in something like cursor. If your prompting is even slightly off it seems like it can go from 10xing a build process to making it a complete waste of time with nothing to show but spaghetti code at the end.

Anyway long live the revolution, glad this was so technically on point and not just a no-ai rant (love those too tho).

Yes, you could write the code yourself, but keep in mind that this activity is going away for most engineers (but not for all) in 1 - 2 years.

I think a better advice would be to learn reading/reviewing an inordinate amount of code, very fast. Also heavy focus on patterns, extremely detailed SDLC processes, TDD, DDD, debugging, QA, security reviews, etc...

Kinda the opposite advice from the blog. :-)

Edit: Somebody pointed out that, in order to read/review code, you have to write it. Very true. It brings a questions of how do you acquire/extend your skills in the age of AI-coding assistance? Not sure I have an answer. Claude Code now has /output-style: Learning, which forces you to write part of the code. That's a good start.

Yes! I could not agree more with this sentiment.

We over-analyse, over discuss, over plan and over optimize before we even write the first import or include.

Some of my best ideas came to me as I was busy programming away at my vision. There's almost a zen like state there

Write the code, deploy.

the end

Blessings, brother, but this insight will never get through to the masses. I can bet about it, so no rage.

This is exactly how I work and I feel like the tools don't accomodate this workflow. I shouldn't have to tell the agent to explicitly re-read the a file after every edit.

"Two prompts and then do it yourself" is a pretty good heuristic. Last year I was simulating a boardgame [1] and wasted ~1 hour trying to get ChatGPT to solve a basic coding combinatorics problem. I needed a method in python to generate all possible hand decisions a player could make. I couldn't make it understand that certain choices were equivalent

[1] https://arthur-johnston.com/paths_of_civ_tech_tree/

What's up with the "prompt refinement" business? Are folks trying to get it right with one shot?

My experience is that treating the generated code as a Merge Request on which you submit comment for correction (and then again for the next round) works fairly well.

Because the AI is bad you get more rounds than in a real code review, but because the AI is fast and in your command each round is way faster than with a code review with a human (< 10 minutes feedback loop).

I wonder how many devs _bear_ current LLM coding tools just because afraid of getting "out of the loop". My experience that if I'm struggling with a problem, LLM would rather waste my time than help.

>If, given the prompt, AI does the job perfectly on first or second iteration — fine. Otherwise, stop refining the prompt. Go write some code, then get back to the AI. You'll get much better results.

This is terrible advice.

Why would I go through the write, run, debug loop myself when I can just have cc do it?

I think when the answer becomes more important than the journey, AI tools become more valuable. Want to figure out why a bug is occurring? Tools like Claude Code can be great for this. Implementing a new API or feature? You’ll have to read all the code it wrote, and if you’re like most software engineers, you’ll be faster at writing code than reading it. So you might as well just write it yourself.

This has helped to explain why, at least for me, LLMs have been more useful for reading code than writing code. I’m also just reluctant to submit the code it’s written on my behalf without making hundreds of small adjustments, but I think I’ll need to get over that, as I wouldn’t be so nit-picky a junior engineer were completing the task.

I argue that if using a llm that has been trained on 'human' text is a cause for more troubles when used to code opposed to when one uses a model trained only code allow me to explain: If one uses models only trained on code all one has to do is to write the instructions as a comment at the top of the document and the llm will do the rest: ``` #The Following piece of code #Shall be written in python #The goal of the code is to #Scrape news.ycombinator.com #Fetching the last 10 posts #using requests and BS4 #The output shall be parsed #Title and corresponding url ``` In fact if the model used is not capable to finnish the script at this point it means that the model cannot code,

I would not recommend iterating too much with AI. On the contrary, do "milestones" and solve the smaller problems independently.

If the context window is full, better save the progress by reformulating the problem and prompt the AI with the progress you made before. A new start with an empty context.

In my experience any coding AI starts with really good code and it goes down from there.

learn to decompose is probably the most rage-baiting phrase I've heard in a long time. Breaking down a problem into smaller parts is not "decomposing"