originally published on medium on january 27, 2026. revised in april 2026.
I remember when I first started hearing about programming. there was this almost mythical figure called “the programmer” — someone who mastered the company’s language and solved anything that involved computers. but what a lot of people don’t know is that, before that, the word “computer” didn’t even refer to a machine. it was a job title.
how we got here
back in the day, “computer” was the job title for people who did extremely complex math by hand. they worked with tables, slide rules, and a lot of patience.
when the first electronic computers were built, those people were the first to “program” them — they already understood the logic behind the calculations.
Margaret Hamilton, by the way, is the one who coined the term “software engineer” to describe her own work — which was, no big deal, writing the software that landed us on the moon.
the point here isn’t just historical. it’s that our profession has never been static. it adapts to what the tech allows, and sometimes that adaptation changes everything: what you do, how you do it, how you present yourself in the market.
in the 90s and early 2000s, the tech market worked differently. if you looked at job postings (there was even a classifieds section in the newspaper), you’d see “ASP.NET Developer”, “Java Programmer”, “PHP Analyst”, “Delphi Developer”. the language was the professional’s identity. made sense: frameworks were heavy, libraries were specific, switching stacks was almost starting from scratch. if you were a Java dev, you’d probably spend years in Java.
and it wasn’t just the code. it was the whole ecosystem — architecture, build, deployment, IDE. moving from Java to Ruby was almost a career change.
around the mid-2010s, job postings started asking for “backend developer” or “frontend developer” instead of a specific language. specialization was still a thing, but the axis shifted.
why? javascript exploded on the frontend with Angular, React and a dozen others (there was even one called Batman.js). the backend fragmented across Go, Node, Rust, Kotlin. and companies realized that a good backend dev who knew Java could learn Go in a few weeks — what mattered was understanding APIs, databases, concurrency, not the syntax.
the frontend, on the other hand, became a world of its own. making a pretty screen wasn’t enough anymore. it was state management, build tooling, componentization, automated testing, accessibility. legitimate specialization.
that’s when “full stack” became a trend. but let’s be honest: most full stacks were (and still are) stronger on one side than the other. the title was more about getting by than mastering both worlds.
while backend and frontend were getting fluid, mobile held out. made sense: iOS and Android were (and still are) completely different ecosystems — Swift vs Kotlin, UIKit vs Jetpack Compose, App Store vs Play Store, distinct design guidelines. a senior iOS dev trying to build an Android app from scratch would struggle. not out of incompetence, but because years of platform-specific knowledge don’t transfer.
there were cross-platform options like React Native and Flutter, sure. but with trade-offs. critical apps were usually still native. that’s why “iOS Dev” and “Android Dev” held onto the most language-specific job title for the longest time.
what ai changes
then we got to 2024, 2025.
Dario Amodei, CEO of Anthropic, mentioned recently that the vast majority of the code at the company is already AI-generated. it’s not marketing hype — I see it happening.
a backend dev who’s never touched React builds a working interface in hours with AI help. a frontend dev who doesn’t know Kubernetes sets up a basic deployment following suggestions. a web engineer prototypes a mobile app in Flutter without ever having studied Dart.
the generated code isn’t perfect. but it’s good enough to unblock the work. and in many contexts — startups, MVPs, internal projects — good enough is all you need.
there’s a point here that bothers me, but I have to be honest: even deep review of AI-generated code is starting to get questioned. the argument goes: if the AI writes code that works, passes tests, and solves the problem, is it worth spending hours reviewing line by line? in small teams under delivery pressure, the practical answer has been “no, it isn’t.”
that’s not necessarily good. unreviewed code accumulates tech debt, may have security issues, gets hard to maintain. but it’s the reality for a lot of teams today. and the trend is for AIs themselves to get better at that review, creating a loop where humans step into the line-by-line less and less.
where we’re going
I don’t think software engineers are going to be replaced. but the work is changing. if AI can write code, what’s left that’s uniquely human?
first, actually understanding the problem. AI generates code for whatever you ask. but asking for the right thing — understanding what the business needs, what the user wants, what the real technical constraints are — that’s still deeply human.
second, architectural decisions. which database? how to split the services? where to put the complexity? these are decisions with long-term consequences that take experience and judgment.
AI can suggest, but someone has to choose and own it.
third, critical review. even as line-by-line review shrinks, someone has to understand whether the solution makes sense in the bigger picture. whether it’ll have performance issues at scale. whether the approach is sustainable.
fourth, communicating and aligning. translating vague requirements into clear specs. negotiating scope. explaining trade-offs to non-technical stakeholders. that’s not going to AI anytime soon.
if I had to describe the profile that’s emerging, it’d be something like: someone who deeply understands systems (not a language), who knows how to use AI as leverage, who can move around any part of the stack when needed, but still has one area where they go deeper.
it’s almost a return to the generalist. but different. not the generalist who knows a little of everything superficially — someone with depth in one area and modern tooling to reach into the others.
for startups, this is gold. instead of hiring a frontend, a backend and a mobile dev, you hire one senior person who trusts their own capacity to unblock themselves. that person uses AI to write the CSS they don’t master, asks for help setting up CI/CD, prototypes the mobile app without native experience.
and if you’re getting into the field now, the advice is simple: don’t get too attached to a specific language or framework. learn the fundamentals — data structures, algorithms, architecture, networks, databases. that stuff transcends any tool. and learn to use AI well. not as a crutch, as an amplifier. understand what it generates, question it, iterate.
the skill of asking good questions of an AI (and critically evaluating the answers) is going to be as important as knowing how to code has been for the last 20 years.
looking back, the profession of “person who works with computing” has never stood still. human computers became language programmers. language programmers became stack devs. stack devs are becoming… what, exactly? “AI-assisted systems engineers”? “solution architects”? maybe product engineers?
maybe something that doesn’t have a name yet. the label matters less than the reality: the work is changing, and whoever adapts stays relevant.
one thing I’ve learned watching this whole story unfold: resisting change has never worked very well in this field. the folks who ignored the web, the folks who thought mobile was a fad — they all had to adapt eventually, just with more difficulty. AI is the next wave, and it’s already here. the question isn’t if you’ll use it, it’s how you’ll use it to do the work only you can still do.