Lessons from a Staff Engineer's AI AMA

Agents do more and more of the coding, but knowing the tools deeply, knowing the fundamentals and standing behind what you merge is still the engineer’s job. That’s the thread through John Kim’s AMA as a senior staff engineer at Meta, the follow-on to the video behind Review Depth Follows Blast Radius.

Learn the tools deeply, not just by using them

Day-to-day work only teaches you so much. He reads the docs end to end and tries every feature and hotkey, because some hidden feature can change how you work and you’d never find it by accident.

The balance: get expert in one workflow and stick with it, but run an exploration phase whenever something paradigm-changing lands, such as a new model or a new kind of agent harness. The skill gap is large; plenty of people are still on a chat window. That fits how I triage new tools (Staying Current: Awareness vs the Trigger to Act): a trial plus a read through the docs.

Use AI to learn, and slow down to do it

If an agent proposes something you don’t understand and your goal is to get better, stop and understand every term. He works through dense material a paragraph at a time with an agent alongside; it’s slow and it sticks.

Adversarial prompts (“grill my architecture”) help, but you can’t spot a bad design you’ve never heard of. Agentic coding is an abstraction, and abstractions leak. When the agent is stuck or confidently wrong, data structures, design patterns and clean code are what let you peel back the layer and steer.

Review: safety first, then quality

• Scale review to blast radius: shared infrastructure and hotspots get more effort from you and the agent; leaf code that isn’t wired in gets a light pass.
• Check gating and rollback before you check cleanliness.
• Old habits still hold: small, single-purpose diffs that are easy to test and revert.
• Ask agents for proof: screenshots, recordings, runtime data, tests (Don’t Read the Code? Verifying AI-Written Code).
• You own what you merge. “The AI wrote it” isn’t a defence in review.

Coding is mostly solved; engineering isn’t

With enough context and validation, writing the code is the agent’s part. Everything around it (deciding what to build, safeguards, review, operating it) isn’t. Permissions are trending towards longer runs with fewer prompts, made safe by guardrails rather than approval clicks.

Prototypes answer one question

Product prototypes are for feel: try the UX, barely read the code. For infrastructure, let several agents explore different architectures in parallel, then try extending each one. You feel a missing abstraction in the API in a way a diagram never shows. Prototypes aren’t for learning; for that, study the fundamentals.

Staff+ is a different job

Senior to staff isn’t a big technical jump; it’s behaviour. You have more ideas than you can deliver alone, so you create scope and bring people with you: staff is team-scale impact, senior staff is cross-organisation influence. The bar is technical excellence plus high EQ: easy to work with, not a pushover.

Moats, roles and teaching

• When anyone can build, the edge is domain knowledge, data and networks (Your Domain Is Your Edge).
• Roles blend: designers ship UI changes, engineers run their own analysis.
• Cheaper code means more code, which means more people to review, land and maintain it. It’s harder for juniors to get in, though.
• Teaching is how you stay sharp. Explaining something exposes the gaps in what you think you know, which is the reason I keep this garden going.

Where I disagree: app vs CLI

His view is that the mass market for AI coding will be the app: rich rendering, voice, drag-and-drop prompt queues. For the mass market, plausibly. I still live in the CLI, because it’s what makes coding from a phone work for me (Extreme Mobile Development, Revisited): an SSH client into a home machine, scriptable, composable with tmux and dotfiles, and it runs anywhere there’s a shell. It sits in assess on my radar until the apps’ remote features mature.