I’ve noticed a recurring worry among developers: if AI can write more code, what happens to the people who used to write it?
I understand the concern, but I think replacement is the wrong frame. Software development has always changed as new layers of abstraction appeared. Compilers, frameworks, libraries, code generators, cloud platforms, and better tooling all removed work developers once had to do manually. They did not make engineering disappear. They changed where the difficult work moved.
AI feels like another shift of that kind. It can take over parts of the implementation process, but that does not remove the need to understand the problem, make trade-offs, shape the architecture, or decide what should be built in the first place.
For me, the useful response is not to defend a fixed definition of what a developer is supposed to do. It is to keep evolving with the work.
Embracing Evolution Over Replacement
One reason I am comfortable with this idea is that software development has never stood still. Higher-level languages reduced the amount of machine-specific detail many programmers had to manage directly. Frameworks standardized work that used to be rebuilt project by project. Package ecosystems made it normal to start from existing building blocks instead of implementing every primitive ourselves.
None of this removed the need for engineers. It changed the level at which we could spend our attention.
I have seen the same thing in my own work. I have used code generation, scaffolding, libraries, and automation because repeating solved work by hand rarely adds value. AI coding tools fit naturally into that progression. Sometimes they can produce a useful first pass. Sometimes they produce something that needs to be corrected or discarded. Either way, the important part is still knowing what I am trying to achieve and being able to judge the result.
That distinction matters. Generating code is not the same as understanding a system. A piece of code can be locally correct and still be wrong for the product, the architecture, the data model, or the operational constraints around it. The more implementation becomes automated, the more valuable that broader context becomes.
So I do not think of AI as something that should take control of the work. I think of it as another tool I can delegate parts of the work to while keeping responsibility for the result.
A Wider Field of View
Most of my career has not fit into a single specialization. I have worked across frontend, backend, databases, infrastructure, product design, native applications, and architecture. More recently, Swift and native Apple development became another part of that picture rather than a move away from something else.
What has changed over time is the size of the field I try to keep in view at once.
Writing a feature is still important, but a feature does not exist only in its source file. It touches data, deployment, performance, user experience, maintenance, and sometimes the business model behind the product. A decision that looks elegant inside one layer can create problems somewhere else.
That is why I do not see architecture or product thinking as a level above coding. They are different views of the same system. Sometimes the right work is implementing a small function. Sometimes it is changing a database model. Sometimes it is questioning whether a feature should exist at all. The useful skill is being able to move between those levels without losing the connection between them.
AI can help inside many of these activities. It can generate code, summarize information, explore alternatives, or help reason through a design. But the responsibility for deciding which constraints matter, which trade-offs are acceptable, and what outcome is actually useful still belongs to the people building the product.
For me, that is a more durable way to think about the future of engineering than trying to draw a line around the tasks AI can or cannot perform today. Those boundaries will keep moving. Responsibility does not disappear just because more of the execution becomes automated.
Filling in the Gaps
A wider field of view creates another problem: the more parts of a system I work with, the easier it becomes to see the gaps in what I understand.
Working across the stack does not mean knowing every part of it equally well. What has changed over time is not simply the list of technologies I use, but how deeply I want to understand the systems behind them. Using a database is different from understanding how its storage model, transactions, indexing, and failure modes affect the rest of the product. Deploying an application is different from understanding the infrastructure, networking, and operational assumptions underneath that deployment.
That pattern keeps repeating. Every time my work reaches another boundary, I find another layer worth understanding better. Sometimes that means going deeper into something I already use. Sometimes it means learning an adjacent field because one product decision crosses several technical boundaries at once.
For me, continuous learning is less about constantly replacing one technology with another. It is about gradually building a better model of how the whole system works — and noticing where that model is still incomplete.
AI changes that learning process too. It can shorten the distance between a question and a first useful answer, but that makes judgment more important, not less. Faster access to an explanation is useful only if I can tell whether it fits the system in front of me.
The Work Changes. So Do We.
I do not know exactly how much of software development AI will automate. I do expect the boundary to keep moving.
But I also do not think the most useful response is to preserve today’s workflow as if it were the definition of software engineering. Our job has never been only to type code. It is to understand problems well enough to build systems that solve them.
Sometimes that requires code. Sometimes it requires architecture, debugging, product judgment, infrastructure work, communication, or learning a part of the system that was previously outside our focus. New tools change the balance between those activities, but they do not remove the need to connect them.
That is the part of this profession I still find interesting. The tools keep changing, the boundaries keep moving, and there is always another layer to understand.
My plan is simple: keep evolving.