Live data from Hacker News

The AI coding trap

chrisloy.dev

151–160 of 424 posts

Re: The AI coding trap

#151
What these articles miss:

1) not all coding is the same. You might be working on a production system. I might need a proof of concept

2) not everyone's use of the coding agents is the same

3) developer time, especially good developer time has a cost too

I would like to see an article that frames the tradeoffs of AI assisted coding. Specifically without assigning value judgments (ie goodness or badness). Really hard when your identity is built around writing code.

Re: The AI coding trap

#152
I don't understand why some people are so upset with AI coding - no one forces them to use it.

Now, if you say the problem is that you don't want to be inflicted with other people's AI code, just enforce more meaningful tests. There has always been bad code in the past, and there always will be.

I, for one, am doing great with AI coding - and my feeling is that more emphasis on project structure is the way forward for better end to end results.

Re: The AI coding trap

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

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

It's about as much time as I think about caching artifacts and branch mispredict latencies. Things I cared a lot about when I was doing assembly, but don't even think about really in Python (or C++).

My assembly has definitely rotted and I doubt I could do it again without some refreshing but it's been replaced with other higher-level skills, some which are general like using correct data structures and algorithms, and others that are more specific like knowing some pandas magic and React Flow basics.

I expect this iteration I'll get a lot better at systems design, UML, algorithm development, and other things that are slightly higher level. And probably reverse-engineering as well :) The computer engineering space is still vast IMHO....

Re: The AI coding trap

#154
post #2

It's a fine post, but two canards in here: First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down. In fact: I do a lot, lot more thinking and balancing different designs and getting a macro sense of where I'm going, because that's usually what it takes to get an LLM agent to build something decent. But now that pondering and planning…

> the LLM may not be learning anything, but I am Regardless of that, personally i'd really like it if they could actually learn from interacting with them. From a user's perspective what i'd like to do is to be able to "save" the discussion/session/chat/whatever, with everything the LLM learned so far, to a file. Then later be able to restore it and have the LLM "relearn" whatever is in it. Now, you can already do th…

I'm using a "memory" MCP server which basically just stores facts to a big json file and makes a search available. There's a directive in my system prompt that tells the LLM to store facts and search for them when it starts up.

It seems to work quite well and I'll often be pleasantly surprised when Claude retrieves some useful background I've stored, and seems to magically "know what I'm talking about".

Not perfect by any means and I think what you're describing is maybe a little more fundamental than bolting on a janky database to the model - but it does seem better than nothing.

Re: The AI coding trap

#155
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'm not impressed by AI because it generates slop. Copilot can't write a thorough working test suite to save it's life. I think we need a design and test paradigm to properly communicate with AI for it to build great software.

Re: The AI coding trap

#156

Earlier quoted context omitted.

OK: AI is slow when using the said loop. AI is like poker. You bet with time. 60 seconds to type prompt and generate a response. Oh it is wrong ok let's gamble another 60 seconds... At least when doing stuff the old way you learn something if you waste time. That said AI is useful enough and some poker games are +EV. So this is more caution-AI than anti-AI take. It is more an anti-vibe-koolaid take.

This depends entirely on how you use said AI. You can have it read code, explain why was it done this or that way, and once it has the context you ask to think about implementing feature X. There is almost no gambling involved there, at best the level frustration you would have with a colleague. If you start from blank context, tell it to implement full app, you are purely just gambling.

> You can have it read code, explain why was it done this or that way,

The thing is that, once you're experienced enough, it's faster to just glance at the code and have the answer right, instead of playing the guessing game with AI.

> and once it has the context you ask to think about implementing feature X

I'm always amazed at someone using that methodology. When I think about a feature, first is to understand the domain, second is which state I'm like to start from and where all the data are. If you don't get these two steps right, what you'll have is a buggy/incomplete implementation. And if you do get these steps right, the implementation is likely trivial.

Re: The AI coding trap

#157
post #76
post #42

Earlier quoted context omitted.

> I put absolute LLM negativity right up there with comments like "i never use a debugger and just use printf statements". To me it just screams you never learnt the tool. To me it just feels different. Learning to use a debugger made me feel more powerful and "in control" (even though I still use a lot of print debugging; every tool has its place). Using AI assisted coding makes me feel like a manager who has to mic…

It’s exhausting because most of us like to sit down open an IDE and start coding with the belief that ambiguous or incomplete aspects will be solved as they come up. The idea of writing out the spec of a feature from without ambiguity, handling error states, etc. and stopping to ask if the spec is clear is boring and not fun. To many of us coding us simply more fun. At the same time, many of us could benefit from tha…

For pet projects, it might be less fun. For real projects, having to actually think about what I'm trying to do has been a net positive, LLM or no LLM.

Re: The AI coding trap

#158
post #142

Earlier quoted context omitted.

it might be functionally correct but if you wrote it yourself it could be orders of magnitude faster

We've been on the Electron era long enough to know that developer time is more expensive than CPU time.

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 around by the developer for tests to run and things to start also slows things down, taking a bit of time there to reduce cpu time is well worth it just to get things done faster.

Re: The AI coding trap

#159
post #147
post #127

Earlier quoted context omitted.

Yes. But here we are, people ignoring all the theft that has happened. People generating images on stolen art and call themselves artists. People using it to program and call themselves programmers. Also, it seems to me that so many people just absolutely ignore all the security related issues coming with coding agents. Its truly a dystopia. But we are on hackernews so obviously people will glaze about "AI" on here.

Maybe we should get upset about people using cameras to take pictures of art on the same principles. And what about that Andy Warhol guy, what a pretender! … so I hope you can see why I don’t actually agree with your comment about who’s allowed to be a artist, and not just dismiss me as a glazer

Who is taking pictures of art and calls themselves artist for that? People are generating images from stolen art and creating businesses off of that. People are faking being an artist on social media. But I shouldn't be surprised that people with no actual talent defend all of this.

You wanna be an artist? Put in the work.

Re: The AI coding trap

#160

Broadly the critique is valid where it applies; I don’t know if it accurately captures the way most people are using LLMs to code, so I don’t know that it applies in most case. My one concrete pushback to the article is that it states the inevitable end result of vibe coding is a messy unmaintainable codebase. This is empirically not true. At this point I have many vibecoded projects that are quite complex but work p…

I had the AI implement two parallel implementations of the same thing in one project. Was lots of fun when it was 'fixing' the one that wasn't being used. So yeah, it can definitely muck up your codebase.
Post reply on HN