Who maintains the software AI helps us build?

Imagine arriving at a fitness class with a booking confirmation on our phone, only to find that the last place has also been promised to someone else. The instructor has a full room, the receptionist has two confirmations, and both members have arranged their evening around being there.

In this hypothetical example, a small team builds a mobile app with AI assistance, giving members a class schedule, bookings, payments, reminders, and a screen for their membership. The gym gets an easier way to manage attendance, and the team gets the satisfaction of seeing something it built become useful.

Before the app, let’s imagine the receptionist taking bookings over the phone and checking names against a shared list. Now members can reserve a class after the gym has closed, instructors can check attendance before arriving, and reception spends less time answering routine questions. There is a good reason to build this, and a good reason for the team to feel pleased with the first release.

As those habits change, the app becomes part of how the gym runs. When two confirmations arrive at the desk, the team has to understand what happened and help the people affected while the rest of the evening’s bookings continue. The gym has accepted an ongoing responsibility with that first release, and someone needs the time and authority to carry it.

The first booking creates a promise

For the first release, we ask AI to help implement the booking flow, and we can follow the result from choosing a class to receiving a confirmation. As we review it, we also need to decide what that confirmation promises. In this app, let’s make the rule explicit: a confirmed booking reserves one place, and the total number of confirmed bookings must stay within the class capacity.

To investigate the opening scene, suppose we discover that both requests checked availability before either had reserved the remaining place. Each saw one place available, so both received a confirmation. The number on the screen was accurate when it was read, but the act of taking the place was not protected against another request doing the same thing.

Our repair would need to make claiming that place a single protected operation in the service that owns the bookings. One request can succeed, and the other must receive a clear response that the class is full. We would also check what happens when a phone repeats the same request after losing its connection, so one attempt cannot quietly become two bookings. Those cases give us concrete behavior to verify before accepting a proposed fix.

AI can help us propose those tests and inspect the implementation, but we still need to connect them to the gym’s actual rules. If the same mistaken assumption shapes the implementation and its tests, agreement between them gives us limited reassurance. We need to compare both with the behavior we agreed to provide.

These responsibilities belong to software development regardless of who writes the code. With AI, I would make explaining the proposed change part of accepting it, including where capacity is enforced, how a repeated request behaves, and what evidence shows the original failure is now prevented. The explanation should point to the implementation and a test we can run. That gives the next person something they can inspect when another feature touches bookings.

A payment problem reaches the front desk

A few weeks into our hypothetical launch, a member pays for a class and receives no booking confirmation. The payment provider records a successful charge, while our app has no completed reservation. The member tries again because there is nothing on the screen that explains what happened.

The earlier capacity fix still matters: it should prevent us from giving this member a place that someone else has already taken. We now have to reconcile two parts of the system that disagree about how far the booking progressed. A successful charge tells us about the payment, while a confirmed reservation tells us whether the member has a place.

Before changing the code, we need to establish the state of that transaction. We would want a reference connecting the booking attempt to the payment, a way to find other attempts in the same condition, and a recovery process that avoids charging the member again. Someone also needs authority to decide what happens if the class is now full, including how the customer gets a refund and an explanation.

This is where monitoring becomes part of customer care. Google’s guidance on monitoring distributed systems distinguishes what is broken from why it is broken. For our app, we would apply that distinction by detecting paid attempts without completed bookings, then using the recorded events to investigate the cause.

An AI assistant could help trace the relevant code and propose a repair. We might also ask it to draft a way to find the affected records, then inspect the selection before allowing any changes. Updating a live booking or initiating a refund deserves a separate decision from reading the records, with a clear account of what was changed and a check of the result.

Meanwhile, the receptionist needs an answer they can use without interpreting technical logs. In our example, a small support view could show that payment was received, the reservation is unresolved, and a named person is investigating. That gives reception something useful to tell the member and helps the next shift continue the conversation without starting again.

After the immediate case is resolved, the team can add a test for this partial failure, a way to detect it, and a short recovery procedure. That work needs a place in the schedule. If everyone is already committed to the next feature, we need an explicit choice about what waits while we finish the repair and make it usable by the people supporting the gym.

A new policy meets existing bookings

A few months later, the gym asks to require cancellations at least twelve hours before a class, up from six. At first glance, we have a number to change and some wording to update. Existing bookings give that request a history we need to consider.

For this example, suppose the gym decides that bookings already made keep the original terms. A member who booked before the change and cancels eight hours before the class would still be within the old deadline. Someone who booked under the new terms and cancels at the same time would be too late. Both outcomes follow the gym’s decision, and reception needs to be able to explain the difference.

We now need to retain which terms apply to each booking and show the correct deadline when a member opens it, including on an older version of the mobile app. The support view from the payment incident has another useful job: showing which policy applied when the booking was made.

We can give AI a much clearer task once that decision exists. A request to increase the required cancellation notice from six hours to twelve leaves the treatment of existing bookings unstated. A useful instruction also carries the decision to preserve their terms, the two eight-hour examples, and the requirement to show the applicable deadline. We can then review the generated change against something more complete than the updated number.

I would keep a short decision record beside the implementation, explaining why the old terms remain and how they are represented. A future maintainer should be able to read that record before simplifying what might otherwise look like unnecessary complexity. The members who booked under those terms still need the distinction to survive the cleanup.

An update has to live alongside older versions

Later in the year, imagine that a phone operating system update exposes a problem in how our app handles reminders. Bookings still appear in the app, but affected members stop receiving the reminder they have become used to. A missed reminder brings the cancellation policy back into the conversation, because a member may discover the booking after their deadline has passed. The gym needs to decide how it will respond while the team investigates.

We reproduce the issue and prepare a fix, while some members continue using an older app version and others install the new one. The booking rules and policy decisions we have accumulated still need to work across that mix.

Our release plan needs to account for that overlap. We would check the affected device behavior, test the versions we still support against the service, and decide how to detect a deterioration after release. Google’s guidance on canary releases describes evaluating a change on a limited population before expanding it. Where our distribution tools allow it, that gives us a useful approach to reducing the reach of a faulty release.

We also need to be precise about recovery. Stopping further distribution does not remove an update from phones that already installed it. Depending on the fault, we may need a compatible service change, a way to disable the affected feature, or another app release. Those options deserve consideration while we still have time to choose between them.

Someone must also have the access and knowledge to build, sign, distribute, and monitor the fix. The organization needs control of those accounts and a second person able to use the process. A working patch becomes useful to members when we can actually get it onto their phones.

There is a quieter form of this work as well. In our plan for the app, we would reserve time to review the libraries and external services it depends on, test upcoming changes, and keep the release process working. We can ask AI to help assess an update and propose the necessary edits, while still deciding what to change together and how to verify it. That time belongs in the cost of running the app, alongside hosting, support, and the next feature.

The next maintainer inherits our decisions

Near the end of this imagined first year, the original developer moves on. Another developer takes responsibility for the app, with an AI assistant available to help explore the code. Their first task is to add a waiting list for classes that are full.

To work confidently, they need to understand how a place becomes available, which member gets offered it, and what happens if that offer expires. The waiting list now meets everything the team has learned: capacity must remain protected, an unresolved payment needs careful handling, and a cancellation must follow the terms attached to its booking.

Suppose the new developer asks an AI assistant to simplify the cancellation code before adding the waiting list. Two policy paths may look like duplication until the earlier decision is available. We should give the assistant the decision record and the tests preserving the old terms, then check that its proposal keeps those commitments. A record sitting elsewhere in the project helps only when the person or assistant making the change actually consults it.

This is where the work left behind becomes valuable. The incoming developer can investigate the payment failure using the recovery procedure, explain the two cancellation windows from the decision record, and practice a release using the instructions. We can ask them to trace one booking and take a small change through a test release while the original developer is still available. The questions they encounter show us what the handover still needs.

For this app, I would make ongoing ownership visible in a few practical commitments:

• A named person owns the service, with a backup who can release a fix.
• The team keeps the booking and payment rules alongside tests that exercise them.
• Support can identify affected members and follow an agreed recovery process.
• Maintenance has time allocated for dependency updates, device testing, and changes to external services.
• Each proposed feature includes the work needed to support it after launch.

Several of those responsibilities may belong to the same person in a small team. They still need time, access, and agreement from whoever decides what the team works on. A named owner can coordinate that work, bring an unresolved decision to the gym manager, and make sure a customer issue reaches someone who can act. The backup makes that arrangement workable when the owner is away.

For this waiting-list request, I would include the effort to operate it in the conversation from the start. A waiting list needs rules for offers and expiry, support for members who miss an offer, and maintenance when the booking flow changes again. We may decide that the benefit justifies all of that, or keep the first version smaller so the team can support it properly.

Before adding another feature, I would want us to walk through one existing booking together, from the member’s tap to the instructor’s attendance list, and explain how we would help if any part went wrong. That is a useful way to see what we understand and where we still need to do some work.

Let’s return to the reception desk a year later. Two members try to reserve the last place, and our corrected booking flow confirms one while telling the other that the class is full. If a payment remains unresolved, reception can see its status, explain the next step, and contact the person responsible for it.

The instructor can get on with the class, and the member has someone who can help. That is the outcome I would want the team to keep building toward, with AI helping us do the work and people able to stand behind what the app promises.