AI is bringing software work full circle

I think we have spent too long describing software work by the part of the process someone owns. Product defines it. Design shapes it. Engineering builds it. Each discipline matters, but those boundaries can make it surprisingly easy to lose sight of the problem everyone is supposed to be solving.

AI-assisted development is making me question how much of that separation we still need. When someone can understand a problem, explore a solution, and work directly with its implementation, the shape of the job starts to change. I see that as an opportunity to take more complete responsibility for the work.

That is what stayed with me from the second half of Laurie Voss’s talk, AI Writes the Code. So What’s Left for Engineers?. Around 16:30, he compares the emerging product engineer with the systems analyst of the 1960s, whose work involved understanding business problems and translating them into something that could be implemented. His argument is that responsibilities we have separated into product and engineering are coming closer together again.

I agree with that direction. The interesting question for me is what we do with the shorter distance between understanding a problem and building something that addresses it.

Why the 1960s comparison makes sense to me

I take the historical comparison as an analogy about responsibility. Modern software has different demands, and I would not treat the history of these professions as a straight line. What feels relevant is the expectation that somebody understands both the business need and what it takes to turn that need into a system.

That is a useful way to think about the future of this work. We often talk about new tools as though they require an entirely new purpose for the profession. I think they can also bring us back to an older, broader purpose: helping an organization solve a problem through software.

The part that changes is how directly a person can participate. Understanding a workflow and expressing it clearly can now lead much more quickly to something concrete enough to examine. That gives the person with the context a chance to remain involved through more of the process.

I find that more compelling than a debate about which job title survives. If we keep the same divisions and simply expect each department to produce its usual deliverables faster, I think we will miss much of the opportunity.

The handoff is what I expect to change

A handoff is useful when it brings in expertise. It becomes expensive when it mostly requires somebody to reconstruct context that another person already has.

A requirement might explain what a feature should do without making the tradeoff behind it obvious. An engineer can implement it faithfully and still have questions about why it works that way. A designer might spot a simpler approach after the scope has already been treated as settled. Nobody has to be careless for this to happen. The work has been divided in a way that makes some information travel poorly.

I expect assisted development to put pressure on those arrangements. If the person shaping the solution can also explore its behavior, some decisions can happen before they turn into formal handoffs. The team can discuss something visible while the reasoning behind it is still available.

That does not mean every conversation needs a prototype. Sometimes the useful result is realizing that a process can be simplified without building anything. I want faster implementation to give us more room to make that decision too.

The organizational question is whether we will let people work across those boundaries. Better tools alone will not help much if every small decision still has to travel through the same chain of approvals.

Product judgment has to get closer to the work

For product owners and managers, I think this shift asks more of us. We should be able to examine the behavior of a solution, explain why it matters, and revise a requirement when the implementation exposes a problem with our thinking.

It is easy to write a requirement that sounds complete. Working through it can reveal that we have not decided what happens when information is missing, who has authority to change something, or how a person recovers from a mistake. I want product people involved in those questions while the answer is taking shape.

My CRM and booking app work for Hoopes Vision is one reason this argument feels familiar. Assisted development let me participate more directly in implementation while managing the broader work. The business context still had to guide the requirements, the workflow, and what I considered ready. That experience makes the idea of a role spanning product and delivery feel practical to me.

The implication reaches beyond that example. If implementation becomes easier to begin, choosing the right work deserves more attention. A request does not become valuable because it is now cheap to build. We still need to understand what will improve, for whom, and whether the added software creates an obligation worth taking on.

Broader roles still need depth

I do not read this shift as permission to become casual about technical knowledge. The ability to ask for an implementation is useful. The ability to recognize when that implementation makes a bad assumption is essential to taking responsibility for it.

I would expect a broader product role to develop a stronger understanding of data, dependencies, and system behavior. I would also expect engineers to have more access to users and business decisions. Both changes make collaboration more informed.

There will still be work that needs deep specialization. I want people to recognize those moments and bring in the right expertise. A person can own a problem through delivery while relying on others to make or review particular decisions. Ownership should make those dependencies clearer.

My concern is that organizations could interpret this as a reason to compress several jobs into one without changing expectations or providing support. That would turn a useful expansion of responsibility into an unreasonable workload. If a role becomes broader, its scope needs to be deliberate. We should judge it by the result it can responsibly deliver.

We need a better way to learn this job

The later part of Voss’s talk also raises the question of how new developers will gain experience if agents take on more of the well-defined implementation tasks. I think that question deserves as much attention as the productivity discussion.

We cannot expect people to arrive with sound judgment if we remove the opportunities to develop it. Understanding users, making technical tradeoffs, and recognizing a weak solution all require practice and feedback.

I would give someone learning this work a small problem they can follow from the initial conversation through implementation and review. Let them explain what they believe the user needs. Ask them to identify their assumptions. Have them inspect the code, test the behavior, and discuss what surprised them with someone more experienced.

That is a learning process I would want to protect, even when an assistant can produce an answer quickly. People need enough time with a problem to form their own explanation of it. Otherwise, we risk training them to accept outputs without understanding what would make those outputs wrong.

What I want this shift to make possible

My agreement with the talk is strongest on the direction of the role. I am less interested in predicting when a particular task will be fully automated. I do not need to assume that all implementation or review becomes autonomous to see the value of bringing product understanding closer to technical work.

I want a person who understands the problem to have more ability to act on that understanding. I want an engineer’s questions to influence the product before the requirements harden. I want a working example to help a team discover that its original idea needs to change.

That is what makes the return to a broader systems role interesting to me. It offers a way to keep the reason for the work connected to the thing being built. The tools are giving us a shorter path between the two. How we organize our teams, develop our skills, and take responsibility for the result will determine how useful that becomes.