Ashby’s post lays out a pragmatic AI-assisted engineering model rather than a pure “replace programmers with agents” pitch. The company says engineers should use LLMs in two modes: a close-in “sidekick” mode for interactive help, and a more hands-off “delegate” mode for scoped tasks. It also insists that humans remain responsible for every line shipped, and tries to show that rising AI usage has not caused an obvious blowup in customer-reported issues.
That basic operating model landed better than the slogan sitting on top of it. Many readers hated the claim that the “cost of producing code is heading towards zero,” because it collapses the expensive parts of software into typing. The stronger reading of the post was that keystrokes are getting cheaper while the hard parts stay put: deciding what to build, communicating intent, reviewing changes, checking correctness, and absorbing the cost of failure. That is why the most useful part of the piece for experienced engineers was the split between sidekick and delegate workflows. Several people said sidekick mode matches reality better because code review and understanding quickly become the bottleneck when an agent can spray out large diffs.
The biggest skepticism was aimed at Ashby’s evidence. The chart tying AI adoption to stable customer issue rates looked too thin to support the thesis, especially because it covered a short time window, bundled usage into crude buckets, and waved away a visible seasonal spike as a recurring blip. The author conceded that the data does not prove AI keeps quality stable. At best it suggests there was no immediate bug apocalypse. That admission sharpened the real takeaway: if AI is helping, the proof is not in a high-level vanity chart. It is in whether a team can keep review quality high while output rises.
That led straight into the incentive problem. Readers did not dispute that “you are responsible for what you ship” sounds good. They doubted most organizations will enforce it when promotion systems still reward visible velocity more than legible quality. Ashby’s leaders replied that they inspect PRs during performance reviews and call out both weak code structure and strong communication. That answer reassured some people, but it also underlined how management-heavy this model is. AI-assisted engineering only works if technical managers are close enough to the work to spot when people are using the tools to think better versus using them to dump review debt on everyone else.
A second thread widened the lens from coding to software businesses. Even if code gets much cheaper, several readers argued that this does not mean vertical
SaaS markets suddenly fragment into thousands of winners. Enterprise buyers care about trust, depth, support,
vendor risk, and operational maturity, not just feature checklists. Ashby’s own product became the example. Some hiring managers said it feels merely adequate or bloated, while the founders answered that they intentionally optimized for flexibility and coverage first because simple, elegant products keep losing in
ATS buying processes. That exchange made the broader point more concrete than the AI memo itself: cheap code may lower entry costs, but it does not erase the messy commercial work of building serious software companies.