Forem: gt12889

How We Built Roly Poly at NexHacks Using DevSwarm and Parallel AI

gt12889 — Thu, 22 Jan 2026 17:48:07 +0000

For our Nexhacks project we wanted to explore a problem within predictions markets.

We started with a pretty simple frustration: prediction markets are powerful, but they’re hard to reason about unless you already think in probabilities. Most interfaces show a final price and expect users to translate/calculate this price into a risk, confidence, and position sizing. That gap is where people get confused.

Users will make bets based on gut decisions but do you know:

Your expected value if you're 80% confident?
The Kelly-optimal position size?
Your 95% Value at Risk?
Whether the risk-reward ratio favors you?

Our original goal was modest. Build something that helps people understand how a prediction market position behaves as probabilities and time change, using real Polymarket data. With our risk decision structure, we will provide a clear +EV, -EV or no edge for the simulated bet.

The Problem We Didn’t Expect

It was 4AM. We were integrating multiple sponsor tools at once: Polymarket data, numeric reasoning, explanations, evaluation, observability. Each one worked fine on its own, but stitching them together espeically with the hackaton time pressure and no sleep after my flght.

Every change required touching multiple pieces. Debugging meant guessing where things went wrong. And as the system grew, we realized the biggest risk wasn’t performance or features it was coordination. The answer here wasnt just 'more instances" or AI tokens

That’s when we stopped treating DevSwarm like “an AI coding tool” and started using it as the backbone of how we worked.

Reframing the System

Instead of thinking in terms of endpoints and API calls, we asked a different question:

“What if analysis itself was a pipeline of specialists?”

So we broke our /explain flow into clear stages, each with a single responsibility, and let DevSwarm handle the orchestration between them.

At runtime, a user interaction kicks off a sequence that looks like this:

One agent focuses purely on numeric reasoning (expected value, Kelly sizing, risk metrics)
One agent focuses on compressing context so we stay efficient
One agent turns that structured data into a clear explanation
One agent evaluates the result for consistency and quality

Each stage runs independently, hands off structured output, and reports its timing and status.

DevSwarm Runtime Agent Pipeline

Context Builder (Wood Wide AI, ~50ms)
↓
Compressor (Token Company, ~25ms)
↓
Tutor (LLM, ~150ms)
↓
Evaluator (Arize Phoenix, ~15ms)

Each stage runs independently and reports timing and status in real time.

How it all fits together

With DevSwarm, we built infrastructure.

The agent pipeline isn't just for show—it's how we:

Debugged sponsor integrations in real-time
Measured each sponsor's contribution
Showed users exactly how their analysis was computed

On top of our team, It was 6 DevSwarm builder agents working in parallel, each with:

Dedicated git branch (git-native isolation)
Specialized prompt (500+ lines of context per agent)
Clear ownership of files and responsibilities
Conventional commit prefixes for merge coordination

We split development into parallel DevSwarm builders, each working on a dedicated branch with clear ownership:

one focused on backend data and Polymarket integration,
one on numeric reasoning,
one on evaluation and observability,
one on UI polish,
and one whose only job was keeping the demo stable.

This sounds obvious in hindsight, but it completely changed our pace. We stopped stepping on each other’s work. Merges became predictable. The main branch stayed demo-ready, which is critical in a hackathon.

Our judge agent is scanning for defects and issues against the scoring criteria

Older judge verdicts, which we used for continuous integration

Conditional "GO" state, after clearing major issues and reaching a high score on the product and technical judge

What We Ended Up Shipping

By the end of the 24 hours, we had something that felt surprisingly cohesive:

A 3D visualization that shows how risk and payoff evolve as probabilities and time change
A numeric engine that computes EV, Kelly sizing, Sharpe-style metrics, and VaR
Live Polymarket data flowing through the system
An automated evaluation loop using Arize Phoenix that let us measure and improve explanation quality instead of guessing

None of this felt rushed, even though the clock was always ticking. DevSwarm absorbed most of the coordination overhead that usually slows teams down.

Agent	Sponsor	Function	Timing
`context_builder`	Wood Wide AI	Compute Kelly, Sharpe, VaR, EV, and break-even metrics	~50ms
`compressor`	The Token Company	Reduce context size by 40%+ and track estimated cost savings	~25ms
`tutor`	LLM	Generate a structured 3-part explanation from compressed context	~150ms
`evaluator`	Arize Phoenix	Score explanation against numeric ground truth and consistency checks	~15ms

The Biggest Takeaway

The most valuable insight wasn’t about speed or AI.

Parallel execution where possible
Structured handoffs between agents
Git-native versioning of agent configurations
Real-time visibility into each agent's contribution

When users can see how an answer is produced not just the answer itself they engage differently. They experiment more. They ask better questions. They actually learn.

For us, DevSwarm changed how we thought about structuring intelligence, both at runtime and during development.

Looking Back

We placed 3rd Overall at NexHacks, which was an awesome outcome, especially since this was only my second hackathon. But the bigger win was realizing there’s a better way to build AI-heavy products under pressure and playing with all the different new integrations.

This is not by hiding complexity, but by organizing it. Once we experienced that, it became hard to imagine going back to the old way.

Check out the result here!

🌑 Into the Dark: Soulbound Codex

gt12889 — Fri, 05 Dec 2025 19:40:09 +0000

🪄 Demo
https://youtu.be/hY6U_CnSAtg
https://portfolio-13181.web.app/

👻 Background

Kiroween is a Halloween-themed hackathon hosted by AWS to showcase the capabilities of Kiro, their AI coding agent. The challenge:
Build something ambitious, creative, and technically unique in under a month.

For me, this project meant stepping into the unknown combining gothic aesthetics, multi-module architecture, AI-powered workflows, and agent orchestration into a single cohesive product.

What emerged from that darkness was Soulbound Codex: a fully featured, atmospheric productivity suite transformed into a spooky, immersive experience.

🪄 Soulbound Codex

A dark, ritual-themed productivity platform with four major modules:

✍️ Ghost Writer

Live AI writing suggestions using multi-agent reasoning + cursed typewriter animations.

📖 Necronomicon Notes

An ancient tome for note-taking with markdown, live preview, full search, and animated parchment effects.

⚰️ Graveyard Dashboard

Tasks appear as tombstones with physics, moonlit shadows, digging animations, particle effects, and Pomodoro tracking.

🔮 Terminal Tarot

Analyzes GitHub commit history and generates tarot-style readings about coding habits, patterns, and project quality.

Plus:
🌕 Moon phase calendar
🕸️ Ambient soundscapes
🧩 Offline-first architecture
🛠️ Cloud sync (Firebase)
🔐 OAuth (GitHub/Google)

This isn’t just a themed UI — it’s a complete productivity platform.

🧠 Technical Achievements
Architecture & Engineering
Multi-module React architecture (React 19 + TS 5.9)
Offline-first design with dual-layer storage
Git analysis in the browser with isomorphic-git
Real-time cloud sync with Firebase
Multi-agent AI orchestration (Nemotron 70B, Gemini, OpenAI)
Intelligent fallback + caching layer for AI reliability
Theme engine with instant switching
Import/export (JSON, Markdown, CSV)
Accessibility overlays for the full suite
UI & Interaction Design
Parchment rendering system
Physics-based task animations
Gothic fonts, particles, ritual effects
Keyboard navigation across modules

⚡ How Kiro Helped (MCP + new Kiro features)

Kiro wasn’t just a tool it was a development partner.
I used nearly every part of the MCP workflow:

🧾 Spec-Driven Development

Every feature began as a .kiro/spec file (see screenshot):
routing-system
multi-age-coordination
necronomicon-enhancements
ghost-writer-ux
spirit-companion-interactions
theme-system
terminal-tarot-improvements
astral-projection

Kiro converted these specs into modular, production-quality code with no ambiguity.
🎚 Steering Files
Under .kiro/steering:
product/ — UX philosophy
structure/ — file org & patterns
tech/ — conventions & architecture
These enforced consistency across the entire app.

🪝 Agent Hooks
Hooks automated complex workflows:
Auto Test Coverage Generator
Localization Translator
Code Quality Analyzer
Context Provider Check
Docs Sync

This automation dramatically reduced manual cleanup time.

🆕 New Kiro Features that were game-changing
✔ Property-based testing

Validated that generated code matched the intent of the spec.
✔ Checkpoints
Let me roll back Kiro-generated changes instantly — a lifesaver for large refactors.
✔ Kiro CLI
Allowed me to run custom agents inside my terminal during development.
✔ Team-Ready Architecture
Centralized spec & steering management meant that this workflow scales to real teams.
Kiroween without Kiro would have taken months, not weeks.

🧩 Challenges I Faced

⏳ Time pressure — balancing a huge multi-module system with limited daily time
🕯 Heavy theming — animations, parchment textures, moon phases needed fine tuning
🤖 AI differences — Nemotron, Gemini, OpenAI all behave differently
🗃 Browser Git analysis — implementing commit parsing client-side was tough

🗓️ Condensed Timeline

Day 1–3 — “I Have No Idea What I’m Summoning, but Let’s Do It.”

I opened a blank repo, lit a metaphorical candle, and told Kiro, “We’re building a productivity suite possessed by ancient spirits.”
Kiro replied with a 27 file project structure in 4 seconds. I panicked, then pretended that was exactly what I wanted.

These first days gave birth to:
The core React architecture
The theme engine
The first cursed prototype of the Graveyard Dashboard
A Notes module that looked like Notion, if Notion had been abandoned in a haunted library
I also learned the ancient truth: a developer’s first three days are 20 percent coding, 80 percent questioning their life choices.

Day 4–6 — “Ghosts, Why Are You Falling Through the Floor?”

Moon phase calendar (astronomically accurate, emotionally chaotic)
Markdown editor
Graveyard physics where tombstones sometimes yeeted themselves off screen for no reason
I spent 2 hours debugging a particle effect that turned the screen into a snowstorm.
Kiro very politely suggested I reduce the spawn rate from 600 particles per second to “something less apocalyptic.”

Day 7–10 — “This Is No Longer a Project. It’s a Pact.”
This phase turned into a full-blown magical ritual.

Accomplishments:
The Git commit divination engine built with isomorphic-git
Tarot generation logic that felt uncomfortably accurate
AI fallback systems across Nemotron, Gemini, Hugging Face, and OpenRouter
Cloud sync that behaved half like Firestore, half like a ghost that rattles chains after midnight

Day 11–14 — “Polish, Panic, Polish Again.”
This period was a montage of frantic coffee-fueled creativity.
New polish included:
Particle effects that no longer triggered GPU meltdown
Keyboard shortcuts that made the app feel like a spellbook you can speedrun
Import/export that mostly doesn’t corrupt your soul— or your JSON
Accessibility improvements because even ghosts deserve semantic HTML
Final UI cleanup where I deleted a div and broke the layout for two hours

At 3AM I added ambient audio and accidentally made the typing sound like “footsteps in your house.”

🎯 What I Learned
✨ Kiro-Related Learnings

Offline-first design pairs perfectly with spec-driven dev

Service layers make AI integrations testable and swappable

Kiro works best when specs + steering rules are extremely clear

Documentation generated through Kiro becomes self-sustaining

Checkpoints and hooks accelerate iteration dramatically

✨ Technical Learnings

Clear specs beat guesswork
Browser Git analysis is powerful but complex
Aesthetics influence user motivation
Ritual interactions create emotional engagement
AI-assisted development is a new and much faster paradigm
✨ AWS SageMaker Lessons

I experimented with Amazon SageMaker for fine-tuning historical figure personality models. While powerful, I learned quickly:

❌ Avoid (Too Expensive for Students):

Real-time endpoints: ~$193/month even when idle
Always-on services quietly accumulate costs
Large GPU instances = impractical without credits

This pushed me toward a hybrid approach using:
Hugging Face + Gemini + local orchestration — far more cost-effective for hackathon use.

🏆 Final Thoughts

Building Soulbound Codex felt like walking through a haunted forest with Kiro carrying the lantern. Each step forward revealed more of the path — sometimes eerie, always exciting.

This hackathon taught me:
how to build complex software fast with AI
how design can shape emotion
how to plan, structure, and ship under pressure
how AI agents can meaningfully extend developer ability

Soulbound Codex is an experience.

And it all came together because of Kiro!!!