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

171–180 of 231 posts

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

#171

Post by copperx »

whateverboat wrote: post #166
webdood90 wrote: post #157

Earlier quoted context omitted.

> 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 Ugh, sounds awful. Constantly context switching and juggling multiple tasks is a sure-fire way to burn me out. The human element in all of this never seems to be discussed. Maybe this will weed out those…

Often when you are solving a problem, you are never solving a single problem at a time. Even in a single task, there are 4-5 tasks hidden. you could easily put agent to do one task while you do another. Ask it to implement a simple http put get with some authentication and interface and logs for example, while you work out the protocol.

Sure, but the subtasks don't feel completely disparate, probably because there's shared context in working memory.

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

#172

Post by adwn »

apsurd wrote: post #147
nicbou wrote: post #114

I'm a solo dev. In fact I'm hardly a dev; it's just a helpful skill. Code writing speed IS a problem, because it takes valuable time away from other tasks. A bit like doing the dishes. I just set up Claude Code tonight. I still read and understand every line, but I don't need to Google things, move things around and write tests myself. I state my low-level intent and it does the grunt work. I'm not going to 10x my pr…

The intention of the title is to say your main problem. The problem separating you from $PROFIT$: 1. Idea 2. ??? 3. Profit Coding effectively is definitely one problem. And you're right that AI helps with that problem. But for startups, side-hustles, VC-pitches and the inner-workings of companies (HN crowd) coding was never the problem. edit to add: So for people working on professional software teams, the discussion…

> But for startups, side-hustles, VC-pitches and the inner-workings of companies and so on (HN crowd) coding was never the problem.

I'd say you're 180° wrong. Getting to an MVP fast is the most immediate problem when you've started a startup. Iterating on ideas fast is the most immediate problem once you've released your MVP. You need an MVP to get users, and you need to to iterate to find product-market fit. Perfectly crafted code is a luxury problem you can't afford in the early stages.

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

#173

Post by discreteevent »

petcat wrote: post #94
tcmart14 wrote: post #80

Earlier quoted context omitted.

I commented elsewhere, but that doesn't mean it's not deterministic. Deterministic means given the same input it gives the same output. Compilers can still have bugs and generate the wrong code. But so long as given the same input it generates the same wrong output, it is still deterministic.

Compilers can generate wrong output in many different ways. And they're all analogous to the same ways that a sophisticated LLM can generate wrong outputs. The compiler relies on: * Careful use of the ENV vars and CLI options * The host system, or the compilation of the target executable (for cross-compiling) * It relies on the source code specifically How is this really different from careful prompt engineering, and…

> How is this really different from careful prompt engineering, and an extensive proposal/review/refine process?

So different that those concepts don't even exist.

I don't have to carefully prompt my compiler in case it might misinterpret what I'm saying. My compiler comes with a precisely specified language.

I never, ever, review the output of my compiler.

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

#174

Post by leptons »

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.

If the "bug" shows up every time in the output given the same input, then it definitely is deterministic.

Just because there are bugs does not mean a compiler is non-deterministic. I looked through a bunch of the bug reports and there is nothing there that can't be fixed to make it deterministic.

You can't fix an LLM to be absolutely deterministic, but you can fix a compiler.

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

#176

Post by hintymad »

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?

When a person writes code, the person reasons out the code multiple times, step by step, so that they don't make at least stupid or obvious mistakes. This level of close examination is not covered in code review. And arguably this is why we can trust more on human-written code than AI-produced, even though AI can probably write better code at smaller scale.

In contrast, Amazon asked senior engineers to review AI-generated code before merging them. But the purpose of code review was never about capturing all the bugs -- that is the job of test cases, right? Besides, the more senior an engineer is in Amazon, the more meetings they go to, and the less context they have about code. How can they be effective in code review?

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

#177

Post by ai-inquisitor »

This entire piece sounds AI written (or at minimum, heavily AI edited) with its "punchy" writing style LLMs love, negative parallelisms galore (see blockquotes 2, 3, 5), invented concept labels ("your calendar is a load-bearing wall" ???), attempts at humor sprinkled in. What a joke of a post.

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

#178

Post by apsurd »

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…

Insightful and helpful to peer into another company's experience. Mostly agree with your highlighted points.

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

This is where unnerving exhaustion comes from though.

I know myself to be on the side of craftsmen. It does takes tons and tons of time to code, but I didn't get exhausted the way I do with AI. AI is productive, I am pro-AI. But boy is it a different kind of work beast.

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

#180

Post by apsurd »

whateverboat wrote: post #166
webdood90 wrote: post #157

Earlier quoted context omitted.

> 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 Ugh, sounds awful. Constantly context switching and juggling multiple tasks is a sure-fire way to burn me out. The human element in all of this never seems to be discussed. Maybe this will weed out those…

Often when you are solving a problem, you are never solving a single problem at a time. Even in a single task, there are 4-5 tasks hidden. you could easily put agent to do one task while you do another. Ask it to implement a simple http put get with some authentication and interface and logs for example, while you work out the protocol.

Seems like you're your saying there is a such a thing as regenerative, light-weight multi-tasking?

no.

Post reply on HN