Your CEO Should Not Be Slacking Your Coding Agent
June 4, 2025
The new wave of asynchronous AI coding platforms makes it entirely possible for your CEO to make a feature request via a Slack message and have a fully autonomous coding agent such as Devin or Codex pick up the task and start implementing it.
I’m here to tell you this is a Really Bad Idea, at least for now.
These “fully autonomous” coding agents still consume precious bandwidth from your human engineers. Allowing folks outside your team to push engineering work to the top of your team’s queue via a Slack message wasn’t a good idea before AI, and it’s not a good idea now.
Allow me to elaborate…
The state of the art
The cutting edge of asynchronous AI coding tools - think Devin, or OpenAI’s Codex - allow your non-technical colleagues to kick off improvements to your codebase by simply making a natural language request. Something like:
Hey @Devin, please add a new dropdown to the Org Details section of the onboarding flow which records whether the organization is tax-exempt. It should default to unchecked.
Each request triggers a fully autonomous AI agent, which will whir away asynchronously in the background, looking through your codebase, making changes, running tests, and eventually submitting a PR.
Magical!
Well, yes. But also no.
The limitations
As discussed here and here, even the most capable AI models aren’t ready to work unsupervised - anything but the most trivial feature request will require human shepherding. My go-to metaphor is to treat the coding agent like a weirdly knowledgable engineer who just joined your company this morning, and who has a very junior design sense.
We should treat the “fully autonomous” changes from a coding agent like the first ticket picked up by a brand-new, fairly junior hire.
Even if a lot of code is produced, the PR still incurs a non-trivial cost on the team which owns the codebase. The changes need to be reviewed carefully - much more carefully than a PR from a human teammate. There will likely be various problems with coding style, questionable design choices, missing or badly abused tests, and so on.
This doesn’t mean that coding agents are worthless - for very straightforward changes they can get 90-100% of the work done in a truly autonomous way. That’s truly remarkable! And for more involved tasks they can still perform a large chunk of the grunt work - although, as I’ll touch on later, a more synchronous human-in-the-loop approach will usually be more productive.
Autonomous AI should not steal your team’s autonomy
Given their current capabilities, any time someone asks a coding agent to do some work they’re also asking human engineers to babysit that work.
Giving someone the ability to kick off coding agent tasks via a Slack message (or web UI, or whatever) is essentially granting them the power to distort your team’s priorities. It’s not that different from just letting that person go into your project management tool and move cards around.
This phenomenon isn’t new - engineering teams have always faced pressure from frustrated stakeholders who want to bypass established processes and jump the queue. The impacts are familiar: product management gets circumvented, strategic roadmap work gets deprioritized in favor of whatever caught a leader’s attention that morning, and the team struggles to make coherent progress on their product.
Slacking a task to a coding agent is the most recent iteration of a leader wandering over and shoulder-tapping their favorite engineer - the one who always says yes and seems to make quick progress, but incurs the hidden costs of a team cleaning up behind them.
Your PM is your team’s interface
You should restrict the operation of these fully-autonomous coding agents to the product delivery team which owns the relevant codebase. But your stakeholders can still have a direct channel for feature requests - your team’s Product Manager! They can still simply send a Slack message>
Hey @<Team’s PM>, please add a new dropdown to the Org Details section of the onboarding flow which collects whether the organization is tax-exempt. It should default to unchecked.
A good Product Manager will take this message and do all the valuable things a PM does - clarify requirements, figure out how it fits into the existing UX (and future vision), thoughtfully prioritize the work. Maybe the next step after all that is for the PM to send a coding task to an autonomous agent!
Coding agents are an amazing addition to your team
Fully-autonomous coding agents are an impressive step forward. But with the capabilities they have today, they’re best used for the most trivial coding chores that your team might otherwise not get to - removing a feature flag, upgrading a library, perhaps adding an extra field to a form.
Additionally, there is a large set of more complex coding tasks where your team can still benefit from using agentic AI, but with a much tighter human-in-the-loop flow, using something like Cursor or Claude Code. I’m not sold on the benefits of an asynchronous agent here, because the feedback loop is much more painful. An analogy might be trying to fix a build error locally, vs trying to fix it by repeatedly pushing commits into your CI/CD pipeline.
But, regardless, you should keep the operation of these fully-autonomous coding agents within an engineering team. They are nowhere close to a free lunch. Allowing your stakeholders to directly prioritize your team’s work (via an autonomous agent, or otherwise) sabotages your autonomy and could seriously hamper strategic progress towards your product vision.