Built for one farm

Here is a thing that was not possible until very recently. Somebody who has never written a program, and never wanted to, sits down with an idea for a tool and, by the time they would have gone to bed, the tool exists. It works. It remembers. It does a job no catalogue has ever listed, because the job is too small, too strange, or too tied to one place for anyone else to have bothered building it. Until now the story stopped where the idea did, and the person made do on paper, or did without. The distance between the idea and the working tool used to be a whole industry wide. Now it is a conversation.

What people build first looks modest, and it is the wrong thing to be impressed by. A planting log becomes a screen you can search. A record of what was sprayed, and when, stops living in a binder. That is the old paper put on glass, and it is the least interesting part. The same evening produces things there is no store for: a crop photographed when it sickens and named before a person could guess, a field read from space plot by plot, a greenhouse vent opened and closed from a text message. None of those is a faster way to do the old job. They are new jobs, and the new jobs are the point.

The new jobs are why this reaches past software. A person who can build what they need can build the instruments of attention, the close observation that farm knowledge has always run on: sensors in every growing space, a season watched in numbers a person can actually read, one field known plot by plot. And the people reaching for this are often the ones nobody called for, people who did not inherit a farm or study agriculture, who arrived with an idea about how things should be done and, for the first time, the means to build it. The practice does not just hand the newcomers a tool. It hands them back their own imagination, which was never for sale.

Why the software never fit

Farm software tends to be built for a category rather than for a farm. It is designed for grain operations, or for dairies of a certain size, or for the industry's idea of what a spraying record ought to contain. That is not stupidity on the part of the people who build it. Software is expensive to write, and a company that solves the same problem for thousands of farms can sell it for less than a company that solves it for one.

The trouble is that the farms that do not fit the category mostly do not complain. A farm buys the program, adapts its routines to the fields the form offers, keeps a paper backup for the parts the program cannot hold, and then stops opening it. The paper comes back out. The industry has a name for this, which is poor adoption, and the name puts the failure in the wrong place.

What has changed is not that farms found better software. It is that they stopped waiting to be sold any. A farmer, or more often somebody who works for farmers, describes the problem in plain language to a conversational AI, and gets back a small working program, without a development team, without a procurement process, and without anybody's permission. The practice has a name now, and it is a bad one. Vibe coding catches the unserious feeling of the thing and misses what it is: the people closest to a problem building a tool for that problem themselves.

The doubt inside the sector

The most direct evidence in this book's own conversations arrived when Donald Killorn was asked about it. He is the executive director of the PEI Federation of Agriculture, and he had been describing the front end his organization is building for a system it calls ag intel. His answer is not about the technology. It is about whether the thing he is building should exist.

"We are in the last moments of, uh, bespoke like, uh, app specific ux."

Those words are a strange thing for a person mid-build to say, and they are exactly right. If a person can describe the screen they want in a sentence and get one, then the screen stops being the valuable part. Killorn describes a weekend conversation with a colleague that gave him chills, and the question at the centre of it is the one every builder in this chapter is implicitly asking: "are we building the right thing?"

He also says where the bottleneck has always been, and it is not the code. "The bottleneck is in adoption". A sector that spent thirty years learning software it did not design is now in a position to write the version it would actually use, and the hard part is unchanged, because a tool nobody opens is a tool that does not exist.

The ordinary version

The smallest real case is also the least spectacular. Chris Unrau runs Precision Land Solutions, a tile drainage and water management business in Winkler, Manitoba. On a farmer-focused video programme called The AI Farm, he described building three business apps with a conversational builder called Base44, mostly during hockey games. One of them replaced an application he had been quoted fifty thousand dollars to have made. The reported cost of building it himself was about forty dollars a month.

That is the shape of the change at the small end: not a product launch, not a competitive strategy, just a business solving its own problem at a price it was willing to pay. It is also self-reported, on a programme about AI, by a person with a reason to sound convinced. The identity and the business are real and easy to check. The claim about what he built is his.

The version with a record

The best-documented case is in Hokkaido, and it is documented by its author. Hiroki Tomiyasu grows about a hundred hectares of broccoli, pumpkins, green onions and soybeans. He grew up outside Tokyo, did not inherit land, did not study agriculture, and spent his early career as a public servant. About ten years ago he was part of a small group restoring abandoned rice terraces in Okayama. Farming came to him as a conviction rather than an inheritance, and he learned it by doing it.

He now spends his off-hours building software for his own farm, and his account of it is public, in a profile published by ChatGPT's professional-user community in June 2026. What he has built is a list of small things, each of which would normally have required an engineer: photographing a diseased broccoli head in the field and getting an assessment in seconds; pulling satellite vegetation data onto maps of his own fields so he can judge what each plot needs; asking for a wiring diagram for a control box and getting one back, annotated, in Japanese. There is also a greenhouse whose vents he can open and close from a text message, and a bot that helps run the farm's group chat.

His one-line summary of it is the reason this practice matters. "It feels like having an ultra-talented engineer always by your side."

The version that starts from somebody else's tool

Almost nobody starts from nothing. They start from somebody else's work. That is why this book keeps returning to openness: the person who can look inside a tool is the person who can build one.

Sekiguchi grows Eustoma, a cut flower, in Namie Town, in Fukushima Prefecture, and he describes himself without hedging: "I have zero programming experience." His account of the last eighteen months is a sequence of models and failures, from ChatGPT to Claude to Claude Code, and what he has at the end of it is a sensor in every greenhouse, a database on a small computer he runs himself, and a web application he checks from his phone. His summary of the period does not pretend the process was smooth: "Days full of failures. But they were also, strangely, enjoyable days."

His account is written in Japanese and the translation is the publishing platform's, so the words carry that caveat. What set him off is not a product. It is a demonstration project from Japan's national agriculture research organization, which puts sensors in fields and shares the data openly. He encountered it in his first year of farming, saw what it could do, and asked himself whether he could do it himself. Somebody else's open project was the on-ramp.

More than the paperwork

The conversion of paper is the easy win, and the one people reach for first, because records are how most farms meet software. But the same evening that produces a form can produce an instrument. Tomiyasu's own fields show up on his phone as satellite readings of what each plot is doing, so he sees which part of the crop is struggling before it would be obvious to the eye. Sekiguchi has a sensor in every greenhouse and a small computer keeping the record. Neither has a paper equivalent. They are observation, and observation is what farm knowledge has always been: a person attending to one specific place until they know it.

That is why this reaches past software and into how a farm learns. Agroecological methods run on exactly this kind of close, specific attention to one field rather than the blanket advice a prescriptive product can sell, and a tool you build for your own ground, and revise as the ground answers back, is closer to that discipline than anything bought off a shelf. The same reach applies to the animals. The economics of animal health run through early detection, and early detection is a thing a person can build toward, not a mystery: a sickness caught before the animal shows it, or a lame step read the same day, costs far less than the animal that goes down and the veterinary call that follows. Commercial products already sell this early warning. The potential is that a farm which can describe the warning it needs, and build it, does not have to rent the idea.

When the tool leaves the farm

Two things happen once a farm's tool works. It gets users, or it gets taught.

Michael Murphy is a first-generation grain grower in Swift Current, Saskatchewan, and the tool he built for his own operation is now a product that other farms run. AG360 collects grain tickets, bin levels, field maps, equipment service history and labour into one place, and its own listing describes it as "Designed by a farmer, for farmers." That listing is a vendor's listing, so the adoption numbers belong to the company: free during beta, onboarding farms across Saskatchewan and Western Canada. What is verifiable is the thing that would have been absurd ten years ago, which is a working farm management platform written by the farmer who needed it.

Then there is the institutional version. The Agricultural Adaptation Council has been delivering programs for Ontario's agri-food sector since 1995 and represents 55 farm, food and rural organizations. In September 2026 it ran an online workshop for agri-food professionals, in two sessions, on using AI in their work, and its promotion did not hedge. It invited them to learn to vibe code.

What breaks

Everything above is the success half of the story and almost all of it is self-reported. The other half is measured, and it is the half that decides whether any of this lasts.

Researchers scanned more than 380,000 web pages and applications running on the platforms people use to build this way, including Lovable, Replit and Base44. Of the 5,000 they found that had been built for business purposes, 40 per cent were handling sensitive data with no basic security controls at all. Two thousand were holding sensitive data with no authentication, no access control and no record of who had looked at it. Every exposure was reachable by anyone with a browser.

That study looked at offices rather than farms, and the pattern matters more than the example. The security finding is a symptom. The disease is that a tool built by one person for one operation has exactly one maintainer, and that person already has a job. There is no on-call rotation, no patch schedule and no support line. So the failure mode of a farm's own tool is not a breach in the abstract. It is a morning in seeding when the form stops saving, and the person who has to fix it is standing in the yard, and the fix is a conversation with a model that has no memory of the version that broke.

The tool test

Ivan Illich offered a way to tell two kinds of tool apart, and it is a better test than anything in the vendor literature. A convivial tool enlarges what a person can do for themselves. An industrial tool is one that demands service and creates dependence, and the dependence is not an accident of design. It is the business model.

By that test, the last three years look like a gift. A farm that can build its own record system, change it next season, and repair it on a bad morning is holding a convivial tool in the plainest sense of the idea. The claim holds for as long as its author is still around.

The trouble is where the dependence has moved. A file on a farm's own computer belongs to the farm. An application living on somebody's platform, with the keys to the database written into the code and nobody assigned to update it, is not really the farm's tool. It is the farm's account, and accounts end. Douglas Rushkoff's old instruction, to program or be programmed, was an argument about literacy before it was ever an argument about software. Nobody in this chapter has become a programmer. They have taken the seat, which is a smaller thing and, for control of your own operation, a larger one.

What this book knows from its own desk

There is one more piece of evidence, and it is the weakest kind. This book is assembled with small tools of exactly the kind this chapter describes.

The script that reflows a paragraph to the manuscript's line width whenever one is edited. The script that takes every quotation in every chapter and checks it against the transcript it came from, character by character, because a misattributed quote is worse than no quote at all. Neither was commissioned, specified or budgeted. Each was described in a sentence, built in an afternoon, and corrected by being used.

That is one author's practice and not a study, and it proves only one thing, which is that the threshold has fallen far enough for somebody who is not a programmer to walk over it. There are far more people who can describe their own problem precisely than there are software companies willing to build for them. What they have lacked is a way to act on the description.

The Situation: one problem, one tool

The Situation for this chapter is a build, and it should take an evening.

Pick one problem you currently solve on paper. It has to be small, repetitive and yours. A planting log for a balcony. A tally of what sold at a market table, and at what price. A record of which hens are laying and when. A chore rota for a shared garden. The spray log for four hundred acres. Any of these is the right size.

Describe it to a conversational AI the way you would describe it to a neighbour. What you record, in what order, and what you want to be able to look up later. Do not specify technologies; you do not need to know what they are, and naming them makes the result worse.

Ask for the smallest thing that works, use it for a week, and write down the two occasions it failed you. Then answer the question that decides whether you have a tool or a demonstration. Who maintains this. If the answer is you, that is a real answer, and this is now your tool. If the answer is nobody, then you have built a demonstration, not a tool, and the difference matters more than the code.

Moves you can make

If you run an organization, the useful question is not which platform to buy. It is which three forms your members hate filling in, and whether any of them could be a sentence instead.

If you farm, keep the paper, which has one property no application has yet matched: it will still be readable in twenty years. Then add one small tool that does the thing the paper cannot, and notice how quickly you start relying on it.

If you fund this work, or regulate it, ask who maintains what gets built. A funder that pays for tools and not for upkeep is paying for a demonstration with a subscription attached.

Open questions

Whether a farm keeps building once somebody offers to do it for them. The first version of a farm's tool comes from the farm, because nobody else would build it. The second version arrives as a product, from a company that saw the first version working, and the second version rarely has the farm in the room. The practice could turn out to be a stage an operation passes through rather than a habit it keeps.

What happens to a farm's own software when the model behind it changes, is deprecated, or changes its price, since the farm's tool is now somebody else's service in a way the binder never was.

And who the maintenance falls to when the first generation of farm-built tools gets old, and the person who wrote them has moved on, and there is no vendor to call. That is the question this chapter raises and cannot answer, and it is the one that decides whether any of this is still running in ten years.

And there is the version that belongs to whoever works across many farms rather than one. A tool that only its author can use has not solved the adoption problem Killorn named. Somebody has to be able to pick it up, understand it, and pass it on, and that is a job in itself. Learning is the thing you build on top of a tool, which is where this book goes next.