Your Agents Can Now Ship From Slack. Who's Allowed to Say No?
Slack Code puts agents, diffs and live previews in the same channel as your sales team, which makes the person with veto power over what merges your most valuable hire
In six years as CTO, I don't think I was ever the person on the team who wrote the most code. Not once. By year three I was maybe in the bottom third by lines shipped, and the company was going from 4 engineers to 31 and from pre-revenue to profitable at 10M monthly active users.
The job was never typing. The job was saying no.
No, we're not adding that field to the users table. No, that endpoint doesn't get to talk to the payment service directly. No, we're not launching that feature Thursday, because the migration behind it is one-way and you will hate me in March. That was the work. Everything else was negotiable.
I've been thinking about that this week because Slack launched code channels where humans and agents build together, with GitHub, Anthropic and Vercel wired in, diffs and live previews rendering inline. Plan the work in the channel, an agent writes it, everyone watches the diff, someone clicks the preview link, it ships.
I haven't used it. It launched yesterday. But I've been shipping MVPs with agent tooling all year, and I know exactly what this changes and exactly what it doesn't.
What it actually changes
It drags software development into the same room as everything else.
That's genuinely new and genuinely good. For most of my career, engineering happened in a place non-technical founders couldn't see. Jira, GitHub, a standup they weren't in. The founder's window into the work was a status update from someone with an incentive to sound confident. I've watched that gap wreck trust at three different companies. The CEO thinks nothing is happening, the engineers think they're drowning, and both are right.
Putting diffs and previews in Slack collapses that. A founder from a sales background can look at a channel and see something moved. They can click a preview and use the thing. That's a real improvement, and I don't want to be cynical about it.
Here's the part that worries me.
The read a lot of founders will take
If you're a funded founder with no CTO, this launch reads like a reprieve. Agents write the code. The tools are in the app you already live in. You can describe what you want, watch it appear, click the preview, and it looks right.
So maybe you don't need to hire anyone yet.
That's the wrong conclusion, and it's expensive. Writing the code was never your bottleneck. Even before agents, you could rent code cheaply. Contractors, agencies, offshore teams, a good junior with time. Getting characters into files has been a solved, purchasable problem for a decade.
Your bottleneck is the person who can look at a diff and say no, that's wrong, before it merges.
What "wrong" actually means here
It doesn't mean the code has a bug. Agents are decent at not writing bugs, and getting better fast. Wrong is a different category.
Wrong is a data model that works fine for 400 users and requires a six-week rewrite at 40,000. Wrong is authentication logic that's technically functional and quietly lets one customer read another customer's records. Wrong is a third-party service getting baked into the core of your product because it was the fastest path in that Slack thread, and now leaving it costs you a quarter. Wrong is shipping a feature that works and that nobody asked for, which is the most common failure of all.
None of that shows up in a live preview. A preview shows the happy path in a browser. It cannot show you the shape of the decision underneath.
I ship MVPs with these tools now. The agents are good. What breaks is never the syntax. What breaks is that nobody with judgment looked at the shape of what got built before it hardened. And things harden fast. A schema decision made on a Tuesday in month one is still constraining you in month fourteen, except now it's load-bearing and touching it means downtime.
Agents accelerate bad decisions at exactly the same rate as good ones
This is the whole argument, so I'll be blunt about it.
An agent in a Slack channel does not have a stake in your company in eighteen months. It does not know that you're about to sign an enterprise customer with a SOC 2 requirement. It doesn't know that the "quick" integration your head of sales is asking for in the thread commits you to a vendor's roadmap. It optimizes for the request in front of it, executed well and executed now.
When a channel full of non-technical people can trigger work, and an agent executes cheerfully and instantly, the natural rate of decision-making goes up by an order of magnitude. If the quality of those decisions stays flat, you don't get a faster company. You get to your architectural reckoning three times sooner with three times the code to unwind.
I've seen the slow version of this. A team I worked with had eight months of feature velocity that looked fantastic on a burndown chart and produced a system where changing the pricing logic meant touching nine services. Nobody made a bad call. Nobody said no, either, and forty small yeses compounded into one very bad quarter.
So hire the veto, not the hands
Your first real technical hire should not be the person who types fastest. It should be someone with architectural judgment and actual ownership over what merges. Someone whose name is on it. Someone who will tell you no in front of your head of growth and be right often enough that you stop arguing.
That person is expensive full-time, and honestly, at 1-15 people you may not have enough decisions per week to fill their calendar. Fine. Rent it. That's the entire reason fractional CTO work exists, and it's why we run it in two-week sprints at $4,500 rather than pretending you need someone at a desk five days a week. If what you need is the thing built rather than the thing governed, we do fixed-scope MVPs at $14,500 and I own the architecture decisions inside it.
Either way, the shape is the same: one person with judgment, accountable for what ships, present at the moment the decision gets made rather than three months later during the postmortem.
Slack Code will make your team faster. Speed is only an asset if someone in the channel has the standing to stop it.
If you're staring at a code channel wondering who's supposed to be reviewing any of this, book thirty minutes and I'll tell you honestly whether you need someone yet.