Coding with AI and finding purpose
In the latter half of 2025, I decided to spend more time “looking” at code. The old me would have said “writing” code, but as we all know, the world has changed, and that’s not the appropriate verb anymore.
Running a software engineering business is a game of rapid change—this industry is beset with such a fate. I myself have changed a lot—from a software developer to a team lead, and eventually an entrepreneur. The biggest change is that I’ve been coding less and less over the years as I’ve inevitably shifted focus to leadership.
When AI coding agents started becoming a thing (and by that, I mean when they really started showing promising results), I honestly couldn’t assess how big of a change they would bring. The blast was enormous—too enormous. It was impossible for anyone to accurately gauge the impact.
How much will it change a small company like ours? How much will it change me?
A question that starts with “how much” must be answered with some kind of quantity—a unit—a measurable and verifiable fact. How much will AI change us? To answer that, we must break down that change into smaller, digestible chunks and pick the ones we care about.
What do I care about? Let’s start with the business of building software.
At the heart of this profession lies the ultimate goal of improving any aspect of human experience—whether it’s the mundane experience of grocery shopping (one of my favorite activities) or a huge feat like probing the universe to ensure the survival of our planet (one of my childhood dreams). These two tasks couldn’t be farther from each other in scope, but it’s not unlikely that both can be improved with a piece of code written in the same language.
Isn’t this industry so damn fascinating?
What I truly care about is how much AI is changing my purpose in this fascinating process of creating software. But how can I measure purpose? Is it about the time I use to write code? Or can it be measured in terms of how much attention, creativity, problem-solving, questioning, prompting, communicating, coordinating, planning, testing in the physical world, campaigning, convincing people to change, and relentlessly trying different approaches whenever a solution fails—all in pursuit of improving human experiences?
AI has only changed one of my purposes. I accepted that in the latter half of 2025, when all I did was sit down, think, write specs, and look at code generated by AI. It was truly beautiful what it— I mean we—can do. Mind you, beauty is not perfect; at times, it’s also blinding.
In terms of quantifiable change, I now write 95% less code. The time to complete a feature’s code has also decreased by approximately 57%.
The ugly part of coding has changed too: the part where we have to type long, boring, boilerplate functions riddled with annoying red squiggly lines.
But the good part, at least to me, hasn’t changed much: the part when, after the code has undergone several levels of transformation under a machine that turns everything into 1’s and 0’s, I—the developer—get the first look at the physical manifestation of the team’s collective imagination and perfect it until it’s finally usable. That satisfying feeling, I hope, will stay the same.
I am, somehow, afraid of change—it would be hypocritical not to admit that. But the fear is so small compared to my excitement about the possibilities. I don’t fear losing my job or my business; I fear it will become harder to find young developers who are genuinely interested in creating great software because they think AI will replace them. When that happens, who will take care of the business of improving human experiences?
Perhaps that’s also my purpose: to find and grow people who will love this job as much as I do. To do that, I must not stop marveling at the beauty of code—written by humans or otherwise.


I think young developers, with the tools available today, will have a very different workflow in the years ahead. There will be a shift in mindset.
In the past, programmers used punch cards to write programs. Later, low-level languages like assembly were commonly used to perform even simple computations. Then came server-side scripting, where technologies like PHP often mixed frontend and backend logic in a single file. Today, we typically separate the frontend and backend into distinct systems.
Maybe future developers will simply have a different workflow. What’s important is that they are still solving problems.