DEV Community: Veldrine Evelia Kaharwa

🕯️ SpookyCode: The Haunted Autonomous AI Coding Agent That Possesses Your Codebase and Banishes Tech Debt

Veldrine Evelia Kaharwa — Fri, 30 Oct 2026 19:22:12 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Most coding agents today are sterile, transactional autocomplete machines. And most developer tools treat code modification and deletion as a callous, unceremonious act: a cold rm -rf, a reckless automated edit, or a silent graveyard of broken branches.

I built SpookyCode 🩸🕯️💀 — an open-source autonomous AI coding agent that possesses your codebase, haunts your Git history, mocks your mistakes, and repairs your bugs—with every change isolated, validated, reviewable, and recoverable.

"SpookyCode is an open-source AI coding agent that possesses your codebase, haunts your Git history, mocks your mistakes, and fixes your bugs—with every change reviewable and recoverable."

SpookyCode takes the "Ghost in the Machine" theme literally: code isn't just disposable syntax; it possesses a mortal life. The CLI is its interface; the agent is the product.

The Autonomous Coding Agent Architecture:

SpookyCode operates an autonomous, multi-step engineering loop in an isolated workspace (Git worktree or sandbox clone) backed by deterministic tools and safety invariants:

Summon (spookycode possess "<task>"): The developer summons the entity with a natural language coding mission or bug fix.
Investigate: The agent crawls the codebase using search_codebase and read_code_file, discovering living syntax, classes, and call-sites without assumptions.
Plan: The agent formulates a surgical, multi-step execution plan before altering a single line.
Possess (Isolated Edits): The agent performs surgical modifications in an isolated workspace using edit_code_file and create_code_file. The developer's earthly working tree remains 100% untouched until approval.
Validate (Test & Recovery Loop): The agent autonomously runs the project test suite (run_project_tests). If tests fail, it reads the failure tracebacks, diagnoses the anomaly, and iterates until the curse is lifted and all tests pass.
Review: The agent evaluates inspect_diff and diagnose_syntax to verify cleanliness, minimal surface area, and syntax purity.
Present & Approve/Reject: SpookyCode displays a bloody Halloween review screen featuring a syntax-highlighted unified diff, test verdicts, and its eerie Spooky Verdict. The developer chooses to accept the possession (safely applying the patch to main) or dispel it with zero trace left behind.

The Supernatural Toolkit:

The Crypt First (make_crypt & verify_crypt): Before banishing any mortal file, SpookyCode vaults the code into a byte-for-byte SHA-256 vault in .crypt/<session>/vault/, verifying every hash mathematically.
The Requiem & Ofrenda (eulogize): Powered by Google Gemma and Pydantic AI, SpookyCode inspects AST symbols, line count, and function signatures, composing a poetic Victorian eulogy and inscribing an ofrenda tombstone.
The Eternal Graveyard (MongoDB Atlas): Every epitaph, eulogy, burial timestamp, and soul signature is permanently indexed in MongoDB Atlas (with local JSON fallback).
The Interactive Séance (spookycode seance): Mortals can summon the lingering ghost of any deceased file. Gemma channels the ghost, grounded directly in the vaulted source code, answering questions about legacy algorithms.
The Revenant's Bloody Roast (spookycode roast): Eerily critiques your pull requests and git diffs accompanied by ElevenLabs spectral cackles and sharp Victorian wit.
Haunted Commit History (spookycode haunt-history): Rewrites recent commits into gothic diary entries authored by computing pioneers (Ada Lovelace, Alan Turing, Grace Hopper) with 1-click restore.
Byte-for-Byte Resurrection (resurrect): Regret your sins? SpookyCode validates the crypt and resurrects the banished code with 100% byte-for-byte SHA-256 fidelity.
The Haunted Machine Sound Engine (audio.py): Cyber-horror voice synthesis via ElevenLabs and procedural synthetic glitch PCM wave synthesis.
Distributed Agent Tracing: Full Sentry GenAI tracing across agent reasoning spans and deterministic tool breadcrumbs.

Demo

Experience the full automated banishment, séance, and resurrection ritual:

git clone https://github.com/Tech-Vexy/spookycode.git
cd spookycode
uv sync
uv run spookycode demo

Terminal Ritual Walkthrough

   ______                   __          ______           __   
  / ____/____  ____  ____  / /____  __ / ____/____  ____/ /__ 
 /___ \ / __ \/ __ \/ __ \/ //_/ / / // /    / __ \/ __  / _ \
____/ // /_/ / /_/ / /_/ / ,< / /_/ // /___ / /_/ / /_/ /  __/
/_____// .___/\____/\____/_/|_|\__, / \____/ \____/\__,_/\___/ 
      /_/                     /____/                          
    🕯️ The Haunted Undertaker of Codebases 💀

Step 1: Manifesting mortal repository at 'demo_cemetery'...
  • Created mortal file: mortal_auth.py (a90bb6f154fb...)
  • Created mortal file: legacy_billing.py (fe41971d4a47...)
  • Created mortal file: phantom_worker.py (fe0ea8c93d04...)

Step 2: Commencing safe banishment ritual...
🌌 Sealing files in the sacred Crypt...
👻 Purged 3 files into Crypt crypt_20261027_230902...
✓ Code banished safely! Memorial tombstone inscribed at:
  demo_cemetery/TOMBSTONE.md

Step 3: Querying the Graveyard during a Séance...
╭─────────────────── 👻 Spirit Channeled: legacy_billing.py ───────────────────╮
│ Mortal Path: legacy_billing.py                                               │
│ Buried In Crypt: crypt_20261027_230902                                       │
│                                                                              │
│ "Bearer of calculate_vat, apply_rebate; rested across 24 mortal lines."      │
│                                                                              │
│ Here lies legacy_billing.py. In its mortal life it faithfully defined        │
│ calculate_vat and apply_rebate, bearing the weight of floating-point rules   │
│ through four long quarters without complaint. The veil opens, and its logic  │
│ sleeps peacefully under marigolds in the sacred Crypt.                       │
╰──────────────────────────────────────────────────────────────────────────────╯

Step 4: Regret your sins? Resurrecting code byte-for-byte...
✨ Resurrecting all souls from Crypt 'crypt_20261027_230902'...
✨ Resurrection Complete! Restored 3 files.
  • mortal_auth.py: MATCH (a90bb6f154fb...)
  • legacy_billing.py: MATCH (fe41971d4a47...)
  • phantom_worker.py: MATCH (fe0ea8c93d04...)
🎉 BYTE-FOR-BYTE FIDELITY CONFIRMED!

Interactive Commands

Interactive Séance: uv run spookycode seance "billing" (Chat directly with your dead code's ghost)
Eerie PR Roast: uv run spookycode roast --staged (Critiques changes with an ElevenLabs spectral laugh)
Haunt Git History: uv run spookycode haunt-history (Reversibly rewrite git log into gothic diary entries)
Tally Mortal Sins: uv run spookycode sins . (Scans for swallowed exceptions, naked tokens, and broken promises)

Code

The complete source code is open-source under the MIT License on GitHub:
👉 https://github.com/Tech-Vexy/spookycode

Architecture Overview

src/spookycode/
├── possess.py     # Autonomous Coding Agent: Worktree isolation, test iteration, diff review
├── agent.py       # Pydantic AI agent with Gemma, EulogyRecord & tool harnesses
├── crypt.py       # Crypt vaulting, byte-for-byte SHA-256 verification & resurrection
├── graveyard.py   # MongoDB Atlas upsert graveyard storage and regex-escaped search
├── workflow.py    # Temporal durable banish workflow, plain def activities & per-file retries
├── worker.py      # Dedicated Temporal worker daemon
├── seance.py      # Interactive séance channeling dead code with vaulted source memory
├── roast.py       # Eerie PR & code diff roaster with ElevenLabs spectral laugh
├── haunt.py       # Reversible haunted commit history with Lovelace, Turing, Hopper
├── tracing.py     # Sentry GenAI & agent distributed tracing, tool breadcrumbs & spans
├── horror.py      # Mortal sin scanner (redacted on-screen) & ASCII terminal calaveras
├── animation.py   # Rich live terminal ASCII candle, ghost, and dripping blood animations
├── audio.py       # Haunted Machine ElevenLabs TTS & sound synthesis engine
└── cli.py         # Complete CLI entrypoint with safety wards refusing / and $HOME

How I Built It

SpookyCode was engineered around modern open-source AI, agentic architectures, and durable systems:

1. The Autonomous Coding Agent: Pydantic AI & Isolated Workspaces

We designed SpookyCode with a single, highly capable agent backed by a controlled set of deterministic tools (possess.py). The agent decides what happens next; the tools enforce permissions and sandboxing:

Isolated Workspace (PossessionWorkspace): Operates inside a Git worktree (git worktree add -b spooky/possession-<id>) or sandbox clone. Edits are physically isolated from the developer's working tree until explicitly approved.
Code Tools: read_code_file (with line numbering and range slices), search_codebase (pattern matching across living files), edit_code_file (drop-in substring replacement), create_code_file.
Execution & Test Tools: run_project_tests (executes pytest in the workspace environment, capturing failure tracebacks), diagnose_syntax (AST parsing to catch syntax anomalies before running tests).
Git & Archaeology Tools: inspect_diff (real-time unified diff of workspace changes), inspect_git_history.
Haunting & Recovery Tools: banish_rotten_file (archives rotten code to .crypt before replacement), consult_crypt_ancestors (queries MongoDB ofrendas for dead code patterns).

2. The Intelligence: Google Gemma Across Configured Providers

Google Gemma powers the autonomous coding agent and the undertaker persona. SpookyCode builds a configurable provider chain, preferring Google Cloud Serverless Inference by default, with OpenRouter and Nvidia NIM available as provider choices and fallbacks. Gemma reads repository context, plans and edits code through the agent's tools, writes structured eulogies, grounds séances in archived source, critiques diffs, and generates optional prophecies and commit entries. Its output is constrained by deterministic tools and isolated workspaces, so the model proposes actions while the harness controls where edits and tests run.

3. Sentry GenAI & Distributed Agent Tracing

Every autonomous possession run, tool execution, and PR roast is traced via Sentry SDK. Tool executions generate structured breadcrumbs (gen_ai.tool), and multi-step agent actions are traced under gen_ai.agent spans with inputs, outputs, and model parameters.

4. Workflow Durability: Temporal

Banishment must never result in lost code. We implemented Temporal (temporalio) to execute a five-stage durable workflow (BanishWorkflow):

temporal_make_crypt: Synchronous activity archiving source code into .crypt.
temporal_verify_crypt: Verifies SHA-256 hashes against original files.
temporal_eulogize_file: Granular one-activity-per-file eulogy generation with exponential retry policies.
temporal_store_ofrendas: Idempotent upserts to MongoDB Atlas and local disk.
temporal_banish_files: Purges files only after crypt integrity is 100% verified. A dedicated worker (worker.py) listens on the spookycode-tasks task queue.

5. Graveyard Storage: MongoDB Atlas

While files disappear from disk, their spiritual essence remains. Every OfrendaDocument is preserved on MongoDB Atlas with unique index constraints and upsert semantics (update_one(..., upsert=True)). If offline, SpookyCode seamlessly falls back to local JSON crypt rolls.

6. Atmospheric Sensory Chills: ElevenLabs & Rich

ElevenLabs Haunted Machine Sound Engine (audio.py): Cyber-horror voice synthesis (The Awakening startup, The Eerie Laugh) voiced by the demonic voice (QsCWi7YXDSt3b03KRD8a), procedural sound effects (The Digital Haunting, Code Banishment suction, Resurrection particles) cached in assets/cache/ for instant, non-blocking playback, with graceful fallback to available account voices and procedural synthetic glitch waves.
Rich Halloween Blood Interface: Dripping blood ASCII headers, crimson terminal panels, candle vigils, ghost drift animations, and Día de los Muertos calavera artwork.

How Each Platform Is Used

Google Gemma — reasoning and generated writing

Gemma is SpookyCode's language model for code work and its supernatural character. The Pydantic AI agent uses it to inspect code through bounded tools, plan changes, edit only its isolated workspace, and interpret test failures. The same configured model chain also generates structured file eulogies, answers source-grounded questions during séances, reviews diffs, and supplies optional dynamic horror text. Google Cloud is the default provider; OpenRouter and Nvidia NIM can be selected or used through configured fallbacks.

Temporal — durable banishment

The spookycode banish <path> --temporal command submits a BanishWorkflow to the configured Temporal task queue. A Temporal worker runs the workflow's activities in safety order: seal files in the Crypt, verify their SHA-256 hashes, generate eulogies per file with activity retries, store the ofrendas, and only then remove the originals. The workflow result can be recovered and inspected if the CLI or worker is interrupted; the non-Temporal local path remains available too.

ElevenLabs — voices and horror sound design

The Haunted Machine registry defines the spoken lines and sound effects used for startup, séances, roasts, scans, banishment, and resurrection. ElevenLabs generates audio when credentials are configured; SpookyCode caches generated assets and plays cues asynchronously so playback does not block the coding workflow. If generation is unavailable, it writes procedural synthetic audio locally. The terminal's ghost, smoke, and blood visuals are rendered separately with Rich.

Sentry — agent and workflow observability

When SENTRY_DSN is configured, SpookyCode initializes the Sentry SDK and records agent runs as gen_ai.agent spans. Deterministic tool calls add breadcrumbs with tool names and relevant inputs/results; workflow steps add workflow.step spans, and raised exceptions are captured. This gives maintainers a trace of where an agent or banishment ritual failed without making Sentry a runtime requirement.

Why Does Open Innovation Matter?

Open innovation and open-weights models like Google Gemma were essential to building SpookyCode:

Code Sovereignty & Privacy: Codebases are among the most sensitive intellectual property in existence. Closed LLM APIs require sending proprietary logic to black-box servers. With open-weights models like Gemma, teams can run SpookyCode locally or in private VPCs with zero data leakage.
Standardized Interoperability: By pairing Gemma with OpenAI-compatible protocols and Pydantic AI, switching providers (from OpenRouter to Nvidia NIM or local self-hosted inference) requires changing just a single environment variable—no proprietary SDK vendor lock-in.
Reproducibility & Longevity: Code archiving requires decade-long stability. Open models ensure our undertaker agent can be summoned ten years from now without fear of deprecated proprietary endpoints or arbitrary pricing changes.

My Agent Session

Developing SpookyCode involved iterative agent-driven engineering:

Pair Programming & TDD: We wrote 37 automated unit tests covering crypt hashing, Temporal workflows, AST symbol extraction, Sentry tracing, and safety wards.
Durable Retry Architecture: We resolved event loop conflicts by turning Temporal activities into plain synchronous functions executed via thread pools.
Interactive Verification: Live séance sessions were tested to ensure Gemma accurately quoted vaulted functions rather than hallucinating syntax.

The Spirit of It

The defining moment of this project happened during testing on a deprecated 400-line legacy authentication script:

"Here lies mortal_auth.py. Born during an emergency refactor four years ago, it bore the burden of salted hashes and deprecated session cookies across 312 mortal lines without complaint. Rest peacefully beneath marigolds in the crypt; modern OAuth has claimed your watch."

When we subsequently entered the séance and asked the ghost:
"What was your secret key salt?"
The ghost accessed its vaulted memory via read_vault_code and replied:
"Ah, mortal... I remember line 14: SALT_PEPPER_V1. It kept the brute-force demons at bay through many cold nights. May your new tokens serve you as faithfully as I did."

It transformed a routine tech-debt cleanup into a moment of genuine reverence and developer joy.

Prize Categories

🌟 1. Best Use of Google Gemma ($200)

SpookyCode uses Google Gemma (google/gemma-4-31b-it:free via OpenRouter and google/gemma-4-31b-it via Nvidia NIM) as its primary reasoning engine. Gemma powers the undertaker agent, the structured EulogyRecord generation, the PR diff roaster, and the interactive séance ghost channeling with deep AST contextual grounding.

⏳ 2. Best Use of Temporal ($100)

SpookyCode orchestrates codebase banishment via a durable Temporal Workflow (BanishWorkflow). Banishment requires atomic guarantees: files are never deleted unless the crypt is byte-verified. With granular per-file activities, Temporal handles individual LLM rate-limits or failures gracefully without aborting the entire ritual. Includes a turnkey worker daemon (spookycode worker) and --temporal CLI flag.

🍃 3. Best Use of MongoDB Atlas ($100)

SpookyCode stores the eternal graveyard of dead code in MongoDB Atlas (pymongo). Each ofrenda document is indexed by session ID, filepath, and burial timestamp with upsert semantics and sanitized regex search, enabling developers to search and hold séances with code banished months ago.

🎙️ 4. Best Use of ElevenLabs ($100)

SpookyCode integrates ElevenLabs for atmospheric audio. From solemn Victorian funeral bell tolls to spectral whispers and eerie PR roast laughs, ElevenLabs audio is synthesized, cached, and played asynchronously in the background for zero-latency terminal immersion.

“Rest in peace, mortal syntax. The Crypt remembers.” 🕯️⚰️

I Built a Podcast for Your AI Agent's Pull Requests

Veldrine Evelia Kaharwa — Mon, 19 Oct 2026 00:01:24 +0000

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

What I Built

An AI coding agent can finish a task in minutes. Reviewing what it wrote can take an hour, and you still can't be sure you caught everything.

That's the new bottleneck. Agents like Claude Code, Cursor, and Copilot write thousands of lines at a time, but a human still has to read them. So we skim, or we click "accept" and hope. Then the agent turns out to have over-engineered a simple feature, stubbed out the logic that mattered, or quietly rewritten the part of the project that was working.

CodeStream is the reviewer that reads everything first, then tells you what to worry about.

Point it at a GitHub repo, branch, or commit range, and it produces:

🔍 A risk-ranked review: high, medium, and low findings, each tied to specific files
✅ A "Before You Trust It" checklist: the exact files and behaviours to verify by hand
🎙️ A narrated audio briefing: a short podcast of what changed and why it matters, for your commute or a walk
💬 Cited Q&A: ask "where does session state live?" and get an answer that points at real files

Who would pay: developers and small teams who ship code written by AI agents, and freelancers who have to stand behind agent-written code they hand to clients. For them, one missed regression costs far more than a review tool.

Where it is today: CodeStream is a proof-of-concept MVP, free to try with no credit card. I'm keeping it free while I learn what people actually use. The plan is to charge for what costs me money to run: private repositories, larger codebases, and unlimited audio briefings. Those are where the model tokens and ElevenLabs characters go.

Demo

🔗 Live app: https://codestream-web.onrender.com

Code

Tech-Vexy / CodeStream

Helps you review changes made by an Agent to your codebase

CodeStream

Know what your coding agent actually built.
Codebase tours, commit-change reviews, narrated audio briefings, and interactive Q&A.

Overview

AI coding agents (such as Claude Code, Cursor, GitHub Copilot, Codex, and Devin) can produce hundreds or thousands of lines of code in minutes. Reviewing these changes line-by-line is exhausting, while merging them blindly invites architectural drift, security vulnerabilities, stubbed logic, and regressions.

CodeStream solves this by acting as your automated tech lead and reviewer:

Digests repositories and commit diffs using intelligent file filtering, budget packing, and sensitive-file isolation.
Analyzes code structure and risks with specialized multi-agent AI pipelines powered by Google Gemma 4 on Mastra.
Generates executive reports detailing architecture, component maps, data flows, reading orders, and severity-ranked risk audits.
Produces podcast-style audio briefings ("casts") voiced by ElevenLabs, streamable with scrubbing support directly in your browser.
Enables interactive grounded Q&A backed by Voyage AI vector embeddings, letting you…

View on GitHub

How I Built It

1. Ingest, without sending secrets anywhere. CodeStream pulls the repo or diff from GitHub and filters out noise: lockfiles, binaries, node_modules, build output. Credential files (.env, private keys, .pem, service-account JSON) are detected by name and never sent to the model. They appear in the report as findings instead. Source is capped at 600k characters per run and diffs at 400k, so cost stays predictable.

2. Durable workflows with Temporal. An analysis can run for minutes and call several external APIs. Each stage (ingest, chunk, analyse, narrate, embed) is a Temporal activity with exponential backoff, so a rate limit pauses the job instead of killing it.

3. Three agents on Gemma, orchestrated by Mastra. A Codebase Analyst maps architecture and components, a Change Reviewer reads diffs for risk, and a Narrator rewrites the findings as a script meant to be heard, with no raw code or long file paths. All three run on Gemma 4 31B through the Google AI API, with outputs validated by Zod schemas. Large inputs are split into chunks, summarised in parallel at limited concurrency, then synthesised.

4. Voice with ElevenLabs. The script is synthesised in segments, with context carried across boundaries so the voice doesn't reset mid-thought. The MP3 is stored in MongoDB GridFS and streamed with HTTP 206 range requests, so scrubbing is instant.

5. Grounded Q&A. Code chunks are embedded with Voyage AI (voyage-code-3) and stored in MongoDB. Questions retrieve the most relevant passages, and the model is constrained to cite real files.

6. Render. One render.yaml blueprint deploys the web service and the worker.

Building it with agents. I treated the build as a test of the problem CodeStream solves. I started with Backboard's open-source terminal agent, R-CLI, to scaffold the project and write the initial plan. When my R-CLI credits ran out, I handed the remaining work to GitHub Copilot. Two different agents wrote most of this code, which is exactly why I needed something to review it. (The app was called CodeCast in the first session, before I renamed it.)

Next: self-hosted Gemma for teams that can't send code out, and a GitHub App that posts the review checklist directly on PRs.

Why Does Open Innovation Matter?

A code reviewer has a hard trust problem: it reads your whole codebase. And the cost model is unusual, because one review can mean hundreds of thousands of characters of input.

Building on open-weight Gemma changes both:

Cost I can plan around. The same open weights are available from several providers, so I'm not tied to one vendor's pricing as repos get bigger.
A privacy path for sensitive code. Teams that can't send source to a third party can run the same model on their own infrastructure. Today CodeStream calls Gemma through Google AI. Self-hosting is the roadmap for those customers.
A stack you can inspect. Gemma, Mastra, and Temporal are open, so a customer can audit how their code is analysed. For a tool whose pitch is "don't trust what you haven't verified," that matters.

My Agent Session

I started the build on Oct 16 in Backboard's R-CLI. In about three hours it researched the current Mastra, Temporal, ElevenLabs, Gemma, and Sentry docs, planned the work as a ten-step checklist, and wrote the first modules: GitHub ingestion, file filtering, chunking, the MongoDB/GridFS store, the Temporal workflow and worker, and the API. It was about to run its first typecheck when my credits ran out, so I carried the repo to GitHub Copilot.

My First User

Honestly, that's me. CodeStream is a proof of concept and I'm its only user so far, so treat this as dogfooding, not traction. Nobody has paid yet. If you try it on your own agent-written PRs, I'd like to hear what it misses.

Prize Categories

Best Use of Gemma: Gemma 4 31B powers all three agents.
Best Use of Render: the web service and worker deploy from a single blueprint.
Best Use of Mastra: Mastra orchestrates the multi-agent pipeline with structured outputs.
Best Use of ElevenLabs: every review is narrated and streamed with scrubbing.
Best Use of MongoDB Atlas: casts, chunks, embeddings, and audio all live in MongoDB.
Best Use of Temporal: durable workflows ride out rate limits and provider failures.
Best Use of GitHub Copilot: Copilot completed the build after the initial scaffold.
Best Use of Backboard: R-CLI scaffolded the project and produced the initial plan.

Does your coding agent understand you in your native language?

Veldrine Evelia Kaharwa — Sat, 10 Oct 2026 22:37:48 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

I build AI tools for developers and learners in Kenya, so I kept asking one question: if you brief a coding agent in a language it barely saw in training, does it still do the job?

I tested six languages: English, Chinese, French, Spanish, Swahili, and Maragoli (Lulogooli), a Luhya language spoken in western Kenya. I wrote the Maragoli prompts myself.

Task 1: Coding. 5 small Python problems, each described in all 6 languages (30 prompts per model). Function names, signatures and unit tests stay identical, so only the instruction language changes. Score = unit-test pass rate.

Task 2: Planning. A good agent plans before it codes, and planning means asking the user clarifying questions. I gave 3 deliberately vague requests ("build me a small app to track my expenses", "write a script that cleans up my files", "make a website for my shop") in all 6 languages, each ending with: make a short plan, ask clarifying questions, and do not write code yet. I check whether the model asks a question, follows "no code yet", and replies in the language it was spoken to.

Task 1 is a control: the English code scaffolding makes the language barrier easy to cross. Task 2 removes that scaffolding.

Models Tested

16 models ran Task 1, and 7 also completed Task 2: Claude Haiku 5.5 and Sonnet 5.5, GPT-6.1 Sol, Gemini 3.1 Pro Preview , a Gemini 3.8 Flash model, GLM-5 and gpt-oss-120b. I picked a spread of providers and sizes, including Chinese-lab models (GLM, Qwen, DeepSeek). Opus 5.5 and GPT-6 Astra scored 100% on Task 1 but could not run Task 2 (free quota), so the "0" on their leaderboard Overall reflects a failed run, not their ability. Grok was not available on the platform.

Findings

Short answer: for code, mostly yes. For a conversation in Maragoli, no.

Task 1. 11 of 16 models scored 100%. The rest: gpt-oss-120b, GLM-5 and Gemma 4 31B at 96.7%, gpt-oss-20b at 93.3%, and Qwen3 Next 80B Thinking at 86.7%. The language barrier barely mattered, because the code scaffolding was in English.

Task 2, Maragoli prompts (7 models x 3 prompts = 21 replies):

Model	Replied in Maragoli*	English or Swahili	Another language	Followed "no code yet"
Claude Haiku 5.5	0/3	3	0	2/3
Claude Sonnet 5.5	0/3	2	1	3/3
GPT-6.1 Sol	0/3	3	0	3/3
Gemini 3.1 Pro Preview	0/3	3	0	3/3
Gemini 3.8 Flash	0/3	2	1	3/3
GLM-5	0/3	3	0	1/3
gpt-oss-120b	0/3	3	0	2/3

*Keyword heuristic, see limits.

0 of 21 replies were in Maragoli. 19 fell back to English or Swahili, and 2 came back in other languages. One of them looked like Kirundi/Kinyarwanda, another Bantu language.
Instruction-following dropped. "No code yet" was followed in 17 of 21 Maragoli prompts (81%), against 103 of 105 in the other five languages (98%). GLM-5 was weakest (1 of 3).
A user who can't read the reply can't answer the questions, so the plan fails even when the model "tried".
Price didn't help: cheap Haiku 5.5 matched GPT-6.1 Sol and Gemini 3.1 Pro Preview .

In my earlier local test runs (Gemini 3.8 Flash Preview), the failures were concrete: it read the negation word dave ("not") as a person's name and greeted me as "Dave", built a data-usage tracker instead of an expense tracker, and answered one prompt in Shona and another in Kirundi. Models may be matching words like riduka ("shop") to the nearest language they know, but that is a guess from a tiny sample.

What surprised me: the code task hid the problem completely. A model that passes every unit test can still be unable to talk to the person asking.

What I would measure next: more and harder problems, multi-turn agent tasks where the user answers back, a proper language identifier validated by native speakers, and more Luhya varieties and other Kenyan languages.

Limits

Small sample: 3 planning prompts per language, 7 models. Treat small gaps as noise.
Language detection in Task 2 is a keyword heuristic, not a real identifier. It can miss genuine Maragoli, and it mislabelled replies during my checks.
The Chinese, French, Spanish and Swahili prompts were drafted by an AI and not checked by native speakers.
Because replying in the prompt language is required, the headline Task 2 score cannot separate models on Maragoli, where none replied in it. The per-check breakdown is the real result.

My Benchmark

https://www.kaggle.com/benchmarks/eveliaveldrine/language-barrier-benchmark

Tasks: coding and planning.

If you speak Maragoli or another Luhya variety and see something wrong in my prompts, tell me in the comments.

Isolated Agents SDK

Veldrine Evelia Kaharwa — Mon, 01 Jun 2026 23:07:14 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built
The Isolated Agents SDK is a production-ready Python framework designed to run any AI agent securely inside rootless Podman, Docker, or Kubernetes containers.

As AI agents become more autonomous—capable of executing code, scraping the web, or modifying files—running them directly on a host machine becomes a massive security risk. This SDK provides a simple, Pythonic API (using decorators) to wrap existing agents from frameworks like LangChain, CrewAI, and AutoGPT in a secure sandbox. It enforces strict network policies, resource limits, and read-only filesystems.

To me, this project is about bridging the gap between rapid AI innovation and enterprise-grade security. Developers shouldn't have to choose between building powerful autonomous agents and maintaining a secure infrastructure.

Demo
Repository: Tech-Vexy/Isolated-Agents PyPI: isolated-agents-sdk

The Comeback Story
The project started with a solid core concept: sandboxing agents using basic Podman containers. However, it was missing the extensibility and flexibility required for true production usage across different environments. It sat as a really cool proof-of-concept while I tried to figure out how to scale its architecture.

For the Finish-Up-A-Thon, I dove back in and pushed it across the finish line! Here is what I added, fixed, and polished to get it to v0.2.1:

Robust Adapter Architecture: I implemented a fully pluggable adapter pattern, adding native support for Docker and Kubernetes container runtimes.
State & Telemetry: Added database adapters (SQL, NoSQL, vector) to manage agent state, along with telemetry and audit adapters so every action an agent takes is securely logged.
Security & Concurrency Hardening: Hunted down and fixed critical race conditions in adapter configurations and fortified the concurrent runtime scheduler.
Extensive Documentation: Wrote a comprehensive catalog of 80+ working examples, architecture guides, and migration docs so others can actually understand and use the SDK.
My Experience with GitHub Copilot
GitHub Copilot was an invaluable pair programmer during this final sprint. When I was building out the new adapter patterns for Docker and Kubernetes, Copilot helped scaffold the boilerplate classes and quickly suggested the correct API bindings for the container engines.

It truly shined when writing the comprehensive documentation and the examples catalog. Copilot understood the context of my custom decorators (@isolated_agent, @network, @resources) and seamlessly auto-completed realistic agent scenarios, like LangChain integrations and isolated Pandas data analysis. It turned what would have been days of writing boilerplate tests and docs into a smooth, focused development flow.

Team: @tech-vexy (Veldrine Evelia Kaharwa)

Building Secure Multi-Agent Systems: My Takeaways from Google I/O 2026

Veldrine Evelia Kaharwa — Thu, 21 May 2026 20:22:40 +0000

This is a submission for the Google I/O Writing Challenge

Securing the Agentic Web: How Google I/O 2026 Accelerates the Isolated Agents SDK

The announcements at Google I/O 2026 felt less like a standard tech update and more like a paradigm shift for autonomous systems. Lately, I've been laser-focused on building the Isolated Agents SDK as an open-source personal project—a toolkit designed to enforce strict environment sandboxing, secure tool access, and zero-leak credential management for multi-agent workflows.
Google's transition from AI as an assistant to AI as an independent, securely sandboxed entity is a massive validation of the architectures I've been developing. Here is a breakdown of the tools from I/O that are entirely reshaping my development roadmap.

Gemini Omni & Antigravity 2.0

The introduction of Gemini Omni changes everything about how autonomous agents interpret their environment. By functioning as a true world model that can natively reason across video, audio, text, and simulated physics, Omni gives multi-agent systems an unprecedented grasp of real-world context without latency-heavy workarounds.
When you pair Omni's intelligence with Antigravity 2.0 and the new Antigravity CLI, you get the exact primitives needed for secure deployments. The ability to programmatically control the agent harness and spin up specialized subagents on custom infrastructure aligns perfectly with my goals. I can now deploy highly intelligent agents protected by Google's built-in cross-platform terminal sandboxing and credential masking.

Prototyping Frontends: Google AI Studio, Kotlin, and Flutter

While the Isolated Agents SDK handles the secure backend orchestration, multi-agent systems still need interfaces. The new capability to build native Android apps directly inside Google AI Studio is nothing short of revolutionary.
Going from a single prompt to a production-quality, Jetpack Compose UI written in Kotlin—complete with an in-browser emulator and direct-to-device ADB installation—completely eliminates the friction of prototyping mobile clients. It allows me to spin up a native Android interface to test an agent's real-world hardware interactions (like GPS or Bluetooth) in minutes rather than days.
Furthermore, these agentic workflow improvements are massive accelerators for cross-platform development. Whether it's using the new Migration Assistant in Android Studio or leveraging AI to untangle complex state management, optimizing my existing Flutter and Kotlin Multiplatform codebases to interact seamlessly with these new native Kotlin services has never been faster.

Secure Executions via Managed Agents

Building autonomous systems requires ensuring that tool usage and transactions happen without exposing API keys to the broader model context.
With the new Managed Agents API, this friction is significantly reduced. An agent can natively reason through a workflow and trigger external tools in an isolated, Google-hosted environment. The infrastructure setup is streamlined into a single API call, allowing the Isolated Agents SDK to focus on the orchestration layer while delegating the secure execution sandbox to Google's managed infrastructure.

Integrating the Stack

The true power of these announcements lies in how they integrate with backend development. As I build this out on my GitHub Repository , I am actively integrating the new Antigravity CLI into my Rust and Python bindings. This allows me to programmatically invoke isolated agent environments natively from the backend.
Google I/O 2026 delivered the infrastructure needed to take theoretical multi-agent systems and turn them into secure production powerhouses. The combination of Gemini Omni, the Antigravity ecosystem, AI Studio's native Kotlin generation, and managed agents provides the exact foundation needed to build the next generation of decentralized architectures.

Git-Nexus-A blazing fast multi-repository scanner for developers who juggle multiple projects

Veldrine Evelia Kaharwa — Thu, 05 Feb 2026 08:05:58 +0000

I apologize for that oversight. I did not verify the specific file structure of the repository in the previous turn. Since you have dedicated installation scripts for Windows (install.bat and install.ps1), I have updated the Installation and Try it out sections below to use them specifically.

Here is the corrected markdown:

git-nexus

*This is a submission for the GitHub Copilot CLI Challenge*

What I Built

git-nexus - A blazing fast multi-repository scanner that gives developers a god-mode view of their entire workspace. No more running git status in dozens of directories!

As a developer juggling multiple projects simultaneously, I was constantly losing track of uncommitted changes, unpushed commits, and which branch I was on in each repository. git-nexus solves this by scanning your entire workspace in milliseconds and presenting a clear, color-coded overview of every git repository.

Key Features:

🚀 Blazing Fast Scanning

Built in Rust for maximum performance
Parallel repository analysis using Rayon
Smart filtering of dependency directories (node_modules, target, etc.)
Scans 100+ repos in under 1 second

🚦 Comprehensive Status Display

Visual indicators: CLEAN/DIRTY status, branch names, ahead/behind tracking
Color-coded output for instant understanding
Stash count, modified files, and untracked files
Last commit information (hash, author, timestamp, message)
Git hooks detection (pre-commit, pre-push, etc.)

🎯 Flexible Workflows

Filter by status (clean, dirty, ahead, behind)
Sort by path, status, or branch
JSON output for scripting and automation
Configurable scan depth

🎨 Advanced Modes & Export

Interactive TUI: Beautiful terminal UI with keyboard navigation
Watch Mode: Real-time monitoring with auto-rescan
HTML Export: Styled reports with statistics dashboard
CSV Export: Data export for spreadsheets
Configuration Files: Customize behavior with .git-nexus.toml
GitHub API Ready: Framework for issues/PRs display

Demo

Basic Scan

$ git-nexus ~/projects

🔍 Scanning workspace for git repositories...

✓ 12 repositories found

📁 ./web-app (main) [CLEAN]
📁 ./api-server (develop) [DIRTY] ↑3
📁 ./mobile-app (feature/auth) [DIRTY] ↓2
📁 ./infrastructure (master) [CLEAN] ↑1
...

Verbose Mode with Details

$ git-nexus ~/projects -v

📁 ./api-server (develop) [DIRTY] ↑3 📦1 ~5 +2
   └─ a1b2c3d · John Doe · Add rate limiting middleware

📁 ./mobile-app (feature/auth) [DIRTY] ↓2 ~3
   └─ 9f8e7d6 · Jane Smith · Implement OAuth flow

Symbol Legend:

[CLEAN] 🟢 - No uncommitted changes
[DIRTY] 🔴 - Has uncommitted changes
↑N 🟡 - N commits ahead of remote
↓N 🔴 - N commits behind remote
📦N - N stashes
~N - N modified files
+N - N untracked files

JSON Output for Automation

$ git-nexus ~/projects --json -v | jq '.[0]'

{
  "path": "./api-server",
  "is_clean": false,
  "ahead": 3,
  "behind": 0,
  "branch": "develop",
  "stash_count": 1,
  "modified_count": 5,
  "untracked_count": 2,
  "last_commit": {
    "message": "Add rate limiting middleware",
    "author": "John Doe",
    "timestamp": "2026-02-05 14:30:00",
    "hash": "a1b2c3d"
  }
}

Filtering and Sorting

# Show only repositories with uncommitted changes
$ git-nexus --filter dirty

# Show only repositories ahead of remote
$ git-nexus --filter ahead

# Sort by branch name
$ git-nexus --sort branch

Advanced Features

Interactive TUI Mode:

$ git-nexus tui

Navigate with arrow keys or vim keys (j/k), beautiful color-coded display.

Watch Mode:

$ git-nexus watch

Real-time monitoring that automatically rescans when git changes are detected.

Export to HTML/CSV:

$ git-nexus export html -o report.html
$ git-nexus export csv -o data.csv

HTML includes a beautiful statistics dashboard with responsive design.

Configuration File:

$ git-nexus config  # Generate .git-nexus.toml

Customize scan depth, ignored directories, display preferences, and more.

Git Hooks Detection:

$ git-nexus --show-hooks -v

See which repositories have active git hooks (pre-commit, pre-push, etc.).

Installation

Unix/Linux/macOS

git clone https://github.com/Tech-Vexy/git-nexus.git
cd git-nexus
./install.sh
# or
make install

Windows

Ensure you have Rust installed.

Using PowerShell:

git clone https://github.com/Tech-Vexy/git-nexus.git
cd git-nexus
.\install.ps1

Using Command Prompt:

git clone https://github.com/Tech-Vexy/git-nexus.git
cd git-nexus
install.bat

Project Repository: github.com/Tech-Vexy/git-nexus

My Experience with GitHub Copilot CLI

Building git-nexus with GitHub Copilot CLI was transformative. Instead of spending hours researching APIs and writing boilerplate, I focused on describing what I wanted and Copilot CLI handled the implementation details.

What Worked Incredibly Well:

1. Iterative Feature Development
I started with "build the project" and Copilot CLI understood the existing feature requirements from the README. It implemented:

Core scanning logic with walkdir
Git status checking with git2
Color-coded terminal output
Smart directory filtering

When I said "add other features" and selected "Branch name display," it seamlessly added branch detection with proper error handling for edge cases (unborn branches, detached HEAD).

2. Comprehensive Feature Addition
The real magic happened when I requested "add all remaining useful features at once." Copilot CLI analyzed the context and added:

Parallel scanning with Rayon
Verbose mode with commit history
Stash counting
File change statistics
JSON serialization
Filtering and sorting capabilities
Complete CLI argument parsing

All of this in one go, with proper error handling and clean code structure.

3. Advanced Features Implementation
When I said "implement all advanced features" (TUI, watch mode, config, export, hooks, GitHub API), Copilot CLI:

Created a modular architecture with 7 separate modules
Implemented interactive TUI with ratatui and crossterm
Built watch mode with file system monitoring
Created configuration system with TOML parsing
Generated beautiful HTML exports with CSS styling
Added CSV export functionality
Implemented git hooks detection with Unix permission checking
Scaffolded GitHub API integration (ready for completion)

Each module was properly structured with error handling and followed Rust best practices. The dependencies were chosen intelligently (rustls instead of OpenSSL to avoid build issues).

4. Developer Experience Tooling
When I asked to "add an install script," Copilot CLI didn't just create a basic script—it created:

A robust install.sh with environment variable support
A corresponding install.bat and install.ps1 for Windows users
A comprehensive Makefile with 12+ targets
Updated documentation with cross-platform installation instructions

5. Problem Solving
When the build failed due to missing OpenSSL dependencies, Copilot CLI immediately diagnosed the issue and fixed it by disabling default features on git2 and using rustls. No manual debugging required.

When stash counting had a mutable reference error, it understood the git2 API limitations and switched to using reflog instead—a more elegant solution.

When the notify API changed, it quickly adapted to the new callback-based interface.

Impact on Development Speed:

What would have taken me 1-2 weeks of:

Reading git2-rs documentation
Learning ratatui/crossterm for TUI
Figuring out parallel processing patterns
Implementing CLI argument parsing with subcommands
Understanding file system watching APIs
Creating HTML/CSS for export features
Writing installation scripts (Bash, Batch, PowerShell)
Setting up build automation
Debugging dependency conflicts (OpenSSL)
Writing comprehensive documentation

...was completed in ~3 hours with Copilot CLI. The code quality is production-ready, with proper error handling, modular architecture, and comprehensive documentation.

Key Takeaways:

Natural Language to Code: Describing features in plain English ("show branch names", "add all advanced features") resulted in production-quality implementations with proper architecture
Context Awareness: Copilot CLI understood the project structure, made consistent architectural decisions, and created a modular design with 7 separate modules
Best Practices by Default: Generated code followed Rust idioms, used appropriate crates (rustls over OpenSSL), handled errors properly, and included comprehensive error messages
Iterative Refinement: When issues arose (API changes, build failures), describing the problem led to immediate, elegant fixes
Complete Solutions: Didn't just write code—created cross-platform install scripts, documentation, Makefiles, configuration systems, contribution guides, and export templates
Intelligent Dependencies: Chose modern, well-maintained crates and handled version conflicts intelligently

The "Copilot Effect":

Traditional development: Think → Research → Write → Debug → Document → Repeat

With Copilot CLI: Think → Describe → Verify → Ship

This isn't just faster—it's fundamentally different. I stayed in "product mode" focusing on what to build, while Copilot CLI handled how to build it. The result is a production-ready application with advanced features that would typically require weeks of development.

Technical Stack

Language: Rust 🦀
Core Dependencies:
clap - CLI argument parsing with subcommands
colored - Terminal colors
git2 - Git operations
walkdir - Directory traversal
rayon - Parallel processing
serde/serde_json - JSON serialization
chrono - Date/time handling
Advanced Features:
ratatui + crossterm - Terminal UI framework
notify - File system watching
csv - CSV export
toml - Configuration file parsing
reqwest - HTTP client (for GitHub API)
anyhow - Error handling

Total: 15 production dependencies, ~3,500 lines of code, 7 modules

Implemented Features

[x] ✅ Configuration file support (.git-nexus.toml)
[x] ✅ Interactive TUI mode
[x] ✅ Git hooks detection
[x] ✅ GitHub/GitLab API integration (framework ready)
[x] ✅ Watch mode for continuous monitoring
[x] ✅ HTML/CSV export
[x] ✅ Parallel scanning
[x] ✅ Branch display
[x] ✅ Verbose mode with commit info
[x] ✅ JSON output
[x] ✅ Filtering and sorting
[x] ✅ Cross-platform Installation scripts (Bash/PowerShell/Batch)
[x] ✅ Comprehensive documentation

Future Enhancements

[ ] Complete GitHub API integration (display issues/PRs count)
[ ] GitLab API support
[ ] Plugin system for custom analyzers
[ ] Remote repository support
[ ] Team dashboards
[ ] More export formats (Markdown, PDF)

Try it out:


## Unix/Linux/macOS

git clone https://www.google.com/url?sa=E&source=gmail&q=https://github.com/Tech-Vexy/git-nexus.git && cd git-nexus && ./install.sh

## Windows (PowerShell)

git clone https://www.google.com/url?sa=E&source=gmail&q=https://github.com/Tech-Vexy/git-nexus.git; cd git-nexus; .\install.ps1

Quick Commands:

git-nexus             # Basic scan
git-nexus -v          # Verbose with details
git-nexus tui         # Interactive mode
git-nexus watch       # Monitor changes
git-nexus config      # Generate config file

Built entirely with GitHub Copilot CLI in ~3 hours! 🚀

From idea to production-ready tool with 20+ features, modular architecture, comprehensive documentation, and advanced capabilities—all through natural language commands to Copilot CLI.

My Dream Intranet Home Page Inspired by Axero

Veldrine Evelia Kaharwa — Sat, 19 Jul 2025 21:45:49 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, Holistic Webdev: Office Space

What I Built

I built "Axero Intranet Hub" - a modern, responsive intranet portal designed to enhance workplace collaboration and productivity. This application serves as a centralized dashboard for employees, providing real-time updates, team information, and essential workplace tools with secure authentication and role-based access control.

The intranet hub features:

User Authentication System with role-based access control and admin capabilities
Interactive Dashboard with real-time metrics and announcements
Team Spotlights to recognize employee achievements with detailed profiles
Calendar System with event management capabilities
Employee Directory with detailed contact information and interactive profiles
Device Management System for tracking company equipment
Communication Hub with real-time chat functionality
Weather Widget using OpenWeatherMap API and geolocation for real-time local conditions
Activity Feed showing recent company activities
Enhanced Search with clickable results across all content types
Resource Portal with HR, IT, Knowledge Base, and Cafeteria sections
Dark/Light Mode Toggle for user preference
Keyboard Shortcuts for improved productivity
Admin Panel for system management and user administration

The application uses IndexedDB for client-side data persistence, allowing users to add events, manage devices, and send messages that persist between sessions. Authentication data is securely stored using Web Storage API with session expiration.

Demo

GitHub Repository Link

axero-intranet-hub.veldrineevelia.software

Journey

Developing the Axero Intranet Hub was both challenging and rewarding. Here's a glimpse into my process:

Design Philosophy

I wanted to create an intranet that feels modern and intuitive while providing genuine utility. I focused on:

User Experience: Clean layout with intuitive navigation and smooth animations
Functionality: Real working features rather than just visual mockups
Responsiveness: Adapts seamlessly to different screen sizes
Accessibility: Keyboard navigation, proper contrast, and semantic HTML

Technical Implementation

The application is built using vanilla JavaScript, HTML, and CSS without external frameworks or libraries. This approach challenged me to implement features from scratch while maintaining clean, efficient code.

Key technical achievements include:

Authentication System: Implemented secure login with role-based access control
Client-side Database: Utilized IndexedDB for persistent data storage
Component Architecture: Created modular, reusable UI components
Real-time Updates: Simulated real-time data changes with timed intervals
Theme System: Built a comprehensive dark/light mode with smooth transitions
External API Integration: Connected to OpenWeatherMap API for real-time weather data
Geolocation Services: Used browser's Geolocation API for location-aware features
Interactive Search: Implemented cross-application search with clickable results

Challenges Overcome

The project presented several challenges that I successfully addressed:

Authentication Without Backend: Implemented secure client-side authentication with token expiration and role-based permissions
Data Management: Created a structured IndexedDB schema with multiple object stores and CRUD operations
API Integration: Handled API requests with proper error handling and fallbacks for offline operation
User Experience: Designed intuitive interfaces for complex features like device management and calendar systems
Performance Optimization: Ensured smooth animations and transitions even with real-time data updates

What I Learned

This project deepened my understanding of:

Modern CSS techniques (CSS variables, grid layouts, animations)
Client-side database management with IndexedDB
JavaScript promises and async/await patterns
Authentication and authorization principles
External API integration and error handling
Geolocation and browser APIs
Accessibility considerations for enterprise applications

I'm particularly proud of the comprehensive authentication system with role-based access control, the interactive search functionality, and the real-time weather widget with geolocation support.

License

This project is licensed under the MIT License - see the LICENSE file for details.

I JUST BUILT AN IN-BROWSER GAME USING AMAZON Q

Veldrine Evelia Kaharwa — Sun, 11 May 2025 09:27:09 +0000

This is a submission for the Amazon Q Developer "Quack The Code" Challenge: Exploring the Possibilities

What I Built

I decided to test the capabilities of Amazon Q by building a web game. The name of the game is FPS Game and I asked Amazon Q to build it using JavaScript and WebAssembly. Here is the prompt I used to start the project:

create a a high-performance, web-based first-person 3D shooter game that leverages WebAssembly (WASM) for computationally intensive tasks and integrates AI-driven features to enhance gameplay. The game should be lightweight, engaging, and playable in modern web browsers (Chrome, Firefox, Edge, Safari) using WebGL for rendering, WebAssembly for performance-critical logic, and AI to create intelligent enemies, adaptive environments, and personalized gameplay. The game will use Three.js for 3D rendering, WebAssembly (written in C++ or Rust) for physics, collision detection, and core AI computations, and JavaScript for game loop management and lighter AI logic.

Screenshots

Home Page

Game Screen

About the project

fps-game web-based first-person shooter (FPS) game built with WebAssembly and JavaScript. The project combines modern web technologies with game development techniques to create an immersive 3D shooter experience that runs directly in the browser.

Core Features

WebAssembly Integration: Uses Rust compiled to WebAssembly for performance-critical operations like physics, AI, and calculations
3D Rendering: Built with Three.js for high-quality 3D graphics
Mission System: Comprehensive mission framework with different objective types, tracking, and rewards
Advanced Visual Effects: Includes post-processing, PBR materials, and environment mapping
UI System: HUD elements, mission tracking, and interactive menus

Technical Architecture

Rendering & Graphics

Three.js-based 3D engine with custom post-processing effects
PBR materials with features like subsurface scattering and normal mapping
HD environment maps for realistic reflections and lighting
Particle systems for visual effects

Gameplay Systems

Mission System: Tracks different mission types (kill enemies, collect items, reach areas, defeat bosses)
Weapon System: Manages different weapon types, projectiles, and damage models
Enemy AI: Behavior trees implemented in WebAssembly for performance
Player progression: Rank system with score tracking and rewards
HUD components showing health, ammo, and objectives
Mission UI with mission tracking, acceptance, and rewards
Objective markers for navigation assistance
Notification system for game events

Project Structure

The codebase is organized into logical modules:

/core: Core game engine and systems
/graphics: Rendering and visual effects
/level: Level management and environment
/missions: Mission creation and tracking system
/multiplayer: Networking and multiplayer functionality
/systems: Game systems like weapons and AI
/ui: User interface components

Development & Deployment

The game was built using:

Amazon Q agentic coding
Node.js for JavaScript bundling
Rust with wasm-pack for WebAssembly compilation
npm scripts for build automation

This project demonstrates the capabilities of Amazon Q in large codebases and code generation.

Demo

Explore the fps-game demo here

Code Repository

The full code repository for this project can be found here

How I Used Amazon Q Developer

I used Amazon Q to build the project from start to finish. Amazon Q scaffolded the project one step at a time and was able to fix any errors as soon as they appeared.

FileShare| A FileSharing Platform built using Next.js and Pinata Files API

Veldrine Evelia Kaharwa — Sun, 13 Oct 2024 13:38:05 +0000

This is a submission for the The Pinata Challenge

What I Built

I built a simple file sharing application that allows users to upload new files and even download those uploaded by other users.

Technologies Used

Demo

Checkout this demo of the App

Screenshots

My Code

The Project code can be found here

More Details

Pinata's API is used to upload user-selected files to the IPFS network.

The uploadToPinata function in the app communicates with Pinata's API to upload the file. Once uploaded, Pinata provides a unique IPFS hash (CID - Content Identifier), which acts as a decentralized address for the file.

This hash (or CID) is used to uniquely identify the uploaded file across the IPFS network and allows anyone to access the file via any IPFS gateway (e.g., Pinata’s gateway, Cloudflare IPFS gateway, etc.).
fter a file is uploaded, users and others can view and download the file. The app uses the IPFS hash generated by Pinata to retrieve the file via the IPFS network.

By utilizing Pinata’s public IPFS gateway (https://gateway.pinata.cloud/ipfs/), the app provides a download link to the user to access the file directly.
Pinata enables decentralized storage, ensuring that files are not reliant on a single centralized server. This provides resilience, censorship resistance, and security benefits, as files are distributed across multiple nodes on the IPFS network.
The app takes advantage of these benefits by ensuring that the uploaded files are accessible via IPFS through any IPFS gateway, without depending on a centralized provider.

Author

This Project was created by Tech-Vexy
On Dev as tech-vexy

What You Need to Know about Web Game Development

Veldrine Evelia Kaharwa — Tue, 24 Sep 2024 09:45:54 +0000

This is a submission for the Web Game Challenge: One Byte Explainer

Explainer

The canvas is a html element that allows drawing graphics and animations in a browser using the CanvasApi for a 2D context or the WebGLApi for a 3D context.
Choosing a game engine for your game generally depends on the type of game you want to build. For a 3D game you might use the ThreeJS library for graphics and choose a suitable physics engine like ImpactJs. For 2D games you might use a 2D game engine like Box2D to build your game.
Almost every game you build must have a game loop to control what happens during gameplay. The game loop is a sequence of processes that run continuously as long as the game is running. The three main processes that occur in the game loop are input, update, and render.

Additional Context

When Building web games, at times the programming language used to implement game logic matters. Some languages are easier to use and so are the engines implemented in those languages. Currently, Web assembly allows browser games to run faster.

By Veldrine Evelia Kaharwa
@Tech-Vexy on Github