AI Is Automating Code. The Job Is Engineering

I am watching our video editing team at Techstrong work differently. Increasingly, they are telling AI what to edit and how. Decisions that once required them to manually execute a series of operations can now be expressed as instructions.

They are still making the creative decisions. They know what they want the video to become. But they can spend more time thinking about what they want to create and less time carrying out every adjustment themselves. They are also editing a lot more video.

That is a different experience from the one implied by the familiar question of whether AI will replace video editors. In the work I am seeing, AI is expanding what our editors can do. Their judgment gets applied to more output.

I thought about that while reading Corynn Winston’s recent CNBC article on software developer job postings. AI is doing more coding, yet demand for developers, at least as measured by those postings, has been recovering.

For anyone who equates software development with typing code, that might seem contradictory. For people who actually deliver and operate software, it should be less surprising.

The Work Was Always Bigger Than The Code

CNBC reports that Indeed’s U.S. software development postings rose almost 15% from late February 2025, while overall postings fell 7%. Over a separate period, May 2025 through May 2026, senior roles accounted for 71% of the increase in software development postings. AI-titled positions accounted for 37%, with those categories potentially overlapping.

There are qualifications. Postings are not completed hires. Software development postings remained roughly 27.5% below their pre-pandemic level. A recovery does not establish that AI caused the growth, much less prove that everyone in the profession is doing well.

Still, the concentration of demand among experienced people deserves attention. Perhaps companies are finding that generating an implementation and delivering a working system require different capabilities.

An experienced developer’s value has never been limited to the number of lines they personally write. Plenty of senior developers still code extensively. They also understand why a particular approach will fail, which dependency makes an apparently simple change risky, and what the customer meant when the requirements said something else.

AI can take on more implementation without resolving those questions.

I see this as developers becoming more focused on software engineering. I am not proposing a new hierarchy of job titles. Developers have been doing engineering all along. The balance of their time and responsibility is shifting toward defining the system, directing how it is built and establishing whether it works.

A request to generate a feature is only the beginning. Someone must determine how that feature fits the architecture, what data it can access, how it behaves under failure and whether its ongoing cost is acceptable. An implementation can satisfy the prompt and still be wrong for the business.

That is why describing this work as “just prompting” misses the expertise behind a useful instruction. Our editors need to know what a good edit looks like. A software engineer needs to recognize what a plausible-looking implementation gets wrong.

Across the Delivery Lifecycle

The same shift extends through QA, DevOps, platform engineering, SRE and security. These disciplines already involve designing systems and exercising judgment. Automating more execution makes those responsibilities more consequential.

Take QA. Generating and running more tests can help, but test volume does not tell you whether you are testing the right things. If an agent writes code based on a mistaken interpretation of a requirement, tests generated from that same interpretation may enthusiastically confirm the mistake.

Someone has to establish what correct behavior means, which failure cases matter and what evidence would justify releasing the software. QA expertise becomes especially valuable when a passing test suite creates confidence that the underlying assumptions do not deserve.

For DevOps and platform engineering, the challenge is larger than making an agent run a pipeline. We have to design the environment in which agents deliver changes. What permissions do they receive? Which checks are mandatory? Can they modify the controls that evaluate their own work? When does a change require approval?

A platform that lets agents move quickly without answering those questions could accelerate the delivery of problems. Building safe, usable paths to production is engineering work, whether the user of that platform is a person or an agent.

SRE faces a similar issue. Automated diagnosis and remediation can be useful, but a system capable of taking action also needs boundaries. Restarting a service is different from changing a database configuration or deleting resources it judges unnecessary.

Reliability objectives, rollback mechanisms and escalation rules determine how much autonomy makes sense. The practitioner must understand the consequences of an intervention, including the possibility that a locally sensible fix creates a larger failure.

Security follows the same logic. Generating fixes and scanning more code are useful activities. They do not, by themselves, establish that the application’s trust boundaries are sound or that its access controls match the business risk.

More code flowing into these systems creates more downstream work. If testing, integration and operations cannot keep up, faster coding simply moves the queue. DevOps practitioners should recognize that problem immediately. Optimizing one activity does not guarantee better delivery.

Nor can the answer be to have a human manually inspect every line forever. Verification must scale too. That means engineering automated checks, useful evidence and escalation mechanisms, then evaluating whether those controls actually work.

What Will We Do With the Capacity?

This is where the business decision becomes important.

An organization can look at faster execution and ask how many people it needs to produce the same output. It can also ask what its people could accomplish with the time they get back.

At Techstrong, I see our editors producing more video and having more room for creative decisions. Both matter. The additional capacity changes what is possible for the team.

Software organizations have their own candidates for that capacity. There are internal tools that never get funded, systems overdue for modernization, reliability improvements repeatedly postponed and customer requests that cannot compete with the existing backlog.

Making development less expensive could make some of that work practical.

There is a Jevons-style possibility here: When something becomes cheaper to produce or use, demand can expand. A company that could justify five software projects might be able to justify more when implementation costs fall.

That does not guarantee more developer jobs. Output could increase while employment falls. Demand might not expand enough to absorb the capacity, or other costs might limit the benefit. Some employers will pursue staff reductions.

But assuming a fixed amount of software work is also a choice, and often a poor starting point. The backlog is not necessarily the full extent of demand. It includes what people believed was feasible enough to request.

The management question is how much value the organization can create with its capabilities, not simply how cheaply it can reproduce last year’s output.

A Pattern Beyond Software

I suspect we will see versions of this in other professions. An accountant’s work includes interpreting exceptions and advising a business, beyond reconciling transactions. Marketing requires deciding what to communicate and to whom, beyond producing campaign assets. Journalism requires finding out what happened and establishing whether a claim is true, beyond assembling sentences.

AI can change the economics of tasks within each profession without taking over the entire service.

That does not mean every professional becomes a people manager. An engineer directing agents can remain an individual contributor, deeply involved in technical decisions. Our editors are still editors.

It also does not mean the transition is painless. Some roles may shrink or disappear. Employers still need ways for less experienced people to acquire the judgment they increasingly expect. And human oversight should not be treated as a permanent employment guarantee; parts of that work will be automated too.

What matters is how the work is reorganized as those capabilities change.

Watching our video team, I see people gaining more room to apply their ideas while getting more work done. That is an outcome worth pursuing deliberately, rather than treating it as an incidental benefit of a cost-cutting exercise.

For software teams, the equivalent is not a bigger pile of generated code. It is more useful software that can be delivered, secured and operated reliably.

Before deciding how many developers AI makes unnecessary, I would ask what we have wanted those developers to build, fix or improve that they have never had the capacity to tackle. Then I would put the new tools to work on that list.