AI Writes the Code. Judgment Still Decides What Ships.

Most of the discourse around AI and software engineering right now sits in one of two camps. Either AI is coming for every developer's job, or AI is a toy that real engineers don't need. We don't sit in either camp, and we've stopped pretending the debate is interesting. At ETAPX, every engineer on the team builds alongside AI as a normal part of how the day goes, not because we're chasing a trend, and not because we think the model is smarter than the person driving it, but because the alternative is slower, and slower doesn't survive contact with a small team trying to ship a live-streaming platform, a payouts system, and a merch storefront at the same time.

The Fear We Don't Share

There's a version of this conversation where the interesting question is whether AI will replace developers. We think that's the wrong question, and answering it either way tells you nothing about how to actually run an engineering team in 2026. The right question is narrower: given that AI-assisted development exists and works, what happens to a team that refuses to use it, next to a team that does? At a company the size of ETAPX, one where the same handful of engineers touch Whistlr's live infrastructure, the Creator Studio desktop app, Gems payouts, and the WTC tab in the same sprint, that gap compounds fast. A team standing on principle against AI-assisted development isn't making a moral stand. It's choosing to ship slower for reasons that don't show up on the roadmap.

Judgment Over Raw Access

AJ has said this plainly in earlier pieces on this blog: the scarce resource was never access to a powerful model. Everyone building software right now has access to roughly the same handful of frontier models. The thing that actually separates a team that ships something real from a team that ships something plausible-looking is judgment, knowing which fifteen percent of a generated diff to keep, which eighty-five percent to throw out, and which five percent should never have been asked for in the first place. That's not a model problem. That's an engineering problem, and it existed before any of this, just aimed at a different kind of input: a junior engineer's pull request, a contractor's rushed implementation, a library you didn't write yourself. AI-assisted development didn't invent the need for judgment. It just increased the volume of code arriving at the door that needs it.

The model can produce ten plausible implementations of a payouts flow in the time it takes a person to read one. Our job was never writing code fast. It was always deciding which version doesn't quietly lose someone's Gems.

ETAPX engineering

This is the same argument AJ has made about the product itself, not just the code behind it. Whistlr doesn't gate creators behind a follower minimum before they can go live, and it doesn't make someone wait a month to see money from Gems land in their account. Those are both judgment calls about where access should be unrestricted and where a human still has to decide something matters. Engineering works the same way internally. Access to a capable model is unrestricted, every engineer has it, nobody has to ask permission to use it on a given ticket. What's not unrestricted is which surfaces get to ship on a generated first pass and which ones get a person sitting with the diff line by line before it goes anywhere near production.

What This Actually Buys a Small Team

Here's the concrete version, because the philosophy only matters if it changes what ships. ETAPX is not a thousand-person engineering org. The team that built the Business+ account tier, wired Gems payouts down to a one-to-two-day turnaround instead of the thirty-day hold that's standard almost everywhere else, and shipped the WTC tab inside Creator Studio is small enough that everyone on it can name every other person on it. A team that size doesn't get to spend a month on boilerplate. AI-assisted development is how a handful of engineers cover the surface area that used to require three times as many people, not by replacing the thinking, but by clearing out the parts of the day that were never thinking in the first place: scaffolding a new screen in the Studio desktop app, wiring up a form for Storefront listings, writing the fortieth variation of an API client, or turning a spec for Circuits or Flow into a first-pass implementation someone can actually react to.

• The first draft of a feature stops being the expensive part, which means more of an engineer's week goes to the parts that actually require a human: pricing logic on the WTC tab, the exact behavior of a payout ledger, or what happens when a stream drops mid-transaction.
• Small, correct changes ship more often, because the cost of trying an approach and throwing it away dropped enough that engineers actually do it, instead of committing to the first idea out of sunk cost.
• The distance between an idea raised in a product conversation and a testable build running in the Studio app shrinks from weeks to days, which matters more for a company Whistlr's size than almost any other lever available to it.

None of that is about typing faster. It's about what a small team can afford to attempt in a week, and whether trying something and being wrong about it costs so much that nobody tries anything unproven.

The Tradeoff We're Not Going to Pretend Doesn't Exist

The honest risk here isn't that AI writes bad code. Frontier models write serviceable code most of the time. The honest risk is what happens to an engineer's judgment once the code in front of them stops costing effort to produce: the temptation to stop reading it as closely, to trust the confident tone of a generated explanation over an actual understanding of what a payout ledger does when two writes race each other. That's a real failure mode, and pretending it isn't real is exactly the kind of thing that gets described later as we didn't see it coming.

That rule sounds obvious written down. It isn't obvious under deadline pressure, which is exactly when it matters. The version of this that fails isn't a team that never uses AI-assisted development on sensitive code. It's a team that uses it correctly for six months and then, on the one Friday afternoon where a release is late and everyone wants to go home, lets a generated change through on the assumption that it's probably fine because the last twenty were. That's not a hypothetical about ETAPX specifically. It's the actual shape of how this kind of mistake happens anywhere, and the only defense against it is a rule that doesn't bend for how tired anyone is that day.

Why review got more specific instead of lighter

What changed at ETAPX isn't that code review got shorter because AI wrote the code. It's that review got more targeted. Nobody spends time flagging a missed semicolon or an inconsistent variable name anymore, that class of note has mostly disappeared, because the tooling catches it before a human ever needs to. What's left for a human reviewer is the part that was always the actual job: does this match how Gems payouts are supposed to behave, does this WTC pricing change do what the creator expects when they publish it, does this Storefront checkout path handle the case where inventory hits zero mid-order. That's a smaller list of questions, and it's a harder list of questions, and engineers spend more of their attention on it than they did two years ago, not less.

Why This Isn't a Threat, It's a Bet on the Team We Already Have

There's a version of adopting AI-assisted development that treats it as a way to need fewer engineers. That's not the bet ETAPX is making, and it's worth saying directly instead of letting it sit as a vague reassurance. The team building Whistlr didn't get smaller once AI-assisted development became normal here, the list of things that team ships in a quarter got longer. A native Studio app, RTMP support for any encoder a creator already owns, a payout system that beats the industry-standard hold by weeks, a merch storefront in PX Shop, close-circle sharing in Circuits, a feed in Flow, all of that exists because a small team could attempt more of it in the same amount of time, not because AI was doing the parts that mattered.

We're not going to tell you AI-assisted development is a solved problem, or that it removes the hard parts of building software. It doesn't. It moves the hard parts somewhere else, toward judgment, toward review, toward knowing which fifteen percent of a suggestion to trust, and that's a trade we'd make every time, because the parts it removes were never where the actual engineering was happening anyway. The scaffolding was never the point. Whether a creator's Gems land in their account in a day instead of a month always was.