Gniewomir Świechowski

There is a huge problem I have not seen discussed in the context of AI. Documentation—just like code—can rot when subjected to unrestricted AI use, and this is not something that can be easily, if at all, fixed. Missing, misleading or outdated documentation forces rushed explorations focused on how, not why—which tightens competition for resources between research, design, and implementation. Good documentation warns about dead ends and explains constraints, allowing teams to reach better decisions faster. Yet, having a good knowledge base was hard before AI, and I’m convinced that it will get even harder with it. ...

I’m in a bind. On the one hand, I’m a big proponent of passive, boring investing—on the other, this approach taken to the logical conclusion of sitting on my hands steers me toward extreme over-exposure to AI. The main issue is that if you try to have low-maintenance exposure to the global stock market, ~60%+ of your ETF(s) exposure will be toward the USA. Then, ~30%+ of it will be the Magnificent Seven (Nvidia, Alphabet, Apple, Microsoft, Amazon, Meta, and Tesla). Which is a pretty sizable bet, all of which can be considered an AI play. ...

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. ...