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

401–410 of 424 posts

Re: The AI coding trap

#401

Post by pietz »

budro wrote: post #110

I think what the article gets at, but doesn't quite deliver on, is similar to this great take from Casey Muratori [1] about how programming with a learning-based mindset means that AI is inherently not useful to you. I personally find AI code gen most useful for one-off throwaway code where I have zero intent to learn. I imagine this means that the opposite end of the spectrum where learning is maximized is one where…

Interesting take.

I think it boils down to personal preference where some people want to use AI while others don't. I also learn when coding with my AI agent. I learn about using the tool more effectively. As someone who has been coding for 10 years, I find more pleasure in AI assisted coding.

But aside from taste, the product and the business don't care about what I like. It's about shipping quality updates more quickly. And while there might be some tension in saying this, I'm convinced that I can do that much more quickly in AI assisted coding.

Re: The AI coding trap

#402

Post by bccdee »

godelski wrote: post #288
Jensson wrote: post #256

Earlier quoted context omitted.

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

> but writing 500 meaningful lines to an existing 100k line codebase in a day is not easy at all. I've had plenty of instances where it's taken more than a day to write /one line/ of code! I suspect most experienced devs have also had these types of experiences. Not because the single line was hard to write but because the context in which it needed to be written. Typing was never the bottleneck and I'm not sure why…

> Things like libraries, scripts, and skeletons tend to be far better solutions for those problems.

My feelings exactly.

LLM code generation (at least, the sort where people claim they're being 10X-ed) feels like it competes with frameworks. "An agent built this generic CRUD webapp on its own with only 30 minutes of input from me!"—well, I built an equivalent webapp in 30 minutes with Django. These are off-the-shelf solutions to solved problems. Yes, a framework like Django requires up-front learning, but in the end it leaves you with fewer lines of code to maintain, as opposed to custom-generated LLM code.

Re: The AI coding trap

#403

Post by bccdee »

wild_egg wrote: post #273
Jensson wrote: post #256

Earlier quoted context omitted.

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

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

To me, this sounds like an nightmare—I'm sure anyone who's worked at a shop with way too many microservices would agree. It's trivial to right-click a function call and jump to its definition; much harder to trace through your service mesh and find out what, exactly, is running at `load-balancer.kube.internal:8080/api`.

Re: The AI coding trap

#404

Post by BowBun »

djeastm wrote: post #261
BowBun wrote: post #94

For now, my mind is still made up. I leave the door open to be shown any serious piece of software that is built primarily through agentic workflows. Having tried to use these tools over the past month to build a critical piece of infrastructure for my company, I agree with OP. I spent so much time wrangling back unnecessary garbage that the LLM found was important, that I wondered if just writing it in one shot woul…

>resulted in the LLM inserting a non-sensical mock at the top of the test file that took me an hour or two to unwind Why didn't you just not accept the change?

Let's step through the flow:

1. Write up a detailed spec as a prompt, including a bunch of detail about the actual functionality. Add in some details about wanting to test everything. At this point I did not specifically say "Hey LLM, in my tests, do not mock one of the key idempotency functions in this system". This is obvious to me since 1/4 of the system was concerned with idempotency, and this was super clear in my original spec

2. LLM works for 30 minutes, spits out 2.5K lines

3. I review the product functionality and the test cases at a glance, and then start running tests and iterating on the software.

If I have to mentally split every line of the LLM output and decide whether it's correct or not (remember, I didn't write the rest of the system), then I lose all the productivity gains that the LLM offers. You don't do this, no one does this unless they're modifying a few lines at a time.

My point is that you cannot build robust software from scratch with LLMs right now. They walk right into footguns we've spent decades learning about and building solutions for.

Re: The AI coding trap

#405

Post by solumunus »

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…

It’s crazy to me that some people love the pressing keys parts so much.

Re: The AI coding trap

#406

Post by johnisgood »

godelski wrote: post #286
johnisgood wrote: post #217

Earlier quoted context omitted.

I use LLMs for coding and I like it the way I am using it. I do not outsource thinking, and I do not expect it to know what I want without giving it context to my thoughts with regarding to the project. I have written a 1000 LOC program in C using an LLM. It was a success. I have reviewed it "line by line" though, I do not know why I would not do this. Of course it did not spit out 1000 LOC from the get go, we starte…

> I have written a 1000 LOC program in C using an LLM. > I have reviewed it "line by line" though, I do not know why I would not do this. 1k LOC is not that much. I can easily do this in a day's project. But it's pretty rare you're going to be able to review every line in a mature project, even if you're developing that project. Those can contain hundreds or even thousands of files with hundreds (hopefully not thousa…

So when people talk about safety, it does matter in Rust, right? Because "1k LOC is not that much. I can easily do this in a day's project.". Why should we choose Rust over anything below 100k LOC if it is nothing?

I am just asking. Everyone says 1k LOC is nothing, yet they want to replace 1k LOC in C with 1k LOC in Rust. You can do it in day. You are a professional!

Or what is your point? That 1k LOC projects are useless or pointless? Because if so, I seriously beg to differ.

> So the problem is when the LLM is churning out code faster than you can review.

I start small, I can review just fine.

Re: The AI coding trap

#407

Post by abustamam »

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…

> 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

Yeah I'm actually quite surprised that so many people are just telling AI to do X without actually developing a maintainable plan to do so first. It's no wonder that so many people are anti-vibe-coding — it's because their exposure to vibe coding is just telling Replit or Claude Code to do X.

I still do most of my development in my head, but I have a go-to prompt I ask Claude code when I'm stuck: "without writing any code, and maintaining existing patterns, tell me how to do X." it'd spit out some stuff, I'd converse with it to make sure it is a feasible solution that would work long term, then I tell it to execute the plan. But the process still starts in my head, not with a prompt.

Re: The AI coding trap

#408

Post by SpaceNoodled »

cloverich wrote: post #216
rwmj wrote: post #61

Earlier quoted context omitted.

I think it's more like code review, which really is the worst part of coding. With AI, I'll be doing less of the fun bits (writing, debugging those super hard customer bugs), and much much more code review.

well to be fair to the argument, reviewing code that you designed.

Pretty shaky definition of "designed" when it's really just whatever the LLM shat out that day.

Re: The AI coding trap

#409

Post by SpaceNoodled »

marcosdumay wrote: post #109
visarga wrote: post #58

Earlier quoted context omitted.

> assumes that 10x coding speed should 10x productivity This same error in thinking happens in relation to AI agents too. Even if the agent is perfect (not really possible) but other links in the chain are slower, the overall speed of the loop still does not increase. To increase productivity with AI you need to think of the complete loop, reorganize and optimize every link in the chain. In other words a business has…

> Maybe you start with constraint design Oh, that's a great idea. Then you get a constraint-based language and write your constraints there!

Prolog makin' a comeback!
Post reply on HN