Am I Still a Developer — or Just Someone Who Knows How to Prompt?
Three months ago, I was onboarding a new developer onto the team. We were walking through the codebase, and at some point he turned to me and asked: “How do you actually work? Like, what does your day look like?”
I started to answer. Then I paused.
Because the honest answer — the one I almost said out loud — was: “I open Cursor, describe what I need, review what comes back, adjust the prompt if it’s wrong, and move on.”
Twenty years in tech. Java since 2015. Spring Boot, Kafka, distributed systems, production incidents at 3am. And the most accurate description of my current workflow is “describe and review.”
I didn’t say that. I gave a better answer. But the question stayed with me for weeks.
The Version of Me That Used to Exist
There was a period — not that long ago — where I knew exactly what kind of developer I was.
I’d trace a NullPointerException through four layers of abstraction not because I had to, but because I wanted to understand it. I’d rewrite a service method three times until the logic felt clean — not clean enough to ship, but clean enough to be proud of. I’d read through open-source Spring Boot projects on weekends just to see how other engineers thought about problems I was also thinking about.
I had opinions. Strong ones. About naming. About where business logic belongs. About why a service shouldn’t know about HTTP. About the difference between code that works and code that’s right.
That version of me spent time inside the problem. Not just around it.
How the Shift Happened
I can’t point to a specific week when things changed. That’s what makes it hard to describe.
It started, as it does for most developers, with the legitimate wins. Let AI handle the boilerplate. The config files. The repetitive CRUD endpoints I’ve written four hundred times across fifteen years of projects. That’s not laziness — that’s appropriate automation. Nobody serious argues against that.
But then, gradually, the boundary moved.
I started using AI for things I could have written myself but chose not to. Still felt fine — efficiency, right?
Then I used it for things I should have known but had gotten rusty on. That one deserved a pause. I didn’t take it.
Then came the shift I didn’t even register in real time: I stopped reaching for the keyboard first. The default became the prompt. The question stopped being “how do I solve this?” and started being “how do I describe this so the AI solves it?”
And then — the one that actually concerned me — I stopped reading the output carefully. Not skimming for bugs. Actually reading. Understanding. Owning.
That’s when I realized the compound effect of a hundred small shortcuts had added up to something I hadn’t consciously chosen.
The Uncomfortable Question
So what am I now?
I still design systems. I still reason about trade-offs — between consistency and availability, between a clean abstraction and a pragmatic one, between what Kafka can handle and what it shouldn’t be asked to. I still catch things the AI misses, because the AI doesn’t know our domain, doesn’t know what broke in production six months ago, doesn’t know why we made the architectural decision that looks strange from the outside.
I still think like a developer. I’m confident about that.
But I also generate, review at speed, and ship code I didn’t work through the way I used to. Code that solves the problem. Code I couldn’t always fully reconstruct from scratch if you took the AI away.
Here’s the framing I’ve landed on after sitting with this for a while:
The tool isn’t the problem. The ratio is.
When I’m designing the architecture, questioning the approach, catching the edge case the model didn’t account for, asking “is this the right solution” instead of just “does this compile” — I’m a developer using AI as a tool.
When I’m prompting, skimming, accepting, and shipping without deeply engaging — I’m outsourcing the thinking, not just the typing. And those are not the same thing.
The title — developer, prompt engineer, AI-assisted engineer — matters less than being honest about which mode I’m actually in at any given moment.
What I’ve Started Doing Differently
I’m not writing a manifesto here. I’ve been in tech long enough to be skeptical of productivity manifestos, including my own.
But a few things have actually changed my day-to-day in ways that feel real:
Owning the hard parts deliberately. For anything involving core business logic — the domain model, the critical service layer, the data consistency guarantees — I write the first version myself. I use AI to review it, suggest improvements, or generate the test suite. But the logic starts with me. This isn’t slower in the ways that matter. It’s slower in the ways that are good for you.
Reading AI output like a code review, not like a search result. The shift is subtle but significant. When you get code from a colleague in a PR, you read it. You question it. You might push back. AI output deserves the same treatment — not because it’s wrong, but because understanding what you’re shipping is part of what it means to own what you ship.
Keeping the debugging muscle active. This is the one I was most at risk of losing. I now deliberately resist the urge to immediately ask AI to explain an error. First pass: me, the stack trace, and the code. This is slower. It’s also the thing that keeps twenty years of pattern recognition from quietly atrophying.
Asking one honest question at the end of the day. Not performatively. Just: did I think today, or did I mostly generate? No judgment attached. Just an honest read on how the ratio is sitting.
What I’ve Accepted
I will not be the developer I was in 2018. That’s not a tragedy — 2018 me was slower, made more of certain kinds of mistakes, and spent significant energy on things that genuinely don’t need human attention anymore.
But 2018 me had something worth preserving: a deep, almost uncomfortable relationship with the code itself. The kind of relationship where you feel the quality of a solution, not just whether it runs.
AI didn’t take that from me. I gradually traded it for throughput, one reasonable-seeming shortcut at a time.
The version of me I’m trying to build now is not the one who rejects the tools — that’s not serious, and it’s not what I want. It’s the one who uses them without losing the judgment that makes the tools actually valuable.
Because here’s the thing nobody talks about enough: AI amplifies whatever you bring to it. If you bring deep technical judgment, it makes you faster and sharper. If you bring the habit of skimming and shipping, it makes you better at that too. The tool doesn’t care. It just multiplies.
The question worth sitting with isn’t “am I a developer or a prompt engineer?”
It’s: what am I bringing to the prompt?
A Question for You
If someone asked you today — a junior colleague, a non-technical friend, your future self — “what do you actually do?”, what would the honest answer be?
Not the polished version. The honest one.
I’ve been sitting with that question for months. I don’t have a clean answer yet. But I think the fact that I’m asking it is the thing that makes me still a developer.
Jorge David has been in technology since 2004 — from managing networks and Linux servers to building distributed systems with Java, Kotlin, Spring Boot, and Kafka. Dev AI Tools is where he writes honestly about AI and the people who use it.