From Skeptic to Orchestrator: The 'Aha' moment that changed the way I build software

I didn’t wake up one day and decide to let AI take over my workflow. In fact, my journey started with a healthy dose of skepticism and ...a free t-shirt.

Like many developers, my first real exposure to AI coding tools was GitHub Copilot, introduced to me while I was working at Sky. At first, it felt like a magic. It wasn't just a clever chat where I had to paste snippets and hope to hit the jackpot; it was actually reading my files and cross-referencing them.

But the "magic" had limits.

As I tried to use it for larger projects, the cracks started to show. The single-agent model felt like a "jack of all trades, master of none." It would get overwhelmed by complex tasks, its memory would bloat, and eventually, I gave up. I went back to using it for low-context tasks or fixing unit tests (which, to be fair, it was great at).

I thought that was it. AI was a helpful junior assistant, but not a game-changer.

The T-Shirt That Changed Everything

Fast forward a few months. I learned about Amazon Q and a contest they were running: "Build games with Amazon Q CLI and score a t-shirt."

My immediate reaction? Free t-shirt to try a new tool? Count me in.

I didn't know it then, but that contest was pivotal. It required me to use a CLI tool.

Wait, AI in the CLI?

That changed everything. Suddenly, the AI wasn't just suggesting code; it had access to all my bash tools. It could run commands. It could interact with my environment. I submitted my attempt at an AI-made game, Tetris clone. Oh, and you can actually play it here if you want to see what a CLI-orchestrated agent can do in minutes.

Months later, the t-shirt actually arrived across the ocean (yay!).

But more importantly, the seed was planted. The CLI was powerful, but I still felt limited by the platform lock-in. I could only really use AWS tools. I needed something more flexible if I wanted to fully commit.

Meeting My "Dev Team"

That’s when my good friend Piotr Swiderski introduced me to OpenCode.

My first reaction was the standard skeptic’s question:
"What does this do better than the agents I already have?"

The answer came in two parts.

1. The Freedom to Swap Brains With OpenCode, I wasn't married to one model. If Gemini produced code I didn't like? Swap to GPT. If GPT started hallucinating? Swap to Claude. I could pick the best brain for the specific problem at hand, all while keeping the same deep context, much wider than what I was used to.

2. The Specialist Squad This was the real "aha" moment. In previous tools, I was talking to one agent that tried to do everything. It was a bottleneck.

OpenCode let me create custom agents.

Imagine building an app and suddenly having a Frontend Expert, a DevOps Engineer, a Product Owner, and a Business Analyst at your disposal. They are all aware of each other. They share the same context. But they have their own capacities and specialties.

I wasn't just a solo developer anymore. I was leading a team.

The Shift to Orchestration

That t-shirt from Amazon Q is still in my drawer, but the lesson it taught me is what I use every day: The CLI is the frontier, and orchestration is the future.

Leading a "team" of agents has fundamentally changed my role. I’ve moved from being the one who types every line to being the one who directs the vision, shifting from "writing code" to "orchestrating solutions." This new workflow feels more sustainable and powerful for a few key reasons:

• No More Context Collapse: Instead of one agent getting confused after the tenth message, I have a workflow where I delegate tasks to specialists who stay focused.
• Model Agnostic Power: I’m no longer locked into one provider. If Claude is better at logic but Gemini is faster at boilerplate, I use both in the same session.
• Verification over Generation: My role has shifted. I spend less time fighting syntax and more time verifying architecture and shipping features that actually matter.
• Instant Experimentation: When a fun new tech emerges, I don't have to spend hours reading docs just to get a hello world. I can start using it and experimenting in seconds by delegating the initial setup to a specialist agent.

This blog series is my documentation of that journey, the wins, the failures, and the tools that actually work in production.

I’m planning to share more about the specific workflows, comparisons, and lessons I’ve learned from my recent projects soon. If you enjoy this type of content and want to see more of my thoughts on the future of development, make sure to keep an eye on this blog or follow me on LinkedIn.

See you very very soon.