As agents take on more of the implementation work in software development, teams have an opportunity to bring customer understanding, product judgment, and engineering closer together. Making that work easier to carry across a team’s usual boundaries could change how products are built, and who takes responsibility for whether they help.
In his talk, “AI Writes the Code. So What’s Left for Engineers?”, Laurie Voss describes more of software development taking the shape of product engineering: understanding what people need, defining what a good solution looks like, and carrying it through to something they can use. Agents take on more of the implementation, and the engineer’s responsibility extends across more of the product.
That sounds a lot like the work that drew me into software in the first place. It also raises a practical question for teams: what needs to change for engineers to take on that broader responsibility?
Learning to build
I taught myself to code in high school. I liked designing websites as much as programming them, and I moved between the two as I worked. In 2003, I won a SXSW Web Award for my portfolio. It was built in Flash, which probably tells you enough about the era.
Design and coding paid my way through undergrad and law school. After a few years practising litigation, I returned to software development in 2015. Since then, I’ve worked with high-growth startups, enterprise IT teams, and government, building interfaces, back-end services, and tools across areas including financial technology, healthcare, and HR software.
I enjoyed that technical work. But the skill I brought to a project often began with curiosity about the person who would use it. What were they trying to do? Why was it difficult? What did we need to understand before deciding that a particular feature was the answer?
Those questions frequently emerged at the interface. Designing a screen forces decisions about what someone needs to know, what they can do, and what happens when something goes wrong. A seemingly small question about a form can expose an unresolved question about the whole product.
Following those questions means being willing to revisit decisions that may already have been treated as settled.
The boundaries of a role
In my experience, the way teams defined engineering roles could make it difficult to follow those questions.
Once you were understood to be a front-end developer, people tended to bring you front-end work. Your interest in the customer’s problem could be welcome, but it wasn’t necessarily part of your responsibility. Someone else had defined the requirement. Your job began further along.
The same could happen with any technical label. A specialization made it easier to explain what you did, assign work, and hire for a gap. It could also become a boundary around what people thought you had to contribute.
There were practical reasons for this. The stack grew enormously. Building and operating an application could require substantial knowledge of browser behaviour, distributed systems, deployment infrastructure, security, and much else. Keeping up with even one part of it was demanding. Teams divided the work so that people could develop the depth it required.
But that division also created handoffs. Customer understanding became requirements, requirements became tickets, and tickets arrived with some of the original context missing. An engineer could make good decisions within an assigned task while having little opportunity to question whether the task would solve the underlying problem.
For a team, the cost is that useful information can emerge during implementation without finding its way back into the product decision. The person who notices a problem may have little room to act on it.
A broader span of work
Agents now make it more practical for an engineer to stay with a problem across those boundaries.
As implementation becomes easier to delegate, a developer can attempt work across a wider part of the stack. That still requires enough understanding to evaluate the result and recognize when help is needed. But the amount of framework knowledge someone can hold in their head may become less of a constraint on what they can build.
The time and attention this frees up should go into understanding the problem more closely. A developer should spend more time with a customer, explore an approach, put something working in front of them, and use their response to decide what to change.
There is particular value in keeping those activities close together. What you learn while building can change the questions you ask. What a customer tells you can change an architectural decision. You can discover that a technically straightforward feature makes someone’s work more complicated, or that a much smaller change would address the problem.
An engineer who participates throughout that process has more context for making those decisions. They also have a clearer responsibility to find out whether the software helped.
This is where I see the value in the product engineer role Voss describes. It gives explicit weight to abilities that have always mattered in software development: asking good questions, understanding a domain, and exercising judgment about what deserves to be built.
Technical depth still matters
I don’t expect every developer to become a generalist, or every team to merge product and engineering into one role.
Some problems demand sustained specialization. Someone needs to understand why a database is struggling, whether a security boundary holds, or how a system behaves under failure. Agents producing more software may create more work that needs that depth of attention.
I’ve spent enough time working down the stack to value what specialists know. There is a great deal you only learn by staying with a class of problems long enough to see the consequences of your decisions.
My expectation is that more developers will work across a broader span of the product, alongside people with deep technical specialties. Across both paths, understanding the customer and taking responsibility for the outcome will matter more.
Making room for the broader role
There is a risk of being nostalgic about the early web. The applications I build now have obligations that my Flash portfolio never had. Reliability, accessibility, privacy, and maintenance deserve serious attention. The complexity that led us towards specialization was real.
But there was value in the continuity of that early work. I could have an idea, work through how it should look and behave, and bring it into existence. Design and programming were connected parts of the same creative work. For teams building more complex products, recovering some of that continuity would mean keeping the people making technical decisions closer to the problem they are trying to solve.
That requires changes in how teams work. Giving an engineer an agent and the same queue of narrowly specified tickets may produce more completed tickets. A broader role needs access to customers, room to question requirements, and some authority to change the approach.
It needs responsibility after release, too. If the job is to solve a problem, shipping is the point at which we can begin learning whether our solution works in practice.
That is the promise I see in the rise of the product engineer. More engineers could stay with a problem from the first conversation through the technical decisions and into the experience of the people using what they built. Teams that make room for that continuity give themselves a better chance of learning what is useful, and acting on what they learn. They also increase their odds of avoiding shipping slop, or bugs, or the enshittification of their product more generally. A pain we are all feeling too frequently these days.
