Before LLMs, being able to deliver a high quality product at pace was largely a combination of product intuition and your ability to get into a flow state and churn out code. Of course, you had to make sure you were building the right thing, often meaning you’d write up some kind of product spec and a technical scoping doc. However, most of the time was spent building, and making minor technical and product decisions along the way.

A memorable example of this for me was when I led our project to build out Customer Status Pages at incident.io. That was a 3-week project, and it will have taken me somewhere around 3-4 days to scope that out. It involved comparing options for the auth flow, figuring out how we might need to adjust our SSR caching (you really don’t want to show a cached version of an auth’d page to an unauthenticated user), and how the config side of it all would work. But after those days of reducing ambiguity, it was all just churning out code.

Over the last year, that’s changed drastically. Being a “10x engineer” is not about getting into a flow state and writing code at 120wpm. We’re moving from being code machines, to spec machines—the best product engineers now are exceptional at defining the work (much like a PM might do in a more traditional org). And for me, this has taken a long time to come to terms with.

Fighting the urge to speed up

When your feature can get built in 3 days instead of 3 weeks, I’ve found an innate urge to speed up scoping at a similar rate. This is a terrible idea. It’s also really hard to default to anything else. If I’m going to spend 3 full days just scoping something out, I’ll feel guilty about it when building it only takes 2 days. But of course, the calculus has changed, and this is what the new normal is.

When a customer request can be handed straight to Cursor’s cloud agent, the only thing that stands between them and a terrible product outcome is us as engineers (and product managers!), stepping in, and using our product understanding to decide if and how that request should actually show up in the product.

We all have to re-learn engineering

If you were already writing great scoping documents, you’ll probably have to get used to putting more meetings in the calendar. The scoping part of a project is usually the most collaborative, where you talk to other engineers and people in the business to figure out exactly how what we’re building should work. Previously, you might’ve had a couple meetings as part of scoping, and then built for 3 weeks. Now, you’ll probably need to have those couple meetings every few days, because your job is no longer code, it’s scope.

If you as an engineer weren’t writing scoping docs before, it’s time to learn, because that’s your job now. Over the next few years, we’ll probably find our work becoming more human-centred as we spend time collaborating on scoping, and leave building to the machines.