Writing Code With AI — What 15 Projects Taught Me
These days I think “having a conversation” describes what I do better than “writing” code.
I sit in front of Claude Code and say “what if we structured this system’s architecture like this?”, look at the answer that comes back, think “ah, that won’t work here,” and steer again. And somewhere along the way tens of thousands of lines of code have come into existence. Over the past few months I’ve built more than 15 projects this way — a crypto exchange, an AI real estate analysis platform, a 12-service microservice system, a coffee machine kiosk. I want to share honestly what I’ve felt doing it.
How should developers change from here
Honestly, I was skeptical at first too. “AI writes the code? It’ll be simple-script level at best.” Then I actually used it, and my thinking changed completely.
It was while building the KoCoin exchange. Seventeen microservices on Spring Boot — matching engine, futures trading, wallets, market-making bots. Designing and implementing that alone would have taken months, but with Claude Code the flow never broke, from architecture discussions all the way to the Terraform infrastructure code. Of course I didn’t use the AI’s output as-is. What mattered was the combination: I set direction, the AI supplied speed.
That experience convinced me of something. What developers will need going forward isn’t “the ability to memorize all the code” but “the ability to know precisely what needs to be built.” Concretely:
Design ability matters more than coding ability. On the Zelotek project, migrating a legacy PHP system to 12 microservices, the hard part was never typing the code. “How do we split the services?” “Should inter-service communication be synchronous or asynchronous?” “Saga or 2PC for distributed transactions?” — those architectural decisions mattered far more. The AI proposed incremental migration with the Strangler Pattern; I judged whether that proposal held up and adapted it to our situation. That, I think, is the developer’s role from here.
“Knowing how to ask” becomes the new core competency. Tell an AI “build me a login feature” and you get ordinary code. Say instead “JWT-based auth, refresh tokens stored in Redis, rate limiting at 10 requests per 15 minutes per IP, with XSS and NoSQL injection defenses” and you get output at an entirely different level. The reason I hit a 98/100 security score building the Hunik homepage was that I knew what to ask about.
Full-stack becomes genuinely possible. “Full-stack developer” always felt a little vague, didn’t it? Go deep on backend and your frontend is weak; be good at frontend and you don’t know infrastructure. With AI you can produce production-level code outside your specialty. On the DDangZip project I built the MSA infrastructure with Spring Cloud Gateway, Eureka, and Resilience4j while simultaneously developing the mobile app in Flutter. Before, that would have taken two or three people minimum.
Things I felt along the way
“AI doesn’t do it for you — it extends you”
This is the big one. AI didn’t replace me. It widened the range of what I can do.
Building the BUJA real estate analysis platform, I designed a dual-AI analysis system running OpenAI GPT-4o-mini and Google Gemini in parallel. Pull government transaction data, forecast prices with linear regression, analyze surrounding infrastructure via Kakao Map, monitor real estate policy through Naver News. All of it built across a Node.js backend, a Flutter app, and a React admin — and honestly, with only my own knowledge I would have struggled to fold all those technologies into one project.
That doesn’t mean I did nothing. “What does real estate investment analysis actually need?” “What comparative value emerges from running two AIs at once?” — those business judgments were not something the AI could make.
“The speed of learning from failure changed completely”
Building an ERP system, I got the structure wrong when first designing the GPT-4-based AI customer support module. Nine modules — ticketing, contract management, production management, installation management — all entangled, and I hadn’t sorted out the dependencies properly. In the old days that would have cost days of refactoring alone. With AI, I could quickly discuss “what’s wrong with this structure” and “how should we untangle it,” and within hours had switched to a new structure that even included WebSocket-based real-time notifications.
Failures themselves didn’t decrease. But recovery from failure became overwhelmingly faster.
“AI held up at the hardware/software boundary too”
Building the coffee machine kiosk software (M300) and a protocol tester (TestHunik), I made an unexpected discovery: AI is quite useful even for low-level hardware integration — RS-232 serial communication, HEX/ASCII packet parsing, polling at 0.5-second intervals. Testing against a real device was of course something I had to do myself, but writing the protocol parser and designing a priority-based command queue benefited a great deal from AI.
“Building Auto-Claude took me a step further”
The most fun project was Auto-Claude: a framework where AI agents autonomously plan, implement, and verify software. Agents write code in parallel across 12 terminals, each working in an isolated Git worktree, with a QA loop running automatically to hold quality. Building it felt like crossing from “using AI” to “building AI.”
How I’ll develop from here
One conclusion from all of this.
Collaborating with AI isn’t a choice; it becomes a fundamental.
Just like Git did. Ten years ago “knowing Git” was a skill; now it’s simply assumed. AI collaboration will go the same way. Three years from now, “developing with AI” won’t be a special ability — it’ll be every developer’s baseline workflow.
So here’s where I’m going to focus.
1. Going deeper on AI agent systems. Auto-Claude gave me a taste, and multi-agent collaboration still has a mountain of unsolved problems: context sharing between agents, conflict resolution, quality assurance. I’m convinced this area will be the game changer for software development.
2. Continuing to widen my architecture range. Experiencing Kafka and 17 microservices on KoCoin, and the Saga pattern and event-driven architecture on Zelotek, gave me a feel for the depth of distributed systems. The better AI gets at writing code, the more the architect’s value — deciding what structure to build — goes up.
3. Becoming the link between business and technology. Building real estate investment analysis in BUJA and the operations system for a coffee machine business in ERP, I realized that good software ultimately starts from understanding the business problem precisely. However good AI gets, someone who knows what to build is still needed. And that’s the developer I want to be.
I started from an empty folder and built more than 800,000 lines of code with AI — from a crypto exchange’s matching engine to a coffee machine’s serial communication. The biggest thing I learned on this journey is that for a developer in the age of AI, the most important thing isn’t “typing code well” but “knowing what to build and why.”
Let’s move forward together as developers who keep asking themselves that question.