The Golden Age of Product Engineers
24 February 2026
Why product engineers thrive in the age of AI agents and what it's like to be a product engineer at Monumental
To build great software products, software engineers have long had to spend a lot of time behind the keyboard writing code. As AI agents start to take over more of the coding, the hard part shifts: it’s less about how to build something and more about what to build and why. That’s exactly the question product engineers are great at figuring out, which is why I think we’re entering a golden age for product engineers.
What is a product engineer?
A product engineer, or product-minded software engineer, is an engineer who combines the work of a software engineer and a product manager. Product engineers don’t just ask “how do we build this?”, they ask “why should we build this?”. This means product engineers need a good view on the high-level goals of the business. They need to understand what the company is trying to achieve so they can figure out where to make the most impact.
Another thing that defines product engineers is being proactive. They don’t wait for a product manager to hand them requirements. They notice user problems, dig into them, solve them, and measure impact. Data analysis is a big part of the job, both to understand what needs to be built and to follow up on whether it actually worked.
Where do product engineers thrive?
Not every company is a great place for product engineers. Three things really make a difference in my opinion.
Easy access to end users. The easier it is to talk to the people using your product, the easier it is to understand their problems. This breaks down in a couple of ways. In SaaS, the buyer often isn’t the end user. Some companies actively shield engineers from customers, routing everything through layers of account managers and support teams. Access can also erode over time. It’s typical for startups to have shared Slack channels with customers and direct, informal feedback loops. As companies grow and start selling to larger organizations, those channels get replaced by formal processes, and engineers end up several steps removed from the people they’re building for.
The ability to make changes quickly. Product engineers need a platform that lets them build and ship features without depending on too many other people. Feature flags, easy experiment setups, good product analytics: all of these speed up the iteration cycle. If pushing a change takes a week of review and coordination, product engineers have a hard time.
A clear, transparent vision. Product engineers need to understand the bigger picture to decide what’s worth building. If the company strategy is opaque or constantly shifting, it’s hard to make good product bets.
Why now is a great time to be a product engineer
Tools for software engineering have improved a lot over the decades, but up until recently, the day-to-day experience of a software engineer didn’t look too different from a software engineer in the 80s. Yes, we got nicer laptops and soy lattes, but we were still all mostly typing code into text editors. AI is rapidly changing this.
A couple of years ago, we replaced copy-pasting from StackOverflow with copy-pasting from ChatGPT. Then the LLMs found their way into our IDEs and we replaced typing out code by pressing tab to accept an autocomplete. For a while though, the results were mixed. Some experienced engineers were skeptical of AI, as the code these models wrote wasn’t great and the productivity gains were meager (if they existed at all). For example, I started using Cursor pretty heavily at the end of 2024, but initially I got comments from my colleagues about my code quality, as I wasn’t spending enough time cleaning up the AI code’s mess.
However, in the last year and especially in the last couple of months, something has been shifting. You can tell something’s up by seeing the sheer number of “AI coding agent” meetups the last couple of weeks. Developers are suddenly finding that AI agents are now capable of writing whole pull requests on their own. More and more software engineers are running more and more coding agents at the same time, in the background.
For product engineers, this is amazing. The long todo lists we manage can finally be tackled. There’s much more room for experimentation. The fidelity of prototypes goes way up. And if something doesn’t click with users, starting over doesn’t feel like killing your darlings. You just revert the changes and prompt again. LLMs are also surprisingly good at the data analysis side of product engineering: wiring up the right queries, creating basic plots, formatting dashboards. This frees up time for what actually matters: interpreting the data and deciding what to build next.
My experience at Monumental
I work at Monumental, where our goal is to automate on-site construction using robots. Concretely (pun intended), we’ve designed a brick-laying robot system and are deploying our robots to build walls for houses, canal walls, infrastructure, and more. We’re a vertical company, meaning we develop, produce, and operate our robots all in-house.
You might wonder: why does a robotics company need user-facing software at all, given that our robots build walls on their own? Well, laying the bricks is only a part of the business. We also have to manufacture our robots, calibrate them, plan out the construction projects, create the designs for the walls based on architects’ drawings, create 3D reconstructions of the building site, and the list goes on. As we scale up our operations, we continuously find more and more areas where building software would be helpful. The application we build, Atrium, touches all of these.
And who are the users? There are many: from robot operators who oversee the robots on site to deployment managers who manage logistics, to engineers who want to develop new capabilities. The great thing is that all of them are my colleagues. This makes working with users extremely easy. We all share the same office, so I can walk over to someone’s desk to watch them struggle with something I built. We all have hot lunches together (this is pretty revolutionary in The Netherlands), which is a great moment to catch up informally. Even my colleagues who are mostly on construction sites often spend a day at the office. When I ship a feature, I can see within the same week whether it actually helped or just added confusion.
Most software engineers at Monumental operate as product engineers. We don’t have product managers (even our CTO still contributes to the codebase) and we’re all obsessed with improving our robots, software, and operations. Most of us are T-shaped engineers, meaning we’re generalists but also each have a specialization. My specialization is Product/UX, which means I spend extra time thinking about how users interact with what we build and whether we’re solving the right problems.
Our software platform makes it easy to move fast. All of our code is in one monorepo, we push to production every week, and feature flags let us ship things incrementally. When I want to test a hypothesis, I can usually get something in front of users within hours or days. We also collect a tonne of data and metrics and our data infrastructure is rapidly improving, which means I can easily create dashboards to see how we’re doing.
I also appreciate how clear our vision is: we want to make houses more affordable and beautiful by countering the shortage of bricklayers. Our business model and immediate goals are also very simple: our revenue is directly linked to how many bricks our robots put down each day. That makes it relatively easy to estimate whether a feature will actually move the needle.
Will AI agents become product engineers?
Given how fast AI agents are improving, it’s fair to ask if the product engineering role is actually safe from automation. Coding agents are already being connected to tools like Slack and Linear, which means they have at least some access to user feedback. Proactive agents are also being experimented with (e.g. OpenClaw). In theory, an agent could monitor bug reports, propose fixes, deploy them, measure the impact, and iterate. The whole product engineering loop.
We’re not there yet. Agent sessions start with very limited context, and the full loop (understanding a complex application, testing it like a real user, deploying, following up) still seems out of reach. For example, at Monumental, we might have to debug a collision between two robots using multiple video streams. Or we might have to do some complex interactions in our wall designer to test a feature. As long as agents can’t be fully trusted with testing their features, software engineers will still be needed for a while to prove the code works before delivering it.
But when agents do get better at this, the product engineering role won’t disappear. We’ll simply spend less time writing code or even reviewing it, and more time on user relationships and deciding what’s worth building. The skills that make a great product engineer today (empathy, judgment, taste) will only become more valuable in the near future.
We’re currently hiring product engineers for the Software - Product/UX role at Monumental. If you like building products end-to-end, care about users, and want to work on something that actually matters, apply here.