Notes ·
AI Is Making Code Cheap. It Is Making Judgment More Valuable.
Joshua MorrisI keep seeing versions of the same question about AI and software engineering: if anyone can ask an AI to build software now, what happens to software engineers? I think the question puts too much value on the act of producing code and not enough on everything required to produce good software. AI is making implementation remarkably cheap, and one person can now generate APIs, React components, database schemas, tests, deployment files, and documentation in an afternoon. That changes the economics of writing software, but it does not make engineering cheap. If anything, judgment, knowledge, skill, and experience become more valuable when producing code is no longer the scarce part of the work.
I have been circling this idea for a while in my writing, on LinkedIn, and through my own experiments with coding agents, harnesses, sandboxes, test systems, and multi-model workflows. The more capable these tools become, the less impressed I am by the fact that they can produce another thousand lines of code. I already know they can do that, and I expect them to become dramatically better at it. What interests me is whether I can give them the right problem, define the right constraints, recognize when they have made a bad assumption, verify what they built, and decide whether the result belongs in a system that other people will depend on. Those are engineering skills, and AI has not made them disappear.
I can ask AI to build me a surfboard
The analogy I keep coming back to is a surfboard. I am a software engineer, not a surfboard shaper, but I could ask an AI to teach me about rocker, rails, volume, fin placement, fiberglass, epoxy, hydrodynamics, and the different shapes people use for different kinds of waves. I could show it photographs, ask for measurements, generate templates, and have it calculate dimensions based on my weight and how I said I wanted to ride. With enough help, I could probably build something that floats. That still would not make me a surfboard craftsman.
An experienced surfboard shaper has knowledge that came from making boards that worked and boards that did not. They have watched how different boards behave in actual water, learned how subtle changes to the rails affect the ride, and discovered how weight distribution, glassing, flex, and shape interact after years of trial and error. Some of that knowledge can be written down and explained to me, but some of it comes from having made a hundred boards and having learned from every mistake along the way. An experienced craftsperson recognizes problems before I even know there is something I should be looking for. AI can give me access to an enormous amount of information about shaping surfboards, but it cannot retroactively give me twenty years of experience doing it.
The same thing is true in the other direction. An incredible surfboard shaper who has spent decades mastering that craft could ask an AI coding agent to build an iPhone application, and I fully expect they could end up with an iPhone application. It might look good, launch correctly, save information to a database, and perhaps even make it through the App Store review process. None of that tells us whether it handles authentication correctly, protects private information, behaves properly with poor network connectivity, follows accessibility standards, leaks resources, has sensible data migrations, performs under load, or can still be maintained two years from now. The surfboard maker may not even know which of those questions need to be asked, just as I would not know which subtle mistake in a board would become obvious the first time it reached the water.
That is not an insult to the surfboard maker, because I would be equally ignorant standing in their workshop. The important distinction is that access to implementation is not the same thing as possession of expertise. AI can help both of us produce something in a field we do not understand, but neither of us suddenly inherits the years of judgment that normally come from practicing that craft. We need to stop treating the ability to generate an artifact as proof that we understand the discipline that created it. That difference is going to matter more as generated work becomes increasingly convincing.
Working software has never been the entire job
I wrote about this in my Methodical Function series on software development when code becomes cheap. Software has always had an entire lifecycle surrounding the code itself, beginning with understanding the problem and continuing through design, testing, deployment, operation, maintenance, and eventually retirement. Someone still has to understand what users actually need instead of blindly implementing what a ticket happens to say. Someone still has to evaluate tradeoffs, understand constraints, decide how the system will be tested, watch what happens in production, respond when it fails, and make choices about how it should evolve. Generating the implementation only compresses one part of that lifecycle.
I wrote something in that article that I believe even more strongly now:
You can't lead what you don't understand. You can't set standards you don't know. You can't review code you can't evaluate. You can't make architectural decisions you can't reason about.
AI can give me three possible architectures, but experience helps me recognize why two of them are terrible choices for the system I am actually building. It can generate a hundred tests, while knowledge helps me notice that none of those tests exercise the failure condition that matters most. It can produce an authentication system, but security experience helps me recognize an authorization assumption that could eventually become a vulnerability. It can propose another microservice, while judgment allows me to decide that we do not need another service at all. When implementation becomes cheap, knowing when not to build something becomes increasingly valuable.
That is one of the parts of engineering that is difficult to measure because the best decision can result in less visible output. Avoiding an unnecessary service does not produce a flashy demo, but it may save years of operational complexity. Rejecting a clever abstraction may result in fewer lines of code while leaving the system easier to understand. Choosing the boring technology may prevent an entire category of future problems. Experience often shows up as restraint, and cheap code generation makes that kind of restraint more important rather than less.
The bottleneck is moving from creation to verification
There is evidence that the nature of engineering work is already beginning to shift. A 2026 longitudinal study of professional software engineers found that developers using AI coding assistants reported spending less time directly writing code and more time directing, evaluating, and correcting AI-generated work. The researchers described this as supervisory engineering work, which feels like a useful description of what I am experiencing myself. I write less code by hand than I used to, but I spend more time reading diffs, defining requirements, building tests, questioning assumptions, and watching what agents changed. The engineering did not disappear; much of it moved to a different part of the process.
DORA's 2025 State of AI-assisted Software Development research reached a related conclusion by describing AI as an amplifier of the systems and practices already surrounding it. Strong organizations with good engineering practices can get tremendous leverage from these tools, while weak processes can produce dysfunction faster. That matches what I see when I work with coding agents. If I give a capable agent clear requirements, strong tests, useful documentation, sensible architectural boundaries, a safe sandbox, and fast feedback, it can accomplish an extraordinary amount of useful work. If I give the same agent a vague sentence and access to production, I have created a very productive way to make mistakes.
The model can be identical in both cases, which is what makes the distinction important. The quality of the engineering around the model determines whether its speed becomes leverage or liability. This is why I am much more interested in harnesses, tests, sandboxing, review systems, and constraints than I am in trying to squeeze another few percentage points out of prompt cleverness. The model will keep getting better, but the system around it still needs to define what good means. That responsibility belongs to the people building and operating the software.
"Almost right" is where experience becomes expensive
The most dangerous AI-generated code is rarely complete nonsense, because complete nonsense is easy to reject. The difficult output is code that is almost right, looks reasonable, passes a few tests, and gives you enough confidence to stop looking closely. Stack Overflow's 2025 Developer Survey found widespread AI usage alongside declining trust in AI output, with developers frequently describing the frustration of receiving answers that were "almost right, but not quite." That is exactly the kind of problem where expertise becomes expensive, because finding the remaining error requires knowing what correct looks like. Plausibility is useful when you are exploring, but it can become dangerous when you are shipping.
If a result is obviously wrong, almost anyone can reject it. If it is 95% correct, you need someone capable of finding the other 5%, and that missing portion may be the most important part of the entire system. It might be a security vulnerability, race condition, incorrect authorization boundary, database design that collapses under real scale, accessibility issue, or business rule that everyone on the team understood but nobody remembered to write into the prompt. Sometimes the missing 5% is simply realizing that the feature solves the wrong problem. Those are the moments when knowledge and experience stop being abstract career virtues and become the difference between software that merely exists and software that actually works.
This applies far beyond software. An AI-generated legal document can look completely convincing to someone who does not practice law, just as a medical explanation can sound authoritative to someone without medical training. The better these systems become at generating plausible work, the more valuable it becomes to have someone who knows where plausible ends and correct begins. That is why I think the value of expertise may actually become easier to see as generative systems improve. The machine can produce the artifact, but someone still has to know whether the artifact deserves to be trusted.
We still have to create experienced engineers
There is one part of this transition that worries me because experience still has to come from somewhere. I wrote recently about Bruce Schneier's distinction between work and the gym, where sometimes the purpose of a task is simply getting the result while other times the struggle involved in doing the work is how we develop the skill. Software engineering contains both kinds of work, and AI makes it increasingly tempting to optimize all of it for the fastest possible result. That creates a real risk that we remove some of the experiences that used to teach people how software behaves when things go wrong. Efficiency is useful, but we need to be careful about which inefficiencies were secretly teaching us something.
I learned an enormous amount by breaking things, making architectural decisions I would never make today, shipping bugs, chasing production problems through logs, and rewriting systems that I originally thought were clever. I have watched code behave completely differently under real traffic than it did on my laptop and spent hours debugging failures that ultimately came down to one stupid assumption. I would prefer not to repeat those mistakes, but I would not give up what I learned from them. Those experiences gave me a catalog of patterns that I now recognize much earlier, often before they become expensive. That recognition is one of the things I mean when I talk about judgment.
Researchers at Carnegie Mellon University's Software Engineering Institute recently studied graduate software engineering students using LLMs for a dependency-upgrade task and found that students sometimes stopped applying disciplined engineering techniques, instead repeatedly feeding build errors back into the model. The AI could move the task forward, but the students were not necessarily practicing the reasoning that would help them solve the next problem independently. That creates a long-term question our industry will have to answer: if AI handles every beginner problem, how do we produce the experienced engineer fifteen years from now? We cannot simply consume expertise without continuing to create it. The challenge is figuring out how to use AI to accelerate learning without allowing it to replace the experiences that produce understanding.
I do not think the answer is banning AI or insisting that every engineer manually do work a machine can handle better. That would be like banning power tools because people still need to understand woodworking. Sometimes the AI should give us the answer, sometimes it should help us reason toward the answer, and sometimes we should turn it off and struggle long enough to understand the problem ourselves. Knowing which situation we are in is itself a judgment call. That may become one of the most important mentoring responsibilities experienced engineers have in the next generation of software teams.
AI will filter software engineers, but not the way people think
I do think AI is going to reduce the demand for some kinds of software engineering work, particularly when the work consists primarily of translating a well-defined ticket into predictable code. Models are becoming very good at that kind of implementation, and I do not expect the industry to preserve repetitive work simply because people used to be paid to do it manually. What I do not believe is that this means software engineers as a profession suddenly become unnecessary. Instead, AI is going to expose the difference between producing programming output and exercising engineering judgment. Engineers whose primary value was typing code may feel much more pressure than engineers whose value comes from understanding systems.
The engineers who understand architecture, users, testing, security, performance, operations, networking, databases, and business constraints suddenly have enormous leverage. They can apply everything they learned over years of building systems through machines capable of implementing their decisions at a speed that would have been absurd a few years ago. Someone without that understanding can generate code just as quickly, but speed is not the same advantage when you cannot reliably evaluate the result. A person who lacks the knowledge to recognize bad output can now generate mistakes faster than ever before. AI amplifies both capability and ignorance.
This is also why I do not think the future belongs to whoever becomes best at prompting. Prompts will improve, models will improve, interfaces will improve, and much of what we currently describe as prompt engineering will eventually disappear into better tooling. Knowledge compounds differently because understanding networking still matters when an agent writes the networking code, and understanding databases still matters when the agent writes the SQL. Browser behavior, security boundaries, distributed systems, accessibility, observability, and performance do not stop mattering because another tool generated the implementation. Understanding people may matter most of all, because somebody still has to understand what problem we were trying to solve before anyone asks the machine to solve it.
The engineers who recognize this change are not competing with AI in a typing contest. They are learning to use AI as another tool for applying the knowledge they already possess while continuing to deepen that knowledge. I think the people who struggle most will be the ones who mistake generated output for expertise and stop developing their own ability to evaluate the work. AI can hide those gaps for a surprisingly long time because the output often looks convincing. Eventually reality provides the review.
The craft did not disappear
I love using AI to build software, and none of this is an argument for returning to a romantic version of programming where every legitimate line of code must be painstakingly typed by a human being. I have no desire to manually produce boilerplate just to prove that I remember the syntax, and I want agents handling repetitive implementation, exploring alternatives, writing test scaffolding, reviewing changes, inspecting logs, and doing mechanical work that gives me more time to think about the system. That is exactly why I have been experimenting with harnesses, sandboxing, and multi-model workflows. I do not want less AI in software engineering; I want better engineering around AI.
The mistake is believing that because a machine can perform part of the craft, the craft itself has become worthless. CNC machines did not make the knowledge of a master machinist worthless, modern cameras did not eliminate photographers, and power tools did not make carpentry trivial. Those tools changed where skill was applied and increased what skilled people could accomplish. AI is doing something similar to software development, although the speed and breadth of the change are much larger than most previous tools. The leverage is real, but leverage is most valuable in the hands of someone who understands what they are doing.
An AI can help me make something that floats, but experience tells a surfboard shaper whether it is actually a good surfboard. An AI can help someone generate an application, but engineering tells us whether that application is secure, maintainable, reliable, useful, and worth owning for the next several years. Those are not minor details around the edge of the work. They are the work.
As code becomes cheaper, I think that distinction becomes easier to see. The scarce skill is no longer simply producing more code. The scarce skill is knowing what deserves to be built, recognizing whether it was built well, and having enough knowledge and experience to know what the machine missed.
Read "Software Development in the Age of AI: How To Think Like an Engineer When Code Is Cheap."
Read "AI Code Assistants as Teammates: A Practical Playbook for Day-to-Day Engineering."
Read "AI in the SDLC Pipeline: Integrating Agents into CI Without Burning Down Production."
Read DORA's 2025 State of AI-assisted Software Development research.
Read METR's study of AI and experienced open-source developer productivity.