Software Engineers Are Still the Artisans of Software
AI is changing how software gets written, but it is not eliminating the work that makes engineering valuable. Engineers may no longer be the artisans of every line of code, yet we remain the authors and artisans of software products.
Programming languages have moved steadily closer to the way people express intent. AI is another step in that progression: engineers can increasingly describe a desired outcome in ordinary language and ask an agent to produce the implementation. But a higher-level language does not remove authorship. It moves authorship up a level.
As code has become easier to write, we have seen more coders, not fewer. What changes now is where engineers need to focus: understanding users, expressing intent clearly, making sure we build the right things efficiently, and creating products that make sense and can continue to scale as people and agents contribute to them.
Great Engineering Was Never Just Writing Code
AI has reduced the time required to produce code. It has not removed the broader work great engineers do in the middle and around the edges.
Engineering work often arrives with a poor definition. A proposal may include more than users need to receive value, or it may omit important considerations such as an API or the feature’s effects on other parts of the system. Sometimes the work should not be built at all. Sometimes a slight change can make it possible to build in a quarter of the time, use fewer resources, or deliver a better user experience.
That judgment is part of engineering. So are the rounds of feedback with Product Management and Design, collaborative testing and discussion, and continued iteration on the actual user experience. Producing an implementation is only one part of creating a software product.
Faster Implementation Can Produce the Wrong Things Faster
The greatest risk of AI-assisted implementation is our ability to rapidly build things no one wants: interfaces that do not make sense, experiences that are slow or unusable, systems that do not scale, and products that fail to solve the actual problem.
A prompt is not a substitute for product judgment. It may describe what to generate, but the engineer still has to decide what should exist, what tradeoffs are acceptable, and whether the result belongs in the product at all. The cheaper implementation becomes, the more important those decisions become.
Speed is valuable only when we are building the right thing. If we neglect the thinking that should precede implementation, we can reach the wrong result faster.
Spend More Time Understanding Before Coding
The engineer’s day-to-day workflow needs to focus more on understanding the problem and reviewing and testing the resulting work.
Previously, teams might spend a good amount of time understanding a problem, the largest share of their time coding, and a smaller amount of time reviewing. Some review naturally happened during implementation because engineers were examining the work as they wrote it.
Now coding is fast while review takes much longer. At the same time, teams are spending less time understanding the problem. That balance needs to change. When coding time has become negligible, spending more time understanding the work upfront can reduce the time needed to review it afterward.
Before asking an AI agent to implement a feature, engineers need to understand the product manager’s intention and the user’s needs. We also need to understand the product itself: how the components we are building on work together and what else they interact with. AI can help us gain some of that understanding, but gaining it remains valuable to the process.
That understanding must then be made legible to the agent. Clear requirements, constraints, examples, and acceptance criteria are no longer just planning artifacts; they are part of the implementation interface. The quality of generated code depends heavily on the quality of the context and intent we provide.
You Are Responsible for the Code You Commit
When you commit code, you are responsible for it. There is no difference in responsibility between code you wrote yourself and code you generated with AI tools.
That means thoroughly testing AI-generated code before committing it and refusing to shift the cost of inadequate review onto someone else. I think of “slop” as using AI to produce something while spending less time on it than you expect another person to spend consuming it. If you submit an AI-generated pull request without reviewing it adequately, you are asking someone else to bear the burden of understanding it and finding its problems.
At a minimum, spend as much time examining AI-generated work as you expect a reviewer to spend examining it. Before requesting review, review the code as though you were the assigned reviewer and no one else would inspect it before it reached users.
The Craft Moves Up a Level
AI does not make engineering judgment less important. It increases the speed at which implementation can happen, making that judgment essential before and after the code is produced.
Authorship has never required typing every word or placing every character by hand. It requires choosing the direction, shaping the result, and accepting responsibility for what is released. Using an agent changes the mechanics of creation, not who owns the outcome.
The craft now extends beyond writing code. Our responsibility is to understand the problem, shape the work, account for the surrounding system, test the result, and stand behind what we commit. The tools may generate more of the implementation, but engineers remain responsible for turning that implementation into a product that makes sense, solves the actual problem, and can scale. We are still the authors.