Over the last few years I've seen coding agents develop rapidly and the techniques of using them change just as much. Engineers that are getting the most out of these tools are the ones that have invested in broadening their skillsets outside of traditional engineering responsibilities.

As coding agents have increased the rate at which an engineer can produce the "coding" part of their role, it's becoming more important to keep your agent unblocked to allow work to continue, similar to how a manager aims to keep their employees unblocked to allow projects to continue. This problem now becomes more frequent in a large organisation where all engineers are AI-enabled and running agents in this fashion. This is because previously, these engineers would often only need to work on engineering related tasks such as developing architecture, writing code, deploying infrastructure etc. while other roles such as business analysts, product managers, designers and others would have relevant work routed to them. A product manager would handle the interface with the customer and understand what we wanted to build and what results it should deliver, a designer would help bring this to life and focus on the look (UI) and feel (UX) of the solution, and the engineer would ultimately build it.

This is all very black-and-white and of course in practice the roles overlap here and there however as the code production process has become faster, these routed responsibilities become a clear bottleneck. You're now spending considerable time at these early stages of problem solving before a quick build stage that validates all of that work.

The cost of a blocked agent

So imagine you're working with an agent to develop software quicker than you ever have before, you've entered a flow state, defining schemas and data flows, making technical tradeoffs and designing architecture BUT THEN the agent asks you about a new button in the design, it's not part of our design system and you don't know what it's meant to do, and there's no notes in the design. At this point, you're ripped out of your flow-state and need to look through meeting notes, any other docs you have, and maybe message a few people or even have a meeting ... that's tomorrow.

This scenario is simplistic but I hope demonstrates the point, this type of blocker existed before agentic coding but the cost of it is now significantly higher relative to your total output. For example, say a project unassisted by agentic coding were to take 100 hours, but with agents takes 50 hours, a blocker that takes 5 hours to unblock would have previously impacted the project by 5% but now it's a 10% impact on the project's total time to delivery.

What happens when the means (coding) to produce the output (a coded product) speeds up substantially without the inputs (product requirements and designs) also speeding up? Well, you get a surplus in capacity that is not being used which results in subpar projects getting put on the conveyor belt if you want more output, or you get reduced team sizes if you want the same output as before. I'd argue that the best businesses would use this newfound capacity to produce more rather than just cutting costs and reducing headcount.

Fix the blockage

And this is why I think that becoming a well rounded product-minded engineer is important for any engineer that works on customer facing software built by product teams. This isn't new, often T-shaped individuals have been touted as great hires and you want them on your team to get the best results. These people are often reasonably senior, have seen a lot and may have even worked in other non-engineering roles before. Previously, you could become one of these people by learning about the other roles in your team, becoming more experienced over the course of your career and aiming to work your way up career ladders, gaining more breadth as you went. However now, I believe that you need to start becoming this individual earlier in your career as businesses will prioritise those that can work like this rather than only do a traditional software engineer's role. I'm not claiming to have the answer to gaining such broad knowledge early in your career but rather I can see that these skills are in demand more than pure coding skills, so there's no better time than now to learn those skills.

Outcomes, not tickets

So what does it look like day-to-day? Well perhaps it makes sense to look at the classic engineer expectation. In a traditional role where engineers are primarily focused on coding (and code-related tasks like architecture, code review etc.) you may come into work, go to your sprint plan or standup, pick up some tickets and then get into the day working on them. An endpoint added here, a frontend route added there, perhaps a bug fix or two. Now throw that away, an AI-assisted product engineer just did all of that before their first meeting. They understood that a particular feature needed to be built, had a rough understanding of the architecture and what was involved and spent most of the development time getting their plan right, probably debating technical decisions with their agents and filling in context around who the customer is, how the feature should work etc. on the fly without needing to step away to get these answers. They aren't focusing on a ticket, they are focusing on the product outcome that the team is looking to deliver.

I'm not advocating for cowboy engineering but rather getting to the quality gate faster. These engineers aren't shipping this work immediately but instead they're presenting it as a demo internally or to users, gaining feedback from PMs, designers and others, and then re-iterating, they're just doing this more holistically than brick-by-brick.

Build the taste you're missing

How do you get to this point? It's not a prerequisite to have god-level AI-skills to be a T-shaped product engineer however the fact that there are people at that level makes it that much more urgent that you become a product engineer. So beyond the AI-skills, you need to focus on the overlaps of your traditional engineering role and the other roles on your team, what questions are your agents getting stuck on that you can't answer? Any of those questions, you should be able to answer so spend time working on what skills you need to actually answer those well.

These may be questions related to user flows, or perhaps the look of things, or domain-specific knowledge that your customer would know. Spend time understanding the work that your colleagues are doing, it's definitely not just whatever they hand you to start building but usually a lot of research, discussion and deep thinking on particular problems. Get closer to your customer, ask to join calls and interviews, dogfood your product if you can, read the brief that was given to your PMs and designers. Ask "why" on every decision that you still need input from others on to understand their reasoning over time. Make calls on low risk decisions, ship your work and get review, learn from these corrections. Study the best products that you personally use, what brings you joy from these products and how can you use similar approaches in the products you work on?

If you're going to take away anything from this post, it's this:

  • If you work on a product team developing software, becoming more product-minded is going to help you more than ever in the age of AI. The more breadth you have, the more effective you will be.
  • Start using agents and notice where you stall progress by needing to loop in others, invest in your own growth at these points.
  • Stop thinking in tickets and start thinking in outcomes.

Related Posts