From E-Commerce to Agentic AI: A 30-Year Developer’s Journey
I wrote my first real program in the early 1990s, sitting in a computer lab at university while working toward a Computer Science degree.
Back then, programming wasn't the career everyone was racing toward.
There was no app store, no cloud, and barely a World Wide Web.
You wrote code because you were genuinely fascinated by the idea that a machine could be made to think, even if only a little bit.
More than 30 years later, I'm still chasing that idea.
The technologies have changed dramatically — from e-commerce and distributed systems to cloud computing, serverless platforms, and now agentic AI.
But the fundamental question hasn't changed:
How can we make software do more with less human direction?
This is the story of that journey.
How It All Started
That fascination with programming led me to IBM straight out of university in 1997.
My first project was integrating tooling for WebSphere Commerce Server — e-commerce in its most primitive form.
This was before payment gateways were commodities and before anyone had figured out how to make online shopping feel safe.
We were building the pipes.
And the pipes were leaking.
Every day was a new problem nobody had solved before, and I loved it.
I joined the team right in the middle of a release crunch.
The very first version of the product was days away from shipping.
I was handed the storefront code and told to build the payment and shipping functions using JSP.
People were willing to help, but the release schedule had everyone stretched thin. There's only so much time senior engineers can spend hand-holding the new person when a deadline is breathing down everyone's neck.
You figure things out.
And you figure them out fast.
And figure things out I did — sometimes the hard way.
Somewhere in the middle of building the JSP wizard for shipping destinations, I quietly excluded Puerto Rico from the United States address list.
It wasn't a dramatic mistake.
It was just a missing entry in a form.
But a tester caught it.
And it taught me something I haven't forgotten:
The edge cases you miss are almost always the ones you didn't know to look for.
After that, I helped build a common, reusable library for payment and shipping address handling, so no one else on the team would have to rediscover the same geography lesson.
We shipped on time.
After one intense week, the team released the first version of the e-commerce engine.
I had joined late in the cycle and contributed only a slice of the whole, but I remember the feeling of that release clearly — the specific kind of pride that comes from being part of something that actually ships, even when you're new and still finding your footing.
Twenty Years at IBM: Growing Into the Problem
I stayed at IBM for more than twenty years.
That might sound like inertia, but it wasn't.
The problems kept changing faster than I could outrun them.
Learning What Distributed Systems Really Feel Like
The provisioning years, from 2003 to 2011, were where I learned what distributed systems actually feel like at scale.
I was the Technology Design Lead on IBM Tivoli Provisioning Orchestration, and later the Architect for Tivoli Provisioning Manager.
Provisioning servers across an enterprise sounds mundane until you've debugged a race condition that only surfaces at three in the morning when five hundred machines try to boot simultaneously.
Those years taught me to think about systems as living, breathing things.
Not static components.
Dynamic interactions.
When Cloud Made Problems Invisible
The caching and cloud years, from 2011 to 2017, pushed me into a different dimension entirely.
I became the Lead Architect for IBM Bluemix Data and Session Cache and eventually an IBM Senior Technical Staff Member (STSM) leading WebSphere eXtremeScale and Distributed Caching as a Service.
The shift to cloud meant the problems didn't just get harder.
They got invisible.
Performance issues weren't in your hands anymore.
They lived somewhere in a data centre you'd never visit.
I had to develop a different mental model:
Design for failure, not against it.
By this point, I had been recognised as an IBM Master Inventor, a title that came from contributing to more than twenty patents spanning automation, distributed systems, cloud data replication, and platform integration.
But the patents weren't the point.
Each one represented a problem that had no concise answer in the literature, where we had to work from first principles.
That habit of thinking from first principles is probably the most transferable thing I've carried across my entire career.
The Challenges That Shaped Me
I want to be honest here, because that's the point of this kind of post.
The hardest technical challenge I faced wasn't necessarily the most complex one.
It was designing for geo-distributed active-active data replication at Huawei, where two data centres in different regions both accept writes and must eventually converge to a consistent state.
The theory is elegant.
The reality is a minefield of clock drift, network partitions, and conflict-resolution edge cases that will humble you.
We published peer-reviewed research on it, which helped.
But what really helped was accepting something fundamental:
Distributed systems are fundamentally non-deterministic, and your job as an architect is to make uncertainty manageable, not to eliminate it.
From Technical Contributor to Technical Leader
The hardest career challenge was different.
It was making the jump from deep technical contributor to technical leader and then again from technical leader to entrepreneur.
Each transition required me to let go of something I was good at.
When I became a Chief Architect at Huawei leading 20–30 engineers, I had to accept that my leverage was now in the clarity of my technical vision and the health of the team, not in the elegance of my own code.
When I later co-founded a startup, I had to accept something else:
There are no playbooks, and the speed of learning matters more than the depth of experience.
One project comes to mind clearly.
In 2024, I was leading a serverless computing initiative to build lightweight AI agent runtimes using WebAssembly (WASM).
The idea was that WASM's sandboxed, near-native execution model was a natural fit for running AI agents efficiently at the edge.
The architecture was sound.
The problem was that WASM tooling for Python wasn't mature enough at the time.
You couldn't simply compile Python code into a WASM module and run it.
Every integration required manual workarounds, bespoke bridging code, and a lot of patience.
We made it work.
But it cost significantly more engineering effort than the design had accounted for, and the result was more brittle than I would have liked.
Looking back now, I can see exactly what would have helped: using AI-assisted code generation to produce a standard, consistent interface layer for each WASM module.
That would have removed most of the manual friction.
The tooling wasn't there yet in 2024.
But the approach was right.
We were just slightly ahead of the ecosystem.
The lesson I took from it:
Keep exploring new things, and never hang up.
Technologies that feel half-baked in one year become load-bearing infrastructure two years later.
The teams that struggled through the rough edges are the ones who know how to use it properly when the rest of the industry catches up.
What I've Learned After 30 Years
After 30 years, if I strip away the buzzwords and the titles, here is what I actually know.
1. Every Technology Wave Has the Same Shape
E-commerce in the 90s.
Dot-com in 2000–2005.
Cloud in the 2010s.
Serverless in the 2020s.
Agentic AI today.
Each wave starts with practitioners saying:
"This changes everything."
Then comes a messy middle where the hard engineering problems reveal themselves.
And then comes a settling period where the technology becomes infrastructure.
I've now lived through enough waves that I can feel when we're in the messy middle.
And that's exactly where the most interesting work happens.
2. The Language Is the Least Important Part
I've shipped production code in C, Java, Python, Rust, and Node.js.
The language matters.
Rust taught me to think about memory in a way Java never forced me to, and that changed how I reason about performance.
But the language is never the point.
The point is understanding the problem deeply enough to choose the right tool.
Every time I've chased a performance issue far enough down, I've found an architectural decision made too early, under constraints that no longer exist.
The lesson isn't to avoid early decisions.
It's to make them visibly, with the assumptions documented, so the next person — including future you — knows what to revisit when the world changes.
4. Patents Are a Record of Unsolved Problems
I have 20+ filed or issued patents.
I'm prouder of the publications.
A patent means you found an answer nobody had before.
A peer-reviewed paper means you explained it clearly enough that other people can build on it.
Both matter.
But the second one is harder.
5. The Best Teams Share a Mental Model, Not Just a Codebase
At IBM and Huawei, I led large distributed teams, sometimes across time zones and cultures.
What separated the high-performing teams from the rest wasn't raw talent.
It was whether everyone in the room could draw the same system diagram from memory.
Technical alignment is a leadership output, not a documentation artifact.
Growth as a Developer: The Honest Version
I went from writing integration tooling for e-commerce in 1997 to architecting an agentic AI platform for the industrial domain in 2026.
The path looks linear on a résumé.
It wasn't.
There were long stretches of being the least experienced person in the room — and shorter, more uncomfortable stretches of being the most experienced person and realising I was wrong about something important.
The Gartner iPaaS Visionary Quadrant recognition for Huawei's cloud integration platform within four years was a team achievement I'm proud of.
But I remember more vividly the architectural dead-ends that preceded it, and the whiteboard sessions at night where we talked each other back from decisions that would have been expensive to unwind.
The real growth came from three habits I'd encourage any developer to build early.
Capture Your Reasoning, Not Just Your Results
When you make an architectural decision, write down the why.
What problem were you solving?
What did you consider?
What did you rule out?
Code tells you what the system does.
Only your notes tell you why it does it that way.
I can't count the number of times I returned to a system months later, stared at a design choice that looked strange, and had no record of the constraints that made it sensible at the time.
That missing context is expensive.
It means re-doing the analysis, or worse, undoing a decision that was actually correct.
Over the years, this became one of the most underrated disciplines I've tried to instil in every team I've led.
Read Outside Your Stack
Some of the best ideas I've applied to software engineering came from operations research, organisational theory, and systems biology.
Distributed systems are complex adaptive systems, and the vocabulary for understanding them has existed in other fields for decades.
Developers in the AI Era
In the AI era, coding is no longer the scarcest skill.
And that changes everything.
I've watched developers at every stage of their career worry about being replaced by AI.
I think they're asking the wrong question.
AI is already a capable coding assistant.
It will only get better.
What it cannot do is understand why a business needs a system to work a certain way, see the architectural trade-offs across a five-year roadmap, or translate a domain expert's vague requirements into a design that will still be maintainable when the team changes.
Those are human skills.
And they matter more now than they did when writing code was the bottleneck.
My advice to developers who are early in their careers is simple:
Invest in your ability to think in systems, understand the business problems behind the technical requirements, and communicate clearly across both worlds.
The developers who thrive in the next decade will be the ones who know how to direct AI effectively, not compete with it.
What I'm Building Now
I'm currently co-founding an AI startup focused on autonomous agentic systems for specific industrial domain sectors.
We're designing enterprise AI agents that can reason, plan, and act with minimal human intervention.
It's early.
It's hard.
And it's the most interesting technical problem I've worked on.
The thread from my first line of C code to today's agentic systems is actually straightforward:
I've always been drawn to the problem of making software do more with less human direction.
E-commerce automation in 1997.
Server provisioning orchestration in 2003.
Serverless computing on the edge in 2020.
Autonomous AI agents in 2026.
The abstraction layer has risen.
The fundamental question hasn't changed.
If you're a developer earlier in your journey, find that question — the one you keep circling back to no matter which technology is in fashion — and follow it.
The career will take care of itself.
A Note on CoderLegion
Communities like CoderLegion matter most in the messy middle of a wave when everyone is confident the technology is important but nobody yet agrees on the right way to use it.
Agentic AI is squarely in that middle right now.
The conversations I've found here, from practitioners who are actually building, not just theorising, are exactly the kind of signal that helps me calibrate what problems are real and which are manufactured by hype cycles.
About Paul Chen
Paul Chen is a COO focused on Agentic AI & Autonomous Systems and Intelligent Cloud & Edge Services, with more than 30 years of experience in distributed systems, advanced cloud applications, and serverless platforms. He is currently focused on agentic AI, autonomous systems, and multi-agent systems. :contentReference[oaicite:1]{index=1}
His career has spanned e-commerce, distributed systems, cloud computing, serverless platforms, and now autonomous AI systems.
View Paul Chen's CoderLegion Profile
Developer: Paul Chen
Series: CoderLegion Developer Stories
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion
