Use AI to take the drag out of small app upgrades

What shipped

Simon Willison published a short note on upgrading llm-anthropic to work with the newer Anthropic Python library. The important detail for an SME is not the library itself. It is the pattern: give an AI coding assistant the migration guide, the relevant repository and a clear instruction to get the tests passing.

That is a practical workflow for a common problem. Many Irish SMEs have one or two small internal tools that nobody wants to touch. They might run a booking process, prepare stock reports, move files between systems or support admin work that used to live in a spreadsheet. The tool works, so it is left alone. Then a library, API or framework changes. The upgrade is delayed because someone has to read the release notes, find the affected code, make trial changes and check what broke.

A small application dependency upgrade assistant does not remove the developer or technical owner. It gives them decision support. It reads the migration guide, release notes and selected code files, then drafts an upgrade plan, suggested code changes and a test checklist. A named person then reviews, edits, tests and approves the work before anything is deployed.

The human review step should be explicit. I would call it the Technical Owner Review. No generated change goes into production until the technical owner has checked the reasoning, run the tests and approved the release through the normal process.

Who should care

This matters if your business owns a small internal application but does not have a full software team around it. That is common in SMEs with 10 to 250 people. The system might have been built by a former employee, a freelancer or a small agency. It may sit quietly in the corner, but it still supports operations, IT, finance, admin or customer service.

The warning signs are familiar. You avoid dependency upgrades because nobody has time to read migration notes. You have a backlog item called “update package versions” that keeps moving to next month. A supplier asks you to move to a new API version, but the business owner cannot get a clear estimate. A technical staff member knows the app is ageing, but every change feels risky.

The risk is not only technical debt. It is operational fragility. If the app breaks during a busy week, the business falls back to manual work. If a security update is delayed for months, the exposure grows. If only one person understands the tool, holidays and staff turnover become a risk.

This is a good fit for Artellis workflow design because the main job is not buying a new platform. The job is to shape a safe, repeatable process around an existing application. The AI assistant helps with reading, comparison, drafting and first-pass code suggestions. The business still keeps its release controls, human judgement and accountability.

It is not a good fit if you need a large engineering programme, model training from scratch or a six figure platform. It is also not about letting an AI agent make unattended changes to live systems. For most SMEs, the useful version is smaller and more controlled: one app, one upgrade, one repository snapshot, one set of test commands and one technical owner.

A worked example

Take a small Irish distribution company with an internal stock adjustment tool. The tool is used by operations and finance to correct stock records after damaged goods, returned items or manual warehouse counts. It is a modest web app built a few years ago. It depends on an external library that has released a new major version, and the old version is now receiving limited support.

Without AI support, the technical owner may need to spend a day reading the migration guide, searching the codebase and trying changes. They may not remember why certain decisions were made. They may also have to create a manual test list from memory. That is exactly the type of low glamour work that slips.

With a dependency upgrade assistant, the workflow is tighter.

First, the technical owner gathers the migration guide, release notes, package file, relevant code folders and current test commands. Sensitive data is not needed. The assistant is given a controlled repository snapshot, not access to production systems.

Second, the assistant summarises what changed in the dependency. It highlights breaking changes, renamed methods, changed configuration and likely affected files. The output is a short upgrade brief, not a long essay.

Third, it maps those changes against the actual code. It might say that three files call a deprecated method, one configuration value needs renaming and two tests should be updated. Where the evidence is weak, it should say so.

Fourth, it drafts proposed code changes. These are not automatically applied to production. They can be prepared as a patch or pull request for review. The assistant should explain each change in plain English so the technical owner can judge it.

Fifth, it creates a test checklist. For the stock tool, that might include logging in as an operations user, creating a stock adjustment, rejecting an invalid adjustment, exporting the finance report and confirming that audit records are still written. It should also include the automated test command and any known manual checks.

Finally, the Technical Owner Review happens. The technical owner reads the plan, inspects the code changes, runs the tests, performs the manual checks and decides whether to approve deployment. If anything is unclear, the AI output is treated as a draft and corrected.

The value is not that the assistant is always right. The value is that it reduces the blank-page work. A task that might have taken one or two days of reading and trial changes can often be reduced to a few reviewed hours. The person remains in charge.

This same pattern connects to a broader point we make in other Artellis insights: useful AI work in SMEs is often about narrowing the job, grounding the assistant in your own material and designing the review step before anyone talks about automation.

Where I'd start

Pick one non-critical internal app and one pending dependency, library or API upgrade. Do not start with the payroll system, customer portal or anything that would stop the business if it failed. Choose something useful but contained.

Define the input pack. At minimum, include the migration guide, release notes, dependency file, relevant source files, existing tests and the commands used to run them. If there are no tests, include the normal manual checks and any screenshots or notes that explain expected behaviour.

Set the output format before running the assistant. Ask for four things: an upgrade summary, a list of affected files, proposed code changes and a test checklist. Also ask it to state assumptions and uncertainties. That makes the review easier.

Name the reviewer. For a small app, this may be the developer, an IT manager, a technical operations lead or the outside supplier who maintains the tool. The important point is that one person is accountable for approval. The AI output is decision support, reviewed by a person before operational use.

Measure the proof in practical terms. Did it find the right files? Did it explain the upgrade clearly? Did it save reading time? Did the test checklist catch anything the team would have forgotten? Did the reviewer trust the process enough to use it again?

If the answer is yes, turn it into a lightweight workflow: collect inputs, generate the draft, complete Technical Owner Review, run tests, approve release and record what changed. That is enough for many SMEs to stop postponing small upgrades and start handling them in a controlled way.