Cover
Sample Chapter

The Centaur Test

Being a centaur

Peter Dalmaris, PhD

From AI Coding for Makers and Solopreneurs

Go back to the book

This appendix started as me trying to sort out my own relationship with these tools, not as a lesson I set out to teach.

I am wired to be productive. I like learning about things I am interested in, and making things, usually in hardware, but a lot more in software. I also tend to overcommit, and my interests lead me to try and take on far more than I have time to either learn or make. I often find myself working on two or three major projects at the same time. When AI coding assistants arrived, I perceived them like an obvious lever for me to use as a way to expand my capacity to build, to teach, and to chase the next thing that caught my attention.

So, I reached for them the way I have reached for every good tool before, and these tools delivered a sudden increase in my productivity, both in terms of output (more "stuff" out the door), and in my learning (more "stuff" in my brain).

So when I came across Cory Doctorow's idea of the reverse centaur, the human who ends up serving the machine rather than directing it, I took pause and started thinking about, perhaps, having put myself in a trajectory of becoming a reverse centaur. Doctorow's reverse centaur idea and critique points straight at the thing that motivates me. If the danger is letting the tool set your pace, then the person most eager to go faster is the most exposed, and that person is me. Given that I don't have a boss, the fact of the matter is that nobody was forcing AI on me.

That was the uncomfortable part.

Working it through, I had to admit that my failure mode has never been laziness. It's the exact opposite. For me, the pull is to keep expanding output until I am managing a factory of my own making instead of doing the work that made the output worth anything. The thing is that AI doesn't create that pull. It removes the friction that used to hold it in check.

This thinking reframed the question for me, and it is the question this appendix is about. The question is not how much AI should I use. The question is am I still the one in charge?. I think this is the question you should also ask the moment your assistant starts saving you real time.

Control, Skill and the Centaur

In the final year of my electrical engineering degree, I followed the Kasparov versus Deep Blue matches live, game by game, over my dial-up Internet connection. That's where my fascination with thinking machines really began, with Deep Blue, if I set aside the Enterprise-D's onboard computer, which could speak and reason like a member of the crew. One was the science fiction I grew up on. The other was a machine beating the best chess player alive while I watched it happen.

After losing to Deep Blue in 1997, Garry Kasparov set up what he called advanced chess: a human paired with a chess playing engine, with the human being responsible for the decision-making, and the machine doing the calculating. A few years later, in a 2005 online "freestyle" tournament, two American amateurs named Steven Cramton and Zackary Stephen, playing under the team name ZackS, beat a field that included grandmasters. The amateurs were not strong players. Stephen was rated well below expert level. What they had was three ordinary home computers running off-the-shelf chess software of the day, Fritz, Shredder, and Junior, and a disciplined method for cross-checking what those programs suggested before committing to a move. The teams they beat combined titled players with the same class of engines, and in some cases with far more powerful hardware, including Hydra, a chess supercomputer built on custom, purpose-designed processing boards. The lesson was not that the machine won. It was that a good human-plus-machine process beat raw machine power. That is a centaur: a human directing a tireless tool.

Doctorow's inversion is the reverse centaur, where the human's task is to serve the machine, paced by it and used up by it, like an Amazon warehouse picker whose speed is set by an algorithm. Both reverse centaur and the regular centaur paradigms use the same technology, but the relation between human and machine is flipped.

Here is the part that matters for a maker. The line between centaur and reverse centaur is not how much AI you use, or which tasks you hand over. It is who sets the terms. Two questions decide it:

  • Control. Do you set where, when, and how the tool is used, and can you walk away from it?
  • Skill. Each time you delegate a task to the tool, are you losing or degrading a skill that you may, or will, need to use next year?

What I attempt to discuss below stems from contemplating my own answers to those two questions. Of course, you may have your own questions, and those can depend on a variety of factors. You may even break my two questions further into sub-questions. For example, the "skill" question might be broken into these two:

  • Skill → Core. Say you are an author, like me. Arguably, being able to write is a core skill, among many others. In a year from now, I still want to be able to write at the same level of quality (or better) as now. So, the skill sub-question that comes to mind is "how much of my writing should I delegate to an AI agent?". If I hand every draft to the assistant, my writing skill will atrophy. At that point, I will be dependent on the machine, and, perhaps even worse, I will be dishonest to my readers. The rule for a core skill is to keep doing enough of it by hand that you do not lose it.
  • Skill → New. Say you are a Maker who comes across LoRa, a low-power long-range wireless protocol, because it solves a range problem in a current sensor network project. This is a skill you don't yet have. The sub-question here is not "how much should I delegate?" but "will I ever need this again?" To answer it, I run a quick three-step check:
    1. Is this a one-off, needed for this project alone and unlikely to return? If so, let the agent produce the firmware, close out the project, and move on. You will get the result quickly without spending a week learning a protocol you may never touch again.
    2. Do I expect to reach for this again in a year? If so, the time I spend learning it is an investment worth making. Letting the agent do it instead means buying a finished project at the cost of a skill I will keep renting from the machine.
    3. Is the question too close to call right now? I defer. If I need to use the skill more than a couple of times, I invest the time to learn it properly.

    The rule for a new skill is to make the rough guess: when there is a real chance it becomes part of your toolkit, learn enough of it yourself that the agent is teaching you rather than replacing you.

Why makers are well-placed, and still at risk

If you build and sell things on your own, or perhaps you are retired, or simply have the freedom to make your own decisions around learning and making, then you already hold the wheel. Nobody sets your quota. Nobody can force a tool on you or force you to produce more. By Doctorow's own test, that independence is what makes you a centaur rather than a reverse centaur.

That is the good news; however, there is a trap in there. Because no boss can push you into the reverse-centaur position, the only person who can is you. The way by which this can happen is particularly sneaky. In 1983, well before any of the recent rapid AI developments, Lisanne Bainbridge described the ironies of automation. The main premise (or irony, if you will) is that when you automate the routine parts of a job, you quietly deskill the operator on the hard parts you couldn't automate, so your own judgement is weakest at exactly the moments it matters most. Modern AI has a sharp version of this. It is excellent at producing locally correct, tidy-looking work but poor at system-level judgement (although this is also a significant area of improvement). Code that looks right and passes its tests gives a false signal of understanding. Ship enough of it, and you end up with a codebase, or a course, or a book, that nobody, including you, actually understands. In the context of programming, this is known as "dark code."

Dark code is particularly easy to accumulate in embedded systems work. Imagine generating firmware for a sensor node. The agent produces clean-looking C, the device transmits correct readings, and the first three tests pass. But the interrupt handler silently blocks when two sensors fire within a microsecond of each other, and the power-management logic assumes a fixed supply voltage that the real circuit never provides. The result is code works under test and lab conditions, which fails occasionally in the field. And when it fails, nobody, including the person who shipped it, knows why. That is dark code: locally correct, passing tests, and opaque to its nominal author.

As an author, I can also recognise a similar phenomenon in any kind of literature, whether fiction or non-fiction. Let's call that "dark text."

But there is a second, quieter risk that tends to hit hardest the people who are driven and curious, who enjoy jumping from one topic to another in quick succession and enjoy making things. With their newfound performance accelerator, AI tools being so good at helping them explore new topics and make things at a supercharged pace, the risk of over-reliance can creep up unnoticed. The more capable the tool, the more tempting it is to keep scaling output past the point where you are still making things but don't really know how they work. And before you know it, you have lost both control and your core skills. The irony here is that as a Maker, nobody asked you to produce more this year because you got a better assistant. You lost control and skills because you wanted more of the things you enjoy doing, but the AI accelerated your pace to a level that made your actual learning and making superficial.

A moment to check yourself

Before reading the rules below, pick something you built or shipped in the last month that involved an AI assistant. Ask yourself two questions: did you set the terms of that collaboration, or did the tool? And if you delegated a skill, do you still own it well enough to use it without the assistant next month? Your honest answers will tell you whether the rules apply as reminders or as corrections.

Rules you can adapt

I will finish this appendix with my eight rules for using AI. I wrote these rules for myself, and generalised them for you. Treat them as a starting template to create your own AI rules. I invite you to rewrite them in the language of your own craft. I have tagged each one with the test it serves (control or skill).

  1. Keep the specification yours. Write the spec, the outline, the shape of the thing you want to create, the what and the why. Let AI fill in the how. If you can't write a clear spec, you don't yet understand what you're building, and you can't judge what comes back. (control)
  2. Ship nothing you cannot explain. If you can't say why a block of code or a paragraph is right, it doesn't go out under your name. (skill)
  3. Keep your core craft warm. Whatever skill your audience or your future self depends on, keep doing some of it by hand. Write a lesson or a chapter cold. Debug unaided, like in the good old days. Reason through a circuit with no assistant. Any skill you delegate to the machine has to stay yours. (skill)
  4. Treat ease as a warning. When output feels good enough to wave through, look hardest. Your confidence in the tool is the risk signal, not the safety one. Always look for things to push back to the machine. (skill)
  5. Verify what your name vouches for. Every technical claim and every line a reader will run gets a human check. The byline is the accountability, and it is yours. (skill)
  6. Do not let throughput become the goal. Measure your work by whether it is correct and distinctive, not by how much you produced or how fast. The day you want to make more of something only because the tool now lets you, stop and run this list. (control)
  7. Keep the exit. Preserve your ability to abandon, downgrade, or go analogue on any tool. A dependency you cannot leave is not a tool, it is an employer. (control)
  8. Disclose plainly, own the core. Say what the AI did and what stayed human. Where it fits your work, make that transparency part of what you teach. (control)

Build your own check

Written rules only work if you run them against real work. Pick something you are about to ship, a chapter, a module, a delegation you are about to make, and walk it through your list honestly. Most of the rules you can check from the outside. Rule 6 you cannot. Only you know whether the real reason you reached for the tool on a given piece was quality or just speed. That flag fires in your head before it ever shows up in the output, which is precisely why it is the one worth watching.

None of this is an argument for using AI less. It is an argument for staying the one who decides. Do that, keep the judgement your audience is paying for in active use, and the tool stays what it should be: leverage you command, not a pace you serve.

About disclosure

If you are an educator, or a writer, like me, you will have to decide what to tell your readers and students about your use of AI. I am in that position, so I had to think carefully how to go about this. Not so much because I want to hide something, but because my use patterns of AI is still changing. So, I have designed a way to think about disclosure that is, hopefully, useful to you.

Some work is judged by who made it and some by whether it works.

A novel's value is partly that a human wrote it. In such scenario, if you disclose that an AI wrote your novel, the cost to you, as the writer, will be steep. Let's look at an example from academia that shows what happens at the far end of that scale. According to relevant research (see the list of my references below if you want to drill into this), academic work is judged almost entirely by who made it. Researchers have measured what some call AI shaming, where if an author labels their paper as AI-assisted, then readers will rate it lower on quality, authenticity, and trustworthiness, even when the text is unchanged. In one study the penalty was around a third of a point on a five-point scale, it fell hardest on work described as AI-drafted rather than AI-edited, and the most confident writers were the harshest judges. As a rational person might expect, authors have responded rationally: an analysis of tens of thousands of papers found that only a fraction of one percent disclosed using AI writing tools, despite the large majority of journals requiring it. The lesson is not that academics are dishonest. It is that when a field treats provenance as the value, honest disclosure carries a real cost, and people stop disclosing. Worth knowing where your own work sits on that scale before you decide what to say about it.

Let's look at another example: professional programming sits near the opposite end of that scale. A client or user judges shipped code almost entirely by whether it works, not by who or what wrote it, so you would expect disclosure to cost nothing here. Of course, even in programming, there is a spectrum on which disclosure results at a cost for the programmer. A 2026 study of AI disclosure practices in freelance work found a real gap between what developers assume and what clients actually want. Programmers tend to disclose their AI practices only when directly asked, on the theory that competent AI use is invisible in code that works, while clients report far less confidence in spotting AI involvement themselves and consistently say they would rather be told upfront. The quality judgement on the work itself barely moves. A feature that passes review is not devalued because an AI helped write it. But the trust judgement can shift hard if a client finds out on their own rather than hearing it from you. The clean position most transparent programmers settle on is simple: disclose what the tool did, keep the judgement visibly yours, and where it fits, make the transparency itself part of the lesson.

I value honesty, especially in a world that is as confusing as ours. But I'm surely not one to tell anyone what they should or not disclose about their use of AI. I hope that the two examples I gave above can help you think about disclosure, and reach your own conclusion.

Now that's out of the way, I'll explain how I use AI.

How I use AI

You have just completed my book on AI for Makers, so it is obvious that I use AI extensively in my work. Here, I'll make my disclosure on how I use AI in my work, rather than leave you guessing.

My use of AI has changed a lot over the last three or four years, as the LLMs and the surrounding tools went from a curiosity to a core tool in my toolkit. Over the last six months I have settled into a stable pattern, and I don't expect it to shift dramatically from here. What follows is how I work today.

I use AI to research the topics I teach and the material that ends up in my courses and books. I check what it gives me, and I edit it, before it goes anywhere near you. Furthermore, I can't claim I trace every fact back to an original source, often I don't know what that source would be, but I don't publish anything I haven't satisfied myself is correct and can't explain in my own words.

For a course or a book, I run long brainstorming sessions with AI to help me work out the structure and architecture. The final draft is always mine. For specific chapters and lectures with heavy technical content, I use AI to help produce a draft, and I run those drafts through quality-assurance agents that check for correctness and hallucination. Then, I review the result myself.

I also use AI to create educational resources, illustrations, diagrams, and demos, that support the teaching. Publications like short guides and blog posts are almost always drafted by a frontier model, under my direct control and final editing, because I find that such content is an excellent match for the agent's capabilities (because of the very narrow scope), and doesn't risk my core writing skills (those are in long-form writing).

I use AI heavily for coding, and for researching components and circuit modules when I'm working on a PCB design. I also use it across the Tech Explorations infrastructure, in tasks like workflow automation, website development, maintenance, and optimisation.

When I answer a student question, AI may help me think it through. Every answer you receive is typed by my own fingers.

The judgement stays mine. I decide what to teach, in what order, and whether any content I publish is correct. That's the part you're paying for, and I don't delegate it. And if I do publish something that has errors, the blame is all mine.

Sources and further reading

General

AI shaming

The term itself

  • Giray, L. (2024). "AI Shaming: The Silent Stigma among Academic Writers and Researchers." Annals of Biomedical Engineering. DOI 10.1007/s10439-024-03582-1. — Where the phrase comes from. A commentary, not a study: it characterises the phenomenon and profiles who does the shaming (traditionalists, technophobes, elitists). (Abstract verified; full text not read.) See pubmed.ncbi.nlm.nih.gov/38977530/

The core empirical result

  • Li, Z., Liang, C., Peng, J., & Yin, M. (2024). "How Does the Disclosure of AI Assistance Affect the Perceptions of Writing?" arXiv:2410.04545. — Great read. Disclosure of AI content generation lowers perceived quality for essays and stories; AI editing only dents creative stories. Disclosure also widens rater variance, and knocks AI-generated essays from 63.6% to 24.5% of the top-ranked 10%. (Read in full.) See arxiv.org/pdf/2410.04545

Supporting empirical

  • "Understanding Reader Perception Shifts upon Disclosure of AI Authorship." arXiv:2510.24011. — 261 participants; disclosure erodes trustworthiness, caring, competence and likability, worst in social/emotional contexts. (Abstract/conclusion only.) See arxiv.org/pdf/2510.24011
  • Draxler, F. et al. (2024). "The AI Ghostwriter Effect: When Users Do Not Perceive Ownership of AI-Generated Text but Self-Declare as Authors." ACM ToCHI 31(2). — Why writers stay quiet even when they don't feel ownership. (Read in full.) See dl.acm.org/doi/epdf/10.1145/3637875
  • Jago, A. S., & Carroll, G. R. (2023). "Who Made This? Algorithms and Authorship Credit." Personality and Social Psychology Bulletin. — The credit-attribution mechanism underneath the penalty. (Citation only.) See journals.sagepub.com/doi/abs/10.1177/01461672221149815
  • Jakesch, M. et al. (2019). "AI-Mediated Communication: How the Perception that Profile Text was Written by AI Affects Trustworthiness." CHI 2019. — The early result, Airbnb profiles. Shows this predates LLMs. (Read in full.) See socialmedialab.sites.stanford.edu/sites/g/files/sbiybj22976/files/media/file/jakesch-chi19-ai-mediated.pdf

Counter-evidence

  • "Quality Perceptions and Intended Engagement in Response to AI-Generated and AI-Assisted News." arXiv:2409.03500. — Preregistered, Swiss sample. Found no significant differences in perceived expertise, readability or credibility, and disclosure actually raised short-term willingness to keep reading. (Read in full.) See arxiv.org/pdf/2409.03500
  • "Writing with AI Boosts Trust-Building Efficiency." PMC12765382. — AI assistance had minimal impact on trust, disclosed or not, in one-shot transactional messages. (Read in full.) See pmc.ncbi.nlm.nih.gov/articles/PMC12765382/

On why writers hide it

  • "It was 80% me, 20% AI: Seeking Authenticity in Co-Writing with Large Language Models." arXiv:2411.13032. — (Read in full.) See arxiv.org/pdf/2411.13032
  • "What Influences Readers' and Writers' Perceived Necessity of AI Disclosure?" arXiv:2604.27129. — Recent, and its related-work section is a bibliography of this area, useful as a shortcut into the literature. (Read in full.) See arxiv.org/pdf/2604.27129
Go back to the book