Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The AI coding trap

chrisloy.dev

Post reply on HN
Print view View original

221–230 of 424 posts

Re: The AI coding trap

#221

Post by onion2k »

tptacek wrote: post #2

It's a fine post, but two canards in here: First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down. In fact: I do a lot, lot more thinking and balancing different designs and getting a macro sense of where I'm going, because that's usually what it takes to get an LLM agent to build something decent. But now that pondering and planning…

Most of my initial prompts to agents start with "DO NOT WRITE ANY CODE YET."

Copilot has Ask mode, and GPT-5 Codex has Plan/Chat mode for this specific task. They won't change any files. I've been using Codex for a couple of days and it's very good if you give it plenty of guidance.

Re: The AI coding trap

#222

Post by mwcz »

benoau wrote: post #124
strogonoff wrote: post #121

Earlier quoted context omitted.

I never made a case against LLMs and similar ML applications in the sense that they negatively impact mental agility. The cases I made so far include, but are not limited to: — OSS exploded on the promise that software you voluntarily contributed to remains to benefit the public, and that a large corporation cannot tomorrow simply take your work and make it part of their product, never contributing anything back. Com…

> — The ends don’t justify the means. IP theft that lies in the beginning of this new wave of applied ML is essentially piracy Isn't "AI coding" trained almost entirely on open source code and published documentation?

Yes, open source works whose licenses constrain derivative works.

Re: The AI coding trap

#223

Post by jsmith99 »

6thbit wrote: post #203

Jumping straight into coding is a very junior thing to do. Using Plan mode in Cline or other agent based workflows is day and night in the outputs. Alas, at least in Cline it seems plan mode doesn’t read files just works off context which is insane to me and hinders its usefulness, anyone know why that happens?

Cline plan mode doesn't tend to read files by default but you can tell it 'read all files necessary to establish a detailed plan'. GPT5 also seems more eager to read files.

Re: The AI coding trap

#224

Post by thisisit »

t0mas88 wrote: post #85
lelanthran wrote: post #80

Earlier quoted context omitted.

> If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting. This argument is wearing a little thin at this point. I see it multiples times a day, rephrased a little bit. The response, "How well do you think your thinking will go if you had not spent years doing the 'practice' part?" , is always followed by either silence or a non…

Separate from AI, as your role becomes more tech lead / team lead / architect you're also not really "doing" as much and still get involved in a lot of thinking by helping people get unstuck. The thinking part still builds experience. You don't need to type the code to have a good understanding of how to approach problems and how to architect systems. You just need to be making those decisions and gaining experience…

> Separate from AI, as your role becomes more tech lead / team lead / architect you're also not really "doing" as much and still get involved in a lot of thinking by helping people get unstuck

True. But the roles as such require you to do a lot of thinking by helping a LOT of people. You end up shuffling between multiple projects/deliverables. Here we are talking about probably a developer working on a single project/deliverable and then equating it to AI. Not to mention the easy to forget part is that by the time you are a tech lead / team lead / architect you have so many hours that you know some stuff like back of your hand.

Re: The AI coding trap

#225

Post by skydhash »

lukaslalinsky wrote: post #192
skydhash wrote: post #156

Earlier quoted context omitted.

> You can have it read code, explain why was it done this or that way, The thing is that, once you're experienced enough, it's faster to just glance at the code and have the answer right, instead of playing the guessing game with AI. > and once it has the context you ask to think about implementing feature X I'm always amazed at someone using that methodology. When I think about a feature, first is to understand the…

I'm not sure where is the misunderstanding but your second paragraph is exactly why I ask AI the questions you question in the first paragraph. I ask the AI to do the domain research, see what we are starting from and THEN ask it to think about a feature. They are not really for me, they are for the AI to have good context what we are working on. As you said, the implementation is then almost trivial and the AI is le…

The thing is, the domain is often more difficult than the actual implementation. And often only a subset matters (different for each task). So I’m wondering if teaching the AI the correct subdomain is indeed faster than just code the solution.

Also trivial work can benefit the coder. Like a light jog between full sprints for your brain. Reviewing code can be more taxing than writing it as you need to retieve the full context at once instead of incremental steps.

Re: The AI coding trap

#227

Post by kiitos »

reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

> If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting...

What about if the "knowing/understanding" bit is your favorite part?

Re: The AI coding trap

#228

Post by rapind »

lelanthran wrote: post #122
t0mas88 wrote: post #85

Earlier quoted context omitted.

Separate from AI, as your role becomes more tech lead / team lead / architect you're also not really "doing" as much and still get involved in a lot of thinking by helping people get unstuck. The thinking part still builds experience. You don't need to type the code to have a good understanding of how to approach problems and how to architect systems. You just need to be making those decisions and gaining experience…

> You just need to be making those decisions and gaining experience from them. The important part that everyone glosses over is the "gaining experience" part. The experience you gained writing code lead to you being tech lead / team lead /architect. The experience you get from those roles, including "helping people get unstuck", makes you valuable because there are people involved, not just technology. IOW, that is d…

> The only "experience" you get with LLM is "put another coin into the slot and pull the lever again".

I relate it to directors on a production. It's certainly very valuable to know how to operate a camera, and especially to understand lighting, storytelling, etc. It gives you insight in how to work with the people who are actually doing these tasks. It helps you to know when someone is gaslighting you, etc.

That being said, it's kind of an insane statement to say that all a director does is pull a lever. I'm sure there are a ton of wannabe directors who try to do exactly that and proceed to fail miserably if they don't adapt quickly to reality. But having a great director is obviously a huge differentiator in output.

Do I think we'll have as many programmers in the future as we do today? Probably not. I think we're going to see a real decimation of coders, but at the same time we might (I say "might") see much greater overall production that may not otherwise exist from the less talented vibers or w/e ridiculously critical name you want. Some of that is certainly going to be interesting and maybe even radically game changing.

IMO our feelings about this are about as relevant as shaking our fist at the cosmos.

Re: The AI coding trap

#229

Post by kiitos »

johnisgood wrote: post #217
godelski wrote: post #198

Earlier quoted context omitted.

(Adding to your comment, not disagreeing) > The argument is that this technology leads people to be careless. And this will always be a result of human preference optimization. There's a simple fact: humans prefer lies that they don't know are lies over lies that they do know are lies. We can't optimize for an objective truth when that objective truth doesn't exist. So while doing our best to align our models they mu…

I use LLMs for coding and I like it the way I am using it. I do not outsource thinking, and I do not expect it to know what I want without giving it context to my thoughts with regarding to the project. I have written a 1000 LOC program in C using an LLM. It was a success. I have reviewed it "line by line" though, I do not know why I would not do this. Of course it did not spit out 1000 LOC from the get go, we starte…

nobody in this or any meaningful software engineering discussion is talking about software projects that are 1000, or even 10000, SLoC. these are trivial and uninteresting sizes. the discussion is about 100k+ SLoC projects.

Re: The AI coding trap

#230

Post by johnisgood »

kiitos wrote: post #229
johnisgood wrote: post #217

Earlier quoted context omitted.

I use LLMs for coding and I like it the way I am using it. I do not outsource thinking, and I do not expect it to know what I want without giving it context to my thoughts with regarding to the project. I have written a 1000 LOC program in C using an LLM. It was a success. I have reviewed it "line by line" though, I do not know why I would not do this. Of course it did not spit out 1000 LOC from the get go, we starte…

nobody in this or any meaningful software engineering discussion is talking about software projects that are 1000, or even 10000, SLoC. these are trivial and uninteresting sizes. the discussion is about 100k+ SLoC projects.

I do not see how this is always necessarily implied. And should I seriously always assume this is the case? Where are you getting this from? None of these projects people claim to successfully (or not) written with the help from LLM have 10k LOC, let alone >100k. Should they just be ignored because LOC is not >100k?

Additionally, why is it that whenever I mention success stories accomplished with the help of LLMs, people rush to say "does not count because it is not >100k LOC". Why does it not count, why should it not count? I would have written it by hand, but I finished much faster with the help of an LLM. These are genuine projects that solve real problems. Not every significant project has to have >100k LOC. I think we have a misunderstanding of the term "significant".

> nobody in this or any meaningful software engineering discussion is talking about software projects that are 1000, or even 10000, SLoC.

Why?

> these are trivial and uninteresting sizes.

In terms of what exactly?

Post reply on HN