AI is changing how engineers work — lessons from the Claude Code founder's workflow

I spent 7 years at Google as an engineer — the last two building AI Agents, including a product we shipped at Google I/O. Now I'm at a Healthcare AI startup, using Claude Code/cursor daily for production work.

Recently I read Claude Code founder Boris's notes on how his team works. What struck me wasn't the specific tips — it was what they reveal about how engineering is fundamentally shifting.

Here's what stood out, and how I've adapted it in practice.

1. Design > Implementation

Boris's top advice: start every complex task in "plan mode." Invest in the plan, and Claude can execute in one shot. When things go sideways, don't push through — return to planning.

My workflow: I use Codex for engineering design, then Claude Code vs Gemini act as staff-engineer to give Codex a review, then back to Claude Code for plan + implementation.

The implication is clear: an engineer's value is moving upstream. The bottleneck is no longer "can you write the code" — it's "can you think through the problem with enough clarity that AI can execute it."

2. Context > Instructions

Boris recommends connecting Slack, Docker logs, and CI pipelines to Claude via MCP. When something breaks, just say "fix" — don't micromanage how.

This is a mindset shift. As engineers, we instinctively want to teach AI how to solve problems. But the real leverage comes from giving AI rich context and letting it determine the approach.

The skill is no longer "programming the solution" — it's "curating the context."

3. Write rules for AI the way you'd write system principles

Boris emphasizes investing in CLAUDE.md — a file defining how Claude should behave in your project. Every time Claude makes a mistake, update the rules. Claude is remarkably good at writing rules for itself.

My practice: I maintain both project-specific and global CLAUDE.md files. I aim for concise, precise rules in global one— similar to Asimov's Three Laws of Robotics. The rules don't need to be numerous. They need to be exact.

This is a new form of knowledge management. You're not just documenting code — you're documenting how to reason about the codebase. And it compounds over time.

4. Meta-learning: build systems that generate systems

Boris's advice: if you do something more than once a day, turn it into a reusable skill.

I've taken this further. I built a "skill generator" — a skill that runs after long conversations to identify patterns worth extracting into new skills.

One side continuously extracts reusable patterns. The other side cleans up what's outdated. This is how you scale yourself.

5. Challenge your AI — don't accept mediocre outputs

Boris: Make Claude review your changes strictly. Make it prove the code works by comparing behavior between main and feature branches.

My take: AI tends toward satisficing. Treat Claude as your reviewer, not just your executor. After a mediocre fix, I'll say: "With everything you now know, discard this and implement an elegant solution."

The quality of AI output is directly proportional to how much you push back.

Where I remain skeptical

Boris mentions he hasn't written SQL in 6 months — he lets Claude handle all data analysis.

I use AI for analysis as well, but when queries get complex, I'm only 70-80% confident in the results. Validating AI output on complex data tasks remains an unsolved problem for me. I'd be curious how others approach this.

The deeper shift

Working with AI agents daily has changed more than my engineering workflow. It's changed how I think about my own role.

I find myself constantly asking: What are the repeatable processes in my work? What can be delegated? What requires my judgment and nothing else?

This is the shift from executor to architect — from someone who does the work to someone who designs systems and orchestrates others (human or AI) to execute.

For engineers, the skills that matter are evolving: clear problem decomposition, system design, context curation, and knowing which questions to ask.

The engineers who thrive won't be the fastest coders. They'll be the ones who can translate ambiguous problems into clear specifications that AI can execute reliably.

This is where I believe engineering is heading. What's shifting in how you work?

HAPPY BUILDING