Thoughts on AI Agent-Based Software Development

As of today, March 14, 2026, I have been developing software alongside AI Agent-based coding tools for roughly two years at most, or about one year at the shortest.
In this article, I would like to share my reflections on this experience.
Just a heads-up: this is a subjective reflection on what I've felt so far, and my views could very well change down the road.
What's Different
1. Decrease in Manually Written Code
As of now, less than 5% of the code committed under my name is actually written by me. I haven't measured this precisely. However, the absolute amount and the proportion of code I write directly are continuously decreasing, and I personally feel it is well under 5%.
I only write code manually when there is an issue with the code generated by the AI or when a part is completely missing. The important takeaway is that there is still plenty of room to reduce this proportion even further.
2. The Need to Create Your Own Workflow
As a software developer, and simply as a working professional before that, everyone likely has their own way of working. This can vary depending on the company, the team you belong to, your specific role, and your personal tendencies.
Alternatively, it might be influenced by the people you work with, and some of the habits you picked up from senior developers back when you were a junior might still linger. The sequence of receiving planning documents, analyzing, designing, writing code, and debugging can differ slightly from person to person.
Once this way of working is established, it is not easy to change. That's because it is the optimal method you have internalized over several years. I remember consciously trying to shift my personal development approach to TDD (Test-Driven Development) in the past. I read many books and actually introduced TDD to several company projects, writing test code right from the start. I went through a lot of trial and error back then, but that experience is still deeply ingrained in how I work today.
Even now, as we build software alongside AI Agents, establishing my own way of working remains incredibly important. The reason this is particularly crucial is that productivity can vary vastly depending on the approach. The difference in individual productivity when humans did everything manually, versus the productivity gap now when working with AI, are bound to be completely different in both scale and nature.
You can start with a very simple approach, such as running Claude Code, having it read a few code files, and telling it, "There's a bug here, fix it." However, going beyond that to systematize the entire software development life cycle (SDLC) and delegating much of it to AI is not as simple as it seems.
Therefore, simply being good at coding is no longer enough; the ability to translate rich experience across the entire SDLC directly into a system has become essential. What we are trying to achieve is not turning a baseline of 100 into 120 or 130, but rather turning 100 into 400 or 1000.
What's Better
1. The Joy of Product Development
I can feel the transition happening—from a software developer to a Product Engineer.
Whereas I used to handle only a fraction of the overall product creation process (Back-end), I am now involved in the entire process of building a 'product'. This brings a completely different kind of joy.
Previously, my main tasks were designing the back-end system, structuring the DB, and implementing APIs based on the spec documents written by the PM. I also had to discuss API structures and call timing with Front-end engineers. But things are different now. As an AI Product Engineer, I perform the roles of a PM, a Full-stack engineer, and partially a QA engineer all by myself.
I am directly involved in and contributing to the entire lifecycle: from identifying the problems customers are facing and brainstorming ideas on how software can solve them, to writing spec documents that translate the voice of the customer into concrete solutions, and finally building and verifying the actual program based on those specs.
This is only possible because AI Agent-based coding tools have reduced the need for human intervention in writing source code, drastically lowering the cost of coding. If a human had to build everything manually like in the past, operating as a one-person team like I do now would have been impossible even to attempt.
Designing systems and writing code are certainly ways of contributing to a product, but they are still just a part of it. When working as a back-end engineer, it wasn't easy to experience making a direct impact on customers. Operating as a one-person team now, I genuinely feel that I am delivering direct impact and value to the users.
2. Overwhelming Productivity Boost
Just a year ago, I thought AI could improve a developer's productivity by about 20 to 30%. But now, I'd have to say we've entered an era where 2x~3x, or even 10x, is entirely possible.
Currently, I use an AI Agile framework called the BMAd Method to conduct initial brainstorming, PRD writing, and architecture design entirely with AI. Based on this, I have built a Workflow using the Ralph Loop method, where the AI implements at least 90% of the entire feature from scratch. I run the Ralph Loop overnight to avoid hitting token limits, and when I come into work in the morning, I spend about 1~2 hours reviewing the generated code, filling in the remaining 10%, and then committing it. A task that used to take a week can now be completed in a single day.
Now, when discussing things with a PM, we don't rely on documents; we look at an actually functioning screen. This is because half a day is more than enough time to generate a spec document and build a prototype that works at a reasonable level.
What's Worse
1. Deterioration of Source Code Skills
This is undeniably clear. There must be a massive gap in source code writing skills between the "me" of one or two years ago and the "me" of today. While I wrote every single line of code myself up until two years ago, now... well, I don't even write 100 lines a day.
How should I put it—a kind of instinct? I can clearly feel it dulling—that intuition of knowing exactly when to use a specific function in one situation or apply a certain syntax in another.
2. The Burden of Code Quality Management
Managing the quality of code written by AI is harder than it seems. When people say AI writes code better than humans, what that really means is it writes code quickly to a level that satisfies the basic requirements (at least for now!).
To write code that understands the distinct characteristics of various company domains and considers the complex interdependencies with legacy systems, you must provide the AI with high-quality Context. You shouldn't provide too much, nor should anything be missing. The Right Context is always crucial.
If you only present requirements to the AI without giving it the proper Context, it can lead to code that is hard to maintain, and potentially pile up technical debt. For instance, a few months ago, I worked on a React-based Front-end module with AI. The features themselves worked fine, and my rough review showed it wasn't bad. However, the company's Front-end engineer gave me feedback saying it looked like code written by a Junior and suggested it needed more improvement. When I checked again, the approach to state management and the application of the design system were quite an old-fashioned style.
Conclusion
Regarding code quality management, I accepted the feedback I received ("looks like code written by a Junior") and improved my Workflow. When delegating tasks to the AI, I made sure to attach internal company guidelines—such as State management, Design system, and Styling conventions—to the Context. After this improvement, the issues of generating overly old-style code or referencing the wrong design system definitely decreased.
I plan to continuously refine it in this manner. Every change comes with pros and cons. We need to evolve AI-based software development by amplifying the pros and compensating for the cons.
As I build up this AI-based development method so efficiently, it also makes me wonder whether I, too, might be replaced someday. And perhaps, the job of a "Software Engineer" isn't disappearing, but rather transitioning into a different form (like a Product Engineer).
Since this change is inevitable, I believe we should embrace and enjoy it. Personally, I'm not entirely sure what will happen to the Software Engineer profession in 5 or 10 years. I just have this vague, optimistic hope that if I adapt to this change and keep living my life, things will work out fine in the end.
Comments (0)
Checking login status...
No comments yet. Be the first to comment!
