Raul Delapena Setiawan
In the modern enterprise, software is often treated as a product of sheer technical output—lines of code written, features shipped, and tickets closed. However, Titus Winters, a prominent software engineer and thought leader, argues that this perspective is fundamentally flawed. Software, he posits, only holds true value when it is successfully deployed to customers. In his keynote at the Craft Conference, "Software Workflow Optimization," Winters challenged the industry to move beyond superficial metrics and embrace a more holistic understanding of the development lifecycle.
The Holistic Framework: Develop, Deploy, Operate
The traditional view of software engineering often conflates distinct activities, leading to inefficient resource allocation. In his recent paper, Develop, Deploy, Operate — a holistic model for understanding the costs and value of software development, co-authored with Leah Rivers and Salim Virji, Winters outlines a tripartite model that separates the software lifecycle into three distinct, yet interconnected, processes:
- Development: A creative, human-centric process focused on problem-solving and innovation.
- Deployment: A rigorous, industrialized "factory" process.
- Operations: An automation-driven process focused on maintaining stability and reliability.
Winters emphasizes that these phases are not merely different tasks; they require entirely different mentalities, performance metrics, and financial investments. Organizations that attempt to manage deployment with the same "creative" mindset used for development, or that treat operations as a manual task rather than an automated discipline, inevitably face bottlenecks.
The Four Pillars of Technical Impact
According to Winters, the health of a software organization must be measured across four fundamental pillars:
- Product Success: Are we building the right things for our users?
- Compute Capacity: Are our infrastructure costs optimized and sustainable?
- Engineering Capacity: Are we effectively utilizing our most expensive asset—our people?
- Strategic Innovation: Are we creating long-term value, or just maintaining the status quo?
The danger, Winters warns, lies in unbalanced optimization. For instance, an organization might reduce compute costs by cutting back on automated testing. While the balance sheet might show a temporary dip in infrastructure spend, the resulting technical debt, production instability, and engineering burnout often lead to significant bottom-line losses that far exceed the savings on compute.
The People Problem: Measuring the Unmeasurable
Perhaps the most provocative argument Winters presents is that the software industry has spent decades obsessing over the wrong metrics. Companies meticulously track cloud spend, token consumption, and server utilization, yet they largely ignore the "biggest line item" on the balance sheet: human engineering time.
"We’ve been measuring everything except the biggest line item, which hardly seems rigorous," Winters noted. Because software engineering is fundamentally a creative and social endeavor, quantifying the output of a developer remains an elusive challenge. We can count commits, but we cannot easily measure the nuance of problem-solving or the long-term strategic impact of a well-architected system.
This oversight creates a blind spot in leadership. Without a clear understanding of where engineering time is actually going—whether it is spent on high-value innovation or wasted on "toil" and inefficient processes—strategic decision-making becomes guesswork.
The AI Shift: A Catalyst for Deeper Problem Solving
The emergence of Generative AI has transformed the discourse around software productivity, often clouding the fundamental lessons that remain as true today as they were a decade ago. While some fear that AI will replace engineers, Winters offers a more nuanced, optimistic perspective: AI is not a tool for shrinking the workforce, but a catalyst for shifting the focus of the engineer.
"The shift that we are looking towards is not a reduction in the number of engineers," Winters argues. Instead, he envisions a transition away from the obsession with raw, syntax-level coding expertise toward a deeper, more sophisticated understanding of the actual problems being solved.
In this new paradigm, the engineer acts as a conductor. AI tools handle the boilerplate and the implementation of established organizational policies, while the human developer remains the final authority, ensuring that the software solves a real-world business need. The AI does not free the developer from "guardrails"; rather, it operates within a system that encodes organizational expertise, allowing the developer to focus on the unique, high-level complexities that AI cannot yet navigate.
Experimental Engineering: AI as a Proxy for Human Effort
One of the most innovative takeaways from Winters’ work is the proposal to use AI as a quantitative proxy for human effort. If we accept that token consumption correlates with the complexity and effort required to solve a task, we can build "eval suites" to conduct empirical, scientific experiments on software practices.
Designing the Evaluation Suite
Winters suggests that organizations should develop a robust suite of software tasks—ranging from bug fixes and refactoring to feature development—across various languages and platforms. Each task would have hidden quality criteria.
By running these tasks through AI agents under different conditions, companies can move from subjective debate to empirical data:
- Testing Efficacy: Does high unit-test coverage actually reduce total "token effort" over the lifetime of a project? By comparing an agent that follows strict testing practices against one that does not, we can quantify the ROI of testing.
- Tooling Value: Does a semantic indexer for a codebase actually speed up development? By measuring the token consumption of an agent with access to such a tool versus one without, organizations can make data-driven decisions on where to invest their tool-building budget.
This approach treats engineering methodology as a scientific variable, allowing teams to justify investments in "clean code," "developer experience," and "fast feedback signals" with cold, hard data.
Implications for Modern Organizations
The implications of Winters’ philosophy are far-reaching. For engineering leadership, the path forward is clear: stop treating software engineering as a manufacturing process that can be optimized by headcount alone.
1. Prioritize Release Cadence
Winters posits that faster release cadence is almost always better than leadership realizes. Shipping is not just about getting features to users; it is a risk-mitigation strategy. The faster an organization can ship a well-tested, reliable update, the faster it can recover from production issues, minimizing potential revenue loss and customer frustration.
2. Treat Developer Experience (DevEx) as Strategic
The "noise" surrounding AI has distracted many companies from the fundamental necessity of a clean, efficient developer environment. "The same lessons are still true post-AI, just accelerated," Winters says. "We need clear processes, clean code, good tools, fast feedback signals, good tests, etc." If an organization ignores DevEx, no amount of AI-generated code will save it from the entropy of a messy, unmaintainable codebase.
3. Embrace the "Human in the Loop"
The goal of AI integration should be to empower humans, not to sideline them. As the cost of generating code drops toward zero, the cost of understanding the system and the business domain increases in relative importance. The most valuable engineer of the future will not be the one who can write the most lines of code, but the one who can best synthesize business requirements, system architecture, and AI-assisted workflows.
Conclusion: A Call to Scientific Rigor
Titus Winters’ critique serves as a necessary wake-up call for an industry that has often prioritized the appearance of productivity over actual, measurable impact. By distinguishing between development, deployment, and operations, and by leveraging AI as an experimental tool to measure human engineering effort, organizations can move toward a more sustainable and effective model.
The future of software engineering lies not in replacing the human, but in better understanding the human’s role in the system. As we navigate the AI-driven landscape, the companies that succeed will be those that treat engineering capacity as a precious, finite resource, and who have the courage to apply the same level of scientific rigor to their workflows as they do to their code.
As Winters aptly summarizes, the discourse remains messy, but the core objectives remain unchanged. The goal is to build, to ship, and to operate—all while keeping the human problem-solver at the center of the architecture.
Ammar Sabilarrohman
