Most People Use AI Like Google. That's Why It Sucks.

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3831929) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Jono Herrington Posted on Apr 28 • Originally published at jonoherrington.com Most People Use AI Like Google. That's Why It Sucks. #ai #leadership For the first month I treated Copilot like a junior engineer with ambition and no guardrails. It would write code I never asked for. I'd be halfway through a function, and Copilot would leap ahead ... creating new methods, suggesting whole classes, trying to take initiative like a junior who wants to prove themselves. The breaking point came during a refactor. It would output code that didn't just ignore our style guide ... it created variables named R and T. It duplicated logic I'd already abstracted. It wrote the same pattern three times instead of recognizing the abstraction. The tests broke, and it didn't care. Because why would it? I hadn't taught it to care. I spent two hours cleaning up a mess that should have taken twenty minutes to write correctly. We teach engineers to take initiative. But with AI, you have to reel it in. That became the pattern. I'd prompt, it would overreach, I'd prune. Prompt, overreach, prune. I was spending more time editing AI output than I would have spent writing it myself. Not because the AI was bad. Because I was asking for answers when I should have been defining the system. The Markdown File Realization The shift happened when I stopped trying to re-prompt my way out of bad output. Instead, I changed what brain the AI pulled from. I created markdown files with our engineering standards. How we write requirements. What questions we ask before we scope. The difference between a user story and a task. How we think about tradeoffs. When we prefer duplication over abstraction. What "clean" means in our codebase. The next time an agent generated code, it didn't improvise. It executed patterns we'd already defined. That was the difference. I wasn't prompting a junior engineer anymore. I was orchestrating a senior engineer. What Senior Engineers Actually Do Senior engineers don't write better code because they type faster. They write better code because they recognize patterns. They know when to abstract and when to duplicate. They understand the constraints that aren't written down but exist in the culture of the codebase. You can't prompt that into an AI. You have to encode it. We built it into skills, rules, agents, hooks. We have markdown files for our BA persona. For our solution architect. For how we handle code review and QA. When an agent generates a spec or writes code, it references these files. It's not improvising. It's executing patterns we've already defined. The old constraint was headcount. "We don't have enough people." Now the constraint is algorithm quality. How well we've encoded judgment. How clearly we've defined what good looks like. Why Architects Are Winning Here's what I've noticed. Principal engineers and architects are adopting AI faster and deeper than mid-level developers. Their usage numbers are way higher. It's not because they're more technical. It's because they already think in systems. A mid-level engineer treats AI like a pair programmer. Prompt, review, accept, repeat. An architect treats AI like infrastructure.…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.