booty

All of what you said is wonderful, and I want to particularly call out this:

    I stopped assuming I had to work the way people 
    said I should. [...] I get to own everything but 
    the typing that way

I think this gets to the heart of my disconnect with the "I miss coding" crowd. I still get to do most of the stuff I found fun w.r.t. creating software.

Typing the actual lines of code was fun, sometimes, but it was never the goal. I feel like I'm still solving the same problems.

Yeah, never thought I'd say this but I think I agree with the marketing guys here. I guess there's a first time for everything.

"Graphics Processing Unit" was purely a marketing term at the time. I mean, there's no lies there. It was a unit, and it processed graphics. It doesn't claim any specific sort of processing capability. If Nintendo had invented that term in 1985 I wouldn't have seen anything wrong with them calling the NES' video chip a "GPU."

Of course today "GPU" has a pretty specific meaning. It basically inherited the meaning from the clunky outdated term "GPGPU."

https://en.wikipedia.org/wiki/General-purpose_computing_on_g...

    bespoke micro-explainers

Thank you for calling this out. There are certainly a lot of legitimate gripes with LLM generated code, but also a lot of never-before-practical solutions to manage code as well.

FWIW, I haven't seen the Gemini 4 explainers, but Codex and (particularly) Claude have been pretty decent at this for a while.

I have had pretty decent success instructing OpenAI/Anthropic models to do this. By default, they don't care too much about human readability (which is understandable) but they're amenable to instruction.

- Basic style/linter rules (so you don't get 200-line functions, etc) paired w/ instructing your agent how to use them goes a long way (e.g., a sane rubocop.yml in your repo, plus a note in AGENTS.md telling the agents how to run rubocop, or whatever makes sense for your language) - I have a code review skill that specifically calls out human-readability concerns such as making sure that identifier names represent their contents and intended use

The other key IME is that you need to make readability/refactoring passes outside of a particular pull request. When working on a specific branch the LLMs will be somewhat myopic, and do stuff that looks pretty good in isolation, but when you zoom out and look at the bigger picture it's kind of a mess - for example, often they'll duplicate some code that existed elsewhere.

The LLMs are also pretty good at generating Mermaid charts and tracing execution flows, which is a great way to understand code. It doesn't help them to produce more readable code but it helps me to understand code I'm unfamiliar with.

> What they specifically said was "enterprise scale projects". Enterprise scale means lots of users, decades of backwards compatibility, regulation compliance, logging and auditing, reporting, role based access control and permissions, integration with other enterprise systems, etc. etc.

Do you really think that's what they meant?

My recollection (NE USA) was that crappy monitors were common.

I.T. was just less well funded in general back then, I think, and hardware was relatively more expensive.

There was also just much less understanding of "hey, developers need somewhat beefy setups"

I remember at my first professional job, I had a 100mhz or 120mhz Pentium I. The receptionist had a 133mhz Pentium I with, I think, more RAM as well. (I remember because it pissed me off...)

There were also a lot more in-house development jobs. Some small non-tech company would grow to the point that the underfunded IT guy was writing all these little scripts and VB apps. And then he'd finally fight and fight and the company would hire a second person as programmer, so the IT guy could focus on fixing people's printers and reinstalling Windows, and management would not understand why they'd need to spend an extra $2000 buying a nice desktop and monitor for the $40K/year programmer they just begrudgingly hired for their company where the average salary was $27K/year.

Shit, even in the late 2010s, in a lot of places would still look at you like your hair was on fire if you asked for a second monitor... there was a stretch there where I'd just bring one of my own... also I remember I had a job where I had a second company-provided monitor and they took it away because they were hiring more engineers and it wasn't "fair" for me to have 2 because they didn't have the budget to give everybody 2 lmao

Yeah, I used it back then. A lot of VBScript on the server and a couple of years Visual Basic on the desktop.

VB/VBScript is almost like writing shell scripts, in one sense. You can write really maintainable, even elegant stuff. It's just that nobody else is, and the language is almost pathologically constructed to discourage it.

(Although, at least shell scripting was never really intended for big apps, so, it has an excuse)

Sans context, I really like the Anthropic and Claude's faux-academic, minimal-ish, intellectual-ish branding.

(Especially the way it looked ~12 months ago -- it's gotten more cluttered since then. Perhaps unavoidably, as the breadth of their offerings has grown)

But over time it's begun to feel like unsettling cognitive dissonance as their ambitions grow and the stuff to worry about has piled up.

VB6 sure looks nice, but I promise it was a hostile mess for anything besides simple GUI apps.

Also, trust me, the VB6 interface hits a lot different (which is to say: worse) on a cramped 800x600 or 1024x1768 monitor than whatever spacious thing you're probably viewing it on. =)

    Makes it that much more absurd that tooling on modern 
    platforms isn't anywhere near this level of discoverability 
    and developer-friendliness.

I can think of a few concrete reasons why.

1. The VB6 UI element palettes work well because there's essentially a 1:1 correlation between the icon and the thing it produces when you drop it onto the canvas. That works well for visual elements but less well for things that don't have visual analogs.

2. Toolbars/palettes don't scale well past a few dozen items, whereas a VSCode-style command palette or text command autocomplete can scale nearly infinitely.

3. The way HTML works is a totally different paradigm than VB6's fixed grids. Obviously (as this demo shows) you can do that in HTML, as long as you're willing to ship stuff that kind of works like a VB6 app.

    It doesn't really matter what the AI companies 
    want, if they misjudge the market somebody will 
    just start a competitor and take it.

This kind of "free markets solve everything" magical thinking is cool when we're talking about lemonade stands, but unfortunately it just isn't reality when we're talking about markets with a really big moat such AI model training.

Even if you made the US the freest market ever, you have the small problem of your free-market hero startups needing to compete with state-sponsored models from China.

(Also, free markets depend on savvy consumers to function properly. We assume that consumers will not choose lemonade that poisons them, for instance. This works well for lemonade stands -- one assumes consumers will steer clear of the lemonade stand ringed by corpses -- but works less well when the product is more complex and people don't understand it. You know, like AI.)

> And I think it's getting obvious by now that inference will move to local compute

From the bottom of my heart, I hope that's the future.

I'm not convinced that will be the case. The AI companies don't want you to have local control. They want you to subscribe to a service that they can change at any time.

I grit my teeth when I type this, but (god help us) I think Apple is maybe the best (least bad?) hope here. They are the only big player with the hardware chops and without a current vested interest in getting you addicted to monthly AI subscriptions. I'm not saying this is highly likely... I'm just saying that out of the current major players, they're the ones with the ability and motivation to move in this direction in the near future.

The next best hope is probably just nVidia or AMD catering to the consumer market once again, after the AI bubble bursts or the datacenter market reaches saturation.

The outside hope is that some startup makes a business out of burning open weight LLMs to silicon like ChatJimmy... although ChatJimmy was bought up by AMD AFAIK.

> I wonder how much of that is caused by folks actually noticing actual degradation in product quality over time (whether or not this exact product is suffering from it).

That's certainly common!

I think ASICS' running shoes were a fun example of where this was probably not the case.

- I certainly didn't notice a difference in that time, though I'm admittedly not much of an actual runner

- Serious runners might notice small technical differences, but the negative user reviews didn't seem to indicate those were the people making the complaints

- The overall user reviews remained positive

- The competition in the shoe market is incredibly fierce; I'm not sure a brand could tank their quality and survive for long

- Let's not forget the other big variable: the wearers' bodies, particularly their feet. Now, those definitely do change over time -- most often for the worse, sadly!

- I doubt anybody was blind A/Bing a pair of Nimbus 20 against a pair of Nimbus 21 or 22 or 23 or 24. At best, a longtime Nimbus buyer is probably comparing a brand new pair of e.g. Nimbus 24 against their degraded but broken-in Nimbus 23 and their memory of how the Nimbus 23 felt when new. (And their body is a year or two older at that point..)

- Because it's such a long-running line of shoes, there could certainly be year-to-year variations... but it's hard to imagine there was an actual 5 or 10 or 25 year downward slope. I mean, otherwise at that point the shoes would just be instantly injuring you or falling apart in a week

- Also because it's such a long-running product line and (aside from bleeding-edge professional marathon/track shoes) sneaker manufacturing in general kind of seems like a solved problem... it seems like all of the possible cost optimizations have already been optimized. I don't really think there's much of a manufacturing or bill-of-materials cost difference between $20 running shoes and $200 running shoes anyway -- I'd be pretty surprised if "quality shrinkflation" was really much of a viable way for ASICS to save a few pennies.

> Then it's probably not really a big deal to find a public charger somewhere you'd be spending the hour or so anyway. you dont see any newish shopping center these days wo a bank or two of chargers but also lots of parks, libraries and other places youd go that dont cost money have chargers now too.

I don't really see a lot of public chargers here in the NE USA, but it's also highly likely I'm simply not looking for them either.

Taking an hour out of my day a few times per week to charge an EV someplace public also sounds like a huge PITA. However, I agree that it's worth it for environmental reasons. I would probably also learn to like it. It's like going to the laundromat. Nobody likes it... but it's also an excuse to chill out and read a book for an hour or two! (or whatever)

For years I used to buy ASICS running shoes. Every year they released a new model of each shoe: "Nimbus 23", then "Nimbus 24" the next year, etc. And every year people would complain in the user reviews about how each shoe was worse than the last.

I was like, wow, I guess the shoes must be literal torture devices full of MRSA-covered broken glass at this point. They've been getting continuously worse for 24 consecutive years!

Of course, what was really happening is that they were not getting worse, but naturally every year there was some small percentage of vocal dissatisfied users, while the silent majority simply enjoyed their shoes and didn't have much to say about them.

(The sorta-opposite happens in sneaker reviews as well. People will gush about how cushy the sole in some particular new sneaker is. Well, yeah, of course it's cushy -- you're comparing a new sneaker to your old sneaker where the foam had lost its bounce...)

Anecdotally, I've never heard this. I have an American hybrid from 10+ years ago with 90K miles and it's been super reliable. (Knock on wood...)

> Unless you live in bumfuck nowhere with expensive electricity, zero solar power and a daily 5 hour commute, an EV will likely work just fine for you.

Whoa, you're leaving out some pretty big demographics.

There are also a lot of people (the majority of people?) for whom EV charging is inconvenient or impossible -- apartment dwellers and people without driveways.

(Yes, yes, some apartments offer EV charging and some people without driveways can just run a charger out to the street)

Strictly from an economic standpoint: The $10T goes right back into the economy. That's $10T worth of STEM jobs and manufacturing and so on. Arguably, it should be spent more directly on schools and universal healthcare and so on, but $10T also creates a lot of jobs and healthcare benefits and funds public schools and so on so it's a tricky comparison to make.

From a non-economic standpoint: Aside from ensuring we don't destroy this planet, what is more important than finding out if we're alone in the universe? Not much, if you ask me.

(I realize finding algae on Saturn's moon doesn't definitively answer that question but it's certainly a uh... pretty big data point)

Maybe. The market will figure out if this is viable, I guess.

For smaller projects or short-lived projects, "AI without talented engineer" is a viable choice already.

But a lot of projects are big and long lived.

The difference in complexity between 1K lines of code and 10K lines of code isn't merely 10x. It's usually more like 100x.

So even if AI becomes 10x better than today (which seems reasonable) there's going to be a level of complexity beyond which you still need some kind of talented engineer-type(s) steering the AI.

At our company (big Rails/React monolith) all PRs do get a human review. Now, I use LLMs to accelerate my reviews, but there's still a lot of space for humans.

- LLMs struggle, or at least burn oodles of tokens, on big complex codebases. Managing tech debt helps the agents as well IMO. - If you ask an LLM to review a non-trivial pull request, it nearly always seems to find at least 10 issues. Many of which are not worth pursuing. Often, they would introduce a lot of extra complexity to harden the code against scenarios we don't care about or can never happen. So there's a lot of room for human judgement there. Typical scenario - the LLM reviewer finds 10 issues and I judge that 2-3 are worth pursuing - As you said, often the architectural approach sucks even with frontier LLMs. Usually from a lack of problem space / usage scenarios more than a lack of technical chops - LLMs tend to err on the side of overengineering the shit out of everything

I do not see how LLMs will be able to manage huge, hairy polygot codebases without humans-in-the-loop in the near future.

Given the pace of progress, I'd be a fool to bet against LLMs in the medium term future. But I think it's far from a given. LLMs themselves, and large codebases, are essentially many-to-many problems approaching something like O(n^n).

It's interesting to think about this in the context of parent poster's story about the Amiga emulator in the nuclear power plant.

Or, more broadly, in the context of any situation where the software is closely coupled to a specific operating system and/or hardware.

Having the source code would have helped tremendously, but might not have been sufficient because of the hardware story and the regulatory approval factor.

    but my anecdotal experience is that LLM written 
    software is very reliable and easy to extend and 
    develop.

Extremely refreshing to read. The whole thing, not just this statement.

Too much discourse creates a false dichotomy of "awesome, wonderful, hand-crafted code" vs "shitty AI slop."

A lot of hand-crafted code is pretty bad. This is true even with talented engineers: there are often edge cases they did not think of... and in many cases, could not have thought of.

And AI code is pretty good if it's steered and vetted by a knowledgeable engineer. It is clear to me, and has been clear for a long time, that "talented engineer plus AI" is the winning combination and will remain that way for at least the near future.

    Everyone in the team has become simple 
    rubber-stampers for whatever the AI puts out.

Whoever figures out better ways to:

1. Present a big AI PR to a fellow human for review 2. Understand a big AI PR, as a human reviewer

...is going to be a hero. This is one of the biggest unsolved problems of this new era.

I've been experimenting with this, but it's early days. My efforts are mostly along the lines of having AI generate artifacts that guide the reviewer through the PR in execution flow order, explaining the reason for changes along the way.

Gran Turismo 3 was where I first started experiencing the "uncanny valley" of graphics. The game looked and felt incredible... so incredible that the lack of damage felt like an immersion-breaker in a way I hadn't experienced before.

    I dont know how they make money here

Well, here's the neat thing: they don't!

Snark aside, Luna 5.6 was (is) an incredible game-changer.

If you're able to use the OpenAI ecosystem, Luna's price/performance is really good. Almost like "they messed up and accidentally made it too good" good.

That's interesting.

I've really gone in the opposite direction: having a dumber model orchestrate. In my case, it's usually a Luna orchestrator spawning Sol/Astra subagents to do the "big brain" work of planning and reviewing.

Reason I went with "dumb orchestrator" was just to save tokens. Having Opus/Sol (let alone Fable/Astra) orchestrate was burning tokens like crazy for me even when much of the gruntwork was being done by Luna/Sonnet/Haiku subagents. (Luna is also really good, like way better than Sonnet...) Perhaps it was a skill issue on my end though, maybe I wasn't just managing context properly.

    "benchmark margins have become a less 
    reliable guide to real-world differences" 
    sounds like a big problem.

My guesses:

1. Real-world use cases typically involve big, hairy, crufty, tech debt laden codebases and benchmarks do not.

2. AFAIK "success" in a benchmark essentially boils down to "do the tests pass and do we get the right result?" which is something the LLMs have been achieving with ease for a while, except maybe for uber-challenging coding tasks that would be outliers in just about any workplace. Whereas real-world software engineering is usually just a bunch of CRUD... and "success" involves harder to measure dimensions like "maintainability" and "did you overengineer this?" and "how did you cope with a bunch of vague and maybe contradictory business requirements?"

Having said all of that, I have never ever looked inside any of these benchmarks. I'm putting my guesses out here strictly in the tradition of "the quickest way to learn about something is to be wrong about it on the internet."

It was partially explained by the article. It was not stated that ROSENOW was repeated in 173, and it was not obvious from the article text why ROSENOW would ever be repeated. Thus my curiosity.

A sibling commenter explained it - Rosenow is both a municipal name and a district name, so naturally it would be repeated. (Like "New York, New York")

    It also makes sense that a longer crib 
    would generally be more effective than a 
    shorter one.

It would seem to me that the odds of looking for even a single ROSENOW in the decrypted message would be plenty. The odds of a single ROSENOW randomly occurring in incorrectly decrypted output are vanishingly small. So it seems to me that looking for ROSENOW is a safer bet vs. looking for ROSENOW ROSENOW -- a single ROSENOW is a great sign you've got the correct key, whereas looking for ROSENOW ROSENOW seems like it would deliver false negatives (think of all the times we say "New York" rather than "New York, New York")

I'm a novice at crypto though, so, maybe I've got that totally wrong.

Ah, thank you! That makes sense.

When visiting a Iowa-class WWII battleship, there were no shortage of things that impressed me. The huge guns, and the decades-ahead-of-their-time analog firing computers. Obviously.

But the galley was NOT far behind. From an impossibly tiny space they served 1,700 meals... three times a day... seven days a week.

The logistics of mass food preparation are so wild.