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

111–120 of 424 posts

Re: The AI coding trap

#111

Post by hansonkd »

jstummbillig wrote: post #89
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. Why? Code has always been the artifact. Thinking about and understanding the domain clearly and solving problems is where the intrinsic value is at (but I'd suspect that in the future this, too, will go away).

Reminds me of critisms of python decades ago. that you wouldn't understand what the "real code" was doing since you were using a scripting language. But then over the years it showed tremendous value and many unicorns were built by focusing on higher level details and not lower level code

Re: The AI coding trap

#112

Post by bikelang »

visarga wrote: post #58
closeparen wrote: post #36

Earlier quoted context omitted.

It's "anti-AI" from the perspective of an investor or engineering manager who assumes that 10x coding speed should 10x productivity in their organization. As a staff IC, I find it a realistic take on where AI actually sits in my workflow and how it relates to juniors.

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

I’ve been trying to re-orient for this exact kind of workflow and I honestly can’t declare whether it’s working.

I’ve switched to using Rust because of the rich type system and pedantic yet helpful compiler errors. I focus on high level design, traits, important types - then I write integration tests and let Claude go to town. I’ve been experimenting with this approach on my side project (backend web services related to GIS - nothing terribly low level) for about 4 months now and I honestly don’t know if it’s any faster than just writing the code myself. I suspect it’s not or only marginally faster at best.

I often find that I end up in a place where the ai generated code just has too many issues collected over iterations and needs serious refactoring that the agent is incapable of performing satisfactorily. So I must do it myself and that work is substantially harder than it would have been had I just written everything myself in the first place.

At work - I find that I have a deep enough understanding of our codebase that the agents are mostly a net-loss outside of boilerplate.

Perhaps I’m holding it wrong but I’ve been doing this for a while now. I am extremely motivated to build a successful side project and try to bootstrap myself out of the corporate world. I read blogs and watch vlogs on how others build their workflows and I just cannot replicate these claims of huge productivity gains.

Re: The AI coding trap

#113

Post by cgh »

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.

A surprising conclusion to me at least is that a lot of programmers simply don’t like to write code.

Re: The AI coding trap

#114

Post by martin-t »

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 last paragraph feels more wrong the more I think about it.

Imagine an AI as smart as some of the smartest humans, able to do everything they intellectually do but much faster, cheaper, 24/7 and in parallel.

Why would you spend any time thinking? All you'll be doing it is the things an AI can't do - 1) feeding it input from the real world and 2) trying out its output in the real world.

1) Could be finding customers, asking them to describe their problem, arranging meetings, driving to the customer's factory to measure stuff and take photos for the AI, etc.

2) Could be assembling the prototype, soldering, driving it to the customer's factory, signing off the invoice, etc.

None of that is what I as a programmer / engineer enjoy.

If actual human-level AI arrives, it'll do everything from concept to troubleshooting, except the parts where it needs presence in the physical world and human dexterity.

If actual human-level AI arrives, we'll become interfaces.

Re: The AI coding trap

#115

Post by sciencejerk »

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…

@shredprez the website in your bio appears to sell AI-driven products: "Design anything in Claude, Cursor, or VS Code

Consider leaving a disclaimer next time. Seems like you have a vested interest in the current half-baked generation of AI products succeeding

Re: The AI coding trap

#116

Post by HPsquared »

guy_5676 wrote: post #100
jstummbillig wrote: post #89

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. Why? Code has always been the artifact. Thinking about and understanding the domain clearly and solving problems is where the intrinsic value is at (but I'd suspect that in the future this, too, will go away).

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…

Code is just one way of representing a specification.

Re: The AI coding trap

#117

Post by baq »

PessimalDecimal wrote: post #87
danpat wrote: post #65

Earlier quoted context omitted.

> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project. This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing. There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it see…

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

> You're constantly back at Day 1 of having to "own" someone else's code.

If only there were some people in software engineering in this situation before AI… oh wait.

In the current times you’re either an agent manager or you’re in for a surprise.

Re: The AI coding trap

#118

Post by sph »

jonahx wrote: post #99

This diagram (which resonated): Traditional Coding: [ Thinking & Coding ....................... | Fixing ] AI-Assisted Coding: [ Coding | Thinking & Fixing ................ ] suggests a workflow where AI is used almost exclusively to speed up the writing of known, targeted code whose structure has already been thought out. And possibly as a (non-coding) sounding board during the thinking out.

The thinking part is the same, yes, but I doubt the fixing is.

Fixing something you have written is much easier than fixing something someone else (or an AI) has written, just because you don't have the mental model for the code, which is the most important part of debugging and refactoring.

Re: The AI coding trap

#119

Post by lubujackson »

PessimalDecimal wrote: post #87
danpat wrote: post #65

Earlier quoted context omitted.

> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project. This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing. There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it see…

> 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 reasoning), so you have it add validation and toasts. But you are now working on a narrower level of abstraction because the bigger goal of "make a user form" has been completed.

Where this gets exhausting is when you assume certain things that you know are necessary but don't want to verify - maybe it let's you submit an email form with no email, or validates password as an email field for some reason, etc. But as LLMs improve their assumptions or you manage context correctly, the scale tips towards this being a useful engineering tool, especially when what you are doing is a well-trodden path.

Re: The AI coding trap

#120

Post by alexandre_m »

guy_5676 wrote: post #100
jstummbillig wrote: post #89

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. Why? Code has always been the artifact. Thinking about and understanding the domain clearly and solving problems is where the intrinsic value is at (but I'd suspect that in the future this, too, will go away).

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.

Post reply on HN