DEV Community: Linford

I Built an AI Security Coach for People Who Can't Afford to Get Hacked

Linford — Fri, 29 May 2026 08:53:34 +0000

CyberBuddy is a gamified Android app that guides everyday users through personal cybersecurity using a Gemini A2A agent. Here's the full build story.

𝗜 𝗯𝘂𝗶𝗹𝘁 𝘁𝗵𝗶𝘀 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝘀𝗼𝗺𝗲𝗼𝗻𝗲 𝗮𝘀𝗸𝗲𝗱 𝗺𝗲 𝗮 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗜 𝗰𝗼𝘂𝗹𝗱𝗻'𝘁 𝗮𝗻𝘀𝘄𝗲𝗿 𝗶𝗻 𝗮 𝗪𝗵𝗮𝘁𝘀𝗔𝗽𝗽 𝗺𝗲𝘀𝘀𝗮𝗴𝗲.

"How do I know if I am safe online?"

She was a student I mentor through Linfy Academy in Strand, Cape Town. Smart. Motivated. Using the same password for her email, her banking app, and her school portal.

There was no simple answer. So I built one.

𝗪𝗵𝗮𝘁 𝗶𝘀 𝗖𝘆𝗯𝗲𝗿𝗕𝘂𝗱𝗱𝘆?

CyberBuddy is an Android app that acts as a personal cybersecurity coach.

It guides users through building their own 𝗣𝗲𝗿𝘀𝗼𝗻𝗮𝗹 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗣𝗹𝗮𝗻 (PSP) - covering password health, device security, and two-factor authentication. It tracks daily security habits through streaks and badges. And it monitors whether your email has appeared in known data breaches.

The AI coaching layer is powered by 𝗚𝗲𝗺𝗶𝗻𝗶 via an 𝗔𝟮𝗔 (𝗔𝗴𝗲𝗻𝘁-𝘁𝗼-𝗔𝗴𝗲𝗻𝘁) 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. More on that below.

𝗪𝗵𝗼 𝗜𝘁'𝘀 𝗙𝗼𝗿

Most cybersecurity tools are built for enterprises with IT departments and budgets.

CyberBuddy is built for three people:

The 𝘀𝘁𝘂𝗱𝗲𝗻𝘁 who just got their first smartphone
The 𝗲𝗱𝘂𝗰𝗮𝘁𝗼𝗿 managing a WhatsApp group for parents
The 𝗽𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹 who knows their passwords are a problem but has no idea where to start

These are the people who get phished. These are the people whose credentials appear in breach databases. These are the people nobody is building for.

𝗧𝗵𝗲 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸

Language:       Kotlin
UI:             Jetpack Compose (Material3)
Architecture:   Clean Architecture + MVVM
Database:       Room (offline-first)
DI:             Hilt
AI Layer:       Gemini API via A2A Protocol
Testing:        JUnit5 + Kotest (property-based)
Dev Tools:      Gemini in Android Studio + Claude Code (JetBrains)

The architecture was designed to be offline-first from day one. Room handles all local state. Gemini enhances the experience - it does not gate it.

𝗧𝗵𝗲 𝗔𝟮𝗔 𝗟𝗮𝘆𝗲𝗿 (𝗧𝗵𝗶𝘀 𝗶𝘀 𝘁𝗵𝗲 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗶𝗻𝗴 𝗽𝗮𝗿𝘁)

Instead of calling the Gemini API directly from every screen, I built a 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗼𝗿 class that acts as the host agent.

It delegates structured tasks to a Gemini-powered coaching agent using Google's A2A protocol.

data class SecurityAgentTask(
    val taskType: String,     // "psp_guidance" | "breach_explain" | "daily_tip"
    val userRole: String,     // "student" | "professional" | "educator"
    val context: Map<String, Any>
)

The benefit: the AI backend is completely decoupled from the Android layer. I can upgrade the Gemini model, swap the agent, or change the coaching logic without touching a single Compose screen.

That is the architectural decision I am most proud of.

𝗪𝗵𝗮𝘁 𝗪𝗲𝗻𝘁 𝗪𝗿𝗼𝗻𝗴

𝟭. 𝗔 𝗽𝗿𝗼𝗽𝗲𝗿𝘁𝘆-𝗯𝗮𝘀𝗲𝗱 𝘁𝗲𝘀𝘁 𝘁𝗵𝗮𝘁 𝘁𝗮𝘂𝗴𝗵𝘁 𝗺𝗲 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗮𝗻𝘆 𝗹𝗶𝗻𝘁𝗲𝗿.

I was using Arb.string(minSize = 1, maxSize = 100) to generate random test inputs for the source field in breach results. The test asserted breach.source.isNotBlank(). It kept failing.

Turns out Kotest's string generator happily produces strings made entirely of whitespace. A string of spaces has a length of 1. It is not blank. Except it is.

One line fixed it:

val arbNonEmptyString = Arb.string(minSize = 1, maxSize = 100).filter { it.isNotBlank() }

74 tests passed before that fix. 75 after.

𝟮. 𝗔𝗜 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀 𝘄𝗮𝗻𝘁 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝘃𝗶𝘁𝘆. 𝗬𝗼𝘂𝗿 𝘂𝘀𝗲𝗿𝘀 𝗱𝗼𝗻'𝘁 𝗮𝗹𝘄𝗮𝘆𝘀 𝗵𝗮𝘃𝗲 𝗶𝘁.

Designing for offline-first while shipping AI features is a real tension. My solution: Room is the source of truth. Gemini is the upgrade. If the agent call fails, the app still works.

𝗧𝗵𝗲 𝗗𝗲𝘃 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄 𝗧𝗵𝗮𝘁 𝗖𝗵𝗮𝗻𝗴𝗲𝗱 𝗛𝗼𝘄 𝗜 𝗕𝘂𝗶𝗹𝗱

I used two AI tools at different stages:

𝗚𝗲𝗺𝗶𝗻𝗶 𝗶𝗻 𝗔𝗻𝗱𝗿𝗼𝗶𝗱 𝗦𝘁𝘂𝗱𝗶𝗼 for scaffolding. Boilerplate, A2A setup, Compose screens. Gemini knows the Android ecosystem deeply and moves fast.

𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 (𝗝𝗲𝘁𝗕𝗿𝗮𝗶𝗻𝘀 𝗽𝗹𝘂𝗴𝗶𝗻) for polish. Edge cases, accessibility, ProGuard rules, test coverage gaps. Claude reads the full codebase and reasons about architecture, not just the current file.

Neither tool replaced thinking. Both tools compressed the time between thinking and shipping.

Before either tool touched the codebase, I wrote three spec files: mission.md, techstack.md, and roadmap.md. That is what kept the agents grounded.

𝗪𝗵𝗮𝘁'𝘀 𝗡𝗲𝘅𝘁

CyberBuddy is being presented at 𝗣𝗲𝘁 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀: 𝗧𝗵𝗲 𝟮𝟬𝟮𝟲 𝗘𝗱𝗶𝘁𝗶𝗼𝗻 - GDG Cape Town's mid-year showcase on 30 June 2026.

After that: Play Store release, closed beta with users from Strand and the IUS Africa youth network, and Supabase MCP integration for cross-device PSP sync.

𝗜𝗳 𝘆𝗼𝘂 𝗮𝗿𝗲 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗳𝗼𝗿 𝗽𝗲𝗼𝗽𝗹𝗲 𝘄𝗵𝗼 𝗻𝗲𝗲𝗱 𝗶𝘁, 𝗞𝗲𝗲𝗽 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴.

El Roi sees the work.

𝗟𝗶𝗻𝗳𝗼𝗿𝗱 𝗠𝘂𝘀𝗶𝘆𝗮𝗺𝗯𝗼𝗱𝘇𝗮

Founder, Linfy Tech Solutions | Strand, Cape Town

How Kiro Specs Made Me Ship a Full-Stack AI App in 48 Hours

Linford — Fri, 05 Dec 2025 00:23:22 +0000

How Kiro Specs Made Me Ship a Full-Stack AI App in 48 Hours

The Challenge

I had 48 hours to build NecroNet-a full-stack AI application that resurrects dead web artifacts (Flash, old HTML) into an interactive museum. That's:

React + Next.js frontend
FastAPI backend
Supabase database
AWS S3 storage
ElevenLabs voice integration
Ruffle emulator for Flash playback

48 hours. Solo developer. This needed serious automation.

The Solution: Kiro Specs

Instead of jumping into code, I spent 30 minutes writing /resurrection.spec.md:

Project: NecroNet
Goal: Resurrect obsolete web artifacts into an interactive museum
Stack: FastAPI, Next.js, Supabase, S3, ElevenLabs
Pipeline:

User uploads artifact → Backend detects MIME type

Migration service → Ruffle for Flash, sanitize HTML

AI narration → ElevenLabs generates ghost curator voice

Museum exhibit → Published to gallery
Database:

artifacts table (id, name, type, storage_url, status, ghost_narration_url)

migration_logs table (artifact_id, event, timestamp)

Then I gave Kiro this spec and asked: "Generate the database schema, API endpoints, and migration pipeline based on this."

Result? Kiro generated code that actually fit together. No refactoring. No "wait, this doesn't match the schema." It just worked because Kiro understood the entire system upfront.

Why Specs Beat Vibe Coding

Vibe Coding: "Make me a file upload endpoint"

Kiro generates a handler function
You paste it in
You realize it doesn't know about your S3 bucket configuration
You ask Kiro again: "Update it to use AWS"
You debug for 30 minutes
It still doesn't integrate with your migration pipeline

Spec-Driven: Define the contract upfront

Kiro sees the full architecture
Generated code respects the database schema
Endpoints return the right data types
Integration points are already designed
Code ships with 80% fewer surprises

The Steering Docs Cherry on Top

I also created /curator.steering.md:

Curator Steering
Voice: Spooky but Professional
Tone: Witty, preservationist, theatrical
Examples:

"This Flash game was released in 2003 during the golden age of Newgrounds..."

"The original devs are probably on LinkedIn now. 🎃"

"Museum note: This artifact demonstrates early web creativity..."

text

Every time Kiro wrote UI copy or generated the ElevenLabs narration prompt, it followed this steering. Result: the entire app had one cohesive personality. Not generic. Not "meh." Haunted.

The Numbers

Time to MVP: 6 hours (thanks to spec-driven generation)
Time debugging integration bugs: ~30 minutes (Kiro already aligned everything)
Lines of code I had to rewrite: < 100 out of 5000+
Coffee cups: 4 (could have been 8 with vibe coding)

What I Learned

Specs are documentation AND contracts. Kiro uses them to generate aligned code. So do future developers reading your codebase.
Steering matters. Without it, every generated artifact is a snowflake. With it, your product has a voice.
Context is king. Vibe coding = asking for help with no context. Specs = walking someone through your entire system first.

The Bottom Line

If you are shipping under deadline (or just shipping, period), stop vibe coding. Write a spec. Give it to Kiro. Watch your project assemble itself.

The future of development isn't "write better prompts." It is "write better specs."

kiro #AI #Development #Automation #Hackathon

Excited to share our Echo Location Project, created together with @williamhenryking for the Google AI Studio Multimodal Challenge! #devchallenge #googleaichallenge #ai #gemini

Linford — Sun, 14 Sep 2025 22:25:28 +0000

Google AI Challenge Submission

William Henry King

Sep 14 '25

Echo Location Project [Google AI Studio Multimodal Challenge]

#devchallenge #googleaichallenge #ai #gemini

Comments 3

3 min read