>I think though that the day is coming where I can trust the code it produces and at that point I'll just by writing specs. It's not there yet though.
Must be nice to still have that choice. At the company I work for they've just announced they're cancelling all subscriptions to JetBrains, Visual Studio, Windsurf, etc. and forcing every engineer to use Claude Code as a cost-saving measure. We've been told we should be writing prompts for Claude instead of working in IDEs now.
Honestly while I know everyone needs a job, just speed run all this crap and let the companies learn from making a big unmaintainable ball of mud. Don't make the bad situation work by putting in your good skills to fix things behind the scenes, after hours, etc.
Management has made it very clear that we’re still responsible for the code we push even if the llm wrote it. So there will be no blaming Claude when things fall apart.
I wonder how much cost savings there are in the long term when token prices go up, the average developer's ability to code has atrophied, and the company code bases have turned into illegible slop. I will continue to use LLMs cautiously while working hard to maintain my ability to code in my off time.
Realistically that's an increase of maybe a couple percent of cost per employee. If it truly does end up being a force multiplier, 2-5% more per dev is a bargain. I think it's exceedingly unlikely that LLMs will replace devs for most companies, but it probably will speed up dev work enough to justify at least a single-digit percent increase in per-dev cost.
“speeding up dev work” is pointless to a company. That benefit goes entirely to the developer and does not trickle down well.
You might think “ok, we’ll just push more workload onto the developers so they stay at higher utilization!”
Except most companies do not have endless amounts of new feature work. Eventually devs are mostly sitting idle.
So you think “Ha! Then we’ll fire more developers and get one guy to do everything!”
Another bad idea for several reason. For one, you are increasing the bus factor. Two, most work being done in companies at any given time is actually maintenance. One dev cannot maintain everything by themselves, even with the help of LLMs. More eyes on stuff means issues get resolved faster, and those eyes need to have real knowledge and experience behind them.
Speed is sexy but a poor trade off for quality code architecture and expert maintainers. Unless you are a company with a literal never ending list of new things to be implemented (very few), it is of no benefit.
Also don’t forget the outrage when Cursor went from $20/month to $200/month and companies quickly cancelled subscriptions…
> Except most companies do not have endless amounts of new feature work. Eventually devs are mostly sitting idle.
At every place I have ever worked (as well as my personal life), the backlog was 10 times longer than anyone could ever hope to complete, and there were untold amounts of additional work that nobody even bothered adding to the backlog.
Some of that probably wouldn't materialize into real work if you could stay more on top of it – some of the things that eventually get dropped from the backlog were bad ideas or would time out of being useful before they got implemented even with higher velocity – but I think most companies could easily absorb a 300% increase or more in dev productivity and still be getting value out of it.
I used to report bugs, read release notes; I was all in on the full stack debug capability in pycharm of Django.
The first signs of trouble (with AI specifically) predated GitHub copilot to TabNine.
TabNine was the first true demonstration of AI powered code completion in pycharm. There was an interview where a jetbrains rep lampooned AI’s impact on SWE. I was an early TabNine user, and was aghast.
A few months later copilot dropped, time passed and now here we are.
It was neat figuring out how I had messed up my implementations. But I would not trade the power of the CLI AI for any *more* years spent painstakingly building products on my own.
I'm using Claude in JetBrains, using the Zed editor's ACP connector.
It's actually pretty slick. And you can expose the JetBrains inspections through its MCP server to the Claude agent. With all the usual JetBrains smarts and code navigation.
Even if you're using Claude, canceling the IDEs might be poor strategy. Steve Yegge points out in his book that the indexing and refactoring tools in IDEs are helpful to AIs as well. He mentions JetBrains in particular as working well with AI. Your company's IDE savings could be offset by higher token costs.
Perhaps it would help if I include the quote, so from Vibe Coding pages 165-166:
> [IDEs index] your code base with sophisticated proprietary analysis and then serve that index to any tool that needs it, typically via LSP, the Language Services Protocol. The indexing capabilities of IDEs will remain important in the vibe coding world as (human) IDE usage declines. Those indexes will help AIs find their way around your code, like they do for you.
> ...It will almost always be easier, cheaper, and more accurate for AI to make a refactoring using an IDE or large-scale refactoring tool (when it can) than for AI to attempt that same refactoring itself.
> Some IDEs, such as IntelliJ, now host an MCP server, which makes their capabilities accessible to coding agents.
Yes, it's fantastic. Hard to imagine a better resource for getting started with vibe coding, on through developing large high-quality projects with it. It doesn't get into the details of particular tools much, so it should stay relevant for a while.
Must be nice to still have that choice. At the company I work for they've just announced they're cancelling all subscriptions to JetBrains, Visual Studio, Windsurf, etc. and forcing every engineer to use Claude Code as a cost-saving measure. We've been told we should be writing prompts for Claude instead of working in IDEs now.