DEV Community: Shakiran Nannyombi

What I learned building a real talent funnel from SRS and Figma to QA, handover, and closing without a perfect ending.

Shakiran Nannyombi — Tue, 04 Aug 2026 10:34:20 +0000

Hey everyone,

If you followed my weekly Hashnode series, you already know the short version: eight weeks, one real product, a lot of shipping, and a quieter finale than I expected.

This post is the longer reflection on the whole arc in one place.

Series link: My Software Engineering Internship Journey

How it started

Week 1 did not feel like “writing production code on day one.” It felt like orientation into a different kind of seriousness.

We were not building toys. We were joining a live talent funnel product, the Talent Funnel, where candidates move through discovery, onboarding, assessments, and interviews, while admins need tools they can trust.

Before the flashy UI work, there was the quieter foundation work: requirements, diagrams, architecture conversations, and learning how classroom theory behaves once real stakeholders and real timelines enter the room.

That first week taught me something I kept rediscovering: industry work is less about knowing everything, and more about becoming useful quickly without breaking what already exists.

The middle: building for real users

Across the middle weeks, the work widened fast.

We moved through:

requirements and data architecture
monorepo structure and type-safe environments
custom auth and onboarding flows
candidate home hubs, assessment surfaces, and UI states
landing pages, hierarchy polish, and painful but necessary rework
admin portals, route hardening, and access control

Some weeks felt like invention. Others felt like correction.

Week 5 especially stuck with me: being right about a UI direction did not always protect the work from being redone. Branch overlap, merge calls, and scope cleanup taught me more than the feature itself. That was uncomfortable. It was also one of the most useful lessons of the internship.

By Weeks 6 and 7, the focus shifted again from “can we build this?” to “can this survive without scaffolding?” We migrated out of temporary paths, cleaned legacy naming, unified branding, hardened staff access, improved analytics and candidate summaries, and started thinking about handover as part of engineering, not as an afterthought.

What the work actually looked like

If I had to name the through-line of my internship, it would be consistency.

Not just visual consistency. Product consistency.

Making routes make sense. Making emails point to real places. Making settings and permissions match how staff actually work. Making responsive layouts behave on phones, not only on laptops. Making localization expose every missing string before a user does. Shipping in related batches instead of one giant pile that nobody can review.

Those details do not always look impressive in a weekly update. They are what make a product feel intentional.

How it ended

Week 8 was the finale: QA, test documentation, and project handover.

As a team, we closed the project. We did not get full client feedback before we wrapped. That is the honest part. Timelines move. Stakeholders are busy. Final reviews do not always land when you hope they will.

Even so, we know they appreciated the work. That appreciation showed up in the collaboration, the trust, and the way the product kept moving forward with us. A long written review would have been nice. Knowing the work mattered still counts.

Closing without a cinematic ending taught me something I did not expect to learn so clearly:

Finishing well is not the same as finishing loudly.

Sometimes a good ending looks like regression checks, documented test cases, known issues written down honestly, and a handover package that lets the next engineers continue without reconstructing the story from commit messages alone.

What I take with me

I leave with more than a portfolio of screens.

I leave with better instincts around:

shipping in related batches
treating documentation as part of delivery
seeing responsive UI, localization, and access control as product integrity, not polish
treating merge conflicts, CI surprises, and overlapping branches as the work itself
measuring progress not only by what I can build, but by whether someone else can continue after me

Somewhere between Week 1 and Week 8, I stopped thinking of an internship as a sequence of tasks. I started seeing it as practice in becoming leaveable, leaving systems, decisions, and context in a state where the team can keep going.

If you are starting your own internship

A few things I would tell my Week 1 self:

Ask for context early. Why a decision exists matters as much as how to implement it.
Expect rework. Being right once does not freeze the product forever.
Write things down while they are still fresh. Future you and future teammates need that.
Care about the unglamorous paths: empty states, mobile, permissions, broken links.
Learn to close. Shipping is not only starting features. It is also QA, honesty about risk, and handover.

Closing

Internships end. Products keep going.

I am proud of what we built, proud of how we closed, and grateful for the team, mentors, and trust that made the experience real.

If you want the week-by-week story, start here:
My Software Engineering Internship Journey

Thanks for reading.

From Idea to Production: Building a Spider-Man Tic-Tac-Toe Game with Kiro

Shakiran Nannyombi — Thu, 30 Jul 2026 06:31:50 +0000

AI coding tools are changing how we build software, but I wanted to explore what it looks like to use AI as part of the software engineering process, not just for generating code.

In my latest article, I walk through building a Tic-Tac-Toe game with Kiro, covering:

Spec-Driven Development
Steering
Hooks
Model Context Protocol (MCP)
Building the application step by step
Lessons learned from using Kiro in a live student workshop

I also share some honest reflections on the experience and a few areas where I think Kiro can continue to improve.

Read the article here:
https://shakiran.hashnode.dev/building-tic-tac-toe-game-with-kiro

I'd love to hear your thoughts! Have you tried Kiro or another AI-powered IDE? What has your experience been like?

7 Weeks, 0 Sandboxes, and a Lot of Code

Shakiran Nannyombi — Mon, 27 Jul 2026 08:13:29 +0000

Lessons From My Software Engineering Internship

When I started my software engineering internship, I thought most of my time would be spent writing straightforward UI components and fixing minor CSS bugs.

I was wrong.

Over the last 7 weeks, I went from breaking down raw Software Requirements Specifications (SRS) to building custom authentication gates, hardening production routes, refactoring monorepo architectures, and managing localized multi-language state persistence.

If you’re currently a student, a self-taught dev preparing for your first role, or just love reading about real-world engineering trade-offs, here are the biggest lessons I learned on the front lines—and why writing clean handovers matters just as much as writing clean code.

1. "Working Code" Isn't Always "Good Code"

In school or side projects, once the feature works on localhost:3000, you ship it and call it a day. In production, that’s where the real work begins.

During Week 5, I built a functional feature that met every technical specification. But after a merge call and design review, we realized the user hierarchy was cluttered and lacked clear ownership boundaries. I had to tear down hours of working UI to rebuild a streamlined, single-contrast CTA layout.

Lesson: Being technically right doesn't mean you're done. Engineering is about clarity, subtraction, and user flow—not just passing tests.

2. Moving Out of the Sandbox (Role-Based Access & Route Guards)

Moving code from a temporary /v2 sandbox folder into /admin primary route directories requires serious security considerations. You can't just hide a button with display: none and assume candidates won't find staff-only portals.

Using tools like Clerk Auth, I implemented strict Staff Access Route Guards to separate identity pools. Candidate roles attempting to access internal management paths hit instant, secure access-denied barriers.

3. State Persistence is Harder Than It Looks

We started by storing quick form inputs in browser localStorage. It worked great for local testing, but scaling an admin console requires converting client-side drafts into live database synchronization.

Handling state transitions, preventing data loss during multi-step onboarding forms, and ensuring seamless API roundtrips taught me more about frontend data flow than any textbook ever could.

4. The Power of Clean Handover Architectures

As my internship reached its final week, the focus shifted from building shiny new features to stabilization and documentation:

Purging Technical Debt: Tracked down legacy file references, standardized component folders, and unified global design packages.
Cleaning Git History: Grouped commits into modular, scoped batches and configured strictly enforced .gitignore parameters (e.g., locking down uidemo/* mock folders).
Documenting Edge Cases: Cataloged setup sequences, API contracts, and known failure modes so the next developer could take over without missing a beat.

Writing clean documentation gives your team absolute clarity and proves you operate with a senior engineering mindset.

Follow the Full Week-by-Week Breakdown!

I’ve been documenting every single week of this journey—complete with technical diagrams, system architecture decisions, Figma workflows, and honest reflections on my personal blog.

If you want to read the deep dives, check out the full series here:

👉 My Software Engineering Internship Journey on Hashnode

Here's a quick peek at what's inside the series:

Week 1: Surviving Week 1: Classroom Theory to Real-World SRS & Use Cases
Week 2: Data Architecture & Translating Requirements into Figma Design Systems
Week 3: Architecting a Monorepo, Custom Auth, and Type-Safe Dev Environments
Week 4: Engineering Frontend Funnels & LocalStorage Persistence
Week 5: When Being Right Still Means Redoing the Work (Hierarchy by Subtraction)
Week 6: Beyond the Sandboxes: Hardening Routes, Admin Portals, & Server States
Week 7: The Final Polish: Purging Debt, Handover Architectures, & Closing the Loop

Coming Up: The Final Reflections & Retrospective

As this 7-week sprint comes to an end, I’m putting the finishing touches on a comprehensive retrospective post dropping soon on Hashnode.

Here is a quick preview of what I’ll be covering in the series finale:

The Reality of Engineering Offboarding: What transferring codebase ownership to full-time engineering teams actually looks like in practice.

Key Non-Technical Takeaways: Communication loops, managing scope creep, and navigating merge calls under pressure.

Advice for Future Interns: The exact tools, mindsets, and workflows that made the biggest impact throughout the project.

Stay tuned—the final reflections drop next week!

To everyone wrapping up internships or preparing for junior developer roles: What is your go-to strategy for leaving behind clean code documentation? Do you prefer inline commenting, detailed README files, or live loom walkthroughs?

Drop your thoughts in the comments below! 👇

🚀 How We Organized the Build with the Gemma Hackathon at Makerere University

Shakiran Nannyombi — Tue, 21 Jul 2026 09:08:23 +0000

Over the past few weeks, our team at GDG on Campus Makerere planned and hosted the Build with Gemma Hackathon, bringing together students and developers to build AI-powered solutions using Google's open Gemma models.

The journey involved:

Getting our Kaggle competition approved
Running a pre-hackathon workshop
Securing partnerships and venue support
Managing registrations and participant engagement
Organizing judging and project submissions

The event welcomed 30+ participants, produced 11 project submissions, and crowned 3 winning teams building solutions in education, healthcare, sustainability, and AI agents.

I wrote a detailed reflection on everything we learned—from planning challenges to event-day execution and the lessons we'll carry into future community events.

📖 Read the full story:
Building a Hackathon from the Ground Up

I'd love to hear from other community organizers:
What has been your biggest lesson from running a hackathon or developer event?

BuildWithGemma #GoogleAI #GDG #GDGOnCampus #Hackathon #CommunityBuilding #ArtificialIntelligence #Kaggle #MakerereUniversity #OpenSourceAI #DevCommunity

When Being Right Still Means Redoing the Work

Shakiran Nannyombi — Mon, 13 Jul 2026 06:53:05 +0000

Week 5 Internship Update

As software engineers, we are often taught that code is a pure meritocracy. If your logic passes local compilation, it should ship, right?

This week taught me that team dynamics, ownership boundaries, and deployment hygiene operate on a completely different set of rules. I had to face a massive branch overlap conflict where my feature code clashed with a parallel teammate's sprint. The fastest path to production? Redoing and rewriting my branch scope entirely.

Beyond git refactors, this week I dived deep into structural UI refinement for our Talent Funnel platform:

Redesigning high-impact landing viewports (subtracting fluff for visual hierarchy).
Splitting dense forms into intuitive multi-step wizard layouts.
Overhauling account security panels and fixing Next.js build-time API creation dependencies.

Read about the balance between technical hierarchy and development humility in my latest article! 👇

My Software Engineering Internship Journey

SoftwareEngineering #WebDevelopment #Frontend #MaterialUI #NextJS #TechInternships #CareerGrowth

From an Idea to a Hackathon: Lessons from Organizing Build with AI Makerere

Shakiran Nannyombi — Mon, 29 Jun 2026 11:12:43 +0000

After months of planning, countless emails, sponsor outreach, community workshops, and late nights, we successfully hosted the Build with AI Makerere Hackathon in partnership with Google Build with AI and Major League Hacking (MLH).

The event brought together student developers from universities across Uganda to build AI-powered solutions addressing real-world challenges using Gemini, Google AI Studio, and Google Cloud.

Along the way, I learned invaluable lessons about:

Building partnerships and securing sponsorships
Planning and organizing a hackathon from scratch
Leading a growing developer community
Navigating unexpected challenges
💡 Creating an environment where students could innovate and learn

This experience reminded me that community leadership isn't about having everything figured out—it's about learning, adapting, and bringing people together around a shared vision.

I've written a detailed reflection covering the journey, the challenges, the impact, and the lessons I'll carry into future events.

👉 Read the full story here: build-with-ai-makerere-hackathon

I'd love to hear your thoughts or learn about your own experiences organizing community events!

BuildWithAI GoogleAI GDG @mlhacks Hackathon DeveloperCommunity ArtificialIntelligence OpenSource CommunityBuilding Leadership

From Classroom to Real-World: Surviving Week 1 of My Software Engineering Internship

Shakiran Nannyombi — Wed, 24 Jun 2026 14:56:53 +0000

Week 1 of My Software Engineering Internship

This week gave me a reality check.

I went from building side projects where I made all the decisions to working on a real team, attending client meetings, writing requirements documents, mapping use cases, and learning that software development starts long before the first line of code.

A few things that surprised me:

Having a classmate become my team lead 👀
Discovering how much time goes into planning before coding
Learning that understanding clients and constraints is just as important as understanding technology
Realizing that teamwork is a skill you have to actively practice

I wrote about the challenges, lessons, and mindset shifts from my first week as an intern.

Read the full story: my-software-engineering-internship

This is the first post in a series where I'll be sharing honest reflections from my internship journey—from requirements and architecture to design, development, and everything in between.

What was the biggest surprise during your first internship or software engineering job?

REST Brain vs Procedure Brain

Shakiran Nannyombi — Wed, 24 Jun 2026 14:53:46 +0000

REST Brain vs Procedure Brain

Today I had one of the most valuable architecture discussions I've been part of.

I joined a monorepo expecting the usual:

Frontend → API Server → Database

Instead, I found an in-process procedural RPC layer with no separate API server.

My first reaction was:

What even is this?

After a real debate about tradeoffs, I finally understood the problem it was solving—and it challenged some assumptions I had about what a backend has to look like.

I wrote about the experience, the tradeoffs, and the shift from REST brain to procedure brain.

Read here: rest-brain-vs-procedure-brain

What's an architecture pattern that felt wrong at first but made sense once you understood the problem it was solving?

A Developer’s Lesson on Feedback

Shakiran Nannyombi — Tue, 21 Apr 2026 06:49:21 +0000

I built my first React Native MVP for a startup pitch.

I was proud of it… until the feedback started coming in.

Instead of handling it, I passed it to a junior teammate.

At the time, I told myself:
“I just don’t like being told what to do.”

But the truth?

I was tired.
I felt unappreciated.
And I was too attached to my work.

Later that day, I stepped away, came back, and realized something:

The problem wasn’t the feedback.
It was my state when I received it.

As developers, we think we’re logical—but feedback hits your ego, your energy, and your identity.

That’s why we react instead of process.

This was a tough lesson for me, especially after realizing it’s a pattern that’s cost me opportunities before.

I wrote a full breakdown on:

Why devs resist feedback
how ego + burnout affect us
and how to actually handle it better

Read it here 👇
the-code-wasn-t-the-problem-my-state-was

Building Secure AI Agents with Auth0 Token Vault

Shakiran Nannyombi — Tue, 14 Apr 2026 01:55:43 +0000

How I stopped storing sensitive tokens in my database and built a security-first AI system

I built a multi-agent AI assistant that needed access to user data like Gmail, Google Calendar, and Notion.

At first, I thought I had it figured out.

I encrypted OAuth tokens myself and stored them in my database.

It worked… but something didn’t feel right.

The problem with “DIY security.”

During the Auth0 “Authorized to Act: Auth0 for AI Agents” hackathon, I took a step back and reviewed my setup.

My system (Londoolink AI) is built with FastAPI + LangGraph and generates personalized daily briefings using multiple agents:

📧 Gmail Agent
📅 Calendar Agent
📝 Notion Agent
📱 Social Agent

To do that, it relies on OAuth tokens.

And that’s where things got risky.

My original approach:

AES-256 encryption for tokens
Tokens stored in my database
Custom refresh handling

It worked… but it wasn’t scalable or truly secure.

What I realized

I was responsible for things I shouldn’t be owning:

🔐 Encryption key management
🔄 Token refresh logic
📊 Audit trails (basically none)
👀 No visibility into token usage
⚠️ No proper control for sensitive actions

In short:

I was rebuilding a security system from scratch… badly.

The switch: Auth0 Token Vault

That’s when I found Auth0 Token Vault.

And it changed everything.

Instead of managing tokens myself:

Auth0 handles token storage securely
Built-in token refresh just works
Full audit logs out of the box
Tokens never touch my database
Easy to enforce secure access patterns

It basically turns token management into a secure API call.

The result

🔒 More secure by design
📈 Easier to scale
🧾 Fully auditable
🤝 Much more user trust

Most importantly:

I stopped worrying about whether I was “doing security right” and started focusing on building features.

About the project

Londoolink AI is a multi-agent assistant that reduces information overload by generating personalized daily briefings from your connected tools.

🙌 Shoutout

Big shoutout to the Auth0 team for building tools that make secure AI development actually practical.

Read the full story

If you want the deeper breakdown, architecture details, and implementation steps, read the full post here:

Shakiran.hashnode.dev

Let’s talk

Have you built AI agents before?

How are you handling auth + token security?

I’d love to hear your approach 👇

My AI Was Smart… But Useless

Shakiran Nannyombi — Tue, 14 Apr 2026 00:42:07 +0000

I built an AI that generates daily briefings from emails, calendars, Notion, and social media.

It worked. It was fast. It was accurate.

But it had one fatal flaw:

It forgot everything.

Every session = reset.
Every user = stranger.

No memory. No context. No continuity.

Then I Fixed It

I discovered Backboard.io after an Auth0 Hackathon on Devpost, and later explored it deeper during MLH Global Hack Week: API Week 2026.

That’s when it clicked:

My AI didn’t need to be smarter. It needed memory.

What Changed Instantly

After adding memory:

My AI remembers user preferences
Conversations actually continue
Outputs feel personal, not generic

It stopped feeling like a chatbot and started feeling like an assistant.

The Real Shift

Most AI apps today are stateless. That’s the problem.

Without Memory	With Memory
You repeat yourself	Your AI learns
Context is lost	Your AI adapts
Personalization is fake	Your AI improves over time

I break down exactly how I built it here:
👉 https://shakiran.hashnode.dev/how-backboard-io-added-memory-to-my-ai-agent

🙌 Shoutout

Huge shoutout to @MLH Global API Hack Week for the sessions and community that made it easier to explore and build with tools like this in real time.

The Invisible Brains: 5 Surprising Realities of the Tiny Operating Systems Running Our World

Shakiran Nannyombi — Wed, 01 Apr 2026 10:48:15 +0000

How tiny operating systems power billions of IoT devices with just kilobytes of memory.

When we think about operating systems, we usually imagine powerful platforms like Microsoft Windows, macOS, or Linux, designed for laptops, servers, and smartphones, with gigabytes of RAM and multi-core processors.

But the majority of computers on Earth don’t run those systems.

Instead, they run tiny operating systems on microscopic hardware: microcontrollers with 10 KB of RAM, a 50 MHz processor, and batteries expected to last years.

These “invisible” operating systems power:

medical implants
industrial sensors
smart home devices
vehicle controllers
environmental monitoring systems

Operating systems like Contiki, TinyOS, and Tock OS redefine what an operating system can be.

DEV Community: Shakiran Nannyombi

What I learned building a real talent funnel from SRS and Figma to QA, handover, and closing without a perfect ending.

How it started

The middle: building for real users

What the work actually looked like

How it ended

What I take with me

If you are starting your own internship

Closing

From Idea to Production: Building a Spider-Man Tic-Tac-Toe Game with Kiro

7 Weeks, 0 Sandboxes, and a Lot of Code

Lessons From My Software Engineering Internship

1. "Working Code" Isn't Always "Good Code"

2. Moving Out of the Sandbox (Role-Based Access & Route Guards)

3. State Persistence is Harder Than It Looks

4. The Power of Clean Handover Architectures

Follow the Full Week-by-Week Breakdown!

Coming Up: The Final Reflections & Retrospective

🚀 How We Organized the Build with the Gemma Hackathon at Makerere University

BuildWithGemma #GoogleAI #GDG #GDGOnCampus #Hackathon #CommunityBuilding #ArtificialIntelligence #Kaggle #MakerereUniversity #OpenSourceAI #DevCommunity

When Being Right Still Means Redoing the Work

SoftwareEngineering #WebDevelopment #Frontend #MaterialUI #NextJS #TechInternships #CareerGrowth

From an Idea to a Hackathon: Lessons from Organizing Build with AI Makerere

From Classroom to Real-World: Surviving Week 1 of My Software Engineering Internship

Week 1 of My Software Engineering Internship

REST Brain vs Procedure Brain

REST Brain vs Procedure Brain

A Developer’s Lesson on Feedback

Building Secure AI Agents with Auth0 Token Vault

How I stopped storing sensitive tokens in my database and built a security-first AI system

The problem with “DIY security.”

My original approach:

What I realized

The switch: Auth0 Token Vault

The result

About the project

🙌 Shoutout

Read the full story

Let’s talk

My AI Was Smart… But Useless

Then I Fixed It

What Changed Instantly

The Real Shift

🙌 Shoutout

The Invisible Brains: 5 Surprising Realities of the Tiny Operating Systems Running Our World

How tiny operating systems power billions of IoT devices with just kilobytes of memory.

Here are five surprising realities about how these systems actually work.