From Java to AI Agents, I’ve Always Been a Builder

I'm a Full-Stack Builder.

From Java and the web, to mobile, Linux, and embedded systems, to today's AI Agents — what I've been doing has never really changed: turning real problems into software that actually runs.

---

The technology kept changing.

I started with Java building enterprise systems, then came Linux, C, and embedded systems, then web, mobile, and Node.js — and most recently, AI Agents.

Every change was never a restart, just one more way to solve problems.

But putting these experiences together, I increasingly feel:

I've actually been doing the same thing all along — understanding a real problem, turning it into software, and then actually shipping that software.

---

Starting with Java and CRM

My career started with Java and JavaScript, building enterprise CRM projects — database design, JDBC, JSP, and JavaScript application development.

But what truly benefited me wasn't just these technologies.

Enterprise projects usually mean facing customers directly: you talk to the customer's project lead, meet the employees who actually use the system, and sometimes do on-site implementation at the customer's location.

Customers never say:

This habit later extended naturally into automation and AI.

During my Ctrip years, I was responsible for the rich-text editor of the trip.com blog. This experience came back to me recently because of a question: when chatting with AI, why can the input basically only be plain text? Font, color, size, the feeling the author wanted to convey, plus the images and videos embedded in the text — all of it disappears in plain text.

I want the model to truly "read" rich text: serialize the structure into Markdown, render style and layout into snapshots for a vision model to "see," and let images and videos flow in through multimodal input. I plan to turn this into a project — connecting my old editor experience to the problems of the AI era.

---

AI Digital Human: A Short, Dense 3D Delivery

After Ctrip, I spent a few months at Quante as a full-stack engineer.

The project: an AI digital-human customer service system for a Disney Resort. We built the front end with Next.js + React, the web-side 3D digital-human rendering and lip/expression sync with Three.js + react-three-fiber, integrated Azure ASR/TTS and FunASR dual-channel voice, and used Socket.io to wire up voice input, interruption, and three-way sync of speech, motion, and expression.

The knowledge-base admin frontend directly reused nsgm-cli, the scaffold I mentioned earlier.

As a staged exploration, the project shipped its first working release within a month, and we then worked through iOS / Android WebGL and audio compatibility issues one by one.

The stint was short, but it gave me an early feel for what the AI era would actually be like:

For AI projects, the hard part is never a single technology — it's assembling rendering, voice, and knowledge-base capabilities into a product that actually runs.

I didn't stop there — the digital-human line later became my own app, Firefly, with two technical retrospectives: Building a Conversational 3D Avatar with React Three Fiber and the firefly-studio architecture retrospective.

---

Payment Verification: Back to Complex, Real Business

After that I worked on PayPal-related projects.

Including the Customer Identity Platform (CIP) and payment system upgrades.

In the AI Payment Upgrade project, I participated in migrating from the traditional NVP, SOAP, and Payment V1 toward Orders V2 REST / SDK.

Projects like this have one trait:

Code is only part of the job.

You also deal with Docker environments, Python automation, Playwright, testing, verification, reporting, and all kinds of compatibility issues in real business scenarios.

For example, turning a verification process that used to be manual into an automated pipeline.

This brought back the feeling I had building enterprise projects early in my career:

A real engineering problem is never "done when the code is written."

Rather:

Can the environment run?
Can the pipeline execute?
Can the results be verified?
Can problems be located?
Can it finally be delivered?

That thread — real business → automation → verification — later extended directly into my Agent engineering direction. Software has to run in a real environment, and so do Agents.

That raised a question worth pausing on: if software engineering itself can be decomposed, executed, and verified, can Agents participate in the same way?

PSE (Planner–Specialist–Evaluator) took shape while answering exactly that question — I later practiced it across several mainstream Agent frameworks and wrote the series up: documents as state machines, LangGraph, LlamaIndex, AutoGen, and CrewAI.

---

AI: Not a Restart, but a Recombination

Later, AI started moving fast into software development.

Many people see AI as another technology pivot.

To me, it's more like a capability recombination.

The old way of working looked roughly like:

Humans understand requirements → humans design → humans write code → humans test → humans deploy

Now it's gradually becoming:

Humans understand requirements → humans design the system → Agents execute → Tools provide capabilities → Workflow organizes tasks → automated verification → humans make the final call

What I started paying attention to was no longer just "how to call a model," but how to let models genuinely participate in building software:

What are Agents responsible for?

How do Tools provide capabilities?

How do Skills accumulate experience?

How do Workflows organize tasks?

And how does a Harness make the whole process controllable and verifiable?

These questions all look new.

But they point at a very old one:

How to make software complete real tasks more effectively.

---

From Writing Code, to Building Systems That Participate in Writing Code

This is also how I understand Vibe Coding now — I've written a full piece on it: I Read Less and Less of the Code AI Writes.

Vibe Coding, to me, is not:

"I can't write code anymore, let AI write it for me."

Quite the opposite.

It pushed my attention up one level:

• What should the overall system look like?
• How does the Sandbox control the execution environment?
• How does the UI make these capabilities actually usable?

In the past, I built software mainly by writing code directly.

Now, I've started building a new kind of software:

A software system that participates in building software.

This is why I keep developing projects like Resolve Studio, Resolve TUI, and Resolve Harness.

Resolve Studio is not another Agent chat UI.

What I really want to solve is: can these proven Agents, Tools, Skills, and Workflows be organized into a real workbench for building software?

What interests me more and more is no longer just:

How do I build an application?

But:

How do I build a system that helps people continuously build applications?

---

I Can Be My Own Customer

This is a feeling that keeps growing stronger as I work on open-source projects.

If the company has real business needs, the requirements come from the company.

If customers have real problems, the customers are the source of requirements.

And when I'm building for myself?

I can be my own customer.

A problem I repeatedly run into can become a project.

A repetitive chore can be abstracted into a Tool.

A reusable piece of experience can be distilled into a Skill.

A complex task can become an Agent Workflow.

A persistent need can grow further into a product.

And once these projects are open-sourced, real problems and use cases from actual users flow back naturally.

A loop forms:

Requirements → Build → Release → Use → Feedback → Build again

This is essentially no different from how I worked on client projects at the very beginning.

What changed is not the way of working, but the shape of the customer — from contracted companies to a real, open-ended group of users. The boundary of "customer" is more open because of that.

---

FDE: A Way of Working I Know Well

The market now has new job titles: AI FDE, AI Builder, Forward Deployed Engineer.

None of these names feel foreign to me.

Because back when I was building CRM systems, I was already doing:

Customer communication → understand requirements → design the system → develop → deploy → gather feedback → iterate.

What draws me to FDE is not the job title — it's that the way of working behind it is one I've practiced for years: enter the real environment, understand the problem, build fast, verify the result, then distill the solution into reusable tools.

That said, what a typical FDE role demands — long stints on customer sites, frequent travel, and continuous firefighting — is not necessarily the work form I'd choose long-term. What I value is the way of working itself, not any particular job title.

What I delivered later became web apps, mobile apps, embedded systems, payment systems, and identity verification platforms.

Now it's becoming:

Agents, Tools, Skills, Workflows.

So I don't think I suddenly "pivoted" from traditional software development to AI.

More precisely:

The form of software keeps changing, and I keep expanding my ability to build.

---

I've Always Been a Builder

If I have to give this career one label, my answer is:

Builder

I used to build applications.

Then I built tools.

Now I'm building systems that build software.

Keep Building.

If you have a real problem that doesn't have a clear answer yet, or you're building a team that wants to land AI in real workflows, I'd love to talk. Turning vague problems into things that can run, be verified, and actually ship — that's what I've always done, and what I do best.

The full timeline lives on my online resume.