I thought this would be a weekend project. Well it is a weekend project, but it was extended to 4 weekends more.
A small CLI. A few commands. Something to quickly test APIs and move on. No UI, no complexity.
I was wrong.
This series is about building a small developer tool and discovering that “simple” is often the hardest constraint to keep.
The goal was to make a CLI to test APIs, like Postman but designed CLI-first.
The first thing is that I needed a way to write the tests and parsing a new designed DSL. How hard could it be, right?... RIGHT!?...
I started knowing nothing about parsers. I built one from scratch, got it working, and then slowly realized it wasn’t maintainable or scalable. The code did the job, but every change felt risky. Tracking how the input format evolved over time was already getting difficult.
If you think writing a parser is hard... try to do one in Rust... you will cry.
Then digging on the web I discovered grammar-based parsing with .pest, which completely changed how I thought about structure, updates, and long-term maintainability—even for a small tool.
Also along the way, I experimented with AI coding agents (because who doesn't at this point). I tried Gemini CLI, OpenCode, and Claude Code. Sometimes they were genuinely impressive: generating working code, exploring alternatives, and speeding up repetitive tasks.
But there were some problems. Don't get me wrong ai-agents are great but sometimes they suggested too much code or slop, and adjusting the prompt on how or where I want the code can take more time than just writing it myself.
More than once, I had to stop, step back, and rethink the architecture before continuing—reminding myself that simplicity and maintainability mattered more than momentum.
This project eventually became Axotly, a lightweight CLI tool for testing APIs.
In this series, I’ll write about:
- Learning parsers from zero and why my first approach didn’t scale.
- Using .pest to make change safer and structure explicit.
- Experimenting with AI agents—and knowing when to ignore them.
- Designing small tools that stay simple over time.
If you’ve ever built something “small” that turned into a design lesson, this series is for you.
Top comments (0)