The Hidden Work Behind Building an App With AI Coding Agents

Signup Write New Story The Hidden Work Behind Building an App With AI Coding Agents by Paul Gendek by Paul Gendek | @ paulgendek Senior Staff Engineer

I returned to a browser music project in September 2026 after its initial feature work had spent months in the background. AI agents made it possible to coordinate implementation, checks and browser validation in parallel. That changed the work I needed to do: keep the product direction clear, make physical-device findings part of the requirements and organize a review queue I could manage.

I am the creator of Mock Band and have a vested interest in the project. AI tools drafted this article from my original interview and the current case study. Agents implemented product changes and ran automated checks; I owned product direction, requirements, physical-device acceptance testing and merge approval.

The project began with a small interruption in something I enjoyed. When I was jamming alone on guitar, changing a metronome or backing groove meant stopping, reaching for the laptop and then trying to recover the idea. With bandmates, I could call for a new key or signal a change while keeping my hands on the instrument.

In a note dated September 17, 2023, I described choosing drums, bass and guitar accompaniment, repeating a groove and reshaping it through follow-up instructions. A footswitch would activate voice listening. I named the project Mock Band and sketched logo ideas on graph paper.

The player would supply the riff and direction. The software would supply an adjustable rhythm section. I wanted deliberate control of accompaniment, not a system that listened to a guitar and automatically followed its performance.

That was a product idea before it was an implementation. The earliest preserved repository commit is from August 2025, although local work may have preceded it. The first product effort took place during parental leave. Repository history supports early Cursor use and later Copilot involvement.

My recollection of that period is prompting the implementation rather than manually writing source code. The contribution I can clearly claim is the concept, platform choice, brand, requirements and acceptance testing. Naming those responsibilities precisely makes the development story easier to assess.

One of the most useful findings came from a purchased Bluetooth footswitch. The interaction had assumed hold-to-talk. The physical device behaved as a toggle.

I could not solve that mismatch by asking whether the code looked plausible. I had to try the switch, describe what it did and feed the result back into Cursor. The interaction was refined around a tap that starts listening while recognition is awaited. It took debugging and repeated manual testing to get it usable.

Recalling scenes with the footswitch was a particularly satisfying early result for me. That is an account of using an earlier build, not a promise about every controller or the current release.

The experience clarified a responsibility I still had even when implementation was assisted. A requirement about a physical gesture has to survive contact with the physical object. The software can consistently implement an assumption that the device immediately disproves.

Life pushed the project into the background after the initial feature work. There was later maintenance, including a security update. I returned in September 2026 as musical and creative activity picked up toward fall.

With Codex, I could coordinate background tasks across implementation, automated checks, browser validation and operational setup. I no longer had to wait for one closely supervised thread before another task could begin.

That gave me a different workflow, but it also created review pressure. More work could arrive for my attention, and some fixes caused regressions. The existence of an agent-produced change did not settle whether I wanted it in the product.

I required QA steps in pull request descriptions and retained human merge approval. GitHub's review documentation describes the practical distinction between commenting, approving and requesting changes. In my workflow, the merge decision remained a separate responsibility from producing the proposed implementation.

When the queue became overwhelming, I asked for related pull requests and manual checks to be combined into batches. The improvement was a review process I could manage. I did not measure a productivity multiplier, so I would not turn that experience into a claim about how many times faster a model made me.

The current product uses React and TypeScript for its interface and state. Text and recognized speech share a command vocabulary, while mapped MIDI actions connect to state and scene handlers. An audio bridge passes changes to an AudioWorklet, which renders drums, bass and rhythm accompaniment and handles timing.

AudioWorklet's separate audio execution context helps explain why interface rendering and musical timing have distinct responsibilities. Knowing that an architecture contains those components is still different from accepting how it feels during practice.

Musical changes can queue for beat or bar boundaries. Scenes and preferences stay in the browser, with JSON backup and import. These choices create real review questions: does the interface make a pending change understandable, and does a player know where a saved configuration will be available?

Some of those questions can be checked through software behavior or a browser inspection. Some require listening. A physical-controller question requires the relevant hardware. A question about useful practice needs someone to practice.

Agents handled automated unit tests and other validation. I supplied manual acceptance testing and merge decisions. That does not mean I manually tested every pull request, or that the maintained release gate certified every legacy test and device combination.

I also reported a successful live MIDI output test through an IAC bus into Logic Pro on September 29, 2026. It supports that particular route. It is not proof that every physical MIDI receiver works.

The most useful review question became specific: what does this check establish, and what remains outside it? Without that boundary, an implementation result can silently become a broader product claim.

The original early-access gate asked people for an email before they could use the app. The list was not growing, and I felt that collecting addresses offered little value while potentially discouraging use. During the September refresh, I chose immediate access. Updates became an optional, confirmed signup.

That was a product decision. Agents could implement it, but they did not establish whether it was the right tradeoff. I needed to decide what mattered at this stage and accept what I was giving up.

It also changed what I wanted to learn. Opening an app is different from starting audio, and starting audio is different from a useful musical session. Even uninterrupted playback does not demonstrate that someone played guitar or found recurring practice value.

Product and distribution were changing together, so I cannot claim that removing the gate caused growth or improved retention. The early playback evidence is observational.

The same discipline matters when describing the work. HackerNoon's second-human rule treats another person's review as a step before ordinary publication. That offers a useful parallel to the review boundary in my project, without making editorial review and software acceptance identical.

In either setting, production and acceptance are different events. An article can sound convincing without its claims being established. A change can pass an automated check without its musical behavior being acceptable. Another review step is valuable only if the reviewer knows which judgment it is supposed to supply.

For the current version, I have not yet established a regular practice routine beyond QA. An original-riff jam-session reel and voluntary practice trials are next steps, not completed outcomes. I cannot claim learning gains, sustained use by guitarists or a broader hardware pass.

The project referenced here is Mock Band, an adjustable browser backing band. It is free to use without an account, with voice and MIDI capabilities subject to browser and device limits. That describes its current access model, not evidence that it has solved the practice problem for other musicians.

Returning to the project gave me more implementation capacity and a clearer view of the work that stayed with me. I had to choose the requirements, confront physical-device behavior, keep review manageable and decide what was ready to merge. The next milestone is evidence of recurring musical value. I want the review process to leave enough room to learn that.

Disclosure: I created Mock Band and have a vested interest in it. This is an AI-drafted account based on my original interview and the current case study. I directed the product and retained merge approval; agents implemented changes and ran automated checks.