01. AI Made My Code Better, but I’m Not as Happy as I Used to Be
Last updated:
In April 2025, I built a command-line tool in Python for testing Akamai rules.
Changing those rules comes with a particular risk: one modification can unintentionally affect existing configurations. Every change therefore needs to be followed by a large set of regression tests. The teams involved also work in different programming languages. If each team has to rewrite the same tests in its own language, collaboration quickly becomes expensive.
My solution was to design a simple testing syntax using YAML. Users would not need to understand how the tool worked internally. They could add test cases by describing the request, conditions, and expected result in a predefined format.
I spent a week building the first version by hand. It could read all the test definitions in a directory, run them from the command line, and display the results in the terminal. It worked, and I had tried to keep the code maintainable, although plenty of problems remained.
Then I gave the requirements and code to ChatGPT.
This was before I started using coding agents such as Claude Code. I had to work through a chat window, repeatedly copying and pasting code. I first showed it some Vitest output so it could understand how I wanted the terminal interface to look. Then I asked it to build an initial version.
In less than thirty minutes, it produced something that ran.
The code had bugs, but it had already identified which parts needed abstraction, how the modules should be organized, and how related functionality should be kept together. The terminal output looked good. It had also generated unit tests with broader edge-case coverage than I had expected.
I did not delete my version, nor did I spend much time staring at the screen in disbelief. Instead, I broke the remaining work into smaller pieces. I wrote roughly ten percent of the code myself and handed the other ninety percent to AI. Once the main architecture had settled, my job became describing requirements, reviewing the results, and asking it to continue.
The project moved faster. The result may even have been better.
The strange part was that I was not as happy as I used to be.
The Urge to Create Came Before the Engineer Title
I was fascinated by computers as a child. On weekends, I would wait for my parents to leave and then play on the family computer until they came home. The moment I heard a key enter the lock, I would pull the plug and try to make it look as though I had not touched the computer all day.
This never worked. The computer case remained warm, and the CRT monitor would make a few creaking noises as it cooled down. If I waited until my parents were already at the door, the monitor was usually more honest than I was.
I did more than play games. I would take the computer apart, put the components back together, and reinstall Windows 98 from a CD. Home computers failed often in those days, and there was not always someone around who could help. I learned about MS-DOS, BIOS settings, and computer hardware from magazines.
None of this had a clear purpose. I wanted to know what was happening inside the machine.
One day, I traded game discs with a classmate. Alongside the game I wanted, the disc contained Dreamweaver and 3ds Max. I did not recognize either program and assumed they were games, so I installed both.
I opened Dreamweaver, made a page, and typed a few characters into the code window beside it. The page changed immediately. It was not until university, when I saw older students using Dreamweaver for their graduation projects, that I understood what I had touched years earlier.
3ds Max was even more confusing. It opened with a teapot that I could manipulate. I kept expecting the real game to begin once I had configured the teapot correctly.
The game never appeared.
At the time, I had no intention of becoming a software engineer. I was drawn to a simpler experience: changing something, watching it respond, and trying to understand why.
A Failed Blog Led Me into Software Engineering
I studied Computer Science and Applications at a university in China for less than a year. During my first year, my visa to study in Japan was approved. I left the four-year program behind, moved to Japan, and eventually chose business studies instead.
In 2011, during my first year at a Japanese university, I was studying and working part-time. I earned less than 150.
Around then, I came across a blog about travel and consumer recommendations. The design was not complicated, but its masonry-style layout caught my attention. Tourism in Japan was growing, and I decided that I could build a website about travel and everyday life in Japan for international visitors.
I rented a server that same day and bought jaforeign.com from GoDaddy. The name combined “Japan” and “foreign.” It looks long and slightly awkward now, but at the time it was the best result I could produce after exhausting every naming idea I had.
The hosting provider offered one-click WordPress installation. Naturally, I chose the more difficult route.
I followed tutorials, typed Linux commands into the terminal, and built a LAMP environment on the server myself. Once WordPress was running and the domain worked, I assumed the difficult part was over. All I had to do now was write.
Three days later, I had written roughly one hundred words.
The problem was obvious: I did not have enough travel experience. Studying and working took up most of my life. Whatever time remained went to computers, games, and films. I wanted to publish travel content, but I had nothing I could keep writing about.
The blog ended with two unfinished articles. Less than two months later, I cancelled the server and shut down the site.
As a product, it failed completely. It had no consistent content, no audience, and hardly any lifespan. But my interest in building it did not disappear. Linux, servers, LAMP, and HTML later became some of the few things I could point to when trying to enter the software industry.
I had chosen the wrong subject for the blog, but accidentally found something I was willing to keep doing.
“I’ve Been Waiting for You. I Thought You Weren’t Coming.”
After graduating with a business degree, I joined an accounting firm. I had taken several bookkeeping and accounting courses at university, so the decision appeared reasonable.
Doing the job felt different.
Working with numbers and reports every day made one thing increasingly clear: I could not imagine spending the next several decades this way. After five months, I resigned without another job waiting for me and without enough savings to support myself.
During the worst period, I ate once a day. In the end, I still had to ask my parents for money.
I wanted to become a software engineer, but the experience from my failed blog was not enough to get me through most interviews.
A recruiter eventually introduced me to a small IT company in central Tokyo. Its office could hold around thirty people. After hearing about my background, the person in charge offered to train me and place me on a project.
I thought I could still find a larger company.
I agreed to report for work the next day, then did not show up. Instead, I continued interviewing elsewhere.
Three weeks passed. Nobody hired me.
I emailed the person at the small company again. When I returned to the office, the first thing he said was:
“I’ve been waiting for you. I thought you weren’t coming.”
He asked where I had been and why I had not reported earlier. I felt fortunate that the opportunity still existed, but I also had to admit something to myself: at that point, I did not have the ability to enter a larger company as a software developer.
During the training, he asked me to build a calculator with PHP and HTML. I finished it that day. It supported addition, subtraction, multiplication, division, and expressions containing parentheses.
It was ugly, but it worked.
My first real assignment was part of a user-management system. Maintenance had been outsourced to the company’s team in India. I was responsible for a simple product-list page that needed to display data and provide filtering.
The application used CakePHP. I worked from the morning until five the next morning. After three days, I had completed only the list display. The filtering feature was still unfinished.
That was the beginning of my software engineering career. There was no elegant breakthrough and no sudden display of talent. Someone gave me an entrance. I built an ugly calculator, then exposed nearly every weakness I had on my first project.
Over the next ten years, I moved from testing into frontend and backend development. I also worked with data engineering, system architecture, and cloud infrastructure. I joined Rakuten in 2018, then moved to Fast Retailing in 2024, where I continued working as a frontend engineer.
But job titles were not what convinced me that I loved creating software.
Creation Felt Complete Only When Someone Used What I Made
In 2017, my team was using iView UI to build an internal dashboard. The system handled basic data operations: adding labels, updating records, and removing data collected from Twitter when it did not meet our requirements.
One feature required the Tag component to support a selectable state. A user might click a tag to decide whether an image should be displayed, or choose one size from several options. Element UI already supported similar behavior, but iView did not.
Since our project needed the feature, I decided to add it to iView.
In October 2017, I submitted PR #2124. It added checkable and checked states to the Tag component, along with event handling and usage examples. The maintainers later adjusted parts of the implementation. The feature entered the project, and our internal dashboard began using it.
Related questions later appeared in GitHub Issues. People were using the feature, and some of them had found problems that only became visible through real use.
Whenever I saw that a stranger had solved a problem with something I had built, the feeling was difficult to describe. It was not only about having code merged or receiving technical approval. Something I had made had entered another person’s work and become useful there.
At the time, two things mattered to me.
First, someone had to use the product, and it had to solve a real problem. Second, I wanted to enter a state of deep focus while building it. My attention would narrow, the outside world would fade, and my mind would contain only the problem, the structure, and the code.
Hours might pass. The exhaustion was real, but so was the sense of fulfilment.
For me, those two things together formed the experience of creation.
I Keep Building Things, but Rarely Stay to Run Them
The same urge led me to create many projects I never finished.
When remote work began in 2020, commuting and office conversations disappeared. I suddenly had more time. I used it to build software, turning passing ideas into small GitHub repositories.
Many were never completed. Most never found users. Still, I enjoyed starting with an empty directory and gradually giving it structure.
rotalacss was one of the more complete projects. It was built on Tailwind CSS, which was gaining popularity at the time, and its component design drew inspiration from Spectre.css. I believed utility-first CSS could reduce the mental overhead of maintaining large projects. I wanted to combine Tailwind’s approach with a more traditional component framework.
The direction was not necessarily wrong. The problem was that I enjoyed the early construction stage but did not keep maintaining the project.
Pitayan Blog repeated the same pattern. I intended to write technical articles but kept modifying the blog theme instead. I spent much of my time working on the site rather than its content.
I still wrote articles, but English is not my first language, and this was before AI writing tools. A single post could take me ten days. Two articles eventually reached the Hacker News front page and brought a burst of traffic, but I never established a consistent publishing schedule.
As products, neither project went far. As learning experiences, they were not worthless. rotalacss deepened my understanding of CSS framework design. Pitayan trained me to write in English and gave me my first exposure to a larger audience.
Together, they revealed a pattern I kept repeating: I was good at taking something from zero to one, but not at staying with it from one to somewhere much further.
I used to describe this as a lack of discipline. Looking back, another explanation seems possible. I was more drawn to the intense period of creation than to operating something that already existed.
From Writing Code to Delegating Work to Agents
Today, I delegate development tasks through Claude Code and OpenAI Codex every day. I also choose appropriate Skills to give agents the context, steps, and constraints they need.
When the requirement is clear, I rarely begin by writing code. I discuss the approach with AI first. When the requirement is unclear, I use AI to help turn a vague idea into something concrete enough to execute.
Delegating to multiple agents has become normal, although I usually keep them within the same project. Too many simultaneous projects force me to keep switching contexts, which works poorly when the task demands concentration.
More of my time now goes toward requirements, architecture, testing, and product judgment. Much of the implementation work I once completed by hand now goes to AI. There are tasks I could write faster myself, but if the requirement is sufficiently clear, I still let an agent attempt them first.
The increase in productivity is satisfying. Work that once required several days can now move forward significantly in one. Ideas I previously abandoned because I lacked time can become prototypes.
But that satisfaction does not feel as full as it once did.
When I used to write code, I would move through the problem layer by layer. Naming, abstractions, boundaries, and error handling all passed through my own thought process. My attention gradually settled into a state of flow.
Now an agent can produce a large implementation in one pass. I read it, review it, adjust it, and issue the next instruction. The pace is faster, but the flow is easier to break.
I still write some code deliberately to preserve my sensitivity to programming. Not because handwritten code is inherently better, but because if I spend too long away from implementation, I may lose the foundation I need to judge the quality of an agent’s output.
For me, the ability to write frontend code by hand can no longer serve as the professional advantage it once did. AI can generate comparable, and sometimes better, results in less time.
The abilities I developed over ten years have not all disappeared. But the most familiar and visible part of them is losing value quickly.
How Much Involvement Does It Take for a Work to Feel Like Yours?
If product outcomes were all that mattered, I should welcome this change without reservation.
I have always believed that a product’s value comes from whether it solves a real user problem. If AI can deliver features faster, increase test coverage, and reduce repetitive work, insisting on writing every line by hand may only delay the solution.
But outcomes are not the whole experience.
If AI builds something while I define the problem, direction, and major trade-offs, I can publicly call it my work. Internally, I find that harder to accept.
Too many details may never have passed through my judgment. The agent may have handled most of the abstractions and implementation. The work may never have been fully processed inside my own mind.
I do not believe creation requires typing every character by hand. Even without writing the code, someone who designs the main structure, develops the implementation plan, and participates in the critical details has still created something.
The difficult part is that this boundary keeps moving.
Today’s agents can already participate in requirements analysis, architecture, implementation, testing, and documentation. How much must a person still do before the resulting work belongs to them? If the human role gradually shrinks to selecting, approving, and correcting, is that enough to sustain the identity of a creator?
Losing a job, title, or existing competitive advantage is not what frightens me most. Jobs can change, and skills can be relearned.
What unsettles me is the possibility that the creative process I love will continue to shrink until only acceptance and review remain.
I will keep using agents. The value of their efficiency cannot be denied, and returning to entirely handwritten code is not an answer.
Still, when I delegate work to several agents and watch them generate code at a speed that would once have seemed impossible, I sometimes think about the child who secretly played with a computer at home.
He took apart the machine, reinstalled the operating system, and typed random characters into Dreamweaver. He watched the page change immediately. There were no users, job titles, or productivity metrics. He did not even know that he was touching code.
But he knew that something had passed through his own hands.
Today, I am still creating software. I simply do not write much of the code myself anymore. The productivity problem has been solved. What remains is more difficult:
When less and less of a work passes through my own hands and thoughts, what allows me to believe that it still belongs to me?
