A centaur is the pairing of a human and an artificial intelligence to play chess.

[…] Kasparov realized that he could have performed better against Deep Blue if he’d had the same instant access to a massive database of all previous chess moves that Deep Blue had. If this database tool was fair for an AI, why not for a human? To pursue this idea, Kasparov pioneered the concept of man-plus-machine matches, in which AI augments human chess players rather than competes against them.

Now called freestyle chess matches, these are like mixed martial arts fights, where players use whatever combat techniques they want. You can play as your unassisted human self, or you can act as the hand for your supersmart chess computer, merely moving its board pieces, or you can play as a “centaur,” which is the human/AI cyborg that Kasparov advocated.

Some mathematicians now use proof assistants to maintain rigor as they apply intuition to work through complex proofs. Steven Johnson uses DEVONthink’s textual analysis to suggest connections between his writing and excerpts he’s pulled from his readings¹:

But 2005 may be the year when tools for thought become a reality for people who manipulate words for a living, thanks to the release of nearly a dozen new programs all aiming to do for your personal information what Google has done for the Internet. These programs all work in slightly different ways, but they share two remarkable properties: the ability to interpret the meaning of text documents; and the ability to filter through thousands of documents in the time it takes to have a sip of coffee. Put those two elements together and you have a tool that will have as significant an impact on the way writers work as the original word processors did.

As Kenneth Goldsmith says (paraphrasing Marjorie Perloff, in his Uncreative Writing):

[…] today’s writer resembles more a programmer than a tortured genius, brilliantly conceptualizing, constructing, executing, and maintaining a writing machine.

I recently started a book club at work to discuss Vaughn Vernon’s Implementing Domain-Driven Design. Domain-driven design is a software engineering practice where we attempt to encode the semantics of a problem domain using the same language as the experts in the domain, as opposed to just capturing the bare mechanics of how an expert solves a problem. By making the language of the code resemble the language of the problem domain, the hope is that the code itself becomes a tool for teaching the organization how to solve problems. The alternative (more often found in the wild) is a convoluted scaffolding of scripts written by an expert with enough skill to build a jig for automating their work. To varying degrees, the jig is incomprehensible to anyone but the original author (and perhaps an apprentice or two). Stewart Brand captures the spirit of such a system well in The Clock of the Long Now:

Typically, outdated legacy systems make themselves so essential over the years that no one can contemplate the prolonged trauma of replacing them, and they cannot be fixed completely because the problems are too complexly embedded and there is no one left who understands the whole system. Teasing a new function out of a legacy system is not done by command but by conducting a series of cautious experiments that with luck might converge toward the desired outcome.

Domain-driven design feels to me like a way out of this trap, but at the same time I think about the end product in terms of centaurs and the power of experts able to build their own tools. If you’d like to hear some blistering snark, ask any professional software developer how they feel about code developed by “academics”; but the amateur coder nonetheless has the potential to augment some other expertise to delightful ends.