A personal reflection after nearly a year of hands-on agentic development
A few days ago, I caught up with Terence, my former co-founder from our startup days in Beijing. When I told him I had spent much of the past year coding again, he was genuinely surprised.
Since Q4 2025, I have quietly returned to hands-on development—not by going back to exactly how I programmed 20 or 30 years ago, but by coding alongside AI agents and our development team.
It has reminded me why I enjoyed programming in the first place.
Returning to the part of coding I enjoy
I have always been good at programming, and I have always enjoyed its problem-solving side. What I enjoy less is the mechanical work surrounding it: learning another API’s conventions, complying with rigid data formats, looking up framework-specific syntax, or discovering that something failed because of punctuation, indentation, tabs or spaces.
Precision matters in software. Computers need exact instructions. But not every difficulty in programming is an interesting problem. Some of it is simply translating a clear intention into the particular format expected by a language, library or API.
Agentic coding changes that balance.
I can describe the problem, architecture and intended outcome while an agent handles more of the mechanical translation into code. I still need to understand the system, examine the implementation, test the result and correct its direction. But I spend less time wrestling with syntax and more time on the part I have always enjoyed: deciding how the problem should be solved.
From software methodology to a tighter loop
Software development has been moving towards shorter feedback cycles for decades. We went from heavyweight, sequential projects to spiral development, agile methods, continuous integration and frequent releases.
Agentic coding accelerates the same underlying loop:
Define → build → test → release → observe → improve
This is why I am less interested in one-shot coding demonstrations. Producing an application from a single prompt may demonstrate a model’s capabilities, but it does not necessarily demonstrate product value or return on investment.
Real software must survive contact with users, changing requirements, security concerns, unexpected data and external systems. It needs to be tested, maintained and improved.
The important unit is therefore not the prompt. It is the complete learning cycle—and how quickly we can repeat it without sacrificing quality.
Managing agents is still engineering
Coding agents can inspect a repository, modify multiple files, run commands, execute tests and revise their work. They also know standard algorithms, database-normalisation principles, design patterns and many implementation strategies that previously required coordination among several specialists.
That can remove a surprising amount of communication overhead. When managing 10 or 20 developers, even a small change may require explanation, task allocation, clarification, implementation, review and reintegration. An agent can sometimes complete that loop in minutes.
But agents also make mistakes. They misunderstand requirements, use outdated APIs and occasionally insist that an incorrect approach will work. If an agent repeats the same failed solution, asking it the same question again rarely helps.
We normally stop the loop, isolate the problem, provide a failing test, simplify the context, switch models or refactor the task. The objective is not to make the agent try harder. It is to give it a better path to a verifiable result.
Experienced developers remain essential for architecture, security, judgment and review. Agentic coding does not remove engineering discipline; it makes that discipline more important because software can now be generated so quickly.
The economics of useful output
Our working budget is approximately RMB 1,000 per developer per month for AI and software tools. We compare more than token prices. We consider the quality of the result, the number of errors, the amount of rework required and how much human time a tool saves.
The cheapest model is not economical if its output repeatedly needs to be redone. The most capable model is also unnecessary for every task.
Our general approach is to use the smallest, fastest and least expensive model that can reliably complete the work. Local or lower-cost models may handle repetitive tasks; stronger online models handle routine development; frontier models are reserved for difficult reasoning, architecture or debugging.
We do not need Claude Opus or GPT-5.6 to write “Hello World.”
I sometimes call this quotamaxing, but it does not mean consuming tokens simply because they are available. It means converting paid capacity into useful, testable software.
A memorable example was the short promotion for Qwen3.8-Max-Preview. During the promotion, its effective off-peak cost between 10 p.m. and 8 a.m. Hong Kong time fell to around 2% of the standard price—a 98% discount, or 0.2折. In practical terms, the same budget could support roughly 50 times the usage. My team and I spent rather more time working at night than was probably healthy.
Voice has become part of my development workflow
After nearly a year of working this way, I also use voice prompts extensively.
Speaking makes it easier to communicate intent, history, constraints and alternatives. I can explain the reasoning behind a task almost as if I were briefing a developer beside me. That context often produces better results than a short typed instruction.
I still use written text for precise filenames, code fragments and technical values. Voice is better for the shape of the problem; text is better for details that must be exact.
There is one practical requirement: I normally need a private room. Continually talking to a computer in an open office would be distracting for everyone else—and perhaps slightly alarming.
The bottleneck has moved
As the systems I worked on became larger, my own implementation time eventually became a limiting factor—not because I could not solve the problems, but because one person could translate only so many ideas into working software.
Moving into management allowed me to scale through teams. My technical background helped me explain what I wanted, divide systems into components and coordinate developers to build them.
Agentic coding changes that equation. It lets me apply many of the same management skills much more directly, while remaining close to the implementation and feedback loop.
In hindsight, my two formal—or formal-ish—professional qualifications seem unusually relevant. One is PRINCE2 project management. The other is an ISEB software-testing practitioner qualification.
When I took the testing course, almost everyone else was pursuing a career as a hands-on software tester. I was a coder and manager with no intention of becoming one. I simply wanted to understand testing properly.
Those two disciplines have now come together. Project management taught me how to break down, sequence and direct complex work. Software testing taught me never to confuse a plausible output with a correct result.
Coding agents can produce an extraordinary amount of software. Someone must still define the objective, direct the work, examine the result and decide what should happen next.
When code becomes cheaper
As implementation becomes faster and less expensive, source code alone becomes a weaker competitive advantage.
Value moves towards understanding the problem, choosing what to build, designing the system, integrating it with the real world and operating it reliably. Trust, distribution, data, service and execution may matter more than the quantity of proprietary code.
This has also made me more willing to open-source parts of our work. If the code is not the main moat, sharing useful foundations can attract feedback and help everyone iterate faster.
The best preparation for the next model
I began writing publicly in 2019, around the time I was experimenting with GPT-2 on my own hardware. In March 2021, I explained why:
I am not a writer and I am very selective on what I share with friends, so why am I writing these? I am using it more like my open journal on mostly non-sensitive topics like work or tech news. To save me time on repeating the same chat. By writing these down, maybe one day some AI bots will be bored enough to go through everything I wrote and sell me something that I didn’t know I truly want. 😃
It was partly a joke. By 2026, it no longer seems especially far-fetched.
Future agents may be able to recall what I have written, understand earlier decisions, anticipate what I need and help me build the next iteration. The code, tests, documentation, searches and explanations we create today become structured context for tomorrow’s models.
That is why I do not want to wait for the next breakthrough before building. The best preparation for a better model is to use the current one, solve real problems and leave the next iteration a better starting point.
After more than 25 years in software, I still enjoy solving problems with computers. Agentic coding has simply brought me closer to that process again.
Leave a Comment