Software Developers Don’t Write Code Anymore

A little while back, I was talking to a friend about how software development has changed so much over the last two years.

We went from hand-written code, then copy-pasting some small code snippets from ChatGPT, to now having AI models make large changes across entire codebases. The shift was consistent, but from the outside, it was almost invisible. I talked to someone from another department at my company recently and explained what GitHub Copilot is and how we use it. They were mind-blown. They had no idea that a tool like this had completely changed how we work.

I went around and asked my colleagues how much code they’re actually writing by hand now. The answer was exactly what I expected: we’re down to single-digit percentages of manually written code making it into our production codebase. The rest is generated by AI, reviewed by a human, and shipped.

Five years ago, I think 80% or more of a software developer’s time was spent writing code. The remaining 20% went to things like code reviews, meetings, and documentation. The exact ratios might be different from company to company. Today, that ratio has completely flipped. The core task that defined the job, writing code, is almost gone. The time that used to go toward writing is now filled with more code review, more feature planning, more bug fixes, and more architectural thinking. The job title stayed the same, but the job itself looks nothing like it did before.

My friend used to be a teacher, and when I said this out loud, I couldn’t help but wonder how insane it would sound if the same thing happened in his field. Imagine if, within two years, teachers no longer spent most of their time teaching. If the defining task of the profession just mostly vanished. That’s the kind of change that happened in software development, and most people outside the industry didn’t even notice.

Note: When I say “AI”, I mostly mean large language models in this context. I’m choosing to use the term “AI”, since most people outside of tech are familiar with it. It hurts me every time, but I had to make the tradeoff for this one. Additionally, almost all of the statements I make have caveats and exceptions. I’m not going into the details to keep this more article readable and more generalizable.

Which Jobs Are Next?

That conversation got us thinking about what other jobs might go through the same kind of transformation. Last year at OpenAI’s DevDay, they had a talk about how they build evaluations for their models. They explained that they’ve shifted toward targeting the top knowledge-work sectors that contribute to GDP and building evaluations around the actual tasks those jobs perform. The slide they showed, listing the sectors and job types they’re targeting, read like a hit list.

The video might be worth a watch: https://www.youtube.com/watch?v=YEaKXjHENyQ&t=241s

I think software development changed first because it sits so close to where these AI models are built. Developers were early adopters by nature. But other industries won’t be far behind. The question isn’t whether these jobs will change. It’s what they’ll look like after.

A Framework for Thinking About It

Around the same time, I watched a video about tacit knowledge and explicit knowledge. Tacit knowledge is the type you build through experience and intuition. It’s hard to write down and hard to teach to someone else. Explicit knowledge is documented, standardized, learnable from a textbook or a documentation.

That distinction gave us a starting point for thinking about which tasks within a job are most likely to be affected by AI. If a task is mostly built on explicit knowledge, an AI model can learn it. If it’s mostly tacit, it’s harder to automate. The share of explicit versus tacit knowledge in a task is fluid and changes over time, but it’s a useful lens for understanding which parts of a job are most exposed to automation.

But as we talked it through and poked holes in the idea, we realized the tacit-versus-explicit split alone doesn’t tell the full story. There are at least two more things that determine whether a task actually gets displaced in practice.

Dimension 1: Knowledge Type

How much of this task can be learned from documented, standardized sources versus experience and intuition? The higher the share of explicit knowledge, the easier it is for an AI to do some or all of it.

Writing code, for example, is mostly explicit knowledge. There are syntax rules, design patterns, best practices, and millions of examples to learn from. That’s why it was one of the first tasks to be automated. Code review used to lean more toward tacit knowledge, built from years of experience reading other people’s code. But recently, there’s been more work put into documenting what good code looks like and turning that into explicit standards. Code review is now more explicit than it used to be, which is why it’s starting to get automated too.

Like I mentioned before, the share of explicit versus tacit knowledge in a task isn’t fixed. It changes over time, either naturally to make the task easier to learn, or intentionally to line the tasks up for automation.

Dimension 2: Delivery Constraint

Does the task require physical presence, a body in the room, or a human relationship to work?

Even if an AI can do the thinking, someone might still need to be there in person. A large share of a plumber’s knowledge is explicit (pipe specs, building codes, standard procedures), but you still need a person at the job site. A teacher might have AI-generated lesson plans, but a six-year-old still needs someone in the room with them.

Dimension 3: Accountability Requirement

Does someone need to be on the hook when things go wrong?

Some tasks carry legal liability, ethical weight, or just the plain social need for someone to blame. A radiologist reading scans, an engineer signing off on structural plans, a lawyer advising a client. Even if an AI does 95% of the thinking, a human stays in the loop because someone has to own the outcome. As of now, you can’t sue an AI, you can’t fire it and You can’t put it in front of a board hearing.

All Three Move

It’s tempting to treat knowledge type as the moving target and the other two as fixed. But all three shift over time, just at different speeds.

The knowledge type scale can shift quick. Documentation, standards, and more training data moves tacit knowledge toward explicit.

I think delivery constraints move at a medium pace, pushed by cultural comfort and infrastructure changes. Telehealth wasn’t very widely adopted before COVID. Then overnight, people were fine seeing a doctor on a screen. The physical presence that seemed necessary became less important.

Accountability moves the slowest because it depends on legal and regulatory change, and those systems are built to be slow. But it moves too. Two years ago, most developers wouldn’t trust AI-generated code in production. The trust threshold moved and now it’s more accepted. The same could eventually happen in medicine, law, or finance. Accountability is also has a social/cultural component. If people are used to the idea of AI being involved in a task, they might be more comfortable with it being part of the accountability chain.

Because all three dimensions shift over time, the framework works best as a point-in-time snapshot. It tells you where a task stands right now. Check again in a year or two, and you can see the direction things are heading.

Applying the Framework

The thing worth stressing is that jobs aren’t one big block. A job doesn’t get automated or not automated. Individual tasks within a job get automated at different rates, and the job reshapes around what’s left. The title “software developer” survived, but the actual work looks completely different than it did two years ago.

To evaluate any job, break it into its major tasks and score each one across three dimensions:

• Knowledge type: What share is explicit versus tacit?
• Delivery constraint: Does it require physical presence or a human relationship?
• Accountability requirement: Does someone need to be legally or socially responsible for the outcome?

Radar charts are a good way to visualize this. Each axis is one of the dimensions, and the distance from the center represents how much of that dimension is present in the task. The more a task fills out the radar chart, the less likely it is to be automated. The more it hugs the center, the more exposed it is.

Here are two examples, on of writing code and one of delivering a lesson plan:

What Comes After

The tasks that are most explicit, least physical, and lowest in accountability get automated first. The job reshapes around what’s left. In software development, that meant less time writing code and more time on design, review, and judgment calls. A lot of developers would say that’s a better version of the job. But it’s also a different job, and not everyone signed up for the new one.

That’s probably how it plays out elsewhere too. A teacher who spends less time building lesson plans can spend more time connecting with students, but the role demands different skills than it used to. A lawyer who offloads legal research to AI can focus on strategy and client relationships, but the junior associate who used to build experience doing that research now has a gap to fill.

The shift creates real opportunity, but it also creates real displacement. Both things are true at the same time. Understanding where a job’s tasks sit across the three dimensions today won’t tell you exactly what’s coming, but it gives you a starting point for thinking about where things are headed.