DEV Community: Jeff Ronnie

# What's Next for AI: A Kenyan Developer's View

Jeff Ronnie — Thu, 02 Jul 2026 08:10:16 +0000

Last week I read a piece by a senior developer asking "what's next for AI?", four years on from ChatGPT, watching vibe coding go from meme to method and wondering out loud whether the next wave of AI restrictions means the most powerful models will stay open to everyone or quietly become the preserve of a few companies and countries.

As I sit here in Kisumu, I just can't shake off this thought, it's been on my mind for a while now. But being in a different location has given me a fresh perspective, and I'm seeing things from a new angle. The question that's been bothering me isn't really about whether AI will remain open or not, that's not the issue anymore. What's really on my mind is who in Kenya will actually have access to this technology, and at what cost? How will this impact the rest of us who make a living building software? It's a different story when you're looking at it from here, and it's making me think about the bigger picture.

The token bill, in shillings

In a place like San Francisco, a model priced in dollars per million tokens might seem like no big deal. But when you're in a country where the money isn't as strong, like Kenya where the shilling has been losing value against the dollar, it's a different story. For someone earning a decent entry-level salary of 40,000 shillings a month, these costs can add up quickly. The cost of using a advanced reasoning model can be tens of dollars per million tokens, while a simpler, faster model might only cost a fraction of a cent. This huge difference in cost is not just a theory, for a startup founder or freelancer in Kenya, it's the difference between being able to launch a product that can handle a few thousand queries a day, or watching their entire month's revenue get eaten up by bills before the tenth of the month. It's a harsh reality that can make or break a business.

This is why so much of what's actually working on the ground here quietly routes around the expensive frontier models. Startups building for SMEs, for farmers, for public services, lean on the cheaper small-and-fast tiers, cache aggressively, batch what they can and reserve the pricier models for the one step in the pipeline where quality genuinely matters. Affordable compute and shared infrastructure have become explicit talking points in Kenya's own AI strategy conversations, not side notes; because token cost is, in practice, the real access-control mechanism, more than any export list.

Where the money and the mandate are pointing

Kenya has a clear plan for using artificial intelligence, and it's not just talking about it. The country's National AI Strategy, which runs from 2025 to 2030, is very specific about where it wants to see AI being used. It's looking at areas like farming, healthcare, education, and how the government delivers services to people. It's also looking at security, banking, small and medium-sized businesses, the arts, and how to make things more sustainable. This isn't just a list of goals, you can already see it happening in the projects that are being worked on.

In Kenya, Fintech is the area where technology has become second nature. A great example of this is Safaricom, which is now using a type of artificial intelligence called generative AI to improve M-Pesa. Other companies like Cellulant are also using AI to detect fraud and decide who should get credit, and they're doing it with real transactions happening every day. The idea that Fintech and AI go hand in hand is not new in Kenya, it's been widely accepted for years, ever since mobile money became a thing.
Agriculture in Kenya is getting a boost from partnerships that use geospatial and satellite data. Organizations like the FAO, NASA Harvest, Microsoft, and the Kenya Space Agency are working together to create maps of crops and forecast yields on a national scale. This information is not only helpful to farmers, but also to insurance companies and lenders. It's like having a crystal ball that shows what crops will do well and where. Twiga Foods is using a similar approach to improve supply chain and logistics, making it easier to get food from farms to tables.

Healthcare and education are crucial areas where technology can make a big difference. We're not just talking about people using new tools, but actually changing the way things work. Think about AI-powered advisors, telemedicine, and diagnostics that can reach people in rural areas. Also, platforms that help students learn in a way that's tailored to their needs. In these areas, it's really important to have voice models that can understand and speak many languages. If a chatbot only works in English, it's not going to be helpful in a country where many people speak different languages. The government is working to improve how it delivers services to the public and how it runs things. One way it's doing this is by using chatbots that can talk to people in many languages. It's also trying to make its tools more efficient. The government has made this a top priority and has even held events like GITEX Kenya and the Nairobi AI Forum to bring people together to talk about it. This year, some big names like the Ministry of ICT, UNDP, and some important international partners got involved.

What's happening in Kenya isn't about the country trying to keep up with the latest artificial intelligence trends. Instead, it's about making deliberate choices on how to use limited and costly computing resources. The focus is on practical areas that can make a real difference, such as ensuring people have enough food, can move money around, and have access to healthcare. It's not about creating chatbots just for the sake of having them.

The developer question underneath all of it

This is where things take a personal turn for me, since coding is my profession.

The original article I read asked whether a 500-person engineering org becomes a 5-person org supervising agents. In Kenya right now, the honest answer is: it depends entirely on which "league" you're in, and that stratification is already visible.

There's a tier of Kenyan engineers being pulled directly into the global market, Microsoft's Africa Development Centre, Google Nairobi, Andela, Turing; earning dollar- or globally-benchmarked salaries, often working on the same agentic tooling everyone else is reading about. For that tier, AI isn't a threat to the job; it's the job. The "cost arbitrage" that used to make Kenyan talent attractive purely because it was cheap is reportedly closing, according to local compensation trackers, which is a good problem to have, because it means people are being paid for skill, not geography.

In Kenya, there's a big group of engineers and founders who are creating products for the local and regional market. They have to deal with clients who pay in shillings, and every feature that uses artificial intelligence has to be worth the cost. This is different from what happens in Silicon Valley. For these engineers and founders, a new way of coding called "vibe coding" is helpful in some ways, but not in others. It makes it cheaper to build the first version of a product, which is great for a market where a lot of software still needs to be created. However, it also means that the things that are really valuable are the things that these coding agents can't do well yet. This includes knowing which industry really needs a particular tool, making it work with payment systems like M-Pesa, dealing with slow internet connections and users who speak many languages, and being responsible when the model makes a mistake, like giving a wrong number in a farmer's loan application.

And there's a foundational tier that barely existed as a "tech job" four years ago: data annotation, AI operations, prompt engineering support, often the entry point into the industry now, useful work, but structurally the most exposed if the tooling above it gets good enough to need less human correction.

The next skill isn't "using AI" : it's using it well

Here's the twist I keep coming back to: if token cost is the real ceiling, then the developers and businesses who win in Kenya won't be the ones who use AI the most. They'll be the ones who use it the most precisely.

Currently, many local AI applications rely on using the same model for every problem, regardless of its complexity. This approach can be costly and inefficient, especially for companies with limited budgets. In many cases, a simpler and more affordable model can handle certain tasks, such as one-line classification, without sacrificing performance. However, for more complex tasks that require multi-step workflows, a more advanced model may be necessary. The most skilled developers are those who can instinctively determine which tasks require a more powerful model and which ones can be handled by a cheaper, faster alternative. They prioritize using the more affordable option unless there's a compelling reason to use a more advanced model, which helps to optimize resources and reduce costs. By taking a more thoughtful and nuanced approach to model selection, developers can create more efficient and effective AI applications that are better suited to their specific needs and budgets.

That's a different skill from "knowing how to prompt." It's closer to systems thinking:

Choosing the right model is a key part of designing a system, not something you do later on. It's like picking the right database for the job - you want to match the complexity of the task to the capabilities of the model. A good engineer wouldn't just use the biggest, most powerful database by default, they'd choose the one that's just right for the workload. Same thing with models, we should be thinking carefully about which one to use, rather than just going with the biggest or most popular one out of habit or because it's trendy.

Token discipline as an engineering practice : trimming context, caching aggressively, batching where latency allows, routing simple calls to small models and reserving expensive ones for the one step where they actually earn their cost. This is quietly becoming as core to the job as query optimization was for the last generation of backend developers. When working on a project, it's not about sticking to just one tool. Instead, it's about bringing together several models and services to get the job done. You might have one model for finding information, another for making sense of it, and a third for handling different languages. Then there's the cheaper option for routine tasks, and maybe a local or open-source model for sensitive information that needs to stay within the country. The key is knowing how to connect all these tools in a way that makes sense, and also knowing when a task is simple enough that it doesn't need any fancy AI at all. This is becoming a special skill in itself - being able to orchestrate all these different tools and services to achieve your goals.

I believe this is exactly the kind of gap that will lead to a certification market, and I'm willing to bet it will happen here. Kenya already has a strong interest in this area, with bootcamps and upskilling programs growing rapidly alongside the rollout of AI strategies and initiatives that train large numbers of people in practical AI skills. The next phase of this training won't focus on basic skills like writing prompts, as that's becoming outdated. Instead, it will focus on more advanced topics like AI systems literacy, such as how to design a multi-model pipeline, how to manage and monitor token spend like cloud infrastructure, and how to decide when human intervention is still necessary. Whoever develops this curriculum, whether it's a university, a bootcamp, or a company like Safaricom or Microsoft training its own employees, will essentially define what it means to be an "AI-ready developer" in this market for the next few years. This is a crucial step, as it will help establish a standard for AI expertise and provide a clear path for developers to acquire the skills they need to succeed in this field. As the demand for AI professionals continues to grow, having a well-defined certification program will be essential for identifying and developing top talent.

So, same worry, different shape

The Polish piece I read ended without a firm answer, and I don't have one either, but here's my honest projection for Kenya specifically:

I think the real problem isn't that the most advanced AI technology will be kept away from us because of export controls, that's more about who gets to use the latest and greatest models first, and let's be honest, Kenya has never been at the front of that line anyway. The real risk I see is that there's a limit to how much it costs to use these advanced models, and that's going to create a two-tier economy. On one hand, you'll have the big global companies and their developers who can use the best AI models without any issues. On the other hand, you'll have the local companies that are trying to solve problems specific to Kenya, using Kenyan money, and they'll be stuck with cheaper, faster, but not-as-good models because that's all they can afford. This means the local sector will never be able to catch up, and that's a big problem.

It's not all bad news. Having cheap and fast models, along with a developer who really gets the problem and knows exactly when to use a model and when not to, is a pretty powerful combination. This could be a better way to build a strong AI sector in Kenya, rather than just relying on the most expensive and advanced tools for every task. But it does change what makes a Kenyan developer valuable over the next few years. It's no longer just about being able to use an API, anyone can do that. Now it's about having the judgment to know which model to use, how much it will cost, and how to make it work with the local constraints. And that's exactly what the next round of certifications will try to teach. The tools are now available to everyone, but it's the judgment and expertise that will set developers apart. Being able to prove that you have this judgment and expertise will be key. It's not just about being able to call an API, it's about being able to make informed decisions about which model to use and how to use it effectively. This requires a deep understanding of the problem, the models, and the local context. In the end, this shift could be a good thing for Kenyan developers. It will allow them to focus on what really matters, using their judgment and expertise to build effective AI solutions that meet the needs of their community. And it will give them a unique advantage in the market, as they will be able to provide tailored solutions that take into account the local constraints and requirements. So, while the tools may be democratized, the value of a skilled and knowledgeable developer is still very high. And it's this judgment and expertise that will be the key to success in the next round of certifications.

What do you think? Is Kenya's AI story going to be about catching up to the frontier or about getting really good at building brilliantly within a tighter budget?

AI Isn't the Tool Anymore : You Are

Jeff Ronnie — Mon, 15 Jun 2026 08:29:22 +0000

Two years ago, I used AI the same way most people did, as a fancy search engine. It felt like a novelty. Fast forward to today, and that relationship has completely transformed. AI is no longer something I occasionally reach for. It is woven into how I think, how I work, and how I build. At some point it stopped being a tool I used and started feeling like an extension of how I operate.

But here is the thing nobody tells you early on: using AI well is itself a skill, one that most people are still sleeping on.

The landscape has changed faster than most people realize,
What started as large language models answering questions has evolved into a sprawling ecosystem of capabilities. We now have RAG systems that give models access to live, external knowledge. We have AI agents that take autonomous actions across tools and APIs. We have multi-agent workflows where one model orchestrates others to break down and solve complex problems, things no single prompt could handle alone.

LLMs
RAG systems
AI agents
MCP servers
Prompt engineering
Subquadratic architectures

MCP servers and connectors now let AI plug into external tools in real time. Subquadratic agent architectures are being built to process information more efficiently at scale. New agentic frameworks are emerging almost monthly. And then there is the headline that genuinely made me stop scrolling: Claude Fable 5 reportedly developing its own emergent reasoning language to solve problems. Whether or not that story is exactly what it sounds like, the direction it points to is clear: these systems are advancing in ways that are genuinely hard to anticipate.

The question is no longer "can AI do this?" It is "do you know how to ask for it properly and do you understand what happens when you do?"

Why you need to understand how these models actually work
This is why prompt engineering is now a legitimate course of study and why dismissing it is a mistake. It is easy to assume you just type what you want and the model figures it out. But that misses the point entirely.

Here are three concepts that will immediately change how you interact with any AI model:

Tokens, not words
Models do not read text the way you do. They process tokens; chunks of characters that may or may not align with full words. Every interaction has a token limit. Understanding this changes how you structure long inputs, how you summarize context, and why some prompts quietly fail for no obvious reason.

Context windows and memory
AI models do not have persistent memory across sessions by default. Everything they "know" in a conversation lives inside the context window; a finite space that fills up. When it does, earlier information starts getting dropped. Knowing this helps you design prompts and workflows that stay coherent even across long or complex tasks.

How agents reason
Agentic AI systems do not just respond, they plan, call tools, evaluate results, and iterate. Understanding how that loop works helps you design better instructions, catch failure modes early, and build workflows that actually hold together rather than breaking silently mid-task.

The gap between users and skilled users is widening
Most people are still treating AI like a search engine with better grammar. They type vague questions, get mediocre outputs, and conclude the tool is overrated. Meanwhile, people who have spent time learning how these models behave are pulling dramatically different results from the exact same interface.

We are at a point where knowing how to work with AI effectively is becoming as foundational as knowing how to use a computer was in the early 2000s. The gap between those who get it and those who do not is going to compound quickly in hiring, in output quality, in the kinds of problems you can actually take on.

The models will keep getting more capable on their own. That part is taken care of. The variable is you specifically, whether you understand enough about how they work to get the most out of them when it matters.

So take some time. Read about tokenization. Understand context windows. Learn what an agent actually is under the hood. Experiment with how differently a model responds when you change the structure of your prompt, not just the content. The investment is small. The returns, compounded over the next few years, will not be.

The Best Career Insurance Is a Tech Event You Don't Want to Attend

Jeff Ronnie — Mon, 25 May 2026 12:11:30 +0000

Let’s be completely honest for a second. As developers, engineering students, or tech enthusiasts, our default setting is comfort within our local development environment. When a notification pops up inviting us to a weekend tech meetup, a hackathon, or a networking session, our brain instantly calculates the social overhead.

“I have a bug to fix.”
“I need to wrap up this module.”
“It’s going to be awkward standing around with a bunch of strangers talking about memory management.”

Tech events can easily feel cumbersome. They require physical energy, commuting, and stepping completely out of your comfort zone.

But over the last month, I decided to ignore that internal friction. I pushed through the initial reluctance and attended a flurry of tech gatherings, ranging from rigorous buildathons to relaxed, beer-fueled academic discussions.

What I discovered is that the very events that feel the most exhausting on paper are exactly what we need to learn faster, prevent burnout, and build the communities that sustain our careers.

Here is what a chaotic month of tech events taught me about the hidden architecture of developer communities.

Demystifying the Complex: When "Nation Dev" Meets Global Science

Early in the month, I engaged with the broader developer landscape during a session with Nation Dev, exploring how the market for developers is evolving. But the real shift in perspective happened when I walked into a global phenomenon that felt entirely different: Pint of Science.

If you haven’t heard of it, the premise is beautifully simple: researchers, scientists, and engineers gather at a local bistro or pub to explain complex academic theses over a casual drink.

[Dense Academic/Tech Thesis] ──> [The "Pub Filter"] ──> [Accessible, Real-World Insight]

Sitting there listening to deep technical theories being broken down in an approachable environment made me realize something vital about engineering communication. In our daily lives, we get trapped in our own silos, whether that’s network programming, cloud infrastructure, or frontend state management.

When you strip away the formal lecture halls and explain a complex system over a casual drink, two things happen:

The imposter syndrome melts away. You realize everyone is just trying to figure out hard problems.

You learn how to communicate. Being able to explain low-level concepts simply is a superpower. If you can’t explain your network architecture or backend engine to someone holding a drink at a social event, you don't understand it well enough yet.

Aggressive Upskilling: The Buildathon Pressure Cooker

Shortly after, it was time to transition from theoretical discussions to raw execution. I attended a local buildathon powered by Cursor and Claude Kenya.

If you've been monitoring the engineering space lately, you know the narrative around AI development tools has shifted dramatically. We aren't just using AI for basic autocomplete anymore; we are orchestrating full-fledged development workflows using context-aware AI editors and advanced model pairs.

Spending hours in a room packed with developers wrestling with these tools taught me a massive lesson about modern upskilling:

The Classroom vs. The Sandbox: You can watch tutorials on modern AI-assisted engineering for weeks, but nothing matches the velocity of a high-pressure buildathon.

When you are working against a clock alongside peers, you don’t have time to second-guess yourself. You lean on the tools, you learn how to prompt with hyper-specific context, and you see firsthand how other developers structure their packages, debug runtime errors, and manage deployment pipelines. You walk into the room knowing the syntax of a language; you walk out understanding how to build a production-ready application at three times your normal speed.

The Power of "Shared Mythology": Celebrating Crypto History

You cannot build a developer culture purely on code and APIs. Communities require a shared history, stories, and milestones that bring people together. I experienced this vividly at a blockchain event celebrating Bitcoin Pizza Day (commemorating May 22, 2010, when a programmer traded 10,000 BTC for two pizzas).

Gathered around boxes of actual pizza with local builders, the conversation naturally drifted past token prices and market charts. Instead, we talked about fundamentals: decentralized consensus, the elegance of peer-to-peer networks, and what it takes to build infrastructure that lasts.

Celebrating these milestones roots our work in a larger narrative. It reminds a junior developer or an engineering student that every massive, global tech ecosystem started exactly like the room they are sitting in: a few curious people, an experimental idea, and some shared food.

The Counter-Intuitive Breather: Team Building and Soft Skills

To cap off this intense run of technical immersion, we had a dedicated team-building day. On paper, a tech team-building day can sometimes look like an unnecessary break from keyboard time. In reality, it is a vital counter-weight to the cognitive strain of development.

Software engineering is an incredibly isolating craft. We spend eight to twelve hours a day looking at logical structures, compilers, and terminal outputs. Our brains operate in a rigid, deterministic world.

Stepping away from the screen to participate in collaborative, non-technical exercises serves multiple functions:

Mental Defragmentation: Just like a hard drive, your brain needs time to index and store information without active processing strain. The best architectural breakthroughs often happen when you are completely detached from the code.

Building Social Capital: It is significantly easier to ask for a code review, debug a broken network route, or pair-program on a messy repository with someone once you've shared a laugh outside the office or classroom environment.

Summary: The True ROI of Showing Up

When you look back at a month filled with diverse events, the compound value becomes crystal clear. It isn't just about the specific lines of code written or the business cards collected. It's about ecosystem integration.
Event Type Direct Developer Benefit The "Hidden" Value
Nation Dev / Tech Sessions Industry trends & framework updates
Pint of Science High-level technical conceptualization Breaking down communication barriers
Buildathons (Cursor/Claude) Advanced AI workflows & rapid prototyping Breaking through analysis paralysis
Blockchain / History Events Architectural & network fundamentals Connecting with a shared engineering culture
Team Building Days Stress relief & cognitive breaks Establishing deep peer trust

Conclusion: Stop Coding in Isolation

If you are sitting at your desk right now, looking at a local event invite and debating whether to go, let this be your sign to just book the ticket.

Yes, it might feel cumbersome. Yes, the first ten minutes might be slightly awkward. But the tech communities I have managed to join over this past month didn't find me through a browser window or a GitHub pull request. They found me because I showed up, grabbed a slice of pizza or a drink, and started talking to the person sitting next to me.

Get out of your IDE for a day. Join a local community, attend a buildathon, talk about your tech stack over a drink, and remember that software isn't just built by compilers, it’s built by people.

Chasing The High Of Total Awareness

Jeff Ronnie — Sat, 23 May 2026 09:32:15 +0000

The Trap No One Warns You About

For most tech enthusiast stepping into the digital world for the first time, the sheer scale of it all often seems like a rush.
You find yourself diving into the deep end, captivated by the high of wanting to know everything. One morning you are learning Go, the next hour you are into DevOps and cyber security and by midnight you are knee deep in a kubernetes setup tutorial you barely understand. You want to understand it all, build it all and be the person who has a hand in the most crucial tools moving the industry forward.

The Crash Hits

With how fast the technical progress moves compared to what the human brain can consume, that initial excitement curdles into something heavier. You end up having fifty open tabs, half finished tutorials, growing backlog of newsletters and instead of excitement you feel dread and overwhelmed.

That dread shifts into paralysis, you tried to touch on everything but feel like you truly know nothing. You are completely lost in the noise, overwhelmed by the feeling you are falling behind in the field you did not even care about 24 hours ago.

The Fix

The instinct to read more or find that one course or road map that makes everything click is usually wrong.

Pick one project, one stack and a problem. Give it your all and aggressively filter out everything else, trusting that the rest of the tech world will still be there once you are done. Anchor your learning to a concrete output and you will find yourself shifting from anxious overload into something far more productive.

You don't need to know everything to be valuable in the industry. The best developers out there, that most people admire, are not the ones that consumed the most content, but the ones who built through the noise while others stuck to watching tutorials.

Close a tab, open your IDE, ship something.

It's Never Too Late to Start

Jeff Ronnie — Tue, 12 May 2026 12:03:26 +0000

There’s a common myth that if you didn’t start coding at age twelve, you’ve already missed the boat. I’m here to tell you, from the heart of Kisumu, that is absolutely false. My journey didn't start with a keyboard in my hand; it started with a conviction that the gap between understanding a network and securing one was a gap worth closing.

The Pivot: From Theory to Tooling

I spent four years at the Technical University of Kenya studying Communication and Computer Networks. I could draw you a packet header from memory, but I couldn't write the code to catch one. The shift happened when I stopped being a student of "theory" and became a student of "production."

If you are a beginner sitting with a Go tutorial open or any other programming language, feeling overwhelmed: Keep going. A month ago, I was just learning the syntax of golang. Today, I am building SME-Shield, a full-stack security dashboard designed to protect small businesses in Kenya.

What Scaling a Project Proves

Transitioning from a CLI (Command Line Interface) tool to a Full-stack product isn’t just about adding a "pretty face." It’s a complete mental overhaul. Here is what that process proves to you as a developer:

Logic is Universal: Whether it's a worker pool in Go or a state-handler in JavaScript, the problem-solving logic remains the same.

Data has a Life Cycle: In a CLI, data is transient. In a Full-stack app, you have to care about its "home" (SQLite), its "travel" (REST APIs), and its "presentation" (Tailwind CSS).

The "User" is Your True North: Building for a terminal is building for yourself. Building a dashboard is building for an SME owner who needs to see a "Security Score" to feel safe.

The Zone01 Kisumu Factor

I wouldn’t be writing this without the environment at Zone01 Kisumu. Tech isn't a solo sport. It’s about being in a room where someone is specialized in Cloud, another in AI, and another in Blockchain and realize you can learn from all of them. This collaborative, project-based model forced me to build something real, and that is the fastest way to bridge the gap.

My Experience: A Note to the Beginners

If you are worried that you’re "just a beginner," remember that every professional-grade product started as a buggy script. My scanner started as a simple ping; today it’s a vulnerability auditor that cross-references the NVD database.

The takeaway? Don't wait until you "know enough" to start a project. Start the project so that you are forced to learn what you don't know.

Why Project-Based Learning Works: Building My First Port Scanner in Go

Jeff Ronnie — Wed, 25 Mar 2026 12:42:45 +0000

Introduction

I spent four years studying Communication and Computer Networks at the Technical University of Kenya. I was fairly solid on theory and could explain TCP/IP handshakes, draw network topologies, and describe exactly what happens when a packet moves from one host to another.

Then I joined Zone01 Kisumu, an environment that forced me to build something with the knowledge I had. That’s when I realized there’s a massive gap between knowing how networking works and knowing how to code it.

This is the story of how I bridged that gap. Let me walk you through the journey; from building a concurrent port scanner in Go to developing a strong conviction that real projects are the fastest way to learn.

To understand how this project pushed me, let’s start by explaining the technical challenge at its core: what exactly is a port scanner?

A port scanner probes a target IP address and checks which of the listed ports are open, closed, or filtered. Tools like nmap do this at a professional level. My scanner is a simpler version, and building it taught me more than any lecture ever did.

The Stack

Language: Go
Concurrency model: Worker pools with goroutines
Input: CLI flags (target IP/range, port range, workers, timeout)
Output: Terminal display + optional file export (JSON, CSV, TXT)

How It Works

Parsing the Target

The scanner accepts a single IP address or a range, such as 192.168.1.1-192.168.1.254. The ParseIPs() function in the scanner package handles expanding that range into a slice of individual IP strings.

Parsing Ports

This was one of the more interesting parts to design with flexibility in mind. I wanted to be able to scan a range (1-1000), a comma-separated list (22,80,443), or use a named profile:

func parsePorts(input string) ([]int, error) {
// check for named profile first
if profile, ok := scanner.PortProfiles[input]; ok {
return profile, nil
}

var ports []int

if strings.Contains(input, "-") {
    parts := strings.Split(input, "-")
    start, err1 := strconv.Atoi(parts[0])
    end, err2 := strconv.Atoi(parts[1])
    if err1 != nil || err2 != nil {
        return nil, fmt.Errorf("invalid port numbers in range: %s", input)
    }
    for i := start; i <= end; i++ {
        ports = append(ports, i)
    }
    return ports, nil
}

for _, p := range strings.Split(input, ",") {
    port, err := strconv.Atoi(strings.TrimSpace(p))
    if err != nil || port < 1 || port > 65535 {
        return nil, fmt.Errorf("invalid port: %s", p)
    }
    ports = append(ports, port)
}
return ports, nil

}

Port profiles like common, web, db, and ssh are predefined slices in the scanner package. So instead of typing --ports 22,80,443,3306,5432, you just type --ports web. Much cleaner.

The Worker Pool (Where Go Shines)

This is my proudest bit. Scanning hundreds of IPs across hundreds of ports sequentially would take forever. The solution? Concurrency.

Go makes this elegant with go routines. These are lightweight threads that can run thousands at a time. My scanner uses a worker pool pattern: a fixed number of workers pick jobs from a shared channel and process them concurrently.

results := scanner.RunWorkerPool(ips, portList, *workers, time.Duration(*timeout)*time.Second)

By default, 100 workers run simultaneously. That means scanning 254 hosts across 100 ports completes in seconds, not minutes.

This was the hardest concept to get right. You’re not writing step-by-step instructions anymore; you’re designing a system where many things happen at once.

The CLI Interface

The main.go uses Go’s built-in flag package to handle all inputs cleanly:

target := flag.String("target", "", "IP or range (e.g. 192.168.89.1-192.168.89.254)")
ports := flag.String("ports", "common", "Ports: range, list, or profile (common, web, db, ssh)")
workers := flag.Int("workers", 100, "Number of concurrent workers")
timeout := flag.Int("timeout", 1, "Connection timeout in seconds")
verbose := flag.Bool("v", false, "Show closed ports too")
vverbose := flag.Bool("vv", false, "Show all ports including filtered")
output := flag.String("output", "", "Save results to file (e.g. results.json, results.csv, results.txt)")

A typical scan looks like this:

go run main.go -target 192.168.1.1-192.168.1.50 -ports web -workers 200 -output results.json

Output & Saving Results

The scanner prints results to the terminal and can optionally save them to a file. I added support for three formats; JSON, CSV, and plain text, because different use cases need different outputs. A security audit might want JSON for parsing; a quick report might want CSV for a spreadsheet.

What I Learned That School Didn’t Teach Me

Networking concepts look different in code.
I knew what a TCP connection was. But writing code that attempts a TCP dial to check if a port is open, and then handling timeouts, refused connections, and filtered ports as separate outcomes, gave me a much deeper intuition for what’s actually happening on the wire.
Concurrency is a design problem, not just a syntax problem.
Go’s go routines are simple to write. Worker pools are simple to understand. But designing a concurrent system, deciding how many workers, how to handle shared state, how to collect results safely requires a different way of thinking that you only develop by doing.
CLI design matters.
A tool that’s hard to use won’t get used. Adding port profiles, verbosity levels, and multiple output formats wasn’t about making the code fancier, it was about making the tool actually useful in real scenarios.
Error handling is where discipline lives.
Go forces you to handle errors explicitly. At first, that felt annoying. Now I see it as one of the language’s best features. Every if err != nil block is a moment where you decide: what should actually happen here?

What’s Next

This scanner works well for small networks, which is exactly the audience I had in mind, SMEs in Kenya who need a lightweight, local tool for basic network visibility without the overhead of enterprise software.

Next steps:

Add OS fingerprinting
Build a simple web UI for non-technical users.
Package it as a standalone binary for easy distribution.

The code is open source on GitHub: github.com/rjeff-sudo

Final Thought

If you’re learning a new language or trying to solidify concepts from school, stop doing tutorials in isolation. Pick something real, something slightly too hard for your current level, and build it. You’ll hit walls. You’ll Google things at 1am. You’ll rewrite entire functions because you didn’t think it through the first time.

That’s not failure. That’s learning.

Built with Go · Zone01 Kisumu · Nairobi, Kenya

If you found this useful or have questions about the code, drop a comment below. I’m always happy to talk about networking and Go.