When typewriters became standard office equipment, nobody at the company scheduled a meeting to debate whether typing was "real writing," and people were expected to learn. Accountants learned spreadsheets when spreadsheets arrived, office workers learned email when it replaced paper memos, and developers learned Git when it replaced SourceSafe and Subversion. Every generation of professionals has watched a new tool move into the middle of its work, and every generation has included people who insisted the tool was optional, right up until it was not.
Software engineering has absorbed these shifts over and over. Compilers replaced hand-assembled machine code, version control replaced folders full of zip files, automated testing replaced hours of manual verification, and continuous integration replaced "it works on my machine." Each of those tools ended up as part of what the job is, and I think AI is on the same path.
There is a quote that gets repeated everywhere right now: "AI isn't going to take your job. Someone using AI is." There's some truth in it, and it's catchy, but it turns a tooling shift into a competition and keeps engineers watching the person at the next desk when they should be watching how their own work is changing. What's happening is simpler and a lot less dramatic, which is that using AI is gradually becoming part of the job, the same way source control, automated testing, and CI did before it.
Every Generation Learns New Tools
Each of the earlier tools moved where the skill lived. There was a time when typing was a specialized profession, and then it was something every professional did. AI feels different because it can write code and tests and explain a system you've never seen before, and that is a bigger leap than a spell checker.
The pattern still looks familiar to me. The people who learn the new tool get more productive, the tool stops feeling new, and after a while nobody thinks of it as a separate skill anymore.
The Wrong Way to Use AI
When someone tells me they can't review all the code AI generates, I usually think they're describing a process problem.1 If AI is producing thousands of lines that nobody can review, you are using it differently than you would use another engineer. You would not ask a junior developer to disappear for three weeks and come back with twenty thousand lines of code, and if one did, you wouldn't try to review it in a single pull request or deploy it all at once.
There is no reason to treat AI differently.
Break the work into small pull requests with clear acceptance criteria, validate each one as it lands, and hold the agent's changes to the same review bar you'd hold a person's.
Same Quality, Less Friction
One of the biggest misconceptions about AI is that its job is to let us write vastly more software. What I want from it is the same quality of software with less friction.
If your development process falls apart because code now arrives faster than it used to, the process already had problems and AI exposed them sooner.2 The practices that fix it are the ones that always did: short-lived branches and small pull requests, continuous validation, and deploys frequent enough that rolling back is routine.
You Still Own What You Merge
This may be the most important part. You merged the pull request, and you deployed it to production. The AI isn't the one who gets paged at two in the morning when production breaks, either.
Responsibility stays with the engineer no matter which tool wrote the code.3 Understanding what ships, reviewing the code, and knowing the tradeoffs are all still part of the job. The tool got smarter. The accountability did not move.
The Profession Has Absorbed This Before
The printing press changed publishing, the calculator retired the slide rule, and modern IDEs replaced bare text editors for most working developers. Each of those shifts made some skills less valuable and others more valuable, and the profession absorbed the change and kept going. Software engineering has evolved alongside its tools for as long as there has been software engineering, and AI is the latest step in that.
The Better Question
So the question I'd rather ask is what the job of a good software engineer looks like once AI is part of the everyday toolset. I suspect the answer looks familiar, because the skills that have always mattered still do. It's someone who understands the systems and owns what runs in production, who keeps changes small enough to review, and who can tell when the AI is wrong.
You Do Not Have to Love It
You do not have to love AI, and you don't have to chase every new model that comes out. You certainly don't have to hand your engineering process over to an autonomous agent. It is getting hard to argue that AI is optional, though, because it has become one of the tools engineers use.
History is full of moments where a new tool became part of the job while people were still arguing about whether it should. The professionals who insisted the typewriter, the spreadsheet, or Git was optional understood their craft fine and misjudged where it was going, and the ones who adapted came out more capable. I think we are in one of those moments now.
Frequently asked questions
Will AI replace software engineers?
- No. AI is following the same path as compilers, version control, automated testing, and continuous integration: it is becoming part of the craft rather than eliminating it. The tools change where the skill lives, but understanding systems, owning production, and exercising judgment remain the engineer's job.
What does "AI is becoming part of the job" mean?
- It means using AI effectively is turning into a baseline professional skill, the way typing, spreadsheets, email, and Git did for earlier generations. Engineers who learn the tool get more productive, the tool stops feeling new, and eventually it is part of professional competence.
What is the wrong way to use AI for coding?
- Letting it generate changes too large to review. If AI produces thousands of lines nobody can evaluate, that is a process problem. Apply the same discipline you would with another engineer: small changes, small pull requests, clear acceptance criteria, and frequent validation.
Does using AI mean accepting sloppier software?
- No. The goal is the same quality of software with less friction. Short branches, small pull requests, continuous validation, frequent deploys, and confident rollback all still apply. If a process falls apart when code arrives faster, the process already had problems and AI exposed them sooner.
Who is responsible when AI-written code breaks production?
- The engineer. The AI did not merge the pull request, deploy the change, or take the page at two in the morning. Responsibility never transfers to the tool, so reviewing code, understanding tradeoffs, and knowing what ships remain part of the job regardless of who or what wrote the code.
Do software engineers have to use AI now?
- Increasingly, yes, because AI has become one of the standard tools engineers use. You do not have to love it or chase every new model, but history favors the professionals who adapt to the tools that join the craft.
Footnotes
- Your AI Is Not Sloppy. You Are. on why unreviewable AI output is a management failure, not a model failure. ↩
- AI Makes Good Engineers Faster and Bad Habits Louder on how AI amplifies whatever discipline, good or bad, a team already has. ↩
- Can I Deploy Your Code? on why ownership means being able to ship and recover what you build. ↩