Leverage When Everyone Has AI

A young developer sent me a message on WhatsApp earlier this year. He had rebuilt something close to one of my client systems over a weekend using an AI agent, and he wanted to know, without malice, why anyone would still pay me. It is a fair question and it deserves a real answer rather than a defensive one.

The answer is that he had rebuilt the artefact, not the work. The code was never the scarce part. It is now less scarce than ever. What remains scarce is everything wrapped around the code, and the sooner an engineer in Uganda understands what those things are, the sooner they stop competing on the one dimension where a machine is unbeatable.

Generation is the cheap part now

Let me concede the point fully before I argue with it. An agent can produce a passable savings and loans dashboard, or a church camp registration form. It can do it in a language I do not know, against a database I have not configured, faster than I could scaffold the project. If somebody’s business model was selling hours of typing, that business model is finished.

But nobody ever bought a dashboard. They bought a change in how their organisation works, and they bought somebody to blame if the change goes wrong. Those two purchases are what is left, and they are worth more than they were three years ago, not less.

The four kinds of leverage this article argues survive cheap generation.

Judgement is mostly deciding what not to build

I am building Scholaris, offline-first school management software for Ugandan schools, aimed at a first pilot with a secondary school in Nwoya District. The specification runs to 141 requirements. The first version deliberately excludes timetabling, the library, transport, payroll and fees.

That exclusion list is the most valuable document in the project. A school in Nwoya has one thing it cannot get wrong, and it is the report card. Marks captured by hand in a book, transferred by a clerk, computed under a grading scheme the school has adjusted twice, printed on a day when the power is out, and then queried by a parent three terms later who wants to know why the total changed. Everything else in a school can survive a spreadsheet. The report card cannot.

Ask an agent for school management software and it will build every module you can name, each of them shallow, none of them trustworthy for the one job that matters. It has no way to know which module carries the school’s reputation, because that is not a fact about software. It is a fact about Nwoya.

Scholaris stores every score in hundredths and every shilling as a whole number, for exactly one reason: a rounding error that moves a child from a B to an A is not a bug report, it is a family in the head teacher’s office. I did not learn that from a specification. I learned it from being that child’s age in a school where the marks were argued over.

Ownership is being the person who is called

Labwor Technologies built and runs the digital platform for NUTOFA SACCO, a farmer-owned savings and credit cooperative. The website was a few weeks of work. The engagement is not the website.

In July the cooperative revised its tillage rate card for members. Somebody had to know, that same week, which pages carried rates, which brochure files were now wrong, which social posts had quoted the old figures, and which claim on the invest page depended on the number that had changed. That knowledge lived in one head, and it was mine, because I had built all of it and because my phone number is the one they have.

The same pattern shows up on the other client platform we run, a corporate site for a civil and electromechanical engineering firm. The build was straightforward. The value is that when they win a contract worth talking about, or a photograph from a site visit is worth publishing, there is one person who already knows the tone the firm uses about itself and can have it live the same day. A generated site cannot accumulate that. It has no memory of the last eighteen months of the client’s own decisions.

This is the leverage nobody writes about, because it is unglamorous. An agent cannot be accountable. It cannot be the name on a contract, it cannot be phoned on a Sunday when a member cannot log in, and it cannot carry a reputation forward from one job to the next. Accountability is a human-only good, and in a market where anyone can generate a plausible system, the scarce thing becomes somebody who will stand behind one.

Domain knowledge you cannot get from a prompt

The work I am proudest of all rests on facts that are not in any training corpus.

A SACCO member’s savings are not a bank deposit. Shares are not savings. A member who has been paying into shares for four years has a claim on a dividend and a borrowing limit derived from it, and if your data model treats the two as one balance you have not built a cooperative system, you have built a bank with the wrong labels. I only know this because I sat through the explanation twice and still got it wrong the first time.

A church camp registration is not an event ticket. A family arrives as one unit, pays in cash at the gate, and the person who registered them three weeks earlier is not the person who shows up. I worked on the registration and camp management system for a Kampala Seventh-day Adventist church’s annual camp meeting as unpaid ministry work, and the requirements that gave me the most trouble were room assignment and meals, neither of which is a software problem until several thousand people are standing in a field expecting both.

In health records, the equivalent lesson was the OpenMRS Billing module. I worked on making it configurable through JSON and XML files, and the reason that mattered is that a facility in Burundi and a clinic in Botswana price the same consultation under completely different rules. If the pricing logic lives in code, every country needs a developer. If it lives in configuration, the implementer in the country changes it on a Tuesday afternoon. That is not a technical preference. It is a claim about who should hold power in a health system.

Distribution is the leverage people least want to hear about

I did not get Ugandan client work by being the best engineer available. I got it because I designed banners and t-shirts for my brother’s printing business in Pader and Gulu from 2008, because I spent four years as a Bible worker running public meetings in villages, and because when a farmer-owned cooperative in Northern Uganda or an engineering firm needed a website, somebody in the room already knew my name.

In Uganda, trust travels by relationship. It does not travel by portfolio. A stranger with a flawless GitHub profile is at a disadvantage against a known quantity with a mediocre one, and no amount of AI-assisted output changes that arithmetic.

The same is true in open source, only the relationships are typed instead of spoken. I started contributing to OpenMRS in June 2023 as a volunteer. The community named me Volunteer Contributor of the Year in 2024, and it did not come from a clever pull request. It came from a year of being present: answering on the community forum, writing the onboarding guide new contributors actually read, showing up to calls at inconvenient hours. Two community management fellowships followed. None of that was code, and all of it was distribution.

What compounds

The clearest piece of leverage I own is unglamorous. I needed to translate devotional and reference material into Acholi across three separate apps, and the free API quota was nowhere near enough for a backlog of over ten thousand items. So I built one translation pipeline over Sunbird AI’s Sunflower model, with a switch that moves a job between the hosted API and the same model running locally, and checkpointing shared across all three projects so nothing is repeated.

One pipeline, a switch between two backends, and shared checkpoints feeding every product.

I built it once. It now works while I sleep, for three products, and it will work for the fourth. That is what leverage is: something you build once that keeps paying without you. Cheap generation makes it easier to build such things, which means the engineers who think in terms of reusable capability rather than delivered tickets are about to pull very far ahead.

My honest answer to the young developer is that he should keep going, and then find the part of the problem nobody can prompt their way into. Build the system, yes. Then learn the cooperative well enough to argue with its treasurer, and be the person whose name is on the contract when it goes wrong. The generation is free now. The standing behind it never will be.