Live data from Hacker News

The AI coding trap

chrisloy.dev

351–360 of 424 posts

Re: The AI coding trap

#351
post #344

Earlier quoted context omitted.

>First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down Yes, and the thinking time is a significant part of overall software delivery, which is why accelerating the coding part doesn't dramatically change overall productivity or labor requirements.

I don't like the artificial distinction b/w thinking and coding. I think they are intimately interwoven. Which is actually one thing I really like about the LLM because it takes away the pain of iterating on several different approaches to see how they pan out. Often it's only when I see code for something that I know I want to do it a different way. Reducing that iteration time is huge and makes me more likely to ac…

Yeah these days I often give it a zero shot attempt, see where things go wrong, reset the state via git and try again. Being able to try 2-3 prototypes of varying levels of sophistication and scope is something I've done in the past manually, but doing it in an hour instead of a day is truly significant, even if they're half or a quarter of the fidelity I'd get out of a manual attempt.

Honestly, even if I did it that way and then threw it all away and wrote the whole thing manually it'd be worth using. Obviously I don't, because once I've figured out how to scope and coach to get the right result it'd be silly to throw it away, but the same value derives from that step regardless of how you follow it up.

Re: The AI coding trap

#352

Earlier quoted context omitted.

Comparing LLMs to programming languages is a fake equivalence. I don’t have to write assembly because LLVM will do that for me correctly in 100% of the cases, while AI might or might not (especially the more I move away from template crud apps)

it might be functionally correct but if you wrote it yourself it could be orders of magnitude faster

No, I wouldn't. That would require me be proficient in this, and I am not, so I am pretty sure I would not get to write better assembly optimisations unless I actually became better in that.

The difference is that there is no point (I know or would encounter) in which a compiler would not actually be able to do the job, and I would need to write manual assembly to fix some parts that the compiler could not compile. Yes a proficient programmer could probably do that to optimise the code, but the code would run and do the job regardless. That is not the case for LLMs, there is a non-zero changeyou get to the point of LLM agents getting stuck and it makes more sense to get hands dirty than iterating with agents.

Re: The AI coding trap

#353
post #33
post #21

Earlier quoted context omitted.

I'm surprised (or maybe just ignorant) that Claude doesn't have an explicit setting for this, because it definitely tends to jump the gun a lot.

Plan mode (shift-tab twice) might be what you want.

A gentle warning to people who are overly trusting: Claude code can and will modify files in plan mode.

Before I switched to a different agent, I routinely ran into situations where I would say "write a plan to do x", it would start planning, and I would steer it by saying something like "update such and such a file, instead of other-file" and it would immediately update it, even though it was in plan mode.

Then I would point out "you're in plan mode, don't update files", and it would go absolutely ham undoing changes and furiously apologizing "You're right! I'm in plan mode, let me undo those changes I wasn't supposed to make!" - meaning that now it's broken the rules twice.

Plan mode does not disable any writing tools, it just changes the system prompt, judging by my experience anyway.

Re: The AI coding trap

#354
I've been using claude code for the past 2 months and I spend most of my time in it's planning mode, which is just amazing to flesh out a good plan. After having a very good/specific plan, it usually one-shots the implementation. If I have a bad plan, it executes poorly.

The other thing that makes a big difference is using a language that has strong typing and a strict compiler. You can allow claude to call the complier, analysers, debuggers and so forth and it works amazing to keep code quality consistent if you tell it always follow your existing patterns.

Lastly, I figured out recently, quite by accident, that claude can call adb/logcat on a connected android device, to ingest real debug logs while my app is running, which can be a firehose of logs. It cuts through it like candyfloss and spots runtime errors significantly faster than a human can read all those log. It found a bug for me that was nearly impossible to find with the IDE & breakpoints, just by ingesting the debug/logcats outputs directly.

So overall the article is great, I do think the way we work can and will fundamentally change in the coming years.

Re: The AI coding trap

#355

Earlier quoted context omitted.

@shredprez the website in your bio appears to sell AI-driven products: "Design anything in Claude, Cursor, or VS Code Consider leaving a disclaimer next time. Seems like you have a vested interest in the current half-baked generation of AI products succeeding

Conflict of interest or not, he's not really wrong. Anyone shipping code in a professional setting doesn't just push to prod after 5 people say LGTM to their vibe coded PR, as much as we like to joke around with it. There are stages of tests and people are responsible for what they submit. As someone writing lots of research code, I do get caught being careless on occasion since none of it needs to work beyond a proo…

> Anyone shipping code in a professional setting doesn't just push to prod after 5 people say LGTM to their vibe coded PR, as much as we like to joke around with it.

I can guarantee this is happening in a lot of companies right now. Any company where there is pressure to use AI tools + pressure to get faster results it's inevitable.

Re: The AI coding trap

#356
Software will be fully replaced with adaptive AI systems that shift form based on multimodal input & interaction.

Current AI models, especially small ones, are quite smooth-brain by themselves.

But, if we can refine them to a point where thinking AI systems can run on smart glasses and smartwatches in a usable, stable state, we can assume by then larger AI systems with higher compute are bound to be much more capable.

We can claim AGI milestone then. And, the real race for superintelligence begins.

Re: The AI coding trap

#357
My impression is, that AI is currently used to get rid of the junior coders, while burning out the senior coders.

Later, you'll realize that there are no new senior coders to burn out, because you got rid of the junior coders, but we're not there yet.

Re: The AI coding trap

#358
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…

For me it's simply this: the best thing about computers and programming is that they do exactly what the code I write says they'll do. That is a quality that humans and human/natural languages don't have. To me, LLMs feel like replacing the best property of computers with a (in this context) terrible property of humans.

Why would I want a fuzzy, vague, imprecise, up-to-interpretation programming language? I already have to struggle with that in documentation, specifications, peers and – of course – myself. Why would I take the one precise component and make it suffer from the same?

This contrasts of course with tasks such as search, where I'm not quite able to precisely express what I want. Here I find LLMs to be a fantastic advance. Same for e.g. operations between imprecise domains, like between natural languages.

Re: The AI coding trap

#359

Every day I think to myself: "Just fake it like you want to be here for 30 more years and then you can retire." I have been working in machine-learning for 10 years. I am tired of the computer. I am tired of working. I just want to lay in the grass.

The how-to-become-a-gardener meme comes to mind. But I feel you. Feels like a golden cage currently. It's very comfy, but you waste your life in front of screen.

Re: The AI coding trap

#360
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…

> There's a divide between people who enjoy the physical experience of the work and people who enjoy the mental experience of the work.

Does this divide between "physical" and "mental" exist? Programming languages are formal languages that allow you to precisely and unambiguously express your ideas. I would say that "fiddling" with the code (as you say) is a kind of mental activity.

If there is actually someone out there that only dislikes AI coding assistants because they enjoy the physical act of typing and now have to do less of it (I have not seen this blog post yet), then I might understand your point.

Post reply on HN