Even the most cockeyed reading of history will tell you that it is absolutely vital to the survival of humanity and all that is good on this earth that the US military be tied down and held back.
copyright is not “broken,” it was always a two-faced scam designed to protect “owners” at the expense of creators. don’t expect this blatant hypocrisy to kill copyright, either - death of copyright is a slippery slope leading straight to communist utopia, and the death of the global acqui-parasite class
in a world where getting 3 people to show up to dinner is a challenge, a coherent, organized group large enough to be visible as a percentage of the population is an exceedingly rare and powerful entity. but history shows that such an entity is usually either 1) stable and peaceful, but actively decaying due to its position of hegemony or 2) unstable and violent, using conflict to sharply define its boundaries and growing by dividing the rest of society into "insiders" and "outsiders". some days i feel like we're microbes stuck in microbiological cycles. but if we make it past this rut, we will have all that we need to lay down an even stronger foundation, to codify systems and organizations designed to scatter and suppress hate and intolerance.
yeah, he’s a real populist with the <15% that wants the federal boot on everyone else’s neck. i think there’s a name for that specific type of “populism”.
if you wanna cheer for fascism, you should do so openly. no one is fooled anymore, and no one will think any higher of you for being in denial about it
i’m confused now. if he’s a serial child rapist sending mexican goons into american cities to murder white nurses, does that mean he’s more of a populist, or less? figured i’d check with the expert.
most web pages are about to be HTML/JS/CSS generated by LLMs directly for users. Truth is, pre-LLM web frameworks were designed for two things: save developer keystrokes and delay the spaghettification of the codebase. We just automated keystrokes, so that's largely irrelevant now. Users don't read code, so spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis, and provide clear ways to fork the spaghetti or start over when the user is frustrated with some bug. There's no framework designed with these requirements in mind, but I am working on one.
> spaghettification is also a non-issue, as long as the framework defines clear containers for spaghettis
Sorry, but I disagree strongly with this. When there is, inevitably, a bug that the LLM can't fix, someone's going to have to read all that spaghetti, and they'll curse whoever put it there. "clear containers for spaghetti" is a pipe dream, all abstractions leak, and the bug may very well be in the spaghetti. "Just start over" is unrealistic for large, complex apps.
Of course, if you really have a solution for this, that would be incredible.
nothing lives forever. software comes into life out of necessity, develops complexities, eventually becomes incomprehensible, obsolete and dead. it’s a natural cycle that we should work into the user experience, instead of defining it as a failure state that we need to “solve for”.
it's always hilarious (and there's a lot of this going on right now) when major players eliminate themselves from the competition, while deluding themselves that they've eliminated the competition.
generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written.
if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
Not to be rude, but what about understanding the "transcendental nature" of LLMs allows people to build more, faster, or with better maintainability than a "hardened industry titan"?
New generations are always leapfrogging those that came before them, so I don't find it too hard to believe even under more pessimistic opinions of LLM usefulness.
They are young and inexperienced today, but won't stay that way for long. Learning new paradigms while your brain is still plastic is an advantage, and none of us can go back in time.
> They are young and inexperienced today, but won't stay that way for long.
I doubt that. For me this is the real dilemma with a generation of LLM-native developers. Does a worker in a fully automated watch factory become better at the craft of watchmaking with time?
I think the idea that LLMs are just good at "automating" is the old curmudgeon idea that young people won't have.
I think the fundamental shift is something like having ancillary awareness of code at all but high capability to architect and drill down into product details. In other words, fresh-faced LLM programmers will come out the gate looking like really good product managers.
Similar to how C++ programmers looked down on web developers for not knowing all about malloc and pointers. Why dirty your mind with details that are abstracted away? Someone needs to know the underlying code at some point, but that may be reserved for the wizards making "core libraries" or something.
But the real advancement will be not being restricted by what used to be impossible. Why not a UI that is generated on the fly on every page load? Or why even have a webform that people have to fill out, just have the website ask users for the info it needs?
But do those watches tell time better? or harder? or louder? Once you have the quartz crystal and have digital watches, mechanical movements became obsolete. Rolex and Patek Philippe are still around, but it's more of a curiosity than anything.
we’ve been taught to think of programs as sculptures, shaped by the creator to a fixed purpose. with LLMs, the greatest advance isn’t in being able to make larger and more detailed sculptures more quickly; it’s that you can make the sculptures alive.
But who _wants_ a program to be alive? To be super clear, I love the tech behind LLMs and other transformers. But when discussing regular, run of the mill software projects that don't require AI capabilities - do you really need to have the understanding of the transcendental nature of LLMs to do that job well?
> generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written.
This part tracks. It's honestly rather generic.
> if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
This, I'm not sure applies either. TBH the biggest risk I'm seeing already right now is how quickly we're starting to see juniors trying to enter the job market who don't have the faintest idea how actually code. Let alone build software (but let's be honest, that's usually been the case). What decisions to make when writing something are based on factors outside just implementing the functionality: how maintainable is this? how extensible?
Giving a junior a sycophant that's reasonably competent at spitting out something functional (not necessarily functional in the sense you need it to be but apparently working) is a recipe for disaster IMO.
There will absolutely be some who "get it". But, how does that scale?
More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".
> More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".
I am definitely worried about that. I got into a mode of doing morning code review every morning due to having a bunch of active open source repos, so over time as they grow in activity I learned to adapt my schedule, mind set, and everything around how to do the right amount of code review (when to finish the PR yourself, when to give pointers to train a new contributor, when it's not worth your time yet to say more than "tests fail", etc.). I started for years pulling every piece of code locally, running it, figuring out why someone would make a change like that, etc. and then it took like 5 years before I could actually start to do code review well just by reading a git diff. I needed to know the domain, the language, the problem space, and how people tend to work, all well enough to make that simple enough to have a mental model.
Then, I tend to see some junior programmers put up LLM stuff and I go "oh just handle the extra memory allocations and it's good to go" and they go "wait handle what where?". If you can't eyeball that in under a minute of scrolling through the code... then you shouldn't be doing code review by scrolling through it yet. But if they keep doing it like this, they will never build that skill.
That's why I think the right LLM usage is really for those who have already built that code review skill. It's not to gate the usage of LLMs, but people will never learn if they aren't strongly engaging with the code at some level.
reply