I kinda like the music comparison because it's so rich with sociological analogues. You have the gear snobs who can't stop buying more premium gear but never sit down and write anything. The kids who pick up a copy of Garageband and put together hits with their natural talent, sense of taste and and interesting story to tell. Soundtrack and videogame composers who have hybrid instincts of session musicians and architects. Avant garde musicians who you're never fully sure of whether they're playing a joke you're in on (or on you) and that's kinda the point. Music critics who have never played or written music a day in their life and yet end up becoming arbiters (or more accurately, delegates) of taste. Fandom stans and ringleaders who absorb it as an identity and run extraordinarily well organized cults with an iron fist.
You can probably find correlates here with coding and AI any which way you look. Coding is so rich that you can use it to do artistic, creative pursuits because it really is an interactive and world building medium if you want it to be. And it can also be a practical, reliable machine that helps you get useful business objectives done. And anywhere in between!
Perhaps the author is indexing on the former because there's an intrinsic value to that, and intrinsic values seem to be quite drowned out by the noise of extrinsic values in this media supercycle.
But I don't think it'll be that way forever. Whenever things get too noisy, people have a way of seeking peace and quiet.
I don't disagree with your conclusions (enterprises will pay top dollar for service guarantees, integration, and someone they can sue) but by that same logic there is no clear winner with Anthropic/OpenAI. Claude has a habit of going down on me when I need it most and seems to be struggling to even keep 3 nines of availability. They're actively hostile to integration and seem more convinced they should be suing others than behaving in a way that doesn't get them sued.
That's not to say I don't believe that there won't be a closed source correlate. I just don't know if OAI and Ant are all that exists.
"Anyone who depends on code review to find bugs is living in a fool's paradise. As everyone should know by now, it is not in general possible to find bugs by examining the code."
I think this is pretty clumsily stated. The way I would best summarize what it should be is "The person best suited to address bugs in the code is the author/owner." That's usually some blend of detecting and fixing them. Code review can certainly surface bug-prone patterns being introduced (or extended), and even catch them directly.
But as many of the peer commenters state here, the depth of code review that finds buggy behavior and risky structuring is pretty involved and an expensive use of time. At most places I've reviewed code prior, this was always amortized as cost of doing business. Maybe partly because there wasn't a "theoretically" faster alternative, and maybe because we were trying to avoid 2 steps forward 1 step back.
Now, I think we are struggling with "the clinical trial problem" where there is more pressure to ship using AI but it doesn't actually abridge the QAing and review part. The problem with trying to abridge that part is it just creates backpressure like a spring and then catastrophically explodes 10x worse later on than if it was dealt with directly. It can be very easy to build a circle of pitfalls that were completely unnecessary. I think that automated code review techniques are going to have to evolve to keep up with the new paths that code can be generated through.
And to anyone that has to go through new, arms race enhanced forms of slop cannons -- my heart goes out to you, because the old ones were never particularly pleasant to deal with.
I've seen folks make it work with a 3090 on 4 bit quant using turboquant for KV cache. That's key because 3090s remain the most cost effective gpu metal for enthusiasts (albeit 24g) and the jump to 5090 (32g) is quite expensive and not always worth the LLM specific performance; sadly, good 32g metal is somewhat lacking in the price point at or above the 3090.
One of the most challenging kinds of thought to work through with my engineers in professional communication is nuance. For example, they may say something like this, but actually mean "For a particular situation, this is wrong."
The context a decision is evaluated is particularly important for "rules of thumb" like this. There's the rule of 3 (which many senior engineers imparted to me earlier on in my career) - don't refactor until you've actually duplicated it thrice, but even so, what they speak of is a catch-22 that's pretty important to reason about carefully.
On one hand, if you overcorrected on the fear of abstraction, you could easily end up with 500 duplicates that are slightly different and need to be maintained 500 different ways, slowly causing slightly wrong behavior some of the time, data corruption, combinatoric explosion. Surely, once there is such a situation, some degree of abstraction is the only right decision.
On the other hand, if you overcorrected on the fear of duplication early on, you could easily end up with a premature optimization and complexity -- complexity which, most importantly, could be rooted in a gap of understanding of how the code will be used and what direction it may go in over time (often based on which direction the business will go over time).
The only answer that actually works, of course, is "somewhere in the middle." Obviously, that's pretty vague and not very useful. Where, exactly, in the middle IS the right place?
As the years have gone by, I've become more and more steadfast that the answer to that question is and must be an art and not a science. Of course, it must always be rooted in practicality, the actual context of the code around it and where the code/business was in the past and where it will be in the future.
But just as importantly, some of it must be based around beliefs in the face of imperfect information about what you want to invest in for the sake of the technology, the team that develops it, and the business that relies on it. It could be that for your team, your values make it make sense to go a little bit further than "good enough" on normalizing your data modeling, because the way you like to run your business requires that normal form to do the analytics and make decisions productively. It could be that for your team, your values make it make sense to go a little bit further than "good enough" on splitting service boundaries and ensuring clean queues and message passing infrastructure, because you have seasonal spikes where you need to scale up to a ton of load and then scale down after without constantly doing a song and dance or pre-provisioning fragile infrastructure.
But the most common thread there is - art, not a science. Every single decision depends on YOUR team, YOUR business, YOUR needs - and like any art, there is no universal rule or discovery or best practice in the industry that will magically work for your needs without working through the details of whether it appropriately fits your situation or not.
So with that said - I can't really agree with you. At any place I've ever worked with a competent team, maintaining duplicate code is just not that hard and follows the same process for being dealt with. Built a robust test suite that encodes the actual differences and the shared structure. Pull out the pieces that have a good reason to be abstracted and redesign the pieces that encode the true differential structure in a way that is intuitive. Lather rinse repeat. It's always straightforward because it's known - by the time you are doing this process, you've had tons of repetitions and data on what is driving you to develop the abstraction, so when you make the decision, you are making it empirically.
Conversely, I have seen many otherwise competent teams slowed to a halt with premature abstraction. Frameworks that were well intended and reduced duplication, but encoded coupling between components that at a certain point in the businesses progression, fought with reality rather than aided, and all because they were frozen into place before anyone empirically had really clear data about whether the abstraction would be worth it long term. Well intended "clean code" refactors that were meant to solve the old "bad duplication" but instead created a far more difficult to reason about "abstracted base" of code that didn't really solve any of the domain modeling problems and was just as difficult to maintain without introducing buggy behaviors (if not more so) than before.
The biggest problem is that premature abstraction is sexy and fun. There are incentives and dopamine hits from doing it extraneously. But fixing legacy duplication is not fun. And so when it gets done, it tends to get done in a pragmatic way to relieve pain rather than to elicit pleasure. That, I believe is one of the biggest confounding sociological aspects of this whole discussion.
What makes you think there will actually be a guillotine? This isn't the French Revolution era.
The alternative to your wet dream is that both Bernie and Luigi are hapless and actually incapable of altering the systems they rail against besides symbolic token gestures meant to appease the hopes of someone, anyone to serve as a messianic figurehead.
What if -- bear with me here -- the very thing that makes those founders able to make the $1B they would otherwise make would drive them to also ask why it is that someone else who had no hand in building or funding it gets lion's share of the $900M while they get only $100M?
You don't /know/ that people need to collectively get over "this" -- you have a feeling that it seems more fair to do that than the alternative. But you can look at what happens elsewhere in the world with regimes that implement exactly what you are describing. And what happens is the people who are most equipped to be the golden gooses that you are proposing are just as equipped to simply most somewhere they can do so unencumbered.
That's why what you're proposing will just never really work.
What happens to the person who earns their income laying bricks when an automatic bricklaying machine is built? Is it unethical for them to earn that income because they are operating the machine? What about the person who finds them people who need bricks laid because the person who lays bricks finds it hard to get good clients who aren't a pain?
I really wish people weren't so easily seduced by the labor theory of value.
The kind of abliteration you are mentioning is no longer state of the art or the most common form of removing the refusal layer in most models. Your your understanding was up to date about a year and a half ago, but has been out of date since after that.
Couldn't agree more. Maybe it's because it's a shining example of their ideological system that actually alters /my/ life, in ways that are tangible and which i can grasp, and makes it better.
It might change soon. Nemotron 120b was never flashy but always well regarded in the community and had material strengths at long context. The 550b next gen version is out now and still very fresh. It is too early to tell but for some reason I believe the impact it will eventually have is quite strong. NVIDIA open weight models are really good. They're not flashy but they're always well put together, well documented, well licensed, and in general make for truly great bases for customization - whether it's Nemotron or Cosmos.
Cosmos 2 in particular already has taken the image diffusion world by storm in a finetune (Anima) essentially replacing/dethroning the previous budget king SDXL. I wonder if the newest Nemotron could have the same impact for open weights LLM?
You can always run deepseek yourself, v4-pro and flash are open weights. It's a little tricky to get the hang of self deploying open weight models but you do fully own your deployment substrate and privacy narrative at that point.
I've been really enjoying claude design but my biggest critique of it (and frankly how vanilla claude handles files in general) is that it has no native conception of git-like version control. In code land you can work around this with harnesses so there's only so much harm claude code/opencode can do, but to your point in small biz land when it's putzing around with a system of record without rewindability, things could get really messy really fast.
A couple more thoughts here - the hard part is not just the data side of it, it's replaying/unplaying actions. Many actions are non-reversible. Code is clean in the same way that google docs is clean. But for many business processes, some actions just can't be unwound once started. If claude initiates a wire that it shouldn't, no amount of git technology will undo that wire.
It's been a very strange realization to have with AI lately (which you have reminded me of) because it also reminds me that the same thing works with humans. Not the killing part at least, but the honeypot and jailing/restricting access part.
Probably because telling someone not to do something works the 99% of the time they weren't going to do it anyways. But telling somebody "here's how to do something" and seeing them have the judgment not do it gives you information right away, as does them actually taking the honeypot. At the heart of it, delayed catastrophic implosions are much worse than fast, guarded, recoverable failures. At the end of the day, I suppose that's been supposed part of lean startup methodology forever -- just always easy in theory and tricky in practice I suppose.
401k rollovers into IRA aren't that hard these days and you could always use that IRA to have a more customized strategy, more specifically direct indexing of a major fund minus key ticker symbols you don't want exposure to. Of course, that all presumes that you won't regret excluding this long term.
We can fault them individually for such corny and groan inducing deceit, but we can't fault them for society's role in rewarding the highest profile and most wealthy founders (OAI/Anthropic) taking the exact same approach with optics.
I am about to go on a long rant, but there is so much money sloshing around the capital allocation machine going towards a vision of the AI managed and optimized future that the propaganda machine for these rose colored delusions must work in overtime. What disappoints me is the question of where the heck are the bears? Did they all go into hibernation 5 years ago when QE gave the retail kindergartener a handgun to pump low quality tickers to the moon? have we just societally accepted that everything should be a hyperreal version of sports gambling now and the world is and ought to be an efficient market of hyperstition?
I may be old and grumpy saying this, but this all sounds dumb and corny. I would like some of the very capable traders who make money repricing mispriced assets to find a way to make money deflating this bubble and bring this environment back to sanity. And I say this as someone who likes the capabilities of AI but continue to see it do little to none of the hard work solving incompressible problems that continue to create and retain enterprise value.
To get off my soapbox for a second and get back to your quoted passage -- what they're really saying is "We are working very hard to make this future coming, and we think so little of your intelligence that we believe you'll fall for the fear tactic of believing it's inevitable, ignoring the fact that it won't happen without someone's hands. And in this case, it is very much our hands, which are incentivized to not just do it but to do it so well that we ensure we do everything possible to make this happen. Part of which means persuading you that it is guaranteed to succeed. If we ever let the honest truth slip that what we're proposing is extremely hard to pull off with pure AI and we're just going to be a any other commercial real estate investor like anyone else, the jig is up."
That's what every single one of these kinds of hypocritical navel gazing faux-concern proclamations amount to for me. Astroturf.
Agreed. I will say that poking around a bit more on that site it looks like a temporary restraining order involving the same parties was granted, so perhaps there's some more history to this dispute than just what is visible on said link.
I'd be interested to see what things look like on a longer timescale, say 500, 1000, 2000, 7000 years. 80 years of time feels like a long time on a human lifescale, but on a civilizational timescale it is a lot shorter.
You can probably find correlates here with coding and AI any which way you look. Coding is so rich that you can use it to do artistic, creative pursuits because it really is an interactive and world building medium if you want it to be. And it can also be a practical, reliable machine that helps you get useful business objectives done. And anywhere in between!
Perhaps the author is indexing on the former because there's an intrinsic value to that, and intrinsic values seem to be quite drowned out by the noise of extrinsic values in this media supercycle.
But I don't think it'll be that way forever. Whenever things get too noisy, people have a way of seeking peace and quiet.