Before AI, the software delivery process I knew had a familiar rhythm.
Someone in product or project management would bring forward a problem or a feature. Business priorities and technical debt helped determine what came next. Design and development would take the work into a two-week sprint, with QA testing along the way and bugs being fixed before the demo.
At the end, the team would show the committed features to the product owner and stakeholders. If everything went smoothly, the changes would be merged and moved to staging. If something needed fixing, that happened first. Production came afterward, perhaps on a Tuesday evening with DevOps helping with the release.
That Tuesday detail sticks with me. Delivery had a place in the calendar. Different people carried different parts of the process, and getting something live meant bringing those parts together.
I’m building Tabwar, a browser extension that saves tabs into project workspaces so I can switch between projects without keeping everything open. Building it with AI agents, I can see those roles coming together around one person.
I can define the problem and scope, work through the design, ask an agent to implement it, test the result, review a demo, request fixes, and prepare a release. The path through staging and production can sit within that same workflow.
The product manager, product owner, designer, developer, tester and release coordinator become responsibilities I move between as the work progresses. AI helps me perform work across those responsibilities. I still have to decide what deserves attention and whether the result is good enough to continue.
The handoffs get closer together
In the process I described, an idea moved between people and disciplines. A question might become a ticket, wait for clarification, return to design, and then go back into development.
With an agent beside me, I can inspect an implementation and change direction within the same working session. A design decision can become something I can use, which gives me another question to ask or another assumption to test.
Tabwar has already given me an example. The first alpha passed its automated checks. I installed it, saved a workspace with 22 tabs, created an empty workspace, and switched between them a few times. My tabs disappeared, and the interface showed a switch needing attention.
That gave the next piece of work a very concrete shape. The builder investigated the failure, reproduced a problem involving restored pages that were still loading, and added a fix with regression tests.
The loop included implementation, testing, personal use, a bug report and another implementation. My own browser session supplied evidence the initial automated journey had missed.
What happens when you demo to yourself?
The demo changes too. I can ask an agent to show what it built, try it, and decide what needs to happen next. There is no need to wait for the end of a two-week sprint to have that conversation on this project.
But reviewing my own product brings a question: how do I get enough distance from the thing I asked for?
A separate tester or stakeholder brings another perspective. They can misunderstand a flow I thought was obvious, challenge an assumption, or use the product differently. When I take on several roles, I need to make room for those different perspectives in the way I review the work.
The missing tabs made that practical. A working screen and passing tests were useful progress. Trying the extension with my actual tabs exposed another part of the problem. Further users will bring situations I have not tried myself.
A shorter loop still needs decisions
This connects to another question I have been exploring: what is a sprint when AI agents do the implementation?
For Tabwar, I asked for a plan built around bounded agent sessions. That plan still has places where work depends on me: confirming behavior in my browser, deciding unresolved product policies, and reviewing the result.
Those responsibilities become easier to see when the same person is carrying the idea through the whole cycle. I can move between defining, designing, building and testing much more directly. I also need to recognize which role a particular decision requires.
For now, Tabwar is a small product I am building around my own needs. It gives me room to try this workflow and observe where it works. The next challenge is to keep enough care and independent feedback in that faster loop as the product grows.
