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 aren't the ones who type fastest. They're 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 is dead. Product writes a spec, throws it over the wall, engineering builds it, nobody's happy. I've seen this fail at every company I've worked at.

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 an implementation plan before you leave the room, you're worth ten times more than someone who needs three rounds of clarification on a Jira ticket.

The most expensive line of code is the one you write before checking if you're solving the right problem. I've watched teams spend months building features that don't fit the architecture, use tools that fight them at every turn, or solve problems that didn't actually exist.

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 rather ship something imperfect on Tuesday than something perfect never. The goal is working software in the hands of users, not a beautifully documented plan that lives in Notion.

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.

A specification that requires three follow-up meetings to clarify is not a specification. It's a conversation starter.

Good specs map directly to your architecture. They name the services, the data models, the API contracts. They flag where complexity lives and propose how to handle it. They're written with the team, not handed down to them. When an engineer reads a spec I've written, they should be able to start building immediately, not start guessing.

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 the things I build. I watch them work. I feel the friction they feel. The best product decisions I've ever made came from using my own software and thinking “this is annoying.”

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