Start Treating AI as Your First Reader

That legacy code still sticks with me.
All the functions were crammed into one file, hundreds of lines of logic rolling from top to bottom, nested if/else layers upon layers, variable names either a, b, or data1, data2. Comments were scarce, and some were as good as none, like "// handle logic here." Handle what logic? Even the person who wrote it probably forgot.

I first tried using Copilot to help me write unit tests. The generated tests looked quite presentable, with neat indentation and proper assertions, but when I ran them, they were completely off: it actually put login and logout in the same test, and used the wrong input parameters. Some tests even failed on unrelated functions, as if they were forcibly pieced together.

Looking at these "confident" test cases, I once doubted: is AI not smart enough? Does it only write boilerplate code, while truly complex logic still needs humans?

But a few weeks later, after I refactored that code, the situation changed dramatically.

Large functions were split into smaller ones, files were organized more sensibly, and key logic got comments. When I tried again, Copilot's tests suddenly became clear and orderly, and it even automatically added a few edge cases I hadn't thought of at first. For example, it would write checks for "empty input" or "exception paths," which are often easy to miss when writing unit tests by hand.

At that moment, I truly realized: AI is not stupid; it just cannot read.

The Invisible Colleague Who Cannot Ask Questions

In traditional software development, when we write documents and code, we think about future colleagues:
"Make it understandable for newcomers," "Make it easy for others to get up to speed."

But now, a new role has quietly appeared in projects: the AI agent.

It might be Copilot writing unit tests, ChatGPT doing code reviews, or even an automated assistant summarizing meeting notes.
It already appears in different corners of the project, but most of the time, it is not counted as a "reader."

The problem is: if we do not treat AI as a reader, it can only understand things literally—and the results naturally go astray.

When human colleagues face bad code, they can stop, frown, and come over to ask, "Is there a missing exception handler here?"
AI will not. It does not doubt, does not ask, does not pause. It is like a quiet intern sitting in the corner, just nodding and rigidly producing output based on the context you give it.

Many people think AI is a "smarter tool," but my experience is: it is more like an invisible colleague who cannot ask questions.
The only difference is that this colleague has no situational reasoning ability and depends entirely on every word you write.

The Problem Is Not AI, but Garbage In

Many people complain about AI: "The code it writes is completely unusable," "The generated requirement analysis is nonsense."
But if you look back at the input carefully, you will find the problem is often not it, but ourselves.

AI follows the simplest yet cruelest rule: garbage in, garbage out.

If requirements are vague, it can only generate vague solutions;
If code is a tangled mess, it can only guess dependencies randomly;
If documentation lacks context, it can only piece together plausible-sounding nonsense.

Human readers will fill in gaps with experience and intuition. A product manager writes three paragraphs of stories, and developers can still sketch out interface logic through mental inference; if a try-catch is missing in the code, an experienced colleague can add it by feel.
But AI will not. You give it what you give it, and it spits out exactly that, with zero tolerance.

I have tried it myself: when I threw a vague question at ChatGPT, it would confidently spout nonsense, even fabricating seemingly authoritative explanations. But when I wrote the context clearly and marked the boundary conditions, it immediately produced astonishingly accurate answers.

So, the first step in treating AI as your first reader is to acknowledge its fragility: if the input is not clean, the output will definitely go astray.

Communicating with AI: Four Core Principles

After years of stumbling with AI, I have gradually figured out a few of the most useful practices.

1. Code must be parseable.
That refactoring made me fully understand: when large functions are split, boundaries are clear, and variable names are meaningful, AI can truly understand the context.
It even automatically generated some boundary tests I had not written, which made me realize: parseability is becoming a new dimension of code quality. Not just readable and testable, but also "understandable by machines."

2. Documentation should be as structured as possible.
Human readers can tolerate lengthy narratives, but AI can only follow the script literally.
I tried writing requirements as three paragraphs of description, and AI's summary went completely off track. Later I switched to a table, clearly listing inputs, outputs, and boundaries, and the interface definitions it generated matched expectations perfectly.
AI struggles to understand stories, but excels at parsing contracts: tables, fields, examples.

3. Write the "why" in comments.
AI can see "what was done" from the code, but it cannot read "why it was done this way."
For example: // Use BFS instead of DFS because we need to guarantee the shortest path.
This one comment is equivalent to injecting business context and design intent into it, keeping it on track during refactoring instead of arbitrarily replacing algorithms.

4. Meeting notes must state conclusions explicitly.
Humans can infer action items from context, but AI needs you to mark them explicitly.
I once encountered a case where AI took a colleague's joking remark, "Why don't we just cut this feature," as a conclusion and wrote it into the notes. After that, I specifically added labels like Action Item: and Decision:, and it stopped going astray.

These methods were originally "good habits for writing for humans," but when AI becomes the first reader, their value is multiplied many times over.

Your New Role: From Producer to Reviewer

After working with AI more, I clearly feel my role changing.
In the past, I was the main producer, writing code, documents, and comments; now, many drafts can be generated by AI first, and I spend more time as a reviewer.

At first, this shift secretly pleased me: finally, less mechanical work.
But before long, I found that behind this sense of ease lurked risks.
AI's output often looks well-formatted and logically consistent, seemingly reliable, but upon closer inspection, there may be holes, or it may even be based on completely wrong assumptions.

At that moment I realized: if I just glance over it lightly and lose my own judgment, I will be led astray by it.

AI can be a colleague, can be a first reader, but it can never make decisions for you.
Business trade-offs, architectural boundaries, when to refactor—these decisions still need humans.
AI's sense of boundaries is built on human professional insight.

Future Engineers Must Learn to Speak Human to AI

For decades, we have been learning "cross-functional communication" in engineering practice:
communicating with product, with design, with marketing.

In the future, one more item must be added to that list: communicating with AI agents.

It may not become your boss, nor your subordinate.
But it is already your silent colleague.
It will read your code, your comments, your documents, yet never ask questions or seek clarification.

Perhaps one day, AI will write more code for AI than humans do. At that point, what we need to do is not write faster than it, but define the rules and contracts. Today, when we practice "speaking human to AI," we are actually practicing how to leave clear constraints for the future world.

So, when you write a line of comment, please think:
This is not only for some future newcomer to read, but also for countless AI agents silently running in the background.

So, starting from the next line of code, how will you treat this silent yet demanding first reader?