DEV Community: Adedeji Olamide

STAY - Keep the Days You Got

Adedeji Olamide — Sat, 15 Aug 2026 12:28:04 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Dogs don't stay long enough.

That is the entire idea behind STAY.

STAY is an interactive experience about time, attention, and memory. It compresses the life of a dog into a few minutes, lets you experience the small choices that make up that life, and then gives you a way to preserve the moments that mattered.

The experience begins with Milo as a puppy.

You spend his life making ordinary decisions:

take the walk
finish some work
play for a while
take the photo
go somewhere new
stay home
give him the shoe he already destroyed anyway

There is no perfect route.

There is no "good owner" score.

Life keeps moving either way.

Milo grows from puppy to young dog, adult, mature dog, and eventually senior.

His behaviour changes with him.

He reacts quickly when he is young.

He becomes calmer as he grows.

Familiar toys and places return years later.

His movements slow down.

And somewhere in the interface, the number of days he has left keeps falling.

The thesis behind STAY is simple:

You cannot give a dog more years. You can give their years more life.

Eventually, Milo's life ends.

There is no dramatic death animation.

For the whole experience, you have learned to expect Milo to occupy part of the screen.

Then that space is empty.

What remains are the moments you chose to keep.

Those memories can be preserved as a verifiable proof on Solana devnet.

But STAY does not end with simulated Milo.

After his Memory Box is complete, the experience asks one final thing:

Milo's story was simulated. Yours isn't.

From there, users can photograph or upload a real moment with their own dog, add a name, date, and short note, and create a cryptographic attestation for that memory.

The photograph itself does not need to live on-chain.

Instead, STAY hashes the image locally, creates a deterministic memory manifest, and commits the proof through a real Solana transaction.

The day will still disappear.

The proof that it happened does not have to.

Demo

🔗 Live Demo: https://stay-coral-gamma.vercel.app

STAY includes a Demo Mode that accelerates the real simulation so judges can experience the full arc without replacing the underlying state machine with hardcoded screens.

The complete journey is:

Meet → Live → Choose → Age → Remember → Lose → Preserve → Bring It Into Real Life

For the strongest experience, use a desktop browser first.

Code

🔗 GitHub: https://github.com/xyzbutworse/dog-years

The repository includes:

the full interactive experience
the life simulation/state system
Milo's age-based behaviour
memory generation
local persistence
deterministic manifest generation
SHA-256 hashing
Solana devnet proof flow
real-memory attestation
verification logic
setup and architecture documentation

How I Built It

I started STAY with one constraint:

Solana could not be something I bolted onto the project at the end just to enter a prize category.

If removing Solana left the central concept unchanged, the integration was not meaningful enough.

So instead of using blockchain for the dog's life itself, I used it for the part of the experience concerned with permanence.

The dog is temporary.

The moment is temporary.

The proof can remain.

A Life Built From Small Choices

The first half of STAY is an authored dog-life simulation.

Milo progresses through multiple life stages and encounters events such as:

his first walk
a destroyed shoe
rainy afternoons
birthdays
trips
favourite toys
photographs
familiar parks
quiet workdays
slower mornings
his final chapter

The user makes small choices throughout those moments.

Those decisions feed the same underlying life state.

STAY tracks values such as:

shared days
walks
play
work
treats
adventures
photographs
memories

Some decisions return later.

A toy introduced when Milo is young can become a worn object years later.

A park can feel different because you have already spent time there.

The goal was to make his life feel like one continuous history rather than a sequence of unrelated prompts.

Milo Is Part of the Interface

I did not want Milo to feel like an illustration sitting next to a web application.

He is the visual anchor of STAY.

The interface reacts around him.

His attention can follow the visitor or objects inside scenes.

His behaviour also changes as he ages.

Puppy Milo is restless and responsive.

Adult Milo is calmer.

Senior Milo reacts more slowly and spends more time resting.

The interface does not need to announce:

Milo is getting old.

You begin to notice it.

That becomes especially important during the ending.

For most of the experience, Milo is always there.

Then he isn't.

The absence is the storytelling.

Memories, Not Scores

When Milo's life ends, STAY does not rank the player.

Instead, it reconstructs the life they actually experienced.

It shows:

how long Milo lived
how many days were shared
which experiences happened
which memories survived

The user can then choose the memories they want to preserve.

Those selected moments form a canonical memory manifest.

STAY then generates a SHA-256 hash from that manifest.

That hash becomes the compact proof of the exact memory set.

Preserving Milo's Life on Solana

The Solana flow is deliberately small.

STAY can commit information such as:

proof version
life ID
owner wallet
memory count
manifest hash
completion timestamp

to a real transaction on Solana devnet.

When the transaction confirms, STAY displays the real signature and verification information.

The proof can be independently inspected through Solana Explorer.

The application never fabricates a transaction.

If a wallet is unavailable or the user chooses not to submit anything on-chain, STAY still allows a local version of the experience.

That state is explicitly labelled:

LOCAL PREVIEW - NOT ON-CHAIN

A successful blockchain preservation is separately shown as:

VERIFIED ON SOLANA DEVNET

The distinction is intentional.

A demo should never pretend to be blockchain activity.

PRESERVE TODAY

The final part of STAY is where the fictional story becomes personal.

After completing Milo's life, the user sees:

MILO'S STORY WAS SIMULATED.
YOURS ISN'T.

They can then preserve one ordinary day with their real dog.

The flow is simple:

take or upload a photograph
enter the dog's name
add a short note
confirm the date
create the memory proof

The image is hashed locally using SHA-256.

STAY then creates a deterministic manifest containing the image hash and associated memory data.

The photograph itself remains off-chain.

Solana stores or commits to the proof.

That separation is important.

STAY is not pretending a blockchain is a photo-storage service.

Instead:

the image contains the memory

and

Solana proves the integrity of that memory

The proof can include information such as:

memory ID
image hash
manifest hash
wallet
timestamp
proof version

If the canonical image changes, the image hash changes.

If the memory metadata changes, the manifest hash changes.

That means the original memory can later be checked against its recorded proof.

Verification

STAY includes verification logic for preserved memories.

The application can:

load the memory
recompute the image hash
reconstruct the canonical manifest
generate the manifest hash again
compare those values with the stored proof
show whether they match
expose the associated Solana transaction when one exists

A modified image should no longer produce the same proof.

This turns the Solana integration into something inspectable rather than decorative.

The Memory Box

Preserved moments live inside a Memory Box.

I intentionally avoided presenting them as NFTs or a crypto portfolio.

The visual language is closer to a physical archive:

photographs
dates
annotations
familiar objects
warm paper
fragments from Milo's life

Technical details are still available for verified memories:

memory ID
image hash
manifest hash
owner wallet
network
Solana transaction signature

But those details are secondary.

The emotional object is the memory.

The blockchain is the receipt.

Visual Direction

I wanted STAY to feel nothing like a conventional Web3 application.

So I deliberately avoided:

crypto dashboards
token charts
purple gradients
glassmorphism
card-heavy layouts
wallet-first onboarding
NFT marketplace aesthetics

The visual direction is closer to an interactive editorial piece or small narrative game.

It uses:

large character-led compositions
warm paper textures
photography
restrained typography
subtle motion
physical-memory references
objects that gain meaning because they return later
Milo as a persistent character rather than a mascot

The wallet only becomes important once there is something worth preserving.

That was intentional.

Technology should not interrupt the life.

It should matter when the life becomes a memory.

Prize Categories

Best Use of Solana

STAY is submitted for Best Use of Solana.

The core blockchain loop is:

life → memories → canonical manifest → SHA-256 hash → Solana transaction → verification

For a real dog, that becomes:

real moment → photograph → image hash → deterministic memory manifest → Solana attestation → independently verifiable memory

There is no token.

There is no marketplace.

There is no "mint your dog" mechanic.

STAY uses Solana because the project ultimately asks one question:

What can remain after a moment is gone?

The blockchain is not the story.

It is proof that the story existed in that exact form.

Dogs have a strange relationship with time.

They arrive and become part of the routine so quickly that it feels permanent.

Walks.

Shoes.

Rainy afternoons.

Photos you almost didn't take.

Sleeping beside your desk while you work.

Then eventually those ordinary days become the things you remember most.

STAY is about noticing them before that happens.

They cannot stay forever.

The memory can.

After Supper: Rewinding a Family Dinner Through Memory

Adedeji Olamide — Fri, 14 Aug 2026 23:58:18 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

I built AFTER SUPPER, an interactive landing page about comfort food, memory, and the people around the table.

Instead of beginning with a perfect plate of food, the experience opens at 20:47 - after dinner is already over.

The plates are nearly empty. The serving bowl has been scraped down. A napkin is crumpled. One chair sits out of place. There are crumbs, stains, water rings, and all the small traces people leave behind when a meal has actually been lived in.

The central interaction is simple: you move backwards through the dinner.

The timeline runs through:

20:47 - After Supper
20:31 - Last Bite
20:09 - Seconds
19:43 - Served
19:21 - Recipe
18:58 - Before Dinner
19:14 - Full Reconstructed

As time reverses, the table slowly reconstructs itself.

Food returns to the plates.
The serving bowl fills again.
Glasses refill.
The napkin straightens.
The chair moves back toward the table.
The warmth of the room returns.

Until eventually:

Everyone was still here.

For this project, I wanted to explore the idea that comfort food is rarely just about the food itself.

It is also the person who always serves everyone before themselves. The person who says they are not hungry and then asks for seconds. The recipe card with instructions like “pepper - you know.” The old stain nobody remembers making. The chair that is always slightly out of place.

So rather than building a restaurant page, recipe catalogue, or food delivery interface, I made the dinner table itself the interface.

Several objects on the table can be inspected to reveal small memories:

a plate connected to a second helping
the central serving dish and family recipe
a drinking glass tied to a recurring ritual
the serving spoon
an old linen napkin
a chair
a worn recipe card

The visual system combines generated 3D/editorial-style food assets with native frontend interaction, typography, motion, and accessibility controls.

The goal was to make one ordinary family dinner feel worth remembering.

Demo

Live Demo:
https://after-supper.vercel.app/

Source Code:
https://github.com/xyzbutworse/after-supper

Move backwards through the timestamps to reconstruct the dinner, then inspect the marked objects around the table.

The experience is designed around one persistent dinner scene that changes through the evening, from the aftermath at 20:47 back to the moment when everyone was still here.

Journey

The project started as a much more conventional comfort-food landing page.

That idea lasted about five minutes.

There are already countless beautiful restaurant pages, recipe sites, food galleries, and menu experiences. I wanted the interaction itself to communicate the theme rather than simply wrapping good photography in a polished layout.

That led to the question that defined the whole project:

What if the first thing you saw was not the dinner, but what remained after it?

From there, the experience became a reverse reconstruction.

One of the most important design decisions was keeping everything inside one persistent dinner scene.

Rather than jumping between unrelated sections, the same table changes through different moments in the evening. Each timestamp represents a different state of the same place.

That allowed the chronology to become both the navigation system and the storytelling device.

Building the visual system

I wanted the table to feel tactile and cinematic without turning the project into a generic glossy 3D landing page.

The material language was kept intentionally domestic:

warm worn wood
matte ceramic plates
clear drinking glasses
brushed metal utensils
soft linen
handwritten paper
rice grains, sauce traces, crumbs, stains, and other imperfections

I used AI-assisted image generation to create a consistent visual world for the dinner, including different table states and individual objects.

Those assets were then integrated into the frontend as controllable layers rather than being used as a single static hero image.

That made the imagery part of the interaction.

Designing motion around the story

The motion system was built around one rule:

Nothing should animate just because it can.

The objects should feel like they are returning to an earlier moment in time.

Instead of random entrance animations, things reconstruct:

plates refill
glasses become fuller
crumbs disappear
the napkin becomes ordered again
objects settle back into place
the table gradually becomes warmer and more complete

The final reconstruction is intentionally the strongest moment of the page.

After moving through the aftermath of the dinner, the user finally reaches the full table and the line:

Everyone was still here.

That was the moment I designed the rest of the project around.

Accessibility

Because accessibility is part of the Perfect Landing criteria, I did not want the project to depend entirely on motion or mouse interaction.

The experience includes:

semantic buttons for interactive objects
keyboard-accessible chronology navigation
visible focus states
Escape handling for memory panels
state announcements for assistive technology
reduced-motion support
responsive mobile behavior
readable story content that still makes sense without the full animation system

Users who prefer reduced motion still get the same sequence through simpler state changes.

What I Learned

The biggest lesson from this build was that a landing page does not need a large feature set to feel substantial.

The strongest part of AFTER SUPPER is not the number of interactions.

It is that the visual design, motion, navigation, copy, and concept are all trying to say the same thing.

One table.
One dinner.
One evening played backwards.

I am particularly proud that the final experience does not need accounts, dashboards, APIs, recommendations, checkout flows, or a dozen pages to communicate its idea.

It just needed a table that remembers.

Comfort food is not only what was on the plate.

It is remembering who was around it.

SIGNAL — Alan Turing, Juneteenth, and the solstice, in three playable acts

Adedeji Olamide — Sun, 21 Jun 2026 15:11:12 +0000

This is a submission for the June Solstice Game Jam

What I Built

SIGNAL is a three-chapter browser game about messages that someone tried to stop, and that got through anyway. Each chapter is its own kind of game, set in a different year, tied together by one idea: the moments that change history usually start with a signal that refuses to die.

Chapter 1: The Machine (1943). You sit at Bletchley Park breaking ciphers on an Enigma-style wheel. The messages you decode were written by people who couldn't say out loud who they were. Crack one, and Alan Turing reads it and talks to you about what you found.

Chapter 2: The Word (June 19, 1865). You become General Order No. 3, the order that reached Texas two and a half years late and finally ended slavery there. It plays as a side-scroller through a greyscale world, and every person you reach restores one stripe of the Pride flag to the screen.

Chapter 3: The Light (June 21, 2026). The game checks today's date. Play it on the solstice and the sky renders differently. Then it looks back at everything you did across the first two chapters, writes you a short personal message, and asks one question: what signal will you send?

That's the theme connection, top to bottom. The solstice is the literal hinge of Chapter 3, since the game knows when June 21 is. Pride runs through the hidden-identity messages of Chapter 1 and the color restoration of Chapter 2. Juneteenth is the entire premise of Chapter 2. June being Turing's birth month is why Chapter 1 exists at all.

Video Demo

Code

GitHub: https://github.com/cybort360/signal

Play it in the browser: https://signal-six-lyart.vercel.app

How I Built It

The stack is small on purpose: Vite, Phaser 4, and the @google/genai SDK for Gemini. No React, no TypeScript. Phaser already hands you scenes, input, audio, and a game loop, so a second framework would just be weight.

A few decisions worth calling out.

Every Gemini call lives behind one file. GeminiService.js is the only place that imports the SDK, and it has two rules it never breaks. It races every call against a 10-second timeout, and it never throws. If the API is slow, errors out, or you're offline, the player gets a hand-written fallback instead of a spinner. I wrote eight fallbacks per call type so the canned lines don't repeat or read as canned. So Chapters 1 and 2 play fine with the network unplugged; only the live Turing lines and the ending reach out.

The cipher is Vigenère, not a real Enigma. Simulating actual rotors would have eaten the whole jam. Vigenère reads as real encryption on screen, it's clean to write as pure functions, and it sits right next to what Bletchley was actually up against. The cipher math has its own unit tests; 55 tests total run on vitest, covering the encoding, the save system, and the AI fallbacks.

Nothing is imported art. The Enigma wheel, the signal particle, the citizens, and the gradient skies are all drawn at runtime with Phaser's graphics API. That kept the build tiny and gave the game one consistent, schematic look without me opening an image editor once.

State carries across the whole game. A single PlayerState object tracks how many ciphers you cracked, how accurately, who you reached in Chapter 2, and what you said to Turing. Chapter 3 feeds all of it into the Gemini prompt, which is why the ending speaks to your specific run instead of a generic one.

The honest messy part: I found a bug late where pressing Enter to skip the Chapter 1 intro leaked into the cipher wheel and confirmed a stray letter, quietly corrupting your first key. It took a real play through to catch. The fix was to drop Enter as a confirm key and keep confirmation on Space only.

It ships to Vercel as a static site. One tradeoff comes with that: the Gemini key gets compiled into the client bundle. Fine for a jam, not something I'd push to production without locking the key to a domain.

Prize Category

I'm submitting for both optional categories.

Best Ode to Alan Turing. Chapter 1 is the whole tribute. It's set at Bletchley in 1943, the mechanic is code-breaking, and Turing shows up as a Gemini-powered character who reacts to what you decode. The deeper idea is the one that haunts his story: he built a machine to uncover hidden messages while having to hide who he was. The messages you decrypt were written by people doing exactly that, and Turing's dialogue keeps circling the gap between the secret you break and the secret you keep.

Best Google AI Usage. I used the Gemini API (gemini-2.5-flash-lite) in two places, and tried to make the AI do something a script couldn't. In Chapter 1, Turing's replies are generated against the actual message you just decoded, so he's answering content rather than playing a tape. In Chapter 3, the model reads your entire play through and writes a personal closing note. I ran it with thinking disabled and a 300-token cap because the writing is short, wrapped every call in the timeout-and-fallback net above, and kept all the prompts in one config file. The result is AI that carries the emotional payoff but can't break the game if the network does.

I Built an Agent That Does VC Due Diligence in Minutes

Adedeji Olamide — Thu, 28 May 2026 18:42:17 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

A few weeks ago I was looking at a list of hackathon submissions and noticed something. Every single project was for developers. Observability agents. Code review bots. Database query assistants. Debugging tools. All useful, all for people who already spend their days in a terminal.

Nobody had built anything for the people who don't.

That's when I thought about VC due diligence. The process that takes 2-4 weeks per deal is, at its core, mechanical. You need to know the market size. You need to map the competition. You look up the founders' previous companies. You read what people say on Reddit and Hacker News. You check how much funding they've raised and who from. None of this is strategic thinking. It's information retrieval, repeated across dozens of sources, by analysts who are overqualified for it.

So I built Axiom, an autonomous startup due diligence agent powered by Hermes Agent.

You type one command:

/axiom-diligence Perplexity AI perplexity.ai

Axiom spawns 7 parallel research sub-agents using Hermes's delegate_task tool:

Agent	What It Researches
Market	TAM, growth rate, timing signal
Competition	Direct/indirect competitors, moat assessment
Founders	Prior companies, exits, reputation signals
Technology	GitHub activity, stack, build vs. buy assessment
Customer Sentiment	Reddit, HackerNews, review sites
Regulatory Risk	Relevant laws, litigation signals, compliance
Financial Signals	Crunchbase funding, investor quality, revenue signals

The orchestrator synthesizes all 7 findings into a structured investment memo with a verdict (INVEST / MONITOR / PASS), confidence score, bull case, bear case, open diligence questions, and all sources cited. Output saves as JSON and Markdown, and renders in a Streamlit dashboard.

Demo

The Streamlit dashboard renders the full VC-style memo with color-coded verdict, five signal metrics, and section-by-section research breakdowns.

GitHub: github.com/cybort360/axiom

Code

github.com/cybort360/axiom

The project structure:

axiom/
├── skills/
│   └── axiom-diligence/
│       └── SKILL.md          ← Hermes skill: the full research methodology
├── mcp/
│   └── axiom_mcp.py          ← Custom MCP server: HN, Reddit, Crunchbase, GitHub
├── web/
│   └── dashboard.py          ← Streamlit: VC-style memo viewer
├── setup.sh                  ← One-command install
└── demo.sh                   ← Run demo on any company

One-command setup:

git clone https://github.com/cybort360/axiom
cd axiom
bash setup.sh

My Tech Stack

Hermes Agent: the agent runtime, skills system, and delegate_task for parallel sub-agents
FastMCP / mcp Python package: custom MCP server for structured data access
httpx: async HTTP client for HackerNews, Reddit, Crunchbase, GitHub APIs
Streamlit: investment memo dashboard
Python venv: dependency isolation

Data sources used (all free, no paid APIs):

Source	What We Pull	How
HackerNews	Stories, comments, founder mentions	Algolia HN API (free, no auth)
Reddit	User discussions, complaints, praise	Reddit public JSON API
Crunchbase	Funding rounds, investors, headcount	Public profile scrape
GitHub	Repos, stars, contributor signals	GitHub public API
Greenhouse / Lever	Open roles by department	Public ATS APIs
Web search	Market size, news, competitors	Hermes built-in web_search

How I Used Hermes Agent

Hermes Agent's delegate_task tool is the reason Axiom works. Without it, a single-agent loop running 7 research threads sequentially would take 10x longer and would hit context limits trying to hold everything in memory.

With delegate_task, each sub-agent runs concurrently, stays focused on its own research slice, and hands back a clean JSON object. The orchestrator gets structured inputs from specialists rather than trying to do everything itself.

Here's what the market research delegation looks like in the SKILL.md:

delegate_task: |
  Research the total addressable market for [company].
  Use web_search to find:
  1. Market size estimates from analyst reports
  2. Year-over-year growth rate
  3. Timing signal: too early, right moment, or saturated?
  4. Key market drivers

  Return JSON with keys:
  tam_estimate, growth_rate_yoy, timing_assessment,
  market_drivers, comparables, sources

Every sub-agent returns a strict JSON schema. The orchestrator never parses free text. It calculates.

The MCP server gives Hermes structured access to six data tools (HackerNews, Reddit, Crunchbase, GitHub, hiring signals, report saving) without any paid API keys. Adding new data sources means adding one Python function.

The skills system makes the research methodology portable. The 363-line SKILL.md defines how a trained analyst would approach each dimension, what questions to ask, what signals to weight, and what the output schema must look like. Install the skill once and use it from CLI, Telegram, or Discord.

Two things surprised me during the build. First, the quality of free data: HackerNews comment threads on a startup's launch post contain more honest signal than most analyst reports. Second, how much the output schema matters. Early versions returned free-form text from sub-agents. Once I forced strict JSON schemas, synthesis became deterministic.

Axiom turned a use case that normally takes weeks and a team of analysts into a command you type once.

Synaptic: A Local-First AI Dev Companion That Remembers How You Think

Adedeji Olamide — Sat, 23 May 2026 04:52:29 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Three weeks into learning Rust, I had Copilot open and Stack Overflow in the next tab. I was making progress — or so I thought. I'd ask Copilot how to handle an error, paste the answer in, the compiler would go green, and I'd move on.

Six days in, I realised I had no idea what I was doing.

I could produce Rust. I couldn't think in Rust. Copilot was making me a faster copy-paster. It wasn't making me a developer.

What I needed wasn't more autocomplete. I needed something to stop me before I typed and ask: "Do you actually understand what you're about to do?"

That question became Synaptic.

Synaptic is a local-first AI dev companion powered entirely by Gemma 4. It watches your entire development environment — files, terminal, errors, shell history — and builds a persistent model of how you specifically think and solve problems. When you're stuck or learning a new language, it surfaces your own past solutions rather than generic documentation pulled from the internet.

The centrepiece is the Socratic gate.

When you open a code file, Synaptic reads your last few hours of activity, identifies what concept is most at stake in that file, and streams a targeted question into a HUD overlay within seconds:

"You've been writing JavaScript closures recently. Before you edit this Rust file: how are you thinking about ownership and when values go out of scope?"

The question isn't generic. It's built from your actual history. Gemma 4 evaluates your answer and either lets you through or asks a sharper follow-up targeting exactly what you glossed over. Over time, your explanations get sharper — because the bar doesn't lower.

Beyond the Socratic gate:

Ambient memory pipeline — every file save and terminal command is compressed by Gemma 4 into a structured memory (summary, concepts, significance score, verbatim error text) every 3 seconds, stored locally in SQLite and indexed for semantic search

Vision error pipeline — on macOS, when a terminal error fires, Gemma 4 reads a screenshot of your actual screen to extract the full stack trace, not the truncated shell history
Four query modes — Translate (JS patterns to Rust), Explain (grounded in your own history), Map Concept (to what you already know), Find Solution (have I solved this before?)

Habit mismatch detection — runs continuously, warns when you apply patterns from your old language that will break in your new one

Stuck detection — watches for compound signals (repeated errors, thrashing, excessive app switches) and auto-surfaces the HUD with relevant context before you ask
Electron HUD overlay — always-on-top, appears uninvited when it has something worth saying Everything runs on your machine. No API keys required. No data leaves without your permission.

Live site: https://synaptic-ebon.vercel.app

Docs: https://synaptic-ebon.vercel.app/docs

Demo

Quick start to try it yourself:

git clone https://github.com/cybort360/synaptic
cd synaptic && npm install
ollama pull gemma4:e4b
ollama pull nomic-embed-text
cp synaptic.config.example.json synaptic.config.json
# Edit synaptic.config.json and add a directory to watchPaths
npm run launch

Open a .rs, .ts, .py, or .go file in a watched directory. The HUD will appear within seconds with a question grounded in your recent activity.

Code

GitHub: https://github.com/cybort360/synaptic

The full pipeline in one view:

Files / Terminal / Shell history
        ↓
    Observer (chokidar + history polling + stuck detector)
        ↓
    Archivist
      ├─ Compressor: gemma4:e4b (every 3s, with vision on errors)
      ├─ Embedder: nomic-embed-text (semantic search vectors)
      └─ SQLite (local, persistent, yours)
        ↓
    Connector
      ├─ Semantic search over history
      ├─ Prompt builder (4 modes)
      └─ Reasoner: gemma4:e4b (streaming)
        ↓
    Socratic Engine
      ├─ Fires on file open for recognised code files
      ├─ Streams question word-by-word to HUD
      └─ Evaluates answer, asks follow-up or passes
        ↓
    Dashboard (http://localhost:3777) + HUD Overlay (Electron)

Stack: Node.js 20, TypeScript, Express, WebSocket, Electron, chokidar, sql.js (SQLite), Ollama. No frameworks. No bundler. Around 5,700 lines of original code.

How I Used Gemma 4

I used gemma4:e4b — the 4B effective parameter model — and the choice was deliberate at every level.

Why E4B specifically

Speed is the constraint. Synaptic compresses every file save and terminal command into a structured memory on a 3-second batch cycle. That cycle is a constraint, not a goal — if compression falls behind, the memories become stale. The Socratic question about your Rust ownership file would be grounded in something you did yesterday rather than what you were doing five minutes ago.

I tested gemma4:26b for this. The batches piled up. The tool became a liability. At 4B effective parameters, gemma4:e4b compresses an event in under 2 seconds on a MacBook. The 3-second cycle stays clean. Memories are always fresh.

Multimodal was the unlock. When you hit a terminal error, your shell history often truncates it. The important part — the line number, the variable name, the exact constraint violated — is three screens down.

Gemma 4 is natively multimodal. When Synaptic detects a terminal error, it captures a screenshot of your screen and sends it to Gemma before compression. Gemma reads the actual stack trace off your screen, not the truncated history. This is only possible with a vision-capable model. A text-only 4B model cannot do it. A vision-capable model too large to run locally cannot do it either. gemma4:e4b is the exact intersection: small enough to run constantly, fast enough for real-time use, and genuinely multimodal.

The Socratic gate depends on first-token latency. The gate fires when you open a code file. The HUD slides up. The question starts streaming in word by word while Gemma is still generating. With gemma4:e4b, the first token arrives in under 3 seconds on a MacBook M-series. The question types itself in as the developer reads it. With a larger model, the developer is already ten lines deep before the question finishes generating — and the gate becomes noise.

What breaks with a different model

Alternative	What fails
A 27B local model	Compression batches pile up. The 3-second cycle becomes 30+ seconds and memories fall behind real activity
A non-multimodal 4B	Vision pipeline silently degrades. Errors are compressed without reading the actual screen output
A cloud-only model	The entire privacy guarantee breaks. Code, errors, and history leave your machine
No local model at all	Socratic gate cannot fire on every file open. Latency makes it unusable as a real-time feature

The three tiers Gemma 4 powers

Task	When	Why Gemma 4
Event compression	Every 3 seconds	Speed. Needs to complete before the next event arrives.
Vision error analysis	On terminal errors (macOS)	Multimodal. Reads the actual stack trace off the screen.
Reasoning + Socratic evaluation	On every query and file open	Quality. Generates personalised questions and evaluates answers.

A separate nomic-embed-text model handles embeddings for semantic search — it outperforms a generalist 4B model at this specific task, so I kept it.

What Gemma 4 made possible that wasn't before

The core thesis of Synaptic is that local AI is now capable enough to be the primary intelligence of a real product — not just a demo. gemma4:e4b can read screenshots, generate coherent structured analysis, evaluate the quality of a developer's reasoning, and do all of this on a consumer laptop in real time.

That's new. Six months ago you had to choose between capable and local. With Gemma 4 you don't.

GreenStep AI

Adedeji Olamide — Mon, 20 Apr 2026 03:12:37 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

GreenStep is a web app that shows you how to lower your carbon footprint and understand it better. Most people have a vague sense that their habits affect the planet but no clear picture of how much. GreenStep makes that happen.

You log your daily activities like driving to work, taking a flight, or eating a burger into the app, and it instantly tells you how much CO2 those activities produce. A live dashboard shows your footprint growing over time with charts, so you can see trends right away. The Google Gemini-powered AI layer looks at your personal activity data and gives you specific, actionable suggestions based on your habits. These are not general tips, but suggestions based on what you actually logged.

The goal was easy: show what was hidden. When you realise that your carbon footprint is a real number that changes with every choice you make, you start making different choices.

Demo

Deployed URL — https://green-step-ai.vercel.app

Screen recording — https://youtu.be/sAft5XNsWeU?si=hrqVKmSPTdfvtoWH

Code

GitHub repo — https://github.com/cybort360/greenStep-AI

How I Built It

Stack: React, Next.js, Tailwind CSS

Frontend: I used React and Next.js to build the UI. The activity logging form is easy to use; just choose a category (transport, food, energy, shopping), fill in the details, and submit. Each submission hits an API route that uses standard emissions factors from the EPA and IPCC datasets to calculate the CO2e value.

Charts and Dashboard: The progress dashboard uses Recharts to show line and bar charts of your footprint over days and weeks. You can see which categories add the most to your total. For most people, transport is the biggest one.

Google Gemini: The app sends a structured summary of a user's recent activities to the Gemini API after they log them. The prompt breaks down the activities by category and asks Gemini to come up with three to five specific, ranked suggestions based on what would have the biggest impact on that user. The response streams back and shows up right away in the UI. This isn't a list of general tips; Gemini looks at your real data and reacts to it. If you've flown three times this month, for instance, it will put that ahead of telling you to switch to LED bulbs.

Backboard: I used Backboard to keep the app's data in sync in real time. When you log an activity, your dashboard updates right away without having to refresh the page. Backboard keeps track of the live state so that your totals and charts show new entries as soon as they are made. When the main loop is "log something, see its effect right away," this made the experience feel responsive instead of static and also give the AI memory.

Key Decision: I made the activity input on purpose very simple. I wanted there to be no friction between a user's daily moment ("I just drove 30 miles") and logging it. People often give up on complicated carbon calculators because they ask for too much up front. GreenStep only asks for the bare minimum to get a useful number, and then it lets Gemini fill in the rest.

Prize Categories

Best Use of Google Gemini: Gemini powers the AI recommendation engine. It receives a personalized summary of the user's logged activity data and generates ranked, specific suggestions for reducing their footprint. The integration is core to the product. Without it, GreenStep is just a calculator. With it, it becomes an advisor.

Best Use of Backboard: Backboard drives the real-time sync layer. Activity logs written by the user propagate instantly to the dashboard, keeping charts and totals live without requiring manual refreshes or polling. It made the feedback loop between "I did this" and "here is its impact" feel immediate.

Why I Want to Be a Front-End Developer and How HNG Will Help Me Achieve My Goals

Adedeji Olamide — Fri, 31 Jan 2025 21:13:25 +0000

My Motivation: Bridging Creativity and Technology

From the moment I built my first webpage, I was hooked. Front-end development captivated me with its blend of creativity and technical precision, transforming lines of code into visually stunning, user-friendly interfaces. But my aspirations don’t stop there. My ultimate goal is to become a blockchain developer, creating decentralized applications (dApps) that empower users with transparency and security.

Front-end development is the perfect foundation for this journey. Blockchain technology thrives on user adoption, and intuitive interfaces are critical for making complex systems accessible. By mastering front-end skills like HTML, CSS, and JavaScript, I aim to build seamless experiences that bridge users with blockchain’s transformative potential.

How HNG Will Accelerate My Growth

The HNG Internship is a launchpad for aspiring developers like me. Here’s how it aligns with my goals:

1. Mastering Core Front-End Technologies

HNG emphasizes hands-on learning with modern web development tools. Their focus on JavaScript—a language pivotal for both front-end and blockchain development—will strengthen my ability to create dynamic interfaces. JavaScript frameworks like React, which HNG covers extensively, are also widely used in blockchain projects for building dApp frontends.

2. Collaboration and Real-World Projects

The internship’s collaborative environment mirrors real-world tech teams. Working on projects with peers will teach me agile workflows and version control, skills essential for contributing to open-source blockchain platforms. Moreover, HNG’s network includes professionals who can offer mentorship on integrating front-end systems with blockchain backends.

3. Pathway to Blockchain Development

While HNG’s web development program hones my front-end expertise, their JavaScript-centric curriculum (see HNG’s JavaScript Developer Hiring) prepares me for backend logic. This duality is crucial for blockchain, where smart contracts (often written in JavaScript-based languages like Solidity) require robust front-end integration.

My Goals for the HNG Internship

Build a Strong Foundation in Front-End Development

Action Plan: Complete all tasks diligently, focusing on responsive design and JavaScript frameworks.
Outcome: Create portfolio projects showcasing interactive web apps.

Explore Blockchain Integration

Action Plan: Use HNG’s resources to learn how APIs connect frontends with blockchain networks. Experiment with libraries like Web3.js.
Outcome: Develop a basic dApp interface that interacts with a blockchain testnet.

Network with Industry Professionals

Action Plan: Engage actively in HNG’s community, seek feedback, and connect with mentors experienced in blockchain.
Outcome: Gain insights into transitioning from front-end to blockchain roles.

The HNG Internship isn’t just a stepping stone—it’s a catalyst. By refining my front-end skills here, I’ll be equipped to tackle the unique challenges of blockchain development. Every button I design, every API I integrate, and every line of JavaScript I write brings me closer to my goal: building decentralized solutions that redefine how we interact with technology.