Volume 24, Issue 2

From Technical Debt to Cognitive and Intent Debt

  Margaret-Anne Storey

Rethinking software health in the age of AI

Generative AI is dramatically accelerating software development, allowing teams to generate and modify code faster than ever before. For decades, software engineering has focused on managing technical debt—how code structure and implementation make systems harder to change.

But in the age of AI, technical debt might no longer be the most important constraint. This article argues that the real risks are shifting toward two less visible forms of debt: cognitive debt and intent debt.

Cognitive debt is the erosion of shared understanding across a team where no one can confidently explain how a system works or predict the impact of a change. Intent debt is the absence of clear goals, constraints, and rationale that explain what the system is for and guide how it should evolve, for both humans and AI agents.

These debts have always existed, but GenAI accelerates their accumulation while hiding their effects. I propose how these forms of debt can be recognized in practice and suggest strategies teams can use to mitigate them.

AI, Development,

Eight Myths on Software Engineering and GenAI

  Jenna Butler, Brian Houck, Margaret-Anne Storey, Travis Lowdermilk, Steven Clarke, and Emerson Murphy-Hill

Examining the most common misconceptions

Generative AI is reshaping software engineering—but the narrative has gotten ahead of the evidence. Marketing claims, anecdotal wins, and misread studies have given rise to a set of persistent myths that are quietly driving poor decisions about AI adoption, tooling, and how to measure success.

This article examines eight of the most common misconceptions. We already know developers don't actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it's closer to 14 percent. That means AI code generation, even when it works well, touches a surprisingly small slice of the actual job. And yet organizations are doubling down on lines-of-code metrics to track AI's impact, which is a measure that is neither statistically valid nor meaningfully connected to outcomes such as software quality or delivery speed.

The reality is messier and more interesting than the headlines suggest. AI works better for some tasks, some developers, and some contexts than others. Productivity gains don't flow automatically from handing engineers a license—they require rethinking workflows at the organizational level. Adoption stalls when developers don't trust the tools, lack time to learn them, or worry about de-skilling. And the "startups move fast with AI" narrative ignores the compliance, legacy systems, and reliability constraints that define enterprise software.

This article isn't skeptical, but rather provides practitioners, team leads, and engineering leaders a clearer, research-backed picture so the decisions organizations make about AI are grounded in evidence, not just enthusiasm.

AI, Business and Management, Development,

Climbing the Generative AI Mountain

  Jenna Butler, Mara Ulloa, Margaret-Anne Storey, and Christian Bird

A "hitchhiker's guide" for product managers

Most product managers (PMs) working in software today feel it—that dizzying sense of standing at the base of a mountain, staring up at a new way of working and wondering where to even begin. Generative AI has fast arrived in the software engineering workforce, with little guidance and high expectations. PMs are expected to be more productive almost overnight, without a map for how to get there.

Microsoft has been at the center of this transformation. Drawing on interviews, surveys, and telemetry from 885 PMs on software teams at Microsoft, we studied how practitioners at every stage of the climb are actually navigating this shift—from those still finding their footing at base camp to those who have reached the summit and fundamentally redesigned how they work. From this data, we developed a set of personas that capture the real texture of the ascent: where people get stuck, what moves them forward, and what traps are easy to fall into.

This article is not a feature overview or a list of prompting tips. It is a practitioner's guide built from real behavior, real struggles, and real wins—with verbatim accounts from PMs doing this work every day. Whether you are still packing your bags or looking to push past the next ridge, this article offers concrete, experience-backed guidance for redesigning your workflows with AI, one step at a time.

AI, Business and Management, Development,

The AI-Native Developer

  Rudrajit Choudhuri, Eirini Kalliamvakou, Brian Houck, Thomas Zimmerman

Redefining work, identity, and the future of craft

AI is changing software development in a way that forces a more uncomfortable question: Which parts of the job are still worth doing? Developers are making deliberate choices about what to keep, what to delegate, and what they no longer recognize as their work. Many report that their work feels less meaningful than before, suggesting a deeper shift in the role itself. Drawing on large-scale mixed-methods surveys of developers and in-depth interviews with AI-fluent practitioners, we investigate what it actually means to be a software developer today, how the role evolves as AI fluency deepens, and where this all might lead. We explore what futures become possible as AI augments software creation and what choices might help us design for the futures worth wanting.

AI, Business and Management, Development,

Knowledge Graphs over Two Decades

  Xin Luna Dong

From web-scale extraction to LLM-augmented intelligence

This paper traces the evolution of knowledge graphs across three generations: entity-based knowledge graphs (KGs), text-rich KGs, and the emerging convergence of KGs and large language models. The boundary between symbolic and neural knowledge continues to blur, leading to a new era of flexible, context-aware knowledge systems.

Visualization

Operations and Life
The Important Decisions Document

  Thomas A. Limoncelli

Every project (and family) needs one.

Long-running projects are a journey. An IDD (important decisions doc) captures knowledge and decisions gathered along the way. It records the what and why of decisions, as well as the rationale for rejecting alternatives. It helps new team members get up to speed, prevents wasting time on relitigating old decisions, improves morale, and increases accountability.

Business and Management, Operations and Life

Kode Vicious
KV the Apostate

Faith-based computing versus the unnatural science

Whether we ask an LLM or a recent graduate to type the code is less important than knowing what the code does, how it was built, and when to look under the hood.

AI, Kode Vicious,

 

Volume 24, Issue 1

Bridging the Moat:
Security for the Layperson

  Phil Vachon

Usability is core to effective security controls.

When you're designing security controls for the masses, you must consider a much wider variety of end users, who have differing levels of knowledge, comprehension of risk, or even mental models of what the value of credentials might be.

Bridging the Moat, Security

The Second-System Pit of Failure

  Terry Coatta and Craig Smith

Lessons learned from building a second-generation system

Our experience with building a new LMS to replace an existing system provides at least one point of evidence that it is possible to avoid the SSE trap. The three principles that guided our design and planning for the new system (treat it like an MVP, look for abstractions that encompass both old and new features, and be sparing in how fully those abstractions are implemented) definitely contributed to the success of the project and are potentially ideas that could be applied in many situations where a system needs to be replaced.

Software Design, System Design and Evolution

Building Malleable Systems, not Future-Proof Ones:
Design for Change

  Paul Callaway

The code you write can't possibly predict every change that comes along.

Design for malleability isn't a bulleted list of rules to follow; it's a set of choices you make every day as you design and modify systems. Code is like a house, and people have to live in it, often for much longer than you expect.

Development

Kode Vicious
Escape Routes

Design your APIs carefully

API design is a nontrivial exercise. It requires thought and consideration for other people and their future requirements (and programmers, I believe, still qualify as people). Sometimes, it just amounts to consideration for your future self who will be faced with reusing that API later.

API Design, Kode Vicious, Tools

Open Source and the Iceberg Theory

  Alyssa Wright and Stephen Augustus

Why "dependency management" isn't enough anymore

The traditional model of passive consumption is fundamentally unsustainable. In an era of AI-generated code and increasing supply-chain attacks, stewardship is now a fiduciary and societal imperative. Embedding a stewardship mindset into core strategy is not a matter of goodwill; it is an investment in the resilience and long-term viability of the systems your company relies on.

Open Source

On the Evolution of Program State

  Paul Vixie

Larger-scoped forces shaping software engineering safety

The main purpose of this article is to provide a way to talk about, and thus a way to think about, the larger-scoped forces shaping both the history and opportunities of software engineering safety. Today's AI coding assistants augur an era when more software will be created than ever before and by more people and agents than ever before. It's undecided as yet whether this era will be safer or more dangerous than the last.

Security

 

Volume 23, Issue 6

Running the "Reflections on Trusting Trust" Compiler

  Russ Cox

Revisiting Ken Thompson's sourceless backdoor

In October 1983, Dennis Ritchie and Ken Thompson received the Turing Award for their work on Unix. Thompson's lecture, reprinted in Communications of the ACM under the title "Reflections on Trusting Trust," explained in three steps how to modify a C compiler binary to insert a backdoor when compiling a target program, leaving no trace in any source code. This article revisits that backdoored compiler, presenting the original code Thompson wrote more than 50 years ago. First, a brief review of Thompson's three steps.

Code, Security

Minimalist Design for Space Camera Flight Software

  Michael Caplinger

Embedded spaceflight software: Small is beautiful.

This article discusses more than 35 years of experience with writing small software systems that control spaceflight imaging instruments. While many systems drift toward more complexity, this article advocates for a minimalist approach, with examples of minimalist systems that have performed well in practice. Most of the methods are applicable to many other embedded software programs.

Embedded Systems

Data Analysis: Why Is It So Complicated?

  Alice Jackson

Why your models are incomplete and rife with inaccuracies, assumptions, caveats, and limitations

This article aims to give you a sense of the depth and breadth of why it's so complicated to conduct and interpret data analysis. It begins with an overview of the purpose of data analysis, reviews different components of data and modeling and how each component introduces complexity to the process of analysis, discusses interpretation of analytic results, and concludes with a few recommendations for productively managing all of these challenges.

Data

Modeling Version Requirements in Open Source Packaging

  Josie Anugerah, Caleb Brown, Elitsa Bankova, Eve Martin-Jones, Dr. Nicky Ringland

A universal model for understanding and describing requirements

We propose a universal model of requirement actions. While the concept of requirements is the same across packaging ecosystems, the syntax used to represent them is not, creating unnecessary confusion. The proposed model does not provide a new syntax for adoption but offers a precise way for ecosystems to define the meaning of their requirement operators. All ecosystem-specific requirements can be translated into the model as well as being defined within it, and dependency-resolution tools need not be specific to a requirement syntax.

Open Source

Drill Bits
What Every Experimenter Must Know About Randomization

  Terence Kelly

This column is for experimenters and the programmers and statisticians who support them. Randomized controlled experiments offer gold-standard insight into cause and effect—the knowledge that informs our most important decisions. Unfortunately, randomization in such experiments is often botched. Randomization errors silently invalidate the interpretation of experimental results, turning a fruitful quest for knowledge into a waste of time and money—or, worse, a wellspring of misinformation. Fortunately, these fatal errors are easy to spot and fix. So whether you're a webmaster using A/B testing to increase engagement, a medical researcher evaluating vaccines, a factory manager exploring productivity improvements, or a scientist seeking the laws that govern nature or human affairs, read on.

Code, Development, Drill Bits

Kode Vicious
A Trunk Full of Swords

The shiniest tool might cut the deepest.

No systems programmer in their right mind reaches first for a kernel modification. The tools available to study problems are far richer above the user/kernel boundary than below. Also, new ideas are easier to try out in a user-space library or program, where the price of failure is that you crash a single program, instead of waiting 10 minutes for a whole server to reboot.

Kode Vicious, Tools

 

 

Older Issues