devto 2026-07-24 원문 보기 ↗
Let me say the honest thing first: an AI types a lot of the code I ship. The offline-first Android app our technicians use at Exequtech, parts of this website, migration scripts, test suites — Claude Code wrote much of it, in my terminal, under my eyes. I don't think that makes me less of an engineer. I think how I do it is what decides that.
A couple of years ago I made it my mission to learn to work with AI properly. Not because it was trendy — because we run a product with real users and a small team, and refusing the leverage would have been malpractice. What I didn't expect is how much actual skill the leverage demands.
Left alone, an agent produces plausible chaos. It will refactor things you didn't ask about, invent an API that almost exists, and write code that is — as most developers who use these tools will tell you — almost right. Almost right is the expensive kind of wrong: it compiles, it demos, and it detonates three weeks later in a basement with zero signal.
So the job becomes something like being a very hands-on tech lead for a very fast, very confident junior:
Structure the problem before the prompt. If I can't state the constraint precisely — "writes must succeed locally and enqueue; the queue drains when the network is healthy" — the agent can't hit it, and I've learned that failing to state it is the signal I don't understand my own problem yet.
Read the diffs. Not skim: read. The day I stopped reading was the day a "small fix" quietly changed how sync conflicts resolved. Never again.
Interrogate instead of accepting. "Why Dispatchers.IO here?" is a free lesson every single time. The agent is the fastest teacher I've ever had, but only if I make it explain itself.
Own the outcome. When sync eats a photo at 22:00, no one asks the model what happened. They ask me. That accountability is the whole difference between using a tool and being its passenger.
Somewhere along the way I noticed something uncomfortable. I was shipping more than ever, and coding less than ever — and I missed it. Worse, I could feel what atrophies when you only review: the finger-knowledge of a language, the instinct for what the standard library gives you, the ability to write the tricky function yourself when the agent circles it.
So I course-correct where I can: when a sprint allows it, I hand-write the piece myself and work the fundamentals properly. The honest version is that the systems often grow faster than the study time I can find — it's a pull I keep answering, not a routine I've mastered. Depth stays the goal; the pace decides how much of it I get each week.
I don't call myself a Kotlin developer or a React developer, and I'm certainly not calling myself an AI whisperer. Languages, frameworks, agents — they're tools. The question that matters is always the same: given this problem, this team, and what we can actually do, what's the best solution? Sometimes that's been no-code with a partner who knew the platform. Sometimes it's an agent on a short leash. And sometimes, when I can claim the time, it's me — typing.
The proof this workflow holds up in production: Exequ-Jobs and Exequtech OS.