From failure you learn—from success, not so much, from OEDP's Fieldnotes on AI

Reflecting on the role of prototyping in inquiry, Data & Tech Lead Cathy Richards writes about leveraging AI early on in the process in order to learn from failure as quickly as possible.

This post is part of a series titled “OEDP’s Fieldnotes on AI”, where we offer reflections about AI in environmental and participatory contexts. In our second-to-last installment, this week’s reflections center on the question:

How can prototyping sharpen inquiry—or capture it?

We consider how fast, imperfect prototypes can clarify thinking (rather than replace it) and environmental questions (without locking communities into technical pathways).

Excerpt from Cathy’s field notebook

There’s a particular satisfaction to finishing something. I just recently finished a book nook, which - while not the hardest one I’ve ever worked on - I probably admired it way too often. Completing things is great. In theory, I wish I completed more things over the course of my life. But, the reality is that in life most things should never really be ‘done’ yet we often strive for an all encompassing solution. This is mostly fine when you’ve correctly identified the problem, but when you haven’t, you risk losing the serendipity of discovery and experimentation.

Charlie Warzel has a name for this: Builder Brain. The Builder mindset tends to skip past the complicated, specific details of a problem in search of the big, ‘world changing’ fix. Builders are so interested in what’s possible that they make illogical leaps, creating things that may or may not truly alleviate the problem then move on to the next big thing, leaving the mess for everyone else to sort out. Builders make tools for communities they’ve never met, for land they’ve never stood on, and for problems they’ve mostly read about.

When scientist Catherine Nakalembe tried to use AI to map crop types in western Kenya, she found that the available tools simply couldn’t recognize what they were looking at. They had been trained almost entirely on European and American farmland, and maize and beans in Kenya look different from maize and beans in Iowa. Her fix: GoPro cameras strapped to the helmets of dozens of volunteers, walking through actual fields, collecting over five million images in two weeks.

Arti Dhar, who runs a conservation group in India called Farmers for Forests, ran into the same problem. Her team tried using a well-regarded open-source model to identify trees on farmland and it missed more than half of them. North American forests had given the model one picture of what a tree looks like. Maharashtra gave it another. They ended up manually labeling 55,000 individual trees from drone footage.

On the surface, these are stories about missing data. But I think they’re about something else entirely - clarifying thinking using imperfect prototypes. The fact that both models were open-source further supported this endeavor as scientists were able to iterate, tweak, and train it on their own data.

Admittedly, over the last few years “move fast and break things” has developed an entirely new meaning. I’ve never been a fan of it, either: it discards the humans caught in the mix when things break. However, prototyping and learning quickly and safely is still a thing we can endeavor for.

The more useful kind of prototyping treats the failure as information. Like in Meet the Robinson’s where the family celebrates failure: “From failure you learn, from success, not so much.” The prototypes displayed around the mansion are a reminder of all the ways they learned along the way.

In the case of AI, not only can we prototype and test quickly, much like the examples mentioned before, but we can also ask these models to help us highlight things we haven’t considered. What questions aren’t we asking? What are we overlooking?

These prototypes won’t cover all use cases. As a matter of fact, they shouldn’t. But they should get us a step closer to understanding where we need to be. What makes a prototype genuinely useful is that it can still be broken and revised without much attachment. A community can look at it and say: this doesn’t look like my home. The option to do that disappears the moment the tool gets scaled or gets labeled as a solution.

Warzel ends his piece with a quote from Elizabeth M. Renieris that’s stuck with me: ”If we just keep building without repairing what exists or applying lessons learned along the way, we will continue to spin our wheels as the same problems accumulate and amplify. In this way, our technology may evolve, but our relationship to it (and to each other) can only degrade.”

I think the most useful thing a prototype can do, especially in environmental work, is slow that down. Not by being less ambitious. But by keeping the questions going a little longer before the answer gets locked in. Spend more time with communities, ask more whys, look around a little longer.