AI writes code. Engineers build software.

AI has not killed programming. It has killed the idea that programming is mainly about typing code. That distinction matters. Much of the current AI discussion still treats software development as if the most valuable part is producing more lines of code faster. The prevailing logic is to give every developer a coding assistant, generate more features, ship more pull requests, and celebrate the productivity graph going up. 

But software organizations rarely suffer because they have too little code. Most suffer because they have too much code they do not fully understand, cannot safely change, cannot test properly, and cannot connect back to a clear business outcome. If I use it badly, AI only magnifies this problem. Code is becoming abundant, while true engineering is becoming scarce. 

The age of abundant code

For most of software history, writing code was expensive. You needed people intimately familiar with the language, frameworks, libraries, patterns, and quirks of the system. Even a small feature required someone to reason through the problem, write the implementation, fix the syntax, run tests, and push the change through review.

AI coding tools have fundamentally changed these economics. Today, a developer can ask an assistant to generate a React component, scaffold an API, migrate tests, or explain a legacy function. While the output is not always correct, it is incredibly fast. For example, recent GitHub data shows developers code up to 55% faster with AI assistants, turning what used to be a three-day API scaffolding task into a morning's work.

I won't pretend that speed isn't useful. AI removes boring work, accelerates onboarding for unfamiliar codebases, and helps non-native English speakers write clearer documentation. It can seamlessly turn rough intent into a workable starting point.

But abundant code creates a new bottleneck. The primary question is no longer, Can we write this? Instead, teams must ask:

• Should this exist?

• Does it fit the architecture?

• Does it solve the actual problem?

• Can we test and operate it safely?

• Can the next person understand and change it later?

Those are engineering questions, not coding questions.

AI slop is code without engineering

"AI slop" isn't just ugly code. It is code produced without sufficient context, constraints, ownership, or feedback. It might compile or pass a simple test, but it ultimately doesn't belong in the system.

This happens when an AI assistant invents a new abstraction because it failed to grasp the existing one, or when a pull request adds unnecessary dependencies to solve a problem the platform already handled. It happens when tests are generated directly from the implementation rather than the requirement, essentially just confirming that the generated code behaves like itself. Most dangerously, it happens when developers accept massive patches simply because reading them carefully would take longer than asking a model to write them, leaving you with code that works in a demo but fails mysteriously in production.

That is output management, not software engineering, and output management does not scale. The more code AI can produce, the more critical it becomes to fiercely gatekeep what code is allowed to enter the system.

The programmer's job is moving up the stack

This shift doesn't make developers less important. It simply moves their valuable work higher up the stack. As typing lines by hand becomes less central, deeply understanding the system becomes vital. The engineer's value shifts from producing code to shaping change.

That includes:

• Understanding the domain well enough to know what problems are actually worth solving.

• Defining clear boundaries between systems, services, and responsibilities.

• Turning vague requests into precise, testable intent.

• Providing AI tools with exact context instead of hoping they infer it.

• Designing robust feedback loops through tests, CI/CD, observability, and production metrics.

This is where the word engineer truly matters. A coder asks AI to build a feature. An engineer asks whether the feature belongs in the product, where it should live, how it should fail, what it costs to operate, and what future changes it makes easier or harder. AI raises the floor for code production, but it does not automatically raise the ceiling for software quality. That ceiling still relies entirely on human engineering judgment.

Orchestration is the new core skill

The best developers I see using AI aren't asking for massive chunks of magic. Instead, they are orchestrating small, controlled steps.

They provide context, demand that the tool inspect existing code before making changes, and constrain the solution. They separate test creation from implementation, read the diffs carefully, and ruthlessly reject plausible-looking code that doesn't fit the system. This workflow looks less like autocomplete and more like managing a lightning-fast junior developer who has read the whole internet but knows nothing about your production environment.

When I train engineering teams on AI adoption, I teach them that useful AI-assisted engineering generally follows this pattern:

1. Describe the intended behavior in plain language.

2. Have the tool inspect relevant code and summarize the current design.

3. Write or update tests first, ideally in a separate step.

4. Generate the absolute smallest implementation that satisfies those tests.

5. Run standard human checks: linting, type checks, security scans, and pipeline validation.

6. Review the diff for architecture, readability, and long-term maintainability.

7. Document anything the next developer needs to know.

None of this removes the engineer. It makes them more responsible, not less, because when AI generates the code, the human still owns the outcome.

Organizations must stop measuring the wrong things

The biggest risk with AI coding tools isn't developer laziness. The biggest risk is that organizations will measure the wrong improvements.

If the goal is more code, more pull requests, or more features, AI will deliver exactly that, including features no one ever should have built. But software delivery is a change management discipline, not a typing contest. The question isn't how much faster we can produce code, but how much faster we can deliver safe, valuable, maintainable change.

That requires a fundamentally different operating model. Teams need coding standards AI tools can follow, architecture documentation current enough to be useful, and CI/CD pipelines providing rapid feedback. They need behavior-driven tests, review practices focused on risk over style, and observability to confirm a change actually worked in production.

In other words, they need strong DevOps discipline more than ever. AI does not replace good software delivery practices; it fiercely punishes their absence. When I audited customers' CI/CD pipeline, I found that faster AI-generated pull requests actually increased their deployment failure rate by 20% because their automated testing couldn't keep up.

Winning teams will engineer the system around AI

There is a tempting, dangerous approach to AI adoption where a company buys licenses, turns on the tools, and simply waits for productivity to skyrocket.

Some of it will. Individual developers will move faster, small tasks will ease, and demos will look impressive. But long-term advantage won't come from having the same AI tools as your competitors; it will come from the engineering system you build around those tools.

That system includes:

• Clear rules for where AI can and cannot be used.

• Secure access to repositories, documentation, and environments.

• Guardrails for generated code, dependencies, and secrets.

• Test strategies that catch AI hallucinations early, and CI/CD pipelines that AI-assisted changes cannot bypass.

• Architecture decision records and standards built for tools to consume.

• A culture where engineers remain strictly accountable for the result.

This is the dividing line between AI-assisted coding and AI-assisted engineering. One produces output, the other produces software.

Coding is cheaper. Engineering is the differentiator.

I remain optimistic about AI in software development. It removes friction, accelerates learning, reduces the pain of legacy systems, and offers a crucial first draft when the blank page is the hardest part.

But I cannot confuse faster code generation with better software engineering. The developers who thrive in the AI era will not be the ones who generate the most code. They will be the ones who can turn messy intent into safe, working, maintainable systems. They will know how to define problems, constrain solutions, verify outputs, and own the consequences.

They will use AI as an accelerator, not an excuse to stop thinking.

AI writes code. Engineers build software. That difference is about to matter more than ever.