Did AI Create a New Kind of Software Developer?

Question: Did AI coding create a new kind of software developer?

I think it did, although not because AI suddenly turned everyone into a programmer. What changed is the implementation barrier: people who already understand a problem, can describe a system, test it, question bad decisions, and keep iterating can now turn that knowledge into working software without first spending years learning to write every line themselves. Technical skill still matters, especially once software becomes important, complicated, or dangerous, but knowing how to manually implement everything is becoming less of a prerequisite for starting.

I put a version of this argument on X recently, and it took off far more than I expected. The line that probably helped pour petrol on it was my suggestion that this new kind of builder seems to be annoying the hell out of quite a few pre-AI programmers. 😅 Predictably, there were plenty of arguments about whether these people should be allowed anywhere near the word developer, but once you got past the dunks and insults, the replies were much more interesting than the terminology fight.

I don’t think the important question is whether AI can write code anymore. We’ve mostly moved past that, and the more interesting question is what counts as software development when physically writing the code is no longer the hard gate it used to be. That’s where I think something genuinely new is happening.

A lot of people replied with some version of “this is me”

One of the biggest surprises was how many people recognised themselves in what I’d described. They weren’t all junior developers or computer science students trying to skip the learning process; there were lawyers, designers, filmmakers, e-commerce people, business owners, and people from all sorts of specialist professions.

What they had in common was domain knowledge. They understood a particular problem extremely well because they’d spent years living with it, but until recently they had no realistic way to turn that knowledge into software. People talked about building internal systems for their businesses, replacing expensive subscriptions with tools they’d made themselves, and creating complete applications despite having no traditional software development background.

Quite a few responses were essentially some variation of “I’ve been trying to explain what I am, and this is it.” That got my attention because if this were just people making to-do apps from tutorials, I wouldn’t find it especially interesting; we’ve had low-code and no-code tools for years.

What these people were describing was different. They know what problem they want solved, they can describe the behaviour they need, and they can look at what the AI produces and say, “No, that’s not right.” They test it, spot inconsistencies, change requirements, and keep pushing until the software behaves the way they want.

They might not know how to manually write every function the model produces, and they might not know all the syntax of the language the finished application uses. But they understand what the system is supposed to do, and increasingly that’s enough to get started. If you’re coming into this without a traditional programming background, I’ve already written more practical guidance on vibe coding for non-programmers; the point isn’t that understanding no longer matters, but that the path towards understanding is changing.

Before AI, implementation ability was the gate

There have always been people with excellent software ideas who couldn’t build software. Someone working inside a legal practice might understand its workflow better than any developer ever will, a builder might know exactly what information needs to be tracked across ten jobs, and a warehouse manager might know the expensive system everyone uses is missing one tiny screen that would save half an hour every morning.

A designer might be able to describe an image workflow in perfect detail, but historically there was still a hard wall between “I know exactly what software I need” and “I can create that software.” Usually another person had to sit in the middle, which meant you needed a programmer, a development team, enough money to hire one, or enough spare time and motivation to learn programming yourself.

AI hasn’t given people better ideas, product judgement, domain expertise, or taste. What it’s done is make implementation ability less of a prerequisite for turning those things into working software, and that’s a much bigger change than “ChatGPT can write Python now.”

It’s also why I don’t think this conversation should be reduced to whether somebody technically qualifies as a programmer. Programming and software development have always overlapped, but they aren’t exactly the same thing, and AI is making that distinction much harder to ignore.

There is a massive difference between steering the model and being steered by it

This is probably the most important distinction in the whole argument. Imagine two people using exactly the same AI coding tool: the first asks it to build a feature, runs what it produces, sees that the happy path works, and moves on without really knowing why the model made the choices it made.

The second person starts with the same request, but then the conversation changes. They ask what happens if the request arrives twice, why a particular piece of state is being stored there, what happens if the process crashes halfway through, why three unrelated files changed, what happens when two users do the same thing at once, and where the input is being validated.

They tell the model to write tests for the failure path, stop redesigning something that already works, and inspect the current implementation before making changes. When something looks suspicious, they investigate rather than assuming the machine knows better.

Both people are technically “AI coding”, but they’re not doing remotely the same job. One is effectively outsourcing judgement to the model, while the other is using the model as an implementation tool. That’s the distinction I’ve tried to make before in Vibe Coding Is Useful, But You Still Have to Be the Builder.

The interesting part is that the person in charge doesn’t necessarily need to know how to manually write the final implementation. They need enough understanding to direct it, question it, test it, and recognise when something has gone sideways, which is a different skill set from traditional programming. It overlaps with programming, architecture, QA, systems analysis, and product management, but none of those labels fits perfectly.

The programmers pushing back aren’t completely wrong

A lot of experienced developers absolutely hated the original argument. Some said that anyone capable of properly describing and testing a software system already understands software, so calling this a new kind of developer doesn’t mean much, while others went straight to the weaknesses of AI-assisted development.

Security came up constantly, along with authentication, race conditions, retries, indexes, rate limits, background jobs, deployment, CI/CD, database design, and everything else sitting underneath an application. The obvious questions are fair ones: what happens when the database falls over, when two users update the same thing, or when the model produces something that looks completely reasonable but is subtly wrong?

I’ve been writing code for over 30 years, and I’m not going to pretend software suddenly became easy because an LLM can produce 500 lines of Go without complaining. Production software is full of ugly details that don’t appear in the screenshot, and you can build an application that appears to work while being a complete disaster underneath. Humans have been managing that perfectly well for decades too. 😂

AI makes it easier to create more software faster, so naturally it also makes it easier to create more bad software faster. That’s real, and there are absolutely people typing “build me an app like Airbnb”, clicking Accept All 47 times, seeing a login page on localhost, and deciding they’re now software engineers.

That’s not the person I’m talking about, and treating every AI-assisted builder as that person makes the discussion less useful. If you’re actually putting an AI-built application in front of users, the checks still matter, which is why I’ve got a separate security checklist for vibe-coded websites covering authentication, permissions, secrets, input handling, and the other things a pretty interface doesn’t prove are correct.

“They’re just product managers”

This was one of the better objections because several people pointed out that what I described sounds suspiciously like a good technical product manager. Describe the system, define the behaviour, understand the user, test the result, push back when implementation is wrong, and keep iterating until the product works: that’s a large chunk of it.

Other people said it’s architecture rather than development, and one reply basically argued that AI hasn’t created a new kind of developer; it’s forced developers to become architects. There’s something to that too, but there’s one important difference in how the work can now finish.

Historically, the product manager didn’t finish the software. They could write perfect requirements, understand the users, and catch every edge case, but eventually someone still had to turn those decisions into running code, so there was an implementation layer between the person who understood the product and the finished application.

That same person can now potentially do both sides. They haven’t suddenly learned JavaScript overnight, but implementation has become something they can increasingly interact with through language, and a product manager who can define a system and then actually produce, test, and deploy the finished application is a different creature from one handing tickets to an engineering team.

Whether we eventually call that person a developer, builder, AI engineer, technical product builder, vibe coder, or something else doesn’t matter very much to me. The label is the least interesting part; the capability is what matters.

“Vibe coder” is already becoming a fairly useless term

This terminology problem isn’t helped by the way vibe coding has expanded to mean almost anything involving AI and code. I’ve seen experienced developers who use Claude or Codex all day called vibe coders, and I’ve also seen people who don’t know what a database is called vibe coders, even though those aren’t remotely the same thing.

At this point the term can describe an experienced engineer using AI aggressively, a non-programmer carefully building and testing a useful application, or somebody clicking Accept All until the errors disappear. That’s far too broad to tell us much, and the same problem applies when discussing AI coding tools generally.

They’re tools, not a skill level. I’ve written separately about what AI coding tools are actually good for, but two people can use exactly the same tool with wildly different levels of judgement. I suspect we’ll eventually develop better language for this because there clearly seems to be a group emerging somewhere between the traditional developer and the non-technical software user.

The kind of software matters

Another reason the argument became heated was that everyone was imagining different software. If you read my original post and picture a non-programmer replacing the senior engineering team maintaining an 18-year-old banking system, then yes, the idea sounds ridiculous.

That’s not where I think the biggest change is happening. It’s happening in the enormous amount of software that previously never got built: internal tools, workflow applications, admin systems, specialist calculators, inventory tools, WordPress utilities, data importers, reporting dashboards, niche business systems, personal tools, community applications, and tiny SaaS products.

It also includes a family recipe system, a tracker somebody needs in their workshop, or some strange little application that makes perfect sense to 300 people and absolutely no sense to everyone else. There’s a huge category of useful software that historically wasn’t economically worth building because a professional development team might quote $50,000 for something solving a $5,000 problem.

When the person with the problem can make a good-enough version themselves over a few weekends, the economics change completely. A project that made no commercial sense can make perfect sense personally or inside one business, which is also why “a real programmer could rebuild that in an hour” isn’t much of a counterargument. Maybe they could, but they didn’t; the domain expert did.

We may get a lot more extremely specific software

Software development has always had an economic filter because building software costs money and time, so ideas have to clear a certain bar before anybody bothers. There needs to be a large enough market, enough internal value, or someone willing to pay for development, and AI lowers that bar for some categories of software.

That probably means we’re going to see many more applications built for extremely specific problems. Some will be rubbish, some will be abandoned six weeks later, and some will accidentally expose their database to the internet because the barrier to making something that looks finished has dropped faster than the barrier to understanding everything underneath it.

That’s worth taking seriously, but some of this software will also be genuinely useful, particularly when it’s made by people with deep domain knowledge. The best software doesn’t always come from whoever knows the most programming trivia; sometimes it comes from the person who understands the problem better than anybody else.

Previously, that person still needed a programmer, while increasingly they might not need one on day one. This is one reason I like small applications so much: if you’re new to AI-assisted building, a small, private, low-risk tool is a much more sensible place to learn than trying to build the next Stripe, which is also the idea behind what I recommend non-programmers build first with vibe coding.

AI is changing the learning path too

This is one aspect I didn’t think about much until I read the replies. Traditionally, learning programming involved learning quite a lot before you could build anything substantial: variables, functions, loops, data structures, a language, a framework, and eventually the larger projects where architectural problems started appearing.

That’s obviously simplified, but the pattern was broadly “learn, learn, learn, eventually build.” AI can flip part of that around because someone can start with the application they actually care about and then let the project force them to learn things in context.

They add authentication, so they have a reason to learn about authentication. They need webhooks, so they find out what a webhook is; then the same event gets processed twice and suddenly they’re learning about idempotency. The application slows down, so indexes matter, and two requests update the same state, so race conditions stop being an abstract chapter in a book and become the reason the thing they built just broke.

Something crashes halfway through an operation, so now they’re thinking about recovery and transactions. The learning loop becomes “build, hit problem, learn, fix, build, hit next problem, learn,” and I learn much better when I actually need the thing I’m learning. I doubt I’m particularly unusual there.

There’s an obvious danger here too because AI can hide the very thing you should be learning. You can get a working implementation of idempotency without really understanding idempotency, and if you keep doing that, eventually you’re responsible for a system you understand almost none of.

The reverse can happen as well. You ask why the model made a particular choice, argue with it, inspect the code, break it, fix it, and eventually you’ve learned something because you had a real reason to. Several people replying to the original post described exactly that process: they’re learning software architecture by building software.

There’s still a line somewhere

None of this means everyone who ships an application should automatically be called a software engineer. Words still mean things, and engineering implies a level of understanding, rigour, and responsibility that “I made the button work” doesn’t necessarily satisfy.

There are also environments where deep technical understanding isn’t optional. Finance, healthcare, infrastructure, security-sensitive systems, large distributed applications, and anything where mistakes can seriously hurt people or cost enormous amounts of money are different from building a job tracker for your workshop.

You don’t want somebody discovering database transactions for the first time while implementing the system moving your pension around, and AI doesn’t change that. At the same time, I think developers sometimes apply the requirements of those systems to absolutely everything even though most software isn’t a payment network, isn’t Netflix, and isn’t controlling an aircraft.

A huge amount of software is forms, databases, workflows, reports, APIs, notifications, business rules, and scheduled jobs. “CRUD and vibes” can still be extremely useful software, and there are businesses running happily on PHP applications somebody wrote 15 years ago that would make a modern architecture astronaut physically ill.

The useful question isn’t whether the code makes a senior engineer feel spiritually fulfilled. It’s whether the software reliably solves the problem it exists to solve, and whether the level of engineering matches the consequences of getting it wrong.

Version 1 isn’t the difficult part forever

This is probably the strongest criticism experienced developers made because getting to version 1 is one thing, while living with version 27 is another. What happens two years later when the original AI-generated code has been changed 400 times, new requirements conflict with old assumptions, a library disappears, or today’s AI confidently recommends ripping out something last year’s AI confidently told you to build?

Those aren’t hypothetical problems because software accumulates history, and history creates a huge amount of software complexity. A clean-sheet application is easier than changing a live application without breaking fifteen things people already depend on, and AI hasn’t magically removed that problem even if it’s getting better at working with existing codebases.

This is where experienced developers still have an enormous advantage. They’ve watched systems fail, they know why some apparently stupid conventions exist, and they know an innocent-looking one-line change can ruin someone’s weekend. A lot of that knowledge comes from scars, and there’s no clever prompt that instantly gives somebody ten years of production experience.

This is also why understandable code matters. If AI helped you build an application but six months later neither you nor the model can work out why anything exists, you’ve created a different sort of problem, which I wrote about in How Do You Stop a Vibe Coded App Turning Into Mystery Code?.

The future isn’t “technical knowledge doesn’t matter.” If anything, technical judgement becomes more valuable, while the interesting change is that you may not need as much technical knowledge to start.

The minimum viable technical skill is moving

This is probably where I’ve landed after reading all the replies. AI hasn’t removed the need for technical skill; it’s changed where the minimum useful level sits.

Previously, there was a large practical requirement to know how to write the software. Increasingly, the requirement becomes understanding enough to direct, inspect, and verify the software, which is still knowledge but slightly different knowledge.

Can you define the problem clearly, break it into sensible pieces, tell good output from bad output, test the result properly, and recognise when the AI is making assumptions it shouldn’t? Can you keep it inside the boundaries of the existing system, understand enough architecture to ask sensible questions, read enough code to investigate something suspicious, and keep pushing when the first answer is wrong?

That’s a very different experience from blindly asking an AI to “make an app.” My own safer workflow is much closer to giving AI a constrained job, checking the result, and keeping control of what actually changes, which I described more concretely in the AI coding workflow I use on real projects.

There’s another skill that hasn’t changed either: can you actually finish? There have always been technically brilliant people with folders full of unfinished side projects, and being able to ship is still a skill.

Maybe AI didn’t create these people at all

This was probably my biggest takeaway from the response. Maybe AI hasn’t created an entirely new kind of person; maybe it exposed a group of people who were already capable of much more than the old software development process allowed them to do.

There have always been people with strong product instincts, deep domain knowledge, logical thinking, an understanding of workflows, good testing instincts, and the ability to describe what they want clearly. There have always been people obsessive enough to keep going until something works, but previously they were missing one extremely important ability: they couldn’t turn all of that into code.

Now, increasingly, they can. That’s why I think so many people recognised themselves in the original post: the capability was already there, while the implementation barrier moved.

When you look at it that way, I also understand why this can feel uncomfortable to some traditional developers. Programming ability used to be the admission ticket, and if you couldn’t code, then beyond a certain point you couldn’t participate.

Now that border is much fuzzier. Someone can come in through a completely different door, having never taken a computer science class and barely knowing the syntax of the language their application is written in, but still understanding the problem, the users, and what the product needs to do.

They can interrogate the AI, test what comes back, and keep iterating until eventually there’s a working application sitting on a server. I don’t think we’ve settled on what to call that person yet, but “not a developer because they didn’t physically type the code” feels increasingly difficult to defend.

We don’t say someone isn’t a developer because they used a framework instead of writing their own HTTP server, and we don’t disqualify them because they used PostgreSQL rather than implementing a database engine. Nobody stopped being a developer when Stack Overflow appeared, because software development has always moved up abstraction layers.

AI may simply be a very large jump in that same direction. The difference is that this jump is large enough to challenge some fairly deep assumptions about what the job actually is.

So, did AI create a new kind of software developer?

I think the answer is yes, with an important qualification. AI didn’t create the people; it gave a group of people who already had domain knowledge, product judgement, logical thinking, and persistence access to an implementation layer they previously couldn’t reach.

That doesn’t make every AI user a programmer, it doesn’t make senior developers obsolete, and it doesn’t make security, architecture, maintainability, or experience less important. It also definitely doesn’t mean every AI-generated application is good, because lowering the barrier to building software lowers the barrier to building bad software too.

What it means is that the gate moved. The minimum skill needed to start building software is lower, while the skill needed to build software that remains safe, understandable, and maintainable over time is still very real.

I suspect we’re only beginning to see what happens when a lot more people can cross that first barrier. Some of what they build will be awful, some will be weird, some will solve tiny problems no traditional software company would ever have bothered with, and some will be extremely useful precisely because the person building it understands the problem better than almost anybody else.

That’s the part I find interesting, rather than whether they’re allowed to call themselves developers. The important change is that they can build the thing at all.