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

31–40 of 231 posts

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

#31

Post by doix »

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…

Pretty much, the article assumes people didn't build the wrong thing before AI. Except that did happen all the time and it just happened slower, took longer to realize that it was the wrong thing and then building the right thing took longer.

It's funny, because you could actually take that story and use it to market AI.

> I once watched a team spend six weeks building a feature based on a Slack message from a sales rep who paraphrased what a prospect maybe said on a call. Six weeks.

Except now with AI it takes one engineer 6 hours, people realize it's the wrong thing and move on. If anything, I would say it helps prove the point that typing faster _does_ help.

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

#33

Post by eecc »

krackers wrote: post #27
petcat wrote: post #20

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…

>Source code in a higher-level language is not really different anymore Source code is a formal language, in a way that natural language isn't.

This is the answer

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

#34

Post by inamberclad »

krackers wrote: post #27
petcat wrote: post #20

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…

>Source code in a higher-level language is not really different anymore Source code is a formal language, in a way that natural language isn't.

When you get to the really tightly controlled industries, your "formal" language becomes carefully structured English.

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

#35

Post by shermantanktop »

gedy wrote: post #8

I'm cynical but kinda surprised that so many mgmt types are rah-rah AI as "we're waiting for engineering... sigh" has been a very convenient excuse for many projects and companies that I've seen over past 25 years.

Absolutely. Everyone loves a roadblock that someone else needs to clear, giving back some time to breathe and think about the problem a bit.

This only works in large companies. In startups this is how you run out of money.

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

#37

Post by operatingthetan »

felipellrocha wrote: post #22
petcat wrote: post #20

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…

If you truly believe that, why don’t you just transform code directly to assembly? Skip the middleman, and get a ton of performance!

I know you're being cheeky but we are definitely heading in that direction. We will see frameworks exclusively designed for LLM use get popular.

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

#38

Post by petcat »

inamberclad wrote: post #34
krackers wrote: post #27

Earlier quoted context omitted.

>Source code in a higher-level language is not really different anymore Source code is a formal language, in a way that natural language isn't.

When you get to the really tightly controlled industries, your "formal" language becomes carefully structured English.

Legalese exists precisely because it is an attempt to remove doubt when it comes to matters of law.

Maybe a dialect of legalese will emerge for software engineering?

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

#39

Post by svachalek »

n4r9 wrote: post #26
felipellrocha wrote: post #22

Earlier quoted context omitted.

If you truly believe that, why don’t you just transform code directly to assembly? Skip the middleman, and get a ton of performance!

Can agents write good assembly code?

With the complexity of modern pipelines, there are very few humans that can beat a good optimizing compiler. Considering that with an LLM you're also bloating limited context with unsemantic instructions I can't see how this is anything but an exercise in failure.

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

#40

Post by exceptione »

petcat wrote: post #20

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…

None of the comparisons make any sense. In short, these concepts are essential to understand:

- determinism vs non-determinism

- conceptual integrity vs "it works somewhat, don't touch it"

Post reply on HN