AI Adoption

Best engineers, who hold institutional knowledge (the 'mental duct tape'), tend to be the slowest adopters because they are best positioned to spot failure modes and missing validation. Instead of forcing adoption, organizations should involve these skeptics by making them responsible for defining the roadmap to make AI safe.

AI adoption follows a three-act process: (1) Simple, successful use cases; (2) Applying practices to bigger problems where AI fails badly and trust breaks down; and (3) Building the real skill by implementing proper guardrails, context, and prompting for scale.

For complex features, spending significant time writing a detailed plan is more effective than simply prompting the agent. A good plan must start with a 'Why' (executive summary) and be broken down into small parts that can each be verified independently.

Since human attention is scarce, it is crucial to build a culture of self-communication by explicitly marking what content was generated by AI versus what was written by a human (e.g., starting PR descriptions with a manual summary).

Instead of spending weeks or months finalizing requirements, focus on delivering value in the next two to four weeks. Long-term plans (1 year) should only serve as directional inspiration, not rigid commitments.

Due to increased code output from AI tools, traditional code review must change. Engineers can self-certify simple PRs, and large features should be stacked into multiple smaller PRs (capped near 500 lines) to maintain meaningful review quality.

For GenAI solutions, failure modes must be categorized (tolerable vs. not acceptable). Critical processes require consensus among multiple models (e.g., using different LLMs to review the same receipt) and running integration tests many times, rather than just once.

AI native means that the person who cares about a feature has the authority and ability to execute the work, collapsing the traditional handover gap between PMs/Designers and Developers. The bottleneck shifts from coding speed to decision-making capacity.

Merge rate (the percentage of PRs that land in production) is the key metric for measuring if an organization is successfully adapting to AI-driven workflows. A high merge rate indicates trust and quality between non-technical contributions and the dev team.

As organizations move fast, it is critical not to abandon engineering principles or 'guards' (like testing, architectural standards). The agent must be designed to learn the codebase deeply and maintain these constraints.

To measure impact, track: 1) Count of PRs opened by non-technical individuals. 2) Merge rate (e.g., an average merge rate of 74% was cited). 3) Percentage of merged PRs that require zero developer intervention.