DEV Community: Josiah Mbao

Building Terminal GPT: How Plugins Turned a Chatbot into an AI Agent

Josiah Mbao — Sat, 24 Jan 2026 18:25:55 +0000

From Simple CLI Chat to the Real Insight: Plugins as the Boundary Between Reasoning and Action

When I first started building Terminal GPT, I envisioned a simple CLI chat interface with an LLM backend. But as I iterated through the architecture, something unexpected happened - the plugin system I built to extend functionality became the most fascinating and powerful part of the entire project.

The key insight: plugins aren't just features - they're the essential boundary between AI reasoning and real-world action. This architectural pattern fundamentally changed how I think about building AI systems.

Why Plugin Architecture Matters

What started as a way to add basic file operations and calculations evolved into a formalized plugin architecture that fundamentally changed how my AI assistant interacts with the world. Instead of being limited to text-based responses, my AI can now:

Read and write files
Perform complex calculations
Access live sports data
Execute system operations
And much more through extensible plugins

The Architecture That Made It Click

The real learning moment came when I realized that plugins aren't just features - they're a fundamental architectural pattern for building AI systems that can actually do things.

Key Design Decisions:

1. Formal Plugin Contracts

class Plugin(ABC):
    name: str
    description: str
    input_model: Type[BaseModel]
    output_model: Type[BaseModel]

    async def run(self, input: BaseModel) -> BaseModel: ...

2. Automatic Registration
Plugins automatically register themselves with the LLM, creating a dynamic tool ecosystem.

3. Structured Input/Output
Pydantic models ensure type safety and clear contracts between the AI and tools.

4. Isolated Execution
Each plugin runs in its own validated environment with error boundaries, ensuring failures are contained and don't crash the entire system.

The Technical Stack

Backend: Python with FastAPI for the REST API
CLI: Rich terminal interface with beautiful formatting
LLM Integration: OpenRouter for flexible model access
Plugin System: Pydantic for contracts, async/await for execution
Architecture: Clean separation with domain-driven design

What I Learned

The plugin architecture taught me that building AI systems isn't just about the model - it's about creating a framework where the AI can leverage external capabilities. This pattern:

Makes the system infinitely extensible
Provides clear boundaries between concerns
Enables graceful failure handling
Creates opportunities for community contributions

Personal Touch: Building My Own AI Agent

What makes this project especially cool for me is that I'm essentially building an AI agent from scratch. As a Houston Rockets and Manchester United fan, I've added sports tools so my AI can answer all my stat-head questions. I've also given the AI some personality - it's got a laid-back, slightly whimsical character that makes our conversations more engaging. It's like having a coding buddy who's also into sports and can actually do things, not just chat!

The Star of the Show

What began as a simple file reader plugin is now a sophisticated system where the AI can reason about which tools to use, chain multiple operations together, and provide structured results back to the conversation.

What's Next?

I'm curious to hear your thoughts on what tools would be valuable in an AI assistant like this. I'm thinking about:

Git operations (status, commits, branches)
Code analysis and refactoring suggestions
System monitoring and diagnostics
Package management (pip, npm, cargo)
API testing and documentation generation

What would you add to make this more useful in your daily development workflow?

Media Assets

Screenshot 1: Terminal Interface

Show the CLI interface with a conversation where the AI has just executed a plugin, displaying the structured results.

Screenshot 2: Plugin Architecture Diagram

The mental model: AI reasons about what to do, then hands off to specialized plugins that safely perform actions and return structured results.

Code Snippet: Simple Plugin Implementation

Here's a clean example of how easy it is to add new capabilities to the system:

from pydantic import BaseModel
from terminal_gpt.domain.plugins import Plugin

class ReadFileInput(BaseModel):
    path: str

class ReadFileOutput(BaseModel):
    content: str

class ReadFilePlugin(Plugin):
    name = "read_file"
    description = "Reads a text file from disk"
    input_model = ReadFileInput
    output_model = ReadFileOutput

    async def run(self, input: ReadFileInput) -> ReadFileOutput:
        content = Path(input.path).read_text()
        return ReadFileOutput(content=content)

I'd love to hear your thoughts on plugin architectures in AI projects. What patterns have you found useful, and what would you add to make systems like this even more powerful?

Shipping CoinPeek: Building a Real-Time Crypto Monitor in Rust

Josiah Mbao — Fri, 09 Jan 2026 21:36:52 +0000

Shipping CoinPeek

A 572KB WASM binary. Zero network requests after initial load. Real-time crypto prices in your terminal.

Why I built it

I was tired of tab-switching to check ETH prices. Every context switch cost me 30 seconds of focus. So I built a terminal dashboard in Rust that shows live market data without leaving my IDE/terminal.

The core TUI (terminal user interface)

Performance Benchmarks

Metric	Value
WASM bundle size	572 KB
Memory footprint	~8 MB (terminal) / ~15 MB (web)
Price update latency	< 100ms (WebSocket)
UI render time	< 16ms (60fps)
Cold start (web)	~300ms
Binary size (macOS)	2.1 MB

Architecture

Terminal app: Ratatui TUI + SQLite for offline persistence
Web app: Yew + WebAssembly (same core logic)
Data layer: WebSocket streaming from Binance (no polling)
Storage: tokio-rusqlite with bundled SQLite (works offline)

The same core logic compiled to WebAssembly and rendered in the browser using Yew.

Lessons Learned

Building CoinPeek reinforced that shipping beats perfection. The first version had hardcoded API calls and no error handling. But it worked — and that momentum carried me through polishing, testing, and CI automation.

What would you add next? A portfolio tracker? Alerts? Sound off in the comments.

Links

Repo: https://github.com/josiah-mbao/coinpeek
Live web: https://josiah-mbao.github.io/coinpeek/

How I Built a Zero-Config CLI That Generates READMEs in 60 Seconds

Josiah Mbao — Fri, 02 Jan 2026 10:34:14 +0000

README files are usually the last thing I write.

Not because they’re unimportant — but because by the time the code works, I just want to ship. Over time I noticed the same pattern: inconsistent sections, missing install steps, or a README that didn’t reflect the project at all.

I didn’t want a smarter template. I wanted less friction.

So I built a small Python CLI that generates a clean, GitHub-ready README with almost no setup.

Design goal: zero configuration

The main constraint I set for myself was:

A developer should be able to try it in under 60 seconds.

That ruled out:
• Config files
• Manual template selection
• Long command flags

If that felt slow or confusing, the tool had failed its goal.

Implementation decisions

Typer for CLI ergonomics

I chose Typer because:
• Type hints double as CLI definitions
• Commands stay readable as the tool grows
• Help output is clean by default

This helped keep the surface area small while still being extensible.

⸻

Jinja2 templates (tested) Templates are easy to add — but easy to break.

Instead of treating them as static files, I:
• Versioned templates
• Added tests to validate output structure
• Enforced required sections per template

This avoids generating a README that looks polished but misses critical sections.

⸻

Smart defaults over questions. Rather than asking everything, the tool:

• Infers project name from the directory
• Suggests sections automatically
• Only prompts when needed

Fewer prompts = faster flow.

⸻

Rich for feedback, not decoration I used Rich sparingly:

• Clear success/failure messages
• Human-readable errors
• No unnecessary animations

CLI tools should feel calm, not flashy. But also not boring.

⸻

What I learned shipping my first PyPI package

One thing I didn’t expect was how different “working locally” is from “working once published.”

In my first release, readmegen init ran — but didn’t actually generate a README.
The issue wasn’t the logic. It was packaging.

I hadn’t bundled my Jinja2 templates in the PyPI distribution, so once installed, the CLI couldn’t find them.

That forced me to learn:
• How Python packaging actually works
• Why MANIFEST.in matters
• How to include non-code files in a distribution
• Semantic versioning and republishing fixes properly

It was frustrating — but also satisfying. Shipping something people can install teaches lessons you don’t get from local scripts.

⸻

What I deliberately didn’t add (yet)

There’s currently a placeholder for AI enhancement.

I could auto-generate descriptions, features, or usage sections — but I’m cautious. Bad AI-generated docs can be worse than no docs at all.

Before adding it, I wanted to understand how developers actually feel about it.

⸻

Where this could go next

Some ideas I’m considering:
• AI-assisted rewriting (opt-in)
• Project structure analysis for smarter sections
• README linting / suggestions instead of generation

But I’m trying to keep the core simple.

Try it (if you want)

pip install readmegen-oss
readmegen init

Repo + docs are here: https://github.com/josiah-mbao/ReadmeGen
Live site: https://josiah-mbao.github.io/readmegen-site/

Question for you

Would you ever let AI write your README files?

I'm genuinely curious before pushing this further.