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

If you thought code writing speed was your problem you have bigger problems

andrewmurphy.io

Post reply on HN
Print view View original

201–210 of 231 posts

Re: If you thought code writing speed was your problem you have bigger problems

#201

Post by giancarlostoro »

hintymad wrote: post #196
giancarlostoro wrote: post #184

Earlier quoted context omitted.

> How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment? Right... Because Humans have never ever accidentally rm -rf'd a production system in the wrong spot? GitLab has entered the chat. Or that time an S3 developer purged more than intended, causing internet outages. All the above are from 2017. Then…

I was not saying that humans are always right. I was assuming that humans probabilistically would make fewer obvious mistakes, which of course could be wrong and hence my questions. Speaking of QA, we would require AI to generate test cases, right? If so, do we rely on human review to ensure the quality of the test cases?

Correct, and this is why I built out GuardRails (inspired by Beads) because AI just keeps going without checking things. I force my agents to run tests, test if the project builds, and even look for human validation that new features work, as well as ensure tests pass.

Re: If you thought code writing speed was your problem you have bigger problems

#202

Post by onlyrealcuzzo »

closewith wrote: post #158
onlyrealcuzzo wrote: post #134

Earlier quoted context omitted.

As it turns out - "just make this button green" - is not the majority of what people at FAANG are doing... As it turns out - 4 years before LLMs - at least one of the FAANGs already had auto-complete so good it could do most of what LLMs can practically do in a gigantic context. But, sure...

Less than 1% of software developers work at FAANG.

Contrary to popular opinion - the majority of engineers are not working at companies that have no revenue.

Anywhere the risk of something going wrong is high, a lot of what you're paying engineers for is to minimize that risk while getting shit done - not to "just do the thing" you might think you're paying for.

Wherever "this sort of works" is good enough, LLMs will excel. Wherever it doesn't, you'll still be paying a lot of money for humans.

Mostly because non-engineers cannot define what "working" is most of the time it's important.

You don't go to a surgeon and tell him to replace your heart in some way. You go to a surgeon to "fix" your heart. You wouldn't even know what that meant. No amount of WebMD LLM summarization is going to help the average person.

Almost 20 years ago, IBM was famous for the average engineer writing ONE line of code per day...

It's not like IBM was paying people to do nothing, contrary to what most people thought who worked there for 15 years.

It's almost as if lines of code don't have value and a working product and the ability to change it reliably does.

Re: If you thought code writing speed was your problem you have bigger problems

#203

Post by furyofantares »

john_strinlai wrote: post #30
furyofantares wrote: post #6

> The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in…

> Why not? Why can't faster typing help us understand the problem faster? do you have a example (even a toy one) where typing faster would help you understand a problem faster?

> do you have a example (even a toy one)

It's extremely common with video games. Lots of game design is done by seeing what something feels like and changing it or throwing it away, repeatedly.

I think UI can be this way a lot too.

Re: If you thought code writing speed was your problem you have bigger problems

#205

Post by bcrl »

perlgeek wrote: post #182
petcat wrote: post #140

Earlier quoted context omitted.

> The process of compiling higher order language to assembly is deterministic and well-tested. Here are the reported miscompilation bugs in GCC so far in 2026. The ones labeled "wrong-code". https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20cr ... I count 121 of them. I've posted this 3 times now. Code-generation by compilers written by experts is not deterministic in the way that you think it is.

In the 12+ years I've been a professional developer, I can only remember two bugs that were caused by the compiler / interpreter, everything else were logic bugs, oversights, 3rd-party libraries, misunderstanding of the requirements, internal contradictions in the requirements etc. So that's maybe 0.1% of all the bugs I've touched. In that sense, code generation isn't really an interesting source of bugs for the disc…

There were more ~26+ years ago. gcc and egcs had some subtle register allocator bugs that would get tripped up under heavy register pressure on i386 that were the bane of my existence as a kernel developer at the time.

Re: If you thought code writing speed was your problem you have bigger problems

#206

Post by mfrankel »

The product world has a somewhat accepted idea to prototype to production framework. AI code generation is great in that world because there is a process to discover what problem to solve.

System maintenance doesn't have a clearly defined "what problem to solve" path. Maybe it's smallest deployable increment to confirmed value delivery. But that's harder to systematize. And AI code generation is probably not a helpful tool here.

Re: If you thought code writing speed was your problem you have bigger problems

#207

Post by pronik »

Code speed or not, people talk about how coding agents have taken away their passion. I've been reflecting on that for quite some time now and quite honestly, I don't miss a single thing.

My passion has always been building something, but my building has always been hindered by a myriad of small paper cuts -- it's just what technology is and, if we are being honest, always has been. It's not being able to recall an exact syntax or a function name for something I know exists, it's frantically searching for whether something I need exists at all and if so, in anything I'm using alredy, it's a CI build not doing the simplest thing after working for months, it's a TypeScript error with a new library not wanting to compile until I change a dozen of things in tsconfig.json, it's my editor deciding not to update diagnostics today at any cost, it's deprecated syntax, it's documentation not describing what functions do and functions not working like the documentation describes them, it's hunting after weird bugs in fourth- and fifth-party code triggered exactly by four people in the world, one of them being me right now.

This list goes on and on and all of those things are great when I finally manage to solve the problems. However, in terms of building things, I find it extremely liberating to have a literal assistant capable of sorting this shit out in seconds or minutes instead of me banging my head against the wall the whole night. Code writing speed wasn't my problem, but I appreciate when I can think about the code as the whole and change it as a whole in an instant. My time spent on building something hasn't changed much in absolute terms, but in the same spent time I will have taken a dozen detours, experimented with alternatives and provided enough context to tell anyone who asks why something is built this way and not another.

Re: If you thought code writing speed was your problem you have bigger problems

#208

Post by wat10000 »

petcat wrote: post #140
pbasista wrote: post #107

Earlier quoted context omitted.

> review the ASM that GCC generates (we don't) Of course we do not. Because there is no need. The process of compiling higher order language to assembly is deterministic and well-tested. There is no need to continue reviewing something that always yields the same result. > We care that it works, and is correct for what it is supposed to do. Exactly. Which is something we do not have with an output of an LLM. Because…

> The process of compiling higher order language to assembly is deterministic and well-tested. Here are the reported miscompilation bugs in GCC so far in 2026. The ones labeled "wrong-code". https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20cr ... I count 121 of them. I've posted this 3 times now. Code-generation by compilers written by experts is not deterministic in the way that you think it is.

It's close enough. If we had a build pipeline that kept prompts in source control, and ran it through an LLM and then a compiler to produce the build output, this would fall over constantly. You'd get radically different results every time. Build pipelines that store actual source code in source control, then run them through a compiler to produce the build output, are used all over the place and they generally work great.

Re: If you thought code writing speed was your problem you have bigger problems

#209

Post by lanstin »

brailsafe wrote: post #168
bvirb wrote: post #127

When we (the engineering team I work on) started using agents more seriously we were worried about this: that we'd speed up coding time but slow down review time and just end up increasing cycle time. So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out y…

> The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced. I've already passed through this phase and have given up on it. I'm sure everyone's experience will vary, but I just find it introduces either sufficiently more context switching or detracts sufficiently…

For years I worked at a large company with so many blockers for everything that I always worked like this all the time - have 5 projects so when one becomes blocked for external deps, you have one to pull out and work on. There is a context switch (which lead me to context preservation habits like checking everything I write into git; using tmux so that the context is sitting around in the bash history of the shell where I was working, that sort of thing; lots of org files and Mac stickies with TODOs etc).
Post reply on HN