How AI Changed My Coding
AI did not suddenly start coding for me. It started as a rough tool in a browser tab, then slowly became part of how I build software every day.
Over the past few years, while building Callings.ai, I have spent more than 10,000 hours working with AI inside my development process. What changed over that time was not just model quality. The way I code changed with it.
This is not a broad opinion about AI. It is my own experience: how it started, what actually improved, and how I use AI to code today.
How it started
My first serious use of OpenAI was in 2021, when I was at Care Intent.
At the time, I was using text-davinci-003 extensively in the API Playground, mostly to generate training material for Google Dialogflow. That was not yet my current coding workflow, but it was the first time I saw that these models could be useful for structured technical work. The interface was primitive, the output was uneven, but the signal was already there.
Before long, I started pushing the model into more technical tasks. The workflow was simple and clumsy: generate something in the Playground, copy it into VS Code, test it, watch it fail, then paste logs and errors back into the model. Sometimes the useful output was only 20 lines. Even then, those 20 lines mattered.
The value was not that AI understood the system better than I did. The value was that it helped me move faster through implementation details, especially in languages or frameworks where I was less fluent. I was still doing the architecture myself: organizing the backend, shaping APIs, thinking through the frontend, and making product decisions.
At that stage, AI was not coding for me. It was helping me keep moving.
The shift in late 2022
When I began laying the groundwork for Callings.ai in late 2022, my main tool became GPT-3.5, again mostly through the API Playground.
That was the first real jump in usefulness for coding. The output was still inconsistent, but it became good enough to support momentum. Instead of treating the model as an occasional helper, I could start treating it as part of the build loop.
Then came another important step with GPT-4 and using it directly in ChatGPT. That was when I could sometimes generate closer to 100 lines of code at a time. By current standards that sounds small, but it changed the rhythm of work.
The process was still very manual. Most of the real work still happened in VS Code. I was copying, pasting, testing, fixing, reviewing, and trying again. Nothing was automatic. Nothing was clean. But the cycle was getting shorter, and that made product development feel more fluid.
That mattered because I was not just experimenting. I was building a real product.
The two major shifts after that
For me, the next phase was defined by two major shifts.
The first came in 2024, when GitHub Copilot became much more useful as a cross-file chat integrated directly inside VS Code. That changed the working experience in a practical way. I no longer had to treat the model as something mostly outside the editor. The context got closer to the code, and the loop became tighter. It was easier to work across multiple files, trace relationships, and stay inside the actual development flow.
The second came with Claude Opus 4.5 in November 2025.
That is when AI-assisted coding started to feel less like a smart helper and more like a real production workflow. The quality, reliability, and consistency were high enough that I could structure work around multiple concurrent agents instead of using a single back-and-forth interaction.
How I use AI to code today
Today, I run up to 10 agents in parallel across different parts of the product. Some work on features. Some debug. Some refactor. Some handle deployment work. Others process user feedback coming directly from the product, including screenshots and metadata, then prepare diagnosis notes, draft responses, and sometimes propose or implement fixes.
As the codebase has grown toward a million lines, my role has shifted with it.
Less time goes into writing every line by hand. More time goes into deciding how work should be split, what context each agent needs, how branches stay separate, and how changes get checked and merged. I still code, but a meaningful part of coding now looks like orchestration.
That shift forced me to become sharper about structure. Parallel agents are only useful when boundaries are clear. Weak architecture creates collisions. Vague context creates drift. Fragile systems break fast.
Building this way in production pushed me deeper into asynchronous systems, orchestration frameworks, context design, specialized data models, and resilient processing pipelines. Over time, I integrated more than 30 AI and data services and deployed high-volume AI workflows processing more than a billion tokens per day. Those numbers matter mostly because they reveal what survives real load and what does not.
What changed in the work itself
The biggest lesson is simple: faster code generation makes judgment more important.
Writing code is easier than it used to be. Deciding what should exist, how it should be structured, and how the whole system stays coherent is still the hard part.
Another change is that software development now feels closer to a creative practice. The cycle from idea to prototype to revision is much shorter. That fits the way I have always liked to work: exploring, testing, adjusting, and refining through iteration.
In that sense, AI did not remove the need for thinking. It made the thinking more visible. Product direction, architecture, sequencing, boundaries, review, and taste matter even more when generation becomes cheap.
A few practical takeaways
- Start with narrow tasks. Early value often comes from unblocking specific implementation problems.
- Keep architecture in human hands. Better structure makes AI much more useful.
- Use parallel agents only when boundaries are clear and branches are managed carefully.
- Treat speed as leverage, not as a substitute for product thinking.
Where this leaves me
What stays with me is not the tool timeline. It is the change in posture.
I started by copying small fragments from a browser tab into VS Code and trying to make them work. Today I build by coordinating AI across a large production codebase, with multiple agents working in parallel across features, debugging, deployment, and support workflows.
That is the real shift for me. Coding has become less about producing every line manually and more about shaping systems, defining boundaries, giving the right context, and deciding what deserves to be built in the first place.
After more than 30 years of building software, this is one of the biggest changes I have seen in the craft. AI did not replace the work. It changed where the work lives, and it pushed me closer to the part I value most: creating, structuring, and refining products at speed.