What we're learning from engineers getting the most from Claude Code
Workflows, mindset, and the anxiety most people aren't talking about
A few weeks ago, I spent a lot of time talking to engineers about how they’re using Claude Code. What I’m trying to figure out is how we help everybody become more effective with these tools – especially those who are still to the left of the adoption curve.
One theme kept coming up: some of our most experienced engineers are accelerating faster and having more success with Claude than those earlier in their careers. This is a direct flip of what we saw last year with the AI autocomplete tools (e.g. Cursor). Claude Code is intuitive for a lot of people, but there are skills and ways of working that some are still struggling with or unaware of. I think strong adoption of Claude requires a real mindset shift, and I see engineers quickly hit local maxima before breaking through to the next big unlock. That’s the problem I’m interested in solving.
So, I sat down with Principal and Staff Engineers Matt, Dan, and Jack for an open conversation about what’s actually working. It was informal – on the balcony in the London office, after work, no agenda. We ended up talking for over an hour about best practices and what we’re all still figuring out. I wanted to share what came up as I think it’s stuff we’re all experiencing, but could do a better job of talking about openly.
There isn’t one right workflow
Engineers can have different techniques with Claude, but there tends to be common themes.
Matt writes long, detailed prompts – “war and peace” was the phrase used. He front-loads all the context, constraints, and direction before Claude writes a line of code – like writing a really thorough brief for a teammate. This doesn’t necessarily happen all in one go, it accumulates through many turns. Matt also uses the “superpowers” plugin, which includes some workflows and skills that Claude applies when developing new features.
“I don’t usually ‘notice’ the presence of the plugin, but I definitely felt the improvement in the way Claude works,” Matt explained. “For example, it asks me questions more than it used to, which is great. It means it’s making less assumptions and forces me to give context where I haven’t realized it was lacking.”
Jack, on the other hand, will often start with long rambly prompts (his words) using voice input with WisprFlow – a self-described “yolo”:
“I can watch that stream of bullshit fly past and I’m like – no, you’re going down the wrong track. It’s not like I’m reading every word, but I just know,” he said.
Jack puts less emphasis on writing the perfect prompt and trusts that the LLM will parse his thoughts as he speaks them out loud in real time. He still gives Claude lots of context, but he’s more comfortable letting Claude get to work earlier and intervenes on the fly if he has to.
As he put it: “Don’t overthink it. Fast correction beats perfect prompting. Iteration is cheap. If it generates a mess, delete it, close the PR and go again.”
Despite using different methods, both invest in building up Claude’s context – and both are applying judgment, taste, and critical thinking throughout.
It’s a conversation, not a one-shot prompt
Matt, Jack, and Dan all take many turns to iterate on their plans. They treat it as an ongoing conversation, not something they need to get right the first time.
Start with the problem, not the solution: “I need to achieve X. Can you look at how this part of the codebase works and help me understand the options?”
Use Claude to help you gather context: “Explain to me how feature X works in this codebase. What are the key models? How does it connect to Fin?”
Shape the solution together: “OK, given what you’ve found, I think option B makes more sense because of Y. What do you think? What am I missing?”
Iterate on the plan before writing any code: “Actually, I’m worried about Z. Can you think about how we’d handle that edge case?”
Then build it: “Great, let’s go with this approach. Build it.”
That might be five, ten, twenty turns before you’ve written a line of code. That’s fine. That’s the process working well. Each turn builds context that makes the next one better – and it all stays in Claude’s memory for the implementation phase.
The engineers who seem to struggle most might not be investing enough in giving Claude the context it needs. Say to it: “Claude, build me feature X for this,” and it will – it’s very good at doing what you say. But it doesn’t know if what you said is the right thing.
An example from the conversation: someone shipped a feature, it worked and shipped on time. But when asked why they built it that way, the answer was: “I don’t know.” The code was fine, but the understanding wasn’t there. And that matters – for the next feature, for debugging, for knowing whether this was actually the right approach.
The fix isn’t “write better prompts.” It’s “have more turns.” Let the conversation develop. You’ll end up with both better code and a deeper understanding of the system.
Boris Cherny, who created Claude Code, works the same way: 80% of his tasks start in plan mode – multiple turns of back and forth before a single line of code is written. Once the plan is right, he auto-accepts everything, because “it’s just going to one shot it.” All the real work happens in the conversation; the code is the easy part.
Everything still has to happen – it just happens differently
When you look at Claude Code, the instinct is to think about what you can stop doing. It’s natural – the tool is incredibly capable, and we’re being told that things should be faster now.
But to get faster, there are foundational things people need to understand first. As Dan put it: “The mindset is not ‘offload the grunt work to Claude.’ Claude is the means through which you achieve the end.”
What actually works better is a different mental model entirely. Matt shared:
“Remember how we used to build things two years ago – ‘I’ve given myself a week to understand the matching system.’ That would have been an actual weekly goal back then. That comes down to half an hour now. But you still need to do it. If you skip it and go straight to ‘build me X,’ Claude will build you X without the understanding. And you’ll be in the position of having code you can’t explain.”
“Think about how you built something in a perfect way a year ago and take every element from it – every single element – and put it into your AI workflow. Don’t lose a single thing. Some of these things are ridiculously fast now, but every element still has to be there.”
Claude doesn’t replace any of the steps. It replaces the mechanisms – grepping through code becomes “explain this to me,” reading old PRs becomes “research how this was done before,” writing a tech plan becomes “help me think through the approach.” It’s the same process as before, but with these new tools, it’s dramatically faster.
Your claude.md is an investment
The engineers getting the most out of Claude invest in their local claude.md files.
For Jack, this was a minor breakthrough: “I realized you just say ‘can you please write this for my claude.md.’” You don’t have to author these files from scratch. Claude can generate them from what it learned during a session.
I saw this play out in a learning session last week. An engineer was using Claude to diagnose a complex defect, but Claude kept referring back to comments in the GitHub issue that were unrelated – pulling in noise from a different context entirely, which was frustrating and resulted in Claude and the user getting stuck. According to Jack, this kind of thing is bound to happen. The move is to identify the problem and help Claude understand what to do instead by writing it to your claude.md. “You can tell Claude: ‘hey, don’t ever do that again.’”
The engineers who are most effective have invested heavily in their claude.md files over time. Every time Claude makes a mistake or gets stuck on something, they encode the fix. Jack updates his memory multiple times a day. The advice is to treat memory as evolving operating instructions. Extract recurring patterns and encode them so the same problem never costs you time twice.
Our Senior Principal Engineer Brian Scanlan refers to this as “feed the flywheel.” As an organization we need to get better at identifying the best local optimizations and applying them to everyone, but the more we iterate locally, the more we’ll learn.
The anxiety is real – and it’s okay to talk about it
There is real anxiety about this shift, and a lot of people are keeping it to themselves. Apparently, there’s a term for it now: Deep Blue.
Some of it is about jobs. Some of it is about being judged – the worry that saying, “I’m struggling with Claude” will show up in a performance review somehow. And some of it is about something deeper: the craft. If you love building things – writing code, solving problems, that feeling when something clicks – there’s a genuine fear of losing something you care about. That’s okay, that’s human. If we can be open about that, maybe we can accelerate learning for those that are feeling it the most.
One of the people in the conversation described exactly this. They’d been afraid of losing the thing they loved about the job. And then they described the relief of realizing: “I’ve shifted how I build now, but I do still enjoy it the same amount. I feel like an engineer when I do it.” This was a feeling all the engineers shared. Once they let go of the writing code part, they realized they could move much faster and it was a lot of fun.
In my opinion, the best way to work through this anxiety is to lean hard into it. The genie is not going back in this bottle, and I personally would rather be on the forefront of this shift than be left behind. We are lucky to be in an organization that gives unlimited access to these tools. We should make the most of the opportunity.
What’s staying with me
A few things from this conversation that I keep coming back to:
There are new skills to learn. Some of the things that make people effective with Claude – planning, solution design, knowing what context to provide, thinking in problems rather than solutions – are often developed after years of engineering experience. That’s real, and it means we need to actively help everyone build these skills earlier.
Less has changed than you think. The value of Claude is not just writing the code. Every step you’d have taken before – asking for help, getting plans reviewed, researching how things work, iterating on an approach – still maps to a Claude session. The process of building something well hasn’t changed. The tools have. Making that explicit is probably the most useful thing we can do.
The conversation and the strategy are saying the same thing. Principles our 2x team are working to standardize (feeding the flywheel, giving agents problems not tasks, documentation as infrastructure) are emerging organically as engineers experiment with Claude. Best practice can be codified and shared.
If any of this resonates – or you see it differently – I’d genuinely like to hear from you. Especially if you’re in the group that doesn’t usually show up to the AI channels. Drop a comment below or send me a message on LinkedIn.
And if you find this kind of work interesting, we’re hiring across departments. Check out our careers page to learn more.
 | A guest post by
|