yowlingcat

I just wonder whether the analogy holds from atom based businesses to byte based businesses. At the end of the day, there are pretty hard constraints on how much a competitor could undercut Vulcan - they'd need to be better a) crushing rocks and b) driving those rocks to where people need it. Something about that, while simple, seems really nonfungible to do well. The business may traffic in commodities, but the service and quality it provides ironically seems to be not really a commodity.

Conversely, AI models feel pretty different. People will swap models at the drop of a hat and while not perhaps fully fungible, the cost of switching can be as low as one engineers it to be. In this case, the service does really seem to feel more like a commodity.

Not sure where this leads or how this ends. Perhaps those two will swap poles for me (IE as robotic automation improves, there are more commoditized Vulcans, and as metered intelligence improves, they become less fungible). I just can't quite see how yet. Just food for thought.

But that assumes this is a net improvement on linguistic efficiency rather than an artifact. Given that they tried to RL away from this style in 5.1 I'm not terribly bullish of Claudlish becoming something people try and learn. It being dense is less the issue than it being vacuous (as another commenter mentioned here). It's just very unclear and ambiguous writing. I think it has no place anywhere that needs language to be put to productive use.

My guess is that there's probably a missing abstraction layer in the 3d editors somewhere. I am pretty bullish on AIs ability to solve this problem, even just based on existing image to 3d models like TRELLIS and HY3D. They work pretty darn well and take a lot of the burden out of not just modeling, but texturing and uv unwrapping.

That being said, I have a correlate here for music production and you could definitely make a lot of the same arguments about it, and they'd be true -- really high learning curve to make something halfway decent even assuming you have the taste part sorted. Some of it is the ability to just creatively think in another language once you become fluent in it.

I think AI can give you leverage when it does stuff you could actually do it manually yourself because you can manually evaluate it and correct it competently. The hard part is how would you evaluate work that is beyond your current competence level?

If that isn't easy, if it's incompressible relative to your current skill level, then that's the very human part that will always be a bottleneck. And that's fascinating to me because if there were better AI tools for music production when I picked it up a few decades ago, I don't know that I would have developed the same fundamentals.

What will fundamentals look like in a post-agentic world? If a lot of the manual gruntwork disappears or is more heavily abstracted, I believe that will matter a lot more.

Dont forget the following:

- Minimax M3 Pro (2.7T)

- GLM 5.3 (or beyond)

- Deepseek V4 Pro (current V4 Pro is preview)

- Kimi K3 weights out in 8 days

Exciting time on the open-weights frontier.

I understand the concern and it's fair but I am very curious about what happens when the two notions of "free" (free as in beer, and free as in freedom) start to diverge because the former gets easier to do.

The latter as always been more durable. Linux doesn't have the mindshare it does because it's "free" as in beer - it's because it's "free" as in freedom.

The price of freedom, of brewing your own beer, is sometimes higher than buying it from the store. But for many folks, the control over the supply chain is what makes it worth it. In LLM-land, it might take a little bit of time for folks to catch up -- or maybe a lot of that is already in motion as companies get paranoid (and rightfully so) to frontier labs getting a little grabby about data. If you need a ZDR environment, "free" as in freedom has a very high premium that you will pay and rightfully so.

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.

GLM5.2 is not available on bedrock or gcp vertex. They aren't real options.

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.