> What code is truly about is precision: code is unambiguous, even when it’s abstract. It’s easy to conflate ambiguity and abstraction—both refer to “a single statement that could have to multiple meanings.” But the meanings of an ambiguous statement are entirely unconstrained.

I used to believe this, but after working at a successful SaaS I have come to believe that correctness and unambiguity are not entirely necessary for successful software products.

It was a very sad realization that systems can be flaky if there is enough support people to solve edge case problems. That features can be delivered while breaking other features as long as enough users don't run into the middle of that venn diagram, etc.

Fact is it always comes down to economics, your software can afford to be as broken and unpredictable as your users will still be willing to pay money for it.

Not sure if tools and technologies can solve accidental complexity.

In my opinion, a system that has been stable for years isn't 'mature' in a good sense. An exceptional system is one that can still change after many years in production.

I believe this is almost impossible to achieve for enterprise software, because nobody has incentive to make the (huge) investment into longterm maintainability and changeability.

For me, consistent systematic naming and prefixes/suffixes to make names unique are a hint that a person is thinking about this or has experience with maintaining old systems. This has a huge effect on how well you can search, analyze, find usages, understand, replace, change.

This is light on specifics, but is still directionally the closest anyone has come to describing my ideal future data platform. The founder Dan Sotolongo's work at Snowflake included Dynamic Tables which makes me think the proposal is basically this: a hybrid transactional/analytical database, with declarative domain-oriented schemas, with smart incrementally calculated updates, and a la carte performance characteristics (i.e. opt into row or columnar storage, or whatever indexing you like). Nathan Marz's Rama is also close to this vision but perhaps a little less accessible for many enterprises as it's more purely developer focused. The win here is that you have a single system with all your data, all the time, and can build on it however you like. Piecing complex new services together across multiple microservices is deeply painful - if you can give me a single smart platform for all my data, and make it work operationally, that feels like a big win.

Obviously a lot of this you can piece together today, in fact Snowflake itself does a lot of it. But the other part of the article makes me think they understand the even harder part of the problem in modern enterprises, which is that nobody has a clear view of the model they're operating under, and how it interacts with parts of the business. It takes insane foresight and discipline to keep these things coherent, and the moment you are trying to integrate new acquisitions with different models you're in a world of pain. If you can create a layer to make all of this explicit - the models, the responsibilities, the interactions, and the incompatibilities that may already exist, then mediate the chaos with some sort of AI handholding layer (because domain experts and disciplined engineers aren't always going to be around to resolve ambiguities), then you can solve both a huge technical problem but a much more complicated ecological one.

Anyway, whatever they're working on, I think this is the exact area you should focus on if you want to transform modern enterprise data stacks. Throwing AI at existing heterogenous systems and complex tech stacks might work, but building from scratch on a system that enforces cohesion while maintaining agility feels like it's going to win out in the end. Excited to see what they come up with!

This resonates a lot if you’ve ever worked in system integration.

In practice, most of the complexity comes exactly from what’s described here: every system has a rich internal model, but the moment data crosses a boundary, everything degrades into strings, schemas, and implicit contracts.

You end up rebuilding semantics over and over again (validation, mapping, enrichment), and a lot of failures only show up at runtime.

I’m skeptical about “one model to rule them all”, but I strongly agree that losing semantics at system boundaries is the core problem.

Ok this was a nice read. Very expressive and I agreed with the majority of the points. I'm not going to lie, I expected "and this is why we built <insert generic gpt wrapper>", but it never came. Which leads me to my question, and forgive me for my impatience, but _what_ are you selling? Is it a platform? Ide? Books? So many words and I ended with more questions than I started. On any who, good read indeed.

Which is why Clojure advocates for simple data structures. They compose easier than code itself.

So this is basically Pick (https://en.wikipedia.org/wiki/Pick_operating_system) for the modern world. Which is a good thing, its about time we resurrected this idea. I wish them the best.

Em dash , corny sub headings, numbered lists for no reason. I think some of this may be human written or edited, but it isn't passing my smell test. Sorry if this is mostly or all human written, but you have a very AI style.

Maybe this unfairly off topic, but in reading the intro, my thought was not that things become brittle and hard to change because of the inelegance of the abstractions, but because of the banal dynamics of work. Mostly, people act quickly towards short term goals, without full understanding. They accept technical debt, they pass things between people, and the numbers to avoid making things kinda gross just never work out.

If code > infra (wrt 'elegance' or whatever we're talking about), then just use code. I.e. build a monolith (or monoliths) as far as is practical.