Beyond Human-Readable: Rethinking Software Engineering Conventions for the Agentic Development Era
This paper argues that software engineering conventions must evolve from human-centric readability to "semantic density optimization" for agentic AI, demonstrating through experiments that aggressive token compression can increase costs by shifting interpretive burden to the model and proposing new paradigms like program skeletons and the rehabilitation of classical anti-patterns to better serve autonomous agents.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
The Big Idea: Writing for Robots, Not Just Humans
For the last 60 years, software engineers have written code like they were writing a novel for a human reader. They use long file names, split code into tiny pieces, and add lots of "ceremonial" comments to make it easy for a tired human to understand.
But now, we have AI Agents. These are robots that read, write, and fix code on their own. They don't get tired, they don't need to "feel" the code, and they don't have a limited working memory like humans do.
The paper argues that we are still writing for humans, but the primary reader is now a robot. This mismatch is costing us money and time.
The Core Concept: "Semantic Density"
Imagine you are sending a package to a friend.
- The Old Way (Human-Optimized): You wrap the gift in 10 layers of tissue paper, put it in a huge box, and write a 5-page letter explaining why you chose that specific tissue paper. It's beautiful for a human to open, but it's heavy and expensive to ship.
- The New Way (Agent-Optimized): You strip away the tissue paper and the long letter. You just send the gift in a sturdy, compact box with a clear label.
The paper calls this "Semantic Density."
- High Density: Words that actually tell the robot what the code does (e.g.,
calculate_tax_for_uk_residents). - Zero Information: Words that just look nice or follow rules but tell the robot nothing new (e.g.,
public static voidin Java, or splitting one function across 10 tiny files just because a human can't remember them all at once).
The Golden Rule: Keep the "meat" (the meaning), throw away the "fat" (the structural fluff).
The Big Surprise: "Compression" is a Trap
You might think, "If robots are reading this, let's just make everything shorter! Use abbreviations like 'tx' instead of 'transaction' and 'err' instead of 'error'."
The researchers tested this, and it led to a Counter-Intuitive Paradox:
The "Reasoning Tax"
Imagine you are asking a smart assistant to solve a mystery.
- Scenario A (Clear): You say, "The butler stole the diamond because he needed money for his gambling debt."
- Result: The assistant solves it instantly.
- Scenario B (Compressed): You say, "B stole D for G."
- Result: The assistant has to stop and think: "Who is B? A butler? A bank? What is D? A diamond? A debt? What is G? Gold? Gambling?"
The paper found that while the "Compressed" version used fewer words (tokens), the AI had to spend 67% more energy figuring out what you meant. It had to "reason" through the abbreviations.
The Lesson: Don't make the code shorter by removing meaning. Make it shorter by removing the boring stuff that doesn't carry meaning.
The New Toolkit: "The Program Skeleton"
Since AI agents can't "browse" a whole project like a human scrolling through files, the paper suggests a new artifact called a Program Skeleton (think of it as a CODEMAP.md file).
The Analogy:
Imagine you are in a massive library (the codebase).
- The Old Way: You have to walk to every single shelf, pull out a book, and read the first page to see if it's relevant.
- The Skeleton Way: You are handed a Library Map that says: "The history books are in Aisle 3, the sci-fi is in Aisle 5. Here is a one-sentence summary of every book."
The Skeleton contains:
- What files exist.
- How they connect (who calls whom).
- One-sentence summaries of what they do.
- It leaves out the actual code.
This lets the AI agent know exactly where to look without having to read the whole library.
What Should We Change?
The paper suggests flipping some old software rules upside down:
- Stop splitting files just because: Humans split code into tiny files because our brains can only hold 7 things at once. Robots don't have that limit. If a feature belongs together, put it in one big file. It saves the robot from making 10 different "phone calls" (tool calls) to read 10 different files.
- Rename things clearly: Instead of short, cryptic names like
calc(), use long, descriptive names likecalculate_monthly_subscription_fee_for_premium_users. To a human, this looks long. To a robot, this is a perfect, self-explanatory instruction. - Re-evaluate "Anti-Patterns": Some things we used to hate (like "God Objects" where one file does everything) might actually be good for robots because it keeps all the information in one place, reducing the need to jump around.
The Catch: The Human Reviewer
There is one problem. While the robot loves the "dense, consolidated, long-name" code, humans might find it hard to read.
If the code is optimized for the robot, the human reviewer might get confused. The paper suggests we need a "projection layer"—a tool that shows the robot the "dense" version but shows the human the "pretty, split-up" version.
Summary
- Old Software Engineering: Optimized for human eyes (small files, short names, lots of comments).
- New Agentic Engineering: Optimized for machine brains (big files, long descriptive names, minimal fluff).
- The Mistake: Trying to "compress" code by making it cryptic. This makes the AI work harder and costs more money.
- The Solution: Keep the meaning rich and clear, but strip away the structural noise. Give the AI a "Map" (Skeleton) so it doesn't get lost.
In short: Write code that is so clear and descriptive that the robot doesn't have to guess, but organized in a way that doesn't force it to walk across the room to find the next piece of the puzzle.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.