Engineering

It is always better to propose a solution instead of pointing out a problem, but while listening to another rant about GitHub enshittification, I came up empty. Not because there are no alternatives—because all of them are entangled in the same incentive structure. There is no escape from market logic, where you build a great product to lure customers in and then switch efforts to lock them in and extract as much value from them as they can stomach—while the core product becomes an afterthought. ...

When doing AI-assisted development using agents, your prompts will inevitably have a lot of decision gaps. Sometimes the model’s “defaults” used in those places are fine, but leaked system prompts suggest that most of them are explicitly prodded towards the lowest change-surface solutions. It’s a safe choice, but in a mature codebase, this will become increasingly corrosive with each change. In fresh projects, it will lock in place bad design decisions that you or the agent made early on. ...

Separating domain entities from ORM models is often dismissed by developers and managers as ‘over-engineering’. Yet, long ago I lost count of how many times a promised ‘simple CRUD’ app turned out to be neither simple nor CRUD. It was just hard to reason about, because the ORM models had outstayed their welcome as a proper domain substitute. 1. The Write vs. Read Symmetry Fallacy The ORM creates a false impression that writing and reading data to and from persistence are the same responsibility. Yet, we care about correctness when writing and performance when reading. There is no symmetry here. ...