Before you put time into a new piece of farm tech, it's fair to ask who built it — and whether they know anything about farming.
For farmBI, the answer is me. Born and bred in southern Hawke's Bay hill country (Tararua? Let's not open that can of worms), chasing sheep since I was in single figures, through to being responsible for 5,500 hectares of an intensive sheep and beef operation. Some dairying slotted in along the way.
I built farmBI, but I didn't write the code. AI tools did that. From paddock to prompt.
If that makes you more nervous rather than less, fair enough. AI can produce something convincing that is wrong. Here's how I approach that.
Pilot or passenger?
Researchers at BetterUp and Stanford's Social Media Lab describe a useful distinction between AI "pilots" and "passengers". Pilots take an active role in directing the tools. Passengers are more inclined to go along for the ride.
The distinction makes sense to me. An autopilot is useful, but someone still needs to know the route, watch the instruments and recognise when something looks wrong.
At farmBI, I decide what the app should do and how it should behave on a real farm. AI helps plan the implementation, write the code and review it. I'm responsible for deciding what makes it into the product.
There's another distinction worth making: AI helping write a feed calculation is different from asking a chatbot to guess how much feed your ewes need. The calculations follow defined equations and assumptions that can be inspected and tested.
Knowing what to ask
You've probably heard of "vibe-coding": type a few prompts, sit back and watch your next global software empire appear.
Yeah, nah.
AI has made building farmBI more affordable. Knowing what it should do still takes work.
Take the feed demand of a ewe at 145% lambing. Is that lambs born? At docking? At weaning? How should her feed requirement change if she's losing body condition? How does the lambs' weaning weight connect with what's being asked of their mum?
Those questions draw on farming experience and research. The choices about how to represent them need to be explicit. Otherwise, you can end up with a very precise answer to the wrong question.
The same goes for pasture growth between measurements, or a crop yielding less than planned. I know the feeling of waking at 3am to heavy rain, instantly regretting stretching the R1s another day in their paddock. Then spending the morning moving other pieces around to limit the damage.
That experience helps me ask useful questions. It doesn't make my answers infallible either.
Expect mistakes. Build in checks.
The build assumes both AI and I can be wrong.
One AI tool proposes a change; another develops its own approach without seeing the first. Differences get examined. But two models agreeing isn't proof: they can share blind spots.
That's why the checks also include published farming information and worked examples with established answers. Calculations are tested against those examples. Decisions about how something should work are recorded, along with the reasons, so they can be challenged later.
A passing test shows that a calculation handles the case tested. It doesn't prove every possible result will be right. The point is to give mistakes several chances to be caught — and keep the reasoning available when something needs investigating.
You're the other pilot
farmBI is getting off the ground with a small group of farmers. Its purpose is to help you examine a plan, compare options and see what the numbers depend on.
The app is the instrument panel. You bring the knowledge of your farm, the practical constraints and the judgement about what to do next.
AI has helped me build it. Helping you think through those decisions is what makes it worth building.
Field notes is written while building farmBI. If you'd argue with any of this, I'd like to hear it — that's most of what the pilot is for.