You built an internal tool — or inherited one — and now you’re responsible for keeping it working. Maybe it’s a Google Apps Script that generates the weekly report. Maybe it’s a Zapier automation that routes leads from the website form. Maybe it’s a simple web app someone built last year that occasionally breaks in mysterious ways. You don’t have a developer on hand for every small fix, and escalating every minor issue through an IT queue isn’t practical.
AI tools have changed what’s possible here. Not every maintenance task requires developer expertise, and AI assistance makes the manageable ones considerably more manageable. Here’s a realistic guide to what you can handle yourself and what you genuinely need a developer for.
Understanding the Tool Before You Touch It
The first maintenance task is understanding what you’re working with. Before making any changes — even small ones — get AI to explain the tool to you. Paste the code into Claude or ChatGPT and ask: “Explain what this does, what data it reads and writes, what external services it connects to, and what would break if the input data format changed.” That explanation is your maintenance manual. It tells you what the tool does, what it depends on, and what the consequences of changes are — all things you need to know before touching anything.
If the tool was documented by whoever built it, read the documentation first and use AI to fill in the gaps. If there’s no documentation, the explanation you get from AI becomes the documentation — write it down somewhere accessible before you make any changes, so you have a record of what the tool was doing before the modification.
📊 Common Maintenance Tasks: What AI Can Handle
| Metric | AI handles reliably | Needs developer review | Requires developer |
|---|---|---|---|
| Explain what a script does | ✓ Yes | ||
| Fix a broken formula or simple bug | ✓ Usually | Complex logic | |
| Update field names or labels | ✓ Yes | ||
| Add a new column or output field | ✓ Often | With side effects | |
| Fix a broken API integration | ✓ Sometimes | Auth / security issues | |
| Migrate to a new data source | Simple cases | ✓ Usually | |
| Performance optimisation | Basic cases | ✓ Usually |
Diagnosing What Broke
Most maintenance requests start with “it’s broken” rather than a specific error description. The first step is getting a specific error. Copy the exact error message — not a paraphrase, the exact text — and paste it into AI with the relevant section of code and a description of what the tool was doing: “This Google Apps Script was working until yesterday. Now when it runs, it produces this error. Here is the relevant function. What’s wrong and how do I fix it?”
Common causes of internal tool failures that AI diagnoses reliably: a column name or sheet name changed in the underlying spreadsheet (very common), an API the tool calls changed its response format or authentication requirements, a permission expired, or the data the tool receives no longer matches the format the code expected. AI identifies which of these applies quickly from the error message and code context, and usually provides a specific fix.
Making Small Changes Safely
The most common maintenance request after “fix this error” is “add this feature” or “change this output.” For small, clearly defined changes — adding a new column to a report, changing which email address receives a notification, updating a category list — AI can write the modification reliably. The prompt structure that works: “Here is the current code. I want to add [specific change]. Show me only the modified section and explain what you changed so I can find the right place to update it.”
Requesting only the changed section rather than a full code rewrite reduces the risk of unintentional modifications elsewhere in the script. And testing the modification on a copy of the tool before applying it to the live version is non-negotiable for any change that affects data or sends external communications.
Managing Dependencies and External Connections
Internal tools often depend on external services — APIs, third-party apps, cloud platforms — that change independently of the tool itself. API authentication methods get updated, service endpoints change, rate limits get modified. When these external changes break a tool, the error often looks like an authentication failure or a malformed response, and AI can usually diagnose the specific issue from the error message and the code’s connection logic.
The longer-term maintenance strategy for tools with external dependencies is to document those dependencies explicitly: which external service does it connect to, what credential or API key does it use, when does that credential expire, and how do you get a new one? This information is almost never documented when a tool is built, and the absence of it is what turns a routine maintenance task into an emergency when a credential expires at an inconvenient time.
🛠️ Sustainable Tool Maintenance Without a Developer
Building a Maintenance Knowledge Base
The most durable solution to the “no developer on hand” problem isn’t a person or a tool — it’s documentation. A shared document that records every internal tool, what it does, what it connects to, the last time it was updated, and who to contact if it breaks fundamentally changes the maintenance situation. New team members can understand the tool landscape without tribal knowledge. AI-assisted diagnosis starts from a better position when there’s documented context to work with. And the inevitable “why is this thing doing that?” conversation with a developer is much more productive when you can share accurate background rather than reconstructing it from memory.
Invest the time to document your existing tools once — even briefly — before the next maintenance event rather than after. The documentation is most valuable before things break, not after.
The businesses that maintain internal tools most sustainably aren’t those with the most capable AI — they’re those with the clearest documentation, the most disciplined testing practices, and the most honest assessment of when a tool has outgrown what AI-assisted maintenance can support. AI is a force multiplier for good maintenance practices, not a substitute for them.
Start with a single tool audit this week: pick one internal tool your team uses regularly, spend twenty minutes getting AI to explain it, and write a one-paragraph description of what it does. That’s the beginning of a maintenance knowledge base — and the beginning of a much more manageable relationship with the tools your business depends on.
A tool that works reliably and is well-documented is an asset. A tool that works but nobody understands is a liability waiting to become a crisis. The documentation investment is small and the return, when the inevitable maintenance moment arrives, is significant.
Knowing When to Escalate
AI-assisted maintenance has real limits, and recognising them prevents the pattern where a tool accumulates patches until it’s more brittle than it was originally. The signal to stop iterating and get proper developer help: the same issue keeps recurring even after AI-suggested fixes, the tool’s behaviour is becoming inconsistent in ways that are hard to predict, or the fix required involves architectural changes that go beyond modifying specific functions. A tool that needs architectural work will not be reliably maintained through AI-assisted patching — it needs a rebuild, and attempting to maintain it indefinitely through patches is more expensive than getting the rebuild done properly.
For tools that are genuinely business-critical — ones where downtime directly affects revenue or operations — establishing a relationship with a developer who can handle urgent fixes is worth the investment regardless of how capable AI-assisted maintenance has been so far. AI maintenance is most sustainable for tools that are useful but not critical, where a broken day or two is an inconvenience rather than a crisis.