Agrifood Vibe Coding

Checking the work

Testing, for people who have never tested anything. This is the skill that matters most, and the one a workshop can only start.

Checking is now most of the job. The AI produces more in ten minutes than you can carefully read in ten minutes, and that gap is the reason verification is not an extra step you do at the end. It is the thing that makes the speed usable.

Why this is not optional

Two reasons, and both are permanent rather than temporary.

The first is speed. There is more output than you can inspect, which means things will reach other people that nobody actually read. The second is the one from the workshop: responsibility does not move. The tool can act, but a person still sets the goal, chooses the evidence, approves the consequences, and remains accountable. If a number goes to a board or a member, someone's name is on it, and it will not be the model's.

Three questions, in this order

Question What you are actually asking
Is it true? Facts, sources, numbers, rules. Most of what an AI tells you about the world needs this check.
Does it work? The thing runs, on your machine, with your messy input, and produces something sensible.
Is it safe to use? Data, permissions, who else is affected, and whether you could undo it.

Most people check the second one and skip the first and third. The first two are the easy ones; the third is the one that decides whether you should.

Is it true?

Six checks that take a few minutes and catch most of it.

  • Ask for the source, then open it. If there is no source, treat the claim as a guess wearing a confident tone.
  • Check the date on the source. Regulation, prices, programs, and technology all move. A correct answer from three years ago is a wrong answer now.
  • Search for the opposite. Spend two minutes trying to find the claim contradicted. If you cannot find anyone disagreeing, you can raise your confidence.
  • Ask what would make it wrong. "What would have to be true for this to be false?" is a surprisingly effective question, and it often surfaces the assumption you were about to inherit.
  • Do your own arithmetic on anything you are about to repeat. Yields, margins, acreage, percentage changes. Numbers are where confident errors do the most damage.
  • Never let a model be the only source for a decision about money, people, livestock, health, or regulation.

Does it work?

This is the part that feels optional and is not. It is also the part that is genuinely satisfying once you get used to it: you are the first person to try the thing, and you get to decide what counts as working.

  1. Run it yourself, in front of you

    Not a screenshot. Not "this should work now". Not a description of what it would do. Open it and use it.

  2. Use the input you will actually use

    Not the tidy example. The messy one: the note typed on your phone, the field with the missing value, the spelling error, the two languages, the number with a comma in it, the file exported from the old system.

  3. Try to break it

    Five attempts take two minutes and teach you more than a week of reading:

    • Leave the field blank and submit.
    • Paste in something huge.
    • Paste in the wrong kind of thing (text where a number goes).
    • Do the same action twice in a row.
    • Enter a real value with a comma, a currency symbol, or a French accent.
  4. Look at the output, not just at the absence of errors

    Nothing crashing is a low bar. Is the answer sensible? Is the total plausible? Does the list contain something that should not be there? You know the domain; the AI does not.

  5. Ask what it did not handle

    "What inputs would break this? What is missing before someone else could rely on it?" The answer is usually a good list, and it is usually longer than the plan suggested.

  6. Then go and try one of those inputs

    A known weakness that has been tested is a decision. An untested list of weaknesses is just hope.

Five checks before you rely on something

A short version you can reuse for anything you build. If you cannot tick all five, the honest move is to call it an experiment rather than a tool. Both are useful; only one should be depended on.

  • It ran on my machine, with my data, while I watched.
  • I tried to break it, and I know roughly what happens when it breaks.
  • I know where the numbers and the claims came from, and I opened at least one of those sources.
  • I know who else is affected by it, and what happens if it is wrong.
  • Someone else could run it using only my notes.

Is it safe to use?

Four questions, asked before the tool goes anywhere near other people's information.

  • What left my control? Which data went into a hosted model, and does that conflict with anything you agreed with a member, a funder, or a client?
  • Who can see the result? A file on your laptop and a page on the open web are very different things, and the second one is easy to create by accident.
  • Could I undo it? Sending an email, posting a notice, paying an invoice, or writing to a member list are not reversible. Do those parts by hand until you have done them by hand many times.
  • Who is accountable if it is wrong? If the answer is "nobody, it just does it", stop and change the design.

Keep a test note

The habit that makes all of the above cheap is a short note in the project folder. Four lines, no format to learn:

test-note.txtWhat I tried: What I expected: What happened: What I will do next:

Two weeks from now you will not remember why the notes are sorted that way, or which of your three attempts to fix the import actually worked. The note costs a minute and saves the afternoon.

When you cannot check it yourself

Sometimes the answer needs a person who knows things you do not: an accountant, a veterinarian, a program officer, the colleague whose problem this actually is. Asking is part of the method, not an admission that you failed at it. The useful version of asking names the uncertainty precisely:

Asking a better questionI built something that calculates X from Y. I have checked it against three cases and the totals look right, but I am not confident about what happens when Z is missing. Can you look at this one case and tell me if the answer is plausible?

The Future Herd Discord is a reasonable first place for the technical half of that question. Post what you tried, what you expected, and what happened.

What not to conclude from all this

The point is not to trust less. Distrust is exhausting, and it makes people slower than working by hand. The point is to trust the right things: the tool for the tedious part, your own eyes for the part that matters, and a person for the part with consequences.

The workshop's framing holds here too. Use AI to extend judgement and capability. Keep humans responsible for goals, evidence, verification, and consequences.