DEV Community: ZIKORA CHUKWUKA

Strategic Logging: The Debugging Skill Nobody Taught Me

ZIKORA CHUKWUKA — Sun, 05 Jul 2026 02:14:25 +0000

When something breaks in production, most developers do one of two things.

They either guess- changing things randomly and hoping something works. Or they panic- opening every tab, reading every Stack Overflow answer, going in circles.

Or more recently paste tracebacks into an AI.

I have done all versions.

I recently realized something from my work building production software.

I realized I was missing a systematic way to see exactly what my code was doing at every step.

Not just when it crashed, but before it crashed. During the journey from request to response, something was going wrong and I had no visibility into where.

All of that changed after I learnt about strategic logging.

What is Strategic Logging?

To understand strategic logging, we first have to understand logging.

Logging is the practice of recording structured events from your code to capture the precise application state, execution path, and environmental context at a specific point in time.

It is like leaving a trail of breadcrumbs in your code. Each breadcrumb tells you exactly where the program went, what data it was holding, and what the environment looked like at that exact moment.

You have probably seen this before:

console.log("here")

That is logging. But it is not strategic logging.

Strategic logging is intentional. It tells you not just that your code reached a certain point, but what the state of your data was at that point, what action was being taken, and what the result was.

The difference looks like this:

// Not strategic
console.log("here")

// Strategic
console.log("Login attempt started", { email: user.email, timestamp: new Date().toISOString() })
console.log("Token received from API", { tokenExists: !!token, status: response.status })
console.log("Cookie being set", { httpOnly: true, path: "/" })

Can you see the difference? The strategic version tells a story. The first version tells you nothing.

My Production Bug

I was building the frontend for an AI startup as the only frontend engineer on the team, consuming a FastAPI backend being built by another engineer.

Auth was not working properly after deploying to staging.

My first instinct was to assume the problem was on my end. I had recently implemented HttpOnly Cookies for session management and there were a lot of moving parts - server actions, middleware, cookie flags. Any one of them could have been the culprit.

So I added logs at every step of the auth flow.

console.log("Server action called with credentials", { emailProvided: !!email, passwordProvided: !!password })

console.log("Calling API login endpoint")
const response = await fetch(`${process.env.API_URL}/auth/login`, {
  method: "POST",
  body: JSON.stringify({ email, password })
})

console.log("API response received", { 
  status: response.status, 
  ok: response.ok 
})

const data = await response.json()
console.log("Response data", { 
  tokenExists: !!data.token, 
  error: data.error || null 
})

What came back stopped me immediately.

The API response status was 500. The token did not exist. The error field pointed to the backend.

The problem was not in my frontend at all. The logs had traced the issue directly to the backend where an incomplete database migration was causing the API to crash silently on every login attempt.

Without those logs, I could have spent days ripping apart my frontend code looking for a bug that was never there.

Instead I had a clear answer in minutes and a productive conversation with the backend engineer to resolve it fast.

What Good Logs Actually Look Like

Through this experience and further, I have come to understand that good logs share a few things in common.

They are contextual.

A good log does not just say something happened. It says what happened, with what data, and what the outcome was.

// Weak
console.log("API call made")

// Strong  
console.log("API call made", { 
  endpoint: "/auth/login", 
  method: "POST",
  status: response.status,
  duration: `${Date.now() - startTime}ms`
})

They follow the journey.

Think of your code as a journey from request to response.

Log at the beginning of each significant step and at the end. That way when something breaks you can see exactly where the journey stopped.

They are removed after debugging.

Very Important.

Production logs that are too verbose can expose sensitive data and slow down your application. The logs I write for debugging are temporary. Once I understand the problem and fix it, I clean them out. What stays in production should be intentional, not accidental.

They never log sensitive data.

This is important. Never log passwords, tokens, full credit card numbers, or any personally identifiable information you do not need. A log file in the wrong hands becomes a security problem.

// Never do this
console.log("User login", { email, password })

// Do this instead
console.log("User login attempt", { email, passwordProvided: !!password })

A Simple Framework for Debugging with Logs

When something breaks and I do not know why, I now follow a simple process.

First I identify the flow. I trace the journey from where the user action starts to where the expected outcome should be. In my case it was: form submission, server action, API call, cookie set, redirect.

Then I add a log at the start of each step. Not inside the step yet. Just at the entrance so I can see how far the request is getting before it fails.

Then I run it and see where the logs stop. The last log that appears before silence or an error is your crime scene. That is where to look.

Then I go deeper into that specific step. Add more logs inside it. Narrow the problem down until you can see exactly what is wrong.

Then I fix it, verify with the logs, and remove the debugging logs once the problem is resolved.

What I Learned

The most valuable thing about this experience was not the fix itself. It was realising that debugging is a skill, not a talent.

Some developers seem to find bugs quickly and others seem to struggle forever.

The difference is usually not intelligence. It is methodology. Strategic logging is one of the most important tools in that methodology.

I also learned something about working on a team.

Without those logs, I might have spent days convinced the problem was mine. The logs gave me evidence. Evidence made the conversation with the backend engineer fast and productive. Nobody was defensive. We just looked at the data together.

That is what good debugging does. It removes the guesswork and replaces it with clarity.

I am actively learning about logging and observability.

This article reflects my current understanding of the subject from real experience.

If you have feedback or see something I can improve, please leave a comment. I am here to learn.

I Built a Voice Coding Agent Over the Weekend on a Laptop With No GPU.

ZIKORA CHUKWUKA — Sun, 05 Jul 2026 00:52:30 +0000

I hold a belief that software is heading toward a voice-first future. Not voice as a gimmick bolted onto an app, but voice as a genuine interface. The kind where talking to your tools feels as natural as talking to a colleague.

The spark for this project came from something small. I was in a live voice session with Claude, the kind where you talk and it talks back in real time, no typing at all. Something about that experience stuck with me. It felt like a glimpse of where things are going.

Around the same time, I had been wanting an excuse to properly play with local AI models. I have always been drawn to the idea of running models on your own machine, no API calls, no cloud dependency, just you and your hardware. I had read about it, dabbled a little, but never gone deep.

So I combined the two curiosities into a weekend project. Build a voice coding agent. Run the speech parts locally. Let Claude be the brain.

That project became Mabara.

What Mabara Actually Does

Mabara lets you talk to your codebase the way you would talk to a coworker. You hold down a key, ask a question or give an instruction, and it responds out loud. It can explain how your project is structured, make changes to your files when you approve them by voice, and if it does something you do not like, you just say "revert that" and it undoes it.

The clever part is where the thinking happens versus where the listening and speaking happen. Claude, running through the Claude Agent SDK, is the brain. It understands your code and decides what to do. But the ears and the mouth, the part that hears you and the part that talks back, run entirely on my own laptop. No cloud speech service. Just my CPU.

And that laptop is not a powerful one. It is an i5-10210U with 8 GB of RAM and no GPU. Not the machine anyone benchmarks AI on. That constraint is actually the whole reason this story is interesting.

This is really a story about measuring things, and about learning to trust data over assumptions.

Disclaimer: I am not an expert on speech models or real-time systems. I am sharing what I measured and what it taught me. If you see something I got wrong, please tell me. I am here to learn.

Lesson One: The Benchmark Is the Truth, Everything Else Is Marketing

Here is a thing everyone "knows" in the AI world. Quantizing a model to int8 makes it faster on CPU. Smaller numbers, faster math. Every optimization guide says so.

So when my text-to-speech model was too slow, I downloaded the int8 version, fully expecting a win.

It ran 2.5 times SLOWER than the full precision model.

Not slower by a little. The full precision model hit 1.6x real-time on my CPU. The int8 version managed 0.6x, which is slower than the speech it was supposed to be producing.

Understanding why taught me more about hardware than any course I have taken. Int8 speedups depend on special CPU instructions, called VNNI on Intel chips, that handle quantized math natively. My Comet Lake CPU does not have them. Without those instructions, the CPU has to quantize, dequantize, and shuffle formats on every single operation. That is pure overhead with zero benefit.

The pattern repeated soon after. Distil-Whisper, marketed as six times faster than Whisper, was exactly zero percent faster for my use case. Push-to-talk clips are short, and short clips spend almost all their time in the encoder, which distillation does not shrink. That famous speedup only shows up on hour-long recordings.

A tuning parameter that was supposed to cut Whisper's processing window did nothing at all. I benchmarked three different values. Identical times, down to the decimal.

By the end of day one I had a personal rule. Nothing ships in Mabara unless it wins a benchmark on this exact laptop. Not a benchmark from someone else's README. Mine.

Lesson Two: I Traded a Beautiful Voice for 1.2 Seconds, and It Was the Easiest Decision of the build

The voice journey humbled me.

I started with Kokoro, an 82 million parameter model that genuinely sounds human. On my CPU it synthesizes at roughly 1.0x real-time. That number sounds fine until you understand what it actually means. The system generates speech exactly as fast as it speaks it. There is zero margin for error. Every sentence boundary becomes a coin flip between smooth speech and an awkward gap.

So I switched to Piper, a smaller and admittedly more robotic sounding model that runs at 7x real-time. The gaps disappeared completely. But the voice bothered me. Every reply reminded me I was talking to a machine, not a colleague.

Then I found Supertonic, a 66 million parameter model that sounds nearly as good as Kokoro and runs at 2x real-time on my hardware. I spent a couple of hours integrating it properly. Picked a voice I liked. Tuned the pacing until it felt right.

Then I actually used it. Within twenty minutes I switched back to Piper.

Here is why. Supertonic needed about 1.6 seconds to produce the first word of every reply. Piper needed 0.4 seconds. That 1.2 second difference does not sound like much written down. But inside an actual conversation, it is the difference between talking to a colleague and waiting for a system to catch up.

I had happily tolerated Piper's robotic edge for a full day of building. I could not tolerate 1.2 extra seconds of silence for twenty minutes of actually using it.

That taught me something I now treat as a rule for conversational interfaces. Response latency beats voice beauty. Users say they want natural. Their patience says they want fast. Watch the patience, not the words.

A small aside. I am Nigerian, and I genuinely wanted a Nigerian accented voice for this. There is a lovely project called YarnGPT that does exactly this, built by a young Nigerian engineer whose work I genuinely admire. But it uses an autoregressive language model architecture for text to speech, which my CPU simply cannot run in real time. It is on my someday list.

Lesson Three: A Voice Agent Is a Pipeline, and Every Stage Must Overlap

The single biggest perceived speed win of the whole weekend had nothing to do with which model I chose.

Early on, Mabara waited for Claude's complete response before speaking a single word. For a long answer that meant thirty seconds of silence, followed by an entire essay all at once. Unusable.

The fix is treating the whole thing as a pipeline. Claude streams text token by token. The moment a full sentence exists, it gets sent to the speech synthesizer. The moment that sentence's audio exists, playback starts, while the second sentence is still being synthesized and the third sentence is still being generated by Claude. Three stages, all running simultaneously.

Speech now starts after the first sentence instead of after the entire response. The total time to finish is the same. The felt experience is completely different.

The same thinking applied everywhere else in the system. The microphone never fully closes. It keeps a rolling pre-roll buffer, because opening the device only after the key is pressed clips your first syllable and ruins transcription. Sentences get batched into single synthesis calls when the queue backs up, because every call carries fixed overhead regardless of length. And every piece of queued audio carries an epoch number, so when you interrupt Mabara mid-sentence, which you do by simply holding the talk key again, it shuts up within 0.2 seconds and any stale audio from the previous epoch gets silently discarded instead of playing awkwardly after you have already started talking.

None of this is exotic engineering. It is simply accepting that in real-time systems, waiting for anything to finish completely before starting the next thing is almost always the wrong design. At least in my experience.

Lesson Four: If the Interface Is Trust, Then Engineer the Trust

A voice agent that edits your code has a unique problem. You cannot see what it is about to do before it does it. The entire interface is confidence itself. So the safety model became the part of Mabara I am proudest of.

Reads are free, no approval needed. But every file edit and every shell command gets spoken out loud, something like "I would like to edit the file page.tsx, do you approve?", and requires a verbal yes from me. Saying "yes for the whole task" approves the rest of that task's edits, because approving fifteen individual edits one by one is misery. Shell commands always ask, every single time, because that is where the truly unrecoverable mistakes live.

Underneath all of this, git does the real safety work. Mabara refuses to edit anything outside a git repository. The first approved edit of any task automatically triggers a checkpoint. Saying "revert that" restores everything the last task touched, including restoring my own uncommitted files from a backup rather than deleting them, which is an edge case that would have destroyed real work in the first week if I had not caught it. Saying "commit this" turns a good task into a proper git commit, containing only the files that task actually touched.

I learned the trust lesson from the model side too, not just the tooling side. I tried running Mabara on a smaller, cheaper model to save on cost. Within an hour it confidently told me my backend was built on a PDF generation library. The real backend was FastAPI, plainly declared in requirements.txt, a file it apparently had not bothered to read. It answered from vibes and documentation prose instead of actual code.

The fix was partly a prompt rule: code is the truth, documentation is intentions, verify before answering. But the deeper lesson stuck with me. A wrong answer delivered confidently in a warm human voice is the most expensive output a tool can produce. I moved back to the larger model as the default. Speed is negotiable. Trust is not.

The Honest Part

Mabara was pair built with Claude Code. The AI wrote most of the actual lines of code. I want to be straightforward about that, because I think the genuinely interesting part of this story is the division of labor, not the line count.

Every decision in this project was mine. Which benchmarks to run. Which numbers to actually believe. When to abandon two hours of integration work because twenty minutes of real use disagreed with it. The AI never once pushed back on the int8 hype or the distil-Whisper hype. The benchmarks did. I chose to run them and I chose to listen to what they said.

I came away from this weekend thinking that this is what engineering looks like now. The typing is cheap. The judgment is the job.

Why I Built This

I built Mabara because I wanted to test a belief I hold, that voice is going to become a real interface layer for software, not a novelty. And I wanted to get my hands genuinely dirty with local models instead of just reading about them.

Both things happened. I now understand the practical tradeoffs of local speech models in a way no article could have taught me. And I have a small, honest proof that voice-first tooling is buildable on modest hardware if you are willing to measure everything and trust nothing you have not tested yourself.

Mabara is open source on my GitHub. One Python file, one process, five threads, no framework. Every default in it won a fight on my specific laptop, which means on your machine some of them might lose. So the losers are all still there behind flags, waiting for your benchmarks to decide.

Have you ever benchmarked a "known" optimization and watched it lose? Or built something voice driven yourself? I would genuinely love to hear what surprised you.

An Auth Story...

ZIKORA CHUKWUKA — Fri, 26 Jun 2026 01:35:07 +0000

I love system design. I love geeking out about the tiny decisions that make software great — for me, for those I work with, and most of all for my users.

My biggest obsession as a budding engineer is ensuring that the products I work on actually work as expected, every time, no matter the edge case.

I am also pretty obsessed about security.

I mean, what is the use of software if it is unsafe to use or loses money when it gets taken down? If I can do anything to secure the software I work on, I would.

Security is something I want to get better at, and I believe talking about it and sharing my work and learnings publicly is one way to do just that. So that is the purpose of this article.

I want to share a concept I learned while implementing Auth as the frontend engineer at an AI startup.

This is my Auth story.

I build my frontends with Next.js.

It basically chose me. It felt like the best option while I was starting out.

It is an elegant framework for a one-man team. I love the idea of having both my frontend and backend within the same codebase. I love a single deployment pipeline. I love shipping fast without reinventing the wheel.

So when the opportunity to join a lean startup team came, choosing Next.js was a no-brainer. It meant I could build fast, deploy faster, and implement solid frontend architecture patterns and security as a one-man frontend team without getting overwhelmed.

Working on this project pushed me to think more carefully about something I had always glossed over: how authentication tokens are actually stored and protected in the browser. The answer to that question is cookies, and specifically, HttpOnly cookies.

Let's talk about Cookies. Specifically HttpOnly Cookies. What they are, why they are useful, when they are useful, and specifically why I used them in my project.

Disclaimer: I am not an expert on this topic. I am only sharing from my personal experience building real projects. Please feel free to give me feedback. I am here to learn.

So what are Cookies?

Cookies are technically key value pairs stored in a browser. For example:

sessionId = abc123xyz

To use an analogy, imagine you drank coffee several times a day at a coffee shop close to your home or office, and every time you visit, the barista asks you the same questions: your name, your preferences, and so on.

You are not just a casual visitor, remember? You are a regular, and several times a day at that. I am sure you would be frustrated every single time. I know I would. Can you not just write my name and preferences down or something!

Well, that is the same thing that happens when a user visits your app in their browser. By their very nature, HTTP requests are stateless. This means they carry no context about who is making them or where the request is coming from. So in the eyes of your server, your best and most regular users are just another request.

Your APIs do not know that a particular request is coming from the same user, so they treat every single request like what it is: just a request. Your users would have to manually authenticate every time they take an action on the frontend that sends a HTTP request to your server.

Cookies help solve this problem by giving the browser a way to tell the server that the HTTP requests are coming from the same logged-in user. So the user authenticates once and can use your app without having to re-authenticate every time their action sends a request to the server.

Cookies are not the only way to solve this problem. Most developers also use local storage:

localStorage.setItem('token', 'abc123xyz')

However, local Storage has its security concerns. It is readable by JavaScript, which means it is exposed to XSS attacks as are regular cookies.

When it comes to server calls and HTTP requests, cookies are actually the more suitable option, and as you will see, we can make them significantly more secure.

The Problem with Cookies

Regular cookies, as I established, are just key value pairs stored in a browser. And because they are stored in a browser they are exposed and can be read by anyone with access to it, including a malicious website.

You can open your browser console right now and type:

document.cookie

To see all your stored cookies.

Cookies can store a number of things. They are basically key value pairs, so you can put whatever string you want in them. They are used to store authentication and session tokens, preferences like dark mode and language, and tracking or analytics data.

The most common use case though is storing session tokens, and that is the whole reason for this article.

You set it up once via:

Set-Cookie: sessionId=abc123xyz

And from then on, the browser sends it back automatically with every request:

Cookie: sessionId=abc123xyz

This means that cookies, while convenient, create a risk surface that makes them a security concern.

In reality, anyone who gets hold of your user's token can authenticate as them and perform actions on their behalf. This vulnerability is the foundation of a very common attack called cross-site scripting (XSS), where a malicious site can read and steal your user's token and do whatever they want on your app acting as that user. Pretty scary.

HTTPOnly cookies solve this by adding a flag. A simple instruction that tells the browser one rule: this cookie is for HTTP requests only. JavaScript is not allowed to touch it.

Set-Cookie: sessionId=abc123xyz; HttpOnly

So when an attack runs:

document.cookie // "" ← the HttpOnly cookie is completely invisible

Nothing happens. The cookie is invisible but still gets sent with each HTTP request. Sweet!

A quick Note

HTTPOnly Cookie is not a silver bullet. While it solves the XSS problem sufficiently, it still leaves two very common cookie vulnerabilities that a serious attacker can exploit: attacks over insecure connections (HTTP instead of HTTPS) and cross-site request forgery (CSRF).

We can address both using two additional flags:

Set-Cookie: sessionId=abc123xyz; HttpOnly; Secure; SameSite=Lax

The Secure flag ensures the cookie is only ever sent over HTTPS. The SameSite=Lax flag helps block CSRF attacks by restricting when the browser sends the cookie across sites. If you want to be even stricter, SameSite=Strict is an option, though it can affect user experience in some cases. Lax is a sensible default for most apps.

Making it all work in Next.js

This is where it all comes together, the juicy part if you will.

Going forward I try to explain my implementation of these concepts in a recent project, the unique features in Next.js that made my decisions possible, and my specific constraints.

For a bit of context: the frontend I am building is for an AI startup. We are building an AI agent for unified customer communication. Our stack of choice is roughly Next.js for the frontend and FastAPI for the backend. We are a small team trying to ship an MVP fast. I lead development on the frontend, consuming a robust FastAPI backend.

The constraint and opportunity

One of the many design decisions we made was to handle cookie setup on the frontend. This is in addition to largely limiting how much the client directly calls the FastAPI server.

While I can't fully go into our system design here, Next.js offers features that are uniquely suited to these constraints. I will be going deep into my frontend implementation of the Auth flow specifically.

A Next.js Primer

To fully follow along there are a few things you need to understand about Next.js and its unique architecture:

The Next.js Server Next.js (specifically the modern app router) is basically a running Node.js process that receives every request, does server-side work and sends back a response. It is a real backend just one that happens to also serve your react UI.
Server Actions A newer Next.js feature that lets you write a function on the Next.js server and call it directly from a form in your UI.
Middleware (Proxy.ts) Code that runs before every request hits your pages. If you are on Next.js 15 or earlier, this file was called middleware.ts. The rename happened in Next.js 16 to better reflect what the file actually does: it sits at the network boundary and proxies requests before they reach your app. The logic is the same either way.

4.Server components vs Client components Server components are React components that never ship their code to the browser. They run on the server and can directly access databases and APIs. Client components run in the browser. Every component in Next.js is a server component by default.

5.Route Handlers Custom request handlers that allow you to build custom RESTful API endpoints in Next.js

These five concepts unlock a lot of benefits and are what allow me to implement my Auth flow within the defined constraints.
Here is the breakdown:

To elaborate: I am designing this flow to handle cookie setting on the frontend, hide the FastAPI base URL from the browser, and largely isolate my backend from external interaction. This creates a server-to-server setup instead of a client-to-server one. Next.js gives me all the pieces to make this possible.

When a new user creates an account and logs in for the first time, the form's action calls a loginAction server action. This server action takes the user's credentials and forwards them to FastAPI directly (server to server), so the browser never talks to FastAPI at all. FastAPI validates the credentials and returns a token string to the server action, which then writes the token into a cookie marked httpOnly: true. The browser receives and stores the cookie but can never read it with JavaScript.

On every subsequent request, the proxy checks for the cookie before any page loads. If the cookie is missing, it redirects to /login. If present, it lets the request through. I want to be clear that I am using the proxy for a lightweight presence check here, not as a full authentication solution. The real auth logic lives on the FastAPI side.

Once through, the Next.js server handles the request in one of two ways depending on what is being loaded. For pages and data that can be fetched at render time, server components read the cookie directly and call FastAPI server to server. For data that needs to be fetched live on the client (in my case, a live inbox that polls every 30 seconds), client components call a Route Handler instead. The Route Handler runs on the Next.js server, reads the cookie, calls FastAPI, and returns the response to the client. The token never leaves the server either way.

So there you go. My not so complicated implementation of HttpOnly Cookies with Next.js within my specific constraints.

I acknowledge there are simpler ways to achieve this, but I want to say again that every case is unique and I implemented what made sense for mine.

Have you handled Auth differently in your Next.js projects? I'd genuinely love to know what you did differently and why.