1. Prototype 2. Initial production implementation 3. Hardening

My experience with LLMs is that they solve “writer’s block” problems in the prototyping phase at the expense of making phases 2+3 slower because the system is less in your head. They also have a mixed effect on ongoing maintenance: small tasks are easier but you lose some of the feel of the system.

Also, normalization solves a problem that’s present in OLTP applications: OLAP/Big Data applications generally have problems that are solved by denormalization.

It's only zero if you don't need to interact with sites that break when you're running an adblocker. I run an ad-blocker nearly continuously, but there are all sorts of sites where I have to disable it in order to use the actual functionality of the site (and these are frequently sites I _have_ to interact with).

The way I've thought about it, though, is that it's possible to design a program well either by encoding your important invariants in your types or in your functions (especially simple functions). In dynamically typed languages like Clojure, my experience is that there's a set of design practices that have a lot of the same effects as "Parse, Don't Validate" without statically enforced types. And, ultimately, it's a question of mindset which style you prefer.

1) nix means I have to install a lot fewer packages globally, which prevents accidentally using the wrong version of a package in a project.

2) I like having a version controlled record of what my systems look like (and I actually like the nix language)