I've been a professional front-end developer for almost six years, and I was playing with code before that. That isn't much next to the veterans with twenty years behind them, but it's been long enough to live through a few real shifts, and the pace has picked up sharply in the last couple of years, mostly because of AI.
This is where my thinking stands in September 2026. Some of it will probably look wrong in a year or two. I'd rather write it down now and update it later than wait until I'm sure.
When One Person Did Everything
Before 2017, before I became a professional developer, I explored web development as a hobbyist. The corner of the web I saw still ran on the old "web developer/designer" role: one person built everything.
You designed the whole site as one big image in Photoshop, sliced it into smaller images, and turned parts of them into links. FrontPage was part of the kit. Deploying meant dragging files into FileZilla or uploading them through cPanel. Docker and proper pipelines existed in bigger teams, but they hadn't reached the small sites I was tinkering with. In my world, "CI/CD" meant hitting upload and refreshing the browser.
Those years taught me to swing the hammer. I didn't know much about where to hit yet.
The jQuery Years
Front-end work was split into two worlds: WordPress sites and custom sites built on jQuery, which had a plugin for almost anything.
jQuery shaped what developers expected working with JavaScript and the DOM to feel like: short, readable code that behaved the same in every browser. ES6 (ES2015) was a different kind of leap. It modernized the language itself. I think of it as JavaScript's new suit, and it shaped how we write JavaScript today.
jQuery, to me, is like the manual car you learned to drive in. It got you everywhere you needed to go, and you have good memories with it. But at some point you move on to whatever fits the road you're on now.
Why We Moved to Frameworks
Web applications kept getting more demanding, and we needed reactivity out of the box. With jQuery, I lost hours figuring out what had changed the DOM, or what some snippet buried in a bloated function was actually doing.
Was that jQuery's fault? Partly. Developers and organizations share the blame, but jQuery gave us more freedom than was healthy. In an ideal world, every team would enforce good practices no matter what the tool allowed. We don't live in that world. Teams change, requirements evolve, and deadlines get tight.
Frameworks were an upgrade with trade-offs of their own. They brought reactivity, isolated UI in the form of components, and isolated logic (React Hooks came later; before them, React had mixins). When something changes in the UI, you know which component owns it.
Technically, frameworks didn't do anything you couldn't do with vanilla JavaScript or jQuery. But that undersells them. They changed how we think. Instead of telling the browser step by step how to update the page, you describe what the UI should look like for a given state, and the framework handles the rest. That shift let us build far more ambitious applications, and it taught me how to organize the work, not just do it.
Today frameworks are the standard, and developers have spent years arguing about which one is best. That argument will probably outlive all of us.
AI Arrives, and Code Stops Being the Bottleneck
When AI arrived, it felt like magic, with obvious weaknesses: early on, you could talk ChatGPT into agreeing with almost anything. Then autocomplete tools like GitHub Copilot gave way to agents. With MCP (Model Context Protocol), models could reach the outside world: query your database, read documentation, talk to other models, and test your application for you. Writing code by hand started to feel like a thing of the past, and many developers began to worry about their jobs.
Here's how I see it. For someone new, writing and debugging code is a huge part of the job and of the learning. You spend a lot of time figuring out why your own code doesn't work, and that struggle is how the skill gets built.
With experience, implementation often stops being the main bottleneck. It doesn't get easy, but more of the difficult work moves elsewhere: understanding the actual problem, choosing an architecture, weighing trade-offs, predicting consequences, debugging when nobody knows what's wrong, and knowing the business well enough to tell what matters.
Seniors still need deep technical skill. It's exactly what lets you look at an AI-generated solution and see that it's subtly wrong: it passes the happy path but breaks under a race condition, leaks memory, or ignores an edge case your users hit every day. Coding stays an important skill at every level. What changes is how much of your day it takes up.
$9,998 for Knowing Where to Hit
Early in my career, I heard a story I keep coming back to.
A huge cargo ship broke down. The owner brought in expert after expert, and nobody could fix it. Finally he called an old craftsman, who looked the ship over carefully, took out a hammer, and hit one spot. The engine started.
He charged $10,000. The owner felt cheated and asked for an itemized bill:
Hitting with the hammer: $2
Knowing where to hit: $9,998
AI is becoming extremely good with the hammer. It's getting good at suggesting where to hit, too. It can compare approaches and argue for one better than some people I've worked with. So what's left for us?
Context, judgment, verification, and accountability. AI doesn't know why your team rejected an approach last year, which feature your users quietly depend on, or what the business can afford to break this quarter, unless someone who knows tells it. It can suggest ten places to hit; knowing which one matters for this product, right now, is still our job. Without that, you fix things that didn't need fixing and walk right past the elephant in the room.
So AI should take part in decisions. But the engineer has to understand the decision, validate it, and own it. When something breaks in production, "the AI suggested it" isn't an answer anyone accepts.
That takes broad understanding of the product, the system, and the business. But breadth alone isn't enough. AI makes it easy to cross into parts of the stack you don't know well, which is great until the output looks perfectly plausible and is wrong in a way only deep expertise would catch. You need real depth in at least one area. Breadth lets you see the whole ship. Depth tells you when the AI is pointing at the wrong spot.
What That Looks Like in Practice
At Cura Healthcare, we needed a doctor app with the same functionality as our website. I designed the architecture: a Flutter app that serves the website's features through WebViews. I defined how the Flutter and WebView integration should work, specified the expected behavior of each feature, and owned the smoke and end-to-end testing. AI wrote all of the code essentially. The app has been in production for months.
The implementation still mattered; a production doctor app has real engineering in it. But AI made it dramatically cheaper, and that moved my effort: most of my judgment went into the architecture, the integration design, and the trade-offs that come with WebViews. AI didn't make the hammer worthless. It made swinging it cheap, and that made knowing where to hit the expensive part.
Cheap Experiments
AI doesn't only lower the cost of building. It lowers the cost of trying.
Teams used to skip testing an approach because a prototype would take days, so they argued in meetings instead. Now we can prototype two competing approaches, test an architecture before committing to it, or explore an unfamiliar technology with a working proof of concept, and reach a first release much faster. Instead of debating every option in theory, we can build a rough version, measure it, and decide. I think this is one of AI's biggest advantages, maybe bigger than raw coding speed.
The catch is the same one that runs through this whole post: a cheap experiment is only useful if someone can judge the result. Two prototypes built in an afternoon tell you nothing if nobody notices that one of them only works because it skips the hard part.
The Catch: Reviewing Is Hard Work
This model has a weak spot, and I'd rather name it than hide it.
Reviewing code is harder than writing it. When AI hands you a large diff, it's easy to skim it, see that it looks reasonable, and approve it. AI generates code far faster than anyone can properly review it, and after the tenth big change of the day, "looks fine" quietly becomes the default. That's review fatigue, and it's real. Owning the testing, as I did with the doctor app, helps: if you define what "working" means, you're not relying only on reading the code. But it doesn't replace understanding what you approve.
There's a deeper problem. Architecture judgment often comes from writing, debugging, and maintaining software. I know which designs fall apart because I've lived through the mess. I learned why frameworks matter by chasing DOM bugs in jQuery, not by reading about them. So if AI does more of the implementation, how will newer engineers build the experience they need to judge it? You need years of swinging the hammer before you get good at knowing where to hit.
Books help. They let you borrow experienced engineers' mistakes instead of making them all yourself. But reading about a production outage and causing one are different kinds of education.
The Hardest Part Is Getting In
My view comes from my own path: I built my judgment by writing code by hand for years. Juniors today don't get that path by default.
They're in a tough spot. There are fewer entry-level openings, and once they're in, AI can do many of the tasks that used to teach them. That's the paradox. Experienced developers can supervise AI partly because they learned through years of hands-on work, and AI may remove the very tasks through which the next generation would have gained that experience. Seniors reviewing AI's work only keeps working if new seniors keep appearing.
My advice: when you learn something, implement enough of it yourself to understand the mechanics. Make mistakes and debug them. Then build the same thing with AI and compare. You'll understand what it hands you, and you'll notice when it's wrong.
I still do this as a senior whenever I pick up something new, and only after that do I let AI speed me up. That doesn't mean avoiding AI while learning; it's a great tutor for getting you unstuck. The trap is on both sides: delegate everything and you never learn the mechanics, stay manual too long and you fall behind. I don't think anyone has fully figured out that balance.
Fewer People, Bigger Scope
Since my hobbyist days, the one-person web developer has split into UI/UX designers, product engineers, front-end and back-end developers, and DevOps engineers. Now the work is moving back into fewer hands. It's not the old role returning: the old web developer did everything because the web was simple. Today's developer can do more because AI covers ground that used to need a whole team.
My expectation is that companies will need fewer developers than they otherwise would have, because individual engineers and small teams will deliver much more. I can't prove it or say how large the effect will be, but AI has already shaken up hiring.
The fair counterargument is that cheaper software means companies build more of it. Some of that will happen, and I expect new roles and new kinds of work to form around AI, the way cloud computing created jobs that didn't exist before it. I just don't believe they'll offset the reduction one for one.
What I can already see is developers becoming builders who own a much bigger scope: the product, the architecture, and the delivery, not just the tickets. AI came with real merits and real costs, and pretending otherwise doesn't help anyone.
What We Lost
Coding has always been fun for me. There was a rush in writing something yourself, debugging it, and watching it finally work. You built it with your own hands. If you were as excited about it as I was, you felt like a magician.
Part of that joy is gone. Approving a clever piece of code that AI wrote isn't the same as writing it yourself after an hour of staring at the screen. I miss it sometimes. Holding onto the past won't bring it back, though.
Still, I'd be lying if I said I only felt the loss. Watching a whole product come together, one I shaped from the architecture down, faster than I ever could alone, is its own kind of fun, just not the kind I started with. Both feelings are true. The way we build has changed, and the reason I build hasn't.