Last week I wrote about constraint. The idea that AI isn’t unreliable, unconstrained usage is. This week I want to go deeper into what constrained usage actually looks like in practice.
The shift that changed everything for me wasn’t a new tool or a better prompt template. It was a mental model. I stopped thinking of AI as a tool I commanded and started thinking of it as a teammate I collaborated with.
That sounds soft, but the results weren’t. On a recent WordPress migration for a major editorial platform, we estimated 232 hours for the content and meta migrations. The actual time was 80 hours. Same scope. Same quality bar. Same review rigor and rollback safety. Different way of working.
Here’s what changed.
Two teammates, one mission
I started thinking of AI as two distinct teammates, each with a different role.
The first is a product manager. Before I write any code, I use AI to shape the work. I describe the problem, the outcome I want, and the constraints I’m working within. The AI asks clarifying questions, surfaces edge cases, and helps me build a clear plan.
For a recent side project, I needed a Gravity Forms plugin that would let users draw a boundary on a map and submit it as an image. Instead of jumping into code, I asked ChatGPT to act like a PM and create a Product Requirement Document. It asked the right questions: What format should the image be? Should the map library be replaceable? Should the image be visible in the admin or just stored?
By the end, I had a PRD that was sharper than most I’ve written manually. It covered the what, the why, and crucially, what wasn’t included.
The second is a junior engineer. Once the plan is clear, I hand it to a coding agent. I treat it like a capable but inexperienced developer who needs clarity and occasional correction. I give it the PRD, point it to relevant examples in the codebase, and let it handle the systematic parts.
That plugin took two hours from PRD to working code. Five clarifying prompts along the way. No mystery, no drift.
You’re the tech lead
This model only works if you stay in the loop.
You’re not delegating to AI and walking away. You’re the tech lead. You provide the context that the AI can’t see. You set direction. You define boundaries. You review the output. You make the calls when the work needs judgment or creativity.
The AI handles the systematic, repetitive parts. You handle everything that requires understanding the domain, the client, the editorial workflow, and the business constraints. The stuff that isn’t written down anywhere.
What not to delegate: Mapping decisions. Architectural choices. Anything where you’d need to explain the “why” to a stakeholder. Anything where the wrong call could break something downstream. If a decision requires context the AI can’t see, keep it.
This division matters. When I let AI make decisions it shouldn’t be making, the output drifts. When I stay in the lead role, it stays on track.
Pairing, not prompting
The other shift was in how I communicate with AI.
I stopped trying to write “perfect prompts” and started describing problems the way I would to another engineer. Instead of “write a script to transform shortcodes into blocks”, I’d say “we’re migrating legacy shortcodes to modern blocks. I need you to find which ones exist, how they’re used, and what their attributes look like, so we can plan the transformation.”
That’s not a prompt. That’s a conversation.
Modern tools like Claude Code, Cursor, and Junie are good at understanding intent. You don’t need clever syntax. You need clarity. Explain the why, describe the outcome, and give an example or two. Let the AI ask questions if something doesn’t make sense.
Knowing when to take the keyboard
One more thing: knowing when to stop.
AI gets stuck sometimes. It repeats the same mistake. It loops on an edge case. It tries to solve something it doesn’t have enough context for. That’s not failure. It’s a signal that the work needs human judgment.
When I’ve given the AI clear instructions and examples, and it still isn’t producing after a couple of attempts, I take the keyboard. I fix the tricky part myself, update the spec with what I learned, and hand the next task back.
This is pair programming, not automation. Sometimes you drive. Sometimes your partner drives. The skill is knowing when to switch.
The model matters more than the interface
Tools change. Models improve. What stays constant is how you think about the relationship.
If you treat AI like a command-line tool, you’ll get command-line results. Transactional. Brittle. Dependent on getting the syntax exactly right.
If you treat it like a teammate, you get collaboration. You get something that can help you think, not just type. You get speed without losing control.
That’s the difference between prompting and pairing. And it’s the difference between AI that frustrates you and AI that actually helps.
This post explores the Execute phase of the Controlled Acceleration Model.