I’ve been in software engineering for 17 years. Mostly .NET, mostly enterprise, mostly healthcare. I know how dependency injection works, when to use vertical slice vs clean architecture, why eventual consistency makes more sense for certain systems.
But now, I barely write code myself anymore.
And my output is actually more productive than ever.
What Changed Isn’t the Skill — It’s How I Use It
My workflow used to be classic: receive requirements, design architecture, open the IDE, write code, debug, deploy. All hands-on.
Now? I still design the architecture. Still decide which patterns fit. Still review the results. But the one writing the code is AI.
Not because I can’t. But because I realized: my value isn’t in keystrokes — my value is in decisions.
A real example: I’m building a POS (Point of Sale) system. I’m the one who decided:
- Offline-first architecture — all reads from IndexedDB, periodic sync to server
- Server-first checkout — try POST to API first, fall back to local when offline
- Vertical slices on the backend — one feature, one file, no excessive abstraction layers
AI implemented all of it. But without those architectural decisions, AI would build something that technically works but is architecturally wrong.
17 Years of Learning Concepts, Not Syntax
Here’s what I’ve come to realize: over 17 years, the most valuable thing wasn’t memorizing C# syntax or specific framework APIs. What’s valuable is:
Knowing when to use what. When a relational database fits better than a document store. When a background job beats real-time processing. When denormalizing data is a trade-off worth making.
Knowing why things fail. When AI generates code that errors out, I can immediately say: “That’s a race condition” or “That’s an N+1 query problem” — without reading line by line.
Knowing proven patterns. Circuit breakers for external calls. Retry with exponential backoff. CQRS when read and write patterns diverge significantly. None of this came from reading docs — it came from failing in production.
AI knows syntax better than I do. AI can generate boilerplate faster. But AI doesn’t have 17 years of context about what can go wrong in production.
How I Work Now
My workflow now looks more like a director than a programmer:
1. I define the “what” and the “why”
“Need a transaction history page. Data from IndexedDB — local first. Users can filter by date and search. Client-side pagination, don’t hit the server for every page.”
2. AI implements the “how”
AI writes the React components, hooks for IndexedDB, filter logic, pagination. Usually 80-90% correct on the first try.
3. I review and redirect
“30-second sync interval is too aggressive for mobile. Change to 5 minutes. And add an online event listener so it syncs immediately on reconnect.”
This isn’t “AI replacing developers.” This is a developer who knows how to leverage AI.
Why Not Every Developer Can Instantly Become an Orchestrator
There’s a misconception that anyone can “use AI for coding.” Technically, yes. Anyone can ask ChatGPT to generate code.
But there’s a massive difference between:
- Asking AI to build a todo app → and getting a todo app
- Asking AI to build a production POS system → and getting something that actually works in the real world
The difference? The ability to judge output.
When I ask AI to build an API endpoint, I immediately know:
- Whether the error handling is sufficient
- Whether there’s a security hole
- Whether the query will be slow with large datasets
- Whether the architecture is consistent with the rest of the system
Without experience, you don’t know what you don’t know. AI will give you code that runs, but not necessarily code that’s right.
Skills That Matter More Now
Where it used to be about “writing clean code,” now what matters is:
Precise communication. How to explain requirements to AI without ambiguity. It’s similar to writing technical specs — and it turns out that’s a skill I’ve been practicing for years as an engineer.
Architecture and system design. The more AI handles implementation details, the more critical the ability to see the big picture becomes. How components interact, where potential bottlenecks are, how the system scales.
Judgment. When AI is right, when it’s wrong. When an AI solution is “good enough” and when it needs refactoring. This can only come from experience.
For Senior Developers Who Are Skeptical
I get the skepticism. I used to think: “If AI does the coding, then what do I do?”
The answer: the same things you’ve always done — minus the repetitive parts.
You still design. Still decide. Still take responsibility when production goes down at 3 AM. AI can’t be blamed during an incident. You can.
The difference is that going from idea to implementation is now much faster. Something that used to take a 2-week sprint can now be done in hours. Not because quality dropped — but because the most time-consuming parts (writing boilerplate, setup configs, implementing the hundredth CRUD) are now delegated.
And the time that’s freed up? Spent on things that truly need a human brain: architecture, product decisions, and making sure everything makes sense for the user.
Closing
I didn’t stop being a software engineer. I’m still an engineer — just with different tools.
My tools used to be Visual Studio and a keyboard. Now my tools are AI that I direct with 17 years of experience.
And honestly? This is the most productive phase of my career.
— Anjar Priantoro, Yogyakarta