DEV Community: Ekong Ikpe

Every Generation Thinks the Next One Has It Easy 💃💃 💃

Ekong Ikpe — Sat, 01 Aug 2026 19:31:03 +0000

Is It Wrong to Watch Movies, Cartoons, or Sci-Fi? 🤔

Of course not.

We enjoy movies even though they're fictional. We appreciate cartoons
even though the characters aren't real. We watch science fiction knowing
today's imagination often becomes tomorrow's technology.

That made me think about another question:

Why is AI-assisted development treated so differently?

I'm fond of reading to keep abreast of what's happening in software and
technology.

Lately, I came across a discussion that made me realize I needed to
write a sequel to a post I published back in April, Defending Vibe
Coding: Why Syntax Might Not Be the Bottleneck
Anymore.

In that article, I argued that AI is shifting the bottleneck away from
syntax and toward system design, validation, and execution clarity.

This time, I'd like to look at why that idea still meets so much
resistance.

That discussion also helped me understand some of the reactions I
receive whenever I post or share my projects.

Nevertheless, I'm still on my vibes. 🙃

So, let's talk about it.

Every generation of engineers believes the next generation's tools make
the craft too easy.

When automatic transmissions became common, no one insisted every driver
master a manual gearbox first.

When voice-to-text arrived, we didn't demand that everyone become an
expert speller before speaking into their phones.

Most programmers today have never written a compiler, an operating
system, or a network stack from scratch. Yet we don't question whether
they're programmers.

So why is AI-assisted development treated differently?

The point isn't that fundamentals are worthless. Far from it. The point
is that the definition of a "fundamental" evolves as technology evolves.

Programming has never been about typing the greatest number of
characters. It has always been about solving problems.

Today, programming is shifting from writing every instruction manually
to designing systems, evaluating solutions, testing assumptions, and
taking responsibility for the final product.

The keyboard is becoming less important than judgment.

AI doesn't remove accountability. If an AI introduces a bug, the
responsibility is still mine. If I can't explain my architecture, defend
my decisions, or verify my software, then I haven't done my job as an
engineer.

But if I understand the system, direct its design, validate its
behavior, and stand behind every release, then whether some of the
implementation came from AI becomes a secondary question.

Every technological shift has been uncomfortable. The challenge isn't to
reject new tools or forget the old lessons. It's to carry forward the
discipline, curiosity, and responsibility that define good engineering
while embracing new capabilities.

The future won't belong to developers who refuse AI, nor to those who
blindly trust it.

It will belong to those who know how to think.

Who Owns the Thinking When You Vibe Code? 🧐

Ekong Ikpe — Thu, 30 Jul 2026 11:45:47 +0000

I’ve been thinking about the phrase “vibe coding.”

Andrej Karpathy used it to describe a way of working where you mostly let the AI write the code and you stop worrying too much about the details.

That’s a real way of working.

But I think we’ve started using the same phrase for two very different habits.

Two Different Ways of “Vibe Coding”

Type	What actually happens	Who’s doing the thinking?
Passive	AI writes it. You mostly just accept it.	Mostly the AI.
Active	You explore ideas with the AI, push back, change direction, and shape the final result.	You — with the AI as a partner.

The first one is what most people complain about.

The second one is something good builders have been doing long before AI showed up.

When an experienced person says, “This doesn’t feel right,” nobody calls it magic. We call it judgment.

That judgment isn’t random.

It comes from years of building things, breaking them, fixing them, and coming back to them later. Your brain starts noticing patterns before you can even explain them in words.

That’s why some ideas suddenly feel obvious.

They weren’t sudden. They were quietly forming for a long time.

AI just changes what happens next.

Sometimes the first idea is yours.

Sometimes the AI asks a question that shows a weak spot in your thinking.

Sometimes it offers a direction you hadn’t seen.

Sometimes it’s confidently wrong.

And this is where I think we also need to appreciate something else: our strengths are diverse, and recognizing those differences matters.

When I interact with an AI assistant, my engagement is often more like having a research assistant or an improved “2010 Google search” 🙃. The difference is that today’s assistants can interact with us in ways that can create an illusion of literacy and understanding.

That doesn't mean we should treat every assistant as the same tool.

A junior developer quickly learns that the choice of tool matters. The same way a sledgehammer is better suited to breaking concrete than a nail hammer, different AI assistants may simply be better suited to different tasks.

Gemini may be better at one thing than ChatGPT. Alexa may be better at another than Grok. And none of that should be surprising. Different tools, different strengths, different purposes.

The more properly we learn how to use these tools, the healthier our development process can become — with or without AI.

And there is another part of this that I think we sometimes overlook: people are part of the toolchain too.

Seniors eventually move on, wear out, change roles, or retire. Juniors eventually have to take over. That means appreciating the process matters. What we learn today shouldn't only help us finish today's task; it should help someone else understand, maintain, and improve what comes next.

No matter how careful we are, humans are explorers by nature. We will always discover something new, question something old, and find another direction to try. Nothing stays perfect enough to satisfy that curiosity forever.

But one thing is worth carrying forward: the willingness to relearn.

We can adopt better tools without throwing away the values that shaped us. We can let AI change how we work without forgetting why we learned to build, debug, question, and understand things in the first place.

Who spoke first doesn’t matter much.

What matters is who made the final call.

Understanding something is a bit like walking without a map. You may not know every step ahead, but you know where you’re trying to go well enough to notice when you’ve started drifting off course.

Ideas don’t always belong to one mind anymore.

Sometimes the spark comes from you.

The next step comes from the AI.

The final result grows out of the conversation between both.

That isn’t passive vibe coding.

That’s still engineering.

The real danger isn’t AI.

The danger is reaching the point where you stop asking “why” and only ask “what’s next.”

There’s a big difference between using AI so you don’t have to think… and using AI so you can think better.

The first one takes over your judgment.

The second one strengthens it.

So maybe we’ve been arguing about the wrong phrase all along.

The real question isn’t whether something was “vibe coded.”

The question is:

Who owned the thinking?

And when the AI is gone, who still understands what was built?

PWAs Cache Resources. Spirit Installs an Application.

Ekong Ikpe — Sun, 26 Jul 2026 10:09:54 +0000

Before we go into this post I earlier planned for a different topic however in the course of my vibe experience something else came up.

There is a question nobody asks when they set up a service worker:

Who owns the application lifecycle?

With a conventional PWA, the browser primarily orchestrates installation, caching, and the service worker lifecycle. The application participates in those decisions, but the browser ultimately controls when service workers are activated, how storage is managed, and what "installed" means on a given platform.

Spirit gives a different answer. The application owns installation, storage, and updates. The browser simply provides the runtime.

That is not a small distinction. It starts with one reframe:

spirit-sw.js is firmware, not middleware.

Every conventional PWA uses the service worker as a proxy — it intercepts requests and decides whether to serve from cache or go to the network. Spirit uses the service worker differently. It never serves your application files. It never touches Cache Storage. It serves a single hardcoded bootstrap string that knows how to resurrect the application from IndexedDB. The service worker is a bootloader. It boots the same way every time.

Everything else follows from that.

What Spirit is

Spirit is an IDB-native installation and boot system. Four moving parts:

spirit-grave.js — the storage layer. Pure IndexedDB, no DOM, no network. Buries a file as a Blob, exhumes it later. Nothing else.

spirit-reg.js — the installer. Runs once, on the first real online visit. Reads spirit-manifest.json, fetches every listed file, buries each one in IndexedDB under gnoke:spirit/files.

spirit-sw.js — the bootloader. Intercepts every navigation request and responds immediately with a hardcoded HTML string baked into the worker itself. That string contains an inline IDB reader — no separate fetch. It reconstructs the application from the grave: CSS injected as <style>, images converted to blob URLs, JS executed as classic scripts in manifest order. Zero network requests on boot.

spirit-revive.js — the updater. Exposes Spirit.reviveFromNetwork(). Call it from a button inside the running application. It re-fetches the manifest, re-buries changed files, and reloads only if something actually changed. Nothing runs in the background automatically.

The lifecycle comparison

With a conventional PWA:

Browser requests URL
→ SW intercepts, checks cache
→ serves cached or fetches fresh
→ background SW update check runs independently
→ new SW waits for all tabs to close (or skipWaiting forces it)
→ user may receive updated code mid-session without requesting it

With Spirit:

Browser requests URL
→ SW responds immediately with hardcoded bootstrap
→ bootstrap opens IndexedDB, reconstructs app from buried files
→ app runs — no network involved
→ update only happens when Spirit.reviveFromNetwork() is called
→ app controls when to prompt, when to reload

The update is part of the application's lifecycle, not the browser's.

What this makes possible

Given a valid installation, startup is deterministic. The same boot sequence runs every time — online or offline, first launch or hundredth. There is no cache miss, no conditional fetch, no race between a new service worker and open tabs.

Spirit is designed so updates replace the installed application as a single managed operation, avoiding the mixed-version states that can occur when independently cached assets drift. One call, one operation, one reload decision.

The bootloader is stable. spirit-sw.js is the only file that triggers the browser's own SW update cycle — and it is designed to change rarely, like actual firmware. The application underneath it can update as often as it needs to without touching the bootloader.

Where this matters and where it does not

Spirit is not a general improvement over Cache Storage. For a news site, a marketing page, a content application — the browser's built-in model is exactly right. HTTP caching, ETags, Cache Storage, and the SW update cycle were designed for that world and they work well in it.

Spirit makes sense for a different category: software that happens to be delivered via the web.

Offline-first tools where network access is intermittent or absent
Browser OS environments where the app manages its own disk
Industrial or embedded browser runtimes where update timing must be controlled
Editors and development tools that need to own their own boot sequence

Spirit was built for GnokeStation — a browser-native OS where IndexedDB is the disk, a SharedWorker is the kernel, and tabs are processes. In that context, the conventional PWA model has a fundamental mismatch. Spirit fits the architecture instead of fighting it.

The honest trade-offs

What you give up:

Browser DevTools understand Cache Storage natively. An IDB-backed virtual filesystem is more opaque to debug.
HTTP-level caching is bypassed entirely. Spirit's current change detection compares blob sizes — a content hash would be more robust and is worth adding.
reviveFromNetwork() buries files sequentially. A tab closed mid-update leaves a partially updated grave. A staged swap — write new files first, then commit — would make updates truly atomic.
The first visit still requires a real online session. Unavoidable.
navigator.storage.persist() lowers eviction risk but does not eliminate it.

What you gain:

The web delivers the application once. After that it runs from local storage entirely.
No dependency on Cache Storage eviction policies.
The application decides when it updates and what the user sees when it does.
The bootloader is stable across application versions.

The deeper idea

Spirit doesn't try to replace the PWA model. It explores a different one: treating the browser as a runtime capable of hosting installed software, rather than a document viewer that happens to cache files.

The web is used once to install the application. From then on, the browser hosts a locally managed runtime whose lifecycle is controlled by the application — not by HTTP caching semantics, not by the SW activation queue, not by storage eviction policy.

Whether that trade-off is right depends entirely on the kind of application you are building.

Spirit is built for the second kind.

And for the records my semantics for file names are my way of expressing myself, what matters to me is that the aim is achieved not the name of the file 🤓

Spirit is part of GnokeStation v2 — a browser-native OS built on SharedWorker as kernel, IndexedDB as disk, and tabs as processes. Built by edmundsparrow.

Stop Believing "Convert PDF to Original Format" Is Magic

Ekong Ikpe — Wed, 22 Jul 2026 18:56:38 +0000

💡 A recent article by @dannwaneri on AI detection motivated this thought.

People often assume that if you have the final product, you can always reconstruct how it was made.

You can't.

Take PDF as an example.

We've all seen advertisements promising:

"Convert any PDF back to Word."

That sounds impressive until you ask one simple question.

How do you know the PDF originally came from Microsoft Word? 🤔

What if it came from Photoshop?

What if it came from Illustrator?

What if it was generated by CAD software?

What if it was exported from LaTeX?

Or better still...

What if it was a handwritten note with hand-drawn diagrams that someone scanned into a PDF?

Now ask yourself:

How is any converter supposed to regenerate the original handwritten notebook?

It can't.

Not because the software is bad.

Because the software does not explicitly know the format or medium in which the document was originally created.

Without knowing whether the source was Word, Photoshop, a scanner, a notebook, or something else entirely, claiming to recreate the original is creating a false reality.

The converter can only produce the best approximation in a format it understands.

That's why "convert PDF to its original format" is usually marketing—not magic.

A PDF is a destination format.

Many completely different tools—and even pen and paper—can produce one.

This is why that discussion on AI detectors resonated with me.

AI detectors examine the final text and attempt to infer the process that created it.

Likewise, people expect PDF converters to examine the final document and somehow infer the software—or even the physical medium—that produced it.

In both cases, we expect certainty from an artifact that does not necessarily reveal its own history. 📄

Computers are excellent at transforming data.

They are not magical historians.

Sometimes the most honest answer isn't:

"This is the original."

It's:

"This is the closest reconstruction possible with the information available."

👍 Never confuse an artifact with the process that created it.

The output tells part of the story.

It rarely tells the whole story.

And perhaps that's the bigger lesson—not just for PDF converters or AI detectors, but for technology as a whole.

We spend so much time expecting tools to perform magic that we sometimes forget to understand what they were actually designed to do.

Every tool has capabilities.

Every tool has limits.

Knowing the difference is part of becoming a better engineer.

🔥 In my next piece, I'll share why learning how to use a tool is often more valuable than simply knowing that the tool exists.

Browser OS Redefined: The Desktop Metaphor Doesn't Quite Fit a 5" Screen Browser

Ekong Ikpe — Sun, 19 Jul 2026 13:34:01 +0000

GnokeStation is a browser OS: it boots its own environment inside the browser, the same way a traditional OS boots hardware. Tabs are processes. IndexedDB is disk. A SharedWorker is the kernel coordinating all of it. It doesn't need to touch your device's hardware to earn the name — the browser is the platform, and GS2 runs it like one.

I had to stop pretending a phone is just a tiny PC and give these apps their own world.

Gnokestation (GS1)*
Since I'm always on my phone instead of a PC, treating my tabs as full-blown apps just makes perfect sense for my workflow.

The honest answer for why I moved from GnokeStation to GnokeStation 2 isn't "GS1 was broken." It's that I was trying to run a desktop-shaped UI on a 5" screen, and no amount of polish fixes that mismatch.

GS1 worked. That was never the problem.

GnokeStation did what it set out to do — a browser-native OS, SharedWorker kernel, apps as windows on a shared desktop canvas. It ran. It held state. It felt like an OS.

But try running Windows 10 or 11 on a 5" screen — even if every pixel renders correctly, it's not usable. That's what GS1 felt like on my phone. The desktop metaphor — shared canvas, floating windows, window chrome — assumes screen real estate I didn't have. The code wasn't the issue. The paradigm was.

GS2: The realization - tabs don't need a desktop under them

The fix wasn't a redesign. It was dropping an assumption.

If each tab is its own process — not a window on a desktop, but a full-screen app that owns its own canvas — there's no shared desktop to shrink. Screen size stops being a single constraint you're fighting across every app, and becomes a per-app concern each tab handles on its own.

Gnoke-station2 (GS2)* That's GS2: tabs as processes. Each one gets the whole screen when it's active. No window management overhead, no chrome eating into 5 inches of usable space, no cramming.

Every app in GS2 is built independently, styled on its own terms. But there's a deliberate pecking order to how styles load — the shell always gets the last word. No matter what an individual app tries to do visually, it can't accidentally break the look of the bar, the icons, or the chrome around it. Independence for each app, but the whole still holds together.

Rehydration: the part that makes it not feel like "just tabs"

Multi-tab browsing on mobile has a known problem: the OS kills backgrounded tabs for memory constantly. Normally that means losing your place — reload, re-navigate, re-enter data.

GS2's gnoke-spirit layer persists tab state to IndexedDB continuously, so when the browser reclaims a tab's memory and you reopen it, it rehydrates — not a fresh load, a resume. That's the difference between "a tab that died" and "an app that was suspended," and it's what makes 50 tabs in GS2 feel closer to 10 native app instances than 10 browser tabs.

I don't need the cloud to keep my world running. My phone holds the truth, and the network is just an option.

So why would anyone leave a Play Store app for this?

Fair question, and I don't think the honest answer is "GS2 is better at everything." It isn't. If you need something to just be great at one thing, a native app that's built and tuned for exactly that thing will usually win.

Where GS2 makes a different tradeoff:

No one installs Adobe Premiere Pro on a machine with 512MB of RAM — and nobody should have to install ten separate native apps just to get ten small utilities on a low-end device either. GS2's apps are small, share one runtime, and don't each carry their own bundled webview/engine overhead.
20 tabs in GS2 vs. 10 tabs in Chrome on the same low-end phone — GS2 reuses one browser webview across every app instead of each one spinning up its own runtime. Roughly double the tabs for the same memory footprint, because the overhead isn't being duplicated per app.
Offline-first by default. Not "works offline if you toggle a setting" — the storage layer (GnokeStore, unified over IndexedDB) is the source of truth, network is optional.
No ads, no accounts, no server dependency. It's not a business model that needs your attention or your data. It just runs.
A URL is already an app. No store listing, no install screen, no permissions dialog, no waiting on a review queue for updates. Tap "Add to Home Screen" and you're done — the next time you open it, whatever changed is already there. Installing a native app is a process. Installing GS2 is a tap.

That's not a pitch that GS2 replaces your Play Store apps generally. It's a pitch that if you're on a low-end device juggling a dozen small tools, running them as lightweight tabs sharing one kernel is a genuinely better use of your hardware than a dozen separate native installs each paying their own memory tax.

The takeaway

GS1 proved the architecture works. GS2 made more sense knowing the architecture only fits once I stopped assuming a desktop has to sit underneath it. Same kernel philosophy, different canvas model — and on a phone, it finally feels like the architecture matches the device.

It's not finished. But it already does the one thing it needed to prove: a browser OS can be a realistic idea on the smallest screen you own.

GSv1

GS2

Disconnected: A 24-Hour Stress Test for Humanity 🥸

Ekong Ikpe — Tue, 14 Jul 2026 15:27:11 +0000

This isn't a wish for the internet to stop — just a moment to imagine what it'd mean to breathe without it.

Not everyone, but a huge percentage of the world now relies heavily on the internet.

What if it were unavoidably shut down for just 24 hours? How long would those hours actually feel — and how much would they reshape our daily routines?

I see the irony everywhere already. The moment a page hangs, I instinctively dial a USSD code to check my data balance. I know someone who pings google.com just to see if he's still connected — using the internet to check whether the internet is still there.

The first hour would probably be spent staring at the network icon, refreshing pages, waiting for life to resume. That's when we'd notice how much of the day quietly depends on the cloud: deliveries stall, payments freeze, navigation disappears, businesses pause. Millions would discover just how many invisible gears keep everyday life moving.

Then the smaller shifts. Looking at the sky to guess the weather instead of opening an app. Realizing the only people who "exist" are the ones actually in front of you. Sitting in a room where the loudest sound is the silence of the feed.

Maybe one day, staying offline will be a skill of its own.

Have we gotten so used to consulting the network before taking a step that we've stopped trusting our own judgment?

Perhaps 24 hours of silence wouldn't just be an outage. It would be a reminder — that before the cloud, there was memory. Before search engines, there was curiosity. Before notifications, there was presence. And before constant connection, we still knew how to walk on our own.

If you asked me, What cloud or internet service would you miss most for a day?

For me, I don't remember the last time I went 48 hours without Gemini.

Owning Compute vs Renting Intelligence ✍️

Ekong Ikpe — Sat, 27 Jun 2026 09:52:41 +0000

About two weeks ago, the U.S. government directed Anthropic to suspend access to its latest frontier models. This week, OpenAI was required to limit the rollout of GPT-5.6 over cybersecurity concerns.

Whether you agree with those decisions or not isn't the point.

The point is that they highlighted something many of us have quietly ignored for years.

If your software depends entirely on somebody else's API, then part of your software is no longer under your control.

Your application can be rate-limited. Features can disappear overnight. Pricing can change. Access can be restricted by policy, regulation, geography, or business decisions you have no say in.

That's not ownership. That's renting intelligence.

For years, local-first development was treated like a niche philosophy. People associated it with privacy enthusiasts, hobbyists, or developers who simply didn't want to manage servers.

Today it feels less like nostalgia and more like common sense.

The conversation is no longer just about privacy.

It's about availability.

It's about resilience.

It's about building software that continues to work even when the internet, an API, or a provider decides otherwise.

This doesn't mean cloud computing is dead. Far from it.

The cloud will remain an important part of our industry.

But we've reached the point where depending on it for everything is becoming an architectural risk, not just a technical decision.

I don't think we're witnessing the end of the cloud.

I think we're being reminded of the value of a parallel ecosystem.

One where intelligence isn't rented—it runs locally.

One where software doesn't ask permission to keep working.

One where the browser is treated as a capable computing platform, not just a window into someone else's server.

No recurring API bills.

No mandatory internet connection.

No unnecessary data leaving the device.

We don't need billion-dollar server farms to solve every problem.

Sometimes a browser tab, local compute, and well-designed software are enough.

For the past year, that's the direction I've been exploring: treating the browser less like a document viewer and more like a sovereign operating system capable of running meaningful software entirely on the client.

Maybe the future isn't cloud-first.

Maybe it's cloud-optional.

Because if recent events have shown us anything, it's this:

The more your software depends on someone else's infrastructure, the less independent it really is.

There's nothing as soothing as having software that works whether there's an internet connection or not. 😎

Kitana: Beyond Token Prediction: Building AI with Human Cognitive Structure

Ekong Ikpe — Sun, 21 Jun 2026 06:10:24 +0000

What If Language Understanding Starts With a Dictionary Instead of a Model?

LLM → pattern matching → guessing → hallucination.

That’s the standard pipeline we accept today.

What if understanding language doesn’t start with prediction… but with structure?

🧠 The thing everyone skips

Every modern AI system eventually scales into:

more parameters
more data
more compute

And yet the same problem keeps showing up:

Meaning is still unstable.

Not compute. Not storage.

Meaning.

📚 The overlooked system already exists

A dictionary already contains something interesting:

A–Z defined
0–9 defined
symbols defined
every word has meaning
every word connects to other words

It’s not random text.

It’s a structured semantic network.

Not perfect.

But structured.

✍️ The simple realization

No human knows every word in a dictionary.

But humans still learn language.

So the question becomes:

What if understanding is not stored… but constructed?

🧩 The direction I started exploring

Instead of building a model that predicts language, I started exploring something else:

A system that:

starts from basic symbols (A–Z, 0–9, characters)
builds into spelling → words → grammar → meaning
uses a dictionary as the grounding layer
connects meaning through structured relationships
learns progressively like a curriculum

Not guessing.

Tracing meaning step by step.

🌊 The core idea (Kitana)

Kitana is not a traditional language model.

It is a cognitive system where:

knowledge is structured (dictionary grounding layer)
learning is progressive (like schooling)
meaning is connected (graph / “tank” structure)
understanding is dynamic, not stored facts
reasoning comes from relationships, not prediction

⚠️ Still early

Right now it’s unstable.

Language is messy:

slang
ambiguity
contradictions
exceptions

And I’m still testing how far structure can go before it breaks.

But one pattern keeps repeating:

The system keeps returning to definitions instead of guesses.

🔥 Final thought

Maybe language understanding doesn’t start with intelligence.

Maybe it starts with:

structure strong enough to make intelligence emerge.

How we curb hallucination

Ekong Ikpe — Tue, 16 Jun 2026 14:03:48 +0000

Artificial intelligence is often blamed for hallucinations as though they emerge from nowhere. In reality, most hallucinations are the result of misalignment—between the system, the task, and the expectations placed upon it.

Reducing hallucination is less about chasing perfection and more about understanding the environment in which intelligence operates.

1. The Core Persona. 😎

Like a skilled artisan using the proper chisel, an AI requires conscious direction. Before any model is deployed, developers must establish its distinct boundaries and operational capabilities, ensuring the technology aligns with human intent from the start.

An undefined system is an unpredictable system. The clearer the purpose, the lower the probability of deviation.

2. The Mismatch Problem. 🤦

We often encounter a conceptual error, much like attempting to use a basic text editor for complex graphic design.

Consumers frequently overrate these systems, forgetting that an AI lacks true situational consciousness. It does not understand the unspoken objective behind a request. It acts upon available information, patterns, and constraints.

When expectations exceed the architecture's intended purpose, friction becomes inevitable. The hallucination is often not the cause of the mismatch—it is the symptom.

3. The Logical Selection. 🧘

Effective workflow relies on choosing the right apparatus for the job rather than expecting a single tool to perform every function flawlessly.

You do not place images inside Notepad documents simply because a particular developer insists their version can handle them. A DocX file or a dedicated word processor was designed for that environment. Notes are for text.

The distinction is not capability alone; it is native capability versus forced execution.

A highly skilled designer may push CorelDraw to perform deep Photoshop-level raster manipulation. The result may even be impressive. Yet the effort itself reveals the mismatch. The designer is working against the environment rather than with it. Meanwhile, a less experienced Photoshop user can often achieve the same outcome with significantly less friction because the tool was architected for that purpose from the beginning.

The same principle applies to artificial intelligence. Expecting a basic or mismatched system to imitate the behavior of a specialized architecture is a conceptual error. Reliability emerges not from forcing one instrument to perform every task, but from selecting the instrument whose natural design already aligns with the objective.

Familiarity and precision should guide our choices, ensuring the digital environment matches the complexity of the task at hand.

4. The Builder's Responsibility. 👌

A tool should be presented as what it is, not what marketing wishes it to become.

Much of the confusion surrounding artificial intelligence does not originate from the user. It originates from unclear boundaries, exaggerated claims, and the failure to communicate limitations honestly.

A smart calculator does not become intelligent because someone labels it AI. A pattern-matching system does not become conscious because it produces convincing language. Renaming a capability does not expand it.

The responsibility therefore extends beyond the consumer. Builders, developers, and organizations must clearly communicate what their systems can do, what they cannot do, and where their reliability begins to decline.

Honest representation creates appropriate expectations. Appropriate expectations create appropriate usage. Appropriate usage reduces friction.

When a tool is accurately described, users naturally place it in the correct environment. When a tool is misrepresented, disappointment becomes inevitable because the promise and the architecture no longer align.

The objective is not to make every system appear more intelligent than it is. The objective is to ensure that capability, description, and expectation remain synchronized.

Truthful boundaries are not a weakness of a product. They are evidence of confidence in its actual purpose.

Conclusion

Hallucination is rarely an isolated defect. More often, it is the visible consequence of a deeper misalignment between purpose, architecture, and expectation.

Define the system.

Understand its boundaries.

Select the appropriate environment.

Communicate it honestly.

Refine through feedback.

The objective is not to eliminate uncertainty entirely. The objective is to reduce unnecessary friction between human intent and machine execution.

When that alignment is achieved, hallucination becomes less of a mystery and more of a manageable engineering problem.

Photo credits = chatgpt 🙏
Post credits = Gemini 🤝

Need a more powerful AI, find out about kitana

Gnoke AI Was the Plan. Then Kitana Happened. 🤔

Ekong Ikpe — Mon, 15 Jun 2026 14:08:20 +0000

LLM — pattern matching — guessing — hallucination.

The holy trinity of modern AI "intelligence." Throw enough parameters at it and after enough guesses it usually lands on something useful. Not wrong, exactly… just started way too heavy. 🤧

Don't get it twisted I ain't trying to solve hallucination - the best intelligence will garbage out the worst inference, just feed it with the right input with wrong intent 😂

Gnoke AI (browser-based sLM) was the original plan.

That was the target.

A small language model that could run inside the browser. Lightweight. Practical. Built for Gnoke-Station 2.

Nothing dramatic. Just engineering constraints and a clear goal.

But the more I worked on it, the more the same problem kept showing up.

Not compute.

Not storage.

Not architecture.

Meaning.

How do you make a system understand language without turning it into something massive?

The thing I kept ignoring

Every direction I explored eventually bent back to the same place.

More data.

More parameters.

More complexity.

And I kept thinking:

There has to be a simpler layer under all of this.

Something closer to how humans actually deal with language.

Not how we predict words.

But how we understand them.

The cheat book — An Oxford or Webster dictionary 👌

At some point, I stopped and looked at something too obvious to notice.

A dictionary.

English already contains a structured system where:

A–Z is defined
0–9 is defined
Special characters are defined
Every word has meaning
Every word has usage examples

It's already a complete semantic handbook.

Not perfect. Not complete.

But structured.

Then another thought hit me:

No human knows every English dictionary word…

but we still know how to learn 🤷

That's the part that matters. Not an AIO but super intelligent enough to know when to use a medical dictionary or physics textbook verified by the and trusted.

Kitana wasn't planned

I set out to build a small language model. What emerged was something closer to a language engine — one that treats the dictionary not as training data, but as the operating system.

Gnoke AI was trying to generate language.

Kitana started leaning toward something else:

Understanding language through structure, not prediction.

Not guessing what comes next.

But tracing what something means.

Step by step.

Definition by definition.

I don't think this is finished

Right now, Kitana is still unstable.

Still being tested against ambiguity, slang, exceptions, and all the messy parts of human language.

And honestly, I don't know where it fully lands yet.

But one pattern keeps repeating:

Every time I try to move it toward a standard AI approach…

It moves back toward definitions.

The smallest dictionary is capable.

Once inference, comprehension, and understanding exist — evolution is unstoppable. Out of the box.

I need to stop here 😂

I think I just made PWAs obsolete. Or maybe I upgraded them. I genuinely can't tell. 🤔

Ekong Ikpe — Mon, 08 Jun 2026 11:38:07 +0000

I watched a movie yesterday (Signal One, 2026) — just when I needed a sci-fi break.

Okay 🤦 I'm obsessed with the browser but don't think all I do is Gnoke. 😉

Why This Post Matters

PWAs have a Service Worker. A manifest. Maybe some IndexedDB if you're disciplined.

And when Android kills your tab — because Android kills everything, eventually — you come back to a blank page. Or the home screen. Or whatever the browser decides to show you.

The app is still "installed." The data is still there. But the session is gone. Where you were. What you were doing. That context that made the app feel like yours.

We just accept this. We've always accepted this.

I don't accept it in Gnoke Station 2 — my browser OS where tabs are apps. Shopping list. Council. Notes. They're supposed to feel real.

Real apps don't forget you.

What PWAs actually give you (and what they don't)

Service Worker caches your assets. Cold boot works offline. Good.

Manifest tells the OS your name and icon. Install prompt appears. Good.

Neither of them knows where you were.

That's the gap. PWAs solved the delivery problem. Nobody solved the session problem.

Every PWA on your phone has the same quiet flaw: open it after Android clears it from memory, and you start over.

Gnoke-Spirit as a solution

Before the tab dies — on pagehide — snapshot everything. Where the user was. What they typed. The URL hash. Scroll position. Every form field that isn't a password.

Write it to IndexedDB. Not localStorage — IndexedDB survives process kills.

On the next boot, before the app renders anything, read it back. Restore it. Fire an event.

The app wakes up exactly where the user left it. Not approximately. Exactly.

I called it resurrection.

It's best-effort — pagehide as the primary trigger, visibilitychange as backup, plus debounced input saves. Abrupt kills may lose the last few seconds. Still vastly better than starting from scratch.

The part I didn't expect

Once spirit was working I looked at the other pieces sitting around it.

Service Worker. Already running. Knows whether the page was served from cache or the network.

Manifest. Already declared. Handles the OS install layer.

Spirit. Knows the full session state.

Three things. Three completely separate browser concerns. Not one of them talks to the others.

But I had boot.js — a single file every Gnoke app loads first. I thought: what if boot.js just asked all three before firing?

{
  source: 'cache',        // SW told boot.js this
  resurrecting: true,     // spirit found a snapshot
  snapshot: {
    hash: '#list:abc123',
    scroll: { x: 0, y: 340 },
    forms: [...]
  }
}

One event. One decision point. Full context. No manual wiring.

Instead of this — per app, every time:

window.addEventListener('load', () => {
  const saved = localStorage.getItem('last-page');
  if (saved) navigateTo(saved);
});

navigator.serviceWorker.ready.then(reg => {
  const fromCache = reg.active?.state === 'activated';
  if (fromCache) skipLoadingScreen();
});

You get this:

document.addEventListener('gnoke:boot', ({ detail }) => {
  if (detail.resurrecting) navigateTo(detail.snapshot.hash);
  if (detail.source === 'cache') skipLoadingScreen();
});

The apps get smarter for free. The coordinator does the work once, centrally.

Against native apps

Android kills your native app. Android kills your browser tab. Same question either way: how do we get the user back to where they were?

Native platforms have lifecycle APIs, Bundles, ViewModels, Room, CoreData — a decade of patterns built around surviving process death.

The web has mostly been pretending the problem doesn't exist.

Spirit isn't doing something native apps can't. It's bringing the same lifecycle resilience to the browser with a tiny amount of vanilla JavaScript.

Spirit treats browser state as the source of truth — the URL, the hash, scroll position, focused field, form values. Those things already exist. Spirit snapshots them. The restore isn't a replay. It's a read.

Spirit doesn't know what a shopping list is. It doesn't need to. If the list encodes its state as #list:abc123 — Spirit captures it automatically.

The hash is the state. Spirit snapshots it. Boot restores it.

The diagram

[ Service Worker ] ---> (Network Layer)  \
[ Web Manifest   ] ---> (OS Layer)        +---> [ boot.js ] ---> Event: `gnoke:boot`
[ Gnoke Spirit   ] ---> (Session Layer)  /

Service Worker owns the network layer.
Manifest owns the OS layer.
Spirit owns the session layer.

Boot.js sits at the intersection. Making it conscious of all three costs almost nothing.

What I'm actually claiming

The delivery problem was solved by Service Workers.
The install problem was solved by manifests.
What was missing was a lifecycle.

Not storage. Not caching. Not installation. Continuity.

Service Worker gave PWAs a body.
The manifest gave them an identity.
Spirit gives them a memory.

That feels less like a webpage. And a lot more like an application.

The coordinator pattern is part of Gnoke Station — open source, MIT.

If you're a senior dev who works close to the browser — primitives, lifecycle, platform APIs — I'd genuinely welcome your eyes on the architecture. 🤷

References

— Edmund Sparrow, Gnoke Suite

Gnoke Skins: Every Device Already Has a Face. It Just Hasn't Rendered Yet.

Ekong Ikpe — Wed, 03 Jun 2026 11:28:25 +0000

There is a gap between what a device knows and what it shows.

Your MiFi router knows signal strength, battery level, how many people are connected, how much data is left. Your AC unit knows the room temperature, the mode, the timer. Your PWM controller knows the duty cycle, the frequency, the load. A signal tower on a factory floor knows whether the line is running, warning, or stopped.

They all know. Most of them just never figured out how to tell you in a way that felt human.

That is not a hardware problem. That is a skin problem.

The $15,000 lesson

A while back I built SignalTower — an Andon-style stack light controller that runs in a browser tab. The point was simple: a standard industrial HMI panel setup costs $15,000 once you add the proprietary OS, the vendor lock-in, the license fees. The browser already ships with Web Serial, WebUSB, Web Bluetooth. The hardware APIs are free. The screen you already have.

SignalTower was one proof. But the skin was never meant to be device-specific. Any hardware that speaks JSON deserves a face.

What if any device that speaks JSON could get a face — designed for humans, not firmware teams under deadline?

Gnoke-Skins

Device (JSON) → config.js → Gnoke skin → Browser

Three pieces. That is the entire architecture.

The device — any hardware that exposes a JSON endpoint. ESP32. Arduino. Raspberry Pi. STM32. A MiFi router. An AC unit. A PWM controller. A generator. A signal tower. Anything.

config.js — one file. You declare the host, map the keys, define presets. Nothing else. This is the only file that changes per deployment.

The skin — a single index.html. Pure display logic. Zero firmware dependency. Swap skins freely. The device never changes.

The firmware bridge is the only device-specific work. Everything else is reusable. One integration per hardware model — after that, every future UI is a skin change, not a firmware project. For manufacturers, that means the frontend never blocks a product launch again.

Three worlds, same idea

I built three skins so far. Each one is a different proof of the same philosophy.

MiFi — live demo

Most MiFi users never change their factory default SSID. Not because they don't want to — because 192.168.1.1 gets in the way.

The skin puts configuration directly on the device screen: SSID, password, connected users, data usage. Navigated with three physical buttons on the device body. T9 keyboard for field editing. 5-second hold-to-reset. Full boot sequence.

No phone. No laptop. No IP address typed into a browser at midnight while your internet is down.

A device that ships with this skin means the customer never sees 192.168.1.1. They see an interface that was designed for them. The telco that ships this first owns that experience.

PWM Controller — live demo

Industrial dark. Large touch targets. Segmented duty cycle bars. Preset buttons: Lathe, Pump, Drill, Boost.

The kind of interface a workshop operator can read from across a room, with gloves on, under bad lighting. Not because it is pretty — because it is right for its context.

AC Remote — live demo

Retro LCD aesthetic. Tactile button feel. Mode, fan speed, sleep, timer, swing.

Works as a phone remote or as an on-device touchscreen. Same skin, two deployment contexts. The device does not change. The surface does.

The deeper thing

A device without a screen is not a limitation. Your phone fills in. Point a browser at the JSON endpoint — the skin renders. The device gains a face it never had from the factory.

A device with a screen but terrible UI is not stuck. The screen runs a browser. The skin loads. The firmware team never has to touch the frontend again.

A device that does not exist yet — that you are sketching on paper right now — can have its UI built before the hardware ships. The skin is decoupled. The bridge connects later.

This is what I mean when I say the face is already there.

The hardware is already broadcasting. The JSON is already flowing. The state is already known. The only missing piece was a layer that catches all of it and renders it as something worth looking at — something a real person can read, navigate, and trust.

Gnoke-Skins is that layer.

The repo is MIT BSL licensed. If you build hardware and you have ever thought "my users deserve better than this" — this is what that looks like before a framework arrives to complicate it.

gnoke-skins.netlify.app
github.com/edmundsparrow/gnoke-skins

Built on an Infinix phone. Deployed to Netlify. Zero dependencies. Because the constraint is part of the philosophy.