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

101–110 of 424 posts

Re: The AI coding trap

#101

Post by didibus »

rapind wrote: post #56
didibus wrote: post #51

Earlier quoted context omitted.

> The reason is pretty simple which is with these AI tools you for the most part replace writing code with writing a prompt I'm convinced I spend more time typing and end up typing more letters and words when AI coding than when not. My hands are hurting me more from the extra typing I have to do now lol. I'm actually annoyed they haven't integrated their voice to text models inside their coding agents yet.

On a mac you can just use a hotkey to talk to an agentic CLI. It needs to be a bit more polished still IMO, like removing the hotkey requirement, with a voice command to break the agents current task.

Does it use an LLM powered voice to text model ?

I find the generic ones like the ones I can use anywhere on Mac to be crap.

If you've used the ChatGPT voice to text model you know what I mean.

Re: The AI coding trap

#102

Post by lukaslalinsky »

nenenejej wrote: post #72
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…

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.

Re: The AI coding trap

#103

Post by raincole »

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 first two paragraphs are so confusing. Since Claude Code became a thing my "thinking" phase has been much, much longer than before.

I honestly don't know how one can use Claude Code (or other AI agents) in a 'coding first thinking later' manner.

Re: The AI coding trap

#104

Post by rdrd »

Even outside of AI coding I have found a tremendous amount of value in using AI to produce a requirements and spec document for me to code from. The key unlock for me is asking AI to “interview” me about how this system/feature should work. As part of that process it will often ask a question that gets me thinking about interesting edge cases.

I will say I always provide an initial context document about the feature/system, to avoid us starting with trivial questions. After about 45minutes I’ll often feel I’ve covered enough ground and given the problem enough thought to really put pen to paper. Off the back of this I’ll ask it to summarise the spec and produce a document. This can be a good point to ditch AI if you are so inclined but still get value from it.

Re: The AI coding trap

#105

Post by OutOfHere »

Effective AI coding is actually extremely slow if you take into account an exhaustive planning stage where the task specification is laid down in sufficient and unambiguous detail. I had to get the LLM to review my spec over twenty times, always freshly, before I thought it was good enough to be implemented well. Also, it really helps for multiple diverse LLMs to review the spec, as they all have their unique insights. In this way, AI coding also helps me avoid numerous bugs that could have left me in trouble if not for the AI.

Once the planning is done, the actual coding is very fast. The human review that follows is again slow, often also leading to minor new tickets.

Re: The AI coding trap

#106

Post by t0mas88 »

babyshake wrote: post #31

Especially with junior engineers it is helpful to ask them to provide a Loom video or other proof that they have verified a feature or bug works as intended. I have tried setting up Claude Code with playwright to verify it's work, but so far am not very satisfied with the results. Any tools that are helpful with this end to end testing for web apps using Claude Code and other AI assistants? Feel free to share your pr…

I've seen reasonable results from letting Claude Code apply test driven development and having a good e2e test suite on top of that (with Playwright). In that setup giving it Playwright MCP to access the app and verify why e2e tests are working or not working, and for writing new tests helps.

Just giving it an MCP to test changes also didn't work for me. But the combination with e2e tests was better.

Re: The AI coding trap

#107

Post by polskibus »

I think the post, while extensive, missed one important issue.

The fact then when we read others' code, we don't remember/integrate it into our thinking as well as we do when we're the authors. So mentoring "AI Juniors" provides less growth then doing the job, esp. if it is mostly corrective actions.

Re: The AI coding trap

#109

Post by marcosdumay »

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…

> Maybe you start with constraint design

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

Re: The AI coding trap

#110

Post by budro »

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 the AI doesn't generate any code for me.

I'm sure there are some people for which the "AI-Driven Engineering" approach would be beneficial, but at least for me I find that replacing those AI coding blocks with just writing the code myself is much more enjoyable, and thus more sustainable to actually delivering something at the end.

[1] https://youtu.be/apREl0KmTdQ?t=4751 (relevant section is about 5 minutes long)

Post reply on HN