I Used Amazon Q CLI to Build a Feature for Amazon Q CLI (And It Was Mind-Bending)

Ever wondered what it’s like to use an AI tool to improve itself? I just spent 2 hours using Amazon Q CLI to build a new feature for Amazon Q CLI, and the experience was genuinely mind-bending.

The feature? A real-time usage tracker that shows your context window consumption as you chat. But the real story is how AI-assisted development has fundamentally changed what’s possible when you’re building software.

The Problem That Bugged Me

I’ve been using Q CLI daily for development work, and there was this one thing that kept nagging at me. The /usage command gives you great insights into your context window consumption, but only as a snapshot. I wanted to see how my token usage evolved during conversations.

You know that feeling when you’re deep in a complex discussion with Q, and you start wondering “am I about to hit the context limit?” The existing command made you break flow to check. Not ideal.

So I decided to build a real-time tracker. What I didn’t expect was how surreal it would be to have Q CLI help me build Q CLI.

The Meta Development Experience

Picture this: I’m sitting there asking Q CLI to analyze its own codebase, suggest architectural improvements for itself, and help debug its own features. It’s like having a conversation with a system about how to make itself better.

> Can you analyze the usage.rs file and explain how token counting works?

Q CLI proceeds to explain its own internals with the kind of detail you’d expect from the original developer. It understood the 4:1 character-to-token heuristic, the progress bar implementation, even the color coding logic.

Then it got weirder:

> Can you create a spec.md for this feature?

Q CLI wrote a 6KB specification for its own enhancement. Complete with technical requirements, UI mockups, and implementation phases. I was essentially having the tool design its own improvement.

Specification-First Development (Because Q Said So)

Here’s something I learned: Q CLI is opinionated about good development practices. When I wanted to jump straight into coding, it suggested creating a proper spec first.

Smart move. The spec prevented scope creep and gave us clear success criteria:

Goal: Real-time context window monitoring
Non-Goal: Complex analytics dashboard (save that for v2)
Success Criteria: Accurate, non-intrusive, zero performance impact

The spec became our north star. Every time I wanted to add “just one more feature,” I could refer back to it and stay focused.

The Implementation Journey

Phase 1: Understanding the Beast

First challenge: understanding how Q CLI actually works internally. This is where the meta aspect really kicked in.

> How does the existing usage calculation work?

Q CLI walked me through its own architecture:

• Context files, tools, assistant responses, user prompts all counted separately
• Visual progress bars with color coding (green → yellow → red)
• Character-to-token conversion using a 4:1 heuristic

Having the tool explain its own internals was incredibly efficient. No digging through documentation or reverse-engineering code. Just ask.

Phase 2: The Architecture Dance

The implementation needed three main components:

1. Event System - Track usage events as they happen
2. Display Manager - Show info without disrupting chat flow
3. Integration Points - Hook into existing message pipeline

Q CLI suggested starting with the event system:

pub struct UsageEvent {
    pub timestamp: SystemTime,
    pub tokens_used: usize,
    pub context_limit: usize,
    pub message_tokens: usize,
    pub session_id: String,
}

Clean, simple, extensible. The AI understood that we might want historical tracking later, so it included timestamp and session_id from the start.

Phase 3: The UX Reality Check

This is where things got interesting. My first implementation was technically elegant but completely unusable.

Iteration 1: Full terminal takeover
Result: Completely blocked user interaction. Oops.

Iteration 2: Async background overlay
Result: Messages appeared briefly then vanished. Better, but still broken.

Iteration 3: Direct integration
Result: Usage info appears naturally in chat flow. Perfect.

The lesson? Sometimes the simplest solution is the best solution. Q CLI helped me realize that trying to be clever with terminal manipulation was missing the point. Users just wanted to see their usage without disruption.

The Debugging Detective Story

During testing, I hit a critical bug. The numbers didn’t match:

• Regular /usage: 13,720 tokens (6.86%)
• Realtime tracker: 0 tokens (0%)

That’s… not good.

> The metrics don't align. Please investigate why.

Q CLI quickly identified the issue: I was missing tool tokens in my calculation. The fix was straightforward once identified:

// Before: Only conversation messages
let total_tokens: TokenCount = (data.context_messages + data.user_messages + data.assistant_messages).into();

// After: Include tools (matching regular usage)  
let total_tokens: TokenCount = (data.context_messages + data.user_messages + data.assistant_messages + tools_char_count).into();

Having Q CLI debug its own feature was surreal. It understood exactly what the regular /usage command was calculating and could spot where my implementation diverged.

The Final Result

After 2 hours of development, here’s what we built:

> /usage --realtime
✓ Realtime usage tracking enabled
Usage info will appear after each response

> Hello, can you help me with some code?
> I'd be happy to help you with your code! What are you working on?

[Context: 11.21% (22/200k tokens)]

Features delivered:

• Real-time context monitoring ✅
• Accurate token calculation (matches /usage exactly) ✅
• Non-intrusive display ✅
• Simple toggle functionality ✅
• Zero performance impact ✅

Development Metrics That Matter

Total Time: 2 hours
Lines of Code: ~150 lines
Files Modified: 4 files
Coffee Consumed: 2 cups
Mind-Blown Moments: Several

Time Breakdown:

• Research & Planning: 30 minutes
• Initial Implementation: 45 minutes
• Debugging & Refinement: 45 minutes

Compare that to traditional development where understanding a new codebase alone could take days. AI-assisted development compressed the entire learning curve into minutes.

What This Means for Development

This experience highlighted something profound about AI-assisted development:

1. Context Understanding is Everything

Q CLI didn’t just help with syntax or boilerplate. It understood the architectural patterns, the user experience goals, and the existing codebase conventions. That’s the difference between a code generator and a development partner.

2. Iterative Feedback Loops Are Incredibly Fast

The cycle of implement → test → get AI feedback → refine happened in minutes, not hours. When something didn’t work, Q CLI could immediately suggest why and how to fix it.

3. Specification-First Development Actually Works

Having Q CLI insist on proper specs wasn’t just good practice—it was essential for keeping the AI focused and preventing feature creep.

4. Simple Solutions Often Win

The most technically elegant solution (async overlay) wasn’t the best user experience. Q CLI helped me recognize when I was overengineering.

The Meta Moments

Some genuinely surreal moments from this development session:

• Self-Documentation: Having Q CLI help document its own new features
• Real-Time testing: Watching usage metrics update as I asked Q CLI for development help
• Architectural Self-Awareness: Q CLI suggesting improvements to its own design patterns

It felt like pair programming with the system itself. The tool understood its own strengths, weaknesses, and improvement opportunities better than any external developer could.

What’s Next?

This real-time tracker is just Phase 1. The spec includes future enhancements:

• Historical usage analytics
• Performance optimization alerts
• Multi-session aggregation
• Web dashboard integration

But for now, Q CLI users have a simple way to monitor context usage without breaking flow—built with Q CLI’s own help.

The Bigger Picture

This wasn’t just about building a feature. It was a glimpse into the future of software development. When AI tools can understand their own architecture, suggest improvements, and help implement changes, the development process fundamentally changes.

We’re not just using AI to write code faster. We’re using AI to think about software architecture, user experience, and system design. The tool becomes a collaborative partner in the creative process.

Summary

Building a real-time usage tracker for Amazon Q CLI using Q CLI itself was a fascinating meta-development experience that showcased the power of AI-assisted software development.

Objectives:

• Demonstrate AI-assisted development workflows
• Show how specification-first development improves outcomes
• Explore the meta aspects of using AI tools to improve themselves

Deliverables:

• Real-time usage tracking feature for Q CLI
• Development methodology insights
• Framework for AI-assisted feature development

The key insight: AI-assisted development isn’t just about writing code faster—it’s about having an intelligent partner that understands architecture, user experience, and system design. When the tool can help improve itself, we’ve crossed into genuinely new territory.

Try the feature yourself: update to the latest Q CLI and run /usage --realtime in your next conversation. Watch your context window usage evolve in real-time, and remember—this feature was built with Q CLI’s own help.

I hope someone else finds this useful.

References:

• Amazon Q Developer CLI Documentation
• Q CLI github Repository