DEV Community: Lewis Sawe

Building a Project Risk Engine on Top of Notion MCP

Lewis Sawe — Sun, 29 Mar 2026 22:21:31 +0000

This is a submission for the Notion MCP Challenge

What I Built

Risk Radar reads your Notion project databases, builds a dependency graph in memory, and writes risk reports back to Notion. It finds critical paths, single points of failure, and cascade risks that project managers usually track in their heads (or don't track at all).

The part I'm most proud of: when a task is overdue, the agent walks the dependency graph and pushes every downstream deadline forward through notion-update-page. Mark one task late, run the scan, and watch 8 dates shift in Notion automatically.

Everything goes through Notion's MCP server. No direct API calls. Notion is the entire data layer.

Video Demo

Show us the code

lewisawe / risk-radar

🎯 Risk Radar — Dependency & Risk Intelligence for Notion

Built for the Notion MCP Hackathon — zero direct API calls, 100% MCP.

The Problem

Project managers track risks mentally but never systematically. When a task slips, nobody knows which 8 downstream tasks just broke their deadlines. Single points of failure hide in plain sight — one person quietly blocking an entire workstream. By the time anyone notices, the cascade has already happened.

The Solution

Risk Radar reads your Notion project databases, builds a dependency graph, and surfaces risks that humans miss. It writes actionable risk reports back to Notion and automatically propagates deadline changes through the dependency chain.

Mark one task late → watch 8 downstream dates shift automatically.

Everything runs through the Model Context Protocol (MCP) — zero direct Notion API calls.

How It Works

Read — Fetches all projects and tasks from Notion via MCP, including dependency…

View on GitHub

How I Used Notion MCP

Reading a dependency graph through MCP

The Tasks database has a self-referencing "Depends On" relation. Reading this through MCP takes three steps per task: fetch the database to get the data source URL, search to get page IDs, then fetch each page individually to get its properties.

The properties come back inside a <properties> XML block as JSON. Relation fields like "Depends On" and "Project" are arrays of Notion page URLs. So building the graph means parsing URLs like https://www.notion.so/abc123def456, stripping the prefix and dashes, and using the normalized ID as the graph node key. Without that normalization step, every dependency lookup fails silently and you get an empty graph. That bug cost me an hour.

The graph algorithms

Once the tasks are in memory with their dependencies resolved to names, the risk engine runs four analyses:

Critical path uses DFS with memoization from root tasks (tasks with no upstream dependencies). It finds the longest chain through the dependency graph. This tells you which sequence of tasks has zero slack — if any of them slip, the project end date moves.

Single point of failure detection does a recursive downstream traversal per task owner. If one person's incomplete tasks collectively block two or more downstream tasks, they're flagged. This catches the scenario where one engineer is quietly blocking an entire workstream.

At-risk detection is simpler: compare each task's deadline to today. Overdue tasks, tasks due within 3 days that haven't started, and tasks due tomorrow that are still in progress all get flagged.

Cascade impact runs BFS from each at-risk task to enumerate every downstream task that would be affected by a slip.

The risk score combines these: overdue_ratio × 40 + spof_penalty (capped at 30) + cascade_penalty (capped at 30). It's a rough heuristic, but it produces scores that feel right. A project with one overdue task and no dependencies scores low. A project with an overdue task that blocks 5 others through a single owner scores high.

Writing reports and cascading deadlines

The risk report is a Markdown page created with notion-create-pages. It includes the risk score with an emoji indicator (🔴/🟡/🟢), the critical path, at-risk tasks with reasons, SPOFs with the tasks they're blocking, and cascade impact chains. A separate Health History entry logs the score with a date for trend tracking.

The cascade feature is the most interesting MCP interaction. When the scan finds an overdue task, it calculates the slip in days, then does a BFS through the dependency graph. For each downstream task that isn't done, it calls notion-update-page with the new deadline using the "date:Deadline:start" property format. A 5-task cascade means 5 sequential MCP update calls. Each one shifts a real deadline in Notion.

What surprised me about Notion MCP

The notion-search results don't include full properties. You get page IDs and titles, but to read "Depends On" or "Deadline" you need a separate notion-fetch per page. For 8 tasks across 3 projects, that's about 25 MCP calls just to read the data. It works, but it means the agent is I/O bound rather than compute bound. The graph algorithms themselves run in microseconds. The MCP calls take seconds.

The other surprise was date properties. Setting a date requires two properties: "date:Deadline:start" for the value and "date:Deadline:is_datetime": 0 to indicate it's a date-only field. Missing the second one doesn't error, but the date renders differently in Notion.

I Built an Agent That Assembles Incident War Rooms in Notion Through MCP

Lewis Sawe — Sun, 29 Mar 2026 21:48:42 +0000

This is a submission for the Notion MCP Challenge

What I Built

Incident Runbook is an agent that turns Notion into a living incident response system. It watches an Incidents database, and when a new SEV1 or SEV2 appears, it cross-references three other databases (Services, Runbooks, On-Call), assembles a War Room page with everything the responder needs, and writes it back to Notion. When the incident is marked resolved, it generates an AI post-mortem with Gemini 2.5 Flash.

The whole thing runs through Notion's MCP server. No REST calls, no webhooks, no middleware layer.

I built this because incident response at most companies is still a manual scramble. The runbook exists somewhere, the on-call schedule is in a different tool, and the service dependency map is in someone's head. This agent pulls all of that together in seconds.

Video Demo

Show us the code

lewisawe / incident-runbook

🚨 Incident Runbook — AI-Powered Incident Response for Notion

Built for the Notion MCP Hackathon — zero direct API calls, 100% MCP.

The Problem

When a SEV1 hits at 2am, engineers scramble: "Where's the runbook? Who's on-call? What depends on this service?" They're copy-pasting from scattered docs, pinging Slack, and losing precious minutes. Incident response shouldn't require tribal knowledge — it should be automated.

The Solution

Incident Runbook turns your Notion workspace into a living incident response system. Log an incident → a full war room assembles itself in seconds.

It connects to Notion entirely through the Model Context Protocol (MCP) — reading databases, assembling pages, and writing post-mortems without a single direct API call.

How It Works

Detect — Scans your Incidents database for new SEV1/SEV2/SEV3 entries
Lookup — Finds the affected service, pulls its runbook, maps dependencies
Assemble — Creates a War Room page with
- Incident details and…

View on GitHub

How I Used Notion MCP

The four-database pattern

The agent coordinates across four Notion databases in a single scan: Incidents, Services, Runbooks, and On-Call. Each scan starts with notion-search on the Incidents database to find new or resolved entries. For each incident, it follows the "Affected Service" relation to the Services database, then follows the "Runbook" relation from that service to the Runbooks database, and pulls contacts from the On-Call database filtered by role.

This means a single incident triggers reads across all four databases. The MCP call pattern looks like:

notion-fetch on the database ID to get the collection:// data source URL
notion-search with that URL to get page IDs
notion-fetch on each page to get properties and content

For a scan with 1 incident, 3 services, 2 runbooks, and 4 on-call contacts, that's roughly 20 MCP calls. Chatty, but each call is fast and the total scan takes a few seconds.

Relation resolution was the trickiest part

Notion MCP returns relation properties as arrays of page URLs, not IDs. So an incident's "Affected Service" looks like ["https://www.notion.so/abc123def456"] rather than a clean ID. Matching that to the actual service record means parsing the URL, stripping dashes, and normalizing to a consistent format across all four databases.

I spent more time debugging ID mismatches than writing the actual war room assembly. Services fetched from the database had IDs in one format, while the relation URLs from incidents had them in another. The fix was normalizing everything to dashless hex strings on read.

Writing Markdown back to Notion

The war room page is a single Markdown string that Notion renders natively. It includes a details table, on-call contacts list, the full runbook steps, dependent services, a timeline, and an action checklist with checkboxes. Creating it is one notion-create-pages call with the incident page as the parent.

The post-mortem works the same way. The agent calculates MTTR from the incident creation time to resolution, feeds the incident details and timeline to Gemini 2.5 Flash, and writes the AI output into a new page.

Watch mode and connection reuse

The agent has a watch mode that polls every 30 seconds. An early version spawned a new mcp-remote process on every poll cycle, which ate system resources fast. The fix was extracting the scan logic into a function that accepts an existing MCP client, so watch creates one connection and reuses it across all cycles.

What I'd do differently

The property parsing is fragile. Properties come back inside a <properties> XML block as JSON, and the key names are case-sensitive and sometimes inconsistent (I found both "status" and "Status" depending on how the database was configured). A more robust version would normalize property keys on read. But for a hackathon, regex and case-checking got the job done

Solving Halloween with Google Gemini and Iterative Image Generation

Lewis Sawe — Wed, 04 Mar 2026 11:25:41 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built an AI Halloween Costume Generator because picking a costume is harder than it should be. You either spend hours scrolling through the same generic ideas online, or you have a vague concept but no clue how to actually make it. I wanted something that could take any input a text idea, a photo, or literally nothing and turn it into a complete DIY guide with materials, steps, and visuals.

The app works three ways. You can search for costume ideas by typing anything ("costumes for my dog," "spooky sci-fi"), and it gives you five different concepts to pick from. You can upload a photo of an object, person, or pet, and it generates a costume based on that image. Or if you're completely stuck, there's a "Surprise Me" button that creates something random.

Once you pick an idea, you get a full breakdown with materials, estimated cost, difficulty level, and step-by-step instructions. The interesting part is the visuals. Instead of generic stock photos or disconnected diagrams, each instruction step has an image that builds on the previous one. You literally watch the costume come together piece by piece.

I used three different Gemini models for this. gemini-2.5-flash handles all the text generation and structured data costume names, descriptions, materials lists, instructions. I defined a JSON schema so the output is always consistent and easy to work with. imagen-4.0-generate-001 creates the first image for each costume guide. Then gemini-2.5-flash-image-preview does something cool it takes the previous step's image and adds the new elements described in the current step. So instead of generating five separate images, it's building one image progressively.

That additive image generation was the hardest part to get right. The model needs to understand what's already in the image, what the text is asking it to add, and how to blend them naturally. It took experimentation to figure out the right prompts and image parameters, but when it works, it makes the instructions way easier to follow than text alone.

Demo

What I Learned

I learned that multimodal doesn't just mean "uses images and text." It's about how those modes interact. The additive image feature only works because the model can see the previous image and understand the text instruction at the same time. That's different from just generating images from text prompts.

Structured outputs made this project manageable. Without the JSON schema, I'd be parsing freeform text and dealing with inconsistent formats. With it, I know exactly what I'm getting back every time, which makes building a UI straightforward.

The search feature taught me something about prompt design. Asking for "five costume ideas" in one call is way more efficient than making five separate calls, and the results are actually more diverse because the model can differentiate them in context.

Google Gemini Feedback

The image editing model (gemini-2.5-flash-image-preview) was the star here. Being able to iteratively build on an image is powerful and not something I've seen done well elsewhere. It worked better than I expected for this use case.

Structured outputs continue to be essential. They're the difference between a prototype and something you can actually ship.

The friction came from tuning the image generation. Sometimes the additive steps would drift from the original concept, or the model would reinterpret elements instead of just adding to them. I had to be specific in the prompts about what to preserve and what to add. It wasn't a model limitation as much as figuring out how to communicate clearly with it.

One thing I'd like is better control over image composition in the editing model. Being able to specify regions or layers would make the additive process more predictable. But overall, the multimodal capabilities let me build something I couldn't have built otherwise.

Qwani Connect, the Nairobi's Young Creatives Community Hub

Lewis Sawe — Sun, 01 Mar 2026 23:55:11 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Qwani is a youth-led creative community based in Nairobi, Kenya. What started as a platform for young writers to get published has grown into a home for artists, musicians, film-makers, illustrators, poets, and anyone who creates.

Every month, Qwani hosts events that bring people together in ways that are hard to find anywhere else in the city:

Hikes "positive suffering," as the community calls it. Last Saturday of every month.
Sketch Tours along Nairobi, walk, learn the history of iconic buildings like Kipande House and McMillan Library, and sketch the city around you.
Poetry & Letter Reading Sessions at the American Corner on Moi Avenue, submit a poem or an unconventional letter, and the group reads and openly critiques it together.
Trivia Nights — board games, Kahoot, and team quizzes. Think you know all 55 African capitals?

Open Mics — poets, musicians, and spoken-word artists get a stage.
Karaoke & Crafts — sing Sauti Sol with your friends while others learn bead-making and crochet.
Picnics at the Arboretum, Cycling Tours through Karura Forest, and Book Discussions with author panels.

I'm part of this community, and I built Qwani Connect for them.

What I Built

Qwani Connect is a community platform that solves three real problems I noticed:

1. Event Discovery & RSVP

Qwani's events are currently scattered across Instagram stories, WhatsApp groups, and word of mouth. Qwani Connect puts every event in one place with RSVP functionality and a real-time "Who's Going" feature, you can see avatar initials of people who've RSVP'd, creating social proof and FOMO before you even commit.

2. The Wall — A Live Poetry & Writing Feed

Currently, members submit poems and letters via email before reading sessions. Qwani Connect replaces that with The Wall a live masonry-layout feed where submitted poems, letters, and stories appear instantly for the whole community to read and heart.

The Wall uses Supabase Realtime — when someone submits a new piece, it appears for everyone without a page refresh. The feed is multilingual, just like the community English, Swahili, and Sheng all live side by side.

3. The Suffering Streak

Qwani's monthly hikes are legendary. The community bonds through what they call "positive suffering." I turned this inside joke into a feature: The Suffering Streak tracks your consecutive monthly hike attendance with a leaderboard.

Miss a month? Your streak resets. The fire emojis scale with your commitment — 🔥 for beginners, 🔥🔥 for regulars, 🔥🔥🔥 for the truly committed. It's gamification that only makes sense if you know this community, and that's exactly the point.

Demo

Check out the Live Demo

Code

[GitHub Repo for Qwani Connect]{https://github.com/lewisawe/qwani-connect}

How I Built It

Tech Stack

Layer	Choice	Why
Framework	Next.js 16 (App Router)	Server components for fast initial load, API routes for backend logic
Database	Supabase (Postgres + Realtime)	Realtime subscriptions for The Wall and Who's Going, Row Level Security, instant setup
Icons	Lucide React	Clean, consistent iconography
Deployment	AWS Amplify	Hosting with CI/CD from GitHub

Database Design

Four tables with Row Level Security:

events      → id, title, description, date, location, category, rsvp_count
rsvps       → id, event_id, name, email (unique per event+email)
submissions → id, author_name, title, content, type (poem|letter|story)
streaks     → id, email, name, hike_count, current_streak, last_hike_month

A Postgres trigger auto-increments rsvp_count when a new RSVP is inserted. The streak API calculates month-over-month continuity server-side to prevent gaming.

Realtime Features

Two features use Supabase Realtime subscriptions:

The Wall subscribes to INSERT events on submissions — new poems appear instantly for all viewers
Who's Going subscribes to INSERT events on rsvps filtered by event_id — new RSVPs show up live on event cards

What Makes This Different

The Suffering Streak is technically just a counter with date logic, but it resonates because it's built on an inside joke. The Wall is a living space where Sheng poems sit next to Swahili letters sit next to English stories, exactly like a real Qwani session.

Building env-doctor with GitHub Copilot CLI

Lewis Sawe — Sun, 15 Feb 2026 23:09:49 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built env-doctor, a CLI tool that automatically checks if your local environment matches what your project expects. You know that frustrating moment when you clone a project and spend an hour figuring out why it won't run? Usually it's missing Node versions, environment variables, or services that weren't mentioned clearly in the README. This tool solves that.

It scans your project files - package.json, Dockerfile, docker-compose.yml, README, CI configs, and more - then extracts what the project actually needs. After that, it checks your local setup and gives you a clear checklist of what's working and what needs fixing. Instead of hunting through documentation, you get a direct report: "Node.js ✅, Docker ✅, PostgreSQL ❌ not running, DATABASE_URL ❌ missing."

The tool covers runtime versions, package managers, databases, services, environment variables, and port availability. It works with Node.js, Python, Go projects and gives you actionable suggestions for fixing issues. There's also JSON output for CI pipelines and a verbose mode that explains everything it found.

Demo

The tool is available at github.com/env-doctor with a comprehensive example project that demonstrates all features.

Here's what happens when you run it on a complex project:

$ env-doctor --verbose

env-doctor - Analyzing project environment...

Runtime Versions:
✅ Node.js 18.17.0 (required: >=18.0.0)
✅ Docker running (v24.0.7)
❌ Python 3.8.10 (required: >=3.9.0)

Services:
❌ redis not found
✅ PostgreSQL accessible on port 5432

Environment Variables:
❌ DATABASE_URL environment variable not set
❌ JWT_SECRET environment variable not set
✅ NODE_ENV=development

📊 Results: 4/8 checks passed (4 failed)
❌ Environment needs attention

 Next steps:
1. Update Python to >=3.9.0
2. Install and start redis
3. Set DATABASE_URL environment variable
4. Set JWT_SECRET environment variable

The example project I included shows off the tool's capabilities with a realistic full-stack application. It has Node.js, Python, and Go services, multiple databases, complex Docker setup, and tons of environment variables. When you run env-doctor on it, you get 13/59 checks passing, which perfectly demonstrates how the tool handles complex real-world projects.

I also built a simple demo script that explains what each file type contributes to the analysis. You can clone the repo and run cd example-project && ./demo.sh to see everything in action.

My Experience with GitHub Copilot CLI

Using GitHub Copilot CLI completely changed how I approached this project. Instead of writing code bit by bit, I could focus on the bigger picture and let Copilot handle the implementation details.

The most helpful part was how Copilot understood context across multiple files. When I described the file parsing requirements, it generated parsers for package.json, Dockerfile, docker-compose.yml, and CI configs all at once. Each parser was tailored to extract the right information - Node versions from package.json, base images from Dockerfiles, services from docker-compose files.

What impressed me was how it handled the environment checking logic. I explained that I needed to verify Node versions, check if Docker is running, test database connectivity, and validate environment variables. Copilot created a comprehensive checking system with proper error handling and meaningful status messages.

The CLI also helped with the user experience aspects I hadn't initially planned. It suggested adding colored output with emoji indicators, a verbose mode for detailed explanations, JSON output for CI integration, and helpful suggestions for fixing issues. These weren't things I explicitly asked for, but Copilot recognized they would make the tool more useful.

Testing was another area where Copilot excelled. It created unit tests for individual components and an integration test that builds a temporary project structure to verify everything works together. The test coverage caught several edge cases I would have missed.

The most significant impact was being able to iterate quickly on complex features. When I wanted to add support for Python projects, Copilot immediately understood I needed requirements.txt and pyproject.toml parsers, Python version checking, and pip availability tests. What would have taken me hours of research and implementation happened in minutes.

Copilot also helped with the example project creation. I described wanting a comprehensive test case, and it built a realistic social media application with multiple languages, databases, microservices, and CI/CD pipelines. This wasn't just a toy example - it's the kind of complex project where env-doctor actually provides value.

The experience showed me how AI tools can handle the mechanical aspects of programming while leaving the creative and strategic decisions to the human developer. I focused on the problem design and user experience while Copilot handled the implementation patterns, error cases, and integration detail

Why My Portfolio Has Superpowers and Villain Galleries

Lewis Sawe — Sat, 31 Jan 2026 16:56:41 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

When I started thinking about my portfolio, I realized most developer portfolios look the same. Clean, minimal, professional. Nothing wrong with that, but it wasn't really me. I wanted something that showed I can do the technical work but also that I don't take myself too seriously. That's where the comic book theme came from. It's a bit ridiculous, but it works.

Portfolio

How I Built It

Built this with React 19 and TypeScript because I wanted type safety and didn't want to deal with prop-type headaches. Used Vite for the build setup since it's fast and doesn't require much configuration. Tailwind handled the styling with a custom theme I put together using comic book colors and those classic comic effects like rotated text and bold borders.

For the data visualization stuff showing skill levels, I used Recharts. It's straightforward and does what I needed without overcomplicating things. The whole thing runs in a Docker container and deploys to Google Cloud Run, which made sense since that's what the challenge required anyway.

I used Google AI Studio and Gemini to help with the content. Writing about yourself is weird, so I had it help brainstorm section names and refine some of the project descriptions. It was useful for keeping the comic book voice consistent without going overboard. I'd feed it my rough notes about projects and it'd help make them more readable while keeping them honest.

The comic book theme isn't just decoration. Instead of calling things "Skills" and "Projects," I went with "Superpowers" and "Missions." There's a "Villain Gallery" section where I talk about actual problems I've dealt with, like systems going down for hours or AWS bills getting out of control. Each one shows what the problem was, how I fixed it, and what changed. It's more interesting than just listing technologies.

Added some interactive stuff too. There's a Konami Code easter egg if you're into that sort of thing, and a click combo system that triggers effects if you click fast enough. Floating particles in the background give it some movement without being distracting. These weren't necessary but they made it more fun to build.

The deployment was straightforward. Multi-stage Docker build where Node compiles everything, then Nginx serves the static files. Keeps the final image small, around 50MB. Cloud Run handles the scaling and HTTPS automatically, and I added the required label for the challenge. The whole setup deploys in a few minutes.

What I'm Most Proud Of

The theme actually works. Every section fits the comic book idea without feeling forced. Hover effects show "KAPOW!" and "ZAP!" text, section headers are rotated like comic panels, and the color scheme stays consistent. It's cohesive but not overwhelming.

Behind all the comic book stuff, the content is real. I've got 9 cloud certifications, projects that range from serverless games to chaos engineering experiments, and actual results from work I've done. One project cut downtime by 95%, another reduced cloud costs by 35%. The fun presentation doesn't hide that there's substance underneath.

The interactive elements turned out better than I expected. The Konami Code works, the click combos feel responsive, and the floating particles add just enough movement. I also made sure it's accessible with proper semantic HTML and ARIA labels, and it's fully responsive. Tested it on mobile and it holds up.

Performance is solid too. Lighthouse scores are in the mid-90s across the board. The Docker image is optimized, and Cloud Run's auto-scaling means it handles traffic spikes without me thinking about it. It's set up properly for production even though it's a portfolio site.

Honestly, I'm just glad I built something that shows what I can do technically while also showing I'm not a robot. If someone looks at this and thinks "this person knows their stuff but seems like they'd be decent to work with," then it did its job.

Live Site: https://comic-portfolio-610288702971.us-central1.run.app

GitHub: https://github.com/lewisawe

LinkedIn: https://linkedin.com/in/lewisawe

Building Multi-Agent AWS Operations Intelligence with Amazon Bedrock AgentCore

Lewis Sawe — Mon, 29 Sep 2025 15:31:46 +0000

We set out to build something that didn't exist yet - a multi-agent AI system that could automatically discover AWS environments and provide real operations intelligence across entire organizations. The goal wasn't just to make another monitoring tool, but to create agents that could actually understand AWS infrastructure and costs in ways that existing tools couldn't.

What We Built

The AWS Operations Command Center is a three-agent system built on Amazon Bedrock AgentCore. Each agent specializes in a different aspect of AWS operations, but they work together to provide unified intelligence about your infrastructure.

The Cost Intelligence Agent handles financial analysis across multiple AWS accounts. It doesn't just pull billing data - it separates actual usage costs from credits to show you what you're really consuming. Most AWS billing tools show you net costs after credits, which hides your actual usage patterns. Our agent discovered $255.22 in real usage across our three-account organization that was almost completely offset by $255.21 in credits, leaving a final bill of just $0.01.

The Operations Intelligence Agent scans resources across your entire AWS organization. It uses cross-account roles to inventory everything from EC2 instances to S3 buckets to RDS databases. In our testing, it found 90 resources across our accounts that we could then analyze for security issues, performance bottlenecks, and optimization opportunities.

The Infrastructure Intelligence Agent generates architecture recommendations and scores existing setups for security and reliability. It's not just templating - it analyzes your actual infrastructure and suggests improvements based on AWS best practices.

The AgentCore Implementation

Getting these agents to work with Amazon Bedrock AgentCore was more challenging than expected. The documentation makes it look straightforward, but the reality involved a lot of trial and error.

Each agent uses the AgentCore runtime framework. The basic structure looks like this:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload):
    session_id = payload.get('session_id', str(uuid.uuid4()))

    # Store session context in memory service
    memory_service.store_context(session_id, {
        'agent': 'cost_intelligence',
        'timestamp': datetime.now().isoformat(),
        'payload': payload
    })

    # Process the request
    result = agent.get_multi_account_costs()

    # Add AgentCore metadata
    result.update({
        'services_used': ['runtime', 'memory', 'gateway'],
        'session_id': session_id
    })

    return result

The memory service integration was crucial for getting agents to share context. When the cost agent discovers expensive resources, that information needs to be available to the operations agent for deeper analysis. We implemented a simple but effective memory service that stores session data with TTL expiration.

Agent coordination happens through an orchestrator that can invoke agents either locally or through the AgentCore gateway. The orchestrator handles partial failures gracefully - if one agent fails, the others continue working and provide what insights they can.

Self-Discovery Architecture

One of the biggest challenges was making the agents work in any AWS environment without manual configuration. Most tools require you to specify account IDs, regions, and access patterns upfront. We wanted agents that could figure out their environment automatically.

The solution was environment discovery during agent initialization. Each agent detects whether it's running in an AWS Organizations management account by trying to call the Organizations API. If that succeeds, it knows it can do cross-account analysis. If not, it falls back to single-account mode.

def _discover_environment(self):
    try:
        sts = boto3.client('sts')
        self.current_account_id = sts.get_caller_identity()['Account']

        try:
            self.organizations = boto3.client('organizations')
            org_info = self.organizations.describe_organization()
            self.is_org_account = True

            accounts = self.organizations.list_accounts()
            self.org_accounts = [
                {'id': acc['Id'], 'name': acc['Name'], 'status': acc['Status']}
                for acc in accounts['Accounts'] if acc['Status'] == 'ACTIVE'
            ]
        except:
            self.is_org_account = False
            self.org_accounts = [{'id': self.current_account_id, 'name': 'current', 'status': 'ACTIVE'}]
    except Exception as e:
        # Handle gracefully
        pass

This approach means you can deploy the same agent code anywhere and it adapts to its environment. Deploy it in a standalone account and it analyzes that account. Deploy it in an organization management account and it analyzes the entire organization.

Cross-Account Access Challenges

Getting true multi-account analysis working was the hardest part. AWS has good security boundaries between accounts, which is great for isolation but challenging when you want unified operations intelligence.

We solved this with cross-account IAM roles deployed via CloudFormation. Each member account gets an OrganizationAccountAccessRole that the management account can assume. The role has read-only permissions and requires an external ID for additional security.

The deployment process uses the configured AWS profiles to push CloudFormation templates to each account:

def deploy_role_to_profile(profile_name, account_name):
    session = boto3.Session(profile_name=profile_name, region_name='us-east-1')
    cf = session.client('cloudformation')

    response = cf.create_stack(
        StackName='aws-operations-command-center-role',
        TemplateBody=template_body,
        Capabilities=['CAPABILITY_NAMED_IAM']
    )

    waiter = cf.get_waiter('stack_create_complete')
    waiter.wait(StackName='aws-operations-command-center-role')

Once the roles are deployed, agents can assume them to access resources in member accounts. The cost agent uses this to get billing data from each account separately, then aggregates it for organization-wide analysis. The operations agent uses it to scan resources across all accounts.

Real-World Challenges

The AgentCore CLI had reliability issues. The agentcore deploy command failed more often than it worked, usually with cryptic IAM errors. Even with admin permissions, we'd hit edge cases where role creation would partially succeed, leaving broken deployments that were hard to clean up.

The memory service had undocumented size limits that caused silent failures. Context data would just disappear without error messages, making debugging difficult. We ended up implementing our own memory service with proper error handling and size checks.

Gateway service communication was unreliable under load, with intermittent connection failures. We built a fallback mechanism that uses local agent invocation when the gateway isn't available.

Version compatibility between the AgentCore CLI and SDK was problematic. Upgrading would break existing configurations in ways that weren't well documented. We had to pin to specific versions and test thoroughly before any updates.

Production-Ready Error Handling

One thing we learned quickly was that AWS APIs fail in many different ways, and you need to handle each failure mode appropriately. We built a comprehensive error handling system that categorizes failures and responds accordingly.

def safe_aws_call(func, *args, max_retries=3, **kwargs):
    for attempt in range(max_retries):
        try:
            result = func(*args, **kwargs)
            return {'success': True, 'data': result}
        except ClientError as e:
            error_code = e.response['Error']['Code']
            if error_code in ['Throttling', 'RequestLimitExceeded']:
                time.sleep(2**attempt)
                continue
            elif error_code == 'AccessDenied':
                return {'success': False, 'error': 'access_denied'}
            else:
                return {'success': False, 'error': str(e)}
        except NoCredentialsError:
            return {'success': False, 'error': 'no_credentials'}

    return {'success': False, 'error': 'max_retries_exceeded'}

This wrapper handles throttling with exponential backoff, distinguishes between different types of access errors, and provides meaningful error messages that agents can act on.

What We Learned

Building multi-agent systems with AgentCore taught us that the framework is powerful but still rough around the edges. The core concepts are solid - the runtime, memory, and gateway services provide a good foundation for agent coordination. But the tooling needs work, especially around deployment and debugging.

The self-discovery approach worked better than expected. Having agents that adapt to their environment makes deployment much simpler and reduces configuration errors. It also makes the system more resilient - agents continue working even when they can't access all the resources they'd like to.

Cross-account analysis is valuable but complex. The security boundaries that make AWS safe also make unified operations intelligence challenging. The IAM role approach works, but it requires careful setup and ongoing maintenance.

Results

The final system provides genuine business value. It discovered $255.22 in AWS usage across our organization that was hidden by credits, giving us visibility into our actual consumption patterns. It inventoried 90 resources across multiple accounts, providing a unified view of our infrastructure that we didn't have before.

More importantly, it demonstrates that multi-agent AI systems can solve real operational problems. The agents work together to provide insights that none of them could generate alone. The cost agent finds expensive resources, the operations agent analyzes them for optimization opportunities, and the infrastructure agent suggests architectural improvements.

The system is production-ready with comprehensive error handling, structured logging, and graceful degradation when services are unavailable. It's not just a demo - it's a working operations intelligence platform that scales from single accounts to entire AWS organizations.

REFERENCES

Lets Connect - Lewis Sawe: LinkedIn

Buy me coffee ☕

Spooky Smart AI That Designs Your Halloween Look

Lewis Sawe — Sun, 14 Sep 2025 21:51:31 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

I built the AI Halloween Costume Generator, a comprehensive web application designed to solve the age-old problem of choosing the perfect Halloween costume. It acts as a creative partner, transforming vague ideas or even simple images into complete, ready-to-make costume guides.

The app provides a multi-faceted approach to inspiration:

Search: Users can type in any theme or idea (e.g., "costumes for my dog," "spooky sci-fi ideas") and receive five distinct, fully-detailed costume concepts to compare and choose from.

Generate from Image: Users can upload a photo of an object, a person, or a pet, and the AI will generate a unique costume concept based on the visual input.

Surprise Me!: For users who are completely stumped, a "Surprise Me!" button generates a totally random and creative idea out of the blue.

Once an idea is selected, the app provides a complete DIY guide, including a list of materials, an estimated cost and difficulty level, and most importantly, detailed step-by-step instructions with custom-generated, additive illustrations that show the costume coming together.

Demo

To try out: Cloud Run Demo link

How I Used Google AI Studio

I leveraged a suite of multimodal models from the Gemini API to power the application's core features, orchestrating them to create a seamless user experience.

gemini-2.5-flash: This was the primary model for all text and structured data generation. I used it with a strictly defined responseSchema to ensure the AI's output was always in a predictable JSON format. This model was responsible for:

Generating the costume's name, description, materials, and detailed text instructions.

Powering the search feature by creating five distinct costume concepts from a single prompt.

Handling the conversational "Refine" feature, where it would modify a costume based on follow-up user input.

imagen-4.0-generate-001: This powerful image generation model was used to create the crucial first image for each set of instructions, establishing the visual foundation for the step-by-step guide.

gemini-2.5-flash-image-preview: This versatile image editing model was the key to creating the app's most unique feature. It was used to generate all subsequent instruction images by taking the previous step's image as input and adding the new details described in the current step's text.

Multimodal Features

The app is built around two core multimodal functionalities that create a rich and intuitive user experience.

Vision Understanding: Image to Costume Idea

The ability for a user to upload an image and receive a relevant costume idea is a powerful multimodal feature. It goes beyond simple text prompts by allowing for visual context. A user can upload a picture of their pet, a favorite object, or a friend, and the AI can creatively interpret that visual data to generate a highly personalized and often unexpected costume concept. This makes the brainstorming process more personal and engaging.

Additive Image Generation: A Cohesive Visual Guide

The app's standout feature is its ability to create a set of instruction images that build upon one another. Instead of generating a new, disconnected image for each step, the system uses an iterative, multimodal process:

Step 1: Generate a base image from a text prompt.
Step 2+: Feed the image from the previous step plus the text for the current step into the image editing model (gemini-2.5-flash-image-preview).

This creates a coherent visual narrative, allowing the user to literally watch the costume come together from one image to the next. This significantly enhances the user experience by making the instructions far easier to understand and follow compared to a series of isolated diagrams. It transforms the app from a simple idea generator into a true step-by-step visual crafting guide.

CLI for the Clueless, Learning AWS CLI Through Interactive Gaming

Lewis Sawe — Tue, 19 Aug 2025 22:47:16 +0000

Forget boring tutorials and dry documentation. What if you could learn AWS CLI by solving mysteries, following clues, and completing challenges? What if mastering the command line felt more like playing a game than studying?

I built an AWS CLI Scavenger Hunt game that teaches you AWS CLI commands through progressive challenges and real-world scenarios. No installation required, no AWS account needed.

Try out the game hosted here - https://lewisawe.github.io/laughing-potato/

Why Learn AWS CLI Through Gaming?

Traditional learning methods for AWS CLI often fail because they're boring, abstract, intimidating, and passive. You read documentation that puts you to sleep, try to memorize commands without context, get scared away by the black terminal screen, and never actually practice what you're learning.

Now instead of reading about commands, you're solving mysteries that keep you motivated. Every command has a purpose and story behind it, making the learning contextual and memorable. The progressive difficulty starts easy and builds complexity naturally, while you're actively typing commands from minute one.

Meet Your New Learning Platform

The AWS CLI Scavenger Hunt simulates a real AWS environment directly in your browser. You'll type actual AWS commands, see authentic responses, and solve progressively challenging scenarios across multiple AWS services.

The game covers over ten AWS services including S3, IAM, Lambda, DynamoDB, CloudFormation, Secrets Manager, CloudWatch, KMS, EC2, and VPC. Every command you learn uses real syntax with authentic responses, so the skills transfer directly to actual AWS work.

Smart learning features enhance the experience throughout. Auto-completion shows you available commands as you type, complete with descriptions. A contextual help system provides service-specific guidance when you're stuck. Progressive hints appear after failed attempts, and an achievement system keeps you motivated to improve.

Your Learning Journey: From Zero to Hero

Level 1: Beginner - "The S3 Mystery"

Your journey begins with the fundamentals. You'll learn the basic command structure that all AWS CLI commands follow:

aws [service] [action] [options]

The first challenge presents you with a simple mystery: "Three buckets hold the key, but only one contains what you seek. List the S3 buckets to begin your quest..."

When you type the command, you'll see a realistic response:

$ aws s3 ls
2023-08-19 12:34:56 my-app-bucket
2023-08-19 12:35:12 clue-bucket-1
2023-08-19 12:35:28 backup-storage-bucket

One stands out: clue-bucket-1. The game then guides you to explore inside this bucket:

$ aws s3 ls s3://clue-bucket-1
2023-08-19 12:36:45        156 clue.txt

This teaches you how to navigate S3 storage and read responses. Each successful command reveals the next clue, creating a natural progression that builds confidence.

By the end of the beginner level, you'll be comfortable with the command line interface, understand how to read AWS CLI output, know basic S3 navigation, and have developed a problem-solving mindset that serves you throughout your AWS journey.

Level 2: Intermediate - "Multi-Service Investigation"

The intermediate level introduces you to the real power of AWS CLI: working across multiple services. You'll start by investigating encrypted S3 buckets and CloudTrail logs, learning how different AWS services connect and share information.

A typical challenge might reveal a Lambda function called 'log-processor' through your investigation. When you run the command, you'll discover environment variables pointing to encrypted SSM parameters:

$ aws lambda get-function --function-name log-processor
{
    "Configuration": {
        "FunctionName": "log-processor",
        "Runtime": "python3.9",
        "Environment": {
            "Variables": {
                "SSM_PARAMETER_PATH": "/advanced-hunt/encrypted-clue",
                "LOG_LEVEL": "INFO"
            }
        }
    }
}

This teaches you how to follow data flows across services, a crucial skill for real-world AWS work. You'll then retrieve the encrypted parameter:

$ aws ssm get-parameter --name /advanced-hunt/encrypted-clue --with-decryption
{
    "Parameter": {
        "Name": "/advanced-hunt/encrypted-clue",
        "Type": "SecureString",
        "Value": "The final clue is in DynamoDB table 'hunt-secrets'",
        "Version": 2
    }
}

The level progresses through Lambda function investigation, encrypted SSM parameters with decryption, and DynamoDB operations. You'll learn cross-service workflows, JSON parsing and analysis, encryption concepts, and real-world AWS patterns that professionals use daily.

Why This Approach Works

Learning by doing proves far more effective than memorizing syntax. Instead of trying to remember abstract commands, you discover them naturally through problem-solving. Each command has immediate purpose and visible results, making the learning stick.

Contextual understanding develops as you see how S3 connects to Lambda, how SSM parameters work with DynamoDB, and how services integrate in real applications. This holistic view proves invaluable when working with actual AWS environments.

Progressive complexity ensures you're never overwhelmed. You start with simple commands and gradually build to complex queries:

# Start simple
aws s3 ls

# Build complexity
aws s3 ls s3://bucket-name --recursive

# Master advanced queries
aws ec2 describe-instances --query "Reservations[].Instances[?State.Name=='running'].{ID:InstanceId,Type:InstanceType}"

Immediate feedback accelerates learning. You don't wait for AWS responses or worry about costs. Every command provides instant feedback, with helpful hints when you're stuck. This rapid iteration helps you learn faster than traditional methods.

Real-world relevance keeps you engaged. Every scenario is based on actual AWS use cases: troubleshooting applications, investigating security incidents, and analyzing infrastructure. The skills you develop apply directly to professional work.

Beyond the Game

The commands you master in the game apply directly to professional AWS work. You'll learn essential AWS CLI patterns like identity and configuration commands:

# Check who you are
aws sts get-caller-identity

# View your configuration
aws configure list

# Get current region
aws configure get region

S3 operations become second nature:

# List buckets
aws s3 ls

# List bucket contents
aws s3 ls s3://my-bucket

# Download files
aws s3 cp s3://my-bucket/file.txt .

# Upload files
aws s3 cp file.txt s3://my-bucket/

Advanced querying with JMESPath filters:

# Find running instances
aws ec2 describe-instances --query "Reservations[].Instances[?State.Name=='running']"

# Get instance IDs only
aws ec2 describe-instances --query "Reservations[].Instances[].InstanceId" --output text

# Filter by tags
aws ec2 describe-instances --query "Reservations[].Instances[?Tags[?Key=='Environment' && Value=='production']]"

Multi-service workflows become second nature as you practice commands like:

# Get encrypted parameters
aws ssm get-parameter --name /path/to/secret --with-decryption

# Investigate Lambda functions
aws lambda get-function --function-name my-function

# Query DynamoDB
aws dynamodb get-item --table-name MyTable --key '{"id":{"S":"item-id"}}'

These patterns appear constantly in real AWS environments.

The skills transfer directly to DevOps workflows for automating deployments and monitoring, security operations for investigating incidents and analyzing logs, cost optimization for finding and managing unused resources, troubleshooting for diagnosing application and infrastructure issues, and compliance work for auditing configurations and access patterns.

Advanced Features for Serious Learners

The achievement system rewards different types of mastery. Perfect Navigator recognizes completing levels with 90% efficiency, while Speed Demon celebrates finishing levels in record time. No Hints Needed acknowledges mastering commands without assistance, and Command Master honors conquering all difficulty levels.

Smart learning tools enhance the experience throughout your journey. Auto-completion shows available commands as you type:

aws s3 <TAB>
# Shows: cp, ls, mb, mv, rb, rm, sync, website

Command history lets you navigate previous commands with arrow keys, contextual help provides service-specific guidance, and progress tracking monitors your improvement over time.

The realistic simulation uses authentic AWS responses with real JSON output formats, proper error messages that teach you from realistic failure scenarios, service integration that shows how AWS services work together, and best practices with commands that follow AWS recommended patterns.

The Science Behind Game-Based Learning

Research consistently shows that interactive, game-based learning increases retention by 75%, reduces learning time by 40%, improves problem-solving skills, and builds confidence faster than traditional methods. The science explains why this approach works so well for technical skills.

Active learning engages you in doing rather than just reading. Immediate feedback lets you know instantly if you're right or wrong. Intrinsic motivation through curiosity drives you forward naturally. Spaced repetition reinforces commands through varied contexts. Flow state occurs when optimal challenge level keeps you engaged without overwhelming you.

Frequently Asked Questions

Do you need an AWS account? No! The game simulates AWS responses, so you can learn without any setup or costs.

What if you get stuck? The game provides progressive hints after failed attempts, plus contextual help for every service.

How realistic are the scenarios? Every challenge is based on real AWS use cases that professionals encounter daily.

Can you use this to prepare for AWS certifications? Absolutely! The commands and concepts directly apply to AWS certification exams.

Is this suitable for complete beginners? Yes! The Beginner level assumes no prior CLI or AWS experience.

Lets Connect - Lewis Sawe: LinkedIn

Buy me coffee ☕

Creating a Plants Vs Zombies with Redis

Lewis Sawe — Sun, 10 Aug 2025 23:43:17 +0000

This is a submission for the Redis AI Challenge: Beyond the Cache.

What I Built

I developed a Plants vs. Zombies-inspired tower defense game that redefines what’s possible with Redis. This project uses Redis as the entire backend infrastructure. All game logic, state management, and real-time features are handled without a traditional SQL or NoSQL database.

Core Game Features

Tower Defense: Engage in real-time battles against waves of zombies.
Live Leaderboards: Compete for the top spot with five different real-time leaderboards.
Persistent Game State: Players can reconnect and resume their games exactly where they left off. -** Dynamic Player Stats:** Track comprehensive, live statistics and player progress.
Smart Username Suggestions: Get creative, plant-themed username ideas automatically.

How Redis Powers the Backend

Redis is the engine behind the game. I utilized its diverse data structures to build a highly performant and scalable backend.
Real-time Communication: Redis Pub/Sub handles all real-time events for multiplayer gameplay.
Leaderboards: Redis sorted sets manage and update the live leaderboards, making it easy to rank players.
Player Data: Game state and player statistics are stored using Redis hashes and other data structures for efficient access and updates.
Analytics: Redis data structures track game metrics and analytics on the fly.
Persistence: Redis's persistence features ensure that all game data is saved across sessions.

Demo

Here is the full Github Code you can test for yourself Github Code

How I Used Redis 8

This project demonstrates Redis using different Redis data structures to replace traditional database architectures:

1. Primary Database (Hashes)

Redis completely replaces SQL databases
Redis stores all persistent data including complex nested game states, player profiles, and session information.

// Store complete game states as JSON
await redis.hset(`game:${gameId}:state`, 'data', JSON.stringify({
  players: {...},
  plants: [...],
  zombies: [...],
  currentWave: 5,
  gameStatus: 'playing'
}));

// Player profiles with statistics and achievements  
await redis.hset(`player:${playerId}:data`, {
  score: 15420,
  zombiesKilled: 89,
  plantsPlanted: 156,
  gamesWon: 12,
  achievements: JSON.stringify(['first_win', 'zombie_slayer'])
});

2. Real-Time Pub/Sub

Live multiplayer without polling
All real-time updates use Redis Pub/Sub for sub-millisecond message delivery to unlimited concurrent players.

// Broadcast plant placements to all players instantly
await redis.publish(`game:${gameId}:updates`, JSON.stringify({
  type: 'plant_placed',
  plant: {type: 'sunflower', row: 2, col: 3},
  playerId: 'GardenMaster',
  timestamp: Date.now()
}));

// Wave completion notifications
await redis.publish(`game:${gameId}:events`, JSON.stringify({
  type: 'wave_completed', 
  wave: 5,
  nextWaveIn: 30000,
  message: 'Wave 5 completed! Prepare for boss wave!'
}));

3. Event Sourcing (Streams)

Complete game replay and analytics pipeline
Provides complete event sourcing capabilities - every game action is recorded for replay, analytics, and debugging without external event streaming systems

// Record every game action for complete audit trail
await redis.xadd(`game:${gameId}:events`, '*', {
  action: 'plant_placed',
  playerId: 'ZombieSlayer', 
  plantType: 'peashooter',
  position: JSON.stringify({row: 1, col: 4}),
  cost: 100,
  timestamp: Date.now()
});

// Analytics pipeline processes all events
const gameEvents = await redis.xrange(`game:${gameId}:events`, '-', '+');
// Can reconstruct any game state from event history

4. Leaderboards (Sorted Sets)

Real-time competitive rankings
Automatic ranking system with O(log N) performance - no manual sorting or separate ranking calculations needed.

// Update multiple leaderboards simultaneously during gameplay
await redis.zadd('leaderboard:high_scores', player.score, playerId);
await redis.zadd('leaderboard:zombies_killed', player.zombiesKilled, playerId);
await redis.zadd('leaderboard:plants_planted', player.plantsPlanted, playerId);

// Get top 10 players with scores instantly
const topPlayers = await redis.zrevrange('leaderboard:high_scores', 0, 9, 'WITHSCORES');
// Returns: [['EpicSunflower', '25840'], ['GardenMaster', '23150'], ...]

5. Lane Management (Lists)

FIFO zombie queues for game mechanics
Perfect queue management for game mechanics - zombies spawn and move in correct order with atomic operations.

// Each game lane has its own zombie queue
await redis.lpush(`game:${gameId}:lane:0:zombies`, JSON.stringify({
  type: 'basic_zombie',
  health: 100,
  speed: 1.0,
  spawnTime: Date.now()
}));

// Process zombies in spawn order (FIFO)
const nextZombie = await redis.rpop(`game:${gameId}:lane:0:zombies`);

👥 6. Session Management (Sets)

Active games and player tracking
Efficient session management with set operations - instant membership checks and lobby management without complex queries.

// Track all active games
await redis.sadd('active_games', gameId);

// Track players in each game
await redis.sadd(`game:${gameId}:players`, playerId);

// Efficient membership checks
const isPlayerInGame = await redis.sismember(`game:${gameId}:players`, playerId);
const activeGameCount = await redis.scard('active_games');

7. Analytics & Metrics (HyperLogLog + Counters)

Memory-efficient statistics
Memory-efficient unique counting, global statistics, and rate limiting without external analytics systems.

// HyperLogLog for unique player counting (uses only ~12KB for millions of players)
await redis.pfadd('hll:unique_players', playerId);
const uniquePlayerCount = await redis.pfcount('hll:unique_players');

// Global game statistics
await redis.incr('counter:total_games');
await redis.incrby('counter:zombies_killed', zombiesKilledThisGame);
await redis.incrby('counter:plants_planted', plantsPlantedThisGame);

// Rate limiting with expiring counters
await redis.incr(`rate_limit:${playerId}:${currentHour}`);
await redis.expire(`rate_limit:${playerId}:${currentHour}`, 3600);

Traditional Redis Usage

// What most applications do - Redis as cache layer
const cachedUser = await redis.get(`cache:user:${userId}`);
if (!cachedUser) {
  const user = await database.query('SELECT * FROM users WHERE id = ?', userId);
  await redis.setex(`cache:user:${userId}`, 3600, JSON.stringify(user));
  return user;
}
return JSON.parse(cachedUser);

Redis as Complete Platform

// What this project demonstrates - Redis as the entire backend
class GameEngine {
  constructor(redis) {
    this.redis = redis; // Redis IS the database, not a cache
  }

  async placePlant(gameId, playerId, plantType, row, col) {
    // 1. Primary Database: Update game state
    const gameState = await this.redis.hget(`game:${gameId}:state`, 'data');
    // ... modify game state ...
    await this.redis.hset(`game:${gameId}:state`, 'data', JSON.stringify(gameState));

    // 2. Real-time: Notify all players instantly
    await this.redis.publish(`game:${gameId}:updates`, JSON.stringify({
      type: 'plant_placed', plant: newPlant, playerId
    }));

    // 3. Event Sourcing: Record for replay/analytics
    await this.redis.xadd(`game:${gameId}:events`, '*', {
      action: 'plant_placed', playerId, plantType, row, col
    });

    // 4. Leaderboards: Update rankings
    await this.redis.zadd('leaderboard:plants_planted', ++player.plantsPlanted, playerId);

    // 5. Analytics: Update global statistics
    await this.redis.incr('counter:plants_planted');
    await this.redis.pfadd('hll:unique_players', playerId);

    // 6 different Redis capabilities in one operation!
  }
}

Key Technical Achievements

Architecture Innovation

Zero SQL databases - Redis handles all data persistence
No cache invalidation - No cache layer because Redis IS the primary database
Event-driven design - Pub/Sub eliminates all polling
Complete audit trails - Streams provide event sourcing out of the box ### Performance Benefits
Sub-millisecond operations - All data operations in memory
Zero cache misses - No cache layer means no cache invalidation complexity
Horizontal scalability - Architecture ready for Redis Cluster deployment
Memory efficiency - HyperLogLog and optimized data structures

roduction Game Features

Persistent progression - Player statistics and achievements survive server restarts
Live competitive rankings - 5 different leaderboard categories updating in real-time
Smart user experience - Auto-generated usernames, responsive design, health monitoring

Deployment Ready

Docker support - Single container and multi-container configurations
Production logging - Structured logging with multiple log levels
Health monitoring - Comprehensive health checks and metrics endpoints
Complete documentation - Deployment guides, API documentation, development workflows

Conclusion

This Plants vs Zombies game demonstrates Redis as a complete, powerful, multi-model platform that can:

Replace entire database stacks - No PostgreSQL, MongoDB, or MySQL needed

Provide real-time capabilities - Built-in Pub/Sub eliminates message queues

Handle complex analytics - HyperLogLog, counters, and sorted sets for insights

Scale to millions of users - Ready for Redis Cluster horizontal scaling

Deliver consistent sub-millisecond performance - All operations in memory

The game is fully functional, production-ready, and demonstrates Redis as the complete backend infrastructure for modern real-time applications.

From Challenge to Comprehensive App, My Frontend Development Journey

Lewis Sawe — Sun, 27 Jul 2025 13:53:20 +0000

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

What I Built

I created a comprehensive Virtual Office Intranet that transforms the traditional workplace experience into an engaging, interactive digital environment. The application simulates a complete office ecosystem with modern glass morphism design and real-time functionality.

Key Features:

Interactive Office Desk

3x2 compact grid of interactive desk items (notes, coffee, plant, calendar, printer, paperclips)
Each item has realistic interactions and state management
Coffee levels, plant growth tracking, printer queue status
Sticky notes system with realistic appearance and color coding

Enhanced Weather Widget

5-day forecast with detailed weather information
Interactive controls and comprehensive stats
Real-time updates and beautiful visual design
Optimized to utilize space effectively

Team Management

Live team member status and availability
Skills tracking and action buttons
Real-time status updates and interactions
Professional profile cards with avatars

Task & Project Management

CRUD operations for tasks with priority levels
Progress tracking and completion statistics
Interactive task cards with status indicators
Pomodoro timer integration with circular progress

Meeting & Calendar System

Video meeting interface with participant grid
Screen sharing options and chat system
Meeting scheduling and management
Calendar widget integration

Analytics Dashboard

Interactive charts and performance metrics
Real-time data visualization
Productivity insights and statistics
Responsive chart interactions

Activity Feed

Real-time activity notifications
Team member actions and system updates
Time-stamped entries with status indicators
Comprehensive activity tracking

Comprehensive Toolbar

Email, calendar, HR portal, IT help desk
Document management and analytics access
Notes system and quick actions
All features fully implemented and functional

Demo

The full source code for NovaTech is available on GitHub. Feel free to explore, contribute, or fork the project: Github Repo

Want to see NovaTech in action? A live version is hosted on GitHub Pages for easy testing: Github Pages Live Link

Journey

Initial Challenge

The project started with a basic layout requirement but evolved into a comprehensive virtual office experience. The main challenges were:

Creating Realistic Interactions: Making desk items feel authentic with proper state management
Responsive Design: Ensuring the 3x2 desk items grid worked across all devices
Real-time Functionality: Simulating live updates without a backend
Professional UI/UX: Achieving a modern, glass morphism design

Development Process

Phase 1: Foundation & Layout

Implemented basic HTML structure with semantic elements
Created responsive grid system for office desk layout
Established glass morphism design system with backdrop blur
Set up proper color scheme and typography

Phase 2: Interactive Components

Developed desk item interactions (coffee, notes, plant, etc.)
Implemented modal system for detailed views
Created sticky notes system with realistic appearance
Added weather widget with comprehensive functionality

Phase 3: Data Integration

Built comprehensive dummy data system (18KB of realistic data)
Implemented API simulation with WebSocket functionality
Created real-time update system for team status and activities
Added proper error handling and fallback mechanisms

Phase 4: Advanced Features

Developed video meeting interface with participant grid
Implemented task management with CRUD operations
Created analytics dashboard with interactive charts
Added Pomodoro timer with circular progress indicator

Phase 5: Polish & Optimization

Fixed layout issues and responsive behavior
Optimized desk items for 3x2 compact grid
Enhanced activity feed with proper dummy data display
Removed all test/debug files for clean production code

Technical Decisions I'm Proud Of

1. Glass Morphism Design System

.desk-item {
    background: rgba(255, 255, 255, 0.03);
    backdrop-filter: blur(20px);
    border: 1px solid rgba(255, 255, 255, 0.08);
}

This creates a modern, professional appearance that's both beautiful and functional.

2. Real-time Simulation Without Backend

// WebSocket simulation for live updates
window.api.emit('team_status_update', {
    userId: 'sarah',
    status: 'in_meeting'
});

Achieved real-time functionality using event simulation, making the app feel alive.

3. Responsive 3x2 Grid System

.desk-items {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    grid-template-rows: repeat(2, 1fr);
    gap: 1rem;
}

Perfect balance between desktop and mobile experiences.

4. Comprehensive Data Architecture
Created 18KB of realistic dummy data covering team members, tasks, meetings, analytics, and activities - making the application feel like a real workplace tool.

What I Learned

CSS Grid Mastery: Achieved complex responsive layouts with proper fallbacks
State Management: Implemented comprehensive state tracking without frameworks
UI/UX Design: Created professional interfaces with attention to detail
Performance Optimization: Balanced rich functionality with smooth performance
Accessibility: Ensured proper focus management and semantic HTML

Challenges Overcome

Layout Consistency: Ensuring desk items matched weather widget proportions
Data Loading: Preventing async data loading from breaking widget functionality
Responsive Behavior: Making 3x2 grid work across all screen sizes
Real-time Updates: Simulating live functionality without WebSocket server

Digital Blueprinting with Kiro's Spec-Driven Development

Lewis Sawe — Thu, 17 Jul 2025 11:14:26 +0000

One of Kiro’s true power lies in its spec-driven development approach, a structured methodology designed to transform vague ideas into code with clarity and consistency. We will walk through how to leverage core spec files that is requirements.md, design.md, and tasks.md

Why Spec-Driven Development?

Traditional development often involves jumping straight into code, leading to scope Creep with requirements change mid development, misunderstandings with developers and stakeholders aren't on the same page, documentation Drift as Code evolves, but the docs don't. "Vibe Coding" AI generates code, but without a clear architectural vision.

Kiro seeks to combats these issues by establishing a clear, AI parsable contract for your project from the outset. This allows it to act as a true copilot, ensuring your components align with your overall vision.

I am going to demonstrate creating a Spec documents, through the creation of a simple stick fighting game.

Step 1: Defining Your Vision with `requirements.md`

This is where your project begins. This is your single source of truth for what your system needs to do, leveraging this file to generate user stories, acceptance criteria, and a foundational understanding of your application.

How to Implement It:

Start with Core Gameplay: Begin with a clear statement of what makes your fighting game unique.

A web-based stickman fighting game where players control stick figure characters 
in combat scenarios. The game will feature simple controls, engaging combat mechanics, 
and smooth animations to provide an entertaining fighting experience directly in 
the browser.

Break Down into User Stories (EARS Notation Recommended): Use the EARS (Easy to Understand, Atomic, Readable, Specific) notation or a similar structured format to define individual features from a user's perspective. Include clear acceptance criteria.

## Requirements

### Requirement 1

**User Story:** As a player, I want to control a stickman character with keyboard inputs, so that I can move and perform actions in the fighting arena.

#### Acceptance Criteria

1. WHEN the player presses arrow keys THEN the stickman SHALL move left, right, jump, or crouch accordingly
2. WHEN the player presses attack keys THEN the stickman SHALL perform punch or kick animations
3. WHEN the player presses block key THEN the stickman SHALL enter defensive stance
4. WHEN multiple keys are pressed simultaneously THEN the system SHALL handle combination moves appropriately

### Requirement 2

**User Story:** As a player, I want to engage in combat with an opponent, so that I can experience competitive fighting gameplay.

#### Acceptance Criteria

1. WHEN two stickman characters are in proximity THEN attacks SHALL be able to connect and deal damage
2. WHEN a character's health reaches zero THEN the system SHALL declare the opponent as winner
3. WHEN an attack connects THEN the system SHALL provide visual feedback and reduce target's health
4. WHEN characters collide THEN the system SHALL handle collision detection accurately

### Requirement 3

**User Story:** As a player, I want to see smooth animations and visual effects, so that the fighting feels responsive and engaging.

#### Acceptance Criteria

1. WHEN a character performs any action THEN the system SHALL display appropriate stick figure animations
2. WHEN attacks connect THEN the system SHALL show impact effects or particle effects
3. WHEN characters move THEN the animations SHALL be fluid at 60 FPS or higher
4. WHEN the game runs THEN all animations SHALL be synchronized with game logic

### Requirement 4

**User Story:** As a player, I want a simple game interface, so that I can easily understand the game state and controls.

#### Acceptance Criteria

1. WHEN the game loads THEN the system SHALL display health bars for both players
2. WHEN the game is in progress THEN the system SHALL show current round information
3. WHEN the game ends THEN the system SHALL display winner announcement and restart option
4. WHEN the player needs help THEN the system SHALL provide accessible control instructions

### Requirement 5

**User Story:** As a player, I want the game to work reliably in my web browser, so that I can play without technical issues.

#### Acceptance Criteria

1. WHEN the game loads in a modern web browser THEN it SHALL run without requiring additional plugins
2. WHEN the browser window is resized THEN the game SHALL maintain proper aspect ratio and playability
3. WHEN the game runs for extended periods THEN performance SHALL remain stable without memory leaks
4. WHEN network connectivity is poor THEN the game SHALL still function as a local experience

Clarify Technical Requirements: Include platform compatibility and performance targets.

## Technical Requirements

### Platform Support
1. Work on modern web browsers (Chrome, Firefox, Safari, Edge)
2. Responsive design that adapts to different screen sizes
3. Mobile device support

### Performance
1. Maintain 60 FPS on mid-range devices
2. Optimize animations and physics calculations
3. Efficient memory usage

### Technology Stack
1. HTML5, CSS3, and JavaScript
2. Canvas or WebGL for rendering
3. Potential use of game frameworks (optional)

Step 2: Architecting Your Game with `design.md`

With clear requirements, we move into the design phase. The design.md file (or a collection of design files within a design/ directory) outlines how your system will meet those requirements. This is where you define architecture, data models, API schemas, and more.

How to Implement It:

High-Level Architecture: Describe the overall system components

# Design Document

## Overview

The stickman fighting game will be built as a client-side web application using HTML5 Canvas and JavaScript. The architecture follows a component-based game engine pattern with clear separation between rendering, game logic, input handling, and animation systems. The game will use a fixed timestep game loop for consistent physics and animation, with interpolation for smooth 60 FPS rendering.

## Architecture

### Core Architecture Pattern
- **Entity-Component System (ECS)**: Characters and game objects are entities with components for position, health, animation, collision, etc.
- **Game Loop**: Fixed timestep update loop with variable timestep rendering
- **State Management**: Finite state machine for game states (menu, playing, paused, game over)
- **Event-Driven Input**: Keyboard input system with event queuing and combination detection

### Technology Stack
- **Rendering**: HTML5 Canvas 2D API for graphics and animations
- **Language**: Vanilla JavaScript (ES6+) for maximum browser compatibility
- **Build**: No build system required - direct HTML/JS/CSS files
- **Animation**: Custom sprite-based animation system with frame interpolation

Components and Interfaces: Characters and game objects are entities with components for position, health, animation, collision, etc

## Components and Interfaces

### Game Engine Core

```

javascript
// Main game engine interface
class GameEngine {
  constructor(canvas)
  start()
  stop()
  update(deltaTime)
  render(interpolation)
}

// Character entity with component composition
class Character {
  constructor(x, y, playerIndex)
  // Components
  position: PositionComponent
  health: HealthComponent
  animation: AnimationComponent
  collision: CollisionComponent
  input: InputComponent
}

// Character states for animation and behavior
enum CharacterState {
  IDLE, WALKING, JUMPING, CROUCHING, 
  PUNCHING, KICKING, BLOCKING, HURT, DEAD
}

class InputManager {
  constructor()
  bindKeys(playerIndex, keyMapping)
  getInputState(playerIndex)
  handleKeyDown(event)
  handleKeyUp(event)
}

// Input mapping for two players
const PLAYER_CONTROLS = {
  PLAYER1: { left: 'ArrowLeft', right: 'ArrowRight', up: 'ArrowUp', down: 'ArrowDown', punch: 'KeyZ', kick: 'KeyX', block: 'KeyC' },
  PLAYER2: { left: 'KeyA', right: 'KeyD', up: 'KeyW', down: 'KeyS', punch: 'KeyJ', kick: 'KeyK', block: 'KeyL' }
}

class AnimationManager {
  constructor()
  createAnimation(name, frames, duration, loop)
  playAnimation(character, animationName)
  update(deltaTime)
}

class SpriteRenderer {
  constructor(canvas)
  drawStickman(character, interpolation)
  drawUI(gameState)
  drawEffects(effects)
}

Error handling, Testing strategy and Implementation Architecture


markdown

## Error Handling

### Input Error Handling
- **Invalid Key Combinations**: Ignore conflicting inputs (e.g., left + right simultaneously)
- **Rapid Key Presses**: Implement debouncing for attack inputs to prevent spam
- **Browser Compatibility**: Feature detection for Canvas API and fallback messaging

### Game Logic Error Handling
- **Animation Errors**: Default to idle animation if animation file missing or corrupted
- **Collision Edge Cases**: Boundary checking to prevent characters from moving outside arena
- **Performance Degradation**: Frame rate monitoring with automatic quality reduction if needed

### Rendering Error Handling
- **Canvas Context Loss**: Detect context loss and reinitialize rendering system
- **Memory Leaks**: Proper cleanup of animation frames and event listeners
- **Browser Resize**: Responsive canvas sizing with aspect ratio preservation

## Testing Strategy

### Unit Testing
- **Character Movement**: Test position updates, boundary constraints, and state transitions
- **Collision Detection**: Verify hitbox calculations and attack/defense interactions
- **Animation System**: Test frame progression, loop behavior, and state synchronization
- **Input Processing**: Validate key mapping, combination detection, and player separation

### Integration Testing
- **Game Loop**: Test update/render cycle timing and state consistency
- **Character Interactions**: Verify combat mechanics, health reduction, and win conditions
- **UI Integration**: Test health bar updates, game state displays, and user feedback

### Performance Testing
- **Frame Rate Consistency**: Monitor FPS under various load conditions
- **Memory Usage**: Track memory allocation and garbage collection patterns
- **Browser Compatibility**: Test across Chrome, Firefox, Safari, and Edge

### Visual Testing
- **Animation Smoothness**: Verify 60 FPS rendering and frame interpolation
- **Collision Feedback**: Test visual effects for hits, blocks, and impacts
- **UI Responsiveness**: Ensure interface elements update correctly with game state

Implementation Architecture

File Structure


markdown
stickman-fighting-game/
├── index.html
├── css/
│   └── game.css
├── js/
│   ├── engine/
│   │   ├── GameEngine.js
│   │   ├── InputManager.js
│   │   └── AnimationManager.js
│   ├── entities/
│   │   ├── Character.js
│   │   └── Effect.js
│   ├── systems/
│   │   ├── PhysicsSystem.js
│   │   ├── CollisionSystem.js
│   │   └── RenderSystem.js
│   └── main.js
└── assets/
    └── sounds/ (optional for future enhancement)

Rendering Pipeline

Clear Canvas: Clear previous frame
Background: Draw arena background
Characters: Render stickman sprites with current animation frame
Effects: Draw particle effects and impact animations
UI: Overlay health bars, round info, and game state
Debug: Optional collision box visualization

Step 3: Executing the Plan with `tasks.md`

This is where Kiro breaks down the design into actionable, atomic steps for implementation. tasks.md typically isn't something you write from scratch, which it then generates it based on your requirements.md and design.md. Your role here is to review, refine, and track progress.

How to Leverage It:

Review Generated Tasks: Once you've created requirements and design documents, break them down into specific tasks:


markdown
# Implementation Plan

- [ ] 1. Set up project structure and core HTML/CSS foundation
  - Create index.html with canvas element and basic page structure
  - Create game.css with responsive canvas styling and UI layout
  - Set up file directory structure for organized code modules
  - _Requirements: 5.1, 5.2_

- [ ] 2. Implement core game engine and loop system
  - Create GameEngine.js with fixed timestep game loop and requestAnimationFrame
  - Implement game state management (MENU, PLAYING, PAUSED, GAME_OVER)
  - Add canvas context initialization and error handling for context loss
  - Write unit tests for game loop timing and state transitions
  - _Requirements: 5.1, 5.3, 3.3_

- [ ] 3. Build input management system
  - Create InputManager.js with keyboard event handling and key mapping
  - Implement two-player control schemes with configurable key bindings
  - Add combination key detection and input debouncing for attacks
  - Write unit tests for input processing and player separation
  - _Requirements: 1.1, 1.2, 1.3, 1.4_

- [ ] 4. Create character entity and component system
  - Implement Character.js with position, health, and state components
  - Create character state enumeration (IDLE, WALKING, JUMPING, etc.)
  - Add character initialization with starting positions and properties
  - Write unit tests for character creation and component management
  - _Requirements: 1.1, 2.2_

- [ ] 5. Implement basic character movement and physics
  - Add movement logic for left/right walking and jumping mechanics
  - Implement gravity system and ground collision detection
  - Create boundary constraints to keep characters within arena
  - Write unit tests for movement calculations and boundary checking
  - _Requirements: 1.1, 5.2_

Starting your Implementation Plan

The Power of Synchronization: Living Documentation

One of Kiro's most powerful features is its ability to keep these specification files in sync with your codebase.

Changes in Code -> Updates in Specs: If you decide to change an API endpoint directly in your code, then it prompts you to update design.md accordingly, or even suggest the change automatically.
Changes in Specs -> Updates in Code: If you modify a data model in design.md, it then can suggest or even apply the necessary code changes (e.g., updating TypeScript interfaces, DynamoDB table definitions).

This "living documentation" ensures that your specifications always reflect the current state of your application, reducing maintenance overhead and eliminating the classic problem of outdated documentation.

Embracing Spec-Driven Workflow

Mastering requirements.md, design.md, and tasks.md is key to harnessing the full potential of Kiro. By embracing this structured, spec-driven workflow, you'll benefit from Increased Clarity where everyone is aligned on what's being built and how. Reduced Errors you can validate code against the specs, catching inconsistencies early. Faster Development of accurate code and infrastructure from precise instructions, and your documentation stays evergreen, making future changes easier.

Join me on this journey as I create my stick game, step by step, spec by spec, and discover the benefits of intentional, efficient development with Kiro.

Lets Connect - Lewis Sawe: LinkedIn

Buy me coffee ☕