A follow-up to "AI Coding Assistants Are Amplifiers"

Last week I wrote about how AI coding assistants are amplifiers — they take whatever signal you feed them and make it louder. The post resonated with a lot of folks, and the conversations that followed kept circling back to one question: if the bottleneck isn't execution anymore, what is it?

The answer, I think, is simpler and more uncomfortable than most engineers want to hear: it's knowing what to build in the first place.

The Speed Paradox

Here's the thing nobody tells you about moving faster: speed doesn't just change how quickly you get somewhere. It changes which skills matter.

When I could write maybe 200 lines of solid, tested code in a good day, there was time for course correction. I'd start building something, realize halfway through it wasn't quite right, and adjust. The slow pace created natural checkpoints. The effort required to write code functioned as a forcing function for thinking.

Now? I can scaffold an entire feature in an hour. The AI will happily generate models, controllers, tests, documentation — the works. If I point it in the wrong direction, it'll get me to the wrong place really fast.

This is the speed paradox. The better these tools get at execution, the more expensive wrong decisions become. When building was slow, a misstep cost you a day. Now it can cost you a week before you realize you've built the wrong thing entirely.

The bottleneck has shifted. It's no longer "can we build this?" It's "should we build this, and which version of this are we building?"

And that's not an engineering question. That's a product question.

The "Tell Me What to Build" Problem

I've noticed a pattern in how engineers interact with product managers, especially on teams that haven't adapted to this new pace. It goes something like this:

PM: "We need to improve the onboarding flow. Users are dropping off."

Engineer: "Okay, what exactly do you want me to build?"

PM: "Maybe add some tooltips? Or a tutorial? What do you think?"

Engineer: "I don't know, you're the PM. Just spec it out and I'll build it."

This interaction made sense when building was the hard part. The PM's job was to figure out what, the engineer's job was to figure out how, and there was a clean handoff in between.

But when you can build three different versions of "improve onboarding" in the time it used to take to build one, that handoff becomes the bottleneck. The back-and-forth to clarify requirements, the waiting for specs, the revision cycles — all of that is now more expensive than the building itself.

What used to be an efficient division of labor is now just latency.

Product Sense as a Core Engineering Skill

I'm increasingly convinced that the engineers who thrive in the next five years won't be the ones who can code the fastest. AI is commoditizing that. It'll be the ones who know which code to write.

That requires product sense. Not "I have opinions about features" sense, but the actual skill of understanding:

What problem are we actually solving?
Who has this problem, and how badly?
What does success look like from the user's perspective?
Which version of this solution is the right tradeoff between value and complexity?
What should we build first, and what can wait?

This isn't about engineers doing the PM's job. It's about engineers being able to have a conversation about the problem space before jumping into the solution space. It's about being able to look at a feature request and ask "why?" until you understand the real need, not just the stated requirement.

Here's a concrete example. A PM on a team I worked with asked for a bulk export feature. The engineer could have just built exactly what was spec'd — a CSV export button that dumps everything. Would have taken maybe two days with AI assistance.

Instead, the engineer asked why users wanted bulk export. Turns out they were trying to do analysis that the app didn't support. The engineer spent thirty minutes talking through what kind of analysis, realized it was just three specific metrics, and built an in-app analytics view instead. Took the same two days, but solved the actual problem rather than the stated request.

That's product sense. The AI didn't make that call. The engineer did.

The Blurring Line

If you'd asked me three years ago what the difference was between a product role and an engineering role, I'd have said something clean: product figures out what to build, engineering figures out how to build it.

That line is blurring fast, and I don't think it's going back.

The "how to build it" part is increasingly a conversation with an AI. The strategic engineering decisions — architecture, patterns, tradeoffs — still require human judgment, but the tactical implementation is getting abstracted away. What's left is the hard work of figuring out what's worth building.

And here's the uncomfortable part: not every engineer is ready for that. Some folks got into engineering because they liked the clear boundaries. You get a spec, you build the thing, you ship it. There's a satisfaction in that clarity. The code either works or it doesn't. The tests pass or they don't.

Product decisions aren't like that. They're fuzzy. You're making bets on what users need, and you won't know if you were right until later — sometimes much later. There's no compiler to tell you if your thinking is sound.

But that fuzziness is increasingly where the value is.

What This Looks Like in Practice

The teams I see adapting well to this shift have a few things in common:

Engineers are in user conversations. Not every call, but enough to have context. They're hearing the problems firsthand, not filtered through layers of product specs and Jira tickets.

Product and engineering co-create solutions. It's not "product specs, engineering builds." It's "here's the problem, let's figure out the right solution together." The PM brings user context and business priorities. The engineer brings technical possibility and feasibility intuition. The solution emerges from the conversation.

Engineers have agency over scope. If an engineer sees a way to deliver 80% of the value with 20% of the complexity, they can make that call. They're not just order-takers waiting for permission.

Prototyping is cheap and frequent. Because building is fast, teams that are doing this well will spin up two or three versions of a solution to test assumptions before committing to one. The AI makes this economically viable in a way it wasn't before.

The teams struggling with this shift are still operating in waterfall mode even if they call it agile. Product writes specs, engineering implements specs, and nobody questions whether the specs were right until after the feature ships and doesn't move metrics.

The Career Implication Nobody's Talking About

If you're an engineer and you're reading this, here's the thing you need to hear: "I just want to code" is becoming a career-limiting statement.

I'm not saying you need to become a PM. I'm saying the value of pure execution is compressing. If your skillset is "give me clear requirements and I'll implement them efficiently," you're competing with AI. And the AI is getting better at that every month.

The engineers who are going to command premium value are the ones who can:

Identify high-leverage problems worth solving
Navigate ambiguity to find clarity
Make smart tradeoffs between speed and quality, scope and impact
Collaborate across disciplines to shape what gets built

These are product skills. They're also engineering skills now. The Venn diagram is becoming a circle.

If you've been avoiding product conversations because "that's not my job," it might be time to reconsider. Because increasingly, it is your job. The AI is handling the other part.

The New Interview Question

I've started asking a different question in interviews: "Tell me about a time you pushed back on a feature request because you thought it was solving the wrong problem."

The answers are revealing.

Some candidates get defensive — "that's not my role, I build what I'm told." That's a signal.

Some will talk about technical pushback — "the architecture was wrong" or "the performance would have been bad." That's fine, but it's not what I'm asking about.

The best answers are about problem understanding. "We talked to users and realized they wanted X, but the real issue was Y, so we built Z instead and it worked better." That's the signal I'm looking for.

If you can't tell me a story about understanding the problem space well enough to influence the solution, I'm not sure what value you're adding that an AI can't.

That sounds harsh. But the market is going to figure this out whether we acknowledge it or not.

What to Do About It

If you're an engineer who's realized "I should probably get better at this product stuff," here's where I'd start:

Sit in on user research. Even just listening to a few customer calls will rewire how you think about features. You'll start seeing problems instead of just requirements.

Ask "why" until you understand the real problem. When a PM brings you a feature request, don't just nod and start building. Ask what problem it solves. Then ask why that problem matters. Keep going until you hit the actual user pain point.

Ship small and iterate. Don't try to build the complete vision in one go. Build the smallest thing that tests your assumption about the problem, ship it, see what happens. AI makes this faster than ever.

Read product strategy. There are frameworks — jobs to be done, outcome-based roadmaps, opportunity scoring — that PMs use to prioritize what to build. Learn them. You don't have to become an expert, but understanding the language helps you participate in the conversation.

Own outcomes, not output. Stop measuring your value by how much code you shipped. Start measuring it by whether the thing you built moved the metrics that mattered. That shift in framing will change how you approach everything.

The Amplifier Still Applies

This all connects back to last week's post. AI coding assistants are amplifiers. If you're amplifying "build exactly what I'm told," you're going to move fast in directions someone else is choosing for you.

But if you're amplifying "understand the problem, design the right solution, build it fast," you're going to be impossible to compete with.

The power is still real. The responsibility is still yours. But now it includes deciding what's worth building in the first place.

The engineers who figure this out won't just survive the AI transition. They'll define it.

What's your take? Are you seeing this shift in your team? Hit me up in the comments or on X.