Tosin Amuda — Blog

How the Global South Can Enter the AI Value Chain: Nigeria’s Case

2026-05-13T00:00:00.000Z

A Nigeria-focused strategy for entering the AI value chain through open-source models, local data, talent, compute, and diaspora transfer.

I will answer from Nigeria's perspective, though the same logic applies to countries with similar constraints: limited frontier AI capital, shallow advanced research depth, and large populations entering an AI-shaped labour market. Nigeria's AI strategy should be value-chain entry. The country should build the layers of the AI economy it can realistically own now, then use them to move upstream over time.

The first reachable layer is open-source and small-model capability. With open-weight models, Nigerian teams can fine-tune, compress, evaluate, and serve useful systems without frontier-scale compute. Around that layer, Nigeria should build local datasets, evaluation benchmarks, applied AI talent, targeted compute, and diaspora knowledge transfer. The goal is to become production-adjacent now and selectively productive over the decade.

Start with open-source and small models

Open-source and small models matter because they give countries outside the frontier a practical production surface. A frontier model may require capital, chips, electricity, and research density that Nigeria does not yet have. A small domain model requires a narrower but reachable stack: good task data, capable engineers, evaluation discipline, inference infrastructure, and enough compute for fine-tuning. That is where Nigeria can start producing capability rather than only watching the frontier move.

The unit of progress should be concrete: a compressed speech model, a curriculum benchmark, a legal retrieval model, a Nigerian-language evaluation suite, a fine-tuned agricultural advisory model, or a low-cost inference service. Each artifact trains people, creates reusable infrastructure, and pushes the country further into the AI value chain.

Create a National AI Value-Chain Agenda

The first move is a National AI Value-Chain Agenda. This should not be a broad digital transformation plan. It should map the specific layers where Nigeria can capture value: open-source model adaptation, small-model training, dataset creation, evaluation infrastructure, inference deployment, AI tooling, and applied research.

The agenda should identify which institutions own each layer, how funding flows into them, and what measurable outputs count as progress. A National AI Adviser should coordinate ministries, universities, regulators, cloud providers, research institutes, and private builders, with legislation within the year so the structure survives electoral cycles.

Fund an Open-Source and Small-Model Programme

The second move is an Open-Source and Small-Model Programme. Nigeria should support teams that can adapt open-weight models, compress them, evaluate them, and serve them cheaply under local infrastructure constraints. This is not a side project. It is the first production layer available to the country.

The programme should fund model adaptation labs in universities, startup teams building narrow models, and public-interest projects that produce reusable tooling. Success should not be measured by announcements. It should be measured by released models, documented evaluations, lower inference costs, reproducible training pipelines, and engineers who can repeat the work.

Treat data and evaluation as national infrastructure

The third move is a Nigerian Data and Evaluation Mission. Data and benchmarks are economic assets, not merely research inputs. Foreign labs have little incentive to curate Yoruba, Hausa, Igbo, Pidgin, and Nigerian English speech data at the quality Nigeria needs. They will not build serious benchmarks for Nigerian curricula, legal procedure, agricultural conditions, clinical workflows, or local administrative tasks unless there is commercial pressure to do so.

Nigeria should therefore fund these datasets and benchmarks as national infrastructure. A country without local data cannot adapt models deeply. A country without local benchmarks cannot tell whether its systems work. A country with both can train, evaluate, negotiate, and build from a position of greater leverage.

Build an applied AI talent pipeline

The fourth move is an Applied AI Talent Pipeline. Nigeria's short-term priority should be applied AI engineers and applied researchers: people who can fine-tune models, build retrieval systems, curate datasets, design evaluations, compress models, deploy inference, and monitor failure modes. This group is more urgent than a small number of frontier theorists because it builds the working base on which deeper research depends.

In the medium term, universities should teach discipline-specific AI in fields where the technology will reshape professional work, including medicine, agriculture, education, law, finance, and engineering. In the long term, Nigeria needs PhD-level researchers in machine learning, optimisation, systems, safety, and model architecture. The order matters. Applied work creates the datasets, failures, research questions, and institutional demand that make serious doctoral research viable locally.

Negotiate targeted compute access

The fifth move is targeted compute access. Nigeria should not begin by trying to match hyperscale training clusters. It needs compute for inference, fine-tuning, evaluation, synthetic data generation, and small-model training. The immediate step is to negotiate cloud credit pools with major cloud providers for accredited researchers, startups, and public-interest teams.

In parallel, Nigeria should build one reliable, independently powered GPU cluster at a federal university or national research centre, sized for fine-tuning and inference rather than frontier pretraining. Over five years, that cluster can grow into a small national research compute network, located only where power, fibre, cooling, security, and environmental conditions are credible.

Use diaspora knowledge transfer deliberately

The sixth move is diaspora knowledge transfer. Nigerians working in frontier labs, cloud companies, AI startups, and research universities abroad are one of the country's fastest routes to frontier exposure. The mechanism should be practical: paid sabbaticals, remote mentorship, joint research, visiting residencies, and later repatriation offers tied to real authority, compute access, and funded teams.

Symbolic homecoming campaigns will not matter if there is no serious infrastructure to join. Diaspora transfer should plug into the open-source programme, data mission, talent pipeline, and compute network.

Own reachable layers, then climb

Once these foundations compound, Nigeria can move from production-adjacent capability to selective production. A technically insulated National AI Agency could then coordinate strong small and domain-specific models in areas where Nigeria has data depth, engineering capacity, and sustained demand. Its job would not be to imitate OpenAI. Its job would be to own the parts of the stack where Nigeria can build advantage, then climb from there.

Nigeria will not be sidestepped because it failed to build a frontier model in 2026. It will be sidestepped if it owns no layer of the AI economy: not the datasets, not the benchmarks, not the model adaptation labs, not the inference infrastructure, not the applied talent pipeline, and not the research institutions that turn today's tools into tomorrow's capability. The first task is to own the layers within reach. Then climb.

This essay began with an October 16, 2024 tweet where I argued for the baby steps Nigeria can take in AI R&D despite its power challenges.

In May 2026, I adapted that thought into an answer to one of the questions in Dwarkesh Patel's Blog prize for the big questions about AI: what countries outside the AI production chain should do to avoid being sidestepped by transformative AI.

Building a Generative UI Agent for Bob, with Bob, by Bob

2026-05-09T00:00:00.000Z

How I built a task-specific harness around Bob that generated, bundled, and sandboxed live UI apps for IBM Think 2026.

At IBM Think 2026, a visitor could come up with an idea, watch Bob plan and write the code, and see the app running on the booth screen two minutes later. IBM had just unveiled Bob, its new coding agent, at the keynote, and the booth was where conference visitors got to try it. Bob is built for complex enterprise development, and my job was to demonstrate those capabilities inside a strict two-minute window.

To deliver that, I built a generative UI agent for the booth. Visitors could describe an app from scratch, or pick an existing example and replay the flow.

This is generative UI in practice: software generated on demand, shaped entirely by a user's prompt rather than served from a pre-built library. It offers a glimpse of a future where interfaces are personalized and ephemeral, created in the moment of the visit to match a visitor's specific intent.

The experience ran on a task-specific harness I built around Bob. In agentic AI vocabulary, a harness covers everything except the model itself: the tools, prompts, modes, and the loop that runs them. Bob already has its native harness. The task-specific harness I added sits on top, wrapping Bob's open-ended generation in deterministic input, build, and render layers.

The experience was built for Bob, the harness that made it possible was built with Bob, and every app a visitor saw was authored by Bob. In the rest of this article, I will share how I designed the architecture to handle the booth constraints, what I learned from the execution, and where there is room for improvement.

Design goals

The loop had to complete while a visitor was still standing there. That single constraint gave the generative UI agent five design goals.

Two-minute cycle. The system had to move from prompt to rendered UI in roughly two minutes. Anything longer would turn the experience from a live demo into a waiting screen.
Predictable structure. Bob could generate the app, but the task-specific harness needed to know where the entry file lived, which files belonged to the app, and what to bundle. The output needed a known shape, not just a pile of generated files.
Predictable dependencies. Generated code could only import what the host had already declared. Surprise modules at runtime would make the app harder to bundle, harder to debug, and harder to trust.
Sandboxing. The generated app needed to render without sharing the host page's styles, globals, or storage surface. The harness had to let the code run while keeping it inside a controlled browser boundary.
Iteration support. A visitor could ask for changes after the first render. Continuing the app needed to be a storage lookup against the same conversation workspace, not a fresh bootstrap from scratch.

Those goals shaped the task-specific harness around BobShell: a context builder to constrain Bob's input, a conversation workspace for predictable file structure, a BobShell subprocess for the generation step, an esbuild bundler for deterministic build, an HTML wrapper for safe import resolution, and a sandboxed iframe for isolation.

The task-specific harness

The generative UI agent is BobShell wrapped in a task-specific harness. The task-specific harness compressed Bob's coding-agent capability into a loop that could run in front of a visitor. Because Bob did not yet have an agent SDK, the task-specific harness invoked BobShell, Bob's CLI, as a non-interactive subprocess.

From there, the pipeline was straightforward: a prompt entered through the chat panel, the context builder assembled the right input, BobShell generated files, esbuild produced a browser-runnable bundle, and the host UI mounted the iframe preview.

Figure 1: the agent, end to end.

The harness separates four concerns: input, generation, bundling, and rendering.

1. Context Builder

The user prompt does not go straight to BobShell. It first passes through a context builder, a backend module that assembles the input BobShell needs for the current turn.

That input depends on mode. The user selects Plan mode or Code mode from the frontend, and the context builder assembles the matching prompt. The booth experience ran plan to code: a visitor generated a plan, approved it, then triggered Code mode.

In Plan mode, the prompt includes the user's request, the workspace path, and a custom instruction that asks Bob to produce a plan document with four sections:

1. Overview
   What the app should do and what experience it should create.

2. Architecture
   The high-level structure of the app.

3. Component breakdown
   The main UI components and what each one owns.

4. Manifest
   The file list, file roles, and entry point esbuild will use.

The planning prompt tells Bob to split larger apps into smaller files first, and the manifest then declares those files explicitly so the harness knows what to bundle.

Design Note: The 600-line limit. In testing, a single write_to_file call struggled once it grew past roughly 600 lines. That failure is why the manifest exists.

The manifest:

{
  "files": [
    { "path": "src/App.jsx",      "role": "entry",     "purpose": "..." },
    { "path": "src/Scenario.jsx", "role": "component", "purpose": "..." },
    { "path": "src/Summary.jsx",  "role": "component", "purpose": "..." }
  ],
  "entryPoint": "src/App.jsx"
}

The manifest is the interface between Bob's open-ended generation and the harness's deterministic build step. It gives both sides a shared file contract before code generation starts: Bob knows what to create, and esbuild knows where to start.

In Code mode, the prompt includes the approved plan, workspace path, conversation history, and any existing files in src/. That lets Bob edit in place during iteration rather than regenerate the app from scratch.

The Code-mode prompt also carries runtime constraints. Because the generated app runs inside an iframe, the prompt tells Bob not to assume access to the parent page, cookies, localStorage, or direct cross-origin APIs. The browser boundary becomes a generation constraint before Bob writes any code.

2. Conversation Workspace

Each session gets a conversation ID, and that ID owns the files Bob works with:

generated/conversations/{conversation_id}/
  src/    # source files Bob writes
  build/  # bundled output from esbuild
  logs/   # agent traces
  docs/   # plan documents

The workspace sits on a volume mount backed by object storage. A database would have been overkill for a handful of JSX and markdown files per conversation, and ephemeral Docker storage would have lost everything on container restart. The volume mount sits between those: files survive container restarts without requiring a schema layer.

The workspace also makes iteration cheap. When a visitor asks for a change, the harness reloads the workspace, sends Bob the plan and existing files, and lets Bob edit in place. Continuing becomes a storage lookup, not a full restart.

3. BobShell Subprocess

Once the context builder assembles the prompt, the harness launches BobShell as a non-interactive subprocess: one invocation per turn, prompt in, output out, wait for completion.

The command shape looked like this:

export BOBSHELL_API_KEY="your-api-key-here"

bob \
  --auth-method api-key \
  --chat-mode={mode} \
  --yolo \
  -p "{prompt}"

The {prompt} comes from the context builder. The {mode} comes from the user's selection in the frontend: usually plan or code, with room for custom modes.

In Node.js, the harness can spawn that command as a child process:

import { spawn } from "node:child_process";

type RunBobShellOptions = {
  mode: "plan" | "code" | string;
  prompt: string;
  apiKey: string;
  cwd: string;
  onStdout?: (chunk: string) => void;
  onStderr?: (chunk: string) => void;
};

export function runBobShell({
  mode,
  prompt,
  apiKey,
  cwd,
  onStdout,
  onStderr,
}: RunBobShellOptions): Promise<void> {
  return new Promise((resolve, reject) => {
    const child = spawn(
      "bob",
      [
        "--auth-method",
        "api-key",
        `--chat-mode=${mode}`,
        "--yolo",
        "-p",
        prompt,
      ],
      {
        cwd,
        env: {
          ...process.env,
          BOBSHELL_API_KEY: apiKey,
        },
        stdio: ["ignore", "pipe", "pipe"],
      }
    );

    child.stdout.setEncoding("utf8");
    child.stderr.setEncoding("utf8");

    child.stdout.on("data", (chunk) => {
      onStdout?.(chunk);
    });

    child.stderr.on("data", (chunk) => {
      onStderr?.(chunk);
    });

    child.on("error", reject);

    child.on("close", (code) => {
      if (code === 0) {
        resolve();
        return;
      }

      reject(new Error(`BobShell exited with code ${code}`));
    });
  });
}

The trick is operational: the Node.js process must run somewhere bob is installed and available on PATH. In this implementation, the backend ran inside a container image that already had BobShell installed. Without that, spawn("bob", ...) fails before Bob receives the prompt.

The --yolo flag deserves explicit framing. It auto-approves tool calls, which removed the human-in-loop step that would have blown the booth's time budget. The flag was acceptable here only because the agent ran in a scoped workspace inside a sandboxed preview. In ordinary development, where the agent has access to your real environment, this flag is a security risk and I would not use it.

While BobShell runs, the harness parses its output and streams intermediate results back to the chat panel through Server-Sent Events. The visitor sees progress instead of staring at an empty preview.

We tried staged generation: skeleton first, then components, so the visitor would see partial output as soon as Bob started writing. It looked useful for live UX, but the bundler cannot tell a partially written file from a complete one. Detecting incompleteness added complexity, and waiting for completion added latency.

For this version, single-shot generation won. Bob writes the app in one Code-mode run, then the backend bundles after BobShell exits.

4. esbuild Bundler

After BobShell finishes, the files in src/ still need to become something the browser can run. esbuild handles that bundling step.

The first version ran esbuild-wasm inside the iframe so the bundle could be built in the browser, near the render. CSP rules in the host environment made that path awkward: the iframe could not reliably load the WASM module under the security headers we needed.

Moving esbuild to the server simplified the harness. BobShell writes files, exits, and the backend runs esbuild against the manifest's entry point:

await esbuild.build({
  entryPoints: [`${workspace}/${plan.entryPoint}`],
  outfile:     `${workspace}/build/bundle.js`,
  bundle:      true,
  format:      "esm",
  jsx:         "automatic",
  external:    ["react", "react-dom/client"],
});

React and react-dom/client stay external, so the generated bundle does not ship its own copy. Instead, the HTML wrapper declares an import map, and the browser resolves those imports at load time. That keeps the bundle small enough to load quickly on the booth display, and gives the host control over which React version the generated app runs against.

The cost is feedback. Because bundling happens after BobShell exits, Bob does not see build errors. If esbuild fails, the backend reports it to the host UI, but Bob cannot read the diagnostic and patch the files in the same turn.

5. Bundle

The bundle is the handoff artifact:

build/bundle.js

It is the generated app after the backend has turned Bob's source files into browser-runnable JavaScript.

The host UI does not mount the preview just because Bob wrote files. It mounts after the backend produces the bundle and sends a bundle-ready notification. The bundle is the artifact; the notification tells the preview area to load the iframe.

6. HTML Wrapper

The iframe does not load bundle.js directly. It loads an API-served HTML wrapper.

The host UI points the iframe's src at an API endpoint for the conversation. That endpoint returns a small HTML document with four jobs: declare the import map, load Tailwind for this version, load the error bridge, and import the generated bundle.

<!DOCTYPE html>
<html>
  <head>
    <script type="importmap">
      {
        "imports": {
          "react": "https://esm.sh/react@19",
          "react-dom/client": "https://esm.sh/react-dom@19/client"
        }
      }
    </script>
    <script src="https://cdn.tailwindcss.com"></script>
    <script src="/runtime/error-bridge.js"></script>
  </head>
  <body>
    <div id="root"></div>
    <script
      type="module"
      src="/api/conversations/{id}/build/bundle.js">
    </script>
  </body>
</html>

The import map controls module resolution for external imports like react and react-dom/client. Tailwind is different: it loads as a script tag in this implementation because import maps do not govern ordinary script URLs.

That Tailwind choice was pragmatic. Bob writes clean Tailwind classes, and utility-class strings are compact in prompts. A production version should generate Tailwind CSS server-side rather than depend on the browser CDN.

The HTML wrapper belongs to the render path, not the backend pipeline. After the backend produces the bundle, the preview receives a bundle-ready notification. The iframe then loads the wrapper, which loads the bundle.

7. Sandboxed iframe preview

The first version rendered generated components directly inside the host page. That put the generated app in the same DOM, CSS cascade, and JavaScript surface as the product UI. A bad selector could restyle the host, and generated code could overwrite assumptions the host depended on.

The harness needed to isolate generated code, styles, build output, and failures. A bundling error should stop the preview, not the host UI. A script error in the generated bundle should be reported by the preview, not treated as a product-shell crash.

The second version moved the generated app into an iframe. We considered web components with Shadow DOM, but Shadow DOM only isolates DOM and CSS. It does not create a separate JavaScript execution environment. With sandbox="allow-scripts allow-forms", the iframe gives the preview its own browser boundary for scripts, styles, storage, and execution failures.

That boundary shapes prompt design too. Bob is told to keep state in memory, avoid cross-origin fetches, and not assume access to the parent page. If the generated app needs to report status outward, it crosses a narrow bridge.

The bridge uses postMessage for two states: the wrapper finished loading, or the generated app hit an execution error. The host listens for both and updates the chat or preview panel without exposing the rest of the product to the generated app.

// Inside the wrapper, before the bundle loads
window.addEventListener("load", () => {
  parent.postMessage({
    type: "generated-app-loaded",
  }, "*");
});

window.addEventListener("error", (event) => {
  parent.postMessage({
    type:    "generated-app-error",
    message: event.message,
    source:  event.filename,
    line:    event.lineno,
  }, "*");
});

// On the host side
function PreviewPane({ previewUrl }: { previewUrl: string }) {
  useEffect(() => {
    const handleMessage = (event: MessageEvent) => {
      if (event.data?.type === "generated-app-loaded") {
        markPreviewReady();
      }
      if (event.data?.type === "generated-app-error") {
        showRuntimeError(event.data);
      }
    };
    window.addEventListener("message", handleMessage);
    return () => window.removeEventListener("message", handleMessage);
  }, []);

  return (
    <iframe
      src={previewUrl}
      sandbox="allow-scripts allow-forms"
      title="Generated app preview"
    />
  );
}

Lessons and next steps

The Think 2026 implementation made one thing clear: Bob already has the primitives. It reads and writes files, runs commands, and generates working React and Tailwind. The work was in the task-specific harness: pointing those primitives at a predictable flow, where to write, what context to use, when to bundle, and where to render.

Without that harness, the output is code in a folder. With it, the visitor gets a browser-runnable app to test.

The first improvement is prompt and harness efficiency. Every second matters in a booth, and every token and setup step has a cost in production. The goal is to design the prompt, context, tools, and workflow so Bob reaches a useful result faster. Interactive BobShell could help: a warm session across turns reduces latency while the harness keeps controlling workspace and output shape.

The second improvement is to put the build step, linting, and security scanning inside the same Bob loop. We had this and removed it for latency, since Bob writes compilable code in one pass often enough to skip validation. Once the first improvement frees up time budget, validation comes back: Bob runs esbuild and the scanners, reads diagnostics, patches the offending file, and retries before the preview reaches the user.

The third improvement is the approved frontend surface. The current harness exposed only React and Tailwind to generated code. A polished version should add richer approved ESM modules, including something like Carbon React, so generated apps do not make Bob recreate every UI primitive.

The Think 2026 version proved the core loop: prompt, context, BobShell, workspace, bundle, wrapper, iframe. The next version should make it more self-correcting, safer, and more efficient.

Bob brings the coding agent. The task-specific harness gives it a job.

The views in this essay are personal. They do not represent IBM, the Bob team, or any of my employers.

Skills Are Prompts, But Not All Prompts Are Equal

2026-04-28T00:00:00.000Z

What's new about a Skill isn't any single property. It is that the properties live together in one named, loadable package.

A Skill is a prompt. Anything that enters an LLM's context shapes what comes out, and a SKILL.md file enters the context like any user instruction or system prompt. Mechanically, the skeptic is right.

Each individual property of a Skill can already be done some other way. A narrowly written system prompt can function as task-scoped. A shared template can be reusable across people. Retrieval can load context only when relevant. A folder can package a prompt with examples and helper scripts. None of these capabilities is new on its own.

What is new is the combination, as a single package.

A Skill is the prompt-shaped package where four properties live together. It is task-scoped rather than project-scoped or session-scoped. The system loads it selectively when the task calls for it, instead of the user pasting it in. It can be reused across people, rather than living inside one person's session.1

And it bundles its full payload, instructions plus examples plus scripts plus references, as one named unit that can be versioned, installed, and uninstalled.

	Handwritten prompt	System prompt	Custom instruction	`CLAUDE.md`	Skill
Task-scoped	●	if narrow	○	○	●
Selectively loaded	○	○	○	○	●
Reusable across people	○	if shared	○	●	●
Bundled payload	○	○	○	partial	●

No single existing artifact carries all four properties. The Skill is the form that ships with them combined.

Each property, on its own, is reachable with what you already have. The combination is what's harder to assemble, because it requires the package to be a first-class unit the system loads, addresses, and unloads on its own. You can build that yourself, with a routing layer and a prompt library and some glue. Skills are the form in which the combination ships as a default, with the system handling the loading instead of the user.

The claim is not that this is unprecedented. The claim is that it is now the default form, and the default form is what determines whether most users will ever benefit from it. What unification enables is why that matters.

What Unification Makes Possible

Two consequences follow from the same property. Both depend on the package being named, selectively loaded, and reusable. Each one solves a different problem.

Consequence 1

Expert knowledge becomes transferable across domains

Before

A lawyer's working knowledge stays with the lawyer. Useful once.

After

The same knowledge is loadable by a founder who has never read a contract carefully.

Consequence 2

Detailed refusals become viable

Before

The model drifts to its training average: AI slop, generic and machine-made.

After

A long, domain-specific list of patterns to refuse is loaded only when needed.

Both come back to the same property: the Skill is selectively loaded and named.

One package, two jobs at once. The same structural property that makes long-form expertise portable also makes long-form refusals affordable.

The first thing it enables is that expert knowledge becomes transferable across domains. A handwritten prompt encoding what a senior contracts lawyer would check is useful exactly once, to the person who wrote it. The same instructions in a Skill, named and addressable, can be loaded by a founder who has never read a contract carefully.

The lawyer's working knowledge becomes a passable substitute for the lawyer, accessible to anyone whose task calls for it. Before Skills, this transfer required the recipient to know enough to copy the right prompt at the right time. Now the system handles the loading.

User asks for a slide deck

→

System scans installed Skills

→

pptx Skill matches and loads

→

Model responds with the Skill in context

Selective loading. The Skill enters context only when the task calls for it, then leaves.

The second thing it enables is that detailed refusals become viable. The model tends to produce something close to the average response in its training distribution. For factual queries, the average is usually correct. For creative or aesthetic work, the average is what people recognize as AI slop: generic, bland, machine-made.

Pushing the model off the average requires telling it specifically what to avoid, not just what to produce. The list of patterns to refuse is often long and domain-specific. A system prompt is the wrong place for it because most conversations don't need the list. A custom instruction is the wrong place because the scope is global.

A Skill loads only when the relevant task is at hand, so it can carry the full refusal list without paying a cost on every other interaction.

An Example That Shows Both at Once

Anthropic's pptx Skill is built for slide decks, and it shows both consequences working in a single package.2 Asked to make a deck about quarterly results, a model with no Skill produces what people now recognize as AI slop: title plus three bullets per slide, generic styling, the same look every time.

The Skill changes the result. It tells the model to pick a content-informed color palette and reject default blue, to commit to a single visual motif and repeat it across the deck, to treat text-only slides as failures, and to vary layouts. It also names specific AI-generated tells and refuses them: accent lines under titles, full-width colored bars, cream backgrounds.

pptx/SKILL.md (excerpt)

---
name: pptx
description: "Use this skill any time a .pptx file is involved..."
---

## Design Ideas

### Before Starting

- Pick a bold, content-informed color palette:
  the palette should feel designed for THIS topic.
- Dominance over equality: one color
  should dominate (60-70% visual weight).
- Commit to a visual motif: pick ONE
  distinctive element and repeat it across every slide.

### Avoid (Common Mistakes)

- Don't default to blue - pick colors
  that reflect the specific topic.
- Don't create text-only slides - add
  images, icons, charts, or visual elements.
- NEVER use accent lines under titles -
  these are a hallmark of AI-generated slides.
- Don't add full-width colored bars -
  they read as AI slop unless explicitly requested.
- Don't default to cream/beige backgrounds
  - use white or the user's brand palette.

## QA (Required)

Convert slides to images, then run a verification loop:
overflow, low contrast, overlapping elements, leftover
placeholder text. Fix and re-verify.

The bundled payload: instructions, named refusals, and a verification loop, in one package the system loads on demand.

Two things came together in that one package. The user who asked for the deck did not need to know what makes a deck good. That knowledge came from a designer, packaged once, addressable from then on.

The deck also did not come back as the slop the model would have produced by default. The specific refusals came from someone who had watched the model fail enough times to know exactly which patterns to name.

A skeptic could write a system prompt that captures part of this. They could write it and live with the cost: it gets loaded on every call where it might be relevant, paid for in tokens, and carried even on calls where it is not. The selective loading isn't a UX detail. It is what makes a long, domain-specific refusal list practical to maintain over time.

What Unification Does Not Solve

Skills can be bad. The format guarantees nothing about the contents. A Skill written by someone without taste in a domain produces tasteless results, and one written before a major change in tools or conventions can keep telling the model to follow rules that no longer apply.

Length and structure do not protect against shallow judgment. A long bad Skill can be worse than no Skill, because users may treat it as authority. Unification is a property of the package, not of what the package contains.

The Markdown Is Simple. What's in the Package Is Not.

Skills are prompts. That is the starting point.

What is new is not the markdown. The markdown is now part of a named, selectively loaded, reusable package that carries its full payload as a unit. What ships in a Skill is a compact way to do two jobs at once: move expert knowledge across domains, and refuse the model's defaults at a level of detail most general-purpose prompts can't afford to carry.

The practical upshot is a different question to ask before reaching for a Skill. The question is no longer "is this prompt good." The question is "does this task call for a package the user could not have assembled themselves." When the answer is yes, the markdown stops being markdown and starts being infrastructure.

The markdown is simple. What's in the package is not.

In one card

A Skill is the prompt-shaped package where four properties live together. The combination is the new thing, and the combination is what makes two awkward problems solvable.

The four properties

Task-scoped Selectively loaded Reusable across people Bundled payload

What that makes possible

Knowledge transfer An expert's working process becomes loadable by anyone whose task calls for it.

Refusing defaults A long, domain-specific list of patterns to reject is loaded only when needed.

The new question to ask Not "is this prompt good." Instead: does this task call for a package the user could not have assembled themselves?

Anthropic's documentation on Agent Skills covers the package format and the progressive-disclosure loading model in more detail. See platform.claude.com/docs/en/agents-and-tools/agent-skills/overview.
The full instruction file for the pptx Skill, including the specific patterns shown above, is published in Anthropic's open repository at github.com/anthropics/skills/tree/main/skills/pptx.

You might still need a useEffect

2026-04-25T00:00:00.000Z

A gentle introduction to useEffect, synchronization, cleanup, dependencies, referential stability, and related React hooks.

A gentle introduction to synchronization in React

useEffect is one of the first React hooks that starts to feel confusing. The name sounds simple, but the behavior gets strange when an effect runs too many times, doesn't run when you expect, or keeps doing work after a component has left the screen.

The clearest way to think about it is this:

useEffect is how your component talks to things that live outside React.

That "outside" includes the DOM, network requests, timers, subscriptions, browser APIs like window.innerWidth, and third-party libraries that want to attach to a real DOM node. Anything that isn't already managed by props and state. The effect's job is to set up a connection to that outside thing on the way in, and tear it down on the way out.

If you want to go deeper on when to use effects and when to avoid them, the React docs have a guide called You Might Not Need an Effect, and Alvin Sng has written about banning direct useEffect in production codebases. Both are worth reading once you've got the basics down. This article is the basics.

How useEffect works

useEffect takes two arguments: a callback function and a dependency array.

useEffect(() => {
  // ...your code
}, [dep1, dep2]);

Three things determine when and how the callback runs.

The callback runs after the component renders

When React renders your component and updates the DOM, it then runs the callback. Anything inside the callback happens after the user can already see the result of the render. That's why effects are a safe place for side effects: they don't block the screen from updating.

The dependency array decides when to re-run the callback

When you provide a dependency array, React compares the values inside it against the previous render's values. If any of them changed, React runs the callback again. If none of them changed, React skips it.

There are three shapes the array can take, and each one means something different:

// 1. Specific dependencies: re-run when any of these change
useEffect(() => {
  const connection = openChatRoom(roomId);
}, [roomId]);

// 2. Empty array: run once after the first render, never again
useEffect(() => {
  console.log("mounted");
}, []);

// 3. No array at all: run after every render
useEffect(() => {
  console.log("rendered");
});

Most of the time you want the first shape. The empty array is useful when the work doesn't depend on any changing value, like a one-time setup. The no-array form is rarely what you want, and the dependency linter will usually warn you against it.

The callback returns a cleanup function

The work an effect starts often needs to be stopped. A setInterval should be cleared. An event listener should be removed. A subscription should be cancelled. To handle that, the callback can return a function, and React will run that function before the next time the effect runs or when the component unmounts.

useEffect(() => {
  const connection = openChatRoom(roomId); // setup

  return () => {
    connection.close(); // teardown
  };
}, [roomId]);

When roomId changes, React closes the old connection before opening the new one. When the component leaves the screen, React closes the connection one last time. This is what most beginner tutorials describe as "mounting and unmounting," but the more useful framing is "open and close a connection."

That's the entire model. Setup runs after render. Teardown runs before the next setup or before unmount. The dependency array decides when to do another setup-teardown cycle.

When not to write an effect

Now that you know what an effect does, it's easier to spot the cases where one shouldn't be there at all. Two patterns come up constantly.

Deriving a value from props or state

If a value can be calculated from existing props or state, calculate it during render. Don't reach for an effect:

// Don't do this
function Greeting({ firstName, lastName }) {
  const [fullName, setFullName] = useState("");

  useEffect(() => {
    setFullName(`${firstName} ${lastName}`);
  }, [firstName, lastName]);

  return <h1>Hello, {fullName}</h1>;
}

// Do this
function Greeting({ firstName, lastName }) {
  const fullName = `${firstName} ${lastName}`;
  return <h1>Hello, {fullName}</h1>;
}

The effect version forces React to render once with an empty fullName, run the effect, then render again with the real value. Two renders to do the work of one. There's also nothing outside React being synchronized here, so the effect doesn't earn its place.

Reacting to a user event

If something should happen because a user clicked a button, that logic belongs in the click handler. It doesn't belong in an effect that fires after the resulting state change:

// Don't do this
useEffect(() => {
  if (product.isInCart) {
    showNotification(`Added ${product.name} to cart`);
  }
}, [product]);

// Do this
function handleAddToCart() {
  addToCart(product);
  showNotification(`Added ${product.name} to cart`);
}

The effect version fires the notification any time product changes, including on initial render if the product was already in the cart from a previous session. The handler version only fires when the user actually clicks. That's almost always what you want.

The general test is: "is this code talking to something outside React?" If no, it probably shouldn't be an effect.

Three things to pay attention to when writing effects

Once you're writing real effects, three things determine whether they behave correctly. The first is positive: getting cleanup right. The other two are traps that catch most beginners.

1. Clean up what you start

Most subtle effect bugs come from missing cleanup. Whatever your setup starts, your teardown should stop. The shape is the same across every external system, just applied to different APIs.

Window event listeners. The teardown removes the same function the setup added:

useEffect(() => {
  function handleResize() {
    setWidth(window.innerWidth);
  }
  window.addEventListener("resize", handleResize);
  return () => window.removeEventListener("resize", handleResize);
}, []);

removeEventListener requires the same function reference that addEventListener got, which is why handleResize is named and reused.

Intervals. The teardown clears the interval:

useEffect(() => {
  const id = setInterval(() => {
    setSeconds((s) => s + 1);
  }, 1000);
  return () => clearInterval(id);
}, []);

Using the functional form setSeconds((s) => s + 1) makes sure the callback always sees the current value, not a stale one captured when the interval was created.

Subscriptions. Many APIs return an unsubscribe function, which you can return directly from the effect:

useEffect(() => {
  return chatRoom.subscribe((message) => {
    setMessages((messages) => [...messages, message]);
  });
}, [chatRoom]);

Network requests. The teardown either marks the response as ignored or aborts the request:

useEffect(() => {
  let ignore = false;
  fetch(`/api/users/${userId}`)
    .then((res) => res.json())
    .then((data) => {
      if (!ignore) setUser(data);
    });
  return () => {
    ignore = true;
  };
}, [userId]);

The ignore flag prevents a stale response from overwriting newer data when userId changes mid-request. One practical caveat: in production apps, libraries like TanStack Query and SWR, or framework data layers in Next.js and Remix, handle race conditions, caching, and loading states for you. Writing your own fetch effects is fine for learning and small projects, but it stops being the right call at scale.

2. Effects run twice in development

If you've used React 18 or later, you've probably seen an effect fire twice in development and wondered if something was broken. Nothing is broken. React's Strict Mode runs setup, then teardown, then setup again, on purpose.

The reason is that Strict Mode is testing whether your teardown actually works. If running setup-teardown-setup leaves your component in a broken state, the synchronization isn't symmetric, and it'll eventually break in production too when a dependency change legitimately causes React to teardown and reopen the connection.

A buggy effect makes this visible:

// Logs two visits in development
useEffect(() => {
  fetch("/api/visit", { method: "POST" });
}, []);

The fix is to add a teardown that cancels the in-flight request, or to move the analytics call somewhere that running it twice doesn't matter. Don't disable Strict Mode. It's catching a real bug for you while it's still cheap to fix.

3. Referential stability

Once you start writing dependency arrays carefully, you'll run into a frustrating-feeling case. The effect keeps firing on every render even though nothing seems to have changed. The cause is almost always referential stability.

React compares dependencies with Object.is. For primitives like strings and numbers, that compares values. For objects, arrays, and functions, it compares references. Since the component function reruns on every render, anything you build inside the function body gets a fresh reference each time, even if the contents are identical:

function SearchResults({ query }) {
  const options = { limit: 20, query };

  useEffect(() => {
    search(options);
  }, [options]);
}

options is a new object on every render, so the effect runs on every render too. There are four reasonable ways out, and the right one depends on what the value is for.

Option 1: depend on the primitive. If the object is only used inside the effect, build it inside the effect and depend on the primitive that actually changes:

useEffect(() => {
  search({ limit: 20, query });
}, [query]);

This is the answer most of the time. Reach for it first.

Option 2: memoize the object. If something else also needs the object, such as a child component or another hook, wrap it in useMemo so its identity stays stable until its real inputs change:

const options = useMemo(() => ({ limit: 20, query }), [query]);

Option 3: memoize a function passed across components. useCallback matters when a function's identity is observed by something else, typically a memoized child:

const runSearch = useCallback(() => {
  search({ limit: 20, query });
}, [query]);

return <SearchButton onSearch={runSearch} />;

If the function only lives inside one effect in one component, you don't need useCallback at all; depend on query directly.

Option 4: a ref for a value that should not retrigger the effect. Sometimes the effect genuinely should not restart when a value changes, but the effect still needs to read the latest version. A ref gives you a stable container whose .current you can update without triggering re-renders:

const latestQueryRef = useRef(query);

useEffect(() => {
  latestQueryRef.current = query;
}, [query]);

useEffect(() => {
  const id = setInterval(() => {
    search({ limit: 20, query: latestQueryRef.current });
  }, 5000);
  return () => clearInterval(id);
}, []);

This works, but it's the option to reach for last. Refs hide which values actually drive the effect's behavior, and they make the dependency lint rule unable to help you. As of React 19.2, there's a cleaner tool for this exact case, which is in the next section.

Plain useEffect covers most synchronization needs, but four situations have their own purpose-built tools. Each one solves a specific gap, and each one fits the same connection metaphor we've been building on.

`useEffectEvent`: read a value without restarting the effect

A common pain point with the dependency array is that it forces a bad trade. Either you list everything the effect reads, which is correct but may restart the connection more than you want, or you omit some values, which is wrong and makes the linter complain. The classic example is a chat room that wants to show a notification with the current theme:

function ChatRoom({ roomId, theme }) {
  useEffect(() => {
    const connection = openChatRoom(roomId);
    connection.on("connected", () => {
      showNotification("Connected!", theme);
    });
    return () => connection.close();
  }, [roomId, theme]); // Reconnects when theme changes
}

The connection only cares about roomId. The notification call cares about theme. Listing both as dependencies means changing the theme tears down the chat connection and opens a new one, which is wasteful and visibly wrong.

useEffectEvent, stable since React 19.2 in October 2025, lets you split the "event-like" piece out of the effect. The effect still reads the latest theme when the notification fires, but theme no longer defines the connection's identity:

import { useEffect, useEffectEvent } from "react";

function ChatRoom({ roomId, theme }) {
  const onConnected = useEffectEvent(() => {
    showNotification("Connected!", theme);
  });

  useEffect(() => {
    const connection = openChatRoom(roomId);
    connection.on("connected", onConnected);
    return () => connection.close();
  }, [roomId]); // Only reconnects when roomId changes
}

This replaces the "ref to read the latest value" trick from Option 4 in the previous section. The hook signals intent, this is an event-like callback fired from inside an effect, and the linter understands not to flag it as a missing dependency.

Ref callbacks with cleanup: when the connection is to a DOM node

Sometimes the thing being synchronized isn't your component, it's a specific DOM node. Imagine attaching a ResizeObserver to a <div> so you can react to its dimensions changing. The conventional approach used a useRef plus a useEffect:

function MeasuredBox() {
  const ref = useRef(null);

  useEffect(() => {
    if (!ref.current) return;
    const observer = new ResizeObserver(() => {
      console.log(ref.current.getBoundingClientRect());
    });
    observer.observe(ref.current);
    return () => observer.disconnect();
  }, []);

  return <div ref={ref}>...</div>;
}

This works, but the ResizeObserver is conceptually tied to the <div>, not to the component's lifetime. React 19 in December 2024 made ref callbacks, functions you pass directly to ref, able to return cleanup functions, which lets you express that relationship directly:

function MeasuredBox() {
  return (
    <div
      ref={(node) => {
        const observer = new ResizeObserver(() => {
          console.log(node.getBoundingClientRect());
        });
        observer.observe(node);
        return () => observer.disconnect();
      }}
    >
      ...
    </div>
  );
}

The setup runs when React attaches the ref, and the cleanup runs when the node is detached or replaced. There's no useRef, no useEffect, and no null check. The synchronization is colocated with the node it depends on.

The rule of thumb: if the thing being synchronized is "this DOM node," prefer a ref callback with cleanup. If it's "this component's lifetime in general," use useEffect.

`useSyncExternalStore`: subscribing to data that drives rendering

You can subscribe to an external data source with useEffect, and the cleanup pattern from earlier works fine:

function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(true);

  useEffect(() => {
    function update() {
      setIsOnline(navigator.onLine);
    }
    update();
    window.addEventListener("online", update);
    window.addEventListener("offline", update);
    return () => {
      window.removeEventListener("online", update);
      window.removeEventListener("offline", update);
    };
  }, []);

  return isOnline;
}

This is fine for most cases. But when the external data drives what you actually render, such as a Redux store, a Zustand store, navigator.onLine, or anything where the value affects the UI, React provides useSyncExternalStore, which handles concurrent rendering edge cases that useEffect cannot:

function subscribe(callback) {
  window.addEventListener("online", callback);
  window.addEventListener("offline", callback);
  return () => {
    window.removeEventListener("online", callback);
    window.removeEventListener("offline", callback);
  };
}

function useOnlineStatus() {
  return useSyncExternalStore(
    subscribe,
    () => navigator.onLine,    // current value on the client
    () => true                  // current value on the server
  );
}

The hook takes a subscribe function, same shape as your effect's setup, a function that returns the current value, and an optional function that returns the value during server rendering. You'll most often see this through libraries, since Zustand and React Redux both use it under the hood, but it's worth knowing about when you're writing your own subscription logic.

`useLayoutEffect`: when synchronization has to happen before paint

useEffect runs after the browser paints, which keeps the screen feeling responsive. Once in a while, you need synchronization that has to happen before paint so the user doesn't see a flicker. Positioning a tooltip based on its measured width is the canonical case: if you measure and adjust in useEffect, the user briefly sees the tooltip in the wrong place before it snaps into position.

useLayoutEffect has the same API as useEffect but runs synchronously before paint:

useLayoutEffect(() => {
  const { width } = tooltipRef.current.getBoundingClientRect();
  setLeft(triggerLeft - width / 2);
}, [triggerLeft]);

Use it only when you actually need it. It blocks the screen from updating until your effect finishes, so the responsiveness benefit of plain useEffect is gone. If you ever notice a one-frame flash between an effect's setup and what the user sees, that's the signal that the effect should probably be a useLayoutEffect.

A checklist before writing an effect

Before reaching for useEffect, ask:

Am I synchronizing with something outside React, or am I deriving a value from props and state? If it's the latter, calculate during render instead.
What is the external system, and what defines the identity of the connection to it?
What values does that identity depend on? Are they all in the dependency array?
Does my teardown actually undo what my setup did?
Will this still behave correctly under Strict Mode's setup-teardown-setup pattern in development?
Is the connection tied to a specific DOM node? A ref callback with cleanup might be a better fit.
Is the effect reading a value that shouldn't restart it? useEffectEvent is built for that.

The rules underneath these questions are simple. If your effect starts something, stop it. If it reads a value that can change, list that value as a dependency unless you have a deliberate reason not to. If you're only moving React values around inside React, you don't need an effect at all.

useEffect isn't an arbitrary hook with a weird name and surprising behavior. It's React's interface to the world outside it. Once you start treating it that way, the rest of the rules write themselves.

LLM Agents: A Gentle Introduction

2026-04-25T00:00:00.000Z

A developer-friendly introduction to LLM agents: what they are, how they run, what tools and memory do, and where to start.

When developers first hear "AI agent" or "agentic AI," a fair question follows: how is this different from sending a prompt to ChatGPT and getting a response back?

A raw language model call is a single round trip. You send input, the model returns output, and the exchange ends. By itself, the model cannot decide to search your docs, call your database, run a test, inspect a file, or check whether its answer worked.

An agent extends that single call into a loop. The model can decide what to do next, call a tool, read the result, update its context, and keep going until the task is finished, blocked, or stopped by a limit.

The simplest way to say it is:

An LLM agent is a language model inside a loop, connected to tools, memory, and an environment.

A single LLM call is input to output. An agent wraps the model in a loop that can act, observe, and continue.

At every step, the model still only sees input. That input may contain system instructions, user messages, tool definitions, memory snippets, prior tool results, and retrieved documents. In that practical sense, everything the model sees is a prompt. The engineering work is deciding what should be assembled into that prompt at each step.

What is an AI agent?

Agents are older than LLMs. In classical AI, an agent is something that perceives an environment and acts on it to achieve a goal. That definition covers simple systems such as thermostats and complex systems such as chess engines, robots, and reinforcement learning policies.

What they share is a shape:

There is a goal.
There is an environment.
The agent observes something about that environment.
The agent chooses an action.
The environment changes or returns feedback.

An LLM-based agent fits the same shape. The user's task is the goal. The model is the decision-maker. Tools are actions. Tool results are observations. The environment is whatever the agent can act on: a browser, a codebase, a database, a calendar, an API, or a sandbox.

So "agent" does not name one specific technology. It names a pattern: observe, decide, act, observe again.

The agent pattern predates LLMs. The shape stays the same; the decision-maker changes.

LLMs as the brain of the agent

For a long time, the hard part was the policy: the logic that maps an observation to the next action. Hand-written rules were brittle. Search systems could explode in complexity. Learned policies often needed task-specific data and training.

LLMs changed the bottleneck. A modern instruction-following model can read a natural-language goal, inspect a list of available tools, choose a tool, fill in structured arguments, and interpret the result. That does not make the model the whole agent, but it makes the model a useful decision engine inside the agent.

Three capabilities made this practical:

Instruction following: you can describe behavior in prose.
Structured output: the model can return JSON or function calls the harness can route.
Long context: the model can receive enough task history, tool output, and retrieved context to continue across multiple steps.

Reasoning improved sharply too, and that is where most agent discussions begin.

The capabilities of an agent

Three capabilities sit at the core of most useful agents: reasoning, tools, and memory.

Useful agents need reasoning to choose, tools to act, and memory to carry context forward.

Reasoning

Chain-of-thought prompting was an eye-opening moment. Before it, many developers did not have a practical reason to believe that asking a model to show intermediate steps could improve difficult answers. The model was not given a new tool or a new training run. The prompt simply gave it room to work through the problem.

User: A bakery has 23 cupcakes. They sell 8 in the morning
and bake 12 more in the afternoon. How many at the end of the day?

Prompt addition: Think step by step.

Model:
Start with 23.
After selling 8: 23 - 8 = 15.
After baking 12: 15 + 12 = 27.
Answer: 27.

The safer way to phrase the lesson is: no task-specific training was needed. The reasoning behavior was latent enough that a better prompt could surface it.

ReAct extended that idea into an agent loop. Instead of only writing intermediate reasoning, the model alternates between reasoning and actions:

Task: What is the population of the capital of Slovakia?

Thought: I need the capital first.
Action: search("capital of Slovakia")
Observation: The capital of Slovakia is Bratislava.

Thought: Now I need Bratislava's population.
Action: search("Bratislava population")
Observation: Approximately 475,000 residents.

Final: Approximately 475,000.

ReAct mattered because it grounded reasoning in feedback from the world. The model could think, act, observe, and revise.

The newer shift is the reasoning model. For a gentle introduction, you can think of these as "thinking models": models trained to spend more computation on hard problems before producing a final answer. The standard terms are reasoning models and test-time compute. OpenAI's o1 and DeepSeek-R1 made this pattern widely visible.

The important point for agent builders is that these ideas stack. A reasoning model can run inside a ReAct-style loop. The model handles hard local reasoning; the loop handles tools, observations, and grounding.

Tools

Tools are how an agent reaches outside the model. A tool might search documents, query a database, send an email, inspect a GitHub issue, run code, or control a browser.

The model learns which tools exist because tool names, descriptions, and argument schemas are included in the model input.

You have access to these tools:

search_docs(query: string, top_k: number)
  Search the knowledge base for documents matching a query.

send_email(to: string, subject: string, body: string)
  Send an email to a recipient.

When the model chooses a tool, it produces structured output. The harness reads that output, runs the actual function in the environment, and feeds the result back as the next observation.

{
  "tool": "search_docs",
  "arguments": {
    "query": "Q3 report",
    "top_k": 5
  }
}

Early agent systems used many custom wrappers. Every framework had its own tool format, and every provider had a slightly different function-calling shape. The Model Context Protocol, released by Anthropic in November 2024, standardizes the client-server boundary for tools and resources. Once an MCP server exists, an agent client can discover and call its tools without a one-off integration for that specific provider.

There is still engineering work. Someone has to expose the useful API as an MCP server, handle authentication, define permissions, and decide what tool outputs should look like. MCP reduces integration friction; it does not remove design work.

As tool catalogs grow, another problem appears: you cannot always put every tool definition into the model context. Tool search solves this by loading only the relevant tools on demand. Claude Code's tool-search documentation is a good practical example of this pattern.

There is also CodeAct, where the model writes executable code instead of emitting one JSON tool call at a time. That can be powerful because code can use variables, loops, and multiple API calls in one action. It also raises the bar for sandboxing and safety.

Memory

The model does not remember previous calls by itself. Each call starts from the input it receives. If the agent "remembers" something, the harness or a tool has put that memory back into the model context.

Short-term memory is the running state of the current task: messages, prior tool calls, prior observations, scratchpad notes, and partial outputs.

Long-term memory persists across tasks: user preferences, project facts, prior decisions, or stored documents. It usually lives outside the model in a database, vector store, file, or application backend.

The hard part is not only storage. The hard part is deciding what to save, when to retrieve it, and how much to put back into context. Too little memory makes the agent forgetful. Too much memory floods the prompt with noise.

The anatomy of a running agent

The capabilities explain what an agent can do. The anatomy explains how it runs.

The model is only one part. The harness, scaffold, and environment make the agent usable.

The loop

The core loop is simple:

Build the model input.
Call the model.
Parse the model response.
If the model is done, return the answer.
If the model requested a tool, run the tool.
Add the result to context.
Repeat until done, blocked, or out of budget.

The harness

The harness is the runtime code that drives that loop.

function runAgent(task, scaffold, environment) {
  let context = buildInitialContext(scaffold, task);

  for (let step = 0; step < maxSteps; step++) {
    const response = model.call(context);

    if (response.isComplete()) {
      return response.answer;
    }

    const toolCall = response.toolCall;
    const result = environment.execute(toolCall);

    context = appendToContext(context, response, result);
    context = compactIfNeeded(context);
  }

  return timedOut();
}

Most production concerns live in the harness: tracing, retries, rate limits, cost tracking, malformed output recovery, context compaction, approval gates, and stopping conditions. A demo can survive with a weak harness. A production agent usually cannot.

The environment

The environment is the world the agent acts on. For a coding agent, that might be a repository, shell, filesystem, test runner, and browser. For a support agent, it might be a CRM, ticketing system, knowledge base, and email API.

Two questions matter:

Is the action deterministic? Running a local parser is easier to reason about than searching the web.
Is the action reversible? Editing a sandboxed file can be undone. Sending money or deleting production data cannot.

The less deterministic and less reversible the environment is, the more guardrails you need: narrow permissions, dry-run modes, human approval, audit logs, and rollback plans.

The instruction scaffold

The terms scaffold and harness are not fully standardized. People often use agent scaffolding and agent harness interchangeably to mean "the software around the model." That is fine in casual conversation, but the distinction is useful when you are building.

In this article, the scaffold is the structure available before the agent runs: role, behavioral rules, tool definitions, permissions, memory conventions, and output formats.

[role]
You are a research assistant for software developers.

[rules]
- Cite sources.
- Search before answering if the answer may have changed.
- Ask before taking irreversible actions.

[tools]
- search_docs(query, top_k)
- fetch_url(url)

[output format]
Respond in markdown with source links.

The harness assembles the scaffold with runtime context: the current task, today's date, retrieved memory, previous tool results, and anything else the model needs for the next step.

Everything the model sees is a prompt

This is the unifying idea. The model does not see your database connection, your app server, your vector store, or your tool registry directly. It sees the input the harness gives it.

That input is systematically assembled context. It may contain static instructions from the scaffold, dynamic facts from the environment, retrieved memory, tool schemas, and observations from previous steps. To the model, all of that is the prompt.

If the agent chooses the wrong next action, the bug is often in this assembled prompt: missing tool description, unclear instruction, stale memory, noisy retrieval, ambiguous output format, or a tool result that lost the important detail.

This is why context engineering is becoming a core agent skill. You are not just "writing prompts." You are designing the information surface the model uses to act.

Architectural patterns

Once you understand a single agent, the next question is how to compose systems.

A workflow is a fixed sequence of steps. Your code decides what happens next. The model may summarize, classify, extract, or generate at each step, but the path is known ahead of time.

A single agent is one model-driven loop with access to tools. The model decides the next action based on the current context. This is the best starting point when the task path is uncertain.

A multi-agent system uses multiple agents, often with specialized roles. This can help when work naturally splits across domains, but it also adds communication overhead, coordination failures, and harder debugging.

An orchestrator-worker pattern is the most common useful multi-agent shape. One orchestrator breaks the task into subtasks and delegates to workers. Mechanically, calling a worker agent is just a tool call where the implementation happens to be another agent.

The honest guidance is boring and useful: start with a workflow when the steps are predictable. Use a single agent when the path is genuinely uncertain. Reach for multi-agent systems only when you have evidence that one agent with better tools is not enough.

Customizing agents

The cheapest way to change an agent is to change the prompt: improve the role, tighten the output format, clarify tool descriptions, add examples, or change what memory gets injected.

When manual prompting plateaus, three stronger options show up.

Prompt optimization treats the prompt as something that can be searched and tuned against a metric. DSPy is the clearest example: you define a language-model program, provide a metric and examples, and let an optimizer improve instructions or demonstrations.

Supervised fine-tuning trains a model on examples of the behavior you want. It is useful when you need a stable format, domain-specific language, or a smaller model to imitate a larger one. It also gives you a model artifact to maintain.

Reinforcement learning with verifiable rewards is useful when correctness can be checked automatically: math answers, code that passes tests, structured outputs that parse, or tasks with clear success signals. For most application developers, this is something you consume by choosing a reasoning model, not something you run yourself.

The order matters. Start with better context. Add prompt optimization when you have a metric. Consider SFT when prompting cannot reliably produce the behavior. Treat RL with verifiable rewards as advanced training infrastructure.

Frameworks at a glance

A framework is a set of opinions about harness, scaffold, tools, state, and deployment.

LangChain and LangGraph are widely used in the Python and JavaScript ecosystem. LangChain gives agent and tool abstractions; LangGraph gives an explicit graph runtime with state, persistence, interrupts, and human-in-the-loop patterns.

Google ADK is a code-first framework for developing and deploying agents. It is optimized for Gemini and the Google ecosystem, but the official docs describe it as model-agnostic and deployment-agnostic.

BeeAI Framework is an open-source framework for building production-grade multi-agent systems with provider-agnostic model support and memory strategies.

Agent Stack, formerly BeeAI Platform, is deployment and runtime infrastructure. It helps run agents as services, with a web UI, CLI, LLM routing, storage, document extraction, secrets, OAuth, MCP integrations, and A2A compatibility.

DSPy is different from graph frameworks. It treats prompts and LM calls as parts of a typed program that can be optimized against examples and metrics.

Do not pick a framework because it is popular. Pick it because its mental model matches the problem you are solving.

Where to start

The smallest useful project is a ReAct-style agent with one real tool.

Pick a model with function calling or structured output.
Define one tool that does something real.
Write the loop yourself.
Log every model input, tool call, observation, and final answer.
Add a stopping condition and a step budget.
Add one small eval set: five to ten tasks you expect it to handle.
Only then move the same idea into a framework.

You will hit the real problems quickly. The model will ask for a tool that does not exist. A tool will fail. Context will get noisy. The agent will repeat itself. Each failure teaches something specific about harness design, scaffold writing, tool design, memory, or context engineering.

That is the durable lesson: an agent is not just an LLM. It is a model inside a runtime loop, shaped by a scaffold, connected to tools, operating in an environment, and fed by carefully assembled context.

Towards a More Trustworthy Electoral Architecture for National Elections in Nigeria: The Presidential Election Results Collation Case Study

2026-04-25T00:00:00.000Z

Nigeria's presidential results still depend on repeated manual collation. This article maps the failure points and proposes a new architecture: BVAS as the capture device, mandatory e-transmission, and a public electronic register for collation.

Interesting Concept I Picked Up — Eliminate Stupid Mental Effort (ESME)

2020-12-20T00:00:00.000Z

I discovered Andela's Eliminate Stupid Mental Effort concept in 2019, a refreshing perspective for Nigerian developers. ESME addresses the unnecessary mental exertion we endure daily, much like enduring Lagos traffic.

Sometimes in 2019, I stumbled on Andela Best Practices on GitHub and, for me, it was the closest you could get to an Andela education if you did not pass through Andela.

One of the very interesting concepts in their best practices is Eliminate Stupid Mental Effort (ESME). I found the concept profound because it recognizes the environment we live in as Nigerian developers and the things we may have internalized while growing up in Nigeria that could affect the way we work.

To understand this concept, you first need to understand stupid mental effort.

Let's look at a typical Lagosian life. Some people say in Lagos it is 5-9 and not 9-5.

You leave your house very early by 5AM to beat traffic and get to work on time. You struggle to enter public transport. Then you spend about 3 hours in traffic, and going back home can be even worse.

As inconvenient as this way of life is, Lagosians have become used to it because this is what they experience constantly and it has become the norm.

I remember a conversation with my friend who was in Rwanda for grad school. She complained that she could not get used to life in Rwanda because things felt slower compared to Lagos.

The problem with getting used to inconvenience is that when things become convenient we think something must be wrong, so we tend to do things the harder way.

What are the possible stupid mental efforts you can encounter as a developer?

Using HTTPS instead of SSH to clone your repository. When you clone with HTTPS, every remote Git operation asks again for username and password. That repeated friction can be avoided by cloning with SSH.
Manual testing and deployment instead of using a CI/CD pipeline. Manually running tests and deploying code is time-consuming and error-prone when it can be automated.

Andela puts it strongly: if you bring a mentality of being okay with inconvenience, or stupid mental effort, to your job as a software developer, you will never achieve greatness.

How do you avoid wasting your mental energy on stupid mental effort?

You must enter the lazy programmer mode where you automate repetitive activities that waste your mental energy or find alternative solutions that make you more productive.

Which other stupid mental efforts can you think of, and how do you think we can address them as developers?

Understanding Serverless using a Restaurant Server Analogy

2020-03-11T00:00:00.000Z

A simple explanation of the serverless cloud model using the analogy of two different types of restaurants: traditional busy restaurants versus futuristic clone-based service.

I will try to explain the serverless cloud model using the analogy of two kinds of restaurants.

Busy restaurant with a typical server

Imagine you walk into a busy restaurant and notice that there are more orders than servers. Requests are handled first come, first served, and when demand spikes, wait times increase.

That is similar to a traditional server-based model in the cloud. One server attends to several workloads, and even when load balancing spreads the traffic, the system still depends on pre-provisioned servers.

Restaurant of the future: serverless

Now imagine a restaurant that employs a human clone outsourcing company. Every time a new order arrives, a fresh server-clone is created, assigned to that order, and destroyed as soon as the work is done.

That is the shape of serverless. A function or container image exists, and the cloud platform spins up a new execution environment for each request or event trigger.

Cloud platforms that offer serverless services let you write code in your preferred language without worrying about where to host it or how to scale it. The platform handles that operational layer for you.

What are the benefits of serverless?

It is one of the cheapest models in the cloud because you only pay when your code executes.
You do not have to worry about scaling, because each invocation gets the compute it needs.
You do not have to manage server tuning, configuration, or maintenance.

What kinds of use cases benefit from serverless?

Event-based notification work, such as sending emails or SMS messages after user registration, or generating PDFs from reports.
Time-based triggers, such as scheduled tasks that send birthday messages or generate monthly reports.

Popular serverless platforms include:

AWS Lambda
Google Cloud Functions
Azure Functions
IBM Cloud Functions

The main value of serverless is not novelty. It is the removal of infrastructure work that does not need to sit in the developer's head.

How to Containerize a React Application

2020-03-11T00:00:00.000Z

Learn how to containerize your React application using Docker with a step-by-step guide from creating a Dockerfile to running your container.

Containers and Kubernetes have become some of the enduring darlings of developers. A recent React deployment I needed to push into a Kubernetes environment made me revisit how much easier the job becomes once a Dockerfile is part of the workflow.

Before getting into the main guide, it helps to remember how much pain containers replace. In one of my internships, I worked as a pre-sales engineer for EduERP, an open-source ERP for universities.

EduERP ran on the LAMP stack and had a number of dependencies. Guiding a university through setup on its own server could take a full week because installation, configuration, and troubleshooting all had to be repeated manually. Docker would have changed that entire experience.

The modern approach

Today the workflow can be reduced to five steps:

Create a Dockerfile containing all instructions for installing dependencies and running the application.
Build the Docker image from that Dockerfile.
Push the Docker image to a container repository.
Have the client pull the Docker image from the repository.
Run the Docker container.

That shift means a setup that once took days can become a repeatable process measured in minutes.

Pre-requisites

Before starting, make sure you have:

Node.js installed in your development environment
Docker installed
A terminal of choice

If you do not have an existing React app, create one:

npx create-react-app my-app
cd my-app

Create an Nginx configuration file that the Docker image can use to serve the application:

server {
    listen 8080;
    server_name frontend;
    location / {
        root /usr/share/nginx/html;
        try_files $uri /index.html;
    }
}

Step 1: Create your Dockerfile

For React apps, the development workflow is usually:

npm install to install dependencies
npm run build to produce the optimized build output
Serve the built site through a web server such as Nginx

That sequence leads directly to a multi-stage Dockerfile:

FROM bitnami/node:12-prod as builder
WORKDIR /app
COPY ./package.json /app/package.json
COPY ./yarn.lock /app/yarn.lock
ENV NODE_ENV=production
RUN yarn install --production
COPY . .
RUN yarn build

FROM nginxinc/nginx-unprivileged
COPY ./nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 8080

Step 2: Build the image

Build the image with a tag of your choice:

docker build -t my-react-app-name .

Step 3: Run the container

To run the container, keep three things in mind:

the container's internal port
the port on your own machine
the image name you used while building

docker run -p 8080:8080 my-react-app-name

If everything works, http://localhost:8080 should serve the newly containerized React application.

Next steps

Push the image to a registry such as Docker Hub
Create a Kubernetes pod definition to run the image

With Docker containers, deployment becomes consistent and predictable across environments. That is the real payoff.

12-Factor Engineering Best Practices You Can Learn From

2020-03-11T00:00:00.000Z

Learn the 12 principles introduced by Heroku engineers for developing high-quality web applications with scale, robustness, and portability in mind.

During my Computer Science days at the University of Lagos, I used to wonder why software engineering was called engineering. Before then, I had always thought engineering had to be hardware.

Luckily, Ian Sommerville was thinking about confused people like me when he wrote Software Engineering. He described software engineering as an engineering discipline concerned with all aspects of software production.

That framing helped. Engineering is still engineering because we make things work by applying theories, methods, and tools where appropriate. We also inherit best practices from other engineers so we can avoid already solved problems.

Similarly, the 12-factor methodology introduced by engineers at Heroku offers practical principles for building high-quality web applications with scale, robustness, and portability in mind.

The 12-factor application methodology

The 12th Factor application methodology contains 12 principles for building a strong web application or SaaS product. It came from Heroku engineers after developing, deploying, and scaling thousands of applications.

Factor 1: Codebase

Track your source code in version control.
Keep one codebase per app and use branching strategies for different deployment paths.

Factor 2: Dependencies

Declare dependencies explicitly with package managers such as npm, Yarn, pip, or Composer.
Avoid copying dependencies into source code directly.

Factor 3: Config

Store configuration in the environment.
Separate secrets and environment-specific values from application code.

Factor 4: Backing Services

Treat databases, queues, and similar services as attached resources.
Be able to switch between local and managed services without rewriting the application.

Factor 5: Build, Release, Run

Separate build, release, and run stages strictly.
Use CI/CD pipelines with test and deploy stages.
Give each release a unique identifier and preserve rollback options.

Factor 6: Stateless Processes

Run the app as one or more stateless processes.
Persist state in backing services rather than application memory.

Factor 7: Port Binding

Export services via port binding.
Make it possible for one application to become another application's backing service.

Factor 8: Concurrency

Scale through the process model.
Separate HTTP work, workers, and other workloads into explicit process types.

Factor 9: Disposability

Optimize for fast startup and graceful shutdown.
Disposable processes make releases and scaling safer.

Factor 10: Dev-Prod Parity

Keep development, staging, and production environments as similar as possible.
Small gaps reduce surprises and improve continuous delivery.

Factor 11: Logs

Treat logs as event streams.
Emit logs to standard output and let external systems handle routing and storage.

Factor 12: Admin Processes

Run management tasks as one-off processes in the same environment as the main app.
Ship admin code with the application to avoid synchronization issues.

A letter to an outgoing Corper — episode one

2016-04-11T00:00:00.000Z

A heartfelt letter to graduating NYSC corps members about maintaining identity, building personal brand, and preparing for life after service to the nation.

Dear Corper,

Corper Shan! I will like to say how else can we thank you for dedicating one year of your life to serve your country. You have shown there is hope in our educational and Healy system only if we have passionate and energetic hands like you. What a great show of patriotism! What a great show of dedicated service! So what's up after service? Like are you ready for the things to come. I am writing this letter to remind you of the changes ahead and how you can prepare for it.

If you don't stand for something you will fall for anything!

First, watch out for losing your identity to the challenges ahead. Watch out for losing your voice to that of the crowd. The school and NYSC has a way of protecting your identity from the reality and harsh conditions of life. The identity I am talking about is who you have always wanted to be! Do you know it is time that the protective shell of school and government ended. Some years back, you were asked what you wanted to be in the future and you mentioned great stuff you wanted to become. The expectation on what you mentioned years back on your great future starts now. The future you talked about years ago is finally here. Nothing holds your future back again not 4 years of school, not one year of service. If you have forgotten those great dream, aspiration and hopes about your future, now is the time to remember. You wanted to be a great biochemist, a world class philosopher, a superb counsellor. However, I hear you are already changing your gears. You wanted to be a world class biochemist and I hear you applying already to be a police officer. Are you sure you are going for your passion ? You want to take any job that comes you ways. You are ready to settle for anybody, any job, any fiancé, any life. Remember anything is nothing, that way any job means no job.

Now I challenge you to recall what you told me sometimes ago. About how you wanted to be somebody, a great person whose voice will be heard and valued. Now it is time to start taking steps toward those future ambition. Let's say you want a biochemist job, you should

list out the top twenty companies/organizations that offer biochemist opportunity.
Write a powerful CV to show your are a biochemist in training who can learn and will be successful.
Then APPLY! Do cold calling or unsolicited application it is allowed!

Go for your passion now ! You wanted to be an entrepreneur now it is the time to test the market. Having formed your identity it is time to give yourself a brand.

Branding is staying true to deliver what you promised as your identity.

Second, I hear you are ignorant of what your personal brand is. You know someone once defined branding as staying true to the what you promised as your identity. A personal brand is how you project yourself. It starts from you on paper, that is your CV. Then the physical you, your dressing, your spoken and written English, social etiquette. It also speaks about your integrity.

Let's start an intro conversation on the CV. I have seen so many dry CV. Old, common and dry! I hope your CV isn't like that. And please don't use the same CV for all job roles. Each job role is unique, so your relevant experience and hobbies should change.

I even hear some of your colleagues don't have a CV yet and they are praying to get a job.

I overheard you wasted almost a page on biodata and nothing much on your relevant work experience. And some of you say you don't have work experience, you want to be an accountant and you served as the financial secretary of your CDS group for almost 11 months. Did you need the Holy Ghost to tell you that it is a relevant experience in the absence of actual formal work place experience. We will talk more about CV subsequently.

What of dressing? By now you should know the dressing of the workplace. You should know the language of the workplace. You can't wear a Khaki to an interview. You can't wear a white tennis for an interview. Now Let's talk about integrity.

Don't be part of the problems, rather be a solution to these problems!!

One of the two major problems of our country is corruption and unemployment. Don't be part of the problems, rather be a solution to these problems!! My pastor used to say your competence will open doors for you but your character will keep you in the room. Let's assume your competence has gotten you a job, problem one of unemployment is solved. Then you will have to face problem two of corruption. You will be tempted with challenges of corruption. I have heard story of young corpers who were avid advocate of anti-corruption who went on to become corrupt as they become entrenched in the system.

Make your stands known from your early days so people are aware you are a no go area!

You might even be a victim of corruption. In a case where you are to get a job and it goes to the family members of a politician. You will be met with a lot of rejections which will should talk about too.

Nobody owes you anything in this life.

Third, you should be aware nobody owes you a job. Nobody owes you anything in this life. Not even your uncle who is promising a job when you come back home. And because of this you might be met with rejections as you apply for various vacancy. It doesn't mean you are not good enough or you should give up. It is just because they can't take all the very fantastic people or maybe you haven't convinced them you are fantastic enough. In fact, I read one stat recently. It refers to the fact that an average graduate should submit their CVs in 70 organization before they are guaranteed a place in 5 companies. So be prepared for rejection in 65 others. Someone will not even get back to you.

Rejections doesn't mean you are not good enough! It means you can do better!!

Remember my friend I have said three things about identity, personal branding and rejection. Don't forget your identity. You can stay true to your identity through personal branding and be prepared for rejection of your brand.

Don't forget our service to our dear nation shouldn't stop in few days time. Service is a continuous process.

Do what you can where you are with what you have!

Happy Passing Out!

Sincerely yours,

Mr. Future

Building Kids Into Whizkids

2015-10-26T00:00:00.000Z

During my National Youth Service, I started an ICT club called 'Whizkids' to empower the next generation of technology leaders. Teaching HTML to excited kids who built their first webpage, I now challenge everyone to organize #hourofcode events and become nation builders.

If you are a techie like me you must have heard about one of these: computer science for high school, hour of code. If you are not a techie you must have heard catch them young or the leaders of tomorrow. I must have complained a lot about NYSC, I had to stop, come to think of it, the NYSC scheme puts me in a position to impact on my host community however big or small. It puts me in a position to build the next set of leaders. With obvious bias, I want the kids in my host community to be next technology leaders of their generations and digital armed forces of Nigeria. This prompted me to start an ICT club in my school.

I can not but mention that the hour of code promotional videos especially the one from Mark Zuckerberg keeps motivating me to do more with raising the next generation of ICT leaders.

Let me digress a little bit I was not lucky to start programming at 13 like Bill gate but I once did Logo programming maybe at 15 can't remember exactly and I felt good about it. However, today is not for inviting you to a pity party of how I started coding late. I am inviting you rather to a challenge. I challenge you to become a nation builder however small or big. Build someone today with your intellect and resources and stop complaining of infrastructural/system collapse in the nation.

Back to the business, the vision for the club was simple: to build next generation of technology leaders. We call ourselves "Whizkids". And our mission was to empower ourselves with contemporary tools to deliver the future. How do we get this done? We will focus on web, mobile and robotics technology.

There are a lot of options here, it was hard getting to choose which technology to actually start with. Scratch, snap, JavaScript, Python, html all staring at me. I decided to start off with html. Whatever you believe in someone agrees with you on the Internet. Someone recently said internet is going to be a place where people echo your ideas. Technologies like Facebook like, Twitter favorite and retweet are obvious examples. I stumbled on html for babies it was helpful in coming up with a curriculum.

Students excited about learning web development

Are the kids excited? Yeah they are super excited they are going to be building a website. How will you feel if at 13, if someone told you, you will be taught how to build a rocket or robot in 2 months. I will be super excited. My closest-to-techy-experience was turning my dad transistor radio to my physics experiment apparatus. It was good experience for me but it was attracted punishment from my dad.

The kids are doing well with learning that HTML code is like two slices of bread with butter. The first slice of bread is like the opening tag, the butter is the content in the middle and the closing tag is like the second slice of bread. My kids have successfully built a webpage containing their school anthem and they are excited.

Everyone who reads this I challenge you to hold an #hourofcode event for kids in your schools, churches or mosques. You can also tweet at me at @tosinamuda

Resurrected from the dead

2015-10-20T00:00:00.000Z

During my National Youth Service as an ICT instructor, I learned how PowerPoint can kill classroom engagement. Through research and student feedback, I discovered solutions to avoid 'Death by PowerPoint' and resurrect interactive learning through better presentation techniques.

I am a geek, I am excited about technology and I love to use it. Teaching ICT even drives me to use technology more. I always tell myself I can't teach technology without using technology. Apart from being passionate about technology, I am more interested in using technology to impact on the lifes of people I meet everyday.

As a matter of fact, after your undergraduate program in Nigeria, there is the compulsory national youth service. Under this scheme, I was posted as an ICT instructor to Jetters Montessori College, Jalingo, one of the best schools in Nigeria and one of the leading schools in ICT in the country. Wow, I was impressed with the level of technology infrastructure available in the school. However, the infrastructure were going into ruins because there were no capable hands to use the school e-learning facilities to teach the student.

The technology infrastructure at Jetters Montessori College

Consequently, the current situation of the school, and my passion for change and technology sets in the temptation to avoid the traditional classroom teaching for an edtech classroom.

I started out by impressing my bosses when I created my scheme of work using Microsoft Word. It was not a big deal to me but my director made it an example for others. As a faithful servant, I continued by creating my lesson plan and note with Microsoft word. I couldn't wait to start my first class with PowerPoint slides.

As a naive teacher, I had quickly forgotten that while in the University I would switch to playing either 2048 or candy crush in a boring PowerPoint class. I had powerful pictures, my PowerPoint was not wordy but something was wrong in the class. I noticed a number of students were distracted, even tried sleeping.

I guess I failed at using technology in my first class. I was tempted to quickly give up as I was advised by a fellow ICT teacher. I told myself No, technology is meant to help and it can work.

Thank God for Google, I did what I usually call counter search on "10 mistakes you could be doing with PowerPoint in class". Then, I stumbled on the phrase "Death by PowerPoint". Powerpoint is meant to power a class but it can kill a class. After the I did my online research, I went offline and did the most important research with my clients, my students of course.

I noticed the following:

PowerPoint was killing the interactiveness of the class.
The students were straining their eyes because of poor lightning in the classroom environment and the choice of background colour.
Some students have eye defects.
When you think your powerpoint is not wordy but is is actually wordy.
Too much information on one slide: more than one equation or table.

I worked with my student in proferring these solutions to avoid death by PowerPoint and also resurrect.

Enhance active learning by using a picture to start off a discussion in class.
Follow the 6 by 6 principle strictly: not more than 6 words in a bulletpoint and not more than 6 bulletpoint in a slide.
Use one word slide to start off a discussion
Use animation to delay how much information the students get at once.
Introduce varieties: try videos to start off a discussion or group discussion.
I am looking at the Takashi method as well. Using only one word per slide.

Now my class has fully resurrected from death by PowerPoint. I also now appreciate why people spend 4 years in school studying education by the day. I can't imagine how much of educational methods I will learn while trying to teach my students. I hope to conduct a research where I will compare my student performance in my course - where I use technology - to other courses - where traditional method is being used. I can't shy away from the fact that I love teaching. What about you?

And please feel free to share your own teaching method. You can also tweet at me @tosinamuda.

The Lie About The Future

2013-12-05T00:00:00.000Z

The article challenges the notion of a promising future that previous generations have promised but not delivered upon. It highlights the disillusionment of today's youth who were told they'd succeed if they worked hard but face challenges like unemployment, nepotism, and economic struggles.

Every generation - while young - admires the beauty of the future, its promises, potentials and possibilities. It is like a Nollywood story of a poor village girl who has been betrothed to a city lover who she has never met, but her parents assure her of the cuteness of the city boy and his heavy pocket, what else can the poor girl ask for. Just like the village girl, the current generation falls in love with this future they are supposedly yet to see but believes the future will come one day. They blush at being called the future leader, the greater tomorrow just like the teen tell themselves you are the cockroach in my wardrobe, of course we know any cockroach is useless, it will eventually spoil some precious cloth.

The old folks, they tell us the sweet phrases: where're the future leaders, the leaders of tomorrow. Have you ever wondered when this tomorrow will come? In high school, our teachers told us about this beautiful future. Distracted by the awesomeness of this lie, as opposed to the inquisitive nature of kids, we never ask how and when they got into theirs. This isn't how it was supposed to go! They told us we would be okay if only we worked hard. They told us we'd be successful if we studied for the exams, had the right hair-cut and had the right parents! They LIED to us!

Pause!!! This generation at 18 wakes up in the FUTURE and discovers their cities are run with thousands of youthful agberos, energetic beggars, cute prostitutes, scholarly aristos, youth discouraged by unemployment, nepotism, struggle for admission, O level exam failures, expensive data (outside blackberry though), incessant power supply. Some of them are wasting away smoking, partying, experimenting hard chemicals believing it will numb their anxiety and give them a break from the supposed beautiful FUTURE.

This was supposed to be the future. The future our principal told us about, the one the sunday school teacher told us every Sunday, in fact the political czars have a way of sweet-talking us into this future. Funny enough, the fools among them still blush at the slightest use of our future leader.

This was supposed to be the future

This generation will be fine if they accept the future is not the city boy who is going to come visiting one day, it is the moment we live in and that the beautiful story they were told won't be soon, and it won't be in the way they were made to believe. This generation can't expect to win by playing along, but what else can they do? After all, the older generations 're the ones with the power. The older folks 've got the money and the guns and the government and maybe God, the older folk sign our paycheques, mark our exams (the old professors) and grade our various crawling efforts to please. What have they got to challenge that?

I'll tell you what we this generation has got. This is the part I start using we.

We have Energy, Information(Truth), Beauty and Love. We have a flourishing counterculture that's more alive than anything the mainstream has produced in the last twenty years. We have social media, mindset deviancy. We have the talent and the information-delivery media to reprogramme the minds of Young Corporate Leaders and drive them, frothing, into the sea. We have the vote. Most importantly, we have much swag.

"Unlike them, we are truly hypertextual. We have the information and communications technology to entirely re-imagine the concept of socio-political power, and we are bright enough and brave enough to use it. We are multi-ethnic, multi-gendered, multi-talented and massively up for a fight, we are no longer frightened of your disapproval, and we have bombs."

If you accept the future leader title, you might not lead until you end up in the grave, because someone will always be alive to lie to you about your position in the future and will distract you from your position today.

Inspired by Penny Red.

Follow @tosinamuda.

Today's Sci-fi and Tomorrow's Reality: 4 Future Technologies You Will Not Believe

2012-04-07T00:00:00.000Z

Explore four groundbreaking technologies that are transforming from science fiction into reality: Internet of Things, Project Glass, driverless cars, and 3D printing.

The movie "The Social Network" before 21st century might have been a science-fiction (sci-fi); however, it turned out to be a real story. This is because prior to the 21st century, there was almost nothing like social networking, no video conferencing, maybe it was in a 1970 sci-fi but in the few space of time, man continues to discover technology that astonishes him. Technology that changes the way we communicate and process information.

I bet there are still technologies that have not entered into the heart of men coming through this century. Nothing seems to be impossible again. The Christian and the other religions of the books might call it the end-time, a philosopher might still be questioning why but as a technology enthusiast I believe this is the beginning of the end we are all anticipating for. If you are still with me permit me to take you into the future for a few minute, a future very near, permit me to introduce to you four awesome technologies you might not believe.

1. Internet of Things (IoT)

Have you ever imagined:

Googling your room to find your lost Blackberry
Your flower tweeting you to be watered
Your pot facebooking you that your food is done
Your laundry machine updating its status about being done with washing your clothes

It might have been sci-fi just a decade ago, but with the internet forcing its way into every aspect of our lives, cyberspace is leaking out into the real world. This is the future with the possibility of interconnecting people and objects – lightbulbs, fridges, cars, buildings – to create an internet of things.

"Some of the things that are possible are truly unbelievable," says Constantine Valhouli from the Hammersmith Group, a strategy consulting firm. This technology is called the Internet of things (IoT), many are already saying this is a trend bound to hit us all in the near future. There is a whole lot about (IOT) here.

2. Project Glass - The Future PC

Now let's take a deeper journey into the future to find out what CNN already calls the future PC. We've moved from a desktop internet to mobile phones and mobile internet – who knows the next step might be the recently unveiled long-rumored concept called "Project Glass," which takes all the functionality of a smartphone and places it into a wearable device that resembles eyeglasses.

The see-through lens could display everything from text messages to maps to reminders. They may be capable of showing video chats, providing turn-by-turn directions, taking photos and recording notes all through simple voice commands, according to a concept video produced by the company and released on YouTube.

3. Driverless Cars

There's still something from Google's Google X lab, the same future-thinking research facility that is working on the project glass and space elevator. However this time around is about a driverless car. The car will be integrated with Google Maps.

"Google believes it is a technology that is here and now and will start appearing in motorcars in the near future," said Professor Alan Woodward from the department of computing at the University of Surrey. "We already have systems that park your cars for you and automatically brake – the next obvious step is to have cars take over the routine driving."

4. 3D Printing Technology

We've talked about glasses and cars; yes it's all about objects, things. However, another technology worthy of mention is the 3D Printing technology.

I bet you've never imagined:

Downloading and printing your favourite delicacy online
Printing out a tennis ball or even a football

Consumer-level 3D printing technology has moved ahead in leaps and bounds in recent years with the release of devices such as the Thing-o-Matic, the Replicator and Cubify 3D printers.

In the nearest future users of this technology will be able to download designs and print everything from car parts to … well, a new and improved 3D printer. The folks at The Pirate Bay are already taking a bold step by adding a new "Physibles" category. The new category will contain digital files for objects that can be physically created using a 3D printer.

In announcing the move on its blog, The Pirate Bay describes physibles as "data objects that are able (and feasible) to become physical." Watch out for a future with huge benefits in terms of savings on shipping and (child) labour, with users even able to literally print food to feed the hungry.

The Future is Now

Technology as a promising world-view in a not-too-distant future will make life richer and comfortable. Imagine getting a tweet from my farm in the village through my project glass in my driverless car. It's a beautiful world I'm sure you will be waiting for.

The convergence of these technologies represents more than just individual innovations – they represent a fundamental shift in how we interact with our environment and each other. As we stand on the brink of this technological revolution, one thing is certain: the future is arriving faster than we ever imagined.