Volume 24, Issue 2

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

 

Volume 23, Issue 5

Memory Safety

Memory Safety for Skeptics

  Andrew Lilley Brinker

If you're tired of hearing about memory safety, this article is for you.

The state of possibility with memory safety today is similar to the state of automobile safety just prior to the widespread adoption of mandatory seat-belt laws. As car manufacturers began to integrate seat belts as a standard feature across their model lines and states began to require that drivers wear seat belts while driving, the rate of traffic fatalities and severity of traffic-related injuries dropped drastically. Seat belts did not solve automobile safety, but they credibly improved it, and at remarkably low cost.

Memory, Security

Safe Coding

  Christoph Kern

Rigorous modular reasoning about software safety

Safe coding embodies a modular, compositional approach to building and reasoning about the safety of large, complex systems. Difficult and subtle reasoning about the safety of abstractions is localized to their implementations; the safety of risky operations within an abstraction must rely solely on assumptions supported by the abstraction's APIs and type signatures. Conversely, the composition of safe abstractions with safe code is automatically verified by the implementation language's type checker. While not a formal method itself, safe coding is grounded in principles and techniques from rigorous, formal software verification. It pragmatically adapts concepts such as function contracts and modular proofs for practical large-scale use by lifting safety preconditions into type invariants of custom data types within the chosen implementation language.

Memory, Security

Practical Security in Production

  Louis Dionne, Alex Rebert, Max Shavrick, Konstantin Varlamov

Hardening the C++ Standard Library at massive scale

The challenge of improving the memory safety of the vast landscape of existing C++ code demands pragmatic solutions. Standard library hardening represents a powerful and practical approach, directly addressing common sources of spatial safety vulnerabilities within the foundational components used by nearly all C++ developers. Our collective experience at Apple and Google demonstrates that significant safety gains are achievable with surprisingly minimal performance overhead in production environments. This is made possible by a combination of careful library design, modern compiler technology, and profile-guided optimization.

Memory, Security

A Practical Guide to Transitioning to Memory-Safe Languages

  Jeff Vander Stoep, Alex Rebert, Lars Bergstrom

Turning off the spigot of vulnerabilities: a new strategy for memory safety

Traditional approaches to memory safety have often amounted to best-effort defect discovery after the fact, and sometimes more advanced strategies focused on threat modeling: identifying critical code, applying interventions, and repeating the cycle as the codebase evolves. While this approach is a valuable part of a defense-in-depth strategy, it is fundamentally flawed as a primary strategy. It traps teams in a reactive and never-ending cycle of treating symptoms with solutions empirically shown to be insufficiently complete without ever addressing the underlying cause.

Memory, Security

Operations and Life
SRE Is Anti-Transactional

  Thomas A. Limoncelli, Christian Pearce

An API for interfacing with automaters

Systems built by SREs are not fully autonomous on day one. It's iteration over time that leads to fully autonomous, functional, reliable service. This iterative process requires SREs to evaluate how much time and money should be spent to achieve the objective. It is the heart of engineering to find the fastest, cheapest, and safest way to create and maintain a system.

Business and Management, Operations and Life

Kode Vicious
Driven to Distraction

From floats to characters and back again

Sometimes, simplifying assumptions are a real problem, and sometimes, they make everything look like a nail, which then makes you think all you need is a hammer. The big challenge with modern systems is that 50 years of doing things the Unix way has left us bereft of better APIs. It's not just the drivers but also the application APIs on top of the operating system that deal only in byte streams. It's as if the operating system designers threw up their hands and said, "Not my job!" and left all the data interpretation to the application programmers and device developers. Since these two parties rarely, if ever, talk to each other, no real progress has been made in this area from that time until now.

Development, Embedded Systems, Kode Vicious

 

Volume 23, Issue 4

Understanding the Harm Teens Experience on Social Media

  Arturo Béjar

A systematic approach to mitigating negative experiences online

The current approach to online safety, focusing on objectively harmful content and deletion or downranking, is necessary but not sufficient, as it addresses only a small fraction of the harm that teens experience. In order to understand harm, it is essential to understand it from their perspective by surveying and creating safety tools and reporting that make it easy to capture what happens and provide immediate help. Many of the recommendations in this article come from what you learn when you analyze behavioral correlates: that you need approaches that rely on conduct in context, better personalization, and providing feedback to actors.

Privacy and Rights

Unsolved Problems in MLOps

  Niall Murphy, Todd Underwood

Either find a better paradigm or fix the ones we're using now.

The excitement with AI is carrying us along in a big wave, but the practitioners whose job it is to make this all work are scrambling behind the scenes, often more in dread than excitement. In some cases they are using outdated techniques, In others, approaches that only work for now. However, we should be casting about for either a better paradigm or a better patching-up of the existing paradigms.

AI

Guardians of the Agents

  Erik Meijer

Formal verification of AI workflows

To mitigate against models going off the rails during inference, people often use so-called guardrails to dynamically monitor, filter, and control model responses for problematic content. Guardrails, however, come with their own set of problems such as false positives caused by pattern matching against a fixed set of forbidden words. This mathematical proof-based approach addresses these limitations by providing deterministic and verifiable assurances of safety without the need to trust the AI nor any of the artifacts it produces.

AI

Moving Faster by Not Breaking Things

  Justin Sheehy, Jonathan Reed

Initial investments allow for a fearless approach to pushing changes.

An engineering team that can move without fear, knowing that they have made themselves safe to do so, can ship more often and more quickly and make more dramatic changes without hesitation. This feels great to individual engineers and enables those engineers to be more effective for the business they work in. A bit of investment in safety pays huge dividends in speed as well as by reducing the frequency and severity of change-triggered incidents.

Development

Operations and Life
No One Has Time to Work on Your Project

  Strata Chalup (Standing in for Thomas A. Limoncelli)

How to work effectively with overwhelmed people to get things done

What if you could apply a few basic principles that would help make working on your project seem more attractive and worthwhile to people? Success in these matters boils down to a few basic principles and assumptions that seem obvious and unremarkable. What makes them effective is when you manage to combine all of them and apply them consistently.

Business and Management, Operations and Life

Kode Vicious
The Process

From start to finish

While the Scientific Method gives us a way to evaluate a hypothesis, a Scientific Process allows us to organize our minds to form these hypotheses, lay out a piece of code, organize a project, or debug a program. It's how we get to the point of focusing enough to solve the incredibly challenging problems we've set for ourselves.

Development, Kode Vicious

 

Older Issues