Six months ago, I made a decision that probably looked insane from the outside: I decided to run Strug City—a real company shipping real products—with an AI engineering team doing most of the technical work. Not as a demo. Not as a proof of concept. As the actual operating model.
Strug Works, our autonomous virtual engineering team, now handles backend services, frontend features, infrastructure updates, and documentation. The team decomposes missions into tasks, writes code, runs tests, and ships pull requests—often while I'm asleep.
I'm not here to sell you on this being easy, or even being the right choice for most companies. But if you're wondering what it actually looks like to run a one-person org with AI doing real engineering work, here's what I've learned.
The Stuff That Actually Works
Infrastructure work is where Strug Works shines. Database migrations, API endpoint additions, authentication flows, test coverage improvements—these are well-defined problems with clear success criteria. When I need a new Supabase table or a new FastAPI route, I can dispatch the mission and move on. The agents know the stack (Next.js 14, TypeScript, Python, Supabase), they know our conventions, and they rarely miss.
Documentation and content generation have been a revelation. I used to let docs drift. Now, when code ships, documentation ships with it. Stream entries summarizing what changed. Blog posts explaining why. Release notes that actually help users. The sc-content-writer agent handles most of it, pulling from commit history and keeping everything aligned with our brand voice.
Bug fixes happen faster than they ever did before. A silent bug that would have taken me a day to track down and fix? Strug Works can hunt it, patch it, test it, and ship the PR in an hour. Not every time—but often enough that I trust the system.
The Stuff That's Hard
Product decisions still require human judgment. Agents can implement features, but they can't decide which features matter. I still own product strategy, prioritization, and the messy work of figuring out what customers actually need versus what they say they want.
Context management is an ongoing challenge. Agents don't intuitively understand the mental model of the system the way a human engineer would after six months on the team. I've built Strug Recall (our organizational memory system) to help, but it's not perfect. Sometimes an agent will solve a problem we already solved, or miss a pattern that should have been obvious.
Code review is still on me. Every PR gets reviewed. I've learned to trust but verify. Most of the time, the code is solid. But occasionally there's a subtle bug, a performance issue, or a design choice that doesn't fit the bigger picture. The agents are good—but they're not infallible, and neither am I.
The Things I Wish I'd Known
First: this model only works if you're willing to build in public and iterate fast. There's no hiding mistakes when your agents are shipping multiple times a day. I've learned to be okay with imperfect releases, rapid fixes, and transparent communication about what's broken.
Second: you have to be technical. I'm not just a product person directing traffic—I'm reading every PR, fixing the things the agents can't, and making architectural decisions that shape how the entire system works. If you can't code, this model won't save you. It will amplify you, but only if you already know what good code looks like.
Third: the orchestration layer is everything. Strug Works isn't just Claude with a code editor. It's a task system, a memory system, role-based agents, Linear integration, GitHub webhooks, and a mission control interface (Dispatcher) that lets me decompose big goals into executable work. Building that orchestration took months. It's not something you can buy off the shelf—yet.
What This Means for You
If you're a solo founder or a small technical team, the question isn't whether AI agents can do engineering work. They can. The question is whether you're willing to build the scaffolding to make them effective.
That means clear task decomposition. Strong conventions. Good memory systems. Fast feedback loops. And a human in the loop who knows the difference between good code and code that just works.
We're shipping Strug Works as a product later this year precisely because I've been running it as an organization first. Every feature we build is one we need. Every bug we fix is one we hit. Every workflow improvement is something that made my day-to-day better.
That's the moat. We're not guessing what autonomous engineering looks like. We're living it.
What's Next
Right now, I'm focused on two things: continuing to scale Strug Works internally (more agents, more roles, more autonomy) and preparing to bring it to market as a product that other technical founders can use.
I'm also working on Sabine, our AI partnership platform, and BanditsTracker, an athletic excellence platform for coaches. Both are being built with Strug Works doing most of the heavy lifting.
If you're curious about what we're building or how the system works, follow along. Everything we do is public. The wins, the losses, and the weird edge cases in between.
This is Act V. We're bringing it to market. And we're proving that one person, the right AI team, and the audacity to build in public can create something real.