Things begin to move way too fast, at least for me.

There is some amazing fact, which shows that an intuitive understanding can also be valid.

I remember reading the memest book of the time – “eXtreme Programming Explained” (by still sober and sane Kent Beck), and trying (probably just like everyone else at the time) to “distill” some grains of “wisdom” from the torrents of “mostly bullshit”.

The real take away from the whole manuscript (at least for me) was that writing tests is what really change everything, in particular, they are, indeed, allow quick, confident and “cheap” refactoring and thus really “facilitate change” and, yes, actually speed up the development process.

As a direct consequence the discipline which lately would be popularized as Test-Driven Development or TTD naturally emerge.

The key point is that it forces one to focus on public (abstract) interfaces and their specifications, and this, quire independently from Kent Beck, are just direct manifestations of the universal principles (of programming, regardless of the paradigm) formulated and popularized by Barbara Liskov and Michael Jackson all the way back in the 70s.

You make everything abstract (a [function] interface) and rigorously specify it with some simple mathematical notation (using sets and functions to define or “represent” relations), just what math major FP guys did from the start, and stay (program) at this very level (of abstraction). It is that simple.

If there are any merit (non-bullshit) in XP and TTD (as disciplined “lightweight” methodologies) it is in implicitly (subtly) forcing one –via focusing on tests and even starting with tests (the “tests before code” mantra) and making the tests to be the source of validation and justified, “safe” confidence – to stay at the proper level of abstraction.

Now guess what? Fucking LLMs (gemini-cli in particular) have proved (validated) the whole approach.

One could allow a mere syntax-level slop generator to perform actual “refactoring” of your code (with over-writing the content of the files and even calling git commit on them!) if, and only if, one can quickly validate the changes – first by making sure that they do not break the tests, and then, implicitly, that the “stable” interfaces are not broken, and thus, they are (still) adhere to the specifications.

To actually resist to become overwhelmed (which is quite normal, and even expected, when so many of highly technical changes happen at once) is to force (via discipline and practice) the mind to stay and remain at the level of interfaces and specifications (just as they taught you back in the 70s ).

In short, the “main” (less abstract) core principle of XP (and implicitly of TTD) have been proven (by example, and intuitively) to be valid for “pair programming” with an advanced slop generator that possess zero “understanding” in principle, by definition (of its algorithms).

It even appears (falsely) as a direct continuum from that very meme book (Google’s SWE book already supersede it) and that LLMs are “perfect” pair programmers, although nobody seem to really program this way anymore (code-review tools replace these “rituals”).

Advanced static typing (type-level constraints and guarantees – trait-based, with extension methods) helps a lot, while tests alone are obviously not enough to guarantee, leave alone prove anything.

I already wrote several times that Rust (and the most constrained languages in general) are the best for vapecoding, simply because a non-bullshit “vibecoding” is just a vastly complex, non-deterministic, approximate constraint satisfaction problem, at least for me.