DEV Community: Archana

Tendril: a garden assistant you barely have to open

Archana — Thu, 08 Oct 2026 00:12:52 +0000

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

What I Built

My balcony has a little garden: two Indian hibiscus, a money plant, jasmine, a blue aprajita, mint, tulsi and sadabahaar. All in pots. I water them every morning and every evening, without fail.

But a routine doesn't look at the sky. It waters the plants an hour before a downpour. It doesn't know a 38°C afternoon is coming. And it definitely doesn't go looking under leaves for aphids.

I didn't want another app to spend time in, though. The whole point of a garden is to not be on your phone. So I built Tendril, a garden assistant you barely have to open :)

It plans the week from the weather. Every Sunday at 7 AM it reads the forecast, and a small open model running on my own machine writes a plan: at most two tiny tasks a day, each under six words.
It checks the sky every morning. If rain shows up overnight, or a heat spike, it quietly rewrites just today's tasks.
The plan is one picture. It's made to fit a phone's lock screen, with the top third left empty for the clock. One glance and you're back outside.
Tell it what you did. Tap Done, or hold the mic and say something like "Watered the chillies, there are aphids under the tulsi leaves." It ticks off the watering, and since aphids are serious, it re-plans the rest of the week with neem oil first. It's set up for English and Hindi.
It only nudges once. After 6 PM, if something's still pending, the page shows one gentle line. That's it. No streaks, no guilt.
No accounts. Set your city, add your plants, scan a QR code, add it to your home screen. Done.

An app that wants you to close it as fast as you can sounds a bit odd, I know. But that's the whole idea :)

Demo

Searching for your city

Adding a plant

The morning plan

Telling Tendril what you did

Code

GitHub: https://github.com/pyarchana/tendril

How I Built It

Nothing fancy, and that's on purpose. Everything that thinks runs on the same machine:

Python and FastAPI for the app, with SQLite for the garden's memory.
Qwen 2.5 (3B), an open-weight model, running locally through Ollama. It writes the weekly plan and reads my notes.
faster-whisper, an open speech model, turning voice notes into text right on the CPU.
Open-Meteo for the forecast and city search. Free, and no API key.
Pillow to draw the plan picture. Every icon in it, the sun, the clouds, the little leaf, is drawn in code.
Docker Compose to run it all with one command.

A small model with big habits

A 3B model is tiny. That's what lets it run on a laptop, but it comes with some habits. My first real run taught me more than all my tests did:

It copied my instructions into its answers. I asked for a short reason with each task, and got back things like "At most 2 tasks per day; fewer is fine on quiet days." Thanks, very helpful :)
Then it copied my example onto every day. I showed it one sample day with "Water deeply at the roots". Next plan: deep watering, seven days in a row, for both plants.
It was slow. The first plan took 242 seconds.

The fix wasn't a bigger model. It was splitting the work. The model handles what it's good at: varied, plant-specific ideas, and making sense of messy notes. Plain code handles what it can't be trusted with. The weather rules (skip watering above 60% rain, shade above 35°C, a deep soak after three dry days) are applied last, over whatever the model said. Repeats get trimmed. Copied reasons get swapped for a real weather note.

Asking for compact JSON helped with speed too. All that indentation was costing about a third of the tokens. A week plan now takes about 100 seconds, which is fine for something that runs quietly at 7 AM.

Keeping the model honest

Every plan has to come back as proper JSON: at most two tasks a day, actions under six words, only plants I actually own, and every date filled in. The server checks each reply with Pydantic. If something's off, it asks once more and says exactly what was wrong ("unknown plant 'Rose'"). If that fails too, a simple rule-based planner steps in. So a plan always shows up, model or no model.

Voice notes got a small safety net as well. In one test the model filed "I watered the chillies… aphids on the tulsi" entirely under tulsi and forgot the watering. Now a tiny keyword check runs alongside it and catches the obvious things like "watered", matched to the plant named in the same sentence.

Making it feel like a lock screen

I wanted the plan to feel calm, like a wallpaper rather than an app. Dark forest green, two big cards, a weather pill that says something like "29° · Rain at 4 PM", and a strip of the next six days at the bottom. Headings are in Bricolage Grotesque, everything else in Figtree.

Why Does Open Innovation Matter?

My garden stays at home. My location, my voice and my plants' history live in one small file on a machine I control. Voice notes are turned into text on that same machine. The only thing that leaves is the garden's coordinates, to fetch the weather.
It costs nothing to run every day. A planner that wakes up every morning, forever, is exactly the kind of thing where paying per request adds up. With an open model, there's no bill that grows.
I could see the model's mistakes, and work around them. Every odd habit above showed up in the raw output, and I could fix it on my side the same day. No waiting on anyone.
Swapping models is one line. If a better small model comes out next month, I change OLLAMA_MODEL and pull it. Everything else stays.

A bigger closed model might have written prettier reasons. But a small open one that lives on my own machine, costs nothing and does the job is more than enough for a few pots on a balcony.

Trying It on My Balcony

The first plan for my balcony landed on a rainy week. The forecast showed rain on four days, with up to a 94% chance on one of them. So Tendril's advice for most of the week was simply: skip watering today.

For someone who waters twice a day no matter what, that was the most useful thing it could say :)

It also left the watering alone on the dry days, because my notes already say I water every morning and evening. It suggested pest checks and pinching off yellow leaves instead.

Turns out the best thing a garden assistant can say is sometimes "don't". 🌱

A study notebook for my brother, written by an open model

Archana — Fri, 02 Oct 2026 16:16:39 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

My brother is preparing for GATE, a big engineering exam in India (think of it as the entrance exam for a master's at the IITs). The computer science paper covers pretty much everything from college, from discrete maths to operating systems to networks.

Studying for it alone is hard. Not because any one topic is impossible, but because nobody is around to tell you "hey, you're getting better". So I built him inkwand, a free study notebook that tries to be that little bit of encouragement :)

It looks and feels like a school notebook, the grid paper kind we all had as kids. Here's what's inside:

The whole syllabus as a bookshelf. 13 subjects and 86 chapters, straight from the official syllabus. Click a book and it slides off the shelf and opens.
Notes for every chapter, written like a friendly senior's notes: the idea in simple words, one worked example, common traps, and one line to remember. Key terms get pink, green and yellow highlighter, traps get orange.
A practice paper for every chapter. Five exam-style questions. Get one right and you get a sticker: a gold star, a medal, a crown or a "Very good!". Get one wrong and you get a gentle cross and an explanation. Full marks gets you a trophy.
Flashcards you tap to flip.
Green ticks. Read the notes, finish the paper, flip every card, and the chapter gets ticked off. Each book shows how far along you are.
A study calendar. Every day you study gets a tick, there's a streak, and hovering over a day shows what you did.
Ask about anything. If something's missing, type it in and Gemma writes fresh notes, a paper or flashcards right there.
No login, no accounts. Everything stays in your own browser.

The stickers and ticks sound silly, I know. But when you study alone, nobody says "well done". Now at least a gold star does :)

Demo

Live: https://inkwand.onrender.com

Opening a book

Practice paper with stickers

Flashcards, then the chapter gets its green tick

The study calendar

Get one wrong, correct it later

A report card, with remarks from Gemma

And it works offline

If you've got two minutes: open Operating Systems, pick Deadlock, read the notes, try the practice paper (go collect a sticker), and flip through the flashcards. Then head back to the shelf and hover over today on the calendar. And scroll all the way down, there's a little classroom waiting at the bottom :)

It runs on an always-on Render instance, so it should open right away :)

Code

GitHub: https://github.com/pyarchana/inkwand (MIT licensed)

How I Built It

Nothing fancy, and that's on purpose. I wanted it to load fast and stay light:

Python and FastAPI on the backend.
Plain HTML, CSS and JavaScript on the front. No framework, no build step. Every icon, sticker and drawing is inline SVG, so there are no image files to download.
Gemma 4, Google's open-weight model, through the Gemini API. The main model is gemma-4-26b-a4b-it, with gemma-4-31b-it as a backup.
Render for hosting, set up from a render.yaml blueprint.

The part that changed my whole plan

My first version asked Gemma to write the notes whenever someone opened a page. It worked! It was also painfully slow. Gemma 4 thinks before it answers, and on the free tier that took anywhere from 45 to 90 seconds. Once it thought so hard that it used up its entire token budget and replied with... nothing.

Nobody wants to wait 90 seconds for a page of notes. So I flipped it around. A small script asks Gemma to write the whole library up front: notes, a practice paper and flashcards for all 86 chapters, 258 pieces in total. It runs 8 requests at a time, retries when the free tier hiccups, and picks up where it left off if you stop it. Everything ends up as about 744 KB of JSON in the repo.

Now chapters open instantly, cost nothing, and still work even if the API key goes missing. Gemma only gets called live for the "ask about anything" box and the "write me a fresh paper" button, and the page is upfront that those take about a minute.

Keeping Gemma honest

Practice papers and flashcards have to come back as proper JSON: exactly four options, one correct answer, and an explanation. The server checks every reply with Pydantic. If something's off, it asks once more with a stricter prompt, and if that fails too, you get a friendly message instead of a broken page.

Free tier things

While writing the library, Google's API threw 74 temporary server errors at me. Then on deploy day, the 26B model failed every single request while the 31B one was totally fine. So now if one Gemma model is having a bad moment, inkwand quietly asks the other one. Swapping models is one setting, which is a big part of why an open model works so well here.

Making it feel like a notebook

I wanted it to feel like sitting at your desk, not opening yet another app. So there's grid paper in the background, headings in pen, and highlighters in the notes. At the very bottom is an empty classroom: a blackboard with chalk in white, pink and yellow, rows of benches, a clock, and a window where the sun glows and clouds drift by. It works on phones too, and it respects reduced motion settings.

Why Open Matters Here

It's free. Good study material shouldn't be stuck behind a paywall. Gemma's free tier and Render's hackathon credits mean inkwand costs my brother, and anyone else who finds it, nothing at all.
The content is open too. Coaching notes are usually locked away. inkwand's whole library is plain JSON in a public, MIT-licensed repo. Spot a wrong answer? Open a pull request and it's fixed for everyone.
No lock-in. When one model broke on deploy day, switching took one setting. If the hosted API ever changes, the same Gemma weights can run somewhere else.
It works offline. The whole library is saved in your browser, so every chapter opens with no internet. And because Gemma's weights are public, the model itself can run fully offline too, with no API key at all. A college lab could host the whole thing for its students.

A closed model might have been faster. But free, forkable and fixable by anyone matters more to me here than a few seconds.

Handing It Over

My brother is not a talker. When I sent him the link, I got no "thanks", no "nice", not even an emoji. Honestly, I saw that coming :)

But everything inkwand remembers lives in his own browser: the stickers, the green ticks, and the calendar that marks every day you study. So a little later, I peeked over his shoulder.

The calendar wasn't empty anymore. There were green ticks on it and stickers on his sheet, and hovering over the ticked days showed what he'd been studying.

He still hasn't said a word about it. 👀

In our house, that's a review.

Prize Categories

Best Use of Gemma: Gemma 4 wrote all 258 pieces of the library, and it writes fresh notes, papers and flashcards on request, with a second Gemma model as a backup.
Best Use of Render: Render is inkwand's AI runtime. The FastAPI service on Render builds every prompt, calls Gemma, validates each reply, retries and falls back between two Gemma models, and serves the front end. It's deployed from a render.yaml blueprint with a health check, auto-deploys on every push, and runs on an always-on Starter instance so it never sleeps.

I made my agent prove every quote against the source document

Archana — Wed, 23 Sep 2026 03:45:19 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

My agent kept citing real documents for words those documents never contained. Not hallucinated quotes: real sentences, attributed to the wrong source. So it now proves every quoted phrase against the exact document it cites, straight from the dataset, and marks the ones that fail.

TSB Oracle answers car repair questions from the public record, and shows you where that record contradicts itself.

Ask why your car brakes on its own and you will find a service bulletin naming a cause, a revision of that bulletin a week later that quietly drops the sentence, a federal investigation covering more model years than the fix does, and owners saying the dealer called it normal. All of it is true at once. A search engine hands you whichever page ranks best, and a chatbot picks one and sounds certain.

This agent retrieves all of it. Every sentence carries the NHTSA id it came from, quotes are checked against the document they are attributed to, and when two sources disagree about your exact car, the disagreement is put in front of you instead of resolved by guesswork.

The dataset is one vehicle and one system, imported from NHTSA's public API: unexpected automatic emergency braking on the 2017 to 2022 Honda CR-V. The conflict at the centre of it is real. NHTSA's investigation EA24-002 covers 2017 to 2022. Honda's software update 26-091 stops at 2019 and excludes the LX trim. A 2021 owner is inside an open federal investigation with no published remedy, and nothing in the record says one is coming.

What the agent does with that:

cites every factual claim with the NHTSA id, linked to the public record
flags in amber any citation it did not actually retrieve
verifies quoted words against the dataset's own copy of the cited document
shows contradictions side by side, with dates and a plain explanation of why they conflict
proposes how a disagreement resolves, and waits for a person to approve it

Demo

tsb-oracle.vercel.app

The demo car is a 2021 Honda CR-V EX. The vehicle in the header is editable, so these all work:

Vehicle	Ask	What it shows
2021 CR-V EX	My CR-V brakes hard on its own with nothing ahead. The dealer says that's normal. Is there a fix?	the coverage gap, already settled by review
2018 CR-V LX	Does Service Bulletin 26-091 apply to my car?	a trim exclusion
2018 CR-V EX	Honda and NHTSA disagree about what causes the braking. Which applies to my car?	an open contradiction, and a proposal
1994 Civic del Sol	Are there any recalls for this car?	no sources, and it says so

While it works, it shows what it is reading rather than a spinner:

Every question is a live model call against my own API balance, so if the demo stops answering, that is why.

Code

github.com/pyarchana/tsb-oracle, tagged v1.0.

How I Used Sanity

The content model. Four types do the work. tsb is a source document, a bulletin, dealer message, investigation or owner complaint, with its model years, excluded trims and a link to the NHTSA record. claim is one statement with the exact words it rests on. contradiction joins two claims that disagree and explains why. decision records how a contradiction was resolved, who resolved it, and whether a person has approved it yet.

What I pointed Context at. The Knowledge Base is built from the tsb and claim types, with the claim's source reference unfolded so each claim carries its document's id. I deliberately left contradiction out. If I had included it, the Knowledge Base would have read my conflicts back to me. Excluding it meant Context had to find disagreement in the sources on its own.

The tools. The agent gets initial_context and knowledge_base_read over the Context MCP endpoint, plus two of my own:

check_applicability runs GROQ over the dataset and returns which documents cover this year, make, model and trim, which contradictions touch them, and whether any has been settled. It answers questions the Knowledge Base cannot: is this trim excluded, is this VIN in range, is this argument already over.
record_decision writes a proposal, never a settled decision.

So Context supplies the wording and GROQ supplies the structure. The Knowledge Base tells the agent what a bulletin says; the dataset tells it whether that bulletin applies to the car in front of it.

What the Knowledge Base build caught. Four issues, all real. NHTSA's own summary of bulletin A18-006 writes "OTC" where the codes are DTCs and "MIO" where the display is the MID. Two entries merged NHTSA's complaint counts with its per-vehicle totals: 31 crashes alleged in complaints against 47 across all reports, 50 injuries against 93. I resolved each in favour of what the source actually supports, and resolutions carry into every later build.

What it did not catch, and why I left that alone. None of my curated claims conflicted. Every one of them says who made the statement it records, so "version 1 of the bulletin says X" does not flatly contradict "version 2 says Y". I could have written an unattributed claim to make the issues feature fire. Staging a conflict to demo conflict detection would have proved nothing.

Why the knowledge base cannot back a quote I assumed Knowledge Base entries could back up a quotation. They cannot, and should not. An entry is a synthesis: it merges several documents into one topic, paraphrases them, and attaches footnotes. That is right for retrieval and wrong for quoting, because a phrase can appear in an entry that no source ever used. So the app checks quoted words against the dataset's verbatim copy of the cited document instead. On a live run it caught the agent quoting version 1 of a bulletin and citing version 2, which is exactly the kind of mistake that sends someone to a dealer asking for the wrong repair.

Persistence. When the agent proposes a resolution, it writes a decision with status proposed. A person opens it in the Studio and approves or rejects it. Approving flips the decision and its contradiction in one transaction, so the two can never disagree about whether a question is settled. From then on, the next person asking about that vehicle gets the settled answer and its rationale instead of the argument.

That review step exists because the demo is public. Without it, one conversation could settle a question for everyone who asks after it.

Sanity Project Details

Project ID: e72p6sym, dataset production, which is public.

A live query against it, no token needed:

https://e72p6sym.api.sanity.io/v2026-09-01/data/query/production?query=*[_type=="tsb"]{tsbNumber,title,sourceType,status,modelYears}

The Studio is embedded at /studio in the app, and the schemas are in sanity/schemaTypes.

Ten files is not a budget

Archana — Fri, 11 Sep 2026 01:28:04 +0000

I have an MCP server that digests a GitHub repository into markdown so a model can read it without cloning anything. Directory tree, plus the contents of the files that matter.

I pointed it at a real repository and got this back:

Error: result (109,668 characters) exceeds maximum allowed tokens

Not a truncated answer. Not a partial digest with a warning. Nothing. The tool call failed and the caller was left with an error message where a repository summary should have been.

The cause was a constant I had written months earlier without thinking about it:

MAX_FILE_BYTES = 32_000
TOP_N_FILES = 10

Ten files, each capped at 32,000 characters. I had reasoned that ten files is a reasonable amount of a repository to show. Which is true, and also not a size limit at all. Ten files is anywhere from a few hundred characters to 320,000 depending on whose repository you point it at.

The obvious fix, and why I did not just do it

The obvious fix is to add a total character cap. Pick a number, fill it, stop.

The problem is picking the number. I could have reasoned my way to one. 50,000 sounds fine. 32,000 sounds fine too. So does 64,000. Any of them sounds fine, which is a good sign that reasoning is not the tool for the job, and is exactly how TOP_N_FILES = 10 got there in the first place.

So before changing anything I measured. Six repositories, spanning the range I would realistically encounter: two small ones of my own, a mid-sized MCP server, a docs-heavy list repo, and two large real codebases.

repository	files	tree	file content	total
GopherMCP/GopherCache	5	89	4,505	4,594
pyarchana/gopher	22	591	23,640	24,231
sktime/sktime-mcp	104	3,296	100,490	103,786
astral-sh/uv	1,578	65,530	142,337	207,867
modelcontextprotocol/python-sdk	1,643	57,306	160,182	217,488
punkpeye/awesome-mcp-servers	10	173	228,137	228,310

A fifty-fold range between the smallest and largest output, from the same tool with the same settings.

Three things fell out of that table that I would not have guessed.

The tree alone can eat everything

Look at the tree column for uv and the python SDK. 65,530 and 57,306 characters, just to list filenames.

I had been thinking of the budget as a cap on file contents. But on a repository with 1,600 files, the directory listing on its own is larger than any sensible total. If I had capped only the file content, uv would have blown past any budget I set before fetching a single file.

The tree needed its own cap, at a fraction of the total, and a note saying how many entries it left out.

The ranking was picking the wrong files

This is the one that actually mattered, and I only saw it because I printed what was being selected rather than just how big it was.

Here is what my tool chose to show about uv, a Rust build tool:

27,194  test/ecosystem/airflow/pyproject.toml
32,048  test/ecosystem/home-assistant-core/pyproject.toml
27,517  test/ecosystem/pandas/pyproject.toml
 9,156  test/ecosystem/jupyterlab/pyproject.toml
 8,757  test/ecosystem/black/pyproject.toml

Eighty-nine thousand characters of other projects' dependency lists, scraped out of uv's test fixtures. The only uv code that made it in was three main.rs files, all of them thin entry points, and Cargo.toml ranked below every one of those fixtures.

And here is awesome-mcp-servers:

32,048  README-fa-ir.md
32,048  README-ja.md
32,048  README-ko.md
32,048  README-pt_BR.md
32,048  README-th.md
32,048  README-zh.md
32,048  README-zh_TW.md

The same README in seven languages, 224,000 characters of it.

The cause was one line:

if name in PRIORITY_NAMES:
    score += 1000

Any file called pyproject.toml got a thousand points, wherever it sat. A vendored copy six directories deep in a test fixture scored exactly the same as the one at the root describing the actual project.

This is why the measurement mattered. If I had shipped the budget on its own, the digest would have gone from 207,867 characters of the wrong files to 40,000 characters of the wrong files. Smaller, still useless, and now looking deliberate.

The file it wanted most came back empty

One more, which I would never have found by reading code.

In the awesome-mcp-servers run, the top-ranked file scored 1200 and returned zero characters:

     0  score=1200   README.md
32,048  score=200    README-fa-ir.md

GitHub's contents API will not serve a file over 1MB. It does not return an error. It returns 200 OK with an empty content field and encoding: "none". So the base64 decode succeeds, produces an empty string, and the file silently disappears.

That README is 1,616,144 bytes. The single most important file in the repository was being dropped without a word, and seven translations of it were filling the space instead. The fix is to notice encoding: "none" and refetch through the blobs endpoint, which serves up to 100MB.

What I changed

A total budget, not a file count. 40,000 characters, configurable. Spent on the tree first, then files in priority order, until it runs out. The number of files now falls out of what fits instead of being pinned in advance.

A cap on the tree, a quarter of the total, with a line saying how many entries it omitted.

A per-file ceiling of 40% of what remains, so one large file cannot crowd out everything else.

Ranking by position, not just name. The priority bonus now decays with directory depth, so the root manifest beats a vendored one. Test and fixture directories lose points, vendored ones lose more, examples lose only a little because sometimes an examples directory is the best documentation a project has. Files in the repository's primary language, which the API already tells you, gain some.

Here is the same table after:

repository	before	after
GopherMCP/GopherCache	4,594	5,005
pyarchana/gopher	24,231	39,263
sktime/sktime-mcp	103,786	39,231
astral-sh/uv	207,867	39,321
modelcontextprotocol/python-sdk	217,488	39,224
punkpeye/awesome-mcp-servers	228,310	39,168

uv's digest now leads with Cargo.toml and README.md. awesome-mcp-servers leads with its actual README. My own small repo got bigger, because it was only ever showing 10 of its 22 files and now shows all of them.

The thing I would tell past me

I nearly shipped a one-line change. Add a constant, clamp the output, close the issue. It would have passed review, passed tests, and produced a tool that was confidently wrong in a smaller font.

What stopped it was spending an hour printing what the tool actually produced against real inputs. Not unit tests, which only check what I already thought to assert. Not reading the code, which is where the bug had been sitting unnoticed for months. Just running it against six real repositories and looking at the output.

If you are building anything that assembles context for a model, you are making size and selection decisions whether you notice them or not. Print what your tool actually sends, against real inputs, at real sizes. The numbers are frequently not what you expect, and the interesting failure is rarely the one you set out to fix.

The tool is pyarchana/gopher, an MCP server that fetches, caches and digests context for Claude. The measurements above live in #5 and #14 if you want the full before and after.

pyarchana / gopher

One MCP server for Claude: digest any GitHub repo, keep memory across conversations, and extract facts locally with Ollama

Gopher

One MCP server that fetches, caches, and digests context for Claude.

Gopher is three things that used to be three separate servers:

fetch: point it at a GitHub repo and get back a clean Markdown digest: full directory tree, plus the contents of the files that actually matter. Filters out binaries, lock files, node_modules, venv, and the rest of the noise, then ranks what's left. No README? It builds one for you.
cache: persistent memory across conversations, stored as two plain files you can read yourself: a structured context.json and an append-only diary.md.
digest: reads a conversation transcript, extracts the facts with a local Ollama model, and merges them into the cache.

Everything runs locally over stdio. Nothing leaves your machine except GitHub API calls.

Tools

Tool	What it does
`fetch_github_repo(repo_url)`	Markdown digest of a public repo, tree plus top files
`read_context()`	Return

…

View on GitHub

Five bugs in my LLM app that never threw an error

Archana — Sun, 30 Aug 2026 02:31:58 +0000

I spent two and a half weeks building an agent that reads a project's code review history and remembers what it decided. 86,321 comments from pandas, distilled into 298 conventions, served out of CockroachDB behind a Lambda.

Every serious bug I hit had the same shape. Nothing raised. Tests passed. The demo worked. And somewhere in the middle, a component was doing absolutely nothing.

Here are five, with the code.

1. `bool("false")` is `True`

The whole point of the system is that it refuses when it does not know. The answering prompt returns JSON with an answered field.

result = await chat.complete_json(messages)
if result.get("answered"):
    return result["answer"]

A model that writes "answered": "false" instead of "answered": false turns a refusal into an answer, because a non-empty string is truthy. The one behaviour the project exists to guarantee, defeated by a quotation mark.

Now every model response goes through a Pydantic model that fails towards doing nothing:

class AnswerOutput(ModelOutput):
    answered: bool = False   # coerces "false" -> False
    answer: str = ""

An answer becomes a refusal. A drafted rule becomes unusable. A contradiction verdict becomes "compatible", which retires nothing. A garbled response is not evidence for writing to memory.

2. A `null` discarded whole responses, six times out of six

The fix for bug 1 caused bug 2, which is funnier than it was at the time.

The prompt that turns a maintainer's comment into a rule says:

"rationale": "why, one sentence, only if they gave a reason"

A maintainer who states a convention flatly gets null back, which is correct JSON for "no reason given". And:

class DraftedRule(BaseModel):
    statement: str = ""
    rationale: str = ""   # null is not a str

Pydantic rejects null for a plain str. Validation is all or nothing. So the entire response was thrown away and replaced with the inert default, which downstream reads as the model having declined.

A real maintainer correction became {"status":"ignored","reason":"no convention stated"}. Six reproductions, six failures, on a payload that was otherwise exactly what I asked for.

class ModelOutput(BaseModel):
    @field_validator("*", mode="before")
    @classmethod
    def _null_text_is_empty(cls, value, info):
        if value is not None:
            return value
        field = cls.model_fields.get(info.field_name)
        return "" if field is not None and field.annotation is str else value

A null where a string was expected means empty, not malformed. Note the field.annotation is str check: scope_pattern: str | None genuinely means None, and coercing that one would turn "applies everywhere" into a pattern matching nothing.

3. 68 of my 79 path rules matched zero files

Each rule stores a pattern for which files it applies to. I matched with fnmatch.

fnmatch("pandas/core/frame.py", "pandas/core/%")   # False

The patterns were SQL LIKE, not globs. pandas/tests/%, pandas/core/%, pandas/tests/%/conftest.py. Nothing asked the extraction prompt for that and nothing documented it. The model just wrote it, presumably because the rules were destined for a database.

% is not an fnmatch wildcard. So 68 of 79 anchored rules silently matched nothing, and the agent ran entirely on the two rules that happened to be written pandas/**/*.py, which cover 63% of the repository.

It looked like it was working the entire time. The fix is one line, and the bug was invisible for a week:

cleaned = pattern.strip().strip("`").lstrip("./").replace("%", "*")

4. The similarity score I was tuning had no signal in it

The agent comments on pull requests, choosing which conventions apply by embedding a description of the change and taking the nearest rules.

It commented on 38 of 40. I assumed a bad threshold and started tuning. At 1.05 it spoke on 95% of pull requests; at 0.95, on 18%.

Then I measured the distribution instead. For 25 real pull requests, distance to the nearest rule versus the tenth nearest:

query phrasing	median nearest	median spread, 1st to 10th
title only	0.954	0.097
title plus directories	0.947	0.100
paths and counts	0.958	0.105
written as a question	0.933	0.095

The nearest rule is not meaningfully nearer than the tenth, under any phrasing. Every rule is a general statement about the same codebase, so every rule is similar to any description of a change to it.

There was nothing to threshold. Retrieval now runs on path matching, which is a fact, and similarity only orders what the paths already admitted.

5. GitHub's `author_association` describes the present

I filtered to maintainer comments using GitHub's author_association field.

It reports whether someone has write access now, not when they wrote the comment. One reviewer wrote 74,077 comments on pandas between 2012 and 2025, more than twice anyone else. He has since left the org, so all 74,077 come back as CONTRIBUTOR.

Filtering on that field discarded about a third of the corpus, including the most experienced reviewers the project ever had. No error, no warning, just a smaller number that looked plausible.

The pattern

None of these raised. Four of the five I found by counting something rather than by reading code: how often does it speak, how many rules match anything, how far apart are the distances really.

A library used wrong fails loudly. A model used wrong returns confident, well-formatted output that is quietly detached from what you meant.

So pick a number that should hold if the system works, and go and look at it. Not "does it return results" but "how often does it speak, and is that the rate I intended". Not "did it cite something" but "do the citations resolve".

Code is at github.com/pyarchana/precedent, MIT.

Google's Workspace Intelligence Might Actually Fix the Thing That Bugs Me Most About AI Tools

Archana — Thu, 23 Apr 2026 03:00:57 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Okay so I've been watching the Google Cloud NEXT '26 announcements drop today and there's a lot. TPUs, agentic platforms, a $750M partner fund. But the thing that actually made me stop scrolling was Workspace Intelligence :)

Not because it's the most technically impressive thing on the list. It's not. But it might be the one that changes how I (and probably you) actually work day to day.

Let me explain.

The thing that's always bothered me about AI in Google Docs

Every time I open Docs and try to use Gemini to help me write something, I spend the first few minutes basically re-introducing myself. Here's the project. Here's the tone we're going for. Here's who the audience is. Here's the doc we drafted last month that this is building on.

It's exhausting :) The AI is smart but it has no idea who I am or what I'm working on. Every prompt is a cold start.

That's exactly what Workspace Intelligence is supposed to fix.

What it actually is

Google is calling it a "semantic layer" across all your Workspace apps. Gmail, Docs, Sheets, Slides, Drive, Chat, Calendar. The idea is that instead of each app being its own isolated thing, there's now a shared understanding of your work running underneath all of them :)

It learns what projects you're actively working on, who you're collaborating with, what your writing sounds like, and what's actually on your plate right now. Then every time you use Gemini anywhere in Workspace, it's pulling from that context instead of starting fresh.

Practically speaking, here's what that looks like across the apps:

Gmail gets an AI Inbox that doesn't just summarize. It suggests what you should actually do, and drafts replies that sound like you, not like a generic assistant :)

Google Chat gets an "Ask Gemini" mode that Google is framing as a "unified command line for your work." You say what you need, it goes off and does it across Workspace. Schedules the meeting, pulls the file, writes the brief.

Docs can now edit multiple images at once for visual consistency, build infographics from your own business data, and handle comment threads. Including making edits to the doc based on the feedback in those comments :)

Slides can build a full deck from a single prompt, and it'll actually use your company's real templates and visual styles. Not a generic blue gradient.

Sheets lets you build and edit spreadsheets by just... talking to it. And it can pull data from your emails, files, and chat history to populate things :)

Drive is getting "Projects," a smarter way to organize everything around active work rather than just being a folder system that you dig through.

The bit I find most interesting

There's a line in Google's announcement that stood out to me: Workspace Intelligence learns your "unique work style, voice, and formatting preferences" so outputs sound "authentically like you."

I'm genuinely curious how well that works in practice :) Voice matching is one of those things that sounds great in a keynote and then either impresses you or makes you cringe when you see the actual output. I haven't been able to test it yet, but it's the thing I'm most excited (and slightly skeptical) about.

What about the "let AI read all my stuff" concern?

Yeah, this is the obvious question. Google is essentially asking you to let a system reason across your email, your calendar, your chat history, and your files. That's a lot of trust.

Their answer: customer data isn't used for ads, isn't reviewed by humans, and isn't used to train models outside Workspace without your permission :) Admins can control which data sources it touches, so if your org doesn't want it reading Gmail, they can turn that off. Client-side encryption and sovereign data controls (US and EU, with more coming) are part of the rollout too.

Whether that's enough will depend on your org's risk appetite. But at least they're not burying it in the fine print.

Where I land on this

I think the individual features are nice, but the real bet here is the compounding effect :) The more Workspace Intelligence understands your context, the more useful every individual tool becomes. That's a different kind of value than "we added a summarize button."

Google's basically trying to turn Workspace from a collection of apps you switch between into something that actually understands what you're trying to get done. Whether that plays out the way they're describing it, or whether it turns into a very well-marketed context window, is something we'll only know once people start using it for real.

But I'm paying attention. And honestly? I think this one's worth your time to follow :)

Are you using Google Workspace day to day? Curious whether this kind of persistent context layer actually sounds useful to you, or if it feels like AI for AI's sake. Let me know below :)

DEV Community: Archana

Tendril: a garden assistant you barely have to open

What I Built

Demo

Code

How I Built It

A small model with big habits

Keeping the model honest

Making it feel like a lock screen

Why Does Open Innovation Matter?

Trying It on My Balcony

A study notebook for my brother, written by an open model

What I Built

Demo

Code

How I Built It

The part that changed my whole plan

Keeping Gemma honest

Free tier things

Making it feel like a notebook

Why Open Matters Here

Handing It Over

Prize Categories

I made my agent prove every quote against the source document

What I Built

Demo

Code

How I Used Sanity

Sanity Project Details

Ten files is not a budget

The obvious fix, and why I did not just do it

The tree alone can eat everything

The ranking was picking the wrong files

The file it wanted most came back empty

What I changed

The thing I would tell past me

pyarchana / gopher

One MCP server for Claude: digest any GitHub repo, keep memory across conversations, and extract facts locally with Ollama

Gopher

Tools

Five bugs in my LLM app that never threw an error

1. bool("false") is True

2. A null discarded whole responses, six times out of six

3. 68 of my 79 path rules matched zero files

4. The similarity score I was tuning had no signal in it

5. GitHub's author_association describes the present

The pattern

Google's Workspace Intelligence Might Actually Fix the Thing That Bugs Me Most About AI Tools

The thing that's always bothered me about AI in Google Docs

What it actually is

The bit I find most interesting

What about the "let AI read all my stuff" concern?

Where I land on this

1. `bool("false")` is `True`

2. A `null` discarded whole responses, six times out of six

5. GitHub's `author_association` describes the present