Methodology

AI has made execution cheap. You can generate a component, a service, an entire feature in minutes. But knowing what to build, why it matters, and where it fits in the architecture? That's the bit that still requires experience. That's what's actually scarce now.

The engineers who'll thrive are the ones who can look at a problem and say “we don't need to build that” or “here's a 90% solution that takes 10% of the effort.” That instinct comes from building things, breaking things, and understanding why businesses actually make money.

The handoff model has never worked well in my experience. However good the spec is, there are always gaps that only surface once you start building, and by then the person who wrote it has moved on to the next thing.

The better model: engineers who understand the business deeply enough to define what gets built, then build it themselves. Not because PMs aren't valuable (they absolutely are), but because the gap between “what we want” and “what's technically sensible” is where most projects go wrong.

If you can sit in a stakeholder meeting, understand what they actually need (not just what they're asking for), and translate that into something you can build, you're worth ten times more than someone who needs three rounds of clarification on a Jira ticket.

I've watched teams spend months fighting an existing implementation, bolting features onto architecture that wasn't designed for them, instead of stepping back and asking “what do we actually need?”

So before I write a line of code, I check. Can we actually build this with our stack? What's the complexity hiding behind the “simple” requirements? Where are the integration points that'll bite us in week three? Answering these questions before you start isn't slowing down. It's the fastest path to shipping.

I'd sooner ship something imperfect today than keep talking about the perfect solution in non-stop meetings. Every week a feature sits unshipped is a week you're not learning whether it actually solves the problem.

This doesn't mean being reckless. It means being deliberate about what “good enough” looks like for v1, knowing what you're consciously leaving out, and having a plan for when you'll come back. The 90% solution that ships this week beats the 100% solution that ships next quarter.

The biggest source of waste I've seen in software teams is the space between what the business asks for and what actually gets built. Requirements get misunderstood, context gets lost in translation, and you end up with something that technically matches the brief but doesn't solve the problem.

I write specs that close that gap. They start from the business need, account for what's technically realistic, and give whoever's building it enough clarity to start immediately without guessing. The goal is that nobody has to come back and ask “what did you actually mean by this?”

I use AI tools constantly. They write code, generate tests, draft documentation, scaffold services. The raw output is remarkable. But they don't understand your business, your users, or why that seemingly simple feature is actually a regulatory minefield.

The pattern that works: human judgment for the what and why, AI for the how and how fast. An engineer with strong product instincts and AI tools can now do what used to require a team of five. That's not a threat to engineers. It's a massive expansion of what one person can own and deliver.

If you're building a tool and you don't use it yourself, you're guessing. I sit with the people who use what I build and watch where they hesitate, where they work around things, where they get stuck. The best product decisions I've ever made came from that kind of direct contact, whether that's working on warehouse floors with the staff or visiting care homes.

Feedback loops should be immediate, not quarterly. Build something, use it, fix it, repeat. That cycle should take days, not months.