Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using AI to write better code more slowly

nolanlawson.com

Post reply on HN
Print view View original

171–180 of 511 posts

Re: Using AI to write better code more slowly

#171

Post by estetlinus »

qsera wrote: post #65
aomix wrote: post #59

Earlier quoted context omitted.

Talking the problem to death with the AI before implementation is a nice zone for me. I feel productive, get good results out of the AI, and still largely understand the code. That’s the part of the AI revolution that I feel has made me a better engineer because I argue about design and architecture all day with a robot.

>I argue about design and architecture all day with a robot. You will outgrow it at some point.

Quite the opposite. It’ll most likely “outgrow” us.

Re: Using AI to write better code more slowly

#172

Post by shinycode »

rootnod3 wrote: post #12
bottlepalm wrote: post #4

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds cor…

And then Anthropic has an outage and you what...have a coffee break until then? All that time babysitting the AIs just to be a little faster but probably with less knowledge/control over what they did?

It’s a fragile equilibrium and it depends on the kind of project you’re working on. If the knowledge debt is ok then yes, it’s just like a delivery job, if the truck has an engine problem I won’t continue to deliver the packages by walking or finding and setting up an other truck from where the vehicle breakdown happens. I’ll just wait because the wait is still faster than the other solution because of the knowledge debt it’s too long to pickup by hand and continue.

Now if it’s my job then I can’t have a knowledge debt and if Claude is down I’ll continue working manually because I know and understand and can continue without having to understand a lot of logic before continuing

Re: Using AI to write better code more slowly

#173

Post by batshit_beaver »

etothet wrote: post #125

“A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible.” A lot of people think a lot of things, but I don’t think the majority of people think the point of using LLMs is so they can produce low-quality code. Do they produce low-quality code sometimes or often? Of course. But they also produce high-quality code very often. And sometimes they just a “fine” job. One…

> We can debate as to how successful we’ve been toward the two goals above, but I think it’s misguided to say that the majority of people think LLMs should produce lower quality code.

Guessing you’re not at FAANG or similar company. For the last 6 months at least there’s been tremendous pressure from leadership (including highly experienced IC engineers) to let AI take the reigns, assumption being that future AI assistants will be able to deal with any level of complexity and tech debt created today.

Given that everyone agrees that reviewing all AI-generated code is impractical (if you let the agents rip at maximum available bandwidth), and that “harness engineering” is at best immature and at worst complete snake oil when it comes to ensuring system stability, maintainability, and quality, I do believe that it’s fair to claim that most engineers are, in fact, supportive of low quality code generated by LLMs.

Fwiw I do see pushback here and there, but only from the lowest rungs on the career ladder - ICs with enough experience to see where this train is headed, but no ability to save it. Management needs to see the results of their policies first, and that will take months or even years to fully play out.

Re: Using AI to write better code more slowly

#174

Post by henry_bone »

bottlepalm wrote: post #4

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds cor…

That sounds expensive.

Re: Using AI to write better code more slowly

#175

Post by redeye100 »

teaearlgraycold wrote: post #136
TACIXAT wrote: post #30

This article doesn't address writing code with AI, just code review. My issue with agentic coding is that I make numerous micro-architectural decisions while programming. I almost never have a full spec up front and develop one as I consider what I am writing. When using Claude Code or Codex, that is all gone. Claude Code is extremely eager to reach the end goal to the point that it feels like a fever dream to write…

A lot of programming work is well represented in the training data. For that kind of stuff there’s not much to do regarding architectural decisions. I love to run the LLMs on auto for that work. But for anything not well represented in the training data, which could be anything from mundane stuff in PyQT or a truly novel application, keep them on a short leash or forget them altogether.

> represented in the training data

This isn’t a binary is/isn’t thing though. What if only 80% of my task is, how would I know that the other part isn’t, if I haven’t worked it through fully

What if my task is generally represented, but for my specific context, there are specific details that aren’t?

How would I know until I’ve reasoned through it myself? At that point having the LLM do the work doesn’t add much value

Re: Using AI to write better code more slowly

#176

Post by Animats »

bottlepalm wrote: post #4

I've hit this point with AI where it's not a simple process, but a long drawn out back and forth. I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slower, but does a better job. Then review the implementation, then have Codex GPT 5.5 xhigh fast review it - which almost always finds cor…

How much are you spending a day for the tokens to do that?

Ingest big project, comment on it gets expensive. I'm not sure how expensive.

Re: Using AI to write better code more slowly

#177

Post by exe34 »

locknitpicker wrote: post #137
bottlepalm wrote: post #114

Earlier quoted context omitted.

If you can't understand why the code is done in a certain way from reading it then the code is missing comments or needs to be refactored. Even code you write yourself, given enough time, you will forget the why unless you wrote comments. In a way comments are as much for you as they are for others. Even before AI, understanding code you didn't write is essential to working on a team of other developers. If you can't…

> If you can't understand why the code is done in a certain way from reading it then the code is missing comments or needs to be refactored. Code is never missing contexts. If what your code is doing is not obvious to the reader, it is bad code that needs to be fixed. Things like cryptic low-level expressions should be extracted to helper functions with descriptive names or even extracted into a class, and classes ne…

yeah that's how a simple algorithm that would fit on a napkin gets broken up into a soup of ravioli that I have no hope to understand. I often end up refactoring it into a simple function in a branch so I can figure out wtf is going on.

Re: Using AI to write better code more slowly

#178

Post by exe34 »

locknitpicker wrote: post #138
well_ackshually wrote: post #46

Earlier quoted context omitted.

congratulations on your soon to be coming burnout. Keeping that many tasks in parallel, running all the time will kill you.

> congratulations on your soon to be coming burnout. Multitasking does not mean burnout. It just means you are not wasting time while idling. Multitasking was not invented for AI coding assistants. What do you think feature branches are used for?

> What do you think feature branches are used for?

Yak driven development.

Re: Using AI to write better code more slowly

#179

Post by wartywhoa23 »

The screechless wind vane of AI narratives be like

- Using AI to write the best code ever faster than any human ever could

- Using AI to write better code more slowly

- Using AI to write code that sucks even more slowly

- Using AI to stockpile horrendous ball of spaghetti code no one fucking understands which grows faster and faster despite going even more slowly

- Using Natural Intelligence to try and fail to untangle the mountain of spaghetti code

- Look guys, down with that AI, we've got a brand new shiny thing to throw trillions of VC dollars at!

Post reply on HN