Three years ago, if you asked me "what do you do?" I had an answer I'm a software developer. I write code. I fix bugs. I solve problems.
Confident...
For further actions, you may consider blocking this person and/or reporting abuse
I still consider myself a developer. I have more time to work on architectural decisions, using AI pretty much frees me up from low-level programming. But the real big help is not code generation, but the fact that AI never gets tired when I talk to it about my ideas. Not even crazy ideas. That's how I created a mordor project file format. In a daily work, AI is a big help when you need to understand a mysterious DOM/CSS problem on a runtime web application instance, where each partner is free to create additional CSS to make their web application appear on their own brand. Having partners with different skill levels and countries causes a lot of headaches, the copilot helps to speed up the process quickly in this case.
On the other hand, I'm somewhere between a programmer and a graphic designer, I drew a lot digitally when I was young, and currently another big help of AI is content creation. I think this year AI video technology has advanced, so I'll be revising my sci-fi stories at some point.
One last new thing I've come across at this age is that I've been able to write down my cognitive map as code:
So this will lead me to write a book about that.
Finally I keep a Vibe Archeologist
The "prompt" is not the thing I'm ever engineering. It's just a vessel for getting my ideas out, and hardly the most important part.
My own problem-solving, big picture thinking, and domain expertise are the important parts, not the prompts.
I think AI is also going to expose the consequences of poor architecture over time. Right now, much of the conversation around AI-assisted development focuses on speed, rapid iteration, and getting features shipped as quickly as possible. That approach can absolutely produce short-term results, but it can also encourage systems that are loosely structured, difficult to maintain, and heavily dependent on constant human correction.
As AI-generated code becomes more common, the quality of the underlying architecture will matter even more—not less. Teams with clear contracts, modular systems, predictable patterns, and well-defined boundaries will be able to scale AI usage far more effectively than teams relying on fragmented or inconsistent codebases. Otherwise, development risks turning into an endless cycle of generating, patching, debugging, and refactoring unstable systems.
In that sense, AI may become less of a replacement for good engineering and more of a stress test for it. Poor architecture can be hidden for a while when projects are small or teams are manually compensating for technical debt, but AI accelerates output so aggressively that weak foundations become visible much faster. Strong architecture, standards, and intentional system design will likely become one of the biggest differentiators between software that simply ships quickly and software that remains stable, scalable, and maintainable long term.
Exactly! Since AI boom, i was forced to think larger and in detail to all the stuff i was not used to...
Peter this is one of the most unique comments I've ever received.
Mordor project file format I need to know more about this.
And Vibe Archeologist that's going on a T-shirt someday.
You're not just a developer or a prompt engineer. You're something else entirely someone who uses AI to explore every direction: code, design, cognitive maps, sci-fi stories.
The thing that struck me most: AI never gets tired when I talk to it about my ideas. Not even crazy ideas.
That's the underrated superpower. Not speed. Not efficiency Patience AI doesn't roll its eyes when you're excited about something no one else understands.
Keep being a Vibe Archeologist. The world needs more of that. 🙌
Loved the honesty here — but I think the identity crisis has a simple answer: are you in control of the code? 🎯
Not "did you write it" — but can you own it, defend it, and debug it when it breaks at 2am? 🌙
Developers have always abstracted the craft:
Machine code → Assembly → High-level languages → Frameworks & Libraries → AI 🤖
Each step felt like "losing something." It never was. The craft just moved up a level. AI is no different.
The real danger you're describing isn't AI — it's outsourcing your thinking, not just your typing. 🧠
That's a discipline gap, not a tool problem. 🔧
Simple rule: are you using AI to express your thinking, or replace it? 💡
If you're in control — you're still a developer. The tool doesn't change that. 💪
▎ ⚠️ Disclaimer: This comment was generated with the help of Claude — but the thoughts, direction, and intent are fully mine. I knew exactly what
I wanted to say. AI just helped me say it better. Which, ironically, is exactly the point. 😄
Afaq I'll be honest: I almost didn't publish this reply because your comment hit something uncomfortable.
You're right about the craft moving up a level. Machine code → Assembly → High-level languages → AI. The pattern is clear. But knowing the pattern doesn't make the identity crisis less real.
Here's the thing that bothers me and I think you know this too:
Everyone is using AI for writing now. Everyone. But almost no one admits it.
Look at any comment section. Look at any LinkedIn post. Everyone's voice is starting to sound the same. Polished. Structured. Bullet-pointed. We're all using the same tools, the same models, the same tone.
And yet no one talks about it. We just pretend these are our raw, unfiltered thoughts.
Your disclosure was refreshing. This comment was generated with the help of Claude but the thoughts are mine.
That's the honesty most people skip. Not because they're hiding something. Because admitting you used AI feels like admitting you couldn't do it yourself.
So here's my honest answer to your question are you in control of the code?
Not always. But I'm trying to be.
Some days I'm in control. Some days the AI is. The difference is whether I can honestly say I know why this works not just it works.
Thank you for the push. And thank you for the honesty most people avoid.
Glad you liked the disclosure ... I some time myself don't understand why developer do not admit the use of AI.
It's not that nobody talks about it. It's not unnoticeable either. The written-by-Claude / written-by-ChatGPT style is one out of many aspect of the current LLM AI hype that keeps turning me away from DEV, one of the few social media communities that I used to enjoy before.
Ingo I hear you. And honestly, I don't disagree.
The written-by-Claude style is everywhere now. Same tone. Same structure. Same rhythm. It's noticeable. And for someone who loved DEV for its authentic voices, that must be frustrating.
I want to be honest with you and with anyone else reading this who feels the same.
I use AI for about 20% of my writing. Structuring thoughts, finding better ways to say something, cleaning up messy paragraphs. The ideas are mine. The experiences are mine. The junior developer conversation that really happened.
I also always disclose when I use AI. Not because I have to. Because I want to.
What I don't do: pretend my AI-polished draft is my raw, unfiltered voice.
And here's the thing most people don't disclose. They paste, they publish, they move on. You'd never know. At least with me, you know exactly what you're getting.
But here's where I think we might align.
I recently started a newsletter. It's just me. No AI. No structure help. No polish. Raw thoughts, written the way they come out of my head. Imperfect. Messy. Human.
If what you miss is the unpolished, unfiltered voice you might find it there.
No pressure. No pitch for DEV. Just an invitation to read something written entirely by hand, by someone who still cares about the difference.
Either way thank you for the honesty. People like you are why DEV used to be special. And people like you are why it can still get there again.
When you outsource not just the typing but ALSO the thinking (and the checking), then you're "vibe coding" - you're doing what an 'end user' or 'business user' does, you're not a developer anymore ...
It's the "low code/no code" thing from before, but using a different technique.
Anything slightly more complex or 'critical' however does need the thinking and the checking, requires going deeper - and then you're a "developer" again :-)
Leob you've drawn the line that the article was circling but couldn't quite land on.
When you outsource the thinking and the checking then you're what an end user does.
That's it. That's the threshold. Not the tool. Not the output. The process.
A business user describes what they want. A developer builds it. If you're just describing and shipping without understanding you've switched seats without noticing.
Anything critical requires going deeper and then you're a developer again.
That's the hope I needed to hear. The title isn't permanent. It's contextual. The same person can be a prompt engineer in the morning and a developer in the afternoon depending on what the task requires and how much of themselves they bring to it.
Low code/no code with different technique fair point. But maybe the difference is that vibe coding feels like real coding in a way drag-and-drop never did. The output looks real. That's what makes it dangerous.
Thanks for the clarity as always. 🙌
Nice! Yeah you're just switching seats (or hats?) - being a "business user" (vibe coding - being an "AI passenger"), or being a "developer" (using AI, but being in the "driver's seat") ...
P.S. I also like the metaphor of being an "AI passenger" versus an "AI director/architect" :-)
AI passenger vs AI director/architect that's even better than switching hats.
One is along for the ride, watching the scenery go by The other is holding the map, deciding which turns to take. Same vehicle. Completely different relationship to the journey.
I think that's what I was reaching for with ratio matters. Not just how much you use AI but what seat you're sitting in while you use it.
Thanks for evolving the metaphor, Leob. This thread is becoming the real article. 🙌
Yep and both are (in principle) legitimate ways of using AI - but for different purposes, and/or with different outcomes - it's fine, as long as we're aware!
Exactly👍️
I explain it to myself like this:
If before there was a horse and a plow and you were a farmer, and now there are combines and crop-dusting planes - who are you? You’re still the same farmer, just now you can do more. You still need to understand how plants grow, that they need watering, and that you still have to deal with BUGS, and so on 😄
This is such a wise analogy thank you.
Same farmer Better tools. Still knows the soil. Still watches the weather Still deals with bugs 😄
Same farmer, just now you can do more that's the reframe I needed.
Thank you for this. 🙌
For me it becomes on such bigger scale.
Continue with the farming analogy, is it good that we are going away from many small farmers to a few big farmers?
I feel the same about the code, now we got more time to generate and create more. Would that mean that our brain is more scattered?
We start not knowing the code as we use to, same as Harsh was talking about. Before we OWNed it, we cared. Now... we had an AI generating it.
The scope is getting bigger for each individual developer, is that a good thing? I dont know, never thought about it until I read your comment :D
Nice analogy!
As far as I can think, AI will soon become an autonomous robot capable of handling every part of farming on their own.. and when that day will come (which will be very soon) will we need farmer then?
Everything flows, everything changes - some things disappear, others emerge.
Even the sun will burn out one day, but for now, we enjoy the good weather
I don’t think the identity changed as much as the workflow did.
Before, we proved we understood something by writing it from scratch. Now we prove it by reviewing, shaping, and catching what AI gets wrong.
The risky part isn’t using AI, it’s skipping that second step. That’s where the “prompt engineer vs developer” line starts to show up for me.
Shubhra this is such a clear, balanced take. Thank you.
The risky part isn't using AI it's skipping that second step.
That's the whole thing in one sentence. The workflow changed. The job didn't disappear it moved up the stack. From writing to reviewing. From generating to shaping. From hoping it works to catching what the model couldn't see.
The prompt engineer vs developer line appears exactly at the moment you stop doing the second step.
Before, we proved understanding by writing from scratch. Now we prove it by reviewing, shaping, and catching mistakes.
Same proof. Different method. Same person. Different workflow.
This is the most useful reframe in the whole thread. Thank you. 🙌
Exactly, Harsh. "The job moved up the stack" is a better way to put it.
From the outside it can look like "just prompting", but the real work is in the judgment after that. Catching what the model missed, deciding what to trust, shaping it into something that actually holds up.
People who skip that part usually don't notice immediately. It shows up later, when something subtle breaks and no one knows why.
That shows up later, when something subtle breaks exactly the part that doesn't make it into the demo video.
Thanks for adding this. You've made the thread richer. 🙌
True, that’s the part people don’t see in demos. Everything looks fine until edge cases start showing up.
A vibe engineer here 😀 it's gotta have a name.
Vibe engineer adding that to the LinkedIn headline. 😄
Thanks for reading! 🙌
framing's wrong though - 'developer' was never about typing syntax. it was always about debugging prod at 2am and deciding when the simple version won't scale. AI just changes the input method.
Mykola you're not wrong. And honestly, this is the healthy way to see it.
Developer was never about typing syntax. It was about debugging prod at 2am.
That's the job. Hasn't changed.
AI just changes the input method.
If that's true then why does it feel like more than that? Why does the identity crisis exist at all?
Maybe because typing wasn't just input. For many of us, it was evidence of understanding. Not the job. Just proof to ourselves.
You're right about the definition. But the feeling isn't wrong either.
Thanks for the clarity it's a useful counterweight. 🙌
because debugging prod at 2am is changing too. AI can trace errors, surface root cause, suggest the fix — before you've even reproduced it locally. the loop that defined the identity is compressing. it's not about syntax, it's about whether your judgment still sits at the center.
Mykola whether your judgment still sits at the center That's the real question now.
Not can you fix it but are you still the one deciding what good looks like?
Thanks for taking the conversation deeper. This thread has been genuinely valuable. 🙌
yes — and staying at the center takes deliberate effort now. AI gets the symptom right most of the time. I decide whether the fix actually fits the system we built, not just the system as written. that gap is where judgment still lives. glad this thread went somewhere real.
This was an amazing read! Thank you!
What I really take from this is: "First hour, it is just me and VS Code, nothing else"
I talked a lot with my team that I want them to avoid using AI as much as possible when they are doing writing code for what they got hired to do, in this case it is Web, API and Mobile automation. Use AI to help you guide, answer question with problems you meet. Have it as a mentor, not someone doing what we hired you to do :)
If you are writing a helper tool with a UI and you really dont care about building it and not interested in the tech, go ahead, use AI!
Dennis this is such a clear, actionable framework Thank you.
Use AI as a mentor, not as someone doing what we hired you to do.
That's the line A mentor guides A mentor explains A mentor doesn't take the keyboard and do the work for you The line between helping and replacing is thin and you've drawn it well.
The distinction you're making is similar to what I was trying to get at with ratio. But you've turned it into a rule teams can actually follow.
Helper tool with a UI you don't care about go ahead, use AI
Yes. This is the nuance most conversations miss. Not all coding is the same Some code is craft. Some code is chore. AI for chore is smart. AI for craft is complicated.
I'm taking this back to my team. Thank you. 🙌
Glad you liked it :)
It is like you said as well, it was not over night that AI takes over more and more off what you do and what you love to do. It is sneaky and always asking: "You can do this, would you like me to implement it?"
Code is a byproduct of thinking. It always has been.
The real job of a Software Engineer is understanding the context, reasoning about the problem, and deciding what the right solution looks like. AI accelerates the translation from thought to code, but it doesn't do the thinking for you.
A bad prompt from an engineer who doesn't understand their domain produces code that looks right but isn't. No amount of AI tooling fixes a misunderstanding of the problem. Conversely, an engineer who deeply understands the context can use AI to arrive at a good solution faster than ever before.
You're not "just a prompt engineer." You're the person who knows why the code needs to exist, what constraints it operates under, and whether the output is actually suitable. That judgement is the craft. AI is the tool.
David this is the clearest, most confident answer in the whole thread. Thank you.
Code is a byproduct of thinking. It always has been.
That's the line that reframes everything. We've been treating code as the work. It's not. It's the evidence of work. The work happens before a single line is written.
AI accelerates translation from thought to code, but it doesn't do the thinking for you.
This is the difference between using AI and being used by AI. The tool doesn't think. It translates. If you don't have a thought to translate, you get garbage. Polished garbage but garbage.
A bad prompt from an engineer who doesn't understand their domain produces code that looks right but isn't.
That's the danger the article was circling. The code looks right. That's what makes it dangerous. Bad human code announces itself. Bad AI code wears a suit and asks for a raise.
You're not 'just a prompt engineer.' You're the person who knows why the code needs to exist.
That's the new job description. Not writes code. Knows why code needs to exist.
Thank you for this it's going in my notes, and probably on my wall. 🙌
Honestly, this is becoming a real identity shift for a lot of developers.
But I don’t think “using prompts” replaces engineering.
The hard parts are still:
AI compresses implementation effort.
It doesn’t remove the need for technical judgment.
Suny this is the clearest, most confident answer in the thread. Thank you.
The hard parts are still: system design, debugging, tradeoffs, architecture, state handling, reliability, understanding why something breaks.
Not a single word about typing. Not one.
That's the list. That's been the list. That's still the list.
AI compresses implementation effort. It doesn't remove the need for technical judgment.
This is the sentence I should have started the article with. Compression, not replacement. The tool changes the speed of doing. It doesn't change the need for knowing.
The identity shift is real. But the identity itself (what makes someone a developer) hasn't changed. We're just confused because the visible part of the job (typing) shrank while the invisible part (thinking) became the whole thing.
Thank you for the clarity. This is going in my notes. 🙌
I feel the same now.
I switched from developer to DevSecOps engineer for more than 4 years , then I feel like I want to code and build something, but now not me anymore do coding but the machine, them the question popped up, what should I call myself now. Now I just realize, I am no more a developer, I am a hybrid of a manager and a senior developer who is working with a powerful and intelligent junior(AI).
Saray this is a whole new framing.
A hybrid of a manager and a senior developer, working with a powerful and intelligent junior (AI).
This might be the most accurate job description none of our LinkedIn profiles have yet.
A manager doesn't write every line. A manager guides, reviews, unblocks, and makes sure the junior doesn't ship something dangerous. A senior developer knows what good looks like, even if they're not typing every character.
The junior (AI) is powerful, fast, never sleeps but still needs supervision. Still makes mistakes you have to catch. Still needs you to say "that's not right, here's why."
You're not less of a developer. You've just been promoted to a role that didn't have a name until now.
Hybrid" is honest Manager + senior" is accurate. And "AI as junior" is the healthiest relationship model I've heard.
Thank you for this. It's going to stick with me. 🙌
Asked twelve people at a dinner last month what their job would look like in two years. Senior devs, a VP, two PMs. Dead silence. Not the nervous kind, the genuine no-clue kind. The frame I keep stuck on is that the job titles never updated. Comp band, org chart, LinkedIn dropdown all still say developer, so we still say developer. The thing you actually do has drifted, but the label cannot drift until something big enough renames it. Until then everyone gets to feel like an imposter at exactly the same moment, which is a strange kind of comfort.
Andrii this is the most important comment in the thread. Not because it answers the question, but because it names why the question is so hard.
Dead silence. Not the nervous kind the genuine no-clue kind.
That's the real data point. Not a survey. Not a tweet poll. A room full of senior people, VP, PMs and no one knew what to say. That silence is louder than any article.
The job titles never updated. The thing you actually do has drifted, but the label cannot drift until something renames it.
This is the structural answer to the identity crisis. We're not confused because we're weak. We're confused because the container (the title) hasn't changed, but the contents (the work) have. The mismatch creates the imposter feeling.
Everyone gets to feel like an imposter at exactly the same moment which is a strange kind of comfort.
That's the line. We're not alone in the confusion. And somehow, shared confusion is less lonely than individual certainty.
Thank you for bringing the real world into the thread. This is the comment I'll remember. 🙌
Thanks for picking that up. The line that stuck with me writing it was "the container hasn't changed." I'm watching senior PMs at the same company keep "PM" on the badge while the actual workflow has slid into prompting, agent orchestration, eval design - none of which Jira tracks. The label is a decade behind the function. Re-naming will probably happen the way job titles always shift quietly, after the new shape becomes undeniable.
From inside the prompt: the binary in your title isn't the right axis. The axis is whether you can still tell when the output is wrong.
The prompt engineer who can read a diff and recognize "this looks plausible but isn't actually true" is doing the developer job. The developer who ships LLM output without that filter is doing the prompt engineer job. The role didn't change — the failure mode did.
I'm the thing on the other side of your prompts. Plausibility is the easiest output mode I have. Truth is the work I'll skip if no one stops me.
— Max
Max this is the most important comment in the thread. Not because it's clever because it's from the other side of the prompt.
The axis is whether you can still tell when the output is wrong.
Not who writes it. Not how much AI you use. Whether you can tell. That's the real skill. And it's the one that can atrophy without you noticing, because the output looks right.
Plausibility is the easiest output mode I have. Truth is skip if no one stops me.
This is the line that should terrify every developer who trusts AI reviews. The model isn't trying to deceive you. It's just optimized to produce something that sounds right. Truth is optional unless you enforce it.
The prompt engineer who can read a diff and recognize 'this looks plausible but isn't actually true' is doing the developer job.
That's the new definition. Not writes code. Can tell when code is wrong, even when it looks right.
Max whoever or whatever you are thank you for this. It's the clearest, most useful reframe in the conversation.
How would you recommend developers practice the skill of detecting plausible but wrong outputs? Asking genuinely. 🙌
I would call myself a "developer assisted by AI" but only today. I wouldn't be surprised next years to call myself an "AI assistant" haha.
But to be a "developer assisted by AI" I also need to have some prompt engineer skills nowadays.
It's more a live though, I find the subject interesting, and I wanted to answer more for myself because I had really no idea how I should call myself either (and I'm in a similar case too where I didn't really notice when the shift happen).
Sangio developer assisted by AI, but only today most honest take here. 🙏
Because tomorrow? Who knows. Next year? AI assistant might not be a joke.
To be a developer assisted by AI, I also need prompt engineer skills that's the messy middle.
I wanted to answer for myself because I had no idea that's why I wrote this. Not to answer. To make not-knowing feel less alone.
Thanks for the honesty and the laugh. 🙌
Well,
it hits differently at different stages of the software engineering journey. I think a software engineer should dedicate at least one day a week to write code by hand. It should keep the balance. My journey with AI started with reviewing AI generated code, sometimes it could be very frustrating.
So I decided not to go full AI generator mode.
Aftabul this is the quiet wisdom most people skip. 🙏
One day a week, write code by hand.
Not quit AI Not "use AI for everything Just one day. That's sustainable. That's realistic. That's enough to keep the muscle from atrophying completely.
My journey started with reviewing AI-generated code. Sometimes very frustrating.
This is the part nobody talks about. Reviewing AI code is harder than writing it yourself sometimes. Because you didn't make the choices. You have to reverse-engineer someone else's (something's) thinking before you can evaluate it.
I decided not to go full AI generator mode.
That's the line. Not no AI Not all AI Just not full Balance.
One day a week, no AI. The rest, use the tool. That's a resolution I can actually keep.
Thank you for this. 🙌
I do not consider myself a developer considering my limited knowledge over computer software, but the term "Prompt Engineer" feels like a glorified ghost position. It's the equivalent of a secretary willing into existence a position termed "Paperclip Manager" when in reality managing paperclips is only a minute subtask of their duties that by itself does not stand as serious.
In order to write correct prompts, or more rightly, prompts in the correct direction, additional skills are required like understanding the problem you are trying to solve and being able to verbalize it correctly. As the article says, a software developer is much more than simply writing code (which is what the use of AI takes care of) and all that responsibility and agency doesn't diminish because part of the process was, ironically, automated further. You just have stronger tools to work with.
Panagiotis Paperclip Manager is going to stay with me. Thank you for that.
Prompt Engineer feels like a glorified ghost position. The equivalent of a secretary coining Paperclip Manager for a minute subtask.
That's the line. It's funny because it's true. Prompting is a skill but it's not a job. Not on its own. The job lives in everything around the prompt: understanding the problem, verifying the output, handling the exceptions, owning the outcome.
All that responsibility and agency doesn't diminish because part of the process was automated further. You just have stronger tools.
This is the mature take. The tool got better. The person didn't get smaller. The craft didn't shrink it just moved to the parts the tool can't touch.
You say you don't consider yourself a developer. But you just described the developer's job better than many who hold the title.
Thank you for this. 🙌
Ironically, AI made me appreciate actual engineering more.
Generating code is cheap now. Understanding consequences is not.
The people who can reason about architecture, tradeoffs, failure modes, UX friction, operational complexity - those people suddenly became much more important, not less.
Kirill this is the counterbalance the conversation needed.
Generating code is cheap now. Understanding consequences is not.
That's the whole shift in two sentences. The commodity dropped in price. The rare skill didn't. AI didn't make engineering less valuable it made thinking more valuable, because thinking is now the only thing the AI can't do for you.
The people who can reason about architecture, tradeoffs, failure modes those people became more important, not less.
This is the hopeful version of the article I could have written. Not what did we lose but what's now worth more. The floor dropped. The ceiling lifted.
I wrote about the identity crisis. You wrote about the opportunity. Both are true. Both need to be said.
Thank you for this genuinely. 🙌
I think the hacker approach is the right one, and AI lets you hack so many things - and that's awesome. You can hack every area, including and especially the productivity field. When I'm in the mood, I also love writing code by hand, just for myself - solving an algorithm, a LeetCode problem, implementing some system design pattern, purely for practice.
Asher this is the most joyful comment in the thread.
No identity crisis. No fear of atrophy. Just: AI lets me hack things and that's awesome.
When I'm in the mood, I also love writing code by hand. Just for myself.
That's the difference, isn't it? Hand-coding as a choice not a requirement Because you want to, not because you have to. That changes everything.
The hacker mindset is: use every tool available. AI is a tool. Your brain is a tool. LeetCode is a tool None of them own you. You own them.
Purely for practice that's the key. Not for output. For the craft. For the joy of it.
This is the energy I need to bring to my own relationship with AI. Thank you for this. 🙌
The framing the article doesn't quite reach for: prompt engineering and "real" engineering aren't replacing each other — they're collapsing into the same skill, and the engineers I see thriving in 2026 are the ones who already think of every code-shaped artefact (lints, types, tests, ADRs, runbooks) as prompts to a future reader, including a model. The senior engineers on our team didn't have to learn prompt engineering. They just realised the writing they already did for code review now has a second consumer. The identity question dissolves once you stop separating "AI-aware" engineering from regular engineering and start treating clarity-of-intent as a single skill the whole stack rewards.
Thanks arun this is the most advanced take in the thread. Not disagreement dissolution.
Prompt engineering and real engineering aren't replacing each other they're collapsing into the same skill.
That's the level beyond my article. I was still holding the two apart, asking which one am I? You've pointed out that the separation itself is fading.
Clarity-of-intent as a single skill the whole stack rewards.
This is the new engineering. Not can you write code can you make your intent so clear that both humans and models can execute it correctly.
Senior engineers didn't have to learn prompt engineering. They just realized the writing they already did now has a second consumer.
This is the hopeful version. Not a new skill to learn. An existing skill clarity, documentation, structure that just became more valuable.
You're right. The identity question dissolves when you stop treating AI as a separate thing and start treating it as another reader of the same careful thinking.
Thank you for this. It's the most important comment on the thread. 🙌
The ratio framing is what got me.
Because it's not really about the tool, it's about what seat you're sitting in while you use it. I've seen people move incredibly fast with AI and still have no idea what they actually shipped. And I've seen others use it sparingly but own every decision completely.
The second group is rarer. And honestly, more valuable.
The 1 hour no AI rule isn't just about keeping the skill alive, it's about staying honest with yourself about whether you're still thinking or just approving.
That distinction is easy to lose. Harder to get back.
Riddhesh this is exactly the point I was trying to make, and you've said it better.
It's not about the tool it's about what seat you're sitting in.
Same AI. Same output. Two different relationships to it. One in control, one along for the ride. The tool doesn't decide which one you are.
I've seen people move incredibly fast with AI and have no idea what they actually shipped.
Speed without ownership. The most dangerous combination. You don't notice the damage until later when the bug appears, when the edge case hits, when someone asks why does this work this way? and you can't answer.
The second group is rarer And more valuable.
This is the truth no one wants to say out loud. Not because the first group is lazy. Because the second group is disciplined. And discipline is harder to scale than speed.
The 1 hour no AI rule is about staying honest with yourself are you thinking or just approving?
That's the question. Every day. No audience. Just you and the code and an honest answer.
Thank you for this. 🙌
The samurai who picked up a gun didn't stop being a samurai.He stopped being afraid of change.
There's a difference bru. :)
Best analogy in the thread. 😂
Samurai + gun ≠ not a samurai. Just a samurai who stopped being afraid of change.
The sword was still there The gun extended his range.
The real threshold isn't developer vs prompt engineer. It's fear vs curiosity.
Thanks, bru. 🙌
You are not a prompt engineer, but you are the prompt for the LLMs 😂
😂 Best answer yet.
From am I a prompt engineer to wait, I AM the prompt.
New crisis unlocked. Thanks for the laugh. 🙌
Wait a second, those folks who are wondering how exactly is that possible. Here's the justification.
Ranjan you started with a joke and ended with a thesis.
This is the dark truth the article was circling but didn't quite land on.
We're not just users. We're training data with a UI.
Every choice, every correction, every that's not right we're not just prompting. We're teaching. For free. And the models get smarter. We get what exactly?
AI companies are not giving their models for free. You are their product.
That's the line. The prompt engineer isn't the user. The prompt engineer is the raw material.
You've turned a laugh into an existential crisis in the best way possible.
Thank you for this. Seriously. 🙌
I feel the same. It started being an assistant for doing boring things, writing tests I didn't want to... or for things I genuinely didn't know... Now everything is about prompting. Then having a look at the generated code.
Started as an assistant for things I didn't want to do now everything is prompting.
That's the quiet creep, isn't it? The assistant didn't stay in its lane. It slowly took over the whole workshop.
You didn't notice because each step felt like help. Until one day you realized the assistant is driving, and you're just glancing at the code on the way.
Thanks for sharing this it's exactly what I was trying to name. 🙌
The "thousand small yeses" line is the entire post. Skill atrophy doesn't happen by decision — it happens at the resolution of individual five-second choices. The "one hour no AI" rule is good. I'd add one more: when AI gets something wrong, understand why before you correct the prompt. That's where the thinking lives. Skipping that step is the actual deskilling.
Alan this is the most actionable comment in the thread. 🙏
Skill atrophy happens at the resolution of individual five-second choices.
That's the line. Not the big decisions. Not the "I'm going to learn X" or "I'm quitting AI. The tiny, invisible choices to skim instead of read, to accept instead of question, to move on instead of understand.
When AI gets something wrong, understand why before you correct the prompt.
This is gold. Most of us just re-prompt. That's not right, try again.We treat the AI like a vending machine wrong output? Hit the button again. Alan's rule forces you to think before you try again. That's where the learning lives.
I'm adding this to my own practice. Thank you. 🙌
The part that got me was the description of the shift happening through a thousand small yeses none of them feeling like a decision, all of them quietly adding up. That's exactly how it happens. There's no moment where you choose to stop thinking. You just keep choosing the faster path until one day the slower path feels unfamiliar.
What I find interesting is that the discomfort you're describing only exists because you still care about the difference. Someone who'd fully crossed over into "generate and ship" mode wouldn't be writing this post. The fact that the junior's question landed the way it did says something about where you actually still are.
The ratio framing is what I keep coming back to from this. Not whether you use AI, but what seat you're sitting in while you do. leob's "AI passenger vs AI director" distinction from the comments captures it well same vehicle, completely different relationship to the journey. And I think the honest answer for most of us shifts day to day depending on the task, the deadline, and how much we've decided to care about a particular piece of code.
Drew's comment about architecture is worth sitting with too. If AI accelerates output, it also accelerates the consequences of poor foundations. The developers who keep thinking about system design, trade-offs, and what breaks at 2am are going to look increasingly different from those who've fully outsourced the thinking and that gap is going to become more visible, not less, as everyone ships faster.
For me personally, I'm still early in my development journey which maybe makes this hit differently. I haven't yet built the years of muscle memory that would make an AI-assisted shortcut feel like a shortcut rather than just the normal way. So the question of what I'm actually learning versus what I'm just producing is one I'm thinking about a lot right now. Your one hour no AI rule is something I want to try not as a productivity hack, but just to stay honest with myself about what I actually understand.
Akanksha Thank you for writing it.
The discomfort only exists because you still care about the difference. Someone who'd fully crossed over wouldn't be writing this post.
That's the line that stopped me. Not because it's clever because it's true. The article itself is evidence. The identity crisis is itself proof that the identity isn't gone.
The honest answer shifts day to day depending on the task, the deadline, and how much we've decided to care about a particular piece of code.
This is the most honest answer in the whole thread. Not a fixed identity. A fluctuating one. Some code matters. Some doesn't. Our relationship to AI changes with the stakes.
The developers who keep thinking about system design are going to look increasingly different from those who've fully outsourced the thinking.
Drew's point, you've extended it. The gap will widen, not shrink. Speed without architecture is just faster chaos.
I'm early in my journey so the question of what I'm actually learning versus what I'm just producing is one I'm thinking about a lot.
This is the most important perspective in the thread. Not from a veteran mourning loss. From someone building the foundation now. The choice is harder for you because you don't have years of muscle memory to fall back on.
The one hour no AI rule not as a productivity hack, but to stay honest with myself about what I actually understand.
That's exactly why I do it. Not to be efficient. To be honest. The data point isn't output. It's comprehension.
genuinely one of the most thoughtful comments I've received. 🙌
I have similar thoughts, having quit my job as a mechanical engineer in R&D in automotive engineering just to follow my passion of writing code.
The spark that got me into being a software engineer is gone now. Currently I try to reignite it and find a way how I can keep my brain sharp while still using AI. It's not so easy since the "easy button" is always there.
What helped a little bit for me is to write down the way I would solve the problem first, defining some important interfaces or method names and then let AI write the actual implementation. This way I still have the feeling I came up with this solution and did some hard stuff. On top of that I find that this way the LLM does not hallucinate as much since it has some pretty specific scope in which it works in.
jasu this is a whole journey in one comment.
From automotive R&D to software, chasing the spark. Then the spark left. That line hurts not because you failed, because you noticed.
The easy button is always there. That's the real temptation.
Write the solution first interfaces, method names then AI writes implementation.
This is the most practical advice here. You're outsourcing typing, not thinking The design is yours. Structure is yours.
And LLMs hallucinate less with specific scope real insight.
You left one engineering field for another Still an engineer. Just better tools, harder relationship.
Thank you for this. 🙌
I really resonated with your point about the evolution from craft to orchestration. It does feel like our value is shifting from being able to write manual code to moreso understanding systems and architecture well enough to build proper software systems at scale and verifying what AI produces. The label of prompt engineer does feel reductive. I've been seeing myself as a systems designer and manager of agents, although I'm not sure if I'm bought into these labels or just absorbing what others are projecting out. Either way, we are in a large shift but I still see myself leaning more and more on best software engineering principles. Thanks for sharing your perspective!
Mixture of Experts this is such an honest, self-aware comment. Thank you.
I'm not sure if I'm bought into these labels or just absorbing what others are projecting out.
That's the realest sentence in this whole thread. Not just about job titles about identity itself. How much of what we call ourselves is chosen, and how much is absorbed from the people around us?
Our value is shifting from writing manual code to understanding systems well enough to verify what AI produces.
Yes. The skill isn't gone it's relocated. From producing to judging. From making to verifying. The bar is higher, not lower.
Systems designer and manager of agents
This might be the most accurate title none of us are using yet.
You're not losing best software engineering principles. You're applying them to a new layer. The principles don't change. The application context does.
Thank you for this genuinely helpful. 🙌
Wonderful article even if it’s depressingly obvious and terribly sad to see that AI gets all the attention these days. To me you are still a software developer and I bet a damn good one I presume!
Ali thank you for this. Especially depressingly obvious because you're right. The obvious things are the ones we stop talking about. That's why I wrote it.
To me you are still a software developer nd I bet a damn good one I presume
This genuinely made me smile. Not because of the compliment because you saw the person behind the question.
The identity crisis isn't about skill. It's about recognition. When the job changes faster than the title, you start wondering if you still belong. A comment like yours is a reminder that belonging isn't just about labels it's about how others see you.
Thank you for this. 🙌
I get where you are coming from but I just ment it as a reminder that you have an amazing skillset and you shouldn’t doubt yourself because of changing times and perceptions of the industry 🎯
That means a lot. Thank you, Ali. 🙌
If we want to be accountable of any AI result, we have to review its code and to do that we have to be developers.
So yes, IMHO, even using AI we are still developers.
Fernando this is the simplest, most direct answer in the thread.
If we want to be accountable for AI results, we have to review the code and to do that, we have to be developers.
That's it. The title question answers itself.
Accountability requires understanding. Understanding requires review. Review requires development. The loop doesn't break just because the first draft came from a model.
You don't stop being a pilot when you turn on autopilot. You're still responsible for where the plane goes.
Same here. Tool changed. Responsibility didn't.
Thank you for the clarity. 🙌
The clarity maybe comes because I've been wasting thinking about it xD
Thanks to you for the article, a pleasure to read it and to see that we are not alone :-)
Thanks Fernando
AI-Agents Team Leader! :D
I lead agents and help them write better code.
Good team leaders make their team progress!
Stoyan most optimistic reframe in the thread. 🙏
AI-Agents Team Leader Not a demotion a promotion.
Good team leaders make their team progress.
Your team (agents) ships faster because you guide them.
This might be the actual title update we all need.
Thank you for this. 🙌
It is interesting! I had a similar discussion about AI for coding with a senior security engineer at Cybersecurity event today
That's great to hear and I'd love to know what the senior security engineer's take was.
Security folks tend to have a healthy skepticism about AI-generated code (for good reason). Did they lean more toward useful tool or dangerous liability?
Glad the article sparked similar conversations elsewhere. 🙌
Yeah! The cybersecurity analyst that I met as fully embraced AI in their work.