# Forecasting a weather-driven risk for farmers, from a research paper to agents

> A sensor network, a white paper from an established Australian scientific organisation and some research code became a production system that forecasts when field conditions turn risky: data lake, models, accuracy reporting and an installable app. Built by hand, then modernised with Claude Code, which now runs it.

- Client: An Australian agriculture-technology company with a large IoT sensor network (Agriculture technology)
- Role: Architect, data scientist and lead engineer, Nicolas Dao
- Status: Live. At Cloudless Labs
- Capabilities: Machine learning, Data lake, Serverless, Agentic programming, Progressive web apps
- Web page: https://cloudlesslabs.com/work/research-to-forecasts/

## Outcomes

- A scientific white paper and non-production research code turned into forecasts that run at scale, every day.
- Forecast accuracy measured continuously, station by station, and reported to the business.
- A neural network later replaced, with agentic programming, by a far more robust prediction method, with no downtime.
- An AWS bill that stays very lean compared with a conventional architecture.

## The situation

Some farm operations depend on a few hours of weather. Do them at the wrong moment and the work is wasted, or worse, it causes harm beyond the farm. Farmers need to know, before they start, whether the next hours are safe.

The company runs a network of weather stations that measure the conditions those decisions depend on. The forecasting method came from a white paper by an established Australian scientific organisation, and the only code was research code, a mix of MATLAB and Python, nowhere near production.

## What I built

The whole system, end to end:

- **Ingestion at scale** from the station network into Aurora MySQL, and into a **data lake** on S3, catalogued with AWS Glue and queried with Athena, so years of readings could be analysed cheaply ([why that design](https://cloudlesslabs.com/stack/guides/data-lake/index.md)).
- **The forecasting model.** I worked from the white paper, and found that the paper and the code didn't always agree. I filled the gaps, ported the method to Python, and improved it with a custom neural network trained on Amazon SageMaker, the same tooling as our [weather forecasts](https://cloudlesslabs.com/work/weather-neural-nets/index.md).
- **Accuracy, measured all the time.** Reporting tools and admin panels compare every forecast with what each station then measured, so the business can state its accuracy, station by station, with numbers.
- **A progressive web app** in React that works on desktop and installs on a phone, for the people deciding whether to go ahead.
- **All of it serverless,** defined with Pulumi. What I'm proudest of is the cost: it scales with the network, and the AWS bill is a fraction of what a conventional architecture would cost. It still is.

## Then, AI took over the maintenance

The first version was crafted entirely by hand: front end, middleware, back end and security. Then we modernised it for agentic programming, and today it is fully managed through agents, under our review.

- **A new admin panel,** built with Claude Code, far better than the original.
- **A better model.** With agentic programming, we replaced the neural network with a new prediction method that made the forecasts much more robust and resilient.
- **No downtime.** Every one of those migrations happened while the system kept forecasting.

The first BI layer was Amazon QuickSight. It's convenient for connecting data that already sits in AWS, and painful to work with for everything after that. We replaced it with bespoke dashboards built with Claude Code, and that's now our advice to every client ([why](https://cloudlesslabs.com/stack/aws-quick-sight/index.md)).

## Why it matters to you

It's the arc most systems will follow: built by hand, then handed to agents for the routine work, with a human owning the design and the results. The system got better, not just cheaper to maintain. If you have a system you're afraid to touch, that's the path we'd take it on.

## Built with

- [Amazon Web Services (AWS)](https://cloudlesslabs.com/stack/aws/index.md): My default in The Stack
- [AWS Lambda](https://cloudlesslabs.com/stack/aws-lambda/index.md): My default in The Stack
- [Aurora PostgreSQL](https://cloudlesslabs.com/stack/aws-aurora/index.md): Use when it fits in The Stack
- [S3 + Glue + Athena](https://cloudlesslabs.com/stack/aws-athena-data-lake/index.md): Use when it fits in The Stack
- [Amazon S3](https://cloudlesslabs.com/stack/aws-s3/index.md): My default in The Stack
- [Claude Code](https://cloudlesslabs.com/stack/claude-code/index.md): My default in The Stack
- [Pulumi](https://cloudlesslabs.com/stack/pulumi/index.md): My default in The Stack
- [Amazon Quick Sight](https://cloudlesslabs.com/stack/aws-quick-sight/index.md): Never in The Stack
- Scientific research
- Python
- Amazon SageMaker
- AWS Glue
- React

## Related

- [Athena or DuckDB?](https://cloudlesslabs.com/stack/guides/data-lake/index.md): the decision guide behind it
- [Cutting an AWS bill from US$240k a year to under US$40k](https://cloudlesslabs.com/work/aws-bill-cut/index.md): a related project
- [Real-time ingestion for a large farm-sensor network](https://cloudlesslabs.com/work/realtime-iot/index.md): a related project
- [Deep neural networks that forecast the weather](https://cloudlesslabs.com/work/weather-neural-nets/index.md): a related project
- [From legacy ASP.NET and stored procedures to Node.js on serverless](https://cloudlesslabs.com/work/dotnet-to-serverless/index.md): a related project
- [Every project](https://cloudlesslabs.com/work/index.md)
- [How we work](https://cloudlesslabs.com/about/how-we-work/index.md)
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)