.jpg)
It comes as no surprise that Al is one of the most talked-about topics this year, including at Menlo. Ask five developers how we feel about using AI to write code and you'll get five different answers. You might even get a different answer from the same person depending on the day of the week, based entirely on what the tools did for them that day.
You could probably figure out where someone stands just by walking through Menlo and listen for different opinions -
"This seems like a good Al task."
"Let's just ask Claude."
'It's so confident and also so wrong."
"This seems over-engineered."
"I just don't like using it."
We haven’t reached a consensus on Al, even as it has become remarkably capable at writing code. I don't expect that to change anytime soon.
We're using it anyway.
Not because everyone loves it, but because it's helping projects execute work more smoothly and more quickly, and our clients have noticed. So here's what using AI actually looks like for us, including the parts that haven't gone smoothly.
An example of how we’re using AI:
Our multi-year Harrison project began experimenting with Cursor with Claude about six months ago. The experiment started because the client asked whether Al could help with a major Python upgrade – the kind that touches almost every file in a massive codebase and demands a lot of patience.
One developer with agentic tool experience paired with another developer to tackle the Python upgrade with the help of AI. This initial experiment worked well enough that we kept going.
From there, we systematically spread the knowledge. Each week, that developer rotated to a new pair partner, gradually building proficiency across the entire Harrison team to use the tools effectively.
This rotation turned out to matter more than the tool.
Eventually Cursor was being used on every machine. With everyone using it, their opinions, including the skeptical ones, became part of how we use AI today.
It took time to get here. That was intentional. I'd be lying if I said it was all smooth.
What emerged is a repeatable process built around an idea the industry has started calling compound engineering: the work you do this week should make next week's work easier. Not just for humans, but for AI too.
Every iteration leaves something behind besides the code. When Al over-engineers something, the correction becomes part of its instructions for that codebase. When a planning approach works well, it becomes the template for the next plan. Over time, both the code and the context improve.
Feature generation gets most of the attention, but much of the value we’ve found has been in less glamorous work: reviewing tests and code coverage, building tools we needed for functional testing, spiking in design concepts, getting up to speed on an unfamiliar codebase in hours instead of days, and writing the investigative scripts nobody ever volunteers for.
How AI is changing the way we work:
Pairing feels different with Al in the room. Much of the work has shifted from creating and implementing a plan to verifying one. The hardest thinking now happens in a concentrated burst at the beginning of an iteration and tapers off from there.
I'm still getting used to that rhythm.
There's a certain mental satisfaction that comes from building something yourself. You don't quite get that same feeling when you’re reviewing an agent’s work. Some days that’s okay, but other days I miss it.
Then there's the speed trap. We've picked the more performant, more complex solution, finished it quickly with the help of AI, and felt great about it ... right up until an issue resurfaced a month or two later and we realized we barely remembered how it worked. Building it so quickly nothing had time to sink in.
Faster, more sophisticated code is a real win for our clients in the short term; we're still figuring out what it costs in the long term.
Estimation has become harder, too. When new scope surfaces for a story card, it's tempting to just fold it into the ongoing work because everything appears to be “fast and cheap” to build now. In the past that added scope would get spun off onto its own card. When you add to the existing card, and then do that a few more times, the Estimate vs. Actual retrospectives stop telling you much. We're trying to be much more explicit about catching ourselves before getting to "while we're in here anyway..." becomes the default.
Where we land today:
We’re still figuring it out! We have developed repeatable ways to use AI that let us deliver new features quickly in a way that keeps us involved throughout the development process. Beyond that, we’re still experimenting. Current experiments include:
- Improving how we interact with the agents while they're writing code, instead of only judging the output at the end.
- In kickoffs, regularly looking back at the architecture the Al produced and deciding as a team where it over-engineered and where it under-engineered. AI does both.
- Practicing creating and modifying architecture together in kickoffs, so we get better at steering the Al when everything is moving fast.
The tools will keep changing: new models, new harnesses, new practices.
Best practices will continue to evolve.
What keeps us steady through all of it is having every kind of voice in the room. The early adopters learn what these tools can do; the skeptics learn where they break. Every one of those five catchphrases at the top of this post has, at some point, saved us from a bad decision – including "I just don't like it." When everyone on the team has a say in how we steer the use of these tools, we end up with better long-term outcomes for our codebases and our clients, and we do it at a pace we can actually sustain.