Three months ago, I made a proposal to the company.

I want to try handling everything myself—from product planning to development, QA, and deployment.

No PM, no Designer, no QA. As a back-end engineer, I was proposing to take responsibility for the entire A-to-Z of a product. The company accepted the proposal, and I am now working in a new way as an AI Product Engineer.

In this post, I candidly share why I made this switch, how I actually work, and what has worked well versus what has been challenging.

Why I Made the Switch

Background: Frustration with Product Release Speed

I have always been thinking about how to release products faster.

While working as a back-end engineer, I realized a certain limitation: no matter how quickly I built back-end server features, it didn't necessarily speed up the product release. This is because the back-end is only one part of the entire software product lifecycle.

My train of thought went like this:

"What are the ways to speed up product releases?"
"Developing the back-end quickly on its own won't speed up the launch."
"Then, wouldn't it work if I, as a full-stack engineer, built both the FE and BE quickly?"

As I was pondering these thoughts, new opportunities began to emerge toward the end of 2024.

Discovery: The Possibilities Opened by AI Coding Tools

From late 2024 to early 2025, I witnessed a rapid advancement in the performance of AI coding tools like Cursor and Claude Code. This was driven by the LLMs released by companies like Anthropic, OpenAI, and Google. It felt like their performance was improving almost on a weekly basis.

Earlier this year (early 2025), while taking a break from work, I studied React and Next.js to build a personal side project and a blog. Initially, my motivation for studying FE technology was purely to see if I could work as a full-stack engineer. In the process, I tried writing front-end code with AI and confirmed that AI is quite capable of writing FE code.

While I had previously used AI to develop Java or Python code for server functions, this was my first time seriously using AI for implementing UI-related features.

This led me to a thought:

BE by me, FE by AI → I can work as a Full-stack engineer.

Even though it was just a personal blog and a side project, I gained a bit of confidence and started wondering if I could apply this at work.

Experiment: The First Attempt as a Full-stack Engineer

I requested a transition to a full-stack engineer role at the company, and the CEO and team lead agreed. Starting with simple backlog items, I successfully developed and released several features.

I enjoyed this process quite a bit, and I gained the confidence that I could work as a full-stack engineer at a production level.

Insight: Discovering the Product Engineer Concept

At the same time, I had another line of thought.

Since I was interested in the development of LLM-based AI technology, I had been following related communities, where I discovered people working as Product Engineers. They weren't much different from me, but the difference lay in how they contributed across the entire product, going beyond just being a full-stack engineer.

I was deeply impressed. I believed that because Product Engineers utilize AI technology to its limits, continuing to study this field would allow me to maintain the most cutting-edge sense of applying AI to real-world work for tangible results.

The core insight was this:

If you utilize AI to its limits, one person can lead a team of AI agents to build an entire product.

The traditional division of labor remains, but with only one conductor. The era where this is possible has arrived. I wanted to test this new way of working to achieve the faster product releases that were the starting point of my concerns.

Decision: Working as an AI Product Engineer

I decided to combine my full-stack experience with the Product Engineer concept and work as an AI Product Engineer.

I proposed this direction to the company and received approval. Being a startup, they were open to efficient methods, and we decided to start small using Agile methods and gradually expand.

How I Work as an AI Product Engineer

BMAD-METHOD: An AI-Centric Agile Framework

I use an AI-centric Agile framework called BMAD-METHOD. BMAD-METHOD (Breakthrough Method for Agile AI-Driven Development) is an open-source AI collaboration framework.

When we simply tell ChatGPT or Claude to "make an app like this," the results are often flimsy. This is because AI, like humans, performs best when given a specific planning document and context.

I believed that rather than just using AI from scratch, using a framework that provides powerful instructions would maximize AI's performance.

The entire workflow is as follows:

Brainstorming → Brief → PRD → UX → Architecture → Epics/Stories → Test Design → Story Development → Code Review → Retrospective

Details can be found in the BMAD-METHOD GitHub repository.

It is integrated with Claude Code, so you can start working immediately by installing it in your local environment and running Claude Code.

Here are three core insights I've gained while using this framework.

Key 1: AI Asks, Humans Focus on the Essence

In the traditional method, humans repeatedly wrote, reviewed, and modified documents. In the current method, AI asks structured questions, and the human focuses solely on answering them.

For example, the Brainstorming stage proceeds like this:

The human inputs what difficulties customers are facing and what value they want to provide.
BMAD-METHOD recommends an appropriate brainstorming technique.
The LLM asks the human questions based on that technique.
The human thinks deeply from the customer's perspective and answers.
Through iterations, the document is completed.

The same goes for writing a PRD. When the LLM asks the human what inputs are needed for the core items of the PRD, the human thinks deeply and answers. Before you know it, the PRD is complete.

Result: Human-to-human communication costs are significantly reduced.

Previously, reading and understanding the plan written by a PM and then discussing it again with the PM to increase the level of understanding was very important at the start of a project. Now, that process simply doesn't exist. I can focus entirely on finalizing specs and writing documentation.

Key 2: Persona-based Agents Collaborate Like Experts

BMAD-METHOD loads different agents into the context for each stage:

Writing PRD → John (PM Agent)
Architecture → Winston (Architect Agent)
UX Discussion → UX Agent

(There are many more!)

It feels like collaborating with an Agile Master, a PM, and an Architect. Each agent has detailed instructions for their field, providing expert-level questions and feedback.

Result: I work alone, but I work like a team.

In other words, I (the human) become the lead of this AI team to make decisions, and the actual tasks are delegated to AI agents by role in a systematic manner.

For example, in the Architecture stage, an Architect agent named Winston analyzes existing source code modules and contemplates how to integrate the project. By giving the PRD and module paths to Claude Code and letting it analyze the source code for 5–10 minutes, a pretty good analysis comes out.

However, you shouldn't just accept these results blindly. You refine the document by reading the analysis and providing feedback on what parts are wrong or how they should be corrected.

Key 3: Coding Time < Planning/Design Time

The Dev Agent handles code writing. The human focuses on finalizing specs and document quality.

If the PRD and Architecture documents are well-written, the Epic/Story breakdown proceeds smoothly. Conversely, if there are gaps in the preliminary work, situations arise where you ask, "Why was this included?" or "Why was this missed?" If this process drags on, it might be better to go back to the PRD or Architecture stage and start over.

Result: Investing in preparation makes development faster.

I spend a lot of time on planning and UX design, and the time spent writing code has decreased significantly compared to before. For QA, I also leave TC (Test Case) writing to the AI, and I only handle the process of executing the TCs myself. When a bug is found, the AI handles the documentation and the fix.

Detailed Workflow

Here is a more specific explanation of how each stage proceeds.

Brainstorming

The project begins by inputting information about customer pain points and the value we want to provide. We go through a process of contemplating how different personas will perceive the project. Through this, the LLM gains a deep understanding of the project, and I organize my thoughts and crystallize them in my mind.

Brief

After the Brainstorming document is produced, we move to the stage of writing a brief.md document, which serves as an overview. It's a one-page document describing what the project is and why we need to do it. I read this document multiple times to ensure that my understanding of the project perfectly matches the LLM's understanding.

This document is short and punchy, enough to be used as an elevator pitch.

PRD

This is the most important stage. Excluding Story development, I spend the most time here. We define core items that make up the PRD, with the LLM asking for necessary inputs for each item and the human responding.

UX

If UX discussion is needed based on the Brief and PRD, we proceed with this stage. For projects requiring front-end feature additions or modifications, it's good to go through this process. I flesh out the user flows I had abstractly envisioned through discussions with a UX expert (agent).

The output is a 'Lo-fi Wireframe.' Since the product I work on is an HR SaaS (B2B) and the views aren't that complex, these wireframes often suffice instead of full design work.

Architecture

After writing the PRD, we don't start development immediately; instead, we go through a thorough preliminary preparation stage. Major technical decisions and system structures are determined here.

For Brownfield projects, we analyze existing source code modules and think about how to integrate this project. It's important to pre-determine which modules need to be involved.

Epics/Stories

Based on the PRD and Architecture documents, the project is divided into developable Epic and Story units. If the preliminary work was done well, this process flows smoothly.

Story Development

The stage where development can actually begin. We don't jump straight into code; we go through several set procedures:

Epic tech context: Writing detailed technical specifications for each Epic.
Create story: Writing detailed markdown files for each Story.
Story context: Consolidating all information the Dev Agent needs to refer to into an XML format.
Dev story: Performing the actual code work.
Code review: Verifying implementation, code quality, security, and test codes.

At first, I felt a bit frustrated with why such complex steps were necessary, but as I completed stories through this process, I began to feel the effectiveness of these procedures.

Tools

Coding: Producing PRD, Architecture, and Epics documents based on Claude Code + BMAD-METHOD. Using Anti Gravity (Gemini) for intermittent validation.
Design: Working with Lo-fi Wireframes for basic design. Using the Nano Banana Pro model in Anti Gravity for component placement based on actual web screens.
QA: Having Claude Code read TC documents and performing the flows via a browser. When bugs are found, Claude Code creates Jira tickets directly.

What Worked

Here is what I specifically did and what I felt went well.

Speed: Growth Curve by Project

I have completed a total of three projects so far.

1st Project

My first project as a Product Engineer.
Only about two modules needed modification, and the scope was very narrow.
- Specific feature details were mostly predetermined.
Felt no significant difference from the traditional method because the project was small.

2nd Project

Larger than the 1st, with more parts to modify.
- About five modules required changes; while the difficulty for each wasn't high, it was important to ensure no logic was missed.
Required a process of contemplating how to flesh out the UI/UX as a PM.
Became familiar with the BMAD Framework, making PRD and Architecture document writing smooth.
The actual source code work proceeded rapidly: half a day each for FE and BE.
Key: Communication costs between roles were significantly reduced.

3rd Project

Understanding service characteristics was key.
- Mostly modified scheduler logic on the back-end.
- Had to consider many parts, including types of schedulers, execution order, and calculation methods.
- Used Claude Code and Gemini to analyze existing service specs and source code to create a guide for scheduling. This document was used as a form of 'tacit knowledge.'
Project Scale
- About three modules were targets for code work, but it involved introducing a new table structure and inserting new logic into critical parts of the existing business logic.
- A significant amount of code was added to both the front-end and back-end.
Proceeded much faster and smoother than the first and second projects.
- Know-how and confidence are building up.

I progressed through three projects, starting from small scales and gradually increasing to medium scales. The biggest gain from this process, above all, was being able to build know-how and confidence.

Quality: Documentation Drives the Code

The quality of the documents produced is better than before. By using a single framework, the document formats and the types of documents produced are standardized.

Furthermore, I experienced that high-quality code is written based on high-quality PRD and Architecture documents. This is essential when working as an AI Product Engineer. This means that the more time you spend defining problems starting from customer requirements and pain points and writing documents on what and how to build, the more the actual coding time decreases and the code quality improves.

I also feel that the bug rate has decreased. The number of bugs found during QA has noticeably dropped. And even when bugs are found, fixing them takes less time because rich related documentation already exists.

Growth: From BE to the Entire Product

My perspective is broadening because I have to think from an overall service perspective, beyond just implementing features according to set specs.

Previously, while working only as a BE, other roles were a "gray zone" to me. Now, it feels like the fog is lifting a bit. I am identifying the difficulties each role faces in the entire product creation process and how best to work.

Because I build the product myself from start to finish, I feel a high degree of autonomy and achievement during the release process. I am experiencing higher job satisfaction than before.

What Didn't Work

Everything can't always be positive. Here are the things that were more difficult than expected.

Discovery of New Communication Needs

I realized that new types of communication are required.

A PM's major role is to discuss with customers, CS, and business teams to draw the product roadmap and communicate even the fine details of individual projects with external team members to decide on direction and details, which are then brought to the product team. Inside the product team, one only needs to worry about how to build the product.

As I took on the PM role as well, I was a bit confused about who to communicate with and how at the start of a project. For a BE, the main communication channel was the PM, but since I became the PM, that channel became much more diverse. I had to spend enough time talking with team members outside the product team at the starting stage of a project.

Because an AI Product Engineer handles the entire process alone, there's a risk of neglecting information delivery to other team members. In other words, other team members might feel like new features they didn't know about are being released.

Discussing the right content with the right people at the right time. I didn't "not know" this, but I came to experience it once again.

AI's Limitation: Injecting Tacit Knowledge

There is hidden domain knowledge that isn't captured in documents or source code. Providing this as context to AI isn't easy. It's easy to overlook its importance and omit it, or sometimes the fact itself might be missing.

For example, there might be a "Feature A" that was first introduced three years ago and has gone through a specific improvement process; often, only "humans" know this history-based information.

If this tacit knowledge can be properly injected into the AI, much higher-quality outputs can be achieved. I need to spend sufficient time in the preliminary stage thinking about and documenting this domain knowledge.

Individual Skill Limits: UI/UX

Personally, I am struggling a lot because I have virtually no experience in UI/UX design.

That's why I intentionally chose projects with a narrow scope and small UI modification ranges. I feel the need to gain experience and study in this area.

The Double-Edged Sword of Autonomy: Isolation

It's also true that I feel a slight sense of isolation along with very high autonomy.

However, since I personally prefer working alone, this feels more like a big advantage. But for someone who isn't like me, it might be difficult.

Also, I sometimes wonder if I'm relying too much on an open-source framework like BMAD-METHOD.

Lessons & Advice

Core Lesson: Preparation is Everything

Initially, it was very experimental, but after several projects, I've gained confidence that this is possible. By doing the work of other roles little by little, I've come to understand their pains and difficulties.

Mindset Shift

As a developer, I feel a strong desire to write code immediately, but to work properly as an AI Product Engineer, it is crucial to strictly follow the preliminary steps.

Furthermore, moving beyond internal product team discussions and sharing the nature of the project and how the service is being improved with the entire company to receive feedback is very important. I learned that I must give people enough time to think and provide feedback before the actual work starts.

Trade-off: Width vs. Depth

Since one person covers a very wide range, it is realistically impossible to dive deep into every area.

However, the expectation is that through collaboration with AI, one can reach a depth sufficient for building a product in each role. This is the main premise for trying this method in the first place:

I will be able to receive enough assistance from AI to try every task alone.

I must constantly ask myself if this premise is being satisfied.

Advice: Start Small and Don't Fear Failure

Where to Start

Start with a very small project (taking about 2–3 days).
It's important not to be averse to just deleting everything and starting over if things aren't going well.
- This is why leaving intermediate outputs and managing history is crucial (one reason for using BMAD-METHOD).

Mistakes to Avoid

Thinking you have to finish everything at once.
- If it doesn't work, just do it again. That's one of the reasons for using AI!
Large Commits.
- It's important to evaluate the AI's output and make small commits frequently. If you try to commit in large chunks, it's very hard to revert if the AI gets lost and works in the wrong direction halfway through.

Prerequisites

In my opinion, the conditions for working as an AI Product Engineer are as follows.

Skills

Essential Skill 1: Must have a basic understanding of Claude Code or other AI agent services (Codex CLI, Cursor CLI, Gemini CLI, etc.).
Essential Skill 2: Must know the entire product creation process and have an "understanding" of the essential tasks in each step.
Essential Skill 3: Software writing ability. You must be proficient in programming. Unless LLM performance improves significantly in the future, I believe it's currently too difficult for non-developers.

Personality

Someone who finds joy in solving problems that customers directly experience.
- If you're the type of person who finds more fulfillment in writing code than in solving customer problems, this might not be for you.
Someone who knows a fair amount about the entire product-making process.
- I don't think this method should be used when you are a junior or have just joined a company.

Organization

An organization ready to experiment with small-scale backlog items.
- Working alone actually requires support at the company and team levels. You need to consider if your organization is ready for this or willing to change.

Next Steps

I plan to release the current project and do 2–3 more medium-sized projects to gather more data. Based on this, I expect to share it with the team to make decisions.

Should we continue in this direction?
Is this method wrong and something we shouldn't pursue?
Or a third direction?

What I want to challenge is not small/medium projects but conducting a large-scale project in this manner. I am still wondering if a project with a 3–6 month scale can be done this way.

What I want to improve is increasing the "trustworthiness" of the AI's outputs (documents, decisions, source code). Increasing this number is the only way to raise the level of automation and ultimately productivity. I expect to increase this through improved LLM performance and agent system enhancements.

Closing

Thanks to AI tools, an era has arrived where one person can lead a team of AI agents and handle the A-to-Z of a product.

It's still in the experimental stage, and not everything is perfect. There are challenges like lack of UI/UX experience, difficulty in injecting tacit knowledge, and a sense of isolation.

But what is certain is that this method works. I have successfully released three projects, and the process is becoming faster and smoother.

I hope this post helps developers who are having similar thoughts.

Comments (0)

Checking login status...

No comments yet. Be the first to comment!

Building Products End-to-End as a One-Person Team

Comments (0)