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

251–260 of 424 posts

Re: The AI coding trap

#251

Post by Jensson »

jowea wrote: post #204
Jensson wrote: post #158

Earlier quoted context omitted.

That is a myth, cpu time is time spent waiting around by your users as the cpu is taking seconds to do something that could be instant, if you have millions of users and that happens every day that quickly adds up to many years worth of time. It might be true if you just look at development cost, but if you look at value as a whole it isn't. And even just development cost its often not true, since time spent waiting…

Yeah, it's time spent by the users. Maybe it's an inneficiency of the market because the software company doesn't feel the negative effect enough, maybe it really is cheaper in aggregate that doing 3 different native apps in C++. But if CPU time is so valuable, why aren't we arguing for hand written C or even assembly code instead of the layers upon layers of abstraction in even native modern software? Also, why

> But if CPU time is so valuable, why aren't we arguing for hand written C or even assembly code instead of the layers upon layers of abstraction in even native modern software?

That is an extreme case though, I didn't mean that all optimizations are always worth it, but if we look at marginal value gained from optimizations today the payback is usually massive.

It isn't done enough since managers tend to undervalue user and developer time. But users don't undervalue user time, if your program wastes their time many users will stop using it, users are pretty rational about that aspect and prefer faster products or sites unless they are very lacking. If a website is slow a few times in a row I start looking for alternatives, and data says most users do that.

I even stopped my JetBrains subscription since the editor got so much slower in an update, so I just use the one I can keep forever as I don't want their patched editor. If it didn't get slower I'd gladly keep it as I liked some of the new features, but it being slower was enough to make me go back.

Also, while managers can obvious agree that making developer spend less time waiting is a good thing, it is very rare for managers to tell you to optimize compilation times or such, and pretty simple optimizations there can often make that part of the work massively faster. Like, if you profile your C++ compiler and look what files it spends time compiling, then look at those files to figure out why its so slow there, you can find these weird things and fixing those speeds it up 10x, so what took 30 seconds now takes 3 seconds, that is obviously very helpful and if you are used to that sort of thing you could do it in a couple of hours.

Re: The AI coding trap

#252

Post by alshival »

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.

Re: The AI coding trap

#253

Post by sarchertech »

jowea wrote: post #204
Jensson wrote: post #158

Earlier quoted context omitted.

That is a myth, cpu time is time spent waiting around by your users as the cpu is taking seconds to do something that could be instant, if you have millions of users and that happens every day that quickly adds up to many years worth of time. It might be true if you just look at development cost, but if you look at value as a whole it isn't. And even just development cost its often not true, since time spent waiting…

Yeah, it's time spent by the users. Maybe it's an inneficiency of the market because the software company doesn't feel the negative effect enough, maybe it really is cheaper in aggregate that doing 3 different native apps in C++. But if CPU time is so valuable, why aren't we arguing for hand written C or even assembly code instead of the layers upon layers of abstraction in even native modern software? Also, why

> But if CPU time is so valuable, why aren't we arguing for hand written C or even assembly code instead of the layers upon layers of abstraction in even native modern software?

Many of us do frequently argue for something similar. Take a look at Casey Muratori’s performance aware programming series if you care about the arguments.

Re: The AI coding trap

#254

Post by bluefirebrand »

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…

> Do you think that all managers and tech leads atrophy because they don’t spend all day “doing"

Yes, obviously this happens.

Do you seriously think that skills don't rust when you stop using them daily?

Re: The AI coding trap

#255

Post by Jensson »

majormajor wrote: post #238
weego wrote: post #234

Earlier quoted context omitted.

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 mid…

> 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

But one of the most fun things you can do is C: creative game development coding. Like coding world simulations etc, you want to be both very fast but the rules and interactions etc is very coupled and complex compared to most regular enterprise logic that is more decoupled.

So while most work programmers do fits A, the work people dream about doing is C, and that means LLM doesn't help you make fun things, it just removes the boring jobs.

Re: The AI coding trap

#256

Post by Jensson »

johnisgood wrote: post #230
kiitos wrote: post #229

Earlier quoted context omitted.

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, pe…

> Why?

Because small programs are really quick and easy to write, there was never a bottleneck making them and the demand for people to write small programs is very small.

The difficulty of writing a program scales super linearly with size, an experienced programmer in his current environment easily writes a 500 line program in a day, but writing 500 meaningful lines to an existing 100k line codebase in a day is not easy at all. So almost all developer time in the world is spent making large programs, small programs is a drop in an ocean and automating that doesn't make a big difference overall.

Small programs can help you a lot, but that doesn't replace programmers since almost no programmers are hired to write small programs, instead automatically making such small programs mostly helps replace other tasks like regular white collar workers etc whose jobs are now easier to automate.

Re: The AI coding trap

#257

Post by djeastm »

alshival wrote: post #252

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.

It sounds like you need a sabbatical.

Re: The AI coding trap

#258

Post by guy_5676 »

alexandre_m wrote: post #120
guy_5676 wrote: post #100

Earlier quoted context omitted.

Code isn't an "artifact", it's the actual product that you are building and delivering. You can use flowery language and pontificate about the importance of the problem domain if you like, but at the end of the day we are producing a low level sequences of instructions that will be executed by a real world device. There has always been, and likely will always be, value in understanding exactly what you are asking the…

Product != Artifact Artifacts are snapshots of system knowledge (code, builds, docs, configs, etc.). The product is the living whole that emerges from these artifacts working together and delivering value.

I'm familiar with "artifact" being used to describe the inconsequential and easy to reproduce output of some deterministic process (e.g. build artifact). Even given the terminology you provide here it doesn't change the content of my point above.

When I see someone dismissing the code as a small irrelevant part of the task of writing software, it's like hearing that the low-level design and physical construction of a bridge is an irrelevant side-effect of my desire to cross a body of water. Like, maybe that's true in a philosophical sense, but at the end of the day we are building a real-world bridge that needs to conform to real-world constraints, and every little detail is going to be important. I wouldn't want to cross a bridge built by someone who thinks otherwise.

Re: The AI coding trap

#259

Post by halfcat »

HiPhish wrote: post #220
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. I think this might simply be how the human brain works. Take autonomous driving as an example: while the car drives on its own the human driver is supposed to be alert and step in if needed. But does that work? Or will the driver's mind wander off because the car has been driving properl…

> My gut feeling is that it's inevitable that we'll eventually just shut out everything that goes smoothly and by the time it doesn't it might be too late.

Yes. Productivity accelerates at an exponential rate, right up until it drives off a cliff (figuratively or literally).

Re: The AI coding trap

#260

Post by WalterSear »

jsmith99 wrote: post #223
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.

You can just add the files to the prompt with the @ sign.
Post reply on HN