AI-Assisted Development: A Merged PR Is Not a Fixed Bug

What an early experiment with an AI maintenance bot is teaching me about delegation, verification, and engineering leadership.

Updating a contact should not erase a phone number you never asked to change.

Yet that is what my maintenance bot found in Scheduled Smiles. Through the interface used by AI assistants, an update that omitted the phone number could clear the value already stored. The requested change could succeed while unrelated information quietly disappeared.

It was a real bug that my exploratory testing and the existing automated tests had missed. The bot then coordinated a fix with a Cursor agent and followed it through review and verification in the development environment.

That follow-through is the reason this experiment interests me. Faster implementation is useful, but maintaining a product also requires someone to notice problems, investigate them, move fixes forward, and check the result. AI assistance is beginning to help me delegate that continuing responsibility.

Scheduled Smiles helps busy people remember occasions and arrange e-cards, mailed cards, and flowers. I develop it when time allows, alongside my full-time work running Trificient Digital, a technology strategy consultancy. It is both a product and a practical setting for exploring how AI changes software engineering.

This is the next step in the experience described in my first article on AI-assisted coding. As of October 20, the maintenance experiment is only about three days old. There are already useful findings, and plenty still to learn.

The work that competes with the next feature

An alert needs investigating. A build fails. A fix is ready, but someone needs to review it. After deployment, someone needs to check whether the original problem has actually gone away.

Each task may be small. Together, they require sustained attention, especially when the same person is responsible for deciding what to build next.

Grok Bot was a natural fit for a practical reason: access was already included in my Cursor subscription. That was the main reason I started using it. It also lets me maintain multiple bots with distinct roles, personalities, and ongoing context. My maintenance bot and social media manager can each have their own responsibilities and working style.

The connection to Cursor is especially useful here. In my setup, Grok Bot can communicate directly with Cursor agents running under the same user account, delegate implementation, and follow up on the work. That makes it a convenient extension of the development workflow I already use. Cursor describes the subscription access and persistent bots in its Grok Bot overview.

My starting request to Grok Bot was to watch alerts from the Azure hosting environment and coordinate fixes. As that became useful, I expanded the role to exploratory testing and then to managing the bugs it discovered. Cursor agents handle the code changes and explain the codebase. Grok Bot keeps the maintenance work moving between those steps.

New features remain a direct collaboration between Cursor and me, from discussion and planning through implementation. Giving maintenance a separate owner creates room for that work to continue without requiring me to personally initiate every investigation.

It also gives the bot a meaningful finish line. Finding a bug is useful. Following it until the corrected behavior has been checked is more useful still.

Verification belongs after deployment, too

The contact-update issue illustrates why that finish line matters. A code change and a passing test can support a fix, but the behavior that matters is what happens when the application is used.

In this workflow, Grok Bot coordinates the implementation and tests with a Cursor agent, reviews the proposed result, and brings the pull request to me. I inspect the changes and decide whether to approve. The required automated gate still has to pass before the change merges.

After deployment to dev, an Azure DevOps notification brings Grok Bot back into the process. It tests the fix and related behavior, records evidence such as screenshots on the bug, and reports the result. If it finds a further problem, it coordinates another PR with the same agent.

The pipeline may already have marked the work item Done. That status is useful for tracking delivery, but the subsequent check answers a different question: does the running application now behave as intended?

For a contact update, that includes preserving information the user did not ask to change. For a shared UI component, it includes checking other places where the component appears. Desktop and mobile behavior both matter.

Screenshots make the findings reviewable. They show what was observed, without replacing tests or proving that every possible interaction is correct.

More testing still needs product judgment

Exploratory testing starts with a goal: schedule an e-card, edit some text, update a contact. The bot tries inputs and routes through the product, looking for behavior that prevents the goal or produces an unexpected result. Another finding involved a calendar component changing dates when they were typed without slashes.

Some failures are clear. Others require an understanding of what the product is supposed to do.

When Grok Bot is unsure, it consults Cursor, which can examine plans, recorded decisions, and code comments. If those do not resolve the question, it comes back to me. There is no comprehensive specification that settles every case, and agreement between two agents is not proof that their interpretation is right.

This is where engineering and product experience remain valuable. The bot can explore more than I have time to check personally. Deciding whether a surprising result is a defect, an intentional tradeoff, or a missing requirement still needs judgment.

The same applies to the fix. Shared validation should behave consistently whether a user comes through the website or an AI assistant. Repairing one entry point while leaving another with different rules would miss the broader problem. Expectations about reuse and consistency therefore need to travel with each task, through explicit instructions and repository rules.

Delegation changes the management work

Having several agents working at once makes coordination decisions more visible. At one point, ten PRs were in progress. That creates capacity, but also review work, overlap, and queues.

One adjustment was to group related small fixes into a single PR where appropriate. Giving every tiny issue its own agent and change introduces overhead and can increase the chance of overlapping edits. Larger changes still need separate treatment.

Another adjustment concerned when my review could begin. Grok Bot was waiting for the gate, which runs sequentially in this project because concurrent runs would interfere. That also left my review waiting in the queue.

I asked it to have Cursor agents run the tests in their own cloud environments first. Successful results can be enough for me to review and potentially approve a change while the required gate remains ahead of the merge. Ready for review and ready to merge are different milestones.

These adjustments draw on the same skills used to manage engineering work: choosing sensible task sizes, identifying real dependencies, communicating standards, and deciding what evidence supports a decision. Those skills remain useful when AI handles much of the execution.

The next test is whether it earns its place

Three days is enough to find promising examples. It is too soon to judge lasting improvements in reliability or the amount of supervision this will require.

Over the next couple of months, the useful questions are practical. Does the bot keep finding genuine bugs? How often do fixes need another attempt? Does it reduce the attention maintenance demands, or move that effort into reviewing its decisions?

Those are the findings I want to return to in a follow-up article. More agent activity alone would not make the experiment successful. A more reliable product, with less work left for me to chase, would.

The missing phone number gives this experiment a concrete starting point. The workflow found an unintended loss of information and carried the correction through to a check in dev. Repeating that kind of follow-through reliably is the responsibility I am trying to delegate.