AI Journey ​

A journal-style log of how I've been incorporating AI tools into my coding workflow: what I've tried, what's worked, what hasn't, and how it's changed the way I build and ship software.

July 2025: First contact ​

It started small, almost experimentally. I opened the free version of ChatGPT and began throwing little problems at it: a piece of logic I didn't want to hand-write, a boilerplate block I'd written a hundred times before, a snippet to unblock myself when I was stuck. Nothing ambitious, nothing that touched a real feature end-to-end. It was a copy-paste relationship: I'd describe what I needed, take what came back, and fold it into my own code by hand. But even at that scale, something clicked: the friction of writing repetitive, mechanical code had dropped, and I could feel that this was going to matter more than a novelty.

August 2025 to February 2026: Building the prompting muscle ​

About a month in, I moved from the browser tab into the editor itself, integrating GitHub Copilot directly into my workflow. This was a different kind of practice. Instead of one-off snippets, I started deliberately building my prompting skill: breaking a feature down into small modules, prompting for a piece, writing the code that connects the pieces by hand, then prompting for the next piece. It was a step-by-step, hybrid process: AI for the parts that were mechanical or well-defined, my own hands for the parts that needed judgment.

The real win during this stretch wasn't speed of thinking: it was speed of typing. Copilot saved me the physical and mental overhead of writing out lines I already knew the shape of, which meant more of my attention stayed on the actual design of the feature rather than the keystrokes needed to express it. This phase ran for roughly six months, through to February 2026, and it's where I built the instinct for how to talk to a model so it gives you something usable on the first or second try.

February 2026: The turning point ​

In February, everything changed in scope. I got full access to Claude, along with room to fully integrate AI into my actual delivery workflow, not just as a helper on the side but as a real participant in building features.

It didn't start smoothly. In the beginning, matching the style and quality of my own hand-written code took multiple rounds of prompting, and for anything with real complexity or nuance, the first output usually needed minor revisions before it was right. Honestly, at this stage the net delivery time wasn't much better than doing it myself: the AI was doing the typing, but I was still doing a lot of the steering, correcting, and re-explaining. It was a necessary, humbling stretch: proof that handing work to AI isn't automatically faster just because the AI is fast.

Skills, plans, and a codebase that learned to speak AI ​

The next shift came when I started learning about skills and structured workflows. That single change made the whole process a lot more predictable: instead of re-explaining context and conventions every time, I could encode them once and let the AI carry that context forward reliably.

Layering a plan-first approach on top of that was the real unlock. Rather than prompting straight into code, I'd have Claude construct a plan file first (a moderately detailed breakdown of the feature) and then iterate on that plan until it was solid, before writing a single line of implementation code. With a good plan in hand, Claude could generate a genuinely full, working feature from it.

But I also learned the limits of process alone: skills and plans weren't enough by themselves to guarantee full feature delivery. The missing piece was the codebase itself. It had to adapt to being read and written by AI: more deliberate comments, clearer docstrings, naming and structure that made intent discoverable, not just implementation. Once the code started documenting its own purpose well enough for a model to recognize it, the plans and skills built on top of it started paying off.

Now: Parallel planning and disposable code ​

My working pattern today looks nothing like it did a year ago. I now plan multiple features and sub-modules in parallel, grouping and sequencing them by their nature and their dependencies on each other. Once that planning phase is done, Claude can build out all of those features in a matter of a single working day. What's left for me is to go through each draft branch, review it thoroughly, and apply whatever minor refactors it needs.

One of the more interesting findings from this stage, and in hindsight a fairly obvious one, is that the amount of refactoring a feature needs afterward is inversely proportional to the quality of the plan I gave it at the start. A weak or vague plan means a rough draft and a longer review pass; a tight, well-considered plan means the output is close to final on the first attempt. Planning has effectively become the highest-leverage part of my job.

The other big unlock has been disposable code: quick snippets, standalone scripts, throwaway HTML pages, small test harnesses, generated on demand and thrown away just as easily. These give me standalone test suites and verification tools that I can update on the go with almost no effort, purely because the cost of writing and rewriting them has dropped to nearly zero. Doing this kind of thing without AI simply wasn't feasible before: the cost-benefit never justified writing a disposable tool for a five-minute check. Now it's routine.

Looking ahead: Bringing it on-premises ​

Everything so far has depended on hosted models like Claude sitting behind an API. The next chapter I want to write for myself is figuring out how much of this same workflow (planning, skills, full-feature delivery) can be reproduced with open-source LLMs running on-premises or on personal servers, instead of a third-party cloud endpoint.

The part I'm most interested in isn't just swapping the model out; it's pairing a self-hosted LLM with localised data graphs: keeping the knowledge the model reasons over (codebase structure, docs, project context) in a graph that lives on infrastructure I control, rather than leaning on a hosted model's context window alone. If that holds up, it opens the door to using this same AI-driven delivery style in settings where sending code and data to an external API isn't an option: client environments with strict data residency requirements, air-gapped systems, or just projects where owning the full stack, model included, matters. It's still an open question how close an open-source, self-hosted setup can get to what Claude delivers today, but that's the experiment I want to run next.