🌱 Dive into Learning-Rich Curation with groCTO ⤵️
Article of the Week ⭐
“I think what many engineers have found so alienating and terrifying about the last two years of AI discourse has been the way so many prominent AI voices appear to be gleefully declaring that software is no longer an engineering problem.”
Charity Majors documents what actually changed in 2025 and what it requires from engineering teams now. The core argument: the shift in code production economics changed where rigor should live, and most teams haven’t caught up.
The economics of code production reversed in 2025. Writing code went from expensive and slow to effectively free and instant. Lines of code moved from carefully maintained assets to disposable outputs, regenerable on demand.
Shared understanding is the actual product. Engineers have historically learned systems by writing and reading code. When code is cheap to produce in bulk, the question becomes how to know what the system actually does. Behavioral tests, characterization tests, and observability answer that. Software engineering has historically deprioritized all three.
Human validation is a poor default. Human brains are bad at the nitpickiness and repetition that validation requires. Majors argues that placing engineers as the primary quality gate wastes their best capacity, and that harnesses and automated evals do it better.
Engineering discipline determines what you actually get from AI. Teams with short feedback loops, clear specs, and observability in production get better outcomes. Without those, faster code production means faster accumulation of technical debt nobody fully understands.
The piece draws on Chad Fowler’s Phoenix Architectures framework: code has become a cache of understanding. When regenerating code is cheap, the constraint shifts to knowing what to generate. Evals, behavioral specs, and production observability become the actual engineering artifacts that matter.
Majors was a sysadmin through the move from handcrafted servers to immutable infrastructure. That transition shapes how she reads the current one. The teams that thrived then built rigor early.
You set the definition of “done.” This piece gives you a framework for updating it.
The conversation around AI in engineering has largely centered on adoption and acceleration. How many developers are using AI tools, how much faster code is being written, and how quickly PRs move through the pipeline. These are valid data points, but they describe the surface of a much deeper structural shift.
AI now directly influences what gets built, how it gets reviewed, and what risk profile the software carries when it reaches production. The engineering system that leaders are responsible for governing has fundamentally changed, but the governance model around it, the metrics, the review cadences, and the decision frameworks remain largely unchanged. This asymmetry is where organisational exposure quietly compounds.
The team at Typo AI developed a framework called AEGIS to bring structure to this problem. It evaluates AI’s impact across five interdependent dimensions: Adoption, Execution, Guardrails, Integrity, and Sustainability. The intent is not to measure how much AI is being used, but to make visible how AI is altering delivery behaviour, where it creates genuine leverage, where it introduces new forms of risk, and where the trade-offs between speed and durability need deliberate leadership attention.
"The question for leaders is no longer whether AI is helping. It's whether the system AI is reshaping is getting stronger or quietly more fragile, and most measurement models aren't built to answer that." — Kshitij Mohan, CEO & Founder, Typo AI
Almost every leader has at least one major weakness. The difficulties arrise when a leader and their direct reports share the same gap, and it happens more than most orgs admit.
Leaders hire what they recognize. They evaluate candidates on the dimensions they understand, which means gaps don’t get covered. They get copied. Stay SaaSy calls it stacked weakness: two operationally weak leaders in a row means zero chance of operational strength underneath them.
The unknown unknown problem. Many leaders don’t know they should be hiring for something because they don’t know that thing exists. They can’t spot the gap, so the job description never mentions it.
This is most acute right now in AI. A CTO without hands-on experience shipping AI products can’t evaluate whether the team’s approach is sound, can’t write a job description for the gap, and often can’t tell when someone is managing upward to cover it.
Self-audit across 6 areas. Technical knowledge, management, process/operations, strategy, presentation, and raw aptitude. Rank yourself honestly, find the low scores, and hire into them deliberately.
Nobody above you is running this audit. Either you do it, or the gaps persist.
Will Larson, CTO at Imprint, spent the past year revising how he runs his engineering org as AI tooling changed the pace of work. The numbers set the context: 6 manual deploys a week to 200-400 automated deploys; Claude Code and Cursor adoption from 25% to 100% of the team in 2 months, with no top-down mandate.
First-pass code is cheap; working code is not. The cost of quality still depends on your development harness: tests, CI/CD, validation environments. Generation speed changed. Everything that makes code safe to ship did not.
Slop PRs are actively harmful. Cheap drafts generated at speed don’t just waste review time. They load the model context with noise and produce worse output than starting fresh. Larson is direct: the context poisons the next run.
Durable teams matter more, not less. The prevailing idea that AI-first companies will run on a small group of genius engineers doing everything solo doesn’t hold in practice. Domain context still limits execution, and persistent, specialized teams are how you accumulate it.
Decision-making speed is now the binding constraint. Every ambiguous call is a bottleneck agents can’t route around. That’s why the CTO role has gotten substantially more technical in the past year. Someone has to make binding calls fast, and that person needs to understand the system well enough to make them.
The teams getting the most from AI have already solved for clarity of direction. Without it, more speed means more of the wrong thing, faster.
That’s it for Today!
Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week, Ciao 👋
Curators - Diligently curated by our community members Denis & Varun
Featured Authors - Charity Majors, Stay SaaSy, Will Larson
Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.