Build With Less AI

Why a TCM Practitioner Approaches AI Automation Differently: The Holistic Workflow

AI Export Lab · July 2026

I spend my mornings taking pulses, looking at tongues, and asking patients about their sleep, diet, and stress. I spend my evenings building an auto parts export website with AI. These two activities look unrelated. They are not. The diagnostic method I was trained in — find the root cause, not the loudest symptom — is the same method that made a 500-page PDF extraction pipeline actually work.

The Question I Get Asked Most

When people find out I am a licensed TCM practitioner who built jjradiator.com with AI, they usually ask one of two things:

  1. "Did you use AI to diagnose patients?" (No. That would be reckless and also illegal.)
  2. "How did you learn to code?" (I did not. Claude writes every line. I describe what I need and check the output.)

The more interesting question — the one almost nobody asks — is whether the TCM training helped with the AI work at all. It did. Just not in the way a tech person would expect.

The Diagnostic Method Transfers

In TCM, you do not treat a headache by only looking at the head. You ask about digestion, sleep quality, stress levels, tongue coating, pulse quality across six positions on each wrist. A headache could be liver yang rising. It could be qi and blood deficiency. It could be external wind-cold invasion. Same symptom, completely different root causes, completely different treatments.

This is not metaphor. This is how I was trained to think about any system — human or otherwise.

When I started building the product data pipeline for jjradiator.com, the obvious "symptom" was: I have a 500-page PDF and I need a CSV. The obvious "treatment" — the one every Google search suggested — was OCR. Feed the PDF to Tesseract. Get text back. Done.

But standard OCR produced garbage. Multi-column layouts became word soup. Tables collapsed. Part numbers got butchered.

A programmer's instinct at this point is to treat the symptom: write a better parser. Add regex rules. Handle each edge case with more code. I watched Claude try this approach for about two hours. The script ballooned from 60 lines to 300. It still broke on every third page.

The TCM-trained instinct is different: stop treating the output. Find the root blockage. Why is the data wrong? Not "how do I clean it?" but "what is wrong with the extraction method itself?"

The root cause was not the parser. It was that OCR sees pixels, not structure. Switching to AI vision — giving the model the whole page image and letting it understand columns, tables, and product blocks as a human would — was the equivalent of treating the organ system instead of palliating the symptom. One change to the approach. The parser stayed at 60 lines. The accuracy went from 35% to 85%.

I wrote about the technical comparison here: Why Standard OCR Fails on 500-page PDF Catalogs. But the meta-lesson is the one that matters: diagnostic thinking transfers. Not because AI is like medicine. Because figuring out why something is broken is the same skill regardless of domain.

Not Knowing How to Code Is a Feature

Most AI automation content is written by programmers. This creates a blind spot: programmers optimize for code quality. They refactor. They add abstraction layers. They worry about maintainability and test coverage. These are good instincts for building software. They are terrible instincts for building a one-off data pipeline that needs to work once and produce a CSV.

I do not have these instincts because I do not know what any of those words mean.

When Claude wrote the Python script for the PDF extraction, I did not ask it to make the code elegant. I did not ask for error handling, logging, or a config file. I asked: does it produce a CSV I can open in Excel? If yes, ship it. If no, tell Claude what I see and let it fix the code.

This is not laziness. It is triage. My constraint is not code quality. My constraint is that I have two hours after work before I need to sleep. Every minute spent on code structure is a minute not spent verifying that the extracted part numbers match the supplier catalog.

The advantage of being a non-programmer in an AI-assisted workflow is that you do not know which corners are "supposed" to be uncuttable. You cut all of them. You find out which ones actually matter by breaking things, not by following conventions. Half the conventions in software engineering exist because they mattered when humans wrote every line. When AI writes every line, a different set of things matter — and nobody knows what that set is yet, because the programmers writing about AI are still too close to their old workflows to see it.

The Bottleneck Is Never Where You Think

In clinic, a patient might come in complaining of fatigue. You ask questions for 15 minutes and discover the fatigue started three months ago, around the same time they switched to a night shift and stopped eating breakfast. The fatigue is not a disease. It is a predictable outcome of a broken circadian rhythm and skipping meals. You do not prescribe herbs for fatigue. You tell them to eat breakfast and get sunlight in the morning.

AI automation has the same pattern.

The most productive thing I did for the PDF pipeline was not writing a better prompt. It was spending 10 minutes to look at every page type in the catalog before writing any code. I found section dividers. Index pages. Pages with different column counts. Pages with handwritten annotations. I learned that the catalog was not one document type — it was four document types shuffled together.

That 10-minute audit changed everything. Instead of one prompt trying to handle all page types (and failing unpredictably), I wrote four prompts, one for each page type, with a simple detection step upfront. The error rate dropped from 15% to under 5%.

The bottleneck was not the AI. It was not the code. It was that I had not looked at my own data before trying to automate it.

This is the TCM diagnostic method in a nutshell: before you treat, you look. Thoroughly. At everything. The thing the patient mentions first is rarely the real problem. The thing you notice on page 47 that looks slightly different from page 46 — that is the real problem.

What This Looks Like in Practice

I am not claiming TCM is a superior framework for AI work. I am claiming that any systematic diagnostic training — medicine, engineering, auto repair, farming — transfers to AI-assisted projects in ways that pure coding skill does not.

Here is the actual workflow I use now, which came directly from how I was trained to approach a new patient:

  1. Observe before intervening. Before writing any prompt or script, I spend time with the data. I open the PDF. I scroll through random pages. I find the edge cases. I do not touch the keyboard. Just look.
  2. Identify patterns, not symptoms. The first thing that breaks is rarely the root cause. The JSON parse error on line 42 was not a JSON problem — it was a prompt problem three steps upstream. Fix the prompt, and 100 parse errors disappear at once.
  3. Treat the system, not the output. When the CSV has wrong data, do not edit the CSV. Find where in the pipeline the data went wrong and fix it there. Otherwise you will edit the same CSV again next week.
  4. Small interventions, observed results. Change one thing. Run it. Check the output. Do not change three things at once — you cannot tell which one worked. This is the same reason TCM practitioners adjust formulas one herb at a time.
  5. Accept that some things cannot be automated. The last 10-15% of data accuracy requires human review. The model cannot verify business logic. I cannot automate away my own domain knowledge. That is not a failure of the tool. It is a boundary.

None of this is specific to TCM. It is specific to having been trained to diagnose before treating, in any domain. The reason it feels unusual in AI content is that most AI content is written by people whose primary training was in writing code — where the instinct is to build first and diagnose by debugging. Reversing that order is the single biggest thing my medical training changed about how I approach automation.

What I Still Get Wrong

I am not holding this up as a flawless method. Here is where the diagnostic approach fails:

The Bigger Point

AI tools are making domain expertise more valuable, not less. When Claude can write a Python script in 30 seconds, the scarce resource is not Python knowledge. It is knowing what script to ask for — and that comes from understanding the business problem, the data, and the constraints.

The person who knows auto parts, or medical billing, or agricultural supply chains — that person, plus Claude, is now more capable than a junior programmer who knows none of those things. The AI handles the code. The domain expert handles the judgment. That is the new division of labor.

I did not build jjradiator.com because I learned to code. I built it because I knew what an auto parts catalog should look like, what data buyers need to see, and how to check whether the output was correct. Claude handled the syntax. I handled the sense-making. That split worked.

If you are a domain expert who has been putting off building something because you think you need to learn Python first — you do not. The AI writes the code now. What you bring — the ability to look at a page of data and know whether it is right or wrong — is the part the AI cannot do. That is the part worth paying for. That is the part I built a consulting offer around.

→ Work With Me — if you have the domain knowledge but not the pipeline, I can help.

Related Articles

→ Back to AI Export Lab — all build notes from this experiment.