DEV Community: Teo Furlan

How I Built a Learning System Inside My AI Coding Workflow (Using Obsidian)

Teo Furlan — Fri, 30 Oct 2026 21:55:25 +0000

Coding with AI agents carries a quiet trap: the illusion of competence.
Tasks close in record time, architecture moves forward, and everything builds cleanly. But at the end of the day, an uncomfortable question remain: Did I actually learn any of this, or was I just acting as a prompt supervisor?

In an intend to prevent AI from turning into a mindless "code vending machine," I designed an integrated learning system where the agent doesn't just write software—it documents my learning journey, maps concepts, and actively tests my comprehension.

Here is how the system works:

The Core Rule: The Vault Stores Comprehension, Not Code

I maintain an Obsidian vault (Engineering/) directly connected to my AI agent sessions via automated hooks and skills.

The foundational rule is strict: the vault never duplicates repository docs or generic boilerplate. It only captures:

Mental models and architectural analogies.
Real trade-offs and discarded alternatives.
Current Architecture Decision Records (ADRs) and their change history.
Especific markers distinguishing verified facts [V] from assumptions [A].

System Architecture: 3 Key Layers

Architecture of the learning pipeline: from session classification to milestone exams.

1. Contextual Project Modes (`learn`, `log`, `off`)

Whenever an agent session starts inside any repository, it checks the configured mode:

learn: Full pedagogical depth. Generates architecture notes, links concepts, and triggers milestone exams.
log: Lightweight mode. Only tracks architectural decisions (ADRs) and concept links.
off: Zero overhead. No notes written to the vault.

2. Background Concept Distillation

Whenever I ask a conceptual question during a session—such as "What is backpressure?" or "Why prefer this concurrency pattern here?"—the agent answers in chat and quietly reports:

Saved "Backpressure" to Concepts.

Concepts start small: a 3–5 line Term (definition, quick example, and the context where it surfaced). As the same pattern appears across different projects, it matures in place into a deeper Concept. Links are embedded organically in the body text, weaving a knowledge web over time.

3. Milestone Exams (Active Recall)

Passive note-taking doesn't build long-term retention. To counter this, whenever a milestone is reached in a learn project, the agent offers an exam:

10 to 12 open-ended questions (no multiple choice—multiple choice tests recognition, not recall).
Grounded strictly in the actual repository code, decisions made, and real bugs encountered during development.
Covers real code reading, failure scenarios, and change propagation ("If we swap dependency X tomorrow, what could break and why?").
Supports an oral mode where questions are evaluated through speech and voice transcription.

If I cannot defend and explain why an architectural path was chosen, the task is not considered truly learned.

What Changed in My Daily Routine

True Retention: The codebase doesn't feel foreign when returning to it two weeks later.
Cross-Project Synergy: A concept learned while fixing a bug in Rust or Go naturally connects to an architectural decision made months later in a TypeScript API.
AI as a Socratic Partner: The agent transitions from an autocomplete utility into a technical partner that demands conceptual clarity before and after shipping code.

If you are using AI agents to write software, consider designing your workflow to amplify your own understanding, not replace it.

Do you have a system for retaining what you learn while coding with AI? Let's discuss your setup in the comments below.

I highlight paper books. A small open model types my quotes while I sleep

Teo Furlan — Sun, 25 Oct 2026 04:33:04 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

I read on paper, with a highlighter in hand. Every quote that stops me ends up in a Notion database: knowing I'll keep what I mark makes me read more carefully, writing it down helps me remember it, and later I can find the right line when it comes up in a conversation or in something I'm writing.

The chore is in between: sitting down with the book, finding each highlighted passage again and typing it word by word. By the end of a book I have dozens of highlighted lines and no will to copy them.

Dogear removes that chore. While reading, the only extra thing I do is take a photo of each page I highlighted. Overnight, a small open-weight model running on a plain CPU in the cloud reads the photos and pulls out exactly the highlighted passages. In the morning I review them and stay in full control: I can keep, edit or delete any quote, and add one the night run missed. What I keep stays in my library, and a Notion export is next.

Dogear works end to end today: I photograph a page from the app, the night run reads it, and the quotes wait for me in the morning. What's still ahead lists what comes next.

Demo

Try it: dogear-web.onrender.com. Anyone can sign in and start their own library. Page photos are read by the next nightly run (06:00 UTC) and deleted afterwards.

The video walks through the whole loop with public-domain books. The screens are the real app with demo data, and the quotes and crops come from Dogear's own pipeline (Tesseract and Gemma 4 on a CPU) run on a page of Pride and Prejudice. The night-run numbers are a real line from the Render log.

Code

teofurlan / dogear

Photograph highlighted pages of paper books; a small open model extracts the quotes overnight.

Dogear

Photograph the pages you highlighted in a paper book. Overnight, a small open-weight model on a plain CPU types out exactly the highlighted passages. In the morning you review them.

Live app · Demo video · API reference

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 3: Slow and Steady.

What it does

Reading on paper with a highlighter is great; copying the highlights out afterwards is not. Dogear moves that chore to a night job and keeps you in charge of the result:

Add a book by typing it or photographing its cover. OCR suggests the title and author; nothing is saved until you confirm.
Photograph each page you highlighted while the book is still open. The photo goes to a private bucket.
Overnight, a cron job reads every pending page with Tesseract and Gemma 4 on a CPU, stores each highlighted passage as a…

View on GitHub

How I Built It

My highlighter is almost invisible to a computer

Before writing any app code, I tested the riskiest assumption with three real photos taken on my lap, one-handed. In a phone photo, a highlighter barely changes the paper: its color saturation measured about 7 out of 255, which is basically gray.

What worked was the Lab color space, which separates brightness from color. Instead of looking for a particular color, the code measures how far each pixel drifts from the paper's own tint, so it doesn't care which pen I picked. Light was the next trap: with half a page in shadow, one paper tint no longer fit the whole photo. The fix was to fit the tint as a smooth surface across the page and compare each pixel with the tint at its own position. That found every highlighted block on my test pages.

The model is a good reader and a bad judge

My first plan was to hand the whole photo to Gemma 4 (e4b, running in Ollama) and ask for the highlighted text. On one page it found 1 of 3 passages. On the other, it confidently returned the chapter title, which isn't highlighted at all. Given only a crop, it read well, but once it silently dropped a whole clause. A quote app that drops words is worse than no app.

So the design flipped: the model reads, the code decides.

Color decides what is highlighted. It's deterministic and cheap.
OCR finds where every word is. Tesseract returns a box for each word, and a word belongs to a quote when enough of the paper under it carries highlighter. That found the exact first and last word of every passage, even when a highlight starts mid-line.
Two readers, compared. OCR knows where but misreads letters. Gemma writes clean text but can skip words. Each block is read by both, and Gemma's version is kept where they agree.
Disagreement is flagged for me, with the photo crop next to the quote. Flags only point my attention: every quote stays mine to keep, edit or delete.

On my two test pages, the pipeline found 3 of 3 passages on each, with no false quotes. Watching Gemma fail taught me two fixes: send crops shaped like a text selection instead of scattered word boxes, and compare readings in a way that forgives OCR's glued words and the page's line-break hyphens. In the end, 4 of the 6 quotes came out with both readers agreeing, and the other 2 were flagged, exactly where OCR scrambled the text near the book's gutter. No wrong quote was presented as confident.

Slow on purpose

None of this has to happen when I take the photo, so it doesn't. A nightly cron job on Render processes the day's photos on a plain CPU, with no GPU. The model weights are baked into the Docker image, and a page takes about a minute and a half on four CPU cores, so even a heavy reading day of 30 pages is done in under an hour, long before I wake up. The job first ran on an 8 GB instance for about 2.5 cents, but Gemma peaked near 7.4 GiB there, so it moved to 16 GB for about a cent more per night.

From a script to an app

Around the pipeline, I built a FastAPI server and a React PWA:

My books, only for me. Sign-in goes through Auth0, the server checks every token, and books live in MongoDB Atlas tied to the verified account. Tests make sure one reader never sees another reader's books.
A library that looks like a book catalog, with covers from Open Library. When there's no reliable match, a book gets a plain placeholder instead of a guessed edition.
Adding a book, the lazy way. I type it or photograph the cover. OCR suggests the title and author, nothing is saved until I confirm, and the cover photo is never stored. Same rule as the quotes: the machine suggests, I decide.
Photos go to the night run, privately. From a book's page I photograph what I highlighted; the phone shrinks the photo and the server stores it in a private Cloudflare R2 bucket. The nightly job claims each pending page, writes its quotes with a small crop of the passage, and deletes the photo. If Gemma can't read a page, the photo waits for another night instead of settling for OCR alone.
The morning review. Each quote sits next to the crop it came from. I keep, edit or delete it, or add a passage the run missed; where OCR and Gemma disagreed, the app says so.
A careful PWA. Its service worker keeps only a public "you're offline" page. Sign-in data, books and photos never touch its cache.

What's still ahead

The full loop works: library, page capture, night run and morning review. Next come search by meaning across my quotes, the Notion export, deleting a book together with its quotes, and a dedicated in-app camera.

Why Does Open Innovation Matter?

My reading stays mine. My photos and highlights are read by a model running in my own night job, not sent to a third-party AI API.
It costs a few cents a night. A small open model on a plain CPU is cheap enough to run every night for years, with no per-request bill.
The model doesn't change under me. The whole design rests on knowing how Gemma fails. With the weights pinned in my image, tomorrow's model fails the same way today's does, so the checks I tuned against it keep working.
Swappable parts. The model and the OCR sit behind small interfaces, so a better open model can replace Gemma without touching the rest.

The Lazy Payoff

Before: in a dense book, I highlight 2 or 3 passages per page. Copying them is a 30 to 60 minute typing session, so I keep postponing it, and the quotes pile up in books I've already shelved.

After: one photo per highlighted page, taken while the book is still open, and a short review over breakfast. The review screen now exists, so I'll measure the real review time over the next books I read.

Prize Categories

Best Use of Gemma: Gemma 4 e4b reads every highlighted block, cross-checked against OCR.
Best Use of Render: the nightly CPU cron job that runs the extraction.
Best Use of MongoDB Atlas: each reader's books, stored per verified account.

Pricor: local AI reads the supplier spreadsheet, an exact engine does the math

Teo Furlan — Mon, 19 Oct 2026 05:01:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

Two suppliers send you their price lists. Supplier A's spreadsheet says 12.100,00 under Precio Bulto c/IVA (price per box, VAT included), 10+5 under Bonificación, and 100 under Unid x Bulto. Supplier B's says 92,00 under Costo Unit. s/IVA (unit cost, before VAT) and 8% under Dto.

Both are selling the same screw. Which one is cheaper?

You cannot tell until both lists speak the same language. Supplier A's screw costs 85.50 per unit: two chained discounts (not 15%), VAT removed, the box split into 100 units. Supplier B's costs 84.64. In many small Argentine shops, and at least one distributor I have talked to, someone does this translation by hand, for every supplier, in every supplier's own format, every time a list arrives. And next week, one of the columns will have moved.

Pricor (price + order) is a local app that turns those files into consistent, importable product records: supplier code, description, net unit cost and currency, with row-level traceability. It reads Excel or CSV, proposes what each column means, asks about whatever the file does not say, and shows every number from the original cell to the final cost before you approve it. Rejected rows stay visible and exportable; nothing is dropped silently.

Pricor prepares the file; it does not replace the shop's management system. Those systems already import price updates, but only in their own fixed formats.

Who would pay? The side hustle I have in mind is setting up and supporting a shop's recurring supplier imports, built on this tool. That is a hypothesis, not validated demand: I have not had a paying customer or measured time saved yet.

Demo

The video was built from screens recorded in the running app with Laya and Gemma 4 E4B running locally, using two small fictional lists ("Ferretería Norte" and "Distribuidora Sur") written for the recording. The narration is a local Kokoro voice.

A longer browser rehearsal on two lists from a real public supplier price page covered the full loop:

First import. Gemma's suggestions arrive with no answer preselected. I confirmed the columns and assumptions, inspected the calculation trace, approved, and downloaded the CSV/XLSX exports.
Next week's list. The same supplier's saved plan was reused. Pricor noticed that the price column had moved and followed the saved mapping instead of reading the wrong column.
Price report. Comparing the two approved lists: 514 increases, 118 decreases, 420 unchanged, 8 new products, 5 discontinued, and one +200% anomaly, across 1,057 and 1,060 accepted products.

To be clear about that run: the second list was simulated by a tool that perturbs a real list and records every change in a manifest. The exports were checked against every changed price and every added or removed code in that manifest, not just the totals. It demonstrates the behavior; it is not evidence of a real supplier's price update.

The arithmetic behind the example at the top, as the receipts in the demo show it:

12,100.00   per box, 21% VAT included
 × 0.90 × 0.95   chained discounts of 10% and 5%
 ÷ 1.21          remove VAT
 ÷ 100           units per box
=    85.50 net per unit

92.00       per unit, before VAT
 × 0.92          8% discount
=    84.64 net per unit

No model calculates those results.

Code

Repository: github.com/teofurlan/pricor

The application is Apache-2.0: backend, frontend, tests, the corpus download tooling (supplier files are linked from their public pages, not redistributed), the Laya fine-tuning tooling and the benchmark. The fine-tuned Laya weights are not published yet; the training script reproduces them.

How I Built It

The whole design is one rule: models interpret, the engine executes, the user decides.

Pricor sits in front of the system a shop already uses (or the one it is moving to), as a local filter with three layers: Laya, then Gemma, then you.

A deterministic profiler finds the header row, row types, apparent column types and number formats (12.100,00 is not 12.1).
A fine-tuned multilingual Laya model classifies each column into a closed set of roles. Columns it is unsure about go to Gemma 4 E4B, running locally through Ollama. Whatever is still uncertain goes to the user.
Questions are generated deterministically from what the plan is missing: does the price include VAT? Is it per pack or per unit? Which currency? Gemma may suggest an answer and show its (uncalibrated) confidence, but nothing is accepted on the user's behalf.
The executor only understands a closed catalog of operations: parse numbers, apply chained discounts, remove VAT, split packs into units, map values, normalize text and, optionally, convert currency. It never runs model-generated code.
FastAPI serves a React frontend. SQLite stores approved plan versions and price history. Exports come with a separate rejected-rows report.

Plans are saved per supplier. Before reusing one, a fingerprint checks each column's position, normalized header and apparent type. If a column the plan needs is missing, the affected rule is blocked instead of quietly producing a cost. Currency conversion keeps the original value and currency, and snapshots the exchange rate used for that run.

Memory is explicit, local and cited

Pricor can remember things like "this supplier's prices always include VAT". Ollama produces bge-m3 embeddings, SQLite stores them, and Python ranks matches by cosine similarity.

A memory is created only when the user writes one, or accepts a Gemma suggestion and clicks Remember this. Never automatically. The most relevant memories are passed to Gemma as numbered, untrusted data; Gemma must cite any memory a suggestion relies on, and the UI shows the citation. A reply citing a memory that was not supplied is discarded entirely. If memory is unavailable, the import continues with a notice. A Memory panel lets the user view, edit and delete everything.

In one manual check (not a benchmark), with one note about one supplier and one about another, Gemma's VAT and per-pack suggestions for the first supplier cited the right note and not the other.

The benchmark did not justify automating everything

The benchmark in the repo has only 29 held-out columns from two distributors, so read it as a sanity check, not a leaderboard:

Classifier	Correct	Accuracy
Keyword/type heuristics	24/29	82.8%
Laya zero-shot	18/29	62.1%
Laya fine-tuned	22/29	75.9%
Gemma prompt-only	25/29	86.2%

In the whole-sheet cascade, 11 columns were resolved automatically (10 correctly) and 18 of 29 still went to the user. That is the honest result: on this data, the app should ask. Laya took about 35 ms per column on GPU; Gemma averaged about 11.4 s per sheet (RTX 4060 Laptop GPU). Those are different units, not a speedup claim.

The caveats are documented next to the numbers: thresholds were chosen on partly synthetic validation data, the test set lacks some roles, the heuristics were written after their held-out headers had been seen, and two labels were corrected after the first run. A heuristics-plus-Laya agreement stage I tried afterwards showed no advantage, so the shipped cascade does not use it.

Bugs worth telling

Percentages. Excel stores a cell displayed as 21% as 0.21. Lose the number format and 21% VAT becomes 0.21% VAT, which still produces a plausible-looking cost. The reader now keeps that meaning at the spreadsheet boundary, without touching the engine's percentage-point contract.

A second discount column. While recording the demo, I found that when a list has two separate discount columns, the plan builder uses only the first one. Chained discounts in one cell (10+5) are handled correctly, which is what the demo uses, but a second column is currently ignored without a question, which breaks the app's own "nothing silent" rule. Fixing that is next on the list.

The backend suite passes 1,219 tests (three live-model tests deselected) and the frontend suite 194. None of that proves compatibility with every Excel file a supplier can produce.

Where I'm Starting From

I did not start from a model looking for a problem. I started from what is publicly visible:

Supplier price lists change often in Argentina. Press reports describe kiosks receiving price-change notices from two or three suppliers a week. Inflation has slowed in 2026, so this is less urgent than in 2023–24, but lists still change.
Management systems already import prices, but only in their own format. The documentation of several local systems (Dux, ADM Global, Flexxus) describes re-importing a file whose columns match their fields, or filling a fixed template. None documents per-supplier saved mappings, pack-to-unit conversion, or chained discounts with VAT included. That gap is my inference from their docs, not a survey.

What people told me so far

After publishing the first version of this post, I talked to two people. Two conversations are not validation, but they changed how I describe the project:

An IT colleague at a distributor confirmed that the product data suppliers send is loaded into the distributor's system by hand, and said a tool like this would help.
A business owner told me Pricor was not very useful for their specific case, but could be very useful for automating data entry into new or existing systems: shops and companies moving from paper records to a digital system. They offered to ask colleagues whether it would help them.

That second idea is broader than supplier price lists, and I have not tested it. The next step is still the same: a supervised trial with a real list someone already handles by hand.

Why Does Open Innovation Matter?

The open models are in the import path, not bolted on as a chatbot. Laya and Gemma read the supplier's data, and their limits directly decide when the app has to ask the user.

Privacy. A shop's supplier lists and costs never leave its own computer to reach a hosted model provider.
Cost. A shop imports the same suppliers every week. With local inference, reusing a plan has no per-call fee. Electricity, hardware and support are not free, but there is no meter running.
Offline. Imports work without internet. Only the optional online exchange-rate refresh needs a connection; a cached or manually entered rate works offline.
Fine-tuning and measurement. Open weights let me fine-tune Laya for this narrow task and publish exactly how I measured it. It improved over its zero-shot baseline but did not beat Gemma or the heuristics on this small set, and I can say so because everything is inspectable and replaceable.
Licensing. Gemma 4 is Apache-2.0, so it can ship inside something a shop pays for.

The next step is not more features: it is a supervised trial with a shop or distributor, using a list they already load by hand. Compare Pricor's output against their current import, watch where the confirmation steps confuse them, and ask what recurring support would be worth paying for. Until then, the business case stays provisional.

Prize Categories

Best Use of Gemma: Gemma 4 E4B runs locally through Ollama. It classifies the columns Laya is unsure about, suggests answers to the plan's questions, and uses explicitly saved memories as cited context. It is not fine-tuned, and it never does price arithmetic.

I am also entering for the overall prize. I do not claim any other partner integration.

Loci: A Walk You Have to Remember

Teo Furlan — Mon, 12 Oct 2026 03:16:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I often walk my dog, and too many walks become the same loop: I hesitate over where to go, then choose the familiar route again. I do the same when I head somewhere nearby, like the supermarket. I wanted a reason to explore on foot, and a little more purpose than scrolling through a walk.

Recently I enabled my phone's warning for using it while walking. I was surprised by how often I was reading social media or chatting as I moved. That made me want to try using technology against the pull of technology: a memory game that gives me something to think about, then asks me to put the phone away.

Loci is an Android app that plans a walking loop through real places near you, turns them into one short mnemonic story, and then hides the map. You look at the route once, put the phone in your pocket, and walk it from memory. The screen is the shortest part of the experience: a minute to memorize, then the rest of the walk is outside.

Meet Loci

Loci is also the name of the character you talk to: a small pixel-art companion on a black field. It waits on the home screen, listens while it plans, gives a hint when you ask, and celebrates when you finish a route. Instead of filling in a form, you ask it for a walk, by typing or by voice, and it answers with a route made of places around you.

Ask Loci	Loci listens while planning

Every landmark is an original 32×32 pixel sprite on a night map, so the places become memory hooks rather than interchangeable pins.

How to play

Ask Loci for a walk or run ("20 min walk, green areas"), then review the planned course and its story.
Study the landmarks while the map is visible. The story is the cue to remember.
Tap Hide map & start, put the phone in your pocket and follow the story from memory. GPS keeps checking with the screen off, and a vibration marks each checkpoint. Order doesn't matter in the current mode.
Ask for a hint if you need one: it replays that place's story fragment and gives a direction, for half credit. Giving up is always available and reveals the map.
At the end, Loci shows what you remembered, with a badge for each place.

Walk from memory	Results

The phone is never locked by the app, so calls and emergency help remain available. Planning requires connectivity; a prepared run works offline. Loci is not turn-by-turn navigation and makes no route-safety guarantee.

Demo

Every screen in the video is the real release build (v1.0.0), recorded on the Android emulator. The only simulated thing is the GPS position (San Telmo, Buenos Aires), moved in small steps to walk the route. The narration is synthetic, generated locally with the open-weight Kokoro voice model.

Try it: install the Android APK from the v1.0.0 release (a sideloaded build, not a Play Store one).
Website: lociwalk.vercel.app

Code

teofurlan / loci

Loci: a memory walk. Gemma turns a random loop of real OpenStreetMap landmarks into a method-of-loci story; you look once, pocket the phone, and walk it from memory.

Loci

Loci is an Android app that plans a walking loop through real landmarks, turns it into a mnemonic story, and asks you to walk it from memory with the phone in your pocket. It is built for the DEV Hacktoberfest 2026 challenge (hf26, Gemma category).

You ask Loci, a small pixel-art companion, for a route ("20 min walk, green areas") by typing or by voice. Loci finds named places near you in OpenStreetMap and links them into a short story using the method of loci: each place becomes a vivid image, and the images follow one another. You read (or listen to) the story once with the map visible, then hide the map and walk. GPS confirms each checkpoint with a vibration, and at the end Loci shows how many you remembered.

See it

Website: lociwalk.vercel.app
Demo video (1:29, the release build on the Android emulator with…

View on GitHub

How I Built It

Gemma is the mechanic

Gemma isn't a chat feature added for decoration. Without a story that connects places to memorable images, there is no memory challenge to carry away from the screen.

Gemma has two jobs:

Parse the request. It turns free text ("30 min run, I remember places better than street names") into bounded route parameters: distance or time, pace, preferences, story style. The app validates and clamps every value.
Write the story. It writes one short mnemonic fragment per landmark, using the method of loci: each place becomes a vivid image, and each image leads to the next. The input is only landmark IDs, names and kinds. No coordinates go to the model, and the IDs that come back are checked against the fetched set.

Gemma never gets to invent landmarks or coordinates. The places come from OpenStreetMap; the model only supplies the words. Voice input uses Android speech recognition and feeds the same text path.

Architecture

The route and memory-game logic is plain TypeScript, with external services behind small adapters:

Free-text request ──> intent parser ──> bounded route intent
                                           │
GPS origin ──> loop candidates ──> Overpass landmarks ──> snapped checkpoints
                                           │
                                           └──> story generator ──> Gemma via Vercel proxy
                                                                      │
                         Expo / React Native screens <── route + story┘
                         GPS fixes ──> hit detection ──> score + vibration

The domain handles distance calculations, randomized loop candidates, landmark selection, GPS hit detection, session state, hints and scoring. Application code composes those steps into route planning. Adapters connect the ports to Overpass mirrors, LLM clients, story templates and cache, and local visited-landmark history. Expo and React Native provide the Android app; MapLibre draws the map with OpenFreeMap tiles. I wrote the domain logic, the adapters and the pure view models behind the screens test-first; the suite has 586 Jest tests.

In production, the app calls the open-weight Gemma 4 model through the Gemini API behind a small Vercel proxy. The proxy fixes the model, caps input and output sizes, applies best-effort per-IP rate limiting and keeps the API key server-side instead of inside the APK. If generation fails, Loci falls back to a cached or template story.

The screen-off run is deliberately simple: it checks proximity to the prepared checkpoints, not whether I followed a particular street between them. Hints and giving up are always available, so the score is never the point of the walk. That balance matters to me: I want a small reason to pay attention to where I am, while still being free to keep walking or stop.

Lessons learned

Leave room for model thinking. Gemma's reasoning could use up a small token budget and leave an empty visible answer. More headroom fixed the case I saw.
A failed request can hide the next one. A transient proxy 502 plus an over-eager, client-wide cooldown meant the story request could silently fall back to a template. Retrying transient proxy failures and limiting the cooldown to Ollama fixed it.
Public data services need alternatives. Overpass returned 504s, so the app tries mirrors instead of depending on a single endpoint.
Screen-off GPS needs Android foreground work. A foreground service keeps the run's location tracking alive while the screen is off.

Why Does Open Innovation Matter?

Loci is built from open pieces end to end, and each one does a job a closed service would have made harder:

Open map data is what keeps the model honest. The places come from OpenStreetMap through Overpass, with names and kinds for parks, monuments, churches, artworks and more (the app draws 18 kinds). Because the real place data is open and queryable, the model never has to "know" a neighborhood: it only writes words about places the app already fetched and verified.
An open-weight model can move. The same prompts and validation run against Gemma on my laptop through Ollama during development, at no cost and with no account, and against hosted Gemma in production. Swapping is configuration, not a rewrite, and running Gemma on the phone itself is a realistic next step rather than a dependency on one vendor.
No map API keys or quotas. MapLibre with OpenFreeMap tiles means the map costs nothing to show and can't be switched off by a billing change.
Small and inspectable. The proxy is a single open function with fixed model, size caps and rate limiting, so anyone can see exactly what leaves the phone: landmark names and kinds, never your coordinates.

Where it worked better than a closed approach: I could develop the whole story pipeline offline against a local model, test failure paths for free, and keep the app's promise ("the model only writes the words") enforceable in code, because both the data and the model are open.

Prize Categories

Best Use of Gemma: Gemma parses every request and writes every story; the route and the game are built around what it produces.

What's next

Take Loci on a longer outdoor walk and share where it went, the distance and the score.
Let Loci ask a clarifying question when a request is vague.
An ordered quest mode, where remembering each place unlocks the next clue.
On-device Gemma, so planning can work without a connection too.

DEV Community: Teo Furlan

How I Built a Learning System Inside My AI Coding Workflow (Using Obsidian)

The Core Rule: The Vault Stores Comprehension, Not Code

System Architecture: 3 Key Layers

1. Contextual Project Modes (learn, log, off)

2. Background Concept Distillation

3. Milestone Exams (Active Recall)

What Changed in My Daily Routine

I highlight paper books. A small open model types my quotes while I sleep

What I Built

Demo

Code

teofurlan / dogear

Photograph highlighted pages of paper books; a small open model extracts the quotes overnight.

Dogear

What it does

How I Built It

My highlighter is almost invisible to a computer

The model is a good reader and a bad judge

Slow on purpose

From a script to an app

What's still ahead

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

Pricor: local AI reads the supplier spreadsheet, an exact engine does the math

What I Built

Demo

Code

How I Built It

Memory is explicit, local and cited

The benchmark did not justify automating everything

Bugs worth telling

Where I'm Starting From

What people told me so far

Why Does Open Innovation Matter?

Prize Categories

Loci: A Walk You Have to Remember

What I Built

Meet Loci

How to play

Demo

Code

teofurlan / loci

Loci: a memory walk. Gemma turns a random loop of real OpenStreetMap landmarks into a method-of-loci story; you look once, pocket the phone, and walk it from memory.

Loci

See it

How I Built It

Gemma is the mechanic

Architecture

Lessons learned

Why Does Open Innovation Matter?

Prize Categories

What's next

1. Contextual Project Modes (`learn`, `log`, `off`)