Writing code is cheap now

> "Or a crane that will stall and drop its load randomly. It would have been sent to the scrapyard on the first day."

The only reason you have the concept that engines can "stall" is because people have bought engines that can stall by the hundreds of millions, instead of the earliest people refusing to buy them at all and all waiting for the perfect engine.

Container ships can sink with all the containers lost at sea. Still used.

Steam train engines could explode, derailing the train and killing some passengers and employees. Still used.

Buildings can collapse. Still used.

Pneumatic tyres can burst. Still used.

Here[1] is Tom Scott using a recreation walking crane from the 13th century, a technology going back to Roman times, which has no evidence that it ever had brakes on it historically. Look at that and tell me you think the rope never snappped, the wood never broke, the walker never tripped and the thing never unreeled the load back to the ground with the walker severely injured, because if it went wrong builders would refuse to use it? No chance.

Nothing functions like you're claiming; that's where we get the saying "don't let perfect be the enemy of good enough", as soon as stuff is better than not having it, people want to make use of it.

[1] https://www.youtube.com/watch?v=pk9v3m7Slv8

This has been my experience, too. In dealing with hardware, I'm particularly pleased with how vision models are shaping up; it's able to identify what I've photographed, put it in a simple text list, and link me to appropriate datasheets. yday, it even figured out how I wanted to reverse engineer a remote display board for a just-released inverter and correctly identified which pin of which unfamiliar Chinese chip was spitting out the serial data I was interested in; all I actually asked for was chip IDs with a quick vague note on what I was doing. It doesn't help me solder faster, but it gets me to soldering faster.

A bit OT, but I would love to see some different methods of calculating economic productivity. After looking into how BLS calculates software productivity, I quit giving weight to the number altogether and it left me feeling a bit blue; they apply a deflator in part by considering the value of features (which they claim to be able to estimate by comparing feature sets and prices in a select basket of items of a category, applying coefficients based on differences); it'll likely never actually capture what's going on in AI unless Adobe decides to add a hundred new buttons "because it's so quick and easy to do." Their methodology requires ignoring FOSS (except for certain corporate own-account cases), too; if everyone switched from Microsoft365 to LibreOffice, US productivity as measured by BLS would crash.

BLS lays methodology out in a FAQ page on "Hedonic Quality Adjustment"[1], which covers hardware instead of software, but software becomes more reliant on these "what does the consumer pay" guesses at value (what is the value of S-Video input on your TV? significantly more than supporting picture-in-picture, at least in 2020).

[1] https://www.bls.gov/cpi/quality-adjustment/questions-and-ans...

I agree mostly with your metaphor, I think perhaps I disagree slightly on how it's applied. You don't need to create your own tools to create art, but I don't necessarily map the "tools" to code. The act of programming is mapping information to hardware, the value is in the information, and using LLM's to bypass the phase where you obtain, synthesise, and extend that information is the part where you lose the benefits of iteration. If you're just using the LLM as a mechanical tool to output code, it's mostly not different from, say, using speech-to-text to output code. When you start hearing things like "I don't care about the quality of the code, just it's outputs" that starts sounding like someone isn't iterating on the information which is the crucial bit.

(I wrote this mainly from the perspective of what it feels like on the inside to write code as a human. I think https://news.ycombinator.com/item?id=47138965 explains it better in terms of the business aspect.)

> Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint.

> At the macro level we spend a great deal of time designing, estimating and planning out projects, to ensure that our expensive coding time is spent as efficiently as possible. Product feature ideas are evaluated in terms of how much value they can provide in exchange for that time - a feature needs to earn its development costs many times over to be worthwhile!

This doesn't seem quite right.

"Producing" code involves a lot more than just typing it. It's slow because the dev is planning things out at the same time, at a micro level. Suppose "a few hundred lines" is 10kB of text; actually typing that out at full speed is maybe half an hour of work for a reasonably accomplished typist. But basically nobody even writes blog posts that fast. As soon as you're writing more than a sentence or two and actually care about how you come across (never mind having to satisfy a compiler) you're invoking system 2 thinking. (I didn't even consider tab completion in my napkin math; it wouldn't really matter, because you have to already be thinking to get value out of it!)

Time spent planning isn't really about saving coding time, because it really can't be. It's not like ultra-cheap code production suddenly lets you just implement all the things and see what happens. Features can be net negative, or even outright harmful to the product. It takes resources to evaluate any unplanned change and then integrate it if accepted. (cf. the recent buzz about FOSS projects getting flooded with AI-generated PRs.) Deciding "this feature will/won't be worth the effort" is a rough guess at best, because the actual code/test loop is where you actually hit the unknown unknowns (presumably LLMs would feel the same way, if they were conscious).

And perhaps most importantly, simply meeting feature goals isn't enough. This might be slightly less true in a world where your developers (now partly LLM) don't care about the existing coding style or architecture and can readily adapt on the fly. But I'm still convinced that just letting everything accumulate without a clear vision — without oversight and accountability — will always ultimately lead to a tech-debt reckoning.

Besides which, "a few hundred lines... a full day" is a highly optimistic metric along an axis that has long been understood to make little to no sense. That's a day where things are only added and not removed or changed (to fix them), in a relatively new system (so that interactions with other stuff don't have to be considered). Extrapolating that rate gives you absurd results, e.g. a team of ten developers might re-create the entire Python standard library from scratch in a year.

Well, that becomes more realistic when you already know exactly everything that you're going to do. But the LLM doesn't know that either. In fact, it doesn't even have the advantage of sharing your team's vision and wanting to see it come to fruition. Ask the LLM: "We're creating a new programming language; what modules should the standard library have?" How helpful is that going to be compared to the (human) new guy?

> I never thought this type of work was particularly hard or expensive though.

Maybe not intrinsically hard, but hard because it's so boring you can't concentrate.

> the LLM becomes a helpful tool but requires a ton of guidance. Even the tests LLMs will write seem biased to pass rather than stress its code and find bugs.

ISTR some have had success by taking responsibility for the tests and only having the LLM work on the main code. But since I only seem to recall it, that was probably a while ago, so who knows if it's still valid.