Who Is Using AI to Change Software Development? AI Programming Is Giving Rise to a New Kind of Software Developer

Lars Jansen, a developer with more than 30 years of programming experience, posted on X with an observation: AI programming is giving rise to a new kind of software developer.

He is not referring to traditional programmers who are proficient in every framework specification, can write a compiler offhand, or have spent 15 years arguing over whether indentation should use tabs or spaces; still less is he referring to people who follow a tutorial to build a to-do list, click Accept all the way through, and then call themselves engineers. He is talking about another group: people who can clearly describe how a system should work, can test it, question the model, refuse to let something go when it seems wrong, and keep revising until the software is truly usable. Many of them would not previously even have called themselves programmers.

This post quickly attracted a large debate, along with many replies saying “this is me.” Jansen then combined his own programming experience and these replies into this long-form opinion piece. It is not a statistically representative industry survey, but an inquiry into a change that has already happened: when writing code by hand is no longer the hard threshold it once was, what counts as software development, and who has thereby gained the opportunity to enter software development?

Who Is Entering Software Development

The replies made Jansen notice that these people are not computer science students, nor newcomers trying to use AI to pass themselves off as senior engineers. They are domain experts who have long lived inside concrete problems: lawyers, designers, film professionals, e-commerce people, and business owners.

What they lacked in the past was usually not ideas, but the ability to turn ideas into software. People working in law firms may know their own workflows better than outside developers; people in construction know what information needs to be tracked across ten projects; warehouse managers know that an expensive old system may only need one more interface to save everyone half an hour a day; designers can also accurately describe how an image workflow should operate.

But knowing “what software I need” does not mean being able to build it. In the past, crossing that wall usually required programmers, a development team, and enough budget, or years spent learning programming oneself. No matter how deep the domain knowledge, without implementation ability, software could still remain only an idea.

AI is lowering that barrier. What respondents talked about was not just personal toys: some built internal systems for their own work, some replaced expensive software subscriptions with self-built tools, and some delivered full-stack systems without a traditional development background.

This is not the same as following a tutorial to build a to-do app. They may not be able to write every function generated by the model, or even be familiar with half the syntax of the language being used, but they clearly understand how the software should work. When the result is wrong, they can identify the problem, test the differences, revise repeatedly, and push the implementation step by step toward what is actually needed.

How They Steer the Model

Knowing how to use AI programming tools does not automatically make someone the new developer described by the author. The real dividing line is whether judgment remains with the person, or is handed over to the model along with everything else.

The first kind of person has AI build a feature, runs it once, sees that the happy path seems to work, and moves on. They do not know why the model chose that implementation, have not checked what assumptions are hidden in the code, and do not know what will happen outside the normal path. In reality, some people really do type “make me an app like Airbnb,” click Accept All 47 times in a row, see a login page appear locally, and feel they have already become software engineers.

The second kind of person may start from the same requirement, but the conversation that follows is completely different. They keep asking:

• What happens if the same request is sent twice?
• Why put this piece of state here?
• If the process crashes between two operations, how is the data recovered?
• I only asked to fix one problem, so why were three unrelated files changed?

They will also ask the model to write tests for failure paths, stop redoing parts that already work, inspect the existing implementation before making changes, and explain suspicious-looking decisions.

Take an inventory tool as an example. Checking only whether the form can be submitted verifies only the smoothest path. Someone who retains judgment will also check whether duplicate submissions cause duplicate stock entries, whether recovery is possible if the process is interrupted between an inventory update and an operation record, how simultaneous inventory changes by multiple people are handled, and whether these failure cases have test coverage.

Both kinds of people use AI to write code, but they are not doing work at the same level. The former outsources technical judgment to the model; the latter treats the model as an implementation tool while taking responsibility for direction, questioning, testing, and final acceptance. Whether one can personally write all the code is no longer the only dividing line; whether one can notice that the implementation has gone off track is the more crucial difference.

This is also why “Vibe Coding” is losing its power to distinguish. The term is used both for senior developers who use Claude or Codex all day, and for beginners who do not understand databases and merely keep accepting model output, and also for non-programmers who seriously test their own tools. Putting all three groups under the same label does not help us judge what abilities they actually have.

Some argue that this ability is actually the work of a technical product manager or architect: defining behavior, understanding users, testing results, and discovering boundary problems. This judgment is partly right, but it misses the final layer in the old process. After a traditional product manager hands requirements to an engineering team, someone still has to turn them into running software; now, the same person who understands the product and the business may use natural language to orchestrate the implementation layer and complete the loop from requirement to deployment themselves. The label is not the point; the newly added delivery capability is.

Why Veteran Programmers Still Matter

Keeping judgment in one's own hands does not mean one already has all the experience required for a production environment. The doubts raised by senior developers are not unfounded, because real software engineering is far more than making the happy path run locally.

Security, maintainability, authentication, race conditions, retries, database indexes, rate limiting, background jobs, CI/CD, and deployment are all hidden where screenshots of the interface cannot show. What happens when the database goes down? What happens when two users perform the same operation at the same time? If the model writes code that looks reasonable on the surface but actually contains a dangerous error, can the user recognize it?

Jansen has written code for more than 30 years, and he does not think software has suddenly become simple just because a model can easily generate 500 lines of Go. AI lets people make more software faster, and it also lets people make more bad software faster. This is not a reason to oppose AI, but it is a real cost that cannot be ignored.

More difficult problems usually appear in the second version. After the first version has been running for two years, the code may have been modified 400 times; new requirements begin to conflict with old assumptions; the system needs to migrate millions of rows of data; a dependency library stops being maintained; a new model may even suggest tearing down the design recommended by the previous model.

Software accumulates history, and a great deal of complexity is generated by that history. Modifying a live system without breaking the 15 features people already depend on is far harder than building a new application on a blank sheet. Senior engineers have seen how these problems happen, know why some seemingly clumsy conventions exist, and know that one innocent change can ruin someone's weekend. That kind of judgment, forged by production incidents, cannot be obtained from a prompt alone.

Which Kinds of Software They Change First

To understand what this group will change, one must first distinguish the risks of software. If one imagines them replacing a senior team and maintaining a bank's transaction system that has been running for 18 years, then of course that is unrealistic. Finance, healthcare, infrastructure, security-sensitive systems, and large distributed applications can harm users or cause enormous losses if something goes wrong, and deep technical understanding is not optional there.

But a great deal of software is not a payment network, Netflix, or an aircraft control system. It is forms, databases, workflows, reports, CRUD, APIs, notifications, business rules, and scheduled tasks. For this ordinary software, the key is not whether it meets the highest level of architectural standards, but whether it can reliably solve the problem it exists to solve.

What the new developers change first is the long-tail software that would previously never have been built because it was not economically worthwhile. The author gives a simple calculation: a professional team might quote $50,000 for a custom tool, but the problem is worth only $5,000 to the person who needs it. Under the old business logic, that project would not happen.

If the person who best understands the problem can make a good-enough version over a few weekends, the calculation changes. The original article lists a very broad range: internal tools, workflow applications, back-office systems, specialized calculators, inventory tools, WordPress utilities, data importers, reporting dashboards, vertical-industry systems, personal tools, community applications, small SaaS products, a family recipe system, a tracker in a workshop, and small applications that matter to only 300 people.

“A professional programmer could rewrite this in an hour” is not a strong rebuttal. Perhaps they really could, but in the past no one went and wrote it; now, the domain expert has built it.

Not all of this long-tail software will succeed. Some will be poor quality, some will be abandoned six weeks later, and some may accidentally expose a database to the internet. Making an application that “looks finished” is easier than understanding everything beneath it. But genuinely useful tools will also emerge, because sometimes the best software does not come from the person most familiar with the details of a programming language, but from the person who best understands the problem.

How They Learn Engineering in Practice

When domain experts begin building these tools themselves, the order in which programming is learned may also change.

The traditional path is usually to learn variables, functions, loops, data structures, a language, and a framework first, and only then gradually move into larger projects and encounter architecture problems. AI makes another path possible: build the application you truly care about first, and then learn whatever knowledge is needed to solve the problems the project encounters.

• You need to control who can access the system, so you learn authentication.
• You need to receive events from an external service, so you understand webhooks.
• The same thing was processed twice, so you learn idempotency.
• Data queries become slower and slower, so you study database indexes.
• Two operations update the same state at the same time, so you understand race conditions.
• The process crashes midway through an operation, so you start considering recovery mechanisms.

These concepts are no longer textbook chapters for “maybe useful someday,” but concrete reasons why the project in front of you cannot continue. Jansen says he learns better when he actually needs a piece of knowledge, and some replies describe similar experiences: learning architecture while building software by questioning the model, reading explanations, inspecting code, breaking the implementation, and then fixing it.

The danger is here too. AI can provide a working idempotent implementation while leaving the user without a real understanding of idempotency. If one merely keeps stacking implementations one does not understand, what one ends up responsible for may be a system that is nearly impossible to explain and maintain. Whether learning by building first can be an effective path depends on whether the user keeps asking, checking, and understanding, rather than merely accepting that the result temporarily runs.

What the New Entry Ticket Is

The changes above point to the same conclusion: AI has not removed technical thresholds, but it has changed where the minimum effective technical ability lies.

In the past, to turn an idea into software, one first needed to know how to write it. Now, some people can hand implementation to the model, but they still need to understand enough to do the following:

• Define the problem that truly needs solving, and break it into reasonable parts;
• Distinguish good implementations from ones that look normal but actually have problems;
• Design tests and check outcomes beyond the happy path;
• Keep the model within the boundaries of the existing system, and investigate suspicious code;
• Keep revising after the first approach is wrong, until the software is truly delivered.

The technical knowledge required to start building may be reduced, but technical judgment has become more important. Being able to complete and ship software was always an independent capability; many technically excellent people also have folders full of unfinished projects, and AI has not removed that final stretch for anyone.

Software development has always been raising the level of abstraction. Developers use frameworks instead of writing their own HTTP servers; they use PostgreSQL instead of implementing a database engine themselves; they consult Stack Overflow without losing their identity as developers. AI may simply be a larger step in the same direction, allowing people to touch through language the implementation layer that they once had to complete by hand.

So what AI creates is not a completely new kind of person. People with product intuition, domain knowledge, process understanding, logical thinking, and testing ability have always existed; what they lacked in the past was a channel to turn these abilities into code. Now they can enter through another door, question the model, verify the results, keep revising, and finally put a truly usable application on a server.