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

41–50 of 511 posts

Re: Using AI to write better code more slowly

#41

Post by deadbabe »

scosman wrote: post #19
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…

yes exactly. Too many people ask AI to one-shot complex tasks, and wonder it behaves like a junior asked to rush something. I have my own skill: 5 rounds of research/planning/test-planning. Interactive with me in loop for all important decisions. Starts with high level shape, then details. Planning can take 2-3 days of my time, then the implementation agent can take many hours (Opus 4.7). It splits the implementation…

Does the 5x faster including shipping? Or just the work part?

IMO if you are not shipping out faster then the faster work gains are meaningless.

If you are shipping faster, you’re probably picking up more work and shipping everything too fast leading to burnout.

Re: Using AI to write better code more slowly

#42

Post by mhluongo »

deadbabe wrote: post #41
scosman wrote: post #19

Earlier quoted context omitted.

yes exactly. Too many people ask AI to one-shot complex tasks, and wonder it behaves like a junior asked to rush something. I have my own skill: 5 rounds of research/planning/test-planning. Interactive with me in loop for all important decisions. Starts with high level shape, then details. Planning can take 2-3 days of my time, then the implementation agent can take many hours (Opus 4.7). It splits the implementation…

Does the 5x faster including shipping? Or just the work part? IMO if you are not shipping out faster then the faster work gains are meaningless. If you are shipping faster, you’re probably picking up more work and shipping everything too fast leading to burnout.

If you're not shipping faster, it's meaningless, and if you are, it's also bad?

Re: Using AI to write better code more slowly

#43

Post by 8note »

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?

why not?

then demand some lack-of-uptime compensation for a lack of uptime

Re: Using AI to write better code more slowly

#44

Post by skydhash »

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 too much like three weeks of work saving you three hours of planning.

In my experience, software engineering is a matter of knowledge. Understanding it and then coming up with a solution. The latter is a flash of insight that comes mostly from experience. Then you gather more information to flesh it out, or brainstorm it with your colleagues.

What you're describing sounds more like a ritual of doing busy work than anything practical. Because tasks vary so much. A feature may be huge, but you take care of it in a day with copy pasting because you already have all the building blocks in other files. And something may be twenty lines of code, but you spent the whole week sweating on it (concurrency stuff maybe). Those ritualistic workflows sounds more like someone imagining software development than actually doing it.

Re: Using AI to write better code more slowly

#46

Post by well_ackshually »

efitz wrote: post #32
rootnod3 wrote: post #12

Earlier quoted context omitted.

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?

If you only have one AI window open, you’re doing it wrong. You task swap to another window/agent, get it working on something, rinse and repeat. I can keep 4 busy most of the time. When I task swap I also check in on what the other agents are doing to make sure they’re on track, not blocked and not struggling.

congratulations on your soon to be coming burnout.

Keeping that many tasks in parallel, running all the time will kill you.

Re: Using AI to write better code more slowly

#49

Post by nomel »

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…

I've noticed the following really helps (most important at end):

1. Have claude form the plan and converse with a simple "Note any concerns with this plan" type plan-critic agent.

2. Let it run.

3. After (with everything in context) have it make a future_recommendations.md.

4. Have it make a plan.md to implement those future recommendations, conversing with the plan critic..

5. Clear context. Repeat with 1. Do this loop a few times, with some feedback from actual review thrown in.

But, most importantly, because Claude will aggressively try to maintain code "as is", and happily build on it's previous crap, while preferring to hand roll implementations of everything, add something like this to memories/directives:

* When evaluating designs, default to "pull in the library" over "hand-roll it." Hand-rolling is much worse than a dependency.

* "Precedent" / "matches house style" / "reuses existing pattern" / "consistent with what we already do" are not valid engineering arguments.

* This project is still in the development stage with no real deployments. Mitigation costs and existing precedence are not a concern.

With these, in the last week that I've started using them (after inspecting the insane justifications for leaving crap design decisions in the plans), Claude went from junior level slop that required more oversight than it was worth to something very reasonable, using standard libraries, requiring nudges for architecture rather than pure "wtf!?".

I think they've fine tuned heavily towards "don't rewrite the codebase" tuning, which completely rational from multiple perspectives, but also not appropriate for new code.

I do enjoy a considerable daily token allowance, so this may not apply to everyone.

Post reply on HN