I Built an AI That Wants You to Stop Using It

suvendu kumar sahoo — Thu, 08 Oct 2026 09:06:56 +0000

I Built an AI That Wants You to Stop Using It

TrailLens — Look beyond the screen.

Most AI products are designed to keep you inside the interface.

TrailLens was designed to do the opposite.

You find something outside.

You capture it.

Local Gemma 3 4B helps understand it.

TrailLens turns that observation into a short, structured field mission.

And then it tells you:

PHONE DOWN.

The most important part of the experience begins when the screen stops being the center of attention.

🌿 What Is TrailLens?

TrailLens is a local AI field-experiment engine for outdoor exploration.

Its core loop is:

SEE
  ↓
GEMMA UNDERSTANDS
  ↓
MISSION READY
  ↓
PHONE DOWN
  ↓
EXPLORE
  ↓
RETURN
  ↓
REFLECT
  ↓
FIELD RECORD

The idea is intentionally simple:

Use AI to create curiosity, then get out of the way.

TrailLens is not trying to become another chatbot.

It is trying to give you a reason to look more closely at the physical world.

🧭 The Problem

A lot of digital products optimize for attention:

more scrolling
more notifications
more interactions
more time on the screen

But when you're outside, the interesting thing is usually already there.

A leaf.

A piece of bark.

A flower.

A stone.

A texture.

A pattern you normally walk past.

So I started with a simple question:

What if AI could help someone notice the physical world, then deliberately disappear from the experience?

That became TrailLens.

🌲 The TrailLens Experience

01 — SEE

You notice something interesting outside.

02 — CAPTURE

TrailLens uses the camera to capture the observation.

03 — GEMMA UNDERSTANDS

The image enters the local analysis pipeline.

Gemma 3 4B analyzes the visual input and produces structured information that TrailLens can turn into a field mission.

04 — MISSION READY

Instead of returning only an identification, TrailLens generates a structured FieldMission.

For example:

Find another nearby leaf with a similar shape and compare the number of lobes and the pattern of its main veins.

The important difference is:

the output becomes an action, not just an answer.

05 — PHONE DOWN

Once the mission starts:

PHONE DOWN.

Put your phone away.
Look.
Walk.
Notice.
Compare.

Pocket Mode intentionally minimizes the interface.

06 — EXPLORE

The user spends a short, bounded period investigating the physical environment.

07 — RETURN

When they come back:

What did you notice?

The reflection is written by the user.

Gemma does not invent the experience for them.

08 — FIELD RECORD

The session becomes a compact record containing the mission, session information, and the user's own reflection.

The application becomes a record of something the person actually did, rather than another chat transcript.

🧠 Why Gemma Matters

Gemma is not just an API call hidden somewhere inside the project.

It is the reasoning layer connecting:

VISUAL OBSERVATION
        ↓
LOCAL AI REASONING
        ↓
STRUCTURED FIELD MISSION

TrailLens uses Google Gemma 3 4B through Ollama for local inference.

That choice matters because the intended environment is the real world, where connectivity may be unreliable.

The local architecture allows the core AI inference path to run on the user's machine rather than depending on a remote AI inference service.

That gives TrailLens an architecture centered around:

local inference
reduced dependence on cloud AI availability for the core model step
a privacy-oriented image-processing path
an open-weight model that can run within a local stack

For this project, open innovation isn't just a licensing detail.

It changes the product architecture.

🏗️ System Architecture

flowchart LR
    U[User Outdoors]
    C[Camera]
    B[Browser]
    A[Next.js /api/analyze]
    V[Payload Validation]
    O[Local Ollama]
    G[Gemma 3 4B]
    M[FieldMission]
    S[Safety Gate]
    Q[Mission Quality]
    P[Pocket Mode]
    X[Outdoor Session]
    R[Reflection]
    F[Field Record]

    U --> C
    C --> B
    B --> A
    A --> V
    V --> O
    O --> G
    G --> M
    M --> S
    S --> Q
    Q --> B
    B --> P
    P --> X
    X --> R
    R --> F

The major boundaries are intentionally explicit:

Browser → Validation → Local Inference → Structured Mission → Safety → Quality → Outdoor Activity

🔬 What Happens After Gemma Responds?

I didn't want a naive:

MODEL OUTPUT
     ↓
SHOW IT TO USER

pipeline.

Instead:

sequenceDiagram
    participant User
    participant Browser
    participant Next as Next.js
    participant Ollama
    participant Gemma

    User->>Browser: Capture outdoor subject
    Browser->>Next: POST /api/analyze
    Next->>Next: Validate payload
    Next->>Ollama: Structured inference request
    Ollama->>Gemma: Multimodal analysis
    Gemma-->>Ollama: Structured FieldMission
    Ollama-->>Next: Model response
    Next->>Next: Safety validation
    Next->>Next: Mission quality evaluation
    Next-->>Browser: Analysis + Mission
    Browser-->>User: Mission Ready

A generated mission therefore passes through application-level validation before it reaches the user experience.

🛡️ Safety Is Part of the AI Design

An outdoor AI assistant shouldn't blindly turn every plausible model output into an activity.

TrailLens includes a deterministic safety layer that can reject unsafe challenge language and substitute a safe fallback.

The system explicitly accounts for categories such as:

wild plant or mushroom ingestion
harvesting or collecting specimens
dangerous terrain
inappropriate wildlife interaction

The principle is simple:

AI can create curiosity without creating unnecessary risk.

Safety is therefore treated as an application boundary, not as something the model is simply expected to get right.

🧪 A Plausible Mission Isn't Necessarily a Good Mission

One of the biggest lessons from building TrailLens was:

A mission sounding plausible does not mean it is a good field mission.

So I built a deterministic Mission Quality Evaluator.

Every mission can be evaluated across five dimensions:

Dimension	What it asks
Grounding	Is the mission connected to what was actually observed?
Specificity	Does it contain concrete actions and observable details?
Safety	Does it avoid known hazards?
Executability	Can a person realistically perform it?
Outdoor Value	Does it require real-world observation instead of screen-only thinking?

Each dimension is scored from 0–20, for a total of 100.

The fixture suite contains 10 deterministic scenarios.

The benchmark produced an average score of 85.4 / 100, while Specificity was the weakest dimension at 14.6 / 20 average.

That result was valuable.

I did not change the rubric to make the numbers look better.

The failures showed exactly where generated missions still needed improvement.

That is the point of an evaluator.

⚙️ Engineering the Local Model

TrailLens includes a reproducible Gemma benchmark suite covering:

cold vs. warm inference
model residency
token ceilings
prompt compression
image-resolution experiments
structured output
reproducibility

One repeated finding was the effect of keeping the local model resident:

Warm model-load overhead was in the tens of milliseconds in the tested runs, versus multi-second cold loading.

The project also makes an important distinction:

model-load latency is not the same thing as total end-to-end inference latency.

Absolute inference time varied across repeated runs on the same test machine, so the benchmark is documented as empirical testbed evidence rather than a universal performance guarantee.

✅ Verification

TrailLens is backed by a real automated verification suite.

Current project verification includes:

100 automated tests
ESLint with zero errors
successful Next.js production build
deterministic safety tests
Mission Quality fixture evaluation
structured FieldMission validation
local Gemma benchmark artifacts
reproducibility evidence

The repository deliberately separates different forms of evidence:

Functional Correctness
        ↓
Contract Validation
        ↓
Safety Validation
        ↓
Mission-Quality Evaluation
        ↓
Performance Benchmarking
        ↓
Reproducibility
        ↓
Real-World Field Validation

That distinction matters.

A passing unit test is not the same thing as proving that a person enjoyed a field mission.

🌿 Why This Fits "Touch Grass"

The challenge is about using open-source AI to create something that gets people away from the screen and into the real world.

TrailLens was built around that requirement from the beginning.

Typical AI interaction

QUESTION
   ↓
AI ANSWER
   ↓
MORE QUESTIONS
   ↓
MORE SCREEN TIME

TrailLens

OBSERVATION
   ↓
GEMMA
   ↓
FIELD MISSION
   ↓
PHONE DOWN
   ↓
REAL WORLD
   ↓
REFLECTION

The screen is supposed to be the shortest part of the experience.

That is the product.

🏕️ What Makes the Idea Different?

The interesting part isn't simply:

"Gemma can identify a leaf."

The interesting part is:

What happens after the identification?

Instead of ending with:

"This is probably an oak leaf."

TrailLens can turn that observation into:

"Find another nearby leaf and compare its lobes and main veins."

That changes AI from an answer engine into a field-experiment trigger.

And then the phone is supposed to disappear from the experience.

📖 The Field Record

The end product is not a chat history.

It is a field record.

A compact memory of:

what was investigated
what mission was attempted
session information
what the user personally noticed

The reflection is intentionally user-authored.

TrailLens doesn't ask the model to fabricate what the person experienced.

🛠️ Built With

Frontend

Next.js
React
TypeScript
Tailwind CSS

AI

Google Gemma 3 4B
Ollama
structured JSON / JSON Schema output

Engineering

Zod
Vitest
ESLint
Turbopack
deterministic safety rules
deterministic Mission Quality evaluation

📈 What I Actually Built

The project evolved through concrete engineering milestones.

M1 — Field Mission Contract

A structured contract between model output and physical-world activity.

M2 — Local Gemma Latency Engineering

Cold/warm benchmarking, model residency, prompt compression, token boundaries, resolution experiments, and structured output testing.

M2.1 — Reproducibility Evidence

A second complete benchmark run to separate reproducible engineering behavior from variable wall-clock latency.

M3 — Pocket Mode + Reflection + Field Records

The physical immersion and reflection loop.

M4 — Mission Quality + Grounding

A deterministic 5-dimension evaluator backed by a 10-fixture test suite.

Productization

An editorial field-guide interface, camera-pipeline hardening, SDLC documentation, contributor documentation, and engineering evidence.

🔍 What I Learned

The biggest lesson wasn't:

"Make the model smarter."

It was:

Design the system around what the model is good at — and explicitly constrain what it isn't.

That led to several architectural decisions:

structured model output
deterministic safety gates
deterministic mission-quality evaluation
performance benchmarking
reproducibility checks
Pocket Mode
user-authored reflection
explicit evidence boundaries

The result is less like a chatbot and more like an AI-powered field instrument.

⚠️ What TrailLens Does Not Claim

I want the project to be honest about its limits.

The Mission Quality system is a deterministic lexical and structural proxy. It is not a semantic judge of the physical world.

The 10-fixture benchmark is not a human user study.

Benchmark latency is measured on a specific local test environment and should not be interpreted as a universal hardware guarantee.

Actual outdoor engagement depends on people, terrain, weather, curiosity, and context.

Those limitations are documented deliberately.

Reproducibility is more useful than inflated claims.

🌎 Open Source

TrailLens is open source:

GitHub

https://github.com/suvendukungfu/traillens

The repository includes:

application source
architecture documentation
SDLC documentation
evaluation reports
benchmark artifacts
Mission Quality fixtures
contributor instructions
changelog

🚀 Run TrailLens Locally

Requirements

Node.js
Ollama

Install Gemma:

ollama pull gemma3:4b

Clone:

git clone https://github.com/suvendukungfu/traillens.git
cd triallens

Install dependencies:

npm install

Run:

npm run dev

Then open:

http://localhost:3000

🧭 The Philosophy

The entire project can be reduced to one sentence:

Use AI once. Then go outside.

Or even shorter:

AI is the bridge. The real product is outside.

That is why TrailLens exists.

🌱 Hacktoberfest 2026 — Touch Grass

TrailLens was built for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

The challenge asks builders to create something with open-source AI at its core that gets people away from the screen and into the world.

TrailLens was designed around exactly that constraint.

The most important screen in the product is the one that tells you:

PHONE DOWN.

Then the app gets out of the way.

🔗 Links

GitHub:

https://github.com/suvendukungfu/traillens

Hacktoberfest Week 1:

https://dev.to/challenges/hacktoberfest-week1-2026-10-05

License: MIT

Final Thought

Most AI assistants try to keep you talking to them.

TrailLens has a different goal:

Say something useful.

Give you something to investigate.

Then get out of the way.

DEV Community: suvendu kumar sahoo

I Built an AI That Wants You to Stop Using It

I Built an AI That Wants You to Stop Using It

🌿 What Is TrailLens?

🧭 The Problem

🌲 The TrailLens Experience

01 — SEE

02 — CAPTURE

03 — GEMMA UNDERSTANDS

04 — MISSION READY

05 — PHONE DOWN

06 — EXPLORE

07 — RETURN

08 — FIELD RECORD

🧠 Why Gemma Matters

🏗️ System Architecture

🔬 What Happens After Gemma Responds?

🛡️ Safety Is Part of the AI Design

🧪 A Plausible Mission Isn't Necessarily a Good Mission

⚙️ Engineering the Local Model

✅ Verification

🌿 Why This Fits "Touch Grass"

Typical AI interaction

TrailLens

🏕️ What Makes the Idea Different?

📖 The Field Record

🛠️ Built With

Frontend

AI

Engineering

📈 What I Actually Built

M1 — Field Mission Contract

M2 — Local Gemma Latency Engineering

M2.1 — Reproducibility Evidence

M3 — Pocket Mode + Reflection + Field Records

M4 — Mission Quality + Grounding

Productization

🔍 What I Learned

⚠️ What TrailLens Does Not Claim

🌎 Open Source

GitHub

🚀 Run TrailLens Locally

Requirements

🧭 The Philosophy

🌱 Hacktoberfest 2026 — Touch Grass

🔗 Links

Final Thought

🌿 Look beyond the screen.