TL;DR
- I'm a non-coding engineer (operations background) who builds tools through AI collaboration.
- This post argues that non-coding engineers — not programmers — are positioned as AI's biggest beneficiaries in the current era.
- The diagonal-axis engineer thrives via 5 layers: dimensional crossover, value asymmetry, handover ability, ownership avoidance (AI-to-AI handover spec), and diagram-as-source.
- "Trivial" tech (pandas + Excel batch files) wins in business contexts because operators can pick it up and adapt it.
- The market value of the AI era boils down to the ability to travel across industries.
1. An Ode to "Trivial" Tech, Continued from This Morning
This morning I wrote about solving the "can't send business data to LLMs" problem with one line of pandas + Faker. (See the earlier post: How I Built a Masking Tool Without Showing AI Any Real Data.)
In the programmer world, that's:
- "pandas? Yeah, sure."
- "Faker? Old hat."
- "Column-wise shuffling? Standard de-identification."
— completely trivial tech.
But in the non-engineer world:
"This eliminates 8 hours of work per month."
"I can discuss it with AI without sending real data."
"I have a scaffold for the masking tool now."
is the response. The same tech becomes either "trivial" or "revolutionary" depending on the evaluation axis.
This value asymmetry is no accident — it's a structural feature of the AI collaboration era. The thesis of this post:
Non-coding engineers, not programmers, are positioned to become the biggest beneficiaries of the AI era. This is realized by arming themselves with the 5-layer structure of the diagonal axis.
2. Vertical, Horizontal, Diagonal: Three Patterns of AI Use
First, let's organize 4 positions on 2 axes (coding ability × domain knowledge):
quadrantChart
title Position of the Diagonal-Axis Engineer
x-axis "Coding Low" --> "Coding High"
y-axis "Domain Low" --> "Domain High"
quadrant-1 "Diagonal-Axis Engineer"
quadrant-2 "Domain Owner"
quadrant-3 "Non-Coding Engineer"
quadrant-4 "Programmer"
The movement from the bottom-left "Non-Coding Engineer" to the top-right "Diagonal-Axis Engineer" is the theme of this post. Building on this matrix, let's look at three patterns of AI use:
| Axis | User | AI's Role | Effect |
|---|---|---|---|
| Vertical (same-dimension acceleration) | Programmer | Speed-up of same skill | 2x faster typing / refactoring |
| Horizontal (same-dimension expansion) | Programmer | Skill width expansion | Frontend specialist learning DB design |
| Diagonal (dimension crossover) | Non-coding engineer | Compensating missing capabilities | "Can design but can't code" → reaches implementation independently |
Vertical + Horizontal = linear expansion that doubles the slope of the graph.
Diagonal = a non-linear shift where the line itself diverges (paradigm shift).
The leverage effect is Diagonal >>> Vertical + Horizontal. 2x speedup vs 0 → 1 crossover — the latter is overwhelmingly larger.
The diagram of how to reach the diagonal-axis engineer position:
graph LR
ZERO["Non-Coding Engineer<br>Coding:× Domain:×"]
DOM["Domain Owner<br>Coding:× Domain:○"]
PROG["Programmer<br>Coding:○ Domain:×"]
DIAG["Diagonal-Axis Engineer<br>Implementation via AI<br>Domain:○"]
ZERO -->|Field Experience| DOM
ZERO -->|Vertical: Coding Study| PROG
DOM ==>|Diagonal: AI Collaboration - Short Path| DIAG
PROG -.->|Diagonal: Domain Acquisition - Slow Path| DIAG
style DIAG fill:#9f9,stroke:#393,stroke-width:3px
style DOM fill:#ff9
The thick line shows the short path (Domain Owner via AI collaboration). The dashed line shows the slow path (Programmer acquiring domain knowledge). The defining feature of the AI collaboration era: the latter requires time and motivation, while the former has its technical gap filled by AI.
3. The 5-Layer Structure of the Diagonal-Axis Engineer
"Can't code but can reach implementation via AI" alone isn't enough armor. Winning in the market requires all 5 layers:
| # | Layer | Effect |
|---|---|---|
| 1 | Dimension Crossover | Reach implementation without coding |
| 2 | Value Asymmetry | Trivial tech matters in business contexts |
| 3 | Handover Ability | Simple implementations spread across industries |
| 4 | Ownership Avoidance | AI-generated specs let maintenance also depend on AI |
| 5 | Diagram-as-Source | Common language between AI and humans |
The 5-layer dependency:
graph TD
L1["Layer 1 Dimension Crossover<br>Reach implementation without coding"]
L2["Layer 2 Value Asymmetry<br>Trivial tech matters in business"]
L3["Layer 3 Handover Ability<br>Spreads across industries"]
L4["Layer 4 Ownership Avoidance<br>AI specs let maintenance depend on AI"]
L5["Layer 5 Diagram-as-Source<br>Common language between AI and humans"]
L1 --> L2 --> L3 --> L4 --> L5
L5 -.-> NEW["New Paradigm<br>Diagram is truth, code is AI's derivative"]
style L1 fill:#fef
style L5 fill:#fc9
style NEW fill:#9f9,stroke:#393,stroke-width:3px
Layer 1 "implementation reach" is the starting point; the higher you stack, the stronger your market position. Past Layer 5, you exit into a new development paradigm.
Let me walk through each layer.
Layer 1: Dimension Crossover
For someone who can design but can't code, AI is the implementation means itself. Areas they previously had to delegate to others, they can now reach independently. 0 → 1 crossover happens.
Layer 2: Value Asymmetry
The opening point. Implementations the programmer world rates as "trivial" or "low-grade" land as business impact in the non-engineer world. The same tech reverses value depending on the evaluation axis.
In other words, the more "low-grade" tech is judged to be, the wider its market lands in business contexts. Programmers tend to lock themselves into a world that competes on technical sophistication, ending up clinging to a narrow market.
Layer 3: Handover Ability
| Implementation Complexity | Required Personnel | Handover Ability | Industry Reach |
|---|---|---|---|
| High / Complex | High-skill programmer | Low (locked-in) | Trapped in 1 industry |
| Medium | General engineer | Medium | Mid-scale deployment |
| Simple (batch + Excel) | Operator | High | Industry-wide |
The simpler the implementation, the more it reaches the field and becomes the gateway to the industry. The artifacts a vibe coder produces structurally land at "simple implementations" (since the coder doesn't read the code, they can't make it complex). Asking AI to "build it as a double-clickable batch file" → it converges naturally to moderate complexity → field handover ability emerges as a side effect.
Layer 4: Ownership Avoidance
Even with simple implementations and field handover ability, maintenance is a separate problem. AI collaboration structurally avoids the ownership trap that programmers have struggled with for a hundred years.
What is an AI-generated spec: A handover document for another account's AI (a different Claude / Gemini etc.) to read and become capable of modifying / maintaining the code. Even if the original vibe coder leaves, a new maintainer can bring in a different AI and ask "please maintain this code" — and the system lives on. This isn't the traditional "human → human" handover; it's an "AI → AI" handover by design.
This builds a 2-layer maintenance structure:
- Layer 1: Simple implementation → operator can touch it directly
- Layer 4: AI-generated spec → new maintainer / AI can take over
The revolutionary point of AI specs is being interactive, not static. The new maintainer's AI can be asked "how does this system work?". The system can be understood via AI without reading the code.
Layer 5: Diagram-as-Source
Layer 4 ensures "AI → AI" subject-axis handover, but for in-progress collaboration where humans and AI must share understanding, one more layer is needed.
So we make diagrammatic specs (Mermaid flowcharts / logic trees) the source of truth:
Natural language spec = soft (volatile, interpretation drifts)
Diagrammatic spec = hard (the structure itself is the source, humans and AI look at the same diagram)
Humans and AI can converse in the same diagram language. Instructions like "change the Yes branch of this gate" land instantly. Visual patterns make dead-code paths and unused nodes obvious.
4. Prerequisites — Without a Verification Eye, the Diagonal Axis Becomes an AI-Dependent Caricature
The 5-layer structure says "you can win without coding," but this is easy to misread.
| Element | Necessity |
|---|---|
| Ability to write code | Not required |
| Ability to structure the system as a whole | Required |
| Verification eye for output validity | Required |
| Ability to cross-reference industry terminology (survey-driven) | Required |
If these are missing, you can't write good prompts for AI, can't verify results, and end up mass-producing buggy deliverables.
In other words, "Domain Owner using AI ≠ Diagonal-Axis Engineer." Between them sits a filter of these 3 elements; those who can't cross it remain at "AI-dependent caricature" level.
Vibe coder = a non-programmer with a verification eye — that's the proper redefinition.
5. Devil's Advocate
The 5-layer structure isn't bulletproof:
- AI-generated spec reliability: AI may write things that are factually wrong, with no verification possible
- Commercial LLM dependency: service shutdown or model change can collapse reproducibility
- Diagram literacy prerequisite: diagrammatic specs require "the ability to read them"
- Short-term vs long-term: as programmers extend into the diagonal axis, the advantage erodes
Each requires individual countermeasures (human review / local LLM redundancy / coexisting static documents), but none of these overturn the post's core thesis.
Responses to Anticipated Pushback
"Can't anyone become a diagonal-axis engineer just by using AI as a domain owner?"
→ No. Without the 3 elements shown in Section 4 (structuring ability / verification eye / survey ability), you become a "vibe coder without a verification eye" who blindly trusts AI output and mass-produces buggy deliverables. Domain Owner + AI ≠ Diagonal-Axis Engineer. There's a prerequisite filter between them.
"Won't programmers eventually become diagonal-axis engineers by acquiring domain knowledge?"
→ Yes, but it takes time. For programmers to acquire specific business domain knowledge, on-the-job training + experience accumulation + dialogue with the business side are required, and this is dramatically slower than AI collaboration's immediate effect (the technical gap filled by AI). The dashed line in the path diagram represents this time gap. The defining feature of the AI collaboration era is this asymmetry: domain knowledge acquisition still takes time, while the technical gap is instantly filled by AI. That's why domain-owner-originated diagonal-axis engineers hold first-mover advantage.
6. My Case — Operations × Cross-Domain Double Cross
In my case, I sit at the top-right of the matrix by acquiring business knowledge through on-the-job experience first, then having AI write the code. Engineers with system construction or operations experience can usually map out routine business flows themselves, and reaching the diagonal-axis position only requires consulting AI for the parts that can be made more efficient.
I (the author) come from an operations background, and I move with the stance of bringing operational discipline (flow establishment / efficiency / monitoring / handover) into business improvements in other domains.
That is:
| Layer | Structure |
|---|---|
| 1 (Diagonal Axis) | Can't code, but reach implementation via AI |
| 2 (Domain Cross) | Operations expertise × cross-domain business flow |
Diagonal Axis × Domain Cross = double leverage. AI collaboration compensates the diagonal-axis weakness (can't code), and operations expertise brings a fresh perspective into other domains.
This is the core market value of the cross-domain engineer. The reason I feel "I can travel across industries" lies in this double cross.
7. Conclusion — A New Development Paradigm
Programmer era: Code is truth, documentation is auxiliary
Vibe coder era: Diagram is truth, code is AI's derivative, natural language is auxiliary
And the market value of the AI collaboration era boils down to the ability to travel across industries. Tech that draws "is that all?" responses is what becomes the gateway to industry adoption.
An ode to "trivial" tech, you might call it.
Top comments (0)