The story behind the project

Four years in the workshop

I spent four years as a light vehicle mechanic. I trained under and worked alongside resourceful general technicians, knowledgeable manufacturer specialists, and experienced electricians alike. Each an expert in their own right, and all capable in different areas. The work I cared about most was diagnosis: reading a vehicle's systems and chasing a fault back to its cause.

That work was getting steadily harder to do. Newer cars are increasingly difficult for an independent garage to diagnose, and the difficulty is built in: more and more of what a vehicle knows about itself sits behind the manufacturer's own tools, software and access agreements. When the car will not tell you what is wrong and the maker's systems are closed to you, swapping the whole assembly is often the only practical answer. "Just replace it" became the standard approach across the trade, and it is no reflection on the people doing the work: the skill was there; the access was not.

I did my share of routine servicing and maintenance through all of this, more of it once I could handle jobs on my own, and there is nothing wrong with that work. It just never held my interest the way fault-finding did.

The unofficial IT job

Somewhere in those four years I picked up a second, unofficial role. The garage's network security and device management were run by an independent IT consultant, and the business needed someone in-house he could work through. I was identified as the technically capable one, so that became me. I helped him roll out and configure Sophos, the endpoint security the site ran on, machine by machine. When hardware aged out or software broke, I found the problem and fixed it myself: moving machines off old, unsupported operating systems, updating BIOS, setting up security policies and admin accounts, unifying passwords and autofill across every browser on site, and stripping the odd machine down entirely to rebuild it. I was also, inevitably, tech support for the older generation of mechanics. Looking back, that was the first teaching I did.

Leaving to retrain

Away from the workshop I had a long-running interest in AI and the technology around it, fed by podcasts and videos. What I had was conceptual understanding. What I lacked was the practical side: the systems behind the tools, the conventions, how any of it is actually built and run. I think that combination is common, and it is part of what this project now exists to address. When I decided to leave the trade, that was the gap I set out to close.

My next move was to try building the learning environment myself, inside ChatGPT. I called it the Personal AI Workstation Handbook — PAWH. I ended up reinventing several established conventions without knowing they existed, badly: markdown "source of truth" files to guide the model, which is essentially what the industry now ships as project instructions; generated scripts to modify project files; a rough git integration through a plugin. At its worst I was uploading a 400MB zip of project files into the chat to keep it current.

It failed slowly. The folder grew too large and complex to review. I leaned on the AI more and checked its output less. Quality got worse as I added rules, not better, and the waits and usage costs climbed — an artifact of my poor implementation, not the capability of the model I was using. Defining meticulous workflows for every task did not fix it either. When I finally stepped back and surveyed what already existed, almost everything I had been hand-rolling was an established tool or convention I simply had not learned yet. I closed PAWH down as a learning experience, kept what was worth keeping, and restarted on the workflow this site now documents.