What Is a Developer for Now?
For most of my career, writing software meant writing code. There were other responsibilities wrapped around it, but somebody had to sit at a keyboard and turn a requirement into C#, JavaScript, SQL, or whatever language happened to be involved. Now, generative AI can produce a lot of working code. Give it a reasonably well-defined problem and it will write classes, database queries, APIs, tests, configuration files, and user interfaces. It can explain an unfamiliar library, troubleshoot an error, and modify code somebody else wrote twenty years ago. It gets things wrong, but so do developers, and it is improving quickly. So if producing code keeps getting cheaper, what exactly is a developer for?
The Job Was Never Really Typing
The obvious answer is that developers are still needed because AI can’t do everything. That’s true, but it misses the more interesting point. Writing code was never the most important part of being a good developer, just the most visible part. The difficult work happened before and after the typing.
What is the user actually asking for? Does the requested solution solve the problem they really have? Where does the data come from? What other systems depend on it? What happens when the database is unavailable? Who should have access? What happens when someone enters something nobody expected? How will somebody support this thing three years from now, after everyone who built it has moved on?
AI can help answer those questions. But somebody still has to know which questions need to be asked.
Knowing What to Build
In the last post I talked about how cheap AI has made it to add another feature, another option, another test. The problem is that cheap to create doesn’t mean free to own. Somebody still has to maintain it, understand it, and get the call when it breaks.
Knowing when not to build something is one of the more valuable skills a developer can have. AI doesn’t know a theoretical failure condition has never occurred in twenty years of operating the plant. It doesn’t know accounting considers one obscure field absolutely critical even though it looks meaningless in the database, or that logistics quietly repurposed a field for their scheduling process.
Those distinctions take business knowledge, and that’s where I think developers may have to adjust how they think about the profession. Learning C# matters. Learning SQL matters. Data structures, APIs, networking, security, and application architecture all matter. But knowing the technology without understanding the business has always limited what a developer can accomplish, and AI makes that limitation more obvious. If I can describe a straightforward customer-entry screen and have AI generate most of it, knowing how to create the controls by hand is worth less than knowing what information actually belongs on the screen.
Why does the business collect that field? Who uses it later? Which fields are required? Which system is the authoritative source? What happens if the value changes?
Those aren’t programming questions. They’re business questions that eventually become programming decisions. As I said before, the question used to be, “Can I build this?” Increasingly it’s, “Should we build this?” A developer who can answer the second one is worth considerably more than one who simply produces code quickly.
Someone Still Has to Understand the System
System knowledge used to be free. You learned how an application worked by building it, one piece at a time, and nobody had to schedule that. It arrived as a byproduct of the typing. That byproduct is disappearing as AI writes more of the code. If AI generates a service that talks to three APIs, writes to two databases, and authenticates through an external identity provider, nobody on the team assembled it, so nobody absorbed it. The understanding that used to come along for the ride now has to be acquired deliberately, as its own activity. I don’t think most teams have noticed that yet, and I have never seen it in anyone’s job description. This matters most when something breaks. Production problems rarely announce themselves by saying:
“Line 147 contains an incorrect algorithm.”
Instead, someone says shipping can’t print a label. Now you have to determine whether the problem is the application, the printer, the network, the database, an API, permissions, configuration, bad data, or something that changed twenty minutes ago that nobody thought was related. AI can be very useful during that investigation, and I use it that way myself. But it can only reason about the system you are able to describe to it. If nobody ever learned the system, there is nothing to describe, and you are troubleshooting an application that no human has ever understood.
The Developer Becomes the Reviewer
Developers will also spend more time reviewing code they didn’t write, and that isn’t necessarily easier than writing it. You have to recognize code that technically works but solves the wrong problem, along with unnecessary complexity, questionable assumptions, security issues, and anything that will be difficult to support. You also have to recognize when AI has confidently invented something, and that requires understanding the technology well enough to challenge the answer.
If the AI says a library behaves a certain way, do you know enough to question it? If it generates a query that returns the expected result, can you tell whether it will still perform against fifty million rows? If it writes authentication code that works, can you tell whether it should ever have been deployed?
Reviewing generated software is becoming a core development skill, and it needs an actual standard rather than a feeling. Here is mine. Before I accept generated code, I have to be able to explain what it does, name the business reason it exists, and describe how it fails. If I can’t do all three, it isn’t finished, however fast it arrived.
The Developer’s Job Just Moved
I don’t think AI eliminates the software developer. I do think it changes what companies should expect from one. Producing another thousand lines of code isn’t much of a competitive advantage when a machine can generate them in seconds. Understanding the business is. So is making good architectural decisions, recognizing unnecessary complexity, knowing when the generated answer is wrong, troubleshooting the system at two in the morning, and taking responsibility for what goes into production.
AI may eventually write most of the code. That doesn’t eliminate the developer. It eliminates the idea that writing code was the most valuable thing the developer did. So what is a developer for? For now, for the judgment. The job has moved before, and every time, the part that looked like the whole job turned out to be the part that got automated. I wouldn’t bet on this being the last move.