Notes from the Back Row: What Happens When a Builder Finally Stops Needing Permission

I've spent 16 years as the bridge. Between clients and developers. Between creative vision and technical execution. Between "we need this" and "it's shipped." I've led teams of twelve, managed $20K monthly budgets, launched a men's cosmetics brand from research through formulation, and sat in more standups than I can count. I've always been hands-on. Just never with the code itself.

That changed in October 2025. Now I sit in the back row of tech events, six projects deep, wondering why I ever needed the middleman.

---

The Real Timeline (And the Ibby Moment)

October 2025. I started dabbling with AI and building. Just last year.

November, I met Ibby again in Surabaya. "Fixer" Ibby, who's been running around the world getting things done. He has no coding experience. But he knew my background, my 16 years of bridging teams and shipping products, and he wanted to see what I could do with these new tools.

December and January, we started sitting together. Not him teaching me. He can't code. Just talking about AI this and AI that. He'd push me, ask what was possible, watch me struggle through the basics. I knew my team was already using AI tools. I was just using it for note-taking and productivity, talking to it like any other assistant.

February 2026. Library Cafe in West Surabaya. Ibby essentially said: just pick it up and do it yourself.

When I returned to Sri Lanka, I was equipped with new tools and a new path. Not because Ibby showed me how to code. Because he saw what I could become before I did.

Since then? Six projects. One big ERP. A few tools for myself. Some ideas that turned into working code. I didn't go from zero to Cursor overnight. I went from "managing builders" to "being the builder" over months of actual shipping, with Ibby's push at exactly the right moment.

Three months ago, I had a team. Client paying me to pay them. Senior developers with subscriptions to everything. Claude Pro, GitHub Copilot, the constant chatter about "we need this tool" and "get that subscription." Always another $200 monthly fee for productivity that never quite arrived.

After months of that investment? Login demos. A few pages. Everyone was excited at the time. Looking back, I wonder: did they know how to use these tools? Or were we all just subscribing to the idea of productivity?

I parked the project. Let them go. Started building myself.

Walking into that Colombo event yesterday, my first tech event in Sri Lanka, I found a seat toward the back, notebook out, still processing if I'd made the right call. Three hundred people packed the room. Five or six young organizers running around pulling strings with sponsors like Gemini and Anthropic. The energy was unmistakable.

---

The Validation (From Someone Who Knows Delivery)

Nick from Cursor took the stage. I expected a product demo. Instead, I got something that stopped my pen mid-sentence:

"It's about spec-driven development. Having context when we speak to an agent makes all the difference."

I felt that in my chest. For 16 years, my value has been context. I know how to talk to a client in New York or a developer in Colombo. I know what "fast" means to business and what "technical debt" means to engineering. I've built Kavemen's supply chain, managed distributed teams across time zones, and learned that clarity beats cleverness every time.

But more than that, I'm the guy who carries all the notes in my head and paper for reference. I remember conversations with CEOs in London: "That's not what the DevOps guy said in the standup." "That's not what the client said." My brain has always been filled with contexts and conversations, bridging gaps that other people didn't even know existed.

That's why I became the middleman for every project I handled. Writing stories, epics, OKRs countless times. Translating. Validating. Shipping through other people.

And here was Nick saying that in this new world, that's the skill. Not syntax. Not framework expertise. The ability to specify clearly, to provide context, to know what success looks like.

I sat there thinking about my git history. Six projects since October. Commits that would never have existed in my old workflow, not because I couldn't manage them, but because they'd be buried under estimation meetings and resource debates and "we'll get to it next sprint." Now I have one site live and several approaching launch. I built that. Me. The operations guy who always had to ask someone else to execute.

No $200 subscriptions. No debates about which AI model to use. Just me, the spec, and the outcome.

This isn't foreign to me. It's the same pattern I used building Kavemen: research, validate, build, ship. The tools changed. The mindset didn't.

---

The Serendipity (Builders Recognizing Builders)

After the sessions, someone approached me. "Drifting Desk?" I squinted, trying to place him.

Turned out he was someone I'd worked with in the past, maybe two years ago. We'd only ever worked remotely. First time meeting in person, and he's at a Cursor event in Colombo. Small world gets smaller.

We caught up. He's moved on, working on agentic workflows now. Burning agentic AI for building and marketing automation. We talked tech. My brain kept spinning with more ideas and potentials I could work on. I compartmentalized it for another day.

We talked about where careers go from here. His, mine, everyone's. No conclusions. Just two people who've managed and built and shipped, standing in a conference hallway realizing the ground has shifted.

It felt like pieces falling into place. Like the 16 years of bridging, the Kavemen years of figuring it out, the months with Ibby learning to build, the recent solo shipping, all of it converging.

---

What I Learned (Applied to How I Actually Work)

Back to my messy notes. Here's what stuck from Nick's talk:

Context is Counter-Intuitive (And I Needed to Hear This)

The research: smaller context windows, better results. 47% less consumption, more accuracy. Don't dump everything into the chat. Start fresh for each focus. Keep it local.

This runs against every operations instinct I have. My instinct is to over-communicate, provide background, make sure everyone has "all the context." But agents aren't team members. They don't need the company history. They need the task, the constraints, and the definition of done.

I thought about my old team. The constant tool-switching, the subscription churn, the never-ending search for the perfect setup. Maybe the context problem wasn't technical. Maybe it was focus. That's a lesson I should have applied from Kavemen: you don't need every ingredient, you need the right ones in the right order.

Debug Mode: For the Bugs You Park (And I Have One)

The developer went through hypothesis A through JJ. When A-Z runs out, it goes to AA-ZZ. They found the fix at JJ.

I sat there thinking about the bug I parked last month in my ERP. Reproduced it, tried logical paths with the agent, got nowhere. Made the call: "I can come back to this later. Now I need to ship." Classic operations thinking: risk management, prioritization, move on.

But hearing that Nvidia story, realizing Debug Mode generates hypotheses until the alphabet runs out, that parked bug suddenly feels addressable. Not by me brute-forcing logic, but by letting the mode do what it's designed for: systematic, exhaustive hypothesis generation.

I've been debugging manually, reproducing issues, guiding agents down specific paths. That works for 90% of problems. But for the 10% that survive your patience? That's what Debug Mode is for.

Now I'm ready to ship my ERP. That parked bug? It's getting the JJ treatment.

These are the same three beats Cursor uses in their Debug Mode announcement: screen recordings bundled with the post. I copied the files into our /public folder so previews don’t depend on a third-party CDN.

References:

• Agent Modes: cursor.com/docs/agent/modes
• Debug Mode: cursor.com/docs/agent/debug-mode
• Debug Mode Announcement: cursor.com/blog/debug-mode

Bugbot: The QA Team I Was Planning to Hire

Then Nick mentioned Bugbot, and I felt like a kid at a toy store who just found exactly what they wanted but didn't know existed.

I've been wondering how to test my ERP properly. Real testing. Bug testing. Not just "does it load" but "where will this break when real users hit it." I was making mental notes about hiring QA, about testing protocols, about all the infrastructure that comes with shipping something real.

And there it was: Bugbot. I sat there thinking, I know exactly where you will be useful. I know what I'm going to do with you.

The loop is clever. Bugbot reviews code, finds issues, spins up a cloud agent to fix them, submits the fix, reviews again. It's not just automated testing; it's automated fixing. For a solo builder who needs to ship but can't afford to ship broken, this feels like having a QA team that works while I sleep.

I'm already planning how to deploy it on the ERP before migration. My future apps? They'll go through the Bugbot cycle before I call them done.

Still frames and diagrams from Cursor’s own write-ups, mirrored here for the same reason as the Debug clips.

References:

• Bugbot Product: cursor.com/en-US/bugbot
• Bugbot Documentation: cursor.com/docs/bugbot
• Building Bugbot: cursor.com/blog/building-bugbot
• Bugbot Out of Beta: cursor.com/blog/bugbot-out-of-beta

---

The 90-Day Filter (Applied to Tools, Not Just People)

Here's a framework I've used for years with developers and interns: "You have 90 days. Deliver, and you're in. Don't, and we both move on."

Sometimes that decision happens in hours. Sometimes days. 90 days is the ceiling, not the floor. I've let people go after their first standup. I've kept others for years. But nothing, no person, no process, no tool, gets more than 90 days to prove it can ship.

It's not about pressure. It's not about hazing. It's about delivery. I've watched too many people optimize for learning the wrong things, subscribing to the right tools, attending the right standups, without ever shipping. 90 days is enough to know if someone can take a brief and get it out the door. Often, you know sooner.

I realized recently I've been running my tools through the same filter.

Gemini didn't renew. Claude got cancelled. A dozen other subscriptions, AI tools, dev environments, productivity apps, none made it past 90 days. Some failed in the first week. Cursor is the only one that survived. Three months now, still delivering. My paid subscription runs at 85% utilization monthly because I'm actually building, not experimenting.

Not marketing. Not hype. Just a builder who needs tools that deliver, and finally found one that does.

That 90-day rule served me well with people. It's serving me better with software.

---

What I'm Doing With This (The Experiment)

I'm not just observing. I'm testing.

Next week, I'm taking my 14-year-old nephew, who's helped with Kavemen and my other businesses, learns fast, asks better questions than some developers I've managed, and giving him a Cursor account. Not to "teach him to code." To see if he can take an outcome and deliver it.

If a teenager with no formal training can ship with these tools, the barrier isn't technical knowledge. It's clarity of thought. Knowing what you want and describing it precisely.

That's a skill I can teach. That's a skill I've been teaching for 16 years, just always through other people.

---

This Weekend: Nature, Perfume, Surf, Maybe Building

I'm heading south for a few days. Beach, fresh air, making perfumes for Kavemen Lab, surfing if the waves cooperate. Maybe some building, maybe not. Bringing my nephew for time away from screens.

My ERP is at that critical stage: ready for migration, needs polish, that parked bug waiting for the JJ treatment. But this weekend isn't about that. It's about letting the pieces settle. The knowledge from yesterday, the plans for Bugbot, the hypothesis waiting to be tested. It'll all be there Monday.

Sometimes you need to step away to let the work happen. That's the whole point of cloud agents, isn't it? The work continues while you live.

---

What This Means (For Builders Who've Always Been Hands-On)

If you've spent your career figuring things out, whether that's formulation, supply chains, team coordination, or product delivery, these tools are for you.

Not to replace teams. To remove the friction between "I know what we need" and "it's built."

I used to go to bed worrying about whether my developers were working, whether they'd hit the demo, whether I'd explained the requirement clearly enough. The subscriptions kept growing. The output stayed flat.

Last night, I slept fine. The agent was working. I didn't check Slack. I didn't send a "just checking in" message.

That's not just convenience. That's a fundamental shift. From managing people who use tools, to using tools that let you build.

The 300 people in that room weren't just developers. They were builders. Some had coded for years. Some, like me, were just figuring out that they could. The organizers, those five or six young people, they weren't waiting for permission either. They pulled strings, got sponsors, made it happen.

That's the energy I'm carrying into next week. Not anxiety about "am I doing this right?" Confidence that "I know what I want to build, and I finally have tools that let me build it."

Sometimes you have to let go of what isn't working to find what was meant to be. Three months ago, that meant a team and a project. Yesterday, it meant sitting in the back row, taking notes, watching the future arrive right on time.

The pieces fall into place. You just have to be willing to see them.

---

Full Cursor Documentation Reference

For anyone exploring these tools, here's the complete link pack from my notes:

Core Documentation:

• Docs Index: cursor.com/docs
• Hooks: cursor.com/docs/hooks
• Third-party Hooks: cursor.com/docs/reference/third-party-hooks
• Subagents: cursor.com/docs/subagents
• Agent Modes: cursor.com/docs/agent/modes
• Debug Mode: cursor.com/docs/agent/debug-mode
• Cloud Agents & Automations: cursor.com/docs/cloud-agent/automations
• Bugbot Docs: cursor.com/docs/bugbot

Product Pages:

• Marketplace: cursor.com/marketplace
• Automations: cursor.com/automations
• Bugbot: cursor.com/en-US/bugbot

Blog Posts:

• Plan Mode: cursor.com/blog/plan-mode
• Debug Mode: cursor.com/blog/debug-mode
• Automations: cursor.com/blog/automations
• Building Bugbot: cursor.com/blog/building-bugbot
• Bugbot Out of Beta: cursor.com/blog/bugbot-out-of-beta

Inline logos: Google, Anthropic, and NVIDIA SVGs from Simple Icons (CC0). Cursor app icon from cursor.com. Screen recordings and product stills above are mirrored from Cursor’s official blog posts (Debug Mode, Building Bugbot, Bugbot out of beta, Plan Mode) and remain © Cursor / respective owners; used here for editorial reference.

---

Written the day after the Cursor 3 event in Colombo. Based on notes taken from the back row, a chance hallway reunion with someone from my past, six months of building since October 2025, and 16 years of being the bridge. Thanks to Ibby for the push at Library Cafe. Heading south now for surf, perfume-making with Kavemen Lab, and time away from screens. The ERP and the parked bug will wait. They always do.

---

For other operators who've started building: What's your experience been? Did you have a "let the team go" moment, or did you find a way to bring them with you?

For the developers I've managed: If we worked together, know this isn't about failure. It's about me finally understanding what was possible. The tools changed. I hope you're building amazing things with them now.

For someone I worked with in the past: Thanks for that hallway conversation. The agentic AI work you're doing is exactly where this is heading. Let's keep comparing notes. We're figuring this out from different angles.

For Ibby: You know what you did. Let's catch up again soon.