We committed to AI-first development a year ago, meaning: AI tooling is in the critical path of our workflow, not an optional add-on that engineers use when they feel like it. Every project, every engineer, every day. This means we've accumulated enough real-world experience to have opinions that aren't just vibes.

Here's what we've actually learned.

What Works Extremely Well

Boilerplate generation is the obvious one, and yes, it's as useful as advertised. Project setup, CRUD operations, form validation, API client code - tasks where the shape of the solution is well-known but the implementation is tedious. AI handles these well and the time savings are real.

Less obvious but equally valuable: test generation. Given a function and some context about the domain, AI will write test cases that cover scenarios a human under time pressure would plausibly skip. We've caught real bugs this way - not because the AI is smarter than the engineers, but because it doesn't have the same biases toward happy-path testing.

Code review and security scanning. Modern AI models are genuinely good at spotting common vulnerability patterns, suggesting input validation improvements, and flagging suspicious logic. We use this as a first pass before human review, and it consistently catches things.

What Requires Careful Management

Complex, novel business logic. When the problem is well-defined and similar to things in the training data, AI excels. When it requires reasoning about domain-specific rules that interact in subtle ways, the output is plausible-looking but subtly wrong. Experienced engineers catch this; inexperienced ones don't, and the bugs are hard to find later.

Multi-file refactors and large context operations. AI tools have gotten better at this, but they still lose coherence across very large codebases or very long sessions. We work around this with discipline around context management - smaller, well-scoped tasks rather than "refactor the entire authentication system."

What Doesn't Work Yet

  • Architecture decisions that require understanding the full business domain and future growth trajectory
  • Integrations with poorly-documented or quirky APIs where the training data is thin
  • Performance optimization that requires deep understanding of how a specific database query plan is executing
  • Any task where being wrong in a specific way has serious consequences and the AI can't easily detect it made an error

What's Changed About How We Think About Engineering

The most important change isn't about specific tools - it's about where engineering judgment gets applied. AI has made the mechanical parts of software development faster. The bottleneck has shifted to the parts that still require human judgment: understanding what to build and why, making good architectural decisions, designing systems for the right trade-offs, and catching the subtle errors that AI introduces.

This means senior engineers are more valuable, not less. The leverage from a skilled engineer who knows how to work with AI is substantially higher than the leverage from a skilled engineer who doesn't. The floor of competence required to ship useful software may have lowered; the ceiling of what a skilled engineer can produce has risen.

The Skill We Didn't Expect to Be Important

Prompt engineering, in the specific sense of knowing how to decompose a task, frame it correctly, provide the right context, and evaluate the output critically - this has become a genuinely important skill for our engineers. It's not the esoteric dark art it's sometimes made out to be. It's more like knowing how to write a good engineering spec: a communication skill that improves with practice and attention.

The engineers who will define the next decade of software development are the ones who can seamlessly coordinate their own judgment with AI execution - knowing when to trust the output, when to verify it, and when to throw it away.