Interesting essay even though I don't like the whole part about singularity. I found this section was a distraction to the more interesting arguments. Indeed, I liked a lot the concept of decoherence and its ties to complexity.

The essay also makes a good job of showing how it's something we have to deal with and likely the worst kind of technical debt. I also shows how it impact productivity obviously. It's all valuable and things I encounter on a regular basis.

And of course, since everything has to talk about LLM these days, it build an interesting case on how and why using those tools especially with harnesses to pump out more code is actually increasing decoherence. Exactly what we don't want.

Unexpected metaphor but it kind of works. Indeed, architecture work is expensive, that doesn't make it unnecessary.

A bit of an advertisement for the author's book but the advice makes sense. The strangler fig pattern indeed works at smaller scales. Grow the new API first, test it, then port.

Another love letter to SQLite. It's meant to be funny but comes with plenty of good arguments and ideas as well.

There is truth here that our profession reinvents the wheel way to often. Some problem are solved, they don't need reinventing. Be careful on your dependencies though, this is where lies the tradeoff.

Since I still hear about "microservices" more often than I'd like to. Here is another piece which points the trade-offs and that really there's no one size fits all.

Interesting article applying data oriented design to parsing tasks. This is really a good approach for performance.

This is an ongoing series, but there are good insights about software architecture work in the first few articles. Shows quite well the important tradeoffs and the usual traps.

Friendly reminder that the answer is "no". You don't want to just rewrite everything, it's not just a syntactical translation, it's a long project and at best you tackle critical components.

This is a good reference on how to write design documents. It's not as easy as it sounds sometimes, and this guide contains good tips.

It's definitely easier not having to scale at all. Which is what you get when you design for local first / client side.

Queues are not magic. If they're unbounded you're in for a world of pain as load increases.

A good primer on the main architecture traits of transformer models.

Nice suggestions on how to structure larger Rust code bases. The proposed error handling is particularly neat and tidy. This is doable in other languages but tends to be more verbose.

Which means simpler models: and this is fine for most use! It's also easier to have more ethical options with the smaller and more specialised models. Let's not forget they exist even though the big industrial complex would like people to forget.

Architecture work is not only technical, you need processes to put the architecture of a project in place. That said, you can make things easier with standards to smooth the path toward the preferred types of architectures in your organisation.

Indeed, architecture work is not only technical (what is really?). You definitely need to account for the organisation and the process to actually put the architecture in place. It's not just about having pretty pictures.

A good primer about design documents. What's nice about this one is the focus on the process rather than the form of the document. Indeed what matters is the shared understanding and making sure the right decision is made.

Shows the problem with layer cakes in applications or how you might want to go toward onion architectures.

Are you sure your understand how your reverse proxy works and the impacts it can have in production?