AI

I was – and I still am – a cynic when it comes to how AI will affect software development (whole “it’s an amplifier” argument + unchanged incentives). Still, after finding a flow which fits my brain, I cannot imagine working without it. Doing TDD when “devopsing” is hard, so the default observed in the wild was “get it right and pray we do not need to touch it” most of the time. Which often meant that Infrastructure-As-Code made things simpler, but reproducibility was not something you really wanted to depend on. ...

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

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