Building Modern Tools for Computational Science in Flutter to Track the American Chestnut

One of the great things about working at a public benefit company is that we get to work on projects that only make sense when you’re trying to do the right thing and are passionate about it. Right after we opened, I spent some time with colleagues at the American Chestnut Foundation and learned how challenging it can be to work with big data in big orchards and state forests. I wanted to develop a small app to help track trees in those settings as well as the deep woods where I occasionally go timber cruising.

You can learn more about that product at its page. This article will tell you why and how we built it, and why we leaned heavily into automation and code generation.

My family used to sit around the wood stove at Christmas trading old stories and legends of Appalachia. My grandfather would, after a time, start cracking chestnuts, which he always ate raw. One Christmas, while I was examining one of those curious brown nuts, he told me the story of the American Chestnut tree and asserted I would be lucky if I ever saw one, especially a wild one.

The American chestnut is a functionally extinct keystone hardwood species in the eastern US. The former range of this tree was from Nova Scotia to southern Georgia, and in some places it accounted for nearly 1 in 4 trees. It produced a light, strong wood that was rich in tannins and highly water resistant. Chestnut barns built over a century ago still stand all throughout the Appalachian Highlands, sometimes being recovered for furniture or paneling. (We had wormy chestnut paneling in one of our houses when I was little.)

It also reliably produces chestnuts every year and became a dietary staple of explorers and settlers as soon as they encountered it. By the early 20th century, it was such an important crop that it was accepted in lieu of cash and the annual nut harvest even dictated train schedules.

Two invasive pathogens, C. Parasitica and P. Cinnamomi, along with a million happy axes, devastated the chestnut population in the 20th century. This caused immeasurable damage to forest species over several decades as that reliable annual crop of chestnuts slowly vanished, and quite a few Appalachian towns disappeared as they lost the nutritional and economic benefits of the nuts and lumber.

The American Chestnut Foundation (TACF) is leading the fight to restore this species. You can learn everything there is to know about identifying wild chestnut trees, growing trees from nuts, their hybridization and recurrent genomic selection (RGS) programs to develop blight- and root rot-resistant varieties, and how to volunteer or donate on their website. Their programs require large amounts of space and volunteers to plant, inoculate, monitor, and harvest the trees (which is how I got involved). Much of their work has focused on producing, via backcrossing, a hybrid chestnut tree with 15/16th (93.75%) American Chestnut DNA and significant blight resistance from the Chinese Chestnut. The RGS process will speed up the breeding cycle and select desirable traits by using genetic sampling and hand-pollination to identify the best trees for the next generation. More information on that process is available on the TACF’s YouTube channel.

We originally built our tree tracking app, Tracee, based on input from collaborators at TACF, my own experience volunteering, and my experience wandering off in the woods on my own to hunt chestnut trees. (I’ve been escaping to the woods for decades, but hunting chestnuts is new.) The idea of “tree tracking” may seem obtuse since trees are enormous, stationary, and breathtaking, but the nuance comes from the surrounding environment. Is it a wild tree on a mountainside that maybe only a few people have seen? Was it a seedling the last time you saw it, and you don’t know where someone transplanted it? Is it in a dense orchard where there are so many trees that they can be hard to count? Or maybe it is in an old orchard where father time, natural death, culling, and roguing have caused rows and landmarks to vanish? If we expand the environment to urban and park settings, then we get into a whole other set of questions and the commercial realm of “tree assessments,” where tree health is often translated into property, timber, or conservation value.

Tracee is primarily GIS-driven, meaning that it uses maps, imagery, and geolocation in the workflow to help users track trees. It works on six operating systems and is available in community, cloud, and enterprise editions. Users can identify objects, log the position, and add metadata with the phone in their hand or from the comfort of their workstation. They can also capture notes through dictation and use manual (community edition) or cloud-based syncing to share their data. Tracee dynamically switches its UI to accommodate the user’s work mode so folks in the field looking up at a 100-foot tree aren’t also trying to type.

I say “objects” because we quickly learned that Tracee can be used for tracking more than chestnut trees. For example (and being completely honest), I actually track more maple trees with Tracee than chestnuts because I’m a maple sugarer. I spend a few months a year gathering sap, and I want to track the health of my trees each season. We’ve also experimented with using Tracee to track “geographic features of interest” for some sponsors, food crops, and urban points of interest.

We built Tracee with Flutter. Flutter is a cross-platform app development framework that is the workhorse of our cross-platform support. Behind the scenes, Flutter builds with CMake on laptops and workstations and uses native build systems on iOS and Android. It is the best “write once, run anywhere” framework I’ve used. It is written in Dart, which is an enjoyable, albeit sometimes curious, language.

I mentioned that our initial prototype of Tracee was vibe-coded. We did this knowing full well that we would have to rewrite the app, but we wanted to understand how far we could go before it broke. It was a surprisingly disappointing experiment. We paid for it over the next few months as we refactored the code, but it also produced downstream results for us that were ultimately good.

Tracee wasn’t the first or only product we’ve built at the Band Gap. However, it has been the most impactful in crafting our internal development process and giving us a framework, Stager, on which we build other applications. Stager has two primary components: its cross-platform parts and its native plugins, which specialize in system-level behavior on specific operating systems. For example, we use different audio capture libraries on Linux and Windows. Tracee now only contains the “app” features, which exist at a higher level than the feature in Stager. These app features include things like component configurations, branding, and data, as opposed to Stager’s selection framework, dictation tooling, map connectors, tree editors, reusable widgets, and other lower-level components.

Stager emerged, in part, as payment for our sins of vibe coding the prototype, and, in another part, because we realized that tree tracking is a variant on a particular type of application that we could standardize somewhat generically (in the templating sense) and reuse if we thought ahead. How we built Stager, therein rebuilding Tracee, has become our standard development process.

I won’t claim that Band Gap is an “AI-first” company, because that’s a lie. Obviously, as a benefit corporation, people come first for us. We like to say that we’re an “AI-native” company that uses machine learning and artificial intelligence, including large language models, to make three people seem like thirty. We see code generation as a tool like any other; LLM-based code generation is simply a different flavor of a very old technology.

The real trick for us was learning how to integrate high degrees of automation into our workflows to create an AI-native software development process that accelerates us. We noticed very quickly that “massive” gains in one phase of development might be completely erased by mistakes or even normal delays in another phase, creating a false sense of productivity. Likewise, we also noticed that cognitive debt caused by high automation is problematic and expensive because it builds unreasonable confidence and assumptions. (I’m lucky to be a former middle-manager, so I had some tricks for handling that one.) Finally, we had a hunch that co-design, pair-programming, and creative use of agents and MCP servers are far more effective than tokenmaxxing. This hunch has, perhaps, turned out to be the most important, and now we always assume two actors working on any given task: a human and an agent. This is true across all tasks, even those that don’t involve code development.

I have always appreciated the hump chart from the Rational Unified Process framework (RUP). I worked with RUP twenty years ago and the image of the hump chart stuck with me. It is like the Hertzsprung-Russell diagram, but qualitative and for software products instead of quantitative and for stars. It describes the phases, iterations, and level of effort for different development activities over time and is a generally good way to simplify the software development lifecycle.

We used this notion to separate roles by phase such that human taskers engage in one set of activities and agents engage in another. The sections below describe how this breaks down by activity type (requirements gathering, implementation, etc.) with the implicit understanding that the activities in every phase and iteration happen with different intensity over time.

I’ll save the details of how we use heavy automation in testing and deployment for a future post. It is more of the same that we saw in the previous section, and you can rest assured that “auditing” is still on the list. (And if you want to help us with testing, have a look at our call for testers.)

We’re pushing ahead on enterprise features for Tracee using the process and tools we’ve discussed here, with some fall deployments here before we know it. Stager has a set of enterprise features coming its way too, and we may propose it as an Eclipse project in the future.

One of the more exciting developments is that this article simply describes the beginning of our journey and where our internal development processes were about six months ago. Since then, we’ve developed a new “internal engineering system” or “meta-agent” that strongly mixes the features of workflow engines like Eclipse ICE with systems programming, fast distributed memory, and normal agents (if I can get away with calling agents “normal”). I’m not sure it is doing anything interesting yet, but it’s sure going to fun finding out!

I’m very grateful for the collaboration and discussion with my colleagues at TACF, including John Scrivani, Vasiliy Lakoba, and Lucinda Wigfield. I learned a lot about big data for forestry and tracking trees, and I look forward to seeing what Tracee and Stager can do next. I am also grateful to the US RSE community for accepting and attending my talk.

Did you know you can hire Band Gap if you need help with software engineering, AI & ML, or all sorts of other computing projects? Email [email protected] if you have questions or would like to receive our capabilities statement.