I built a farming bot.
It had other plans.

A farm seemed like a fun place to start

I wanted a project that would give me a reason to learn Python beyond working through another tutorial. Then I found Kaggriculture on Kaggle: a competition where you write a program to play a farming simulation.

That sounded fun. It also turned out to be a lot more involved than I expected.

I wasn’t clicking around the farm myself. I had to write a bot that could look at the game state, decide what to do, and send back an action. Then it had to keep doing that while the game moved forward.

At the beginning, I didn’t know how to build an AI farmer. By the end, I had a working entry submitted. It wasn’t a top-performing bot, but I’m proud that I got it there.

What does a farming bot actually do?

Think of the bot as the person making the farm’s decisions. What should it plant? Which worker should handle the next job? Is there enough space to carry the harvest? When should it sell?

My approach was to write the decision rules myself, with AI helping me work through the code and ideas. This was a rule-based agent—not a neural network I trained, and not a reinforcement-learning system learning through rewards.

That distinction matters. I was learning how to describe a strategy in code, test it, and improve its decisions.

The simulation runs for a limited number of turns. A plan that seems sensible on its own can still be a bad idea if the worker spends too much time walking, misses a useful shop window, or finishes with goods that never get sold.

The farm became a scheduling problem

One of the biggest parts of my bot was deciding how to use the workers. Hiring more people wasn’t enough. They needed useful jobs and enough time to finish them.

I worked on evaluating possible tasks, estimating the actions they would take, and fitting them into a worker’s schedule. I also had to think about what each worker would carry and when they needed to return to the shed.

A detail that kept coming back was the return trip. It’s easy to see a profitable harvest and count the actions needed to reach it. But reaching the crop isn’t the whole job.

The harvest still has to get home. Otherwise, a good-looking plan can leave a worker holding the profit.

I explored including the journey back to the shed in the cost of a candidate task, rather than treating it as something to sort out later. Near the end of the game, that becomes even more important.

Then came all the little things

Seeds, crop timing, fertilizer, market orders, animals, storage capacity—each new detail connected to something else.

I worked on inventory forecasting and when supplies needed to be ordered. I also reconsidered consolidating seed purchases: grouping everything into one early order wasn’t always the same as buying what was needed at the right time.

I experimented with expanding into a second quadrant of the farm. More land created more possibilities, but also more travel and more decisions for the scheduler.

And the final day needed its own attention. Producing more goods doesn’t help much if there isn’t time to move and sell them before the episode ends.

None of this was a single magical AI trick. It was a lot of small decisions, testing, and asking why the bot did something I hadn’t intended.

A good local run isn’t the whole story

I ran local simulations to watch how different versions behaved. Those runs helped me see whether the bot could make money, where it stalled, and what a change seemed to improve.

But I learned to be careful about what a result actually meant.

An in-game cash total from a local episode isn’t the same as a competition rating. Playing against another agent is also different from optimizing a farm in isolation.

I ran into uncertainty while comparing versions, too. If I couldn’t be sure the test had loaded the version I meant to run, I couldn’t be sure which code deserved credit for the result.

That was a useful lesson beyond this game: before celebrating an improvement, make sure you actually tested the thing you changed.

The same applied to the submission. I had been working toward a two-quadrant strategy, but the submitted version didn’t reflect everything I thought I was sending. Watching what the entry actually did mattered more than what I’d named it.

I got it submitted

As the deadline got closer, I still had plenty of ideas and things I wanted to fix.

There’s always one more improvement. One more rule. One more test that might explain why a worker made a strange decision.

But I didn’t want this to become another project I worked on and never finished. I submitted the bot, and I kept learning from its behavior.

The competition is over now. My entry wasn’t doing especially well, and I’m not presenting this as a winning strategy. Getting a working program through the submission process was still a real accomplishment for me.

I started with “How would I even do this?” and ended with a program making its own farming decisions in a competition. That’s a pretty satisfying change.

What I’d take into the next challenge

I’d start with a small baseline I understood, make one change at a time, and keep clearer notes about what each version was supposed to do.

I’d also verify the submitted file’s behavior earlier. A local improvement only helps if the right code reaches the competition.

Most of all, I’d keep using projects like this to learn. Having a farm to improve and a deadline to work toward made me want to understand the code in a way that a tutorial alone didn’t.

AI helped me get farther. I still had to ask questions, follow the logic, decide what I wanted the bot to do, and notice when the result didn’t make sense.

I don’t need to pretend I knew all of this at the beginning. Figuring it out was the point.

Learning as we go.