The Most Important Capability in the AI Era: Engineering Industry Experience

From chatbot to Vibe Coding, from conversation to engineering. This is a real account of mistakes.

Start with a formula

After countless mistakes over the past year, I reached a judgment:

Ability to get results in the AI era = industry capability × AI capability × engineering capability

All three are multiplied. If any is zero, the result is zero.

Industry capability: deep understanding and delivery in a domain—where users hurt, how the market works, what is valuable and what can sell.

AI capability: basic understanding of AI as a new production factor—the difference between models and Agents, and which AI suits which scenario.

Engineering capability: translating industry understanding into structures AI can execute—what can be decomposed, how to produce reliably, when to intervene and when to let go.

Industry capability can be developed over time; AI capability can be learned. Engineering capability must be built through actual work.

An honest note: this article is not for everyone. If you only want AI to polish copy or make an image, this is enough. If you have tried to make tools with AI and something always felt wrong, these four detours may be relevant.

Four detours at a glance

Stage one: prompts—I thought conversation was development

Early 2025, after DeepSeek

Like most people I began in a chatbot: enter a question, wait for AI, enter another, wait again.

Concept: A chatbot is a chat interface such as ChatGPT or Claude. A prompt is your instruction; a system prompt is the underlying “constitution,” for example “you are a professional marketing consultant.”

I learned that structured instructions worked much better than casual questions: clarify role, task, background and format. Then I began nesting windows and manually carrying information. I added a system prompt and thought I had “developed an Agent.”

Looking back, it was a chat box in a vest: no hands to call tools, no planning to break down work, and no memory between conversations.

But I did learn to translate vague ideas into structured language AI could process—the foundation for what followed.

The problem was that I became the workflow's courier, repeatedly restating context and checking whether AI misunderstood. I thought I managed AI; in practice AI managed me. I was excited by a “new workflow” but also invisibly exhausted, constantly watching and unable to let go.

Stage two: the low-code illusion—thinking drag and drop bypassed technology

Two months with Coze and Dify

After learning that an Agent needs Model + Memory + Tools, I tried low-code platforms. Drag-and-drop AI applications sounded wonderful.

Concept: Coze and Dify are low-code AI platforms that package underlying details so nontechnical people can build applications like blocks.

I felt the AI world opening up. But the output was underwhelming.

Deployment was a nightmare. Docker, environment configuration and API access could each block me for a day. The domestic ecosystem was largely closed; after spending time connecting tools, I found few practically useful.

Output was low. After days I had an RSS fetch-and-aggregate script. It worked but had no business significance. I also had to learn each platform's abstractions, finding my way through a fog.

The worst was the determinism trap. Low-code platforms define paths in advance, while business has branches, rollbacks and exceptions. The harder I tried to cover uncertain business with deterministic tools, the more painful it became.

I gave up. The platforms trapped me in their logic instead of helping with mine. It was discouraging to invest time without producing what I wanted; seeing others' success stories made me wonder whether I was simply not smart enough.

Stage three: the map—I understood it but could not drive

The LangChain/LangGraph period

After giving up drag and drop, I turned to open-source frameworks. With a little Python, I went to the source.

Concept: LangChain and LangGraph are open-source AI application frameworks written in Python. LangChain resembles a pipeline chaining tasks; LangGraph resembles a state machine with a shared whiteboard, conditional transitions and retries.

I finally understood the underlying Agent architecture:

But a wide gap separates understanding concepts from building a system. Work was busy and I had only an hour or two after work. Pure-code development of a complex system was inefficient; more time went to syntax and debugging than business logic.

This stage left me a map: what an Agent system looks like, how workflows differ from Agents and what a state machine is. It helped later when better tools let me build, because at least I knew what I was building. At the time, though, it felt frustrating to understand the manual without knowing how to use the machine.

Stage four: Vibe Coding—from making something to imagining a company

This stage had three settings—Cursor → Trae → Claude Code—but all were Vibe Coding: using natural language in a code workshop to direct AI to write and modify code and run tests.

Cursor: making something usable for the first time

Cursor gave me my first sense of control.

Concept: Cursor is an AI-native code editor. You can see which file AI opens, which lines it writes and where it stops to ask your opinion. This is Vibe Coding: when the vibe is right, code appears.

Control meant AI wrote code, but I made decisions. If it wrote frontend styles, I judged the appearance; if it designed an API, I needed to understand it.

I built a rough data-analysis product: upload data and AI produces visual conclusions. Its biggest value was not the features but seeing the full shape of a product: product documentation to decide what to build, frontend for the interface and backend for data logic, each needing different capabilities.

I knew AI had carried me through once, but I had not learned to fly myself. I could understand the general code but not why one part needed asynchronous execution or another caching.

Trae: trying to run a company in a folder

Cursor showed the possibility but had limitations, so I moved to ByteDance's Trae IDE and attempted more.

Concept: Trae resembles Cursor but has stronger Agent-calling capabilities. MCP, the Model Context Protocol, connects AI to external systems such as Feishu documents.

Goal: rebuild daily workflows with Vibe Coding. I wanted to move writing, HTML presentations and data-analysis reports from separate tools into Trae and have Agents do them.

I learned intensely along the way:

• Read developer consoles, API keys, permissions and API documentation across vendors and products.
• Built an MCP connection to Feishu for scheduling, learning OAuth, token management and request signing.
• Turned my capabilities into Skills: content writing, data cleaning, layout, articles and illustrations.
• Picked up code languages: YAML for configuration, JSON for data, HTML/CSS for frontend and Python for logic.

It was extremely chaotic; trying to connect everything amplified the chaos. I wanted a data Agent to analyze raw data → produce charts → a content Agent to polish language → a Skill to output a report. In practice it was a disaster.

• Context contamination: the next Agent did not properly use chart data from the previous one.
• Quality declined: every Agent “improved” the work until it was neither accurate analysis nor clear language, and data provenance was wrong.
• File boundaries were unclear: Agents did not know what to do; outputs were messy and exhausting to find.

I entered an inefficient 80% tuning, 20% production period, fixing one bug after another.

I also saw that content was the easiest AI entry point and that more people would use AI to produce it, intensifying creator competition. If I stopped at “using AI for content” without deeper capabilities, I would be buried in a meaningless war of noise and loudspeakers.

The hardest part of complex Trae projects was the tangled feeling: more files, more complex rules, a more fragile system, declining quality and increasing fatigue. Trae had limits, and so did I. When neither of us was capable enough, it felt like mutual torment.

Claude Code: entering the terminal and extracting a design philosophy

When Trae was insufficient, I tried what I considered the strongest AI engineering tool. Trae had been a divergent, chaotic period; Claude Code became a period of convergence and simplification.

Concept: Claude Code is Anthropic's terminal-level AI tool, operated through the command line rather than a GUI. It exposes the Agent runtime. I paired it with the official Sonnet 4.6 model.

My first feeling was that it really was different. With the same natural-language request, it recognized intent more accurately and performed complex work more consistently. Even paired with Kimi, I got better results than using Kimi K2.5 directly.

The output was better and less verbose, but expensive: I previously spent about 500 per month on Trae; Claude Code plus Sonnet 4.6 took that to over 2,000, with clear gains.

Why did it work so well? I studied analyses and found several design principles:

• Context is a valuable resource that must be managed carefully.
• Progressive disclosure: give an Agent only what it needs now.
• Clean context windows for subagents: each subtask gets an independent, uncontaminated thinking space.
• Security and accuracy review are a baseline.

I also felt that the best sources were largely outside domestic social media.

Anthropic and OpenAI documentation, Google Cloud white papers, GitHub projects and engineers' thinking on X offered more systematic first-hand information; many domestic materials were several layers removed and lacked the full context.

I also saw something Trae had that Claude Code did not: simpler Agent calling. Although it is essentially @-mentioning a file, it is friendlier to consumers but offers less opportunity to explore the underlying mechanism. Different audiences and product philosophies produce different design choices.

These observations made me ask: what is my purpose in using AI, and what design philosophy serves it?

My essential aim is to put integrated marketing work into one context. Integrated marketing coordinates all brand channels, tools, resources and products to deliver a unified, clear and consistent message and experience. I think an IDE's centralized environment suits it: process messy multi-source information in one system, reduce loss and inefficiency, and see inputs, outputs and feedback in one product.

I brought in my understanding of brand and integrated marketing. I see a brand as a philosophical vision beyond immediate reality, requiring a system to explain it in the world. Mathematics has shown consistency over time; perhaps its construction logic could carry my purpose and vision into AI systems.

I therefore used the “edifice of mathematics” to think about an Agent system, designing files with layers:

This addressed the Trae problem of rules repeated everywhere, growing confusion and no clear root or exit. It was not achieved at once: repeated practice, reflection, trials and discarded ideas gradually revealed what I wanted.

I also found a possible way to combine consistent management of marketing projects with AI systems. For execution, I designed a project container:

Each complex project is a game level with a goal, boundary and progress, stored in a Project folder. PROJECT.md maps background, requirements, goals, file index and notes. state.yaml records execution state: what each Agent did, with history, current and next fields. A session can crash or context fill up and require /clear, but if those files remain, the state is retained.

Maintenance is partly active. I added instructions to ops.md so Agents usually update state after an action. With larger context—generally 60–70% full—maintenance can deteriorate and needs human attention.

I also designed domain divisions (content, work, testing), action levels (system, project, plan, action), a Skill IPO protocol and file formats (YAML for state, Markdown for rules, JSONL for logs), with Skills responsible for action levels and Agents for domains.

I finally began feeling that I had moved from “chatting with AI or using it to make content” to designing systems for AI to handle complex problems.

I still often feel overwhelmed. But it comes from seeing a possibility for AI to contribute. I understand more now, though there is a long road to a genuinely usable product, especially gaps in code and software engineering. Fortunately, software engineering in the AI era may no longer require the old learning path.

I am finding a way out of chaos through stronger tools, understanding their principles and developing my own principles that remain useful amid change.

Four suggestions for nontechnical people creating with AI

First, assess your industry capability. Not everyone should start with AI engineering. If you have domain experience, deepen it with AI. Without deep understanding, even mastery of tools yields generic output without a moat, perhaps something the market will not buy. I believe AI will wash across all industries' sub-80-point work. Find where you exceed 80 points in a field and amplify it with AI.

Second, Vibe Coding + Skills are an especially valuable entry point. This is not about memorizing syntax. Enter an environment where you can see code, understand structure and direct AI in natural language. To understand AI, visit its production environment and learn the mechanism. Use an AI-native IDE such as Cursor or Trae with a real business problem; try, ask and understand. Skills in particular may become important AI-production infrastructure. Embracing short video means understanding how good video is made, not merely scrolling; AI is similar.

Third, engineering thinking matters more than coding ability. I expect top engineers to make coding Agents highly capable. You need not write code, but should understand system design: files, formats, state, rules, information flow and how to set these up for your business. That determines how deeply AI can serve a domain. More technically, a Harness around the Agent for stability matters more.

An interview with OpenAI engineer Weng Jiayi included a point I agree with: teaching researchers engineering is harder than teaching engineers research. There is no shortcut, but engineering ability accumulates while you solve real problems.

Fourth, don't be driven by FOMO. Tools and concepts change daily. I see three underlying abilities: industry capability < AI understanding < engineering implementation. They do not disappear when a tool is replaced. Assess which you need to strengthen; I consider them increasingly difficult in that order.

Finally ask: if I could do anything I wanted, what would I most want to do? AI opens more roads, but cannot answer why you set out.

My four stages as a reference

These are the four stages I actually traveled in a year, not a standard answer. If you are learning AI and unsure where to go, use the map as a reference.

Stage	What I did	What it might feel like
Prompt	Optimized chatbot instructions, thinking a system prompt meant developing an Agent	Every chat starts over; the person carries information
Low-code illusion	Tried Coze/Dify, thinking drag and drop bypassed the technical barrier	Spend 80% learning platform logic, produce little and become trapped in it
Map	Understood LangChain/LangGraph architecture but could not build a system	You have a map but cannot drive; time goes to syntax
Vibe Coding	Built a rough product in Cursor, tried to “run a company” in Trae, then extracted principles with Claude Code	From AI carrying you, to tangled chaos, to designing how AI works—the longest and hardest stage

There is no standard path, but the shared foundations remain industry capability, AI understanding and engineering implementation. If you are on this path, good luck; if you find a better one, tell me.

2026-04-05