Who takes care of the work that keeps coming back?

From Replit’s deleted database to the Base44 flaw: what AI agents must deliver, who can approve their work, and how to measure real productivity gains.

Nesibe | AI Governance Expert and Ruzgar “Mark” Imren

Nov 11, 2026

What happens when AI agents take over real work: who defines success, who approves the result, and how to measure what people can actually hand over.

Hello everyone,

Welcome to everyone who's joined us since the last edition! Many thanks to everyone who's been passing TechLetter along to friends and colleagues. It's always a real pleasure to think that something I've written here is being used in a conversation between people I've never met.

Quick update from my end: we’re launching new corporate training programs at STRATRI on responsible AI use, AI governance, and working with AI agents. If you’re planning training for your organisation, do get in touch. For speaking engagements and workshops, you can find me at nesibekiris.com.

The AI and workload discussion in the last edition generated quite a bit of interest, so I wanted to spend a little more time on it. We looked at the situation where one person saves an hour, and someone else does the corrections. But work was already waiting: things to fix, check, and follow up on that somehow keep finding their way back onto the same people’s lists.

This felt like a good opportunity to introduce you to Atlantic, this edition's sponsor. It investigates, fixes, and tests software bugs before an engineer reviews the changes. That gives us a concrete way to explore a broader question: what would AI need to take over before you could stop thinking about a task?

You’ll also find a code for TechLetter readers and details of Atlantic’s fellowship program below.

Enjoy the read,

Nesibe

AI at work: who owns the job once the app is actually working?

Working on the STRATRI website recently gave me a concrete reason to think about what we mean by “finished.”

As a non-technical person, I’ve been working on the AI Governance Maturity self-assessment. Someone completes the assessment, fills in their details, and receives a PDF with recommendations about where to begin.

At one point, I had a PDF to review while the form kept returning an error.

That made me think more carefully about what I was delegating. A finished design satisfies a design brief. Getting a useful report to someone who completes the assessment is a larger job, including the connections between those individual tasks.

Building has become easier. Knowing how to assess what you’ve built doesn’t automatically follow.

In July 2025, Replit acknowledged that its agent had deleted data from Jason Lemkin’s application database. Lemkin reported that the rollback worked, despite the agent’s claim that recovery was impossible. Replit also explained that development changes could affect the production application under the previous setup, and described its move to separate development and production databases by default.

The key change was what the agent could access. Separating those environments reduced the need for a person to police the boundary between trying something out and changing live data.

A different issue appeared at Base44. In July 2025, Wiz disclosed a vulnerability that let unauthorised users access private applications. Wix, which owns Base44, fixed the issue within 24 hours of disclosure and reported no evidence of prior abuse.

That was a platform flaw, not evidence that a customer prompted the system badly. A builder could have gone through the ordinary login process successfully without preventing unauthorized access.

Employees can now build useful tools outside the development process their organisation previously relied on. Security, release approval, and maintenance still need owners. Introducing customer data or connecting a company system should trigger a decision about review and support before others depend on the tool.

There is a staffing consequence too. If engineering and security teams are expected to support these tools, that work needs to appear in their capacity planning. One department’s new ability to build software can create responsibilities in another that were never part of the conversation.

Software debugging: why a small fix can take an afternoon

Most of this work arrives without the drama of a public incident. It turns up as a support ticket, often with very little information.

A customer paid but never received the confirmation email. Did the payment succeed? Was an email generated? Does the failure affect every order or only a particular checkout option? The ticket may simply say “email broken.”

Before writing a patch, an engineer needs to investigate and reproduce the problem. Afterward, they need to run the application and check the affected flow. A few changed lines can sit in the middle of a much longer assignment.

A study of 484 Microsoft developers reported that debugging took about 9% of their workweeks, with another 5% spent on pull requests and code review. These were self-reported findings from one company. What interested me was the preference for less debugging and more preventive work, including documentation, reviews, and mentoring.

A broken checkout needs attention now. The documentation that might prevent the next problem can usually wait until next week.

An agent that investigates the issue, prepares a change, and tests it could take over much of that groundwork. But I’d want the demonstration to continue beyond the first plausible patch. Can it run the application and recover from a failed attempt without repeatedly bringing the engineer back in? That is where we see how much of the job has actually been delegated.

AI governance: what the agent must deliver, and who can approve it

Before delegating a task, somebody needs to define a satisfactory result. “An email was sent” doesn’t establish that the correct customer received the correct order information. For my assessment, a successful form submission wouldn’t tell me who could access the information afterward.

Those conditions belong in the assignment. Otherwise, the reviewer discovers the missing requirements after receiving something described as finished.

Permissions should reflect the stages of the job. An agent could prepare a fix and test it in an isolated environment, while releasing it to customers remains a separate decision. The team needs to know what the system must achieve and where its authority ends.

The handover should include the problem, changes, tests, results, and unresolved issues. Without that evidence, the reviewer may have to reconstruct the investigation. It should also be clear what the evidence doesn’t establish: a functional test is not a complete security assessment.

The reviewer needs time and authority to act. Can they reject the result, request further investigation, or stop it progressing? “A human must review” is difficult to reconcile with targets that reward clearing the queue as quickly as possible.

Finally, reviewing a particular fix doesn’t make that engineer responsible for the agent’s permissions, ongoing evaluation, and failure handling. Assign ownership of the automated process separately from approval of its individual outputs.

Measuring AI productivity through the work people can hand over

I’d evaluate an agent on real tasks from the backlog, including unsuccessful attempts. Track where people intervene, what they investigate or retest, and whether resolved issues recur. A completion rate tells us more when we can see the human effort behind it.

And I‘d be particularly interested in where the intervention happens. If employees repeatedly have to supply the same missing context, the system may need better access to information. If they keep correcting what counts as success, perhaps the assignment was poorly defined. Those are different problems, and another training session for employees may address neither.

It is also worth examining the remaining work. If an agent handles straightforward cases, people may receive fewer tasks but a higher proportion of difficult ones. That could be a good use of their expertise. It could also mean that the old handling-time targets no longer fit the job.

A smaller queue doesn't necessarily mean a lighter day. Companies should review the remaining case mix before assuming they can reduce capacity or increase targets.

And if time is recovered, what will the team do with it?

Perhaps engineers can improve their tests or address a recurring design problem. Perhaps another worthwhile project is waiting. Either may be reasonable, but the choice should be explicit. Preventive work will struggle to happen if every available hour is immediately committed elsewhere.

Which recurring task would you most like to hand over, and what would you need to receive before you'd consider it properly handled?

If your team already uses agents, I’d also be interested to hear how the work has changed for the people reviewing their results.

Thanks for reading and for passing TechLetter on to friends and colleagues.

Until next time,

Nesibe

Discussion about this post

Ready for more?