Live data from Hacker News

The AI coding trap

chrisloy.dev

181–190 of 424 posts

Re: The AI coding trap

#181

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

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

That's not the same thing. LLMs don't just obscure low-level technical implementation details like Python does, they also obscure your business logic and many of its edge cases.

Letting a Python interpreter manage your memory is one thing because it's usually irrelevant, but you can't say the same thing about business logic. Encoding those precise rules and considering all of the gnarly real-world edge cases is what defines your software.

There are no "higher level details" in software development, those are in the domain of different jobs like project managers or analysts. Once AI can reliably translate fuzzy natural language into precise and accurate code, software development will simply die as a profession. Our jobs won't morph into something different - this is our job.

Re: The AI coding trap

#182
post #56

Earlier quoted context omitted.

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.

I believe it does on newer macs (m4 has neural engine). It's not perfect, but I'm using it without issue. I suspect it'll get better each generation as Apple leans more into their AI offering.

There are also third parties like Wispr that I haven't tried, but might do a better job? No idea.

Re: The AI coding trap

#183
This omits the deep knowledge required for traditional coding. This opens up coding to non devs, e.g. product managers.

For vibe coding you need systems thinking, planning and logic, but less craftmansship.

For PO's the chart looks different, here the traditional flow contains: "polish concepts, make mocks, make stories, dailies, handovers, revisions, waiting for devs busy with other things"

The vibing PO has none of that.

Not saying this is sustainable for big projects already, but it is for ever growing "small" projects (especially if it's a techincal PM that can code a bit). It's just so much faster without devs -_-.

Disclaimer: I am such a PO. What I now wonder: how can I mix vibe coding and properly developed foundations (ai assisted, but not 99% vibed). One answer in my view is splitting services in vibecoded and core, but dependencies on the core already slow you down a lot. Curious to hear how others mix and match both.

What I actually do right now:

- fullstack PoC vibecoded

- specifications for core based on PoC findings

- Build proper vibecoded V1 mocking what moves to core. But here already a more structured vibecoding approach too.

- replace mocks with actual core

Not yet done but planned: build throwaway PoC in a branch of the core so I can also vibe on top of the core directly, including modification of the core.

Re: The AI coding trap

#184
post #43

Earlier quoted context omitted.

Most of us do nothing but remix the past solutions. Since we don't know what else might already exist in the world without digging very deep, we fool ourselves into thinking that we do something very original and unique.

And even truly novel and unique things are more often than not composites of things that have come before prior. We all stand on the shoulders of giants/priors.

There's plenty of novelty out there. In fact it's in infinite supply.

The giant's shoulder just give us access to useful an lucrative spaces in which to build that novel stuff.

Re: The AI coding trap

#185
post #161

Earlier quoted context omitted.

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

Do you think that all managers and tech leads atrophy because they don’t spend all day “doing”? I think a good number of them become more effective because they delegate the simple parts of their work that don’t require deep thought, leaving them to continue to think hard about the thorniest areas of what they’re working on. Or perhaps you’re asking how people will become good at delegation without doing? I don’t kno…

> Do you think that all managers and tech leads atrophy because they don’t spend all day “doing”?

Yes? If not 100% then a number pretty close to that. Definitely 100% of all the managers/non-coding leads I’ve worked with

Re: The AI coding trap

#186
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 idea that technology forces people to be careless

I don't think anyone's saying that about technology in general. Many safety-oriented technologies force people to be more careful, not less. The argument is that this technology leads people to be careless.

Personally, my concerns don't have much to do with "the part of coding I enjoy." I enjoy architecture more than rote typing, and if I had a direct way to impose my intent upon code, I'd use it. The trouble is that chatbot interfaces are an indirect and imperfect vector for intent, and when I've used them for high-level code construction, I find my line-by-line understanding of the code quickly slips away from the mental model I'm working with, leaving me with unstable foundations.

I could slow down and review it line-by-line, picking all the nits, but that moves against the grain of the tool. The giddy "10x" feeling of AI-assisted coding encourages slippage between granular implementation and high-level understanding. In fact, thinking less about the concrete elements of your implementation is the whole advantage touted by advocates of chatbot coding workflows. But this gap in understanding causes problems down the line.

Good automation behaves in extremely consistent and predictable ways, such that we only need to understand the high-level invariants before focusing our attention elsewhere. With good automation, safety and correctness are the path of least resistance.

Chatbot codegen draws your attention away without providing those guarantees, demanding best practices that encourage manually checking everything. Safety and correctness are the path of most resistance.

Re: The AI coding trap

#187

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…

Let me ask you this: do you understand the code your colleagues produce as well as the code you write yourself?

Of course not that's a bit disingenuous. I would hope my colleagues write code that is comprehensible so it's maintainable. I think that if the code is so complex and inscrutable that only the author can understand it then it's not good code. AI doesn't create or solve this problem.

I do think when AI writes comprehensible code you can spend as much time as necessary asking questions to better understand it. You can ask about tradeoffs and alternatives without offending anybody and actually get to a better place in your own understanding than would be possible alone.

Re: The AI coding trap

#188
This is why you do not use Claude Code for complete project overhaul. For example, if you are writing in Python, categorize your functions and modules very well so that when you ask Claude's help, it won't get lost and start screwing up the entire project. I use modular design with Claude Code very often, and this is the only way I have found it useful. I won't let it change the code of preexisting projects, and only make it analyze individual files/functions for improvements.

People without a true coding background get stuck after a single function because the context window is still so narrow, and code assistants do not get the full picture of the project. It reminds me of the offshore developer's work ethic: "But sir, you told me to add this button there like that, so I deleted the entire codebase". Without thinking about why in general. It keeps saying, "You are absolutely right! I shouldn't have done that!" I just like working with a crappy coder from Fiverr or another freelancer site.

Re: The AI coding trap

#189

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

Your point of view assumes the best of people, which is naive. It may not force you to skip understanding, however it makes it much easier to than ever before.

People tend to take the path of least resistance, maybe not everyone, maybe not right away, but if you create opportunities to write poor code then people will take them - more than ever it becomes important to have strong CI, review and testing practices.

Edit: okay, maybe I am feeling a little pessimistic this morning :)

Re: The AI coding trap

#190

Earlier quoted context omitted.

And even truly novel and unique things are more often than not composites of things that have come before prior. We all stand on the shoulders of giants/priors.

There's plenty of novelty out there. In fact it's in infinite supply. The giant's shoulder just give us access to useful an lucrative spaces in which to build that novel stuff.

That doesn't contradict what I said. Just that pattern detection based on priors doesn't rule out novelty if guided by a human.
Post reply on HN