The New Era of Software Engineering

I'm Syed Ahmer Shah. I'm 19, I'm from Pakistan, and I'm still an undergraduate studying Software Engineering. I want to say that clearly before anything else, because I'm not writing this as some expert looking down from a mountain of experience. I'm writing this as someone who is in it right now, watching the ground shift under his own feet while still learning how to walk on it.

This is not a "10 years from now, robots will take your job" article. I don't know what happens in 10 years. Nobody does, not even the people running the biggest AI labs in the world, no matter how confident they sound on stage. What I do know is what happened to me in the last year, what I saw happen to a senior developer I worked under during my internship, and what I've watched happen across the entire industry I'm trying to build a career in. That's what I want to tell you about.

How It Used to Work

Before I get into AI, I want you to understand what software engineering actually was, because a lot of non-technical people imagine it as some kind of typing wizardry — fingers flying across a keyboard, green text on a black screen, hacker-movie stuff.

It was never that. Software engineering was closer to construction work, except the building was invisible.

You start with a problem. A bank wants an app so people can send money without visiting a branch. A restaurant wants a system to manage orders. A hospital wants patient records that don't get lost in a filing cabinet. The engineer's job was to take that vague human need and turn it into thousands, sometimes millions, of precise instructions that a machine could follow without ever getting confused, because machines don't tolerate confusion. A single misplaced comma could crash the entire system.

This meant a developer spent years learning the "grammar" of programming languages — Python, Java, JavaScript, C++ — the same way you'd spend years learning a foreign language before you could write a novel in it. Then on top of that grammar, you had to learn logic: how to break a huge problem into small enough pieces that a computer could handle each piece one at a time. Then you had to learn the tools around it — databases to store information, servers to run your program, version control so ten people could work on the same project without overwriting each other's work.

And then, once all of that was written, you had to test it, break it on purpose, find where it failed, and fix it. Debugging — hunting for the one wrong line in ten thousand — was often the most painful and most respected skill in the field. Senior engineers weren't senior because they typed fast. They were senior because they had, over years, built an instinct for where problems hide and how systems fail.

That was the job. Slow, deliberate, deeply manual. You earned your competence one bug, one late night, one confusing error message at a time. That was the world I entered when I chose this degree.

That world is not gone. But it is no longer the whole story.

Then the Machines Started Writing Code Too

Somewhere in the last two or three years, something changed that most people outside tech still haven't fully registered. AI coding tools stopped being toys that could autocomplete a line of code, and started becoming something closer to junior engineers you could actually talk to.

GitHub Copilot was one of the first tools that showed people this was even possible — it sat inside your code editor and suggested entire chunks of code as you typed, trained on an enormous amount of publicly written code. Then came tools like Cursor, which is basically an entire code editor rebuilt around AI from the ground up, letting you describe what you want in plain English and watch it write, edit, and restructure real files across a real project. Then Claude Code and OpenAI's Codex arrived, and these went even further — they don't just suggest code, they can plan a task, write across multiple files, run commands in a terminal, test what they built, notice their own mistakes, and fix them, almost like an actual teammate sitting next to you.

This is the part I need you to sit with for a second, especially if you're not from a tech background: these tools are no longer just "helping you type faster." They can take a task like "add a login page with email verification" and actually go do it — write the files, connect the pieces, and hand you something that mostly works, in minutes.

And the people who built this world are the ones telling us how far it's already gone. Google's CEO, Sundar Pichai, has said that well over 30% of the code at Google is now written by AI. Microsoft's CEO, Satya Nadella, has said something similar about his own company's codebase. Anthropic's CEO, Dario Amodei, predicted in early 2025 that the vast majority of code could be AI-written within a matter of months. Google's own AI leadership has talked about AI performing like a junior software engineer within a year. These aren't random influencers making noise for clicks. These are the people who literally run the companies building this technology, telling us — in public, on the record — that the ground has already moved. [1][2][3]

And then there's Ryan Dahl. If you're not from tech, that name might mean nothing to you, but in this industry it means a lot. Dahl created Node.js in 2009, a piece of technology that quietly powers a massive chunk of the modern internet — it's one of the reasons so many websites and apps you use every day even work. This isn't some junior developer with a hot take. This is one of the most respected engineers alive. And in early 2026, he posted something that spread across the entire developer world within hours: that the era of humans writing code by hand, line by line, is effectively over. He was careful to say this doesn't mean engineers have nothing left to do — but that the "writing syntax word by word" part of the job, the part most of us spent years training for, is no longer where the real work lives. [4][5]

When I read that, sitting in my hostel room in Pakistan, I felt something between excitement and a small, quiet panic. Because I knew exactly what he was talking about. I had already started feeling it myself.

My Own Trap

I want to be completely honest here, because I think this is the part that actually matters for anyone reading this who is learning to code right now, anywhere in the world.

When these tools got good, I got lazy. Not lazy in the sense of not working — I was working all the time, shipping code, finishing assignments, building projects fast. But lazy in a much more dangerous way. I would open an AI tool, describe what I wanted, and let it write the whole thing. It worked. It ran. I moved to the next task. I didn't read the code line by line. I didn't ask myself why a particular function was structured that way, or what a specific keyword was actually doing under the hood, or why the AI chose this approach over another one that might have existed.

For a while, this felt like progress. I was building things faster than my classmates. I was getting things done. But somewhere in the back of my mind, a quiet alarm kept going off. If someone asked me to explain the code I had just "written," could I actually explain it? Sometimes I could. But more and more often, the honest answer was no. I would stare at my own project and realize I understood what it did, but not how or why, not really — because I hadn't done the thinking. The AI had done the thinking. I had just done the asking and the copying.

That is a terrifying place to be as an engineer. Because the moment something breaks in a way the AI can't fix — and it will happen, because AI still makes confident mistakes, still misunderstands context, still writes code that looks correct but hides a subtle flaw — you're stuck. You don't have the foundation to even know where to start looking. I remember one specific night where a project I'd mostly "AI-built" broke in production-like conditions, and I sat there for almost two hours completely lost, not because the problem was that hard, but because I had never built the muscle to think through it myself. I had outsourced the muscle before I'd even built it.

That night was my turning point. I understood, very clearly, that if I kept going like this, I wasn't becoming a software engineer who uses AI. I was becoming a person who prompts AI and hopes for the best. And those are not the same thing, even if they can look identical from the outside for a while.

So I changed how I worked, deliberately and stubbornly. Now, before I let an AI tool write a single line for me, I make it explain itself first. What is it about to do? How is it planning to do it? Why this approach and not another? I go through this with it — sometimes it takes thirty, forty minutes before any actual code gets written — until I genuinely understand the plan well enough that I could, in theory, write it myself, just slower. Only then do I let the AI generate the code, and even then, I read every part of it like I'm grading someone else's homework, because in a sense, I am. It's slower. It's less flashy. But I walk away from every session actually knowing something I didn't know before, instead of just having a folder full of code I can't defend.

What I Saw During My Internship

This brings me to something that crystallized all of this for me — my internship at a software house called XCL.

There was a senior Laravel developer there, someone with real years of experience, working on a genuinely large, complicated codebase — the kind of project with so many moving parts that a beginner would get lost just trying to find where one feature lived. One day I asked him if he could walk me through how he actually works now, day to day. He said sure, and showed me.

What I watched was, honestly, a little surreal. He used Cursor almost constantly to write the actual code — describing what he needed, letting it generate large sections, adjusting as he went. Then, once a chunk of work was done, he would switch over to Claude specifically to review it — hunting for bugs, logic errors, things that didn't quite fit the rest of the system. He told me straightforwardly: this is what works for him now. Write with one tool, review with another, move fast, ship fast.

I remember standing there thinking two things at the same time, almost fighting each other in my head. The first was pure amazement — this man was moving through a massive codebase at a speed that would have taken a team of people years earlier. The second feeling was something closer to dread. Because if this is how a senior engineer with real, hard-earned experience works now — AI writes, AI reviews, AI fixes — then what exactly is left for someone like me, who's still learning, still building that foundation? Are we all just going to become prompt engineers, typing instructions into a box and hoping the box understands us well enough?

I sat with that question for a long time. I still don't have a perfect answer. But I've come to believe something, and I want to explain why.

Will Engineers Be Replaced?

Here's what I actually think, based on what I've read, what I've watched with my own eyes, and what I've lived through myself: software engineers are not being replaced. But the way we work is already changing, and it started changing a while ago, not in some far future.

Think about it like this. When calculators became common, accountants didn't disappear — but an accountant who could only add and subtract by hand, with nothing else to offer, became far less valuable than one who understood what the numbers actually meant for a business. The tool didn't remove the need for judgment. It removed the need for manual labor that judgment used to require. Something similar, but far more dramatic, is happening in software.

The parts of the job that were pure manual labor — typing out boilerplate code, remembering exact syntax, writing repetitive functions that follow known patterns — are being absorbed by AI, and honestly, good riddance to some of it. What's rising in value instead is exactly what AI still can't reliably do on its own: understanding what a business or a person actually needs and translating vague, messy human wants into a real system; making architectural decisions about how a large system should be structured so it doesn't collapse under its own weight two years later; knowing when the AI-generated solution is subtly wrong even when it looks perfectly fine on the surface; and taking responsibility when something breaks, because AI cannot be held accountable — you can.

Ryan Dahl himself made this same point when his statement went viral — he wasn't saying engineers are finished, he was saying the part of the job tied to typing syntax by hand is finished, and what remains is design thinking, decision-making, and reviewing and steering what the machine produces. That distinction matters enormously. [5][6]

So here's the honest, unglamorous truth I've landed on, and I say this as someone still figuring it out, not as someone who has it all solved: AI will not replace the engineer. But it will absolutely replace two specific kinds of people. First, it will replace the engineer who refuses to touch it at all, who insists on doing everything the old manual way out of pride or fear, because they will simply be too slow compared to everyone else in the industry. And second — and this is the one that scares me more, because I almost became this person — it will replace the engineer who depends on it completely, who never builds real understanding, who can prompt but can't think, and who becomes helpless the moment the AI gets something wrong, which it still does, regularly.

The survivors, I think, will be the people in the middle. People who use AI aggressively, without guilt, because refusing to use a tool this powerful would be its own kind of foolishness. But people who never let it replace the actual understanding in their own heads — who still ask why, who still read the code line by line, who still know enough to catch the AI when it confidently walks off a cliff.

What I'm Telling Myself, and Maybe You Too

I don't know exactly what software engineering will look like in five years. I don't think anyone genuinely does, no matter how certain they sound in interviews or on X. But I know what I'm choosing to do with my own hands, right now, at 19, while I still have time to build the right habits before they calcify into bad ones.

I use AI every single day. I'm not going to pretend otherwise, and I don't think anyone in this field honestly can anymore. But I use it after I understand the plan, not instead of understanding it. I let it write the boring parts fast, so I have more time to think about the parts that actually require thinking. And when something feels like magic — when the AI produces something that just works and I don't quite know why — I stop and I dig until I do know why, even if it costs me an extra half hour I didn't plan for.

That senior developer at XCL wasn't wrong to work the way he does. He's fast, he's effective, and he ships real, working software for real clients. But he got to that speed after years of understanding what "good code" even means, after years of debugging things by hand, after building the judgment that now lets him trust and check an AI's work in seconds instead of hours. I think that's the actual lesson hiding underneath all of this. The tools have changed. The starting point has not. You still have to understand before you can supervise. You just get to supervise something a lot faster and more capable than yourself, if you've earned the right to.

We're not becoming obsolete. We're becoming something else — something that doesn't fully have a name yet. Call it what you want. I just know I'd rather walk into that future understanding every step I take, even if it's slower, than sprint into it blind and find out too late that I never actually learned to walk on my own.

References

1. Reuters/company statements on AI-generated code at Google and Microsoft, as reported via CEO remarks from Sundar Pichai and Satya Nadella (2025).

2. Dario Amodei, Anthropic CEO, public remarks on projected AI coding capability, March 2025.

3. Jeff Dean, Google AI leadership, public remarks on AI performing at a junior-engineer level, May 2025.

4. Ryan Dahl (creator of Node.js and Deno), public post on X, January 2026 — reported by OfficeChai, "Era Of Humans Writing Code Is Over: Node.js Creator Ryan Dahl," https://officechai.com/ai/era-of-humans-writing-code-is-over-node-js-creator-ryan-dahl/

5. Reading.sh, "The creator of Node.js says the era of writing code is over," https://reading.sh/the-creator-of-node-js-says-the-era-of-writing-code-is-over-8320c868043b

6. EducationPost, "Era of humans writing code is over, says NodeJS creator Ryan Dahl," https://educationpost.in/news/technology/era-of-humans-writing-code-is-over-says-nodejs-creator-ryan-dahl

Tools referenced: GitHub Copilot (GitHub/Microsoft), Cursor (Anysphere), Claude Code (Anthropic), OpenAI Codex (OpenAI).

Find me across the web:

• Portfolio: ahmershah.dev

• Crunchbase: @syed-ahmer-shah

• Crunchbase Company: @syedahmershah

• Clutch: @syed-ahmer-shah

• Tech Behemoth: @syed-ahmer-shah

• Design Rush: @syed-ahmer-shah

• Edverise: @syed-ahmer-shah

• Trust Pilot: @ahmershah.dev

• LinkedIn: Syed Ahmer Shah

• GitHub: @ahmershahdev

• AWS Builder Profile: @syedahmershah

• DEV: @syedahmershah

• Medium: @syedahmershah

• Hashnode: @syedahmershah

• Substack: @syedahmershah

• HackerNoon: @syedahmershah

• Substack: @syedahmershah

• Facebook: @ahmershahdev

• Linkedin Page: @syedahmershah

• YouTube: @ahmershahdev

• Instagram: @ahmershahdev

• TikTok: @ahmershahdev