Is Your Team Still Hand-Chiseling Code?

If you go on Hacker News or to conferences and meetups, it’s easy to leave with the impression that everyone is using Claude Code or Cursor as a crucial part of their development process.

But if your team isn’t using AI yet (or using it as much as you would like), you’re probably worried that they, and your team, will fall behind. And you aren’t the only one.

In conversations with founders and engineering leaders lately, I’ve noticed that there’s a widening gap, and it’s only quietly talked about: many engineers are eagerly adopting AI, but lots are also rejecting it, either quietly or openly. They’re less than thrilled about the prospect of cleaning up AI slop or worry that it will take away their favorite part of their job.

And this is becoming a big frustration on both sides. Engineers who aren't using AI feel pressured into doing something they don’t want to do, and leaders panic as they watch other teams and competitors that are using AI speed ahead.

Here at Geocodio, Claude Code has become a key part of our workflow, and it’s exponentially sped up our development. Yet it’s also changed how our engineers spend their time: less coding, more architecture, more QA. That’s a big shift towards other parts of the engineering process, and it's understandable that some people would struggle with such a big shift.

But that’s a relatively recent development. Claude Code was released on February 24, 2025: less than a year ago.

I’d say that I myself was still pretty skeptical of the practical applications of AI myself until last summer, and even somewhat opposed to it given that my own book was included in the LibGen dataset used as training data by Meta and OpenAI. If you’d told me a year ago that I’d be writing this blog post, I would have laughed you off. But the benefits are undeniable, and I know we wouldn’t be as productive as we are without it. We can build full prototypes of features in a day's worth of work that would previously have taken months. We're tackling far more ambitious projects than we would have attempted before.

But I’ll shut up about that now, because if your team isn’t using AI, that probably only makes you feel worse, and that’s the opposite of my intent here.

So: how do you go from skeptical developers to a team that eagerly adopts AI?

I wrote a book on using empathy in product development, so you probably won’t be surprised to read that I suggest starting with empathy (and its crucial accompaniment, boundaries). You’re probably reading this because you’re set on your team adopting AI, and I’m here to say that you can hold that line while genuinely listening to and incorporating their concerns.

First, acknowledge that their fears are real. Yes, AI means they’ll spend less time coding, and yes, it means they’ll spend more time doing QA. Listen to them, hear them out, and make sure their concerns are handled in how you implement AI. If they’re concerned about quality, make sure to allocate time for building and maintaining custom tooling that allows them to define for AI what their definition of quality is. They’ll need to spend more time scoping and learning how to prompt, and that will take practice.

Take away the pain. Human beings are hard-wired to try to avoid pain rather than trying something new and risky, so use that to your advantage. Dig into your notes from 1-on-1s, and encourage them to adopt AI for the parts of their job they might find dull or draining, like writing documentation, writing a changelog update, or writing tests. Give them explicit permission to "cheat" on the stuff they don't like. You'll still see efficiency gains from this, and they'll probably be much happier in their job—and perhaps feel freed up to explore these new tools more—if you can start by taking away the parts they hate.

Shift towards the upsides. When someone is resisting something new, it’s often because they’re seeing the negatives rather than being excited about the possibilities. People who are unhappy often struggle to try new things, so that's why I suggest taking away the pain first and then once they're a bit happier, crack open the door a little more and try to get them excited about it. If they’re concerned about losing the craft of building, help them see that they’ll get to spend more time prototyping with minimal consequences, something they wouldn’t have gotten to do before. If they love the problem-solving parts of engineering, help them see that AI lets them try more solutions, not fewer. It means they’ll probably ship projects much faster, meaning they get to experience that fundamental common joy of engineers more often: building things that make people’s lives easier.

Like anything, social proof helps. If their friends and co-workers aren’t coding with AI, they may not have seen someone experience the “a-ha” moment. If you're not sure where to start, pick one engineer who's even slightly curious and give them a half day to experiment on a low-stakes project. Let them share what they learned with the team. That's how it started for us, and it's how movements tend to happen: not through mandates, but through one person showing another what's possible. (Or one person experiencing FOMO.)

Give them time to have the “a-ha moment.” If your engineering team is like most, their plates are probably already full. The idea of having to have what they might perceive as an intern write code for them and then QA that, on top of their existing work, is probably not a welcome assignment. “I can do it so much faster myself because I’ll do it the right way the first time,” they might be thinking to themselves as they stare down the prospect of editing some AI slop. Unblocking this means doing something that’s probably very hard for you: clear a day in their calendars and give them a whole day to build a side project on company time. You might be thinking about how expensive that is, but is it more expensive than your team not adopting AI?

If they still refuse, it may be time for a hard conversation. The other quiet conversation going on among leaders is what to do about team members who blanket refuse to use AI, even when they have been given ample opportunities and expectations have clearly been set that they are expected to make AI part of their workflow. Perhaps they have strongly-held environmental or ethical concerns about AI, and no amount of pair programming will alleviate that. If that's the case, it may be time to have a hard conversation about whether they're still a fit for your team. I hesitate to mention this and I hope you can avoid it, but the reality is that I know several leaders who have been in this position, even with senior-level team members. For leaders, the efficiency gains are impossible to deny, and it's like having someone who only wants to hand-copy manuscripts when there's a perfectly good printing press sitting right next to them. Turning a scriptorium into a print shop requires retraining, and if people refuse to retrain, they should probably go work for a scriptorium.

Our journey (and different perspectives) at Geocodio

Even though we’ve broadly adopted Claude Code at Geocodio, we have different levels of enthusiasm about AI. I mentioned I myself only started regularly using it myself last summer. Our junior engineer, Cory, considers himself a skeptic. Our CTO, Mathias, first vibe-coded a project this summer. One of our principal engineers, Sylvester, regularly blasts through his Claude Max plan. And our other principal engineer, TJ, is an AI leader himself.

To help you navigate your own team’s objections, I asked our engineers to be as honest as possible about how coding with AI has changed their work. I’ve included their full responses below. Hopefully their perspectives can give you some inspiration as you talk to your own engineers.

Sylvester Damgaard, Principal Engineer, Infrastructure: More Architecture, Less Implementation

I was not outright skeptical of AI-assisted coding, but I definitely underestimated how quickly it would become genuinely useful in day-to-day work. Six months ago, it often felt like working with very eager junior developers who frequently missed the mark. Today it feels much more like a mixed team, where some contributions are surprisingly strong and others need clearer direction and correction. The turning point for me was realizing that the quality of the output depends heavily on my ability to clearly define the task, provide precise feedback, and continuously review the results.

AI is now my primary tool, and I write far less code myself. My role feels closer to that of a team lead than a traditional individual contributor. I spend more time on architecture, intent, quality assurance, and iteration, while AI handles much of the implementation work. This allows me to experiment faster, change direction with very little cost, and focus on the parts of engineering where human judgment still matters most. At the same time, strong technical fundamentals remain essential. Without a solid understanding of the code and the surrounding ecosystems, it is easy for AI to take you in the wrong direction without you realizing it.

I feel significantly more productive and more empowered as an engineer, but also more accountable. AI is not a replacement for expertise, it amplifies it. To developers who resist it, I would say that the resistance often comes from a fear of losing the parts of the job you enjoy or feel confident in. In reality, the work shifts rather than disappears. To engineering leaders, adopting AI means helping teams build new skills. Clear communication, strong review practices, and a high bar for quality become even more important. It is not less craftsmanship, it is a different kind of craftsmanship.

Cory Stine, Sales and Support Engineer: AI Skeptic

I think it would be fair to call me an LLM skeptic in my personal life. I have some fundamental ethical issues with many of the larger LLM platforms, but more than anything, I just haven’t found a good use case for them day-to-day. When I’m not coding, I tend to like things that are analog.

For that reason, it took me some time to embrace working with Claude Code at Geocodio. As a junior engineer, I was concerned that by leaning too heavily on LLMs, I would lose out on the nuts and bolts of software engineering and miss crucial opportunities for learning. Claude can output great code, but it’s also important to know (and reinforce) the fundamentals or you might miss a bug or the opportunity to make things more efficient.

I took these concerns into account as I developed my Claude workflow. For the vast majority of tasks, I start by working on the project alone without LLM assistance. Then as questions or challenges crop up, I treat Claude like the step before reaching out to a more senior engineer, using it to clarify error messages, problem solve logic issues, or aid in refactoring. This makes things much more efficient since our team works asynchronously around the world and there isn’t always someone immediately available to assist me.

Claude is also perfect for repetitive tasks that might take time away from my other work. For example, I used it recently to add Fathom events to every link on our website’s NavBar, something that could have been very time-consuming, which instead only took a few minutes.

Ultimately, as a junior engineer, I think that it’s important to balance the efficiency of LLM use with the educational and professional value of good old-fashioned manual coding. I view Claude as a supplement to my existing workflow, not as a replacement. It is a tool to assist with my growth as an engineer.

TJ Miller, Principal Engineer, AI: Bullish, But Always Watching

I've been bullish on AI-assisted coding since Copilot dropped back in 2021. Even then, I could see where this was headed. But being bullish doesn't mean being naive. I've always been skeptical and cautious with the output. When I came across Aider in 2023, I was blown away by the potential. Then Claude Code came along and I knew we were playing on a different level entirely. And over the last couple months, Opus 4.5 has been a genuine game changer.

My approach has always been to treat agentic coding like pair programming, not autopilot. I keep an eye on it as it works and course-correct in real-time rather than setting it loose on a task and walking away. That mental model—AI as a collaborator rather than a replacement—shapes everything. I spend a lot more time now thinking through architecture, planning the right abstractions, and considering the broader implications of what we're building before any code gets written. And on the back end, I'm doing more QA and code review than ever. The craft hasn't gone away; it's shifted.

The result? I feel significantly more productive as an engineer. And here's the thing: I thought I'd miss the craft of hand-writing code. But I've found so much joy in this workflow too. I still find myself writing interfaces and public APIs for the AI to work with, making sure we really nail what we're trying to do and that the code feels great. The craft is absolutely still there; it's just expressed differently. For devs who are resistant: I get it. But you're not losing the parts of the job you love. You're trading some of them for new ones that are just as rewarding.

Mathias Hansen, CTO: From Toy to Transformation

AI started as a fun toy for me, something we used to generate bedtime stories for our daughter. When I first tried using it for coding, the productivity gains were questionable at best. I only reached for it on small scripts or side projects where the stakes were low.
That's changed completely. I've been writing code for almost 25 years, and this is by far the biggest paradigm shift I've ever experienced.

The way I approach problems is fundamentally different now. One of the biggest advantages is the ability to throw code away. If I'm trying to solve a problem but I'm not sure which architecture would be the best fit, I can have the LLM code up all three versions and pick the one I like best. I would never have done that before because it would have felt wasteful. Now, exploration is cheap.

It's also more important than ever to understand exactly what we're building. We spend more time assessing requirements and asking questions about a task upfront before we start building. It's never been this fun to write specs and plan, because you can jot down a few bullet points and have the AI come back with clarifying questions to complete your thinking.

As an engineer, you end up becoming more of a curator, overseeing everything and making judgment calls about the quality of the codebase. The craft isn't disappearing; it's shifting toward architectural thinking, code review, and knowing what "good" looks like. Prompting is now one of the most important skills a developer can learn. The LLM output is only as good as the input you give it. Garbage in, garbage out, but faster than ever.

When things are moving this fast, there's a real temptation to just keep shipping. But we can’t push out code that's buggy or has security vulnerabilities. Sometimes you have to deliberately slow down and be even more careful than before. When you're shipping more than ever, you're also creating more lines of code to maintain and a larger surface area for bugs. Human code review is more important than ever. LLMs can write tests that look correct but don't actually test anything meaningful. We often use a more capable model, like Opus, specifically for test generation and then scrutinizing the output.

Making sure Claude follows our existing code standards, patterns, and conventions takes real effort. You can't just point it at a task and walk away. You have to guide it, give it the right context, and review what it produces against the rest of the codebase.

Bring them along without mandates

You might be understandably tempted to enforce an AI coding mandate and call it a day. Yet the path forward isn't to drag reluctant engineers along. It's to meet them where they are, take their concerns seriously, and create the conditions for them to discover the benefits themselves.

That doesn’t mean abandoning your expectations and letting AI adoption inch along at a snail’s pace or letting truly recalcitrant engineers plod along without it. You can set clear expectations that this is where software engineering, and your organization, is going, and then work with them to get there. Not everyone will move at the same adoption rate. Give them time to explore. Pair program with them to teach them prompting and tooling. Create an environment that lets them experience the “a-ha” moment themselves.

They aren’t going to be true believers overnight, and they don’t have to be. But if you can help them see that the craft they love isn't going away—it's evolving—and that AI can be empowering for them and take away the tasks they dread, they might be more eager to come along.