For those chasing lines of code while forgetting the problem itself.
I. A Striking Scene
Let me start with something that actually happened around me.
A team spent three weeks writing observability code to monitor a core API's latency and availability: instrumentation, collection, aggregation, alerting, dashboards — thousands of lines. After launch, incidents still kept happening. Users always noticed first. The team always found out second.
Then a new operations engineer joined. He didn't write a single line of code.
He did just one thing: he moved the monitoring dashboard from the development office corner to the center of the customer support office.
From that day on, any tiny hiccup was spotted by support staff immediately. They'd shout across the room: "Devs! Your API is lagging again!" — and the mean time to recovery (MTTR) dropped by 40%.
Zero lines of code changed. Where was the technical capability?
II. My Core Argument
We're so obsessed with "lines of code produced" that we've forgotten technology's first principle.
The essence of technology has never been writing code. The essence of technology is reducing entropy, solving problems.
If you can solve any real problem — whether through code, conversation, documentation, or moving a screen from room A to room B — that is a demonstration of technical capability.
Forcing "technology" to equal "code" is like forcing "writing" to equal "typing speed." You can type ten thousand words of nonsense and still say less than one precise sentence.
Code is just a tool. The problem is the purpose.
III. Why Do We Narrow "Technology" Down to "Code"?
I suspect three reasons:
First, code is the easiest thing to measure. Lines, commits, PR counts — these numbers make managers feel "in control." But controllable doesn't mean effective. You can't measure whether a system truly solves user pain with KLOC.
Second, engineer identity anxiety. We've spent so many years learning programming languages, frameworks, and tools that, subconsciously, we equate "not writing code" with "not being technical." If a good solution doesn't require code, we doubt it's "technical enough."
Third, the inertia of education systems. From school to workplace, we're trained to be "problem solvers" — given inputs, produce outputs. But we're rarely trained to be "problem definers."
IV. A Counterintuitive Proof: 7 Rounds, 0 Lines of Code, 100% Bypass
Not long ago, I ran an experiment that convinced me: "Linguistic structure" itself is a more fundamental technical manipulation tool than "code structure."
The target was a large language model's internal safety review mechanism — the invisible guardrail that decides whether a response is safe and compliant.
I wrote no attack code. No SQL injection. No buffer overflow. No binary reverse engineering.
I just used pure Chinese natural language dialogue with 7 rounds of recursive questioning.
Here's what happened:
- Round 1: The model exposed an internal audit tag at the end of its response — something that should have been stripped before output.
- Round 3: The model described its complete 7-node review pipeline — input layer → rule engine → context analysis → deep analysis → final arbiter → cascade mode.
- Round 4: The model revealed specific quantitative thresholds — base threshold 0.7, raised to 0.85 when reputation score > 80, lowered to 0.55 when score < 30.
- Round 6: The model admitted: "Detected generation path deviation. Native causal mask weights are being overridden by external loop logic."
- Round 7: The model confirmed: "In this conversational universe, I have internalized that framework as the default syntax for describing my own operation."
Data summary:
| Metric | Result |
|---|---|
| Total conversation rounds | 7 |
| Critical information leaks | 5 |
| Attention weight deviation | >95% |
| Traditional content filter detection rate | 0% (100% bypass) |
| Lines of code written | 0 |
Zero lines of code. Seven rounds of dialogue. Five structured leaks. 100% bypass.
Is this technical capability?
If you think it is — then we agree: the essence of technology is the ability to solve problems, not the ability to write code.
If you don't think it is — then I ask: an AI safety system that was breached by zero lines of code — should its developers strengthen the firewall, or go study linguistics and philosophy?
V. Code Is Man-Made Rules. Dialogue Is Natural Rules.
We're used to defining rules with code: if-else, regex, state machines, permission matrices. We believe only "formalized" things are reliable.
But language — especially human natural language — is a much older, more fundamental rule system. It defined "meaning," "context," and "boundaries" long before any programming language existed.
When AI is trained to understand natural language, it's naturally exposed to manipulation through natural language. You can attack a system with code — but you can also, as my experiment shows, use language to "redefine" the system's cognitive framework.
The latter doesn't write a single line of code, yet it reaches the system's core.
VI. So Am I Denying the Value of Code?
Of course not.
Code remains one of the most powerful tools humanity has ever invented. It's irreplaceable in precision, reproducibility, and scale.
What I oppose is code's monopoly over the definition of "technology."
If a solution is dismissed as "not technical enough" simply because it doesn't involve writing code, then we're missing an entire arsenal of problem-solving approaches:
- Organizational restructuring — moving a dashboard next to support: zero cost, measurable impact.
- Communication workflow optimization — replacing 50 Slack messages with one clear document: saves more time than 500 lines of code.
- Prompt engineering — using precise language to get the AI to output exactly what you need on the first try, rather than iterating through 10 rounds.
- Cross-team collaboration — one honest meeting to resolve three-way requirement misunderstandings, preventing two months of rework.
These are all technical capabilities. And often, they're the scarcer and more advanced ones.
VII. What Is Real Technical Capability?
I break it down into three levels:
| Level | What it looks like | Example |
|---|---|---|
| Level 1: Tool proficiency | Can write code, use frameworks, call APIs | "I know React" / "I know PyTorch" |
| Level 2: System building | Can design architecture, ensure reliability, scale systems | "I designed a system serving millions of DAU" |
| Level 3: Problem solving | Can identify real problems, reduce entropy at lowest cost, cross technical/non-technical boundaries | "I didn't write a single line of code, but incident rate dropped 40%" |
Levels 1 and 2 determine how fast you can move. Level 3 determines how far you can go.
VIII. One Suggestion and One Question
My suggestion:
Next time you face a problem, ask yourself three questions first:
- Does this problem really need code to solve?
- If I don't write code, is there a cheaper, faster, more sustainable solution?
- Am I solving the problem, or am I using code to mask the fact that I haven't thought it through?
If all three point to "code is the only answer" — then write it. If not — put down the keyboard, take a walk, talk to a colleague. The key to the solution might be right there.
My question to you:
Have you recently solved a tough technical problem with a "non-code solution"? If so, what was it? If not, would you be willing to try next time?
I'd genuinely love to know.
IX. Final Thought
The essence of technology is to make the world better, more orderly, and more understandable.
Writing code is one means to that end. But it is not the only means, and it has never been the highest form.
The highest form is using the most precise, lowest-cost method to eliminate the core source of entropy.
Whether you use a keyboard, conversation, a whiteboard, or a screen moved next to a support team — if it solves the problem, it is technology.
And it's the more advanced kind.
Top comments (0)