This page holds the longer story behind one paragraph of the journey: the year and more between first using AI chat assistants and choosing an agentic coding tool on purpose. It is here on its own page, so the journey stays readable, because the detail matters to anyone weighing the same transition.
Five stages, not a switch
My engagement with AI-assisted development did not begin with agentic tools, and it did not begin with code. It began in a browser, with Microsoft Copilot and ChatGPT, and moved through five stages, each teaching something the next one built on: writing, then troubleshooting, then production infrastructure, then a first attempt at building an application, and only then, once I knew what was missing, choosing deliberately between tools. That took well over a year, none of it a dedicated stretch, because it all ran alongside the ordinary work of the role. And it was a chat window throughout: every piece of code went in by pasting and came out by copying, which shaped both what the tool was useful for and how large the eventual gap to agentic tooling turned out to be.
Stages one to three: building judgment cheaply
The first uses were small and practical: rewriting emails, clarifying technical explanations for non-technical readers. That sounds trivial next to building software, and it was the necessary start, because judgment about a tool must be built somewhere, and building it on production infrastructure is an expensive choice. Use then expanded into troubleshooting: reading unfamiliar errors across systems I did not own the internals of, where the tool generated hypotheses faster than working alone, often wrongly, never authoritatively. The first production-stakes use was the encrypted backup certificate work, where the documentation was ambiguous and a wrong assumption would have been discovered during a restore. I acted on nothing without verifying independently, which is the discipline that made the threshold crossable at all.
Stage four: trying to build something
Months in, I attempted an actual application, and it turned out to be a better teacher than a smooth success would have been. The subject was the interface to our Remedyforce ticketing data: a Python desktop tool written by an external consultant, no more than a couple of weeks old. It worked as delivered, and it had the shape a tool gets when it is built quickly, by one person, to run one way. The economics put it on my desk: changing anything meant buying more consulting hours, and we had no in-house Python developer free to take the code over, so the honest destination was our own stack, C#.
The moment that reframed the project came from trying to run it as a module. It failed immediately: the application object had no run method. That error was the symptom, not the problem. The problem was that the application had no real entrypoint at all, and nothing had ever caught it, because the code had only ever been executed one specific way. Once that was visible, the list grew: circular imports, callbacks welded to business logic, modules never designed to be imported. For our purpose it needed redesigning, not tidying.
What a chat window could and could not do
Working through that refactor taught me the real shape of chat-based assistance, and the limitations were specific. It was good at reasoning: describe a problem clearly and it helped think through the structure and explain why an error meant what it meant. What it could not do was touch the project, and every constraint followed from that single fact:
- It could not read the codebase. Everything moved by paste and copy.
- It could not accept the whole file, so a large legacy file went through in chunks, reassembled by me, which is where the inconsistencies lived.
- It could not compile, run, or test anything. Every suggestion was unverified until I built it myself.
- It had no view of the rest of the project, so consistency across files was my job.
- It had no memory between sessions. Every decision reached one day had to be re-established the next.
None of that made it useless. It made it a thinking partner with no hands, which is a meaningful thing to have and a different category of tool from one that reads a repository, edits files, and runs a build.
Where that project went
I moved the tool to a web application built on FastAPI, and it grew a proper structure across several months of on-and-off work, every gap meaning re-established context the tool did not retain. It is the direct ancestor of the Legacy Ticket Archive, and I want to be straight about the ending: the production archive was rebuilt on our internal C# stack, taking the lessons and leaving the code, because a FastAPI service would have recreated the very situation that started all of this, Python software in a shop with no Python developer to maintain it. I do not regard it as a wasted project. Understanding why the desktop tool had to go is what made the production rebuild fast when better tooling arrived.
Stage five: choosing a tool deliberately
Months of building through a chat window is what made the next step obvious: I knew what was missing from having personally been the bridge between a reasoning engine and a codebase. Before starting anything substantial, then, we compared the options available (Microsoft Copilot, Claude, and OpenAI’s tooling) against a problem I had already failed to solve comfortably with one of them. We selected Claude, and the same discipline, comparison before adoption, is what later produced a formal evaluation of 16 local models instead of picking one on reputation. Copilot kept the role it had proven good at, everything written for people instead of a compiler, while Claude Code did the implementation: two tools, different jobs, one project.
The transition that mattered
The shift from a chat window to agentic tooling changed the category of problem worth attempting. In the first arrangement I was the hands: every file read, every change applied, every build run, one paste at a time. In the second, the tool reads the codebase, proposes a plan, changes many files, runs the build, and responds to what broke. The work I was doing did not change; I stopped being the transport layer between the reasoning and the code. The clearest measure is on this site: the ticketing interface rewrite ran on and off for months and reached deployment planning without shipping, while the production archive that replaced it was built, deployed, and running alongside eight other projects inside a single stretch of a few months.
The story continues in the journey.