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

231–240 of 424 posts

Re: The AI coding trap

#231

Post by hackable_sand »

AnotherGoodName wrote: post #25
bgwalter wrote: post #15

Earlier quoted context omitted.

"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.

I see a lot of comments like this and it reflects strongly negatively on the engineers who write it imho. As in I've been a staff level engineer at both Meta and Google and a lead at various startups in my time. I post open source projects here on HN from time to time that are appreciated. I know my shit. If someone tells me that LLMs aren't useful i think to myself "wow this person is so unable to learn new tools th…

Ah yes, the hallmarks of top talent:

Violent insecurity and authoritarianism... definitely not compensating for anything there.

Re: The AI coding trap

#232

Post by ZephyrBlu »

keeda wrote: post #211
ZephyrBlu wrote: post #176

Earlier quoted context omitted.

> No it isn't. There's literally nothing about the process that forces you to skip understanding. Any such skips are purely due to the lack of will on the developer's side This is the whole point. The marginal dev will go to the path of least resistance, which is to skip the understanding and churn out a bunch of code. That is why it's a problem. You are effectively saying "just be a good dev, there's literally nothi…

I don't think that is a problem with AI, it is a problem with the idea that pure vibe-coding will replace knowledgeable engineers. While there is a loud contingent that hypes up this idea, it will not survive contact with reality. Purely vibe-coded projects will soon break in unexplainable ways as they grow beyond trivial levels. Once that happens their devs will either need to adapt and learn coding for real or be P…

On vibe coding being self-correcting, I would point to the growing number of companies mandating usage of AI and the quote "the market can stay irrational longer than you can stay solvent". Companies routinely burn millions of dollars on irrational endeavours for years. AI has been promised as an insane productivity booster.

I wouldn't expect things to calm down for a while, even if real-life results are worse. You can make excuses for underperformance of these things for a very long time, especially if the CEO or other executives are invested.

> The real problem we should be discussing is, how do we convince students and apprentices to abstain from AI until they learn the ropes for real

I hate to say it but that's never going to happen :/

Re: The AI coding trap

#233

Post by b_e_n_t_o_n »

swiftcoder wrote: post #214
yoz-y wrote: post #206

Earlier quoted context omitted.

This harkens back to the waterfall vs agile debates. Ideally there would be a plan of all of the architecture with all the pitfalls found out before any code is laid out. In practice this can’t happen because 30 minutes into coding you will find something that nobody thought about.

In the micro, sure. In the macro, if you are finding architecture problems after 30 minutes, then I’m afraid you aren’t really doing architecture planning up front.

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.

Re: The AI coding trap

#234

Post by weego »

PessimalDecimal wrote: post #34
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…

> 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 article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…

Who are this endless cohort of develops who need to maintain a 'deep understanding' of their code. I'd argue a high % of all code written globally on any given day that is not some flavour of boilerplate, while written with good intention, is ultimately just short-lived engineering detritus of it even gets a code review to pass.

Re: The AI coding trap

#235

Post by b_e_n_t_o_n »

iLoveOncall wrote: post #95

> LLMs are lightning fast junior engineers I cannot express how tired I am of seeing this beyond stupid take. If you truly believe that, you have either only ever worked with the most piss-poor junior engineers, or you simply have never worked with junior engineers. LLMs do not learn, LLMs do not ask clarifications, LLMs do not wonder if they're going in the wrong direction, LLMs do not have taste, LLMs do not have o…

> LLMs do not have taste

This is the fundamental issue with LLM's imo.

Re: The AI coding trap

#236

Post by kiitos »

tptacek wrote: post #41
closeparen wrote: post #38

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.

This logic doesn't even cohere. Thinking is a significant part of software delivery. So is getting actual code to work.

if you're spending anywhere near as many engineering hours "getting code to work" as you're spending "thinking" then something is wrong in your process

Re: The AI coding trap

#237

Post by sensanaty »

johnfn wrote: post #161
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…

Do you think that all managers and tech leads atrophy because they don’t spend all day “doing”? I think a good number of them become more effective because they delegate the simple parts of their work that don’t require deep thought, leaving them to continue to think hard about the thorniest areas of what they’re working on. Or perhaps you’re asking how people will become good at delegation without doing? I don’t kno…

As an IC turned temporary manager that went back to being IC, yes, absolutely my skills atrophied. This isn't even a programming thing, this is just a regular human thing with most, arguably all, things that you don't practice for a while.

Also I find the idea that most managers or technical leads are doing any kind of "deep thought" hilarious, but that's just maybe my apathy towards management speaking.

Re: The AI coding trap

#238

Post by majormajor »

weego wrote: post #234
PessimalDecimal wrote: post #34

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. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…

Who are this endless cohort of develops who need to maintain a 'deep understanding' of their code. I'd argue a high % of all code written globally on any given day that is not some flavour of boilerplate, while written with good intention, is ultimately just short-lived engineering detritus of it even gets a code review to pass.

If you're on HN there's a good chance you've self-selected into "caring about the craft and looking for roles that require more attention."

You need to care if (a) your business logic requirements are super annoyingly complex, (b) you have hard performance requirements, or (c) both. (c) is the most rare, (a) is the most common of those three conditions; much of the programmer pay disparity between the top and the middle or bottom is due to this, but even the jobs where the complexity is "only" business requirements tend to be quite a bit better compensated than the "simple requirements, simple needs" ones.

I think there's a case to be made that LLM tools will likely make it harder for people to make that jump, if they want to. (Alternately they could advance to the point where the distinction changes a bit, and is more purely architectural; or they could advance to the point where anyone can use an LLM to do anything - but there are so many conditional nuances to what the "right decision" is in any given scenario there that I'm skeptical.)

A lot of times floor-raising things don't remove the levels, they just push everything higher. Like a cheap crap movie today will visually look "better" from a technology POV (sharpness, special effects, noise, etc) than Jurassic Park from the 90s, but the craft parts won't (shot framing, deliberate shifts of focus, selection of the best takes). So everyone will just get more efficient and more will be expected, but still stratified.

And so some people will still want to figure out how to go from a lower-paying job to a higher-paying one. And hopefully there are still opportunities, and we don't just turn into other fields, picking by university reputations and connections.

Re: The AI coding trap

#239

Post by benoau »

mwcz wrote: post #222
benoau wrote: post #124

Earlier quoted context omitted.

> — 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.

Some licenses do.

In my experience AI coding is not going to spew out a derivative of another project unless your objective is actually to build a derivative of that software. If your code doesn't do the same or look the same it doesn't really meet the criteria to be a derivative of someone else's.

I mostly use Cursor for writing test suites in Jest with TypeScript, these are so specific to my work I don't think it's possible they've infringed someone else's.

Re: The AI coding trap

#240

Post by shortrounddev2 »

A friend of mine who is newer to coding than me is worried that by using AI so much, he's losing his ability to code, and its also killing his motivation because using AI to generate code is just not fun. We do "analog coding sessions" together where we code together without LLM assistance. Its much more enjoyable!
Post reply on HN