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

391–400 of 424 posts

Re: The AI coding trap

#391

Post by rhetocj23 »

bgwalter wrote: post #15
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…

"AI" does not encourage real thinking. "AI" encourages hand waving grand plans that don't work, CEO style. All pro-"AI" posts focus on procedures and methodologies, which is just LARPing thinking. Using "AI" is just like speed reading a math book without ever doing single exercise. The proponents rarely have any serious public code bases.

Exactly.

And this should not be a surprise at all. Humans are optimisers of truth NOT maximisers. There is a subtle and nuanced difference. Very few actually spend their entire existence being maximizers, its pretty exhausting to be of that kind.

Optimising = we look for what feels right or surpassses some threshold of "looks about right". Maximizing = we think deeply and logically reason to what is right and conduct tests to ensure it is so.

Now if you have the discipline to choose when to shift between the two modes this can work. Most people do not though. And therein lies the danger.

Re: The AI coding trap

#392

Post by user3939382 »

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…

> different to the experience you get from prompting

In my experience no. The agents get trapped by the exact programming pitfalls a junior would. The LLM is basically a 16 year old who read a given languages For Dummies book cover to cover 3-4x and has the syntax down but understands little about actually programming especially once you run into any real complexity. However 100% of those limitations can be overcome by proper architecture, testing, specification / requirements analysis (which is a lost art in the time of Agile but which I am a master of), and a sprinkle of technical strategic guidance. Especially the agent doesn’t understand its limitations so you need to have an eye for when it’s working on a problem that’s outside the competency its token window can produce. I could go on for 2 hours but bottom line is IMHO there’s more to it than this simple claim.

Re: The AI coding trap

#393

Post by [deleted] »

didibus wrote: post #51
_fat_santa wrote: post #40

Earlier quoted context omitted.

> 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. Here's mine, I use Cline occasionally to help me code but more and more I find myself just coding by hand. The reason is pretty simple which is with these AI tools you for the most part replace writing code with writing a prompt. I look at it like this, if writing the prompt, and the inf…

> The reason is pretty simple which is with these AI tools you for the most part replace writing code with writing a prompt I'm convinced I spend more time typing and end up typing more letters and words when AI coding than when not. My hands are hurting me more from the extra typing I have to do now lol. I'm actually annoyed they haven't integrated their voice to text models inside their coding agents yet.

[deleted]

Re: The AI coding trap

#394

Post by pixl97 »

phatfish wrote: post #370
hattmall wrote: post #343

Earlier quoted context omitted.

The accountability would be in whoever promoted it. This isn't so much about accountability, as it is who is going to be responsible for doing the actual work when AI is just making a bigger mess.

The accountability will be with the engineer that owns that code. The senior or manger that was responsible for allowing it to be created by AI will have made sure they are well removed. While an engineer is "it" they just have to cross their fingers and hope no job ending skeletons are resurrected until they can tag some other poor sod.

So not really any different from how things work without AI.

Re: The AI coding trap

#395

Post by pixl97 »

swiftcoder wrote: post #383
b_e_n_t_o_n wrote: post #233

Earlier quoted context omitted.

Depends on what you're building. If it's another crud app sure, but if its something remotely novel you just can't understand the landscape without walking through it at least once.

> if its something remotely novel you just can't understand the landscape without walking through it at least once Sure you can. Mapping out the unknowns (and then having a plan to make each one knowable) is the single most important function of whoever you have designing your architecture. Up-front architecture isn't about some all-knowing deity proclaiming the perfect architecture from on high. It's an exercise in…

>Mapping out the unknowns

and

> isn't about some all-knowing deity

Seems like a big conflict of your own thoughts.

Or as they say....

> there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know.

Re: The AI coding trap

#396

Post by pixl97 »

badsectoracula wrote: post #265
didibus wrote: post #93

Earlier quoted context omitted.

You want something that requires an engineering breakthrough. Models don't have memory, and they don't have understanding or intelligence beyond what they learned in training. You give them some text (as context), and they predict what should come after (as the answer). They’re trained to predict over some context size, and what makes them good is that they learn to model relationships across that context in many dim…

> You want something that requires an engineering breakthrough. Basically, yes. I know the way LLMs currently work wouldn't be able to provide what i want, but what i want is a different way that does :-P (perhaps not even using LLMs).

What you want is actual AGI/ASI, which is a different can of worms and likely has a whole list of different existential problems that come with it.

Re: The AI coding trap

#397

Post by swiftcoder »

pixl97 wrote: post #395
swiftcoder wrote: post #383

Earlier quoted context omitted.

> if its something remotely novel you just can't understand the landscape without walking through it at least once Sure you can. Mapping out the unknowns (and then having a plan to make each one knowable) is the single most important function of whoever you have designing your architecture. Up-front architecture isn't about some all-knowing deity proclaiming the perfect architecture from on high. It's an exercise in…

>Mapping out the unknowns and > isn't about some all-knowing deity Seems like a big conflict of your own thoughts. Or as they say.... > there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know.

> But there are also unknown unknowns—the ones we don't know we don't know.

And pretty much your job as an engineer is to mitigate the risk that poses.

We don't build new architectures in a vacuum. We build on what has worked before in similar situations, and we adapt it to the problem at hand.

That adaptation is an ongoing process - but it's not the same as saying "fuck it, let's vibe-code our architecture"

Re: The AI coding trap

#399

Post by chrisloy »

dkural wrote: post #372
chrisloy wrote: post #20

Earlier quoted context omitted.

Author here - I agree and have written about this before, though focusing a bit more on how far down the stack they might go, rather than up: https://chrisloy.dev/post/2025/03/23/will-ai-replace-softwar... Article being discussed in this thread isn't intended to be a luddite rejection of AI. It's just a mistake I see people keep making (and have made myself) and some thoughts on how to avoid it with the tools we have…

This is a nice article, I misunderstood some of your vision in the original article; thank you for pointing it out.

Thank you, glad you enjoyed it!

Re: The AI coding trap

#400

Post by LunaSea »

dpflan wrote: post #46
james_marks wrote: post #13

Earlier quoted context omitted.

I’ve also had success writing documentation ahead of time (keeping these in a separate repo as docs), and then referencing it for various stages. The doc will have quasi-code examples of various features, and then I can have a models stubbed in one pass, failing tests in the next, etc. But there’s a guiding light that both the LLM and I can reference.

Sometimes I wonder if pseudocode could be better for prompting than expressive human language, because it can follow a structure and be expressive but constrained -- have you seen research on this and whether this an effective technique?

I had good success with prompting using the fully complete code.
Post reply on HN