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

271–280 of 424 posts

Re: The AI coding trap

#271

Post by wild_egg »

hyperadvanced wrote: post #244
lukax wrote: post #242

Earlier quoted context omitted.

Have you tried Soniox? It's really not expensive ($0.12/h, $200 free credits when you sign up) and really accurate. https://soniox.com/ You can use it with Spokenly (free app, bring your own Soniox API key) on macOS and iOS (virtual voice keyboard) https://spokenly.app/ Disclaimer: I've worked for Soniox

Why would I buy this if my Mac has it for free? Is it “just better”?

The mac one is pretty limited. I paid for a similar tool as above and the LLM backing makes the output so much better. All my industry specific jargon gets captured perfectly whereas the Apple dictation just made up nonsense.

Re: The AI coding trap

#272

Post by closeparen »

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.

Which part of the third chart do you disagree with?

Re: The AI coding trap

#273

Post by wild_egg »

Jensson wrote: post #256
johnisgood wrote: post #230

Earlier quoted context omitted.

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…

There's an argument to be made that this gap is actually highlighting design issues rather than AI limitations.

It's entirely possible to have a 100k LOC system be made up of effective a couple hundred 500 line programs that are composed together to great effect.

That's incredibly rare but I did once work for a company who had such a system and it was a dream to work in. I have to think AIs are making a massive impact there.

Re: The AI coding trap

#274

Post by rTX5CMRXIfFG »

lubujackson wrote: post #119
PessimalDecimal wrote: post #87

Earlier quoted context omitted.

> What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions? The difference is the hope of getting out of that situation. If you've inherited a messy and incoherent code base, you recognize that as a problem and work on fixing it. You can build an understanding of the code through first reading…

The key point is "relegating the reasoning". The real way to think about interfacing with LLMs is "abstraction engineering". You still should fully understand the reasoning behind the code. If you say "make a form that captures X, Y, Z and passes it to this API" you relegate how it accomplishes that goal and everything related to it. Then you look at the code and realize it doesn't handle validation (check the reason…

I find this to be too rosy a story about using agentic coding to add to a codebase. In my experience, miss a small detail about the code and the agent may can go out of control creating a whole new series of errors that you wouldn’t have had to fix. And even if you don’t miss a detail, the agent eventually forgets because of the limited context window.

This is why I’ve constrained my use of AI agents to mostly “read-only and explain” use cases, but I have very strict conditions for letting it write. In any case, whatever productivity gains you supposedly “get” for its write scenarios, you should be subtracting your expenses to fix its output later and/or payments made for a larger context window or better reasoning. It’s usually not worth the trouble to me when I have plenty of experience and knowledge to draw from and can write the code as it should be myself.

Re: The AI coding trap

#275

Post by strangescript »

I appreciate these takes, but I can't help to think this is just the weird interim time where nothing is quite good enough, but in a year an article like this would clearly be "overthinking" the problem.

Like when those in the know could clearly see the internet's path to consuming everything but it just hasn't happened yet so there were countless articles trying to decide if it was a fad or not, a waste of money, bad investment, etc.

Re: The AI coding trap

#276

Post by posix86 »

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…

What is "understanding code", mental model of the problem? These are terms for which we all have developed a strong & clear picture of what they mean. But may I remind us all that used to not be the case before we entered this industry - we developed it over time. And we developed it based on a variety of highly interconnected factors, some of which are e.g.: what is a program, what is a programming language, what languages are there, what is a computer, what software is there, what editors are there, what problems are there.

And as we mapped put this landscape, hadn't there been countless situations where things felt dumb and annoying, and then situation in sometimes they became useful, and sometimes they remained dumb? Something you thought is making you actively loosing brain cells as you're doing them, because you're doing them wrong?

Or are you to claim that every hurdle you cross, every roadblock you encounter, every annoyance you overcome has pedagogical value to your career? There are so many dumb things out there. And what's more, there's so many things that appear dumb at first and then, when used right, become very powerful. AI is that: Something that you can use to shoot yourself in the foot, if used wrong, but if used right, it can be incredibly powerful. Just like C++, Linux, CORS, npm, tcp, whatever, everything basically.

Re: The AI coding trap

#277

Post by tptacek »

closeparen wrote: post #272
tptacek wrote: post #41

Earlier quoted context omitted.

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

Which part of the third chart do you disagree with?

Here we're really arguing about his first chart, which I agree with, and you do not.

Re: The AI coding trap

#278

Post by latentsea »

ZephyrBlu wrote: post #176
halfadot wrote: post #167

Earlier quoted context omitted.

> 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. 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 lack of will to learn will not change the outcomes for you…

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

> The marginal developer is not going to put in the effort to wield AI in a skillful way. They're going to slop their way through. It is a concern for widespread AI coding, even if it's not a concern for you or your skill peers in particular.

My mental model of it is that coding with LLMs amplified both what you know and what you don't.

When you know something, you can direct it productively much faster to a desirable outcome than you could on your own.

When you don't know something, the time you normally would have spent researching to build a sufficient understanding to start working on it can be replaced with evaluating the random stuff the LLM comes up with which oftentimes works but not in the way it ought to, though since you can get to some result quickly, the trade-off to do the research feels somehow less worth it.

Probably if you don't have any idea how to accomplish the task you need to cultivate the habit of still doing the research first. Wielding it skillfully is now the task of our industry, so we ought to be developing that skill and cultivating it in our team members.

Re: The AI coding trap

#279

Post by tptacek »

kiitos wrote: post #236
tptacek wrote: post #41

Earlier quoted context omitted.

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

Take that up with the author of this article!

Re: The AI coding trap

#280

Post by jay_kyburz »

enraged_camel wrote: post #78
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…

>> 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. All code is temporary and should be treated as ephemeral. Even if it lives for a long time, at the end of the day what really matters is data . Data is what helps you develop the type of deep understanding and expertise of the domain…

In many cases, the code is "data". The code is a set of rules or instructions by which the data must be transformed for business cases.

You need to understand both the data, and the transformations that are being made to the data.

Post reply on HN