The data centaur vision

If you're going to add automation to your team, think of a centaur. You need to direct people’s brains, judgment, and knowledge of context and history to lead to outcomes. Give them more horsepower so they can go faster, be stronger, and lift more for your organization.

If you give people command of more data, the ability to process more of this data, to clean and contextualize it, and to turn it into solutions and help find those hidden patterns, you develop a team with superpowers.

But, if you look at them as cogs or units you can automate and eliminate, you end up with people who are interchangeable by design. It forces you to invest only in your systems with disposable people. That’s a reverse centaur,ⁱⁱⁱ where the machine is the head, and human effort must carry all that horse weight around.

The technologist and writer Cory Doctorow has an excellent example of a freelancer who is hired to use AI tools to ”write” 64 pages of content and fact-check it himself. It sounds like a great cost-saver, but it turns into a bad outcome for the publisher when AI hallucinations crop up throughout the guide. The system is architected to produce a bad outcome, and the human is there to take the blame for it.

You've just created the person in charge of getting fired for a generative AI hallucination or a mistake. You haven't really prevented the mistake. You've created blame, but it doesn’t help achieve your goals.

Empowering individual developers

Take a software development task, for example, creating a feature that allows users to custom-theme your website for their company colors and logos.

The reverse centaur developer thinks, "I just have to add this generated code. My job is to check that there aren't any security holes at the end. I'm only responsible as the person who gets blamed if there are big bugs or problems." That's not a fulfilling job.

The centaur developer thinks, "I want to generate a set of requirements that look reasonable and complete before I approve them. Then I can break those out into individual development tasks with tests." They pump requirements through agentic workflows, using them for tasks like a first draft code review. The tools help them move faster and concentrate on tough problems.

The difference is participation. Developers understand where the edges are, and where the priorities lie. They become committed. Without that ownership, they say “yay” or “nay” to what the AI did and send it out the door. You end up falling short of requirements that no one understands and safeguards that no one cares enough about.