AI stopped being just a coding tool for me

Coding is one of the easiest parts of AI-assisted work to understand. Give an agent a technical task, inspect what it produces, run it, find what is wrong and revise it. There is something tangible at the end: a change in the software. Even when the implementation is imperfect, the value is relatively easy to see.

For quite a while, that made “coding tool” a useful mental model for me. It was never the only thing I used AI for, but software development made the relationship especially concrete. I could take something that would previously have required much more manual implementation work and get to a working version considerably faster.

My actual product work refused to stay inside that description. In the previous Journal entry, I wrote about how Codex shortened the distance between noticing a problem and putting a working change back into use. What I left mostly unexplored was what started happening between those two points. The task might begin with code, but very often the next question was no longer a coding question.

Sometimes implementation exposed a product decision I had not made clearly enough. Sometimes a product decision created an architectural consequence. A test could show me that I had left something important out. A performance problem could lead away from application code altogether and into infrastructure or deployment. What changed gradually was that AI remained useful while the problem changed shape. I saw this repeatedly with HoursKZ.

Once the software was being used, new work was rarely as simple as “add this function.” Even when the implementation itself was straightforward, there were questions around it: does this actually belong in the product, where should it sit, what existing behaviour does it affect, and are we solving the operational problem or simply adding something that sounds useful?

AI could help me work through those questions. I could compare options, trace likely consequences and move from the product question into the implementation without starting the entire conversation again from zero. It could also make a vague instruction concrete enough for me to see where I had not thought it through. The final decision was still mine.

That distinction became more important as the work widened. AI made it cheaper to explore a decision and faster to turn that decision into something real. It did not make the decision automatically correct.

Architecture started appearing in much the same way. As functionality became more connected, “write this function” was increasingly preceded by questions such as where a responsibility should live, which component should own a piece of behaviour, what another part of the product should know about it, and what a local change would affect elsewhere.

I did not suddenly hand architecture over to an AI agent. What changed was that the discussion did not have to stop when it reached architecture. I could move from the intended behaviour into the technical structure, then into implementation, and back again when the code exposed a consequence I had not considered.

The VOP work gave me a particularly clear example from debugging. At one point, we were dealing with significant performance problems. It would have been easy to keep treating them as application problems and continue looking for code to optimise. The more important issue turned out to be the runtime environment: where different parts of the system were actually running, how they were reaching the database and what that meant for latency.

That investigation required moving outside the source code. Deployment topology, network path, infrastructure configuration and runtime measurements mattered more than another round of application optimisation. Once the actual topology was corrected, much of the apparent application-performance problem disappeared with it. The lesson for me was larger than that particular incident. If I was using AI to help solve a software problem, there was no good reason for the investigation to stop at the repository simply because the task had started there.

Testing sometimes sent the work in the same direction. I could get back an implementation that behaved exactly as I had described and still realise, once I looked at it properly, that I had left something important out. In those cases the implementation had made my own assumption concrete enough to inspect. Fixing the code was not always the next step. Sometimes I needed to reconsider what I had asked for in the first place. At that point the work had moved back into product thinking.

This is probably where my own background affects how strongly I notice the change. I was already used to moving between product ownership, architecture, delivery, implementation, QA, UAT and deployment. AI did not give me those disciplines or remove the experience needed to make decisions inside them. What it changed was the execution cost of moving among them.

Previously, moving a problem through several disciplines often meant creating something for the next stage: a requirement, design, technical explanation, implementation task, test case, deployment instruction or review. Those things still have value, especially when several people are involved, but in my own work I no longer need every change in the nature of the problem to become a hard handoff.

A requirement can still be questioned while the implementation is in progress. An architectural choice can be revisited because the implementation made one of its consequences visible. A failed test can send me back to the original product assumption instead of only back to the code. A deployment problem can move the investigation into infrastructure without becoming an entirely separate piece of work.

That has increased how much of a product I can practically carry myself. I am careful with that statement because it is easy to turn it into the usual claim that one person with AI can replace an entire team. That is not what I have seen. Different specialists bring depth, experience and perspectives that do not become interchangeable because an agent can help someone work across several areas.

The change is in span. An experienced person can now directly execute more of the work around a decision before another handoff becomes necessary. For me, that has made the distance between deciding something and discovering its consequences much shorter.

Speed is part of the benefit, but it is no longer the part I find most interesting. If all AI did for me was write code faster, it would still be useful. The larger change is that I can often keep following the same problem as it moves from the reason for a feature to its design, implementation, testing and operation. When something goes wrong, I can also follow it backward.

That continuity is useful, but it has an obvious weakness: a mistaken assumption can travel just as efficiently as a good one. If the starting instruction is wrong, AI can help turn it into coherent implementation with impressive speed. The result can look polished and still be built around the wrong starting point. So the increased execution capacity has made my own responsibility more visible, not less.

An AI agent can propose something, implement it, inspect it, test it, revise it and help investigate why it behaved differently from what I expected. None of that transfers ownership of the result. If I choose the wrong behaviour and ship it quickly, the fact that an agent produced the code is not much of an explanation.

This is also why “coding tool” eventually stopped feeling accurate to me. I still use AI to write software. A lot. But the code is increasingly just one place where the work passes through.

The more significant change has been that the same working thread can now follow a product problem much further than I used to expect: into decisions, technical structure, implementation, testing, deployment and sometimes back to the original assumption that started the work.

AI did not make those parts disappear. It just stopped staying on the coding side of them.