I've spent the last month watching how teams use cto.new, and I've noticed a few patterns in what works and what doesn't. It's not really about the setup, most people figure that out fine. It's about how you think about delegating work to an AI agent.

Start small, build big

The biggest mistake I see is starting with the most complex, important task. Someone will come in, describe their entire feature roadmap, and expect cto.new to nail it on the first try. That's not how this works, and honestly, that's not how it should work.

Instead, start small. Pick a bug that's been sitting in your backlog. Add a simple feature. Something you could fix in an hour yourself, but you're curious to see how the agent handles it. This serves two purposes: you learn the tool, and you build a sense of what it's actually capable of.

Be Specific About What You Want

The quality of what cto.new produces is directly tied to how clearly you communicate. This isn't magic. If you say "improve the frontend," you'll get something mediocre. If you say "add a loading spinner to the checkout button using the existing Spinner component in utils/ui, and make sure it follows the pattern in CheckoutForm.tsx," you get something you can actually use.

Same goes for success criteria. If you have tests or specific patterns you want followed, include them in the task description. The agent doesn't guess, it works from what you give it.

Treat It Like a Real Teammate

This is important: review the code. Actually review it. Don't just merge it because it's from an AI agent. Comment on it. Request changes if something doesn't feel right. This does two things. First, it keeps you accountable for the quality of your codebase. Second, the agent learns. It remembers your feedback and applies it to the next task.

The more you work with cto.new, the more it understands your style, your preferences, your architecture. It becomes less like a generic tool and more like someone who knows your project.

Rethink What You're Doing With Your Time

The biggest the time you get back, and what you can do with that time. If cto.new handles the routine stuff-bug fixes, boilerplate, refactors - you spend your cycles on architecture decisions, code review, and the parts of your job that actually need human judgment.

Queue up a few tasks overnight. Let it work while you sleep. In the morning, you've got PRs to review instead of code to write. That's a different way of working.

The Catch That Isn't a Catch

I'll be honest: there's no catch here. It's completely free. But there is a learning curve, and that curve is steeper if you treat it like a magic box. It's not. It's a capable agent that works best when you treat it professionally-be clear about what you want, review the output, and give it context about your codebase.

The teams that get the most out of CTO.new are the ones who spend five minutes setting up their integrations and ten minutes writing clear task descriptions. That's it.

Where to Go From Here

If you're curious, sign up at cto.new. Start with that small task I mentioned. See what happens. Join the Discord if you get stuck or have questions. And if it works for you-and I think it will-start thinking about which parts of your development workflow you want to hand off.

That's how background agents can start to radically improve how you build.