Nearly every software company keeps its most valuable asset on a platform somebody else owns: GitHub, GitLab, Bitbucket, or one of a handful of smaller hosts. Your git history can leave any of them in an afternoon — almost nothing else you built there can, so who owns the platform matters more than its feature list.
TypeSafe AI launched Jev on 15 September 2026 with a headline of "193.6x faster, 444.6x cheaper" and a promise that it "can't hallucinate". Read the primary sources rather than the reposts and a narrower, more interesting product appears: a frontier-trained classifier for software, not a better large language model, with every number so far reported by the vendor.
The plugin built, packaged and published on the first try. I could not have explained the packaging step to anyone, and I shipped it anyway. After several months of building games, static sites, libraries and plugins with an artificial intelligence (AI) assistant doing most of the typing, that sentence is the whole story: producing code stopped being the hard part, and something else moved into its place.
Every strategy for surviving the flood of machine-written pull requests optimizes the same thing: catching bugs. The research on code review says catching bugs was never the job it was best at.
A tweet doing the rounds says LinkedIn merged four job titles into one. The quote is real, the role is real, and the arithmetic everyone read into it is not — and the difference is the whole career signal.
Every agent is, at heart, a loop: a model calling tools until the job is done. The interesting engineering question of 2026 is what happens when you wire many of those loops together into a graph — and when you shouldn't.
There are more kinds of software test than anyone can keep straight — unit, integration, contract, snapshot, mutation, smoke, load, chaos. This post walks through each one, what it actually buys you, and whether it earns its place in a real codebase.
A practical tour of the diagram types that earn their place in engineering documentation — when to reach for each one, and how to keep them maintainable.
Steve Jobs famously spoke about the concept of "A players" in the context of building effective teams. His philosophy was centered on the idea that the best employees, the "A players," are not just marginally better than average employees, but exponentially better. He believed that A players are more creative, productive, and capable of working at a pace and quality level that far exceeds others.
Recently, we had an in-depth discussion on structuring React applications using a layered architectural approach. This method aligns with fundamental software architecture principles such as the Single Responsibility Principle (SRP) and the Single Source of Truth (SSoT). It shares similarities with Clean Architecture and Layered Architecture and, interestingly, shows parallels with the Model-View-Controller (MVC) pattern in some respects. We are also applying Dependency Inversion principle (DIP), depending on abstractions rather than concrete implementations of lower-level modules.