About centaurs
2026-05-25 
Living in contradictions is fine.
We do this all the time, that's probably how we survive the inherent conflicts between social fitting requirements and our inner desires.
Software developers these days would probably agree they currently are either:
- totally ok with the impacts of LLM[1] on their craft
- rejecting LLM entirely
- somehow adapting, yet trying to keep control
Picture these as bounds with infinite gradients in between, and your own cursor is probably positioned there somewhere.
I am somehow adapting.
As a library maintainer, I need to keep control of the code i'm shipping. For some reason, I have not tried agents, and use LLM as a supercharged and polite version of stackoverflow[2]. In my experience, the code generated by LLM is generally decent, often too verbose, and the necessary refactoring is on me. The whole inherent hallucination aspect of LLM dictates every line of code be reviewed, corrected, rewritten, condensed, optmised, etc.
I guess this makes me some sort of centaur.
The term of centaur was coined at the end of the last century, to describe human + machine chess games, when the human input was still making the combo stronger than their indiviual parts. This is not the case anymore. In a chess game opposing a chess engine against a human + engine, the engine will almost always win; the centaur can only hope to draw.
Chess is not programming of course, yet I find some interesting parallels, in that we are at a stage today where on one hand, human input and responsibility are (still) critical to ship good software, and on the other, LLM as a tool has transformed shovels into excavators. The comparison with chess ends here: in programming, humans are the ones that know what to build, and more simply, just have a will per se. This cannot be solved through brute force, or machine learning, as of today.
Being a centaur comes with a set of contradictions, especially in open-source, where trusted people and communities matter even more than the code they build together. While open-source developers benefit from perks of being superpowered, they are also torn by undesired consequences that affect the core of the mission, which is 'building in community', as dear Patak would say. Among other:
- automated PR, often gigantic in size
- absence of answers from their author after a review
- untested slop code
- no human voice or intent
- ...
Generating code was never the purpose of open-source.
Anybody can use excavators instead of shovels and request code to be pulled, a tool is just a tool, it all depends on the brain and heart it extends. But when the excavators are self-driven inside an open-source project, it just becomes gaping holes. This is why we must find together means to protect people in open-source. This is very new, we are figuring it out, creating new detection tools, to filter out the undesired noise that covers open-source projects. Caring hearts and brains are as we speak discussing, planning, building new fields for centaurs to stay human.
I think we might just pull it off, as a community.