惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

IT之家
IT之家
Microsoft Azure Blog
Microsoft Azure Blog
人人都是产品经理
人人都是产品经理
博客园 - 聂微东
博客园_首页
阮一峰的网络日志
阮一峰的网络日志
V
V2EX
小众软件
小众软件
F
Fortinet All Blogs
Microsoft Security Blog
Microsoft Security Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
H
Hackread – Cybersecurity News, Data Breaches, AI and More
量子位
Google DeepMind News
Google DeepMind News
Jina AI
Jina AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
aimingoo的专栏
aimingoo的专栏
B
Blog RSS Feed
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
宝玉的分享
宝玉的分享
有赞技术团队
有赞技术团队
J
Java Code Geeks
WordPress大学
WordPress大学
The Cloudflare Blog

Giant Robots Smashing Into Other Giant Robots

Client success starts before kickoff 5 easy, actionable tips for software development in healthcare Announcing importmap-update: automated dependency updates for importmap-rails When to vibe code an app and when to hire someone Why leaders have to know about PMS 🩸 Is AI ruining my brain? Tech Leaders Meetup is coming to Edinburgh Designers already think in React Tech Leaders Meetups are back in London this autumn GPT and Claude go to heraldry school Inserting State Transitions in Postgres AI makes creating software faster, but in regulated industries, judgment matters more Tech Leaders meetup in Amsterdam PMs Don't Need to Code, but They Do Need to Understand How healthcare tech teams innovate while balancing speed and security Can’t touch the DOM? Reach for :has() to style any element Buying Time, Choosing Words: Consulting Through Diplomatic Communication thoughtbot around the world, meet us at upcoming events Modeling State Transitions in Postgres Humid 1.0: React server-side rendering in Rails can be easy! A prototype is not a product. It's a conversation. New: The State of Software Delivery in Healthcare Sign in with Google for React Native What founders told us about working with AI tools for startups Join us: Building Secure Healthcare Systems Upcase has retired, but the learning continues The Bike Shed Ep 506: The Muppet Software Team Migrating to native stack navigation, with a surprise from iOS 26 Past and present thoughtbotters at LRUG this Monday The Bike Shed Ep 505: What is a “principal” or “staff” engineer?
Don’t hire thoughtbot to write code
Ran Craycraft · 2026-08-21 · via Giant Robots Smashing Into Other Giant Robots

If your primary goal is to buy the largest number of development hours at the lowest possible rate, you probably shouldn’t hire thoughtbot. That has probably always been true, but AI makes it a lot more obvious.

Code is ridiculously easy to produce today. Good code is not, and good decisions definitely are not. Coding agents can build working software at a pace that would have been inconceivable a few years ago, and experienced developers can use them to understand unfamiliar codebases, prototype solutions, write tests, investigate bugs, and ship production software much faster than they could before.

That’s great news for companies building software, but it should also raise the bar for software consultancies. Of course our developers write code, and they should use AI to write it faster where it makes sense. But if the primary value you get from thoughtbot is the amount of code our developers produce, I don’t think we’re earning the premium you’re paying us.

A premium consultancy has to earn the premium

For a long time, one of the most common reactions to a software team that wasn’t moving fast enough was to add more developers. We have this much work, we have this many developers, therefore we need moar developers. When you’re a hammer, everything looks like a nail.

The bar for that decision should be much higher now. If engineers are waiting on product decisions, another developer doesn’t remove the constraint. If customers aren’t adopting what you’re shipping, more engineering capacity just helps you build the wrong thing even faster. If a modernization initiative keeps stalling on architecture, adding implementation capacity is still solving the wrong problem. Headcount is not the diagnosis.

Being experienced isn’t enough anymore, either. Clients should expect senior consultants to move incredibly fast, use AI intelligently, communicate well, and understand the business problem rather than simply working through a backlog. If a contract developer joins your team and gives you exactly the same value as someone you can hire internally for half the price, you should hire the internal developer.

A premium consultancy has to earn the premium by getting to useful outcomes faster, finding problems earlier, and making the existing team better.

Sometimes the right answer is fewer people

Experienced team augmentation should mean bringing senior developers, product managers, designers, or technical leaders into an existing team to add capability, not just capacity. The right people shouldn’t create another management job for your leaders. They should help figure out why the work isn’t moving in the first place.

A company may believe it needs three developers and discover that an experienced developer and product manager would remove even more constraints. Another may actually need a designer and developer. AI makes these smaller, experienced teams even more interesting because each person can now operate with more leverage than they could a few years ago.

I’m skeptical of folks who believe one AI-enabled developer suddenly replaces ten people, but I’m equally skeptical that the team structures we built in the before-times are automatically the right ones now. We’d rather put fewer experienced people on the right problem than sell a client more people than they need.

That philosophy applies to budget, too. If the obvious engagement is too large, I’d rather make the team smaller or narrow the initial problem than compromise on the quality of the people doing the work. Budget constraints should change the shape of an engagement before they change the quality of the team.

You should expect us to disagree with you

If I’m paying for judgment, I don’t want consultants who agree with every decision I make. I want people who can disagree thoughtfully, explain why, test an assumption when possible, and then commit to the decision the team makes together. That’s partnership, and it feels very different from buying labor.

If you hand a consultancy a backlog and they efficiently work through every ticket exactly as requested, they may produce excellent software. There are situations where that’s exactly what a company needs. I’m just not convinced you should pay premium consulting rates for it.

The work where experienced consultants create the most value usually has some ambiguity. Maybe the problem is product rather than engineering. Maybe a prototype in a Shaping Sprint could answer the important question before anyone commits to a production build. Sometimes we should challenge the proposed solution or tell a client that we think they’re solving the wrong problem.

The client doesn’t have to agree with us, but if they’re paying for our experience, they should expect us to use it.

Hire for ownership and augment for capability

Companies should build great internal teams. If a capability is core to your organization and you know you’ll need it for years, hire. My rule is to hire for ownership and augment for capability, and sometimes you should do both.

thoughtbot is a much better fit when you already have a capable team and an important problem, but need experienced people who can increase your capability quickly. Sometimes you need that capability now, not six months from now.

AI is going to keep making software faster and cheaper to produce. I don’t think that makes experienced consultants obsolete. It raises the standard for what a premium consultancy needs to contribute. So don’t hire thoughtbot just to write code. Hire us when you need experienced people who can help you figure out what’s actually slowing you down, make better decisions, and solve the most important problems faster.