Just one person's opinion: I can't get into the mode of programming where you "chat" with something and have it build the code. By the time I have visualized in my head and articulated into English what I want to build and the data structures and algorithms I need, I might as well just type the code in myself. That's the only value I've found from AI: It's a great autocomplete as you're typing.

To me, programming is a solo activity. "Chatting" with someone or something as I do it is just a distraction.

▲

whynotminot 6 days ago | parent | next [-]

A good part of my career has been spent pair programming in XP-style systems, so chatting away with someone about constraints, what we're trying to do, what we need to implement, etc, might come a bit more naturally to me. I understand your perspective though.

▲

skydhash 6 days ago | parent [-]

That may be one of the reason for the conflict of opinions. I usually build the thing mentally first, then code it, and then verify it. With tools like linters and tests, the shorter feedback make the process faster And editor fluency is a good boost.

By the time, I'm about to prompt, I usually have enough information to just code it away. Coding is like riding a bicycle downhill. You just pay enough focus to ride it. It's like how you don't think about the characters and the words when you're typing. You're mostly thinking about what you want to say.

When there's an issue, I switch from coding to reading and thinking. And while the latter is mentally taxing, it is fast as I don't have to spell it out. And a good helper to that is a repository of information. Bookmarks to docs, documentation browser, code samples,.. By the times the LLM replies with a good enough paragraph, I'm already at the Array page on MDN.

▲

lazyasciiart 6 days ago | parent [-]

Having it write unit tests has been one place it is reliably useful for me. Easily verifiable that it covers everything I’d thought of, but enough typing involved that it is faster than doing it myself - and sometimes it includes one I hadn’t thought of.

▲

skydhash 6 days ago | parent [-]

I’ve read somewhere, IIRC, that you moslty need to test three things: Correct input, incorrect input, and input that are on the fence between the two. By doing some intersection stuff (with the set of parameters, behavior that are library dependent), you mostly have a few things left to test. And the actual process of deciding on which case to test is actually important as that is how you highlight edge cases and incorrect assumptions.

Also writing test cases is how you experience the pain of having things that should not be coupled together. So you can go refactor stuff instead of having to initialize the majority of your software.

	▲	lazyasciiart 6 days ago \| parent [-]
		If you need to hand write tests to think through all that then sure, don’t let an AI do it for you.

▲

nicwolff 5 days ago | parent | prev | next [-]

I'm not chatting with the LLM – I'm giving one LLM in "orchestrator mode" a detailed description of my required change, plus a ton of "memory bank" context about the architecture of the app, the APIs it calls, our coding standards, &c. Then it uses other LLMs in "architect mode" or "ask mode" to break out the task into subtasks and assigns them to still other LLMs in "code mode" and "debug mode".

When they're all done I review the output and either clean it up a little and open a PR, or throw it away and tune my initial prompt and the memory bank and start over. They're just code-generating machines, not real programmers that it's worth iterating with – for one thing, they won't learn anything that way.

▲

tempodox 6 days ago | parent | prev [-]

That's my basic doubt, too. When developing software, I'm translating the details, nuances and complexities of the requirements into executable code. Adding another stage to this process is just one more opportunity for things to get lost in translation. Also, getting an LLM to generate the right code would require something else than the programming languages we know.