The future Laurie Voss describes in his talk, “AI Writes the Code. So What’s Left for Engineers?”, sounds a lot like the work that drew me into software in the first place.
Voss sees 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.
For me, that would be a welcome development. I suspect it would feel familiar to a lot of developers who started building things in their bedrooms in the early 2000s.
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 eventually law school. I went on to practise litigation for a few years, but the impulse to build products stayed with me. In 2015, I returned to software development.
Since then, I’ve worked with high-growth startups, enterprise IT teams, and government, across areas including financial technology, healthcare, and HR software. That work took me deep into the stack. I built interfaces, back-end services in .NET and Node, microservices, and command-line tools. There was always another part of the system to understand.
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.
That was the work I wanted to follow wherever it led.
The boundaries of a role
I often felt that only part of this was available to me in the role I had been hired to fill.
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.
I found that frustrating because my interest in software had always extended across those boundaries. I wanted to understand the problem well enough to help shape the thing we built.
A broader span of work
What interests me about agents is the possibility of carrying more of that work myself.
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 could go into understanding the problem more closely. A developer could 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 the part of Voss’s product engineer that appeals to me. The role 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.
That also 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.
A welcome return to a more thoughtful 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 I would like to recover some of the breadth that made building websites so compelling to me. 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.
My career has given me a much deeper understanding of what that work involves. It has also reinforced how much depends on curiosity about other people: their circumstances, their frustrations, and the things they are trying to accomplish.
I want more of my working life to make use of that curiosity. I want to stay with a problem from the first conversation through the technical decisions and into the experience of the people using what we built.
That is the promise I see in the rise of the product engineer. For those of us who came to software because we wanted to build useful things, it feels like room to do more of the job.
