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

71–80 of 231 posts

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

#71

Post by charcircuit »

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!

Assembly eats up context like crazy. I usually only have my LLM use assembly for debugging / performance / reversing work.

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

#72

Post by nemo44x »

operatingthetan wrote: post #37
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!

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.

I think that’s possible too but the trouble is training them. LLMs are built on decades of human input. A new framework, programming language, database, etc doesn’t have that.

We are in the low hanging fruit phase right now.

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

#73

Post by senko »

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.

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

Heh, depends on what you do. Many times the stakeholders can't explain what they want but can clearly articulate what they don't want when they see it.

Generate a few alternatives, have them pick, is a tried and true method in design. It was way too expensive when coding was manual, so often you need multiple rounds of meetings and emails to align.

If you don't think coding was the bottleneck, you're not thinking creatively about what's only now possible.

It's not what you can do faster (well, it is, up to a point), but also what can you now, do that would have been positively insane and out of the question before.

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

#74

Post by skydhash »

myylogic wrote: post #12

[flagged]

The thing is that speed in building stuff doesn't really help. What you want is a model and a simulation framework. In the traditional way, you usually start with a simple model and a simple framework. Then when you add a new parameter, you adapt the framework and once you've found a balanced set of inputs, you think which new parameter you want to add. This iteration leads to a great understanding of the model and the behavior of the system that implements it.

LLM usage is usually a build of the system for the full parameter set. The speed increase is countered by the fact that there's no understanding of the system and the simulation space is so large that the user don't really bother to explore it. There's been a lot of talks about having a full test suite for simulation, but they are discrete and only prove specific points in the input space (There's a lot of curves that can pass through a finite set of points)

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

#75

Post by john_strinlai »

observationist wrote: post #66
john_strinlai wrote: post #30

Earlier quoted context omitted.

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

Sometimes articulating the problem is all you need to see what the solution is. Trying many things quickly can prime you to see what the viable path is going to be. Iterating fast can get you to a higher level of understanding than methodical, deliberative construction. Nevertheless, it's a tool that should be used when it's useful, just like slower consideration can be used. Frontier LLMs can help significantly in e…

so, what i am gathering is that some people in this comment section read "typing faster" literally, while other people are reading it and translating it to "iterating faster".

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

#77

Post by batshit_beaver »

petcat wrote: post #38
inamberclad wrote: post #34

Earlier quoted context omitted.

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?

Legalese already exists in software engineering. Several dialects of it, in fact. We call them programming languages.

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

#78

Post by petcat »

ruszki wrote: post #58
petcat wrote: post #38

Earlier quoted context omitted.

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?

Legalese is nowhere near precise, and we have a whole very expensive system because it’s not precise.

It is an attempt the be precise, and to remove doubt. But you're right that doubt still creeps in.

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

#79

Post by raw_anon_1111 »

podgorniy wrote: post #60

Yeah, we again have a solution (LLMs) in search of problems. Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z". -- This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to…

This is categorically not true. For almost all of my 30 years it’s been

1. Talk to the business, solve XYProblems, deal with organization complexity, learn the business and there needs.

2. Design the architecture not just “the code”, the code has to run on something.

3. Get the design approve and agree on the holy trinity - time/cost/budget

4. Do the implementation

5. Test it for the known requirements

6. Get stakeholder approval or probably go back to #4

7. Move it into production

8. Maintenance.

Out of all those, #4 is what I always considered the necessary grunt work and for the most part even before AI especially in enterprise development where most developers work has been being commoditized in over a decade. Even in BigTech and adjacent codez real gud will keep you as a mid level developer if you can’t handle the other steps and lead larger/more impactful/more ambiguous projects.

As far as #5 much of that can and should be done with automated tests that can be written by AI and should be reviewed. Of course you need humans for UI and UX testing

The LLMs can do a lot of the grunt work now.

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

#80

Post by tcmart14 »

petcat wrote: post #67
tcmart14 wrote: post #61

Earlier quoted context omitted.

I really hate the trying to make LLM coding sound like it's just moving up the stack and is no different from a compiler. A compiler is deterministic and has a set of rules that can be understood. I can look at the output and see patterns and know exactly what the compiler is doing and why it does and where it does it. And it will be deterministic in doing it.

> compiler is deterministic and has a set of rules that can be understood. 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. It appears that code-generation is not as deterministic as you seem to think it is.

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.
Post reply on HN