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

11–20 of 231 posts

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

#11

Post by bob1029 »

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 can't we figure out the right thing faster by building the wrong thing faster?

Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time.

This is easily the biggest bottleneck in B2B/SaaS stuff for banking. You can iterate maybe once a week if you have a really, really good client.

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

#13

Post by furyofantares »

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…

The post also smells heavily LLM-processed. I feel like I've been had by someone pumping out low effort blog posts.

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

#14

Post by dmitrygr »

hathawsh wrote: post #7
gammalost wrote: post #3

Seems easy to address with a simple rule. Push one PR; review one PR

Also add a PR reviewer bot. Give it authority to reject the PR, but no authority to merge it. Let the AIs fight until the implementation AI and the reviewer AI come to an agreement. Also limit the number of rounds they're permitted to engage in, to avoid wasting resources. I haven't done this myself, but my naive brain thinks it's probably a good idea.

> I haven't done this myself, but my naive brain thinks it's probably a good idea.

Many a disaster started this way

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

#15

Post by cdrnsf »

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…

Because you're working on the implementation before you understand the problem?

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

#16

Post by nyeah »

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 can't faster typing help us understand the problem faster?"

Because typing is not the same as understanding.

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

#17

Post by furyofantares »

bob1029 wrote: post #11
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 can't we figure out the right thing faster by building the wrong thing faster? Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time. This is easily the biggest bottleneck in B2B/SaaS stuff for banking. You can iterate maybe once a week if you have a really, really good client.

That's fair. I'm usually my own customer.

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

#18

Post by 6stringmerc »

Because the way the world is currently and this is trending, let me jump in and save you a lot of time:

Expedience is the enemy of quality.

Want proof? Everyone as a result of “move fast and break things” from 5-10 years ago is a pile of malfunctioning trash. This is not up for debate.

This is simply an observation. I do not make the rules. See my last submission for some CONSTRUCTIVE reading.

Bye for now.

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

#19

Post by hathawsh »

dmitrygr wrote: post #14
hathawsh wrote: post #7

Earlier quoted context omitted.

Also add a PR reviewer bot. Give it authority to reject the PR, but no authority to merge it. Let the AIs fight until the implementation AI and the reviewer AI come to an agreement. Also limit the number of rounds they're permitted to engage in, to avoid wasting resources. I haven't done this myself, but my naive brain thinks it's probably a good idea.

> I haven't done this myself, but my naive brain thinks it's probably a good idea. Many a disaster started this way

Yep, we're on the same wavelength.

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

#20

Post by petcat »

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution.

For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve.

Source code in a higher-level language is not really different anymore. Agents write the code, maybe we guide them on patterns and correct them when they are obviously wrong, but the code is merely the work-item artifact that comes out of extensive specification, discussion, proposal review, and more review of the reviews.

A well-guided, iterative process and problem/solution description should be able to generate an equivalent implementation whether a human is writing the code or an agent.

Post reply on HN