I think AI is starting to fundamentally change what strong engineering looks like.
And honestly, I don’t think the biggest shift is coding speed.
It’s ownership.
Because writing code is becoming dramatically cheaper.
But deeply understanding the problem, the customer, the tradeoffs, the scope, and whether something actually creates value is becoming dramatically more important.
So when I think about engineers today, I increasingly look for people who operate more like mini product owners or mini founders.
People who don’t just wait for tasks.
People who try to understand why something should exist in the first place.
Ownership also means not treating development like isolated ticket execution.
Strong engineers increasingly need to navigate ambiguity across the organization:
talk to other teams, understand dependencies, ask difficult questions, unblock decisions, and actively pull the information they need.
Because building the right thing often requires coordinating people, context, and decisions — not only generating implementation.
1. Reduce Ambiguity Aggressively
Before starting implementation, I increasingly expect engineers to reduce ambiguity aggressively.
Talk to PMs.
Talk to designers.
Understand the customer case.
Challenge the scope.
Figure out what actually matters and what can be simplified.
Because once implementation becomes cheap, understanding the problem becomes dramatically more valuable.
The best engineers I’ve worked with are usually the ones who help teams reach value faster — not necessarily the ones who write the most code.
2. Think Before Generating Code
I also think planning matters more now, not less.
Before generating code, understand the implementation strategy.
Compare approaches.
Read.
Ask AI.
Discuss tradeoffs with teammates.
And most importantly, understand what kind of system you are actually building.
An isolated MVP, a customer-specific workflow, and long-term core infrastructure are completely different engineering problems.
Not every idea deserves the same level of engineering investment from day one.
3. The Workflow Is Changing
At this point, I increasingly expect engineers to use AI continuously during development.
Engineers should stop treating manual coding as the default way software gets built.
More and more, the process becomes:
telling AI what to build, reviewing the result, correcting it, refining it, validating it, and repeating the loop until the implementation behaves exactly as intended.
The engineer’s role increasingly becomes:
direction, judgment, validation, architecture, and decision making.
If something is repetitive, automate it.
If something can be accelerated safely, accelerate it.
If a workflow repeats itself, turn it into a reusable process and share it with the team.
The value is no longer in manually producing the code.
It’s in knowing what should be built, how to direct AI effectively, and how to verify that the result actually works.
4. Engineers Still Own Quality
AI generating code does not remove responsibility from engineers.
If anything, it increases it.
Because someone still needs to evaluate engineering quality — while also validating that the product behaves correctly, solves the user’s problem, and works reliably across real-world scenarios.
5. Learning Speed Matters More Than Ever
The pace of change right now is difficult to overstate.
The engineers who grow fastest are often not the ones who already know everything.
They’re the ones who continuously learn, adapt, compare approaches, and evolve their workflows.
AI also lowers the cost of learning itself.
Which means curiosity becomes an even more valuable skill.
Honestly, I think the role is becoming more interdisciplinary.
Part engineer.
Part product thinker.
Part systems designer.
And I also think this definition may change again very quickly.
But right now, the engineers who stand out the most to me are usually the ones who combine strong engineering judgment with ownership, product understanding, and the ability to work effectively with AI.
Because increasingly, the job is not writing the code itself.
It’s making sure the right thing gets built — and that it actually works for users.
