A tiny nature journal powered by open-weight AI, built to get people away from their screens and back into the world.
What if we tracked changes in nature the same way we track changes in code?
As developers, we're constantly looking for differences. We compare versions, inspect commits, hunt for bugs, and write changelogs to remember what changed and why.
But outside our screens, changes are happening everywhere.
A tiny plant is growing between two cracks in a footpath. Shadows move across a campus wall. Leaves fall, clouds change shape, and a patch of grass looks different from the last time we passed it.
Most of the time, we walk straight past them.
I built Patchnotes for a simple reason: I wanted to turn the idea of going outside into something small, engaging, and worth returning to, using a concept familiar to anyone who has spent time around code.
Nature has commits, too. We just rarely bother to read them.
🔗 Live demo: https://patchnotes-nature-has-commits-too.ai.studio/
💻 Source code: https://github.com/vendetta2025/hackweek1
🤖 Open-weight model: Gemma 4 26B A4B IT (gemma-4-26b-a4b-it)
🌱 The problem: we're surrounded by things we don't notice
Modern apps are incredibly good at keeping us on our screens.
They give us feeds to scroll, notifications to check, streaks to maintain, and endless content to consume. Even apps designed to encourage healthier habits can turn those habits into another digital activity.
I wanted to approach the problem from the opposite direction.
Instead of building another app that asks users to spend more time inside it, I wanted to create one whose most important instruction is to put the phone away.
That became the central design principle behind Patchnotes:
The screen should be the shortest part of the experience.
The app gives you something specific to look for, lets you step outside and observe it yourself, and helps you document what you noticed after you return.
It doesn't require you to be a botanist, an experienced hiker, or someone who already knows a lot about nature. You can start with a five-minute walk around your campus.
The goal isn't to turn every walk into a productivity exercise. It's simply to help you pay attention.
🍃 What is Patchnotes?
Patchnotes is an AI-powered nature journal built around three stages:
Discover → Observe → Document
Rather than generating a long list of activities and expecting users to figure out what to do, it turns a small amount of user input into one manageable outdoor mission.
1. Discover — find something worth noticing
The user selects an environment, such as a campus, street, park, garden, or balcony.
They then choose how much time they have—five, ten, or fifteen minutes—and whether they want to walk around or stay in one place.
From these choices, the AI generates an observation mission.
A mission might ask you to notice different leaf shapes, watch how sunlight falls across a wall, listen for outdoor sounds, or look for small patterns in your surroundings.
Each mission includes a short title, a clear activity, things to observe, and a question to think about.
The important detail is that the activity should be specific enough to get someone started but simple enough that they don't need to keep checking their phone for instructions.
Once the mission is ready, the idea is to lock the screen and go outside.
2. Observe — leave the screen behind
This is the part of Patchnotes that matters most, even though the app has almost nothing to do during it.
You complete the mission in the real world.
Maybe you notice that two trees growing near each other have different-looking leaves. Perhaps a nearby wall creates a sharp boundary between sunlight and shade. Maybe you hear a bird you hadn't noticed before.
You don't need to prove anything or find something extraordinary.
You simply observe.
When you return, you tell Patchnotes what you actually noticed.
That distinction matters. The user supplies the real-world observation; AI should help organise and reflect on it, not invent an experience that never happened.
3. Document — turn an observation into a Patchnote
After the user describes their observation, AI transforms it into a concise field note.
A completed entry might look something like this:
PATCH #001 — The Wall's Shadow
Observation
The plants growing near a wall appeared smaller than the plants in a more open area. The wall also created a large shaded region.
A possible explanation
Differences in sunlight might affect plant growth, although water availability, soil conditions, and other factors could also explain the difference.
Next visit
Return to the same location and observe whether the plants in the shaded area look different.
This is an illustrative example of the intended output, not a claimed result from a particular field test.
The AI should distinguish what the user actually observed from what might explain it. A possibility should remain a possibility; the application shouldn't turn a few sentences into an unsupported scientific conclusion.
Finally, the user can save the entry in My Patchnotes, creating a personal journal of small discoveries.
🧠 Why use open-weight AI?
This is the question that matters most for the Hacktoberfest Open-Source AI Challenge.
It would have been easy to add a conventional closed-model API to a nature-themed website. But that would have missed an important opportunity to make the underlying AI technology part of the project's identity.
Patchnotes is designed around a configurable open-weight model that performs the two central AI tasks:
- Generating missions based on the selected environment, activity, and available time.
- Turning a user's actual observation into a structured, thoughtful field note.
The model isn't there merely to provide a conversational interface. Its purpose is to help bridge the gap between an outdoor experience and a useful written record.
Choosing openness without making setup painful
I also wanted to keep Patchnotes accessible to people who don't want to download a large language model, configure a local runtime, or troubleshoot a complicated installation before trying a simple nature journal.
For that reason, the intended deployment uses hosted inference for the open-weight model rather than requiring every user to run a model locally.
That is a deliberate trade-off.
It reduces setup friction, but it also means the AI features depend on the configured inference provider, its availability, and its usage limits. Hosted inference is not the same as running fully offline.
The value of the open-weight approach is the ability to choose and replace the underlying model instead of designing the application exclusively around one closed model provider.
What about privacy?
The journal uses browser-local storage to keep saved observations available on the same browser and device.
That means the application doesn't need a journal database, a user account, or a synchronisation service simply to remember what someone wrote.
It also means entries aren't automatically synchronised across devices, and clearing the browser's site data can remove them.
However, locally saved journal entries do not automatically make the entire application offline or private. When a user requests an AI-generated mission or field note through hosted inference, the relevant request is sent to the configured AI provider.
I consider that distinction important. Privacy claims should describe what the application actually does, not what we would like it to do.
The open-weight model provides flexibility over the AI component; local browser storage keeps the journal implementation simple. Neither should be confused with complete offline operation.
🛠️ How the application is put together
I deliberately kept the first version focused on the complete experience rather than building a large platform.
The core components are:
| Component | Responsibility |
|---|---|
| Web interface | Environment selection, mission display, observation input, and journal navigation |
| AI integration | Generate missions and transform observations into field notes |
| Browser storage | Save, restore, and delete journal entries |
| User interface states | Display progress, results, empty states, and errors |
Technology used in this build
- Development environment: Google AI Studio
- Frontend: React 19 (react: ^19.0.1, react-dom: ^19.0.1), Vite 8 (vite: ^8.3.0, @vitejs/plugin-react: ^6.1.1), TypeScript 7 (typescript: ^7.0.2).
- AI model: Google Gemma 4 26B A4B IT
- Inference provider: Google Gemini API (accessed through Google AI Studio)
-
Storage: Browser
localStorage
The implementation is intentionally limited in scope.
There is no need for accounts, a social feed, a location-tracking system, or a complex database to complete the core user journey.
The important engineering requirement is that the mission and field-note buttons perform real AI requests, display appropriate loading states, and report failures honestly. A successful-looking interface is not sufficient if the underlying AI request never works.
🎨 Designing for less screen time
One of the interesting design constraints was that Patchnotes needed to be attractive without becoming another product that encourages endless interaction.
The interface uses a restrained nature-inspired visual identity: warm cream surfaces, deep forest-green accents, readable typography, and a small number of clear actions.
The layout follows the user's journey instead of organising everything around a dashboard full of statistics.
The goal is to make the next action obvious:
- Choose a mission.
- Go outside.
- Return and record the experience.
- Save the observation.
There is no leaderboard to climb and no infinite feed to browse.
A nature journal should help users return to the world around them, not compete with that world for their attention.
🧪 Testing the idea in the real world
An app built for the Touch Grass theme shouldn't be evaluated only by looking at its screenshots.
Its most important test is what happens when someone actually takes it outside.
For the initial evaluation, I focused on the complete user journey: selecting a mission, generating the instructions, recording an observation, producing a field note, and saving the entry.
Field-test record:-
Location or setting: Garden, staying in one place (stationary observation).
Mission attempted: Stay still in the garden and observe subtle movements in the natural environment without touching anything.
What I observed: The wind swayed the leaves back and forth. Staying in one position helped me notice their movement instead of simply walking past them.
What worked: The stationary activity was simple and easy to follow. It encouraged me to slow down, pay attention to a small detail in nature, and appreciate something I might normally overlook.
What needs improvement: The mission could provide a more specific observation cue, such as comparing the movement of leaves on different branches or noticing whether the leaves moved continuously or in short bursts.
The technical checks also matter: saved entries should survive a page refresh, individual entries should be deletable, and a failed AI request should produce a visible error rather than fabricated output.
I don't want to claim that every mission is perfect or that the model can reliably explain everything people see outdoors. That would be an unrealistic expectation for a lightweight observation tool.
The point is to help users notice more, not to replace their judgment with an AI-generated answer.
⚖️ Trade-offs and limitations
Patchnotes is a focused prototype, not a scientific instrument or an ecological monitoring platform.
It has several deliberate limitations:
- Hosted inference requires connectivity. The current approach avoids requiring users to install a large local model, but AI functionality depends on the configured provider.
- Free usage is not unlimited. Provider quotas and availability can affect how often the model can be used.
- Observations come from the user. AI cannot verify what the person actually saw.
- Interpretations can be wrong. The user should treat possible explanations as suggestions, not scientific facts.
- The journal is browser-specific. Saved entries are not automatically synchronised to another device, and browser data can be cleared.
- The app is intentionally small. It does not try to provide comprehensive species identification, mapping, weather forecasting, or ecological analysis.
These limitations helped define the scope rather than justify adding more features. I would rather deliver one coherent experience than attach a dozen APIs to a project whose purpose is to encourage less screen time.
🌍 What open innovation makes possible
For me, the most interesting part of this project isn't generating a title for a journal entry.
It's the possibility of building small, personal tools around open AI models without committing the entire application to a single closed model provider.
An open-weight model can be evaluated, replaced, and adapted as the project evolves. A different model could produce more concise missions, follow a different writing style, or handle uncertainty more effectively.
That flexibility matters even in a small project.
It also leaves room for a future version in which a fully local model could generate missions without a network connection, provided users have compatible hardware. That is a possible future direction, not a capability I claim for the current hosted-inference version.
The bigger lesson is that AI doesn't always need to produce more content, automate an entire profession, or keep a user talking to a chatbot.
Sometimes its most useful role is to provide a small nudge, then get out of the way.
🚀 What's next?
If I continue developing Patchnotes, I'd focus on improving the quality of the observation missions, testing whether users genuinely return to the same outdoor locations, and making the generated notes more faithful to what people actually report.
I would also evaluate different open-weight models and compare their usefulness, latency, instruction following, and ability to express uncertainty.
Rather than introduce a complicated gamification system, I'd like to understand whether a simple mission and a personal record are enough to encourage repeated observation.
The measure of success shouldn't be how much time users spend inside Patchnotes.
It should be whether they have a reason to put the phone away and notice something they might otherwise have missed.
🌿 The final thought
We write changelogs because changes matter.
A line of code changes. A bug disappears. A feature becomes possible. We record these moments so that they don't get lost.
The world outside changes too, often quietly and without asking for our attention.
Patchnotes is my small attempt to record a few of those changes.
One walk. One observation. One little patchnote at a time.
Nature has commits, too. Go outside and notice them.
Links
- Live demo: https://patchnotes-nature-has-commits-too.ai.studio/
- Source code: https://github.com/vendetta2025/hackweek1
Top comments (0)