As many in the BHIS community know, I’ve been working for months on an AI Fundamentals class for Antisyphon On-Demand. If you’ve been waiting for it, I’m sorry it’s taking so long. Believe me, I’m frustrated too.
No surprise, I’ve been using AI to help develop the course materials, with mixed results. It turns out I’m an AI micromanager. Let me explain.
The lab manual I built for the local LLM workshop at the Antisyphon AI Summit was, hands down, the most thorough and detailed lab manual I’ve ever created. I was proud of it, and students said they appreciated the detail, too. But building that manual led me down a rabbit hole of increasingly elaborate authoring standards, review procedures, and checks intended to keep the AI on track. The new eight-hour course inherited all of that machinery. It also inherited a shortage of clarity about what actually counted as finished.
Several months and four versions later, I had to admit that I was part of the problem. I was micromanaging the work. I had to approve everything, and when the results didn’t satisfy me, I kept correcting, refining, and eventually starting over. Somewhere along the way, the lab manual had also become more of a textbook, with all the additional work that entailed.
Once I realized that my behaviors were contributing to my own frustration and the associated delays, I decided to scrap things yet again and start over with version five. This time I went even more scorched earth and nuked the entire Claude project and all the chat sessions and cruft it contained.
Apparently, I needed to make the restart loop literal.
I do this with games, too. I’m a chronic restarter. I keep going back to the beginning instead of getting further into the story, the challenges, and the lore.
Apparently, this is something I need to work on beyond how I use AI.
The destination wasn’t the problem
Throughout all of this, the goal of the course has remained pretty consistent. I want to help people go from knowing nothing about AI to being able to prompt effectively and build contextual reference files they can reuse, giving them practical skills they can apply to their own work.
The format and content have changed over the months, sometimes because conversations illuminated different needs and priorities. Those changes gave me legitimate reasons to revisit parts of the course, but they shouldn’t have caused a full restart. Au contraire! I did that all on my own.
The trap I was in looks like this: I would get three or four modules into a version and become increasingly unhappy with how it was coming together. I’d correct things, ask for revisions, and revisit decisions until I was frustrated enough to scrap it and start again, convinced that this time I could get it right. Unfortunately, the new version would inherit much of the same process that had bogged down the previous one. I was giving myself another beginning without doing enough to change what happened after it.
One problem, I realized, was that I was trying to make the lab manual do too much. The detailed approach that students appreciated in the local LLM workshop had grown into an expectation that the new manual would carry much of the instruction itself. I was building something closer to a textbook while also trying to develop the class, then getting frustrated by how difficult it was to produce something I was happy with.
For version five, I’ve gone back to a more traditional division of work, with the lab manual guiding students through the labs and me teaching the concepts using slides and demonstrations, including narration over demo videos. That gives each part a clearer purpose and gives me a more manageable assignment to delegate.
Before starting again, though, I needed to answer a question I should have asked much earlier: what, specifically, would be different about this attempt? A fresh project and a revised outline weren’t going to be enough if I carried the same habits and expectations into the next version. I had to change how I worked.
I tried letting AI do the work
The irony is that I didn’t begin this project by insisting on supervising every little thing. For the first version, I gave Claude broad descriptions of what I wanted and let it do a substantial amount of the drafting. The results were horrific, which did very little to encourage me to step back and let it get on with things.
For version two, I spent more time planning and outlining the structure. That was a reasonable response to a disappointing first attempt, but having a more detailed outline didn’t mean that I had figured out how to delegate the work effectively. I could describe the topics I wanted covered without necessarily making clear what a successful lesson should look like, how much detail belonged in it, or which decisions Claude could make without consulting me.
There is a difference between knowing what I want when I see it and explaining it well enough for someone else to produce it. Working with AI has given me plenty of opportunities to encounter that difference, usually while staring at something that technically addresses my request but still isn’t what I meant.
And that leaves me with a question I don’t always enjoy answering: did the AI fail to follow my instructions, or did I fail to explain what I needed? Sometimes the answer is both. Sometimes I discover what matters to me only after seeing a draft that doesn’t have it.
That discovery can be useful, provided I turn it into a clearer assignment. It becomes less useful when every disappointing result persuades me that I need to supervise more closely, specify more details, and reserve more decisions for myself. At that point, I’m spending a great deal of time directing the work without necessarily getting better at handing it over.
The lesson I’m taking into version five is that loosening the reins requires some preparation on my part. I need to give Claude a task with a clear purpose, enough context to make useful decisions, and a finish line it can actually reach. Then I need to let it complete that task before deciding that I should have been holding the reins all along.
Every mistake became another rule
While developing the local LLM workshop, I accumulated an extensive set of authoring standards. There were rules about voice, headings, glossary entries, checkpoints, formatting, and how to introduce concepts before asking students to use them. Much of that guidance served a useful purpose, and the resulting manual was better for having it.
The trouble was that the standards kept growing, along with the machinery for enforcing them. By the time I stepped back to examine the process, there was an authoring standard, voice notes, a prose review skill, a linting script, project memory, and additional review requirements. When a review produced inconsistent results, the response was to develop a more detailed rubric intended to make the next review more reliable.
I was building quite an elaborate system for checking work that I couldn’t ever finish.
Some requirements also worked against each other. Exercises needed labels such as “Typical result” and “If it looks different,” but those deliberately brief labels could run afoul of prose rules against sentence fragments. Requirements about introducing a concept at its first appearance depended on the order of the whole course, even while individual lessons were being drafted and reviewed. Resolving those problems required exceptions, decisions about which instruction took precedence, or moving a check to a different stage.
Meanwhile, fresh reviewer agents could raise new concerns about material that had already been through review. Fixing those concerns produced revised prose, which gave the next review something else to examine. Matters of taste could become obstacles to completion, and every finding that required my approval added another decision to my workload.
In a later reconstruction of the process, Claude identified conflicting requirements, overlapping checks, and the absence of a clear stopping condition. That matched my experience of continually addressing findings without reaching a point where a lesson was finished.
The uncomfortable part is that I helped create this system. Adding another rule felt like a practical response to a specific problem, and I wasn’t regularly asking whether an older rule should be retired or whether the extra check justified the attention it would consume.
For version five, the lab manual has a substantially shorter standard that explicitly replaces the earlier requirements for this course. It also tells Claude to use judgment where the new standard is silent, rather than reaching back into the old one for more rules. Specified structural checks now happen as pages are generated, leaving me to spend more of my attention testing whether the labs actually work.
I still need standards. But when I add one, I also need to decide where it applies, how it will be checked, and what happens when the work meets it. Otherwise, I’m giving myself another reason to keep reviewing.
The AI micromanager approves everything
Throughout the earlier versions, I kept Claude on a short leash. Actions required my approval, which meant that delegating a task didn’t necessarily free me to do something else. I still had to be available to examine what it wanted to do and decide whether it could proceed. Combined with the expanding review process, that gave me plenty of opportunities to intervene.
Some of those interventions were necessary. I’m responsible for what I teach, and students deserve materials that are accurate, understandable, and usable. But I also know that I can get hung up on choices simply because they aren’t the choices I would have made. Recognizing that a result is different from what I pictured is easy. Deciding whether that difference actually matters takes more thought.
If I want to approve every choice along the way, I also have to accept that the work will keep waiting for me. There is only so much efficiency to be gained from an assistant that can work quickly but needs me to keep opening the gate.
For version five, I explicitly told Claude that I struggle with delegation and needed help figuring out where to stop involving myself. When it proposed a different division of work, I agreed to try it. Given how well my previous approach had been working, I had nothing to lose.
So now Claude drafts the lab specifications, and the generator builds the pages. My work includes testing the labs in actual chatbots, capturing the screenshots, and recording the instruction. Those are substantial responsibilities without adding approval of every intermediate step. I still retain deliberate approval gates for actions such as commits and publishing, but I’m letting the AI do more of the work between those tasks.
That includes letting Claude choose examples for the labs. I can replace an example if testing shows that it doesn’t serve the lesson, but I’m trying to give it that chance before substituting something merely because I would have picked a different subject.
The practical change is to agree on the assignment and its boundaries, then review a completed unit of work. When I do intervene, I need to be able to explain what needs fixing and why. If my only objection is that I would have done it differently, I have some work of my own to do before reaching for the reins.
Hundreds of hours of practice at what?
You would think that spending hundreds of hours working with a tool would make you better at using it. And it can, provided you’re learning from the experience and changing what you do. But it’s also possible to spend those hours reinforcing habits that aren’t helping. As much as it pains me to say it, I had to consider how much of my time on this project falls into that category.
I certainly had plenty of practice explaining what I didn’t like about a draft, asking for another pass, and supplying more instructions when the result still wasn’t right. What I can’t say is that I was getting better at giving Claude a task it could complete without my constant intervention.
Clarity is a substantial part of the problem. Knowing what I want students to learn doesn’t automatically mean I’ve explained what belongs in a particular lesson, how much supporting material it needs, or what would make it ready for testing. A long set of instructions can leave those questions unanswered, even while specifying exactly how the headings should be capitalized.
Then there’s the distinction between something the AI failed to do and something I hadn’t yet decided. If I discover a requirement while reviewing a draft, I need to recognize that I’m changing the assignment. That may be necessary, but it deserves a closer look when it keeps happening. Otherwise, I keep moving the finish line while wondering why nothing ever crosses it.
This is an uncomfortable lesson to encounter while building a course intended to help other people use AI effectively. It’s also a practical example of why experience alone isn’t enough. I needed to examine where my instructions left room for confusion, where my expectations conflicted, and where I was intervening out of habit, and how to break habits reinforced by hundreds of hours of labor.
This time, I’m actively trying to practice delegation on a scale where I can see the whole process: define a lab, let Claude build it within the agreed boundaries, test the result, and address specific problems. If it needs revision, I want to understand why before asking for another version. And when it meets the requirements, I need to let it be finished.
That last part may take some practice, especially because I’m a chronic perfectionist.
Recognizing the infinite loop
While trying to understand how I’d gotten myself into this mess, I read Terence Kok’s The AI Infinite Loop: Why My 4-Day Project Took 4 Weeks. His account of a project trapped in repeated revisions sounded uncomfortably familiar.
Kok described three contributors: “helpfulness churn,” where asking for improvements keeps producing more edits; fatigue from repeatedly auditing the output; and the loss of earlier constraints as revisions continue. He recommends settling the structure before detailed drafting, limiting each section to two revision attempts before reconsidering the brief, and completing the final polish outside the AI conversation. Those are practices he reports using, rather than guarantees that every project will finish on schedule.
What caught my attention was how easily asking for help could perpetuate the work. If I ask an LLM what could improve, it can offer suggestions for me to evaluate. As a chronic perfectionist, I’m quite capable of turning those suggestions into another round of requirements, even when the existing draft already does its job.
The two-revision limit particularly appeals to me. After two unsuccessful attempts, I would need to stop and examine the assignment and its checks before requesting more prose. Did I explain the problem clearly? Do the requirements agree with each other? Am I asking for a necessary correction, or pursuing a preference I haven’t managed to articulate?
That pause may also help me distinguish a problem with one lab from a reason to reconsider the whole course. I’ve had plenty of practice escalating dissatisfaction into a restart, so I need a way to catch myself before I do it again.
Kok’s recommendation to finish outside the AI conversation gives me something else to consider. I still need to test the labs and review the materials, but I don’t have to turn every editorial decision into another exchange with Claude. I can make a correction myself and move on, provided I don’t use that final pass as an excuse for another comprehensive rewrite.
Version five: give the lab manual one job
The biggest change in version five is also the easiest to explain: the lab manual will be a lab manual. I’ll provide the instruction through slides and demonstrations, so each lab page can concentrate on helping students complete an exercise and understand what they observe. I don’t need to put the entire lecture on the page before letting students try something.
That narrower purpose gives me and Claude a basis for simplifying the authoring process. The new Lab Manual Standard runs to roughly 650 words, compared with about 6,700 in the earlier standard. More importantly, it explicitly replaces the old requirements for the course. Where it leaves something unspecified, Claude can use judgment instead of digging through the previous standard for another restriction.
We also moved structural checks into the process that builds the pages. Claude drafts a short lab specification, and a script validates it before generating the Obsidian page. Missing sections and other specified structural problems stop the build, which reduces the need to discover those same problems through repeated prose reviews. When something needs changing, we edit the specification and rebuild the page.
None of that tells us whether a lab actually works. That part belongs to me, and the new process makes the distinction visible. Claude’s descriptions of expected chatbot results are predictions until I run the exercises. The pages remain marked as untested until I check them, capture the necessary screenshots, and confirm that the instructions make sense in practice.
At this point, eight lab specifications have been turned into pages, and all eight still need testing. I have something concrete to work through, with a defined role for Claude and a defined role for me. That’s progress, even though it’s much too early to declare the problem solved.
The next challenge is to test those labs without turning each one into an invitation to rebuild the course. If an exercise confuses me or produces an unexpected result, I need to investigate that specific problem. If the example works and teaches what it needs to teach, I need to give students the chance to use it.
Still frustrated. Still trying.
I’d love to end this by telling you that the course is finished and that I’ve conquered my need to supervise every little thing. Unfortunately, I’m still frustrated, the labs still need testing, and I haven’t suddenly become comfortable letting go of control. I’ve agreed to try a different way of working, and now I need to give it a chance.
That will probably get uncomfortable the first time I encounter a choice I don’t like. Before I intervene, I need to ask whether it creates a problem for the student or merely offends my sense of how I would have done it. When something does need fixing, I need to keep the correction proportionate instead of letting it grow into another round of course redesign.
If you recognize yourself in any of this, I hope you’ll take a look at your process before you spend another evening rewriting your instructions. Can the AI complete the assignment you’ve given it? Have you decided what counts as acceptable? And will you let the work be finished when it gets there? Those are questions I wish I’d asked myself sooner.
For those of you waiting for the class, thank you for your patience. I still want to put something in your hands that deserves the time you’ll spend with it, and I need to remember that you can’t learn anything from a course I never finish.
For now, I have eight labs to test.
~B~