Wow, this really sucks. With all the money flocking to companies that trained LLMs on stolen data, we may lose the only set of IDEs that offer high quality professional development tools
There are even areas in which some of those best IntelliJ IDEs.
One such thing that Xcode has that IntelliJ doesn’t is per-pane history. In Xcode hitting back/forward navigates history for your focused editor pane whereas IntelliJ’s navigates history across all editor panes.
This might sound like a minor difference, but Xcode’s way gets me to where I want to go more quickly most of the time because I’m not having to wade through the likely-irrelevant history of the other panes. It’s a frequent frustration whenever I have to use an IntelliJ IDE.
Another example, it took several years for JetBrains to add mixed language JNI debugging in IntelliJ, between Java and C, C++. Something that Eclipse and Netbeans were already doing in 2005.
Just feels like they've been making all the wrong decisions. Quality has been really lackluster, and their attempts to hop onto the AI train have been as annoying as they have been bad. CoPilot sucked. Their own AI coding models suck.
The redesign they've gone for also seems like a supremely weird choice. It's like they're trying to be more like VS Code, when their probably biggest selling point was that unlike VS Code, they offered a full and traditional IDE experience.
Their trajectory has been a deeply questionable mix of change for the sake of change and nervously doing what everyone else is doing.
I don't think they can compete with AI IDEs. They should maybe focus on the niche that they are good at, and completely get rid of anything ML/AI related. It's going to be a lot cheaper.
They could establish a foothold in AI accelerated development but they sadly aren't doing it, instead focusing on "developing agents" (aka openclaw/pi/codex/claude simulacrum #9998).
IDEs are on a steep decline, so not so surprising. I've disabled most code extensions from vscode and find myself using multiple terminals and the built in git diff UI. I barely see the code, only care about the changes.
All the death knell comments - Is no one looking at the revenue line? Revenue still trending the same. Costs presumably haven't skyrocketed. They've invested in something big. Thats probably a good thing, and often needed to evolve.
Apparently, no one commenting knows how to read financial statements. They look at one item and assume the company is going out of business. Meanwhile, their total assets have increased. Cost of services have increased - mostly commensurate with revenue growth, although the gap has been shrinking. Operating costs have been pretty flat. I don't have time to investigate where they spent the money, but the company is not at risk. They brought in more money than in prior years and spent it on something. That's it.
Why are investments considered losses? It always seemed unintuitive to me as a layman. You made the profit and it's free to use however you want... investing it is a loss?
Probably AI spend and increased developer cost (salary + AI subscription cost). And the increase in memory prices means procuring IT assets has sky-rocketed too.
I would assume the margins they operated on, evaporated with the AI bubble.
> Is no one looking at the revenue line? Revenue still trending the same.
Yes. Companies have been looking at nothing but revenue for over 10 years now. You realize that a sustainable company has to look at net profit at some point?
Yeah, mind blowing after reading some comments which wen to conclusions without thininkg...
Look at the report (or point your clankers at it), not the saased helgi-pay-me-for-more, but free, full at CZ corporate registry. few tidbits from my fast (error prone) readin:
- main reason of net income loss is currency movement in 2025(CZK vs USD). eg. if they hold USD, they report loss without money moving. The other was bigger costs (but look below)
- they have 6% rev growth but ONLY in this CZK entity, whole group is whooping 25% up
- investing was lending (to subsidiaries) and outflow to bank deposits (sic!)
- cost increase impacting operating profit was from:
- “Other services”: +1,941, to 4,941.
- Consulting: +482, to 601.
- Marketing: +428, to 2,146
- Software development: -1,025, to 3,216
Looks fine for me and definitely not ai-doom-scenario.
why this is a surprise? I have 0 reasons to buy IDE in 2026.
Their main moat was smart refactor, and a few other nice tools to debug. regardless of what you think about coding is done, agents and your harness is the best tool. I heard they doing business accelerator to find a new business ideas. But as a company, hardly imagine anyone buying expensive IDE in 2 years. Why?
I still love my IDEA & Rider, but a lot of my attention has moved to VSCode with Claude Code plugin. The Claude plugin/tooling for these IDE's is abysmal in comparison (talking strictly about the Claude Code experience here - not the bundlende AI Assistant.
I am not moving away from JetBrains anytime soon, but it does gets harder to justify when I spend considerable time in a competing offering that has better experience and is free...
Yep, I don't remember the last time I opened up an IDE anymore. I mainly built my own open source AI coding orchestrator lol: https://github.com/saadnvd1/agent-os
The landscape is changing significantly, and I think these types of tools will become more popular.
Yep. Especially considering their primary userbase are technically apt developers, there's zero reason to use any of their products. Especially given how quickly the landscape is changing.
Unfortunate because they make great products, but also expected given AI. A bit like Nokia, they're a great company that didn't do anything particularly wrong but they got swept by a superior technology.
They keep trying to bite into AI but they should focus on making their tools more stable and should have invested more into Kotlin Native, could of had a fully native IDE and tooling by now and purged reliance on the JVM.
Cause Cursor was so massive? JetBrains is not just some random niche company, they're used in 88 companies out of the Fortune 100, that's nothing to sneeze at.
I still haven’t found an IDE that I feel really helps me develop with AI better than the command line. I have built bespoke tools that work the way I want. But a really good integrated solution would blow my current workflow out of the water. No one seems to have built an IDE with deep support for worktrees, parallel session, walking me thru diffs, and optionally handing control back to me to write the occasional hand-written code myself. Plus most of my work is done on mobile, so Jetbrains has an amazing opportunity…but they seem to be chasing the competition instead of focusing on their moat.
Sublime was/is still the best, unfortunately had to finally abandon it due to lack of first-class agent support. Hard to find something that emphasizes core text editing first and that doesn't constantly have some new update to apply on start that may break or change something.
I'm not sure what the problem is after rereading their post? All you need to support everything they said is a remote connection to a heirarchy of worktree-supporting sessions per project, with each having a proper scrolling feed of agent actions taken and your input box.
When you are paid to sit on your ass to review as much generated code as you can, or to create as much good code as possible given the constraints of a limited amount of tokens, sure. But when you're on your own clock, the trade-off between latency, token budget and quality shifts considerably. And when it actually is a side project (yeah, many meanings of "serious" will be out, I give you that), mobile is just awesome.
That slow trickle of back and forth that gets our intelligent machines called "toasters" in a way not predicted by Battlestar Galactica at all, that really starts shining on mobile. Hands off on terms of signing off every little detail, hands on in terms of never being too far out of the loop, keeping the unattended steps small.
Maybe something like delta? This is still pretty new from the folks that make Zed, but looks promising and would address some of the things you mention https://delta.dev/
Yeah, one limit for me is I need to use the subscriptions, so I'm tied to the Claude Code and Codex harnesses. The best solution IMO is a "bring-your-own-harness" one, where you can drop in whatever harness works the best for you and your development environment can be driven by it.
Air itself as well as the new Air plugin for the IDEs and the AI assistant support ChatGPT subscriptions, though you may have to disable JetBrains as a provider so that it's not billed against that. (It's weirdly called logging ot of JetBrains, though you still remain logged in to JetBrains for all other purposes.)
Anthropic is a different story, but I think it may still be possible via the Claude ACP agent (JetBrains' support of ACP is generally pretty good; I use it with anothe harness for open weight models regularly).
Right now there's a huge friction with IDEs, that if I have it open while claude is working on something, then any caches it has get stale very quickly, and it churns processing trying to keep up with edits.
Any leverage that claude could benefit from LSPs or language/AST MCPs is undone by that tooling not being able to keep up or stay fresh, so the IDE just "runs hot" for no purpose.
Which means I'm incentivised to close my IDE while claude is working, and now I've got used to not looking at the code.
Like you, I really want a system that works better. I want claude to search and edit through better tooling, it would be faster, more accurate, and should in theory be able to leverage compilers to apply edits better and more accurately.
I don't want claude wasting an awful lot of time grepping for things that a compiler cache can answer, but if that compiler cache can't keep up then it's actively harmful.
I'm sure there must be a better way, there must be a way to have smarter more change-aware cache invalidation, and smarter more cache-aware claude tool use, but so far none has happened.
Long term I'm sure the pairing will emerge, but unfortunately I don't think that's going to come from the IDE vendor side, it'll have to come out of some harness research lab, where Anthropic or a competitor finds a way to reliably leverage this stuff for a speed and accuracy boost.
It's completely bonkers to me that an LLM can almost "natively" read profiler output, but doing so involves vast amounts of text and context ingestion, when there are real tools sitting there that it ignores in preference for either reading vast amounts or iffy python one-shot scripts to parse stuff.
This 100%. My current workflow is switching between CC and VS Code to review code, and it's extremely clunky. There is still not a single harness/ADE that can do everything correctly in one tool.
Cursor has support for work trees, parallel chats, will walk you through diffs line by line. This is what I primarily use for the walking through diffs feature. If I need something to just throw over the wall, I fire up claude.
> I still haven’t found an IDE that I feel really helps me develop with AI better than the command line.
With Codex GUI app and Astra you can communicate through screenshosts and collages. WAY faster and more precise for many types of jobs and workflows. Literally just scribble crap into the screens and it knows... no need to write out 50 paragraphs of prose to describe a button and its position.
I will have to try it out. I haven't tried it yet mostly because it seemed like it costed extra or would put me on API pricing. I have tried a workflow with Android Studio with Claude Code, but whenever I opened a worktree it took 5 minutes for Gradle to sync.
I’m trying to contextualize this information. JetBrains isn’t publicly traded best as I can tell, and these numbers come from other public filings:
> Figures are the company's own (unconsolidated) statutory statements filed with the Czech business register…
Are these as reliable as the U.S. 10K or its European equivalent?
I assume that a company like JetBrains would be investing in shifting products around A.I., so it doesn’t seem too surprising that they don’t report a profit for 2025.
A bit tongue-in-cheek but I'm amazed by people that don't open an IDE or look at code. Are you paid to press enter at anything that Claude present to you?
Personally I usually use Claude inside the Jetbrain's IDE terminal, even if I code by hand obviously less. I still like using the diff, navigation, quick access to any file path for my prompt etc but maybe that won't last.
I used to use Claude inside of a terminal within Webstorm until I realized I rarely looked at the code in the IDE. Instead I was creating draft PRs and reviewing the code in github. Now I use claude inside of herdr, and I appreciate having more screen real estate devoted to claude. As a long-time Jetbrains subscriber it pains me to stop using it. But at this point, I'm not sure what they could come up with that would be compelling enough for me to switch back.
Their coding agent "Junie" is actually really good. The problem is they force you through only a few curated models. And try to funnel you through them to subscribe to do it, too. It's not like Pi or opencode that lets you just point at an OpenAI API endpoint and then choose whatever model. If I recall you can even actually use local models, or openrouter etc, but only use the specific model variants from their curated list. It's insane. They tried to stick themselves in the middle, and failed. Nobody will use it.
They've also done so many pivots on AI, all of them weakly and annoyingly done. They couldn't even pull of FiTM copilot well, they were super late on it and it had all sort of bugs.
They could have just taken the loss and written an amazing GUI coding agent that integrated well with their IDE -- amazing integrations with their refactorings, etc. -- but that played well in other people's ecosystems but they refused and tried to own the whole pipe. Or something. They just confused me.
Their latest attempt is to allow you to connect to and run other people's agent harnesses inside the IDE and it works well enough but it wasn't enough to grab me since I (like you) use herdr on another machine to do the coding.
I've been using their products since ~IDEA 3.x. Almost my entire 25+ year career really. My fingers are wedded to their keystrokes.
You can actually configure the ide with any open ai compatible endpoint, I use llma and it lists all the models that I have currently installed, works well. Or am I missing your point?
Junie in particular, or just their various other "AI Assistant" / "Chat" things? They have multiple confusing overlapping products/modes going on. "JetBrains AI" -- which may or may not be same as "Junie"?, "AI Chat", then there's the "Agents" tab which integrates outside coding agents.
I guess they iterated quite a few products to "not get behind" and see what sticks.
Most recently they integrated air, which is basically an "agent management/orchestrator" where you can run any ACP-compatible agent with any model you want and it's just the single place where you manage them, see their progress, steer them, merge their results etc.
AI Assistant > Providers & API Key
There is an option Third Party AI Provider, where you can select OpenAI compatible, and then you can customize where (core, instant helper, inline etc) do you want to use third party, where JetBrains.
JetBrains face a unique problem: they are a real business that can't just raise infinity money from SoftBank or request government bailouts because the sheer size of their debts imperils the financial system. So they have to do things that might seem annoying or overly pushy versus their competitors.
For their entire existence people have complained about JetBrains this way because they always face some competitor that isn't making money and isn't even trying. Eventually those competitors go down, but a new one instantly arises. People just really love losing money on developer tools.
Wanting to charge money for an AI service is a clearly sensible business move. If their competitors weren't shredding the world's entire supply of investable capital as quickly as possible, this would be a good strategy. Alas.
Using a CLI coding agent in your IDE's terminal is a terrible way to view conversation history and works poorly for organizing multiple conversations.
It only fits a hands-on, merely AI-assisted development approach, on one feature at a time, that is not typically productive compared to agentic development.
You might disagree, but you'll find that the proponents of the hands-on approach are losing ground every month as AI gets better at working autonomously.
Except surrendering cognitive control over the system being built makes things worse.
Claude constantly makes poor architectural decisions, adds unnecessary and costly checks, makes wrong assumptions, etc.
Doesn't take the value out of LLMs writing code, but they need to be properly steered and reasoned with. How will you do so if you don't even browse the code it generates.
I always suspect that the people all in fully agentic codig like this are mostly creating prototypes, half-assed copies of existing products, etc.
This doesn't say much. Plenty mobile apps, even paid ones, are of shovelware quality. And even if that's not the case, it's typically something very self-contained and of relatively low complexity.
On my personal projects I also seldom need to review code very thoroughly. But it's also not super complex stuff.
At my workplace things are not like that. It's a very complex system on a highly regulated environment. Opus 5.5 constantly get things wrong in ways that are simply not acceptable.
And I am not even an AI naysayer. I accept it as another development tool.
Agentic development is basically a scam IMO. I’ve written about this before, but collaborative coding with AI is a huge productivity boost and you can still own all the quality. Ultimately with agentic development there’s too much you can’t, and won’t, review. The quality slips out of your hands.
I still read all the code AI produces, and I have a specific workflow. I scaffold the API first using AI, then review it for quality. Then I write tests, and review them for quality. Implementation is last, and technically I need not review the code but I choose to.
When I’ve done agentic development, the only thing I’ve accomplished is 100x more token burn with lower-quality code. It’s also not faster, because the tokens cost time and so many mistakes are made that must be cleaned up. The agents burn so much time going around in circles, when I could’ve just steered the model to write a good implementation.
Keep in mind, this is very fast. Models still produce thousands of lines of code in mere minutes. And with tests backing them up and an API frozen, the model goes much faster as it can iterate and has a framework for what it’s doing.
I think you're paid to deliver. Lots of developers for decades have delivered crap that looks good on the surface and is otherwise unmaintainable. Now we're reaching the point where "everyone can code" and review queues are getting too long, with the result of many PRs being yoloed.
This of course varies by company but this is clearly where it's headed: bot pushes, bot reviews, you look at the PR title and click merge.
When you give a ticket to a jr developer, do you look over their shoulder the entire time they write the code? Or do pause to answer questions, give feedback on how to go about a task, and review their results?
JetBrains still has best tooling for previewing changes, resolving conflicts, git integration. I get that vibe coders not necessarily need all that but it's the best class tooling money can buy.
I’m sure there are people who aren’t looking at the code at all. But for those that are I guess I’m wondering why bother with an IDE anymore?
I’m finding I can just review everything I need to with a text editor like Neovim now. Even GitHub review is probably good enough for people.
Personally I don't use CLI anymore, Codex app is very good and it starts to look like how IDEs will be in the future. You can review code in a GitHub style diff and leave inline comments (super useful), have multiple agents work in parallel with or without worktrees, plus there is very good code navigation (especially if you ask followup clarification questions that will link to other parts of code).
Related, it amazes me how many seasoned developers don't know how to do basic tasks in their editor/IDE with the keyboard and instead rely on their mouse. Most people don't need to be super users, but it baffles me when I see a developer who hasn't at least learned the keyboard shortcuts for opening files and jumping to functions/methods, etc.
I’m only a mild keyboard user in IDEs, but I think I’d go mad if the keyboard shortcuts for quick open, jump to line, jump to function, etc suddenly disappeared.
You will be surprised by how many professional software engineers don't read their code or care these days.
I have seen a bubble sort function in a PR from an engineer with 20 years of experience. Meanwhile sort from standard library is easily available with one single line.
The bar has become as low as "it works" without considering what's in the code or whether the entire feature should even exist at all.
P.S. that same engineer sent out a PR of 200-file feature. The PR is so large that it freezes the latest MacBook Pro if you try to read it. Nobody reviewed it and he merged it himself. Nobody uses that feature, and nobody in the teams wants to maintain it. Now we are considering scrapping it.
It’s so easy to generate a pile of crap now that it “just works” as you say.
Quality, maintainability, simplicity, understandability, flexibility etc all still matter at $DAY_JOB, where you’ve got paying customers. We’ve got a responsibility to write good software that adds to people’s lives.
I’d recommend to try to raise the bar. Commit messages written by humans, no PRs above a certain size, any PR needs an introduction / explanation by author first for the reviewers.
The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
So it's already an improvement. Should it be manually read, comprehended, reviewed? Probably. But they can get to an improvement over what they did 2 years ago, with basically no effort. And then they can get a little bit further, with massive effort?
The "LLM-yolo" is a big knee in the cost/benefit curve. It's an improvement over their "old code". The only drawback is: it's still containing bugs, and now no one understands them. But that's not hitting them until that code has aged somewhat, so a year or two down the line.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
If mediocre code is better quality than what you wrote by hand, you've quickly discovered that you're incompetent.
The problem with hand review I always had was trying to teach the other person. You don't want to present them with an avalanche of problems. So you pick the most important 5. Over time this iterates and you build someone good at what they do.
The good part of LLMs is you don't have to worry about overloading them: you can just outline every problem with the code they produce.
The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
There's also the problem of this ultimately being my code. It isn't Claude's - Claude isn't a person.
I still read the code. I use LLMs to review it. But I also review it myself. Ultimately its faster than before, and probably better quality (because I can just give all the problems to the LLM), but slower than people doing zero review.
> The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
After I give feedback to the AI I then ask it if we learned something and then I ask it to store that guidance in a relevant skill file.
I have skill files for everything and anything in my project. Three just for testing - one for frontend, backend, and e2e. I have one just for frontend forms. I have one for project terms, which I ask it to read before doing anything, so it keeps the terms in the project right. I have one for doing db migrations and one for doing backend routes. I have many tens of skills that have been slowly built up like this.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Not my experience at all. Mediocre LLM-code, mediocrely reviewed is a loaded footgun aimed at both your feet.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Emphasis mine.
I can't phantom some that bad at coding. Using such exaggeration void your comment.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
No, I find that most teams I've been on have 5% to 20% of their most artisan engineers actually giving a shit about the code, and gently coaching the other 95% to 80% of the engineers who are usually much more junior during code review to not push unmaintainable slop. If you're on a team that doesn't still have someone giving a shit, it's not a sign that there are no teams that don't give a shit, it's that you're on a shit team.
There are also teams where the incentive is to get to pull request (or merge request) as soon as possible, so that you can move the ticket across the board and relieve downward pressure. That usually means pushing subpar code to PR that you know you'll spend another few hours fixing.
Anyway, if you're on a shit team, but you're still satisfying product and nothing is blowing up yet, there's a pretty good sign that your software has no moat and will be the first to be replaced by LLM-generated software on-demand. This is probably where most niche B2B back-office, front-office software sits. Stuff that sits somewhere in the realm of "We could probably do this in Excel if we wanted to."
When you get paid to care, you will care. Unfortunately, no one cares, they just want results, any result. Bubble sort will do, especially for low volume tasks.
Use the time you save by not caring, to do other fun stuff.
> Use the time you save by not caring, to do other fun stuff
What kind of time do you save, especially at work? At any normal software shop you have an endless list of things to do. And most often you don't get to choose the "fun" part.
Bubble Sort. It's like a joke you couldn't write. This kind of thing is awful if this is how engineering is going for user-facing apps, but disastrous if this is how it's going for infrastructure and libraries.
It's interesting your complaints are similar to mine about TDD. I've dealt with so many engineers that assume that coverage and passing tests is the bar.
Had AI do some work parsing markdown with the leading library for it.
Follow up work to generate markdown? It wrote a mess of manual string building instead of using said library lol. Even with strong AGENTS.md guidance around using existing and leading community libraries they will often take a hard left and write stdlib straight into your repo.
Y'all should scrap that feature and maybe the engineer. I believe the Shopify CEO recently referred to those types of PR as "slop grenades" that cause headaches for everyone else..
This is not overly surprising to me, the last decade or so has seen the industry become a "good job that pays well" and many people got into not for the love and craft, but for the money
I dont think it has as much to do with that as it does rising expectations from leadership to just ship MORE.
MORE MORE MORE like AI has given executives an excuse to ratchet up performance expectations by at least 3x (as in my company) up to 10x for certain start ups I've heard.
There's literally not enough time for a human to do all the activities around quality they were doing even a year ago.
If you need to review every edit that claude wants to make what's the point in using it? We're now treating it basically like a junior dev. Do our best to make sure that it's on the right path (leaning hard on the superpowers plugin) then let it work and look at the result. Though even that review is heavily AI assisted now. Our leadership has mandated that everything that can be done by AI, should be done by AI. We've only been in that mode for a couple of months but I'm starting to think that it's plausible with proper human steering and oversight.
I'm not being flippant. If I need to sit and watch a claude session reviewing every edit it makes, that's slower than me coding the changes by hand. Either it's good enough to work independently or it's not worth using. I have no idea how Google is using AI, but from what I've seen at my own company I do know that using AI effectively _and_ setting up repos/projects for good AI usage (and with guardrails to keep AI in check) are both acquired skills. Skills that the majority of devs don't have right now.
Really the single biggest piece I use today is using a tool like superpowers to ensure your task is well defined. Added bonuses are its TDD implementation skills and multiple review steps baked into the workflow. Before I discovered superpowers I was manually telling claude to do these workflows, the plugin makes it easy.
In the repo itself:
* Keep agents.md focused; claude likes to really bloat it by default. The "Adding guidance for AI agents" rules go into every project and have worked pretty well.
* Aggressively use nested agents.md files. Focused rules located where they're relevant seem to do much better than having a large whole-project rule dump in the root agents.md.
* Recently I've started using the tech debt and deferred work documentation rules. Claude frequently decides on its own that some piece of functionality or issue is "deferred until later" or "out of scope". These rules help make it clear so that you can make it fix the item or at least have it documented for a followup session.
* Have it test all the things. Most of my personal projects with claude have about a 3:1 ratio of test:application code and high coverage. Claude make it easy to build test harnesses for things that most of us wouldn't have bothered with 5 years ago.
* Strict type checking, linting, static analysis, warnings as errors, etc. Anything you can turn on or add to block questionable code, do it.
* Use a claude pre-tool hook to run all of your checks before you allow a git commit command. Left on its own it can and will decide that it has a valid reason to bypass git commit hooks (husky) to commit broken code or tests.
I do look at the code and have to correct Claude most of the time, but I've noticed that with AI-assisted coding, I mostly look at the diffs when i'm inside IntelliJ. I don't need a pricey full-fledged IDE to just look at files and their diffs.
> Are you paid to press enter at anything that Claude present to you?
I mean, sometimes work falls exactly at the tool's strongest suit/match.
I am trying to think of what a comparison here could be but, for example, I remember early days in my career where pretty much 80% of the work was writing boilerplate and using scaffolding/generator tools, plugging them in the various plumbing and pipes of the stack, and just ticking boxes through Jira
Lots of "CRUD" and/or similar "recipe" type of work that was really just turning your brain off and needed that grunt labour force
You may ask: why is the person even needed?
My answer is the same as before: I don't know, I didn't know why were they needed back them either, felt like all could be automated as well, maybe the cost to invest in automating and mapping that all out was never a priority and the ROI math was "good enough" for the business while leadership had other north stars they were worried about?
I'm slowly accepting that this is the new reality.
I've spent 1 month between august and early september writing some of the best code of my life. LLMs only provided feedback, I wrote all the code manually, still remember it by heart.
I was very delighted by the many architectural iterations that led to it. 9 files, around 10k lines of code (of those, 7k tests).
By the end of super funny exercise I kinda realized that if I had the same feature vibe coded it would've been better. I would've done much more and progressed more feature wise.
I just feel stupid hand writing my code.
It doesn't help that I work with stellar individual contributors. All of my team mates (except a junior) are either all former faang or contributed to projects we all use (from the TypeScript compiler to Linux). And they are all abandoning if not spearheading the abandonment of reading code. I'm talking people that truly loved the technical aspect of it and excelled in it.
I just feel stupid, like I'm carrying a weight that I should abandon.
Comments like yours feel would've made sense 6 months ago, but now are crumbling.
Software is essentially so cheap and throwaway nowadays that letting LLMs write it is imperative. When you find your use cases you start reviewing it or rewriting it thoroughly.
I’ve been using agents to do the code for me, but I explicitly tells it to iterate in small changes that I can review and approve as it happens, not after a 2k lines diff. It makes me understand what’s being made, and test every little change before we move on to change other parts of the code. Also helps you correct any misunderstanding right from the start.
I am mostly happy with Neovim with an LSP integration. I'm not going to say it's "lighter" or anything because rust-analyzer isn't exactly "small", but it is a simpler, and IMO "cleaner" interface. Also completely free.
I keep lazygit open next to each Claude/Codex session that's working on a change, but over time scrolling the changes has gone from necessary to just out of curiosity.
At this point of 2026, if you're reading code and still catching things, then the problem was your workflow I think. You should have decided more high level preferences like invariants before the work began.
I just look at my own diffs in a draft GHE PR and iterate with my agent on Github. This is often a much better UX than trying to make sure every single linter or thing is consistent between my machine and the CI machine. We do use Docker but it's still just easier to do it all on the CI box / Github.
I switched to vscode because the complexity and runtime overhead of intellij were no longer justified with Claude writing most of the code. I work on a big java code base and every two days I had to wrangle with intellij cache, clearing it or what not. With Claude I'm working in multiple work trees at the same time and this just amplifies every issue intellij had with slow indexing and broken caches. And TBH nowadays I eyeball the code more than read, so a basic code editor with navigation seems enough
I was at a product developer conference a few weeks ago (will keep the company name private for now), and the speaker asked the room, How many of you are "still" using an IDE to create your applications, implying that if you are using an IDE, you are a dinosaur. I don't believe that but some company leaders are thinking it.
I've found that reviewing generated code, leaving comments, and asking Claude to address my comments is usually enough. When it isn't, a common editor is usually sufficient, and an IDE takes too long to start for the very small change I want to make.
> I'm amazed by people that don't open an IDE or look at code
Oh, boy, here we go... Sighs and pulls up a chair.
Using an IDE has nothing to do with looking at code. The best engineers I've ever known use what JetBrains aficionados would refer to as "editors", not full-blown IDEs. To a person, not one of them felt as though they were missing anything they wanted or needed. I would probably even say "Unix is my IDE". I have a terminal chock-full of advanced command line tools to search and manipulate codebases. It's always fun and convenient when a GUI gives easy access to those things, but it's just that: a convenience, and only when the GUI exposes the full option set of the underlying tool, which they almost never do. Basically, I can alt-tab to a terminal, press up-arrow to expose "cargo build", and hit enter to run it, about as easily as someone else can select the build menu in an IDE. Further, if that build menu option is any less configurable than Cargo.toml, I'd prefer the text config any day. And finally, "cargo build" works with any editor I'm using that day, even if they don't their own build system wrappers.
IDEs are fine for people who enjoy them. I grind my teeth whenever anyone hints that they're remotely necessary for, well, anything, or that people who aren't using them are somehow missing out on something. We know what we're missing, and frankly, we're not missing it.
Actually I really only need bare vim now. It's really refreshing. I can view, navigate, diff etc without any fancy plugins. I can add comments where I want the agent to change something.
Why's that? Ruby on Rails is a fantastic framework. My point was that if somebody who has done the work before AI agents is now following the footsteps of not reading code, then why are we still telling people that it's still useful to read code?
The quickest sign I have right now to find if the developer/team don't read their code is looking at their recently AI-generated test cases. Often, coding agents go too verbose in their tests and they are most often overlooked even during normal reviews. If there are verbose tests, like declaring a constant and asserting it's value, you know that the code isn't being read much.
Jetbrains lost our entire (small) team a few years back when they completely neglected (no, to minimal progress for years) their typehint support in PyCharm. I think they now finally have caught up somewhat judging from the updated on all the issues in youtrack I'm still subscribed to.
What did your python people move to from pycharm? Every team I've worked on has been about 30% python (70% go) and the python people have always had pycharm installed and ready to go for their python days.
I've always had a personal ultimate sub even though I use vscode 99%. There would be a lot more ultimate subs barely used like mine if they weren't 3-4x the price of the singles. I've never felt justified in asking for ultimates business price for how little I use it, but my teams always have a pycharm license.
The real surprise is how small their balance sheet is given they're such a well known and loved name. 16m CZK is 0.7m USD annual revenue.
There are companies where you'd rather be the owner, and others where you'd rather be an employee, or a customer. I think the JetBrain's customers are the real winners in this one.
An IDE connects a human coder to the development process. If the role of that coder changes in that process, the IDE connection is not going to be as heavy as it used to be.
It isn't as much the price of a license as much as the time it takes to get approval for newer engineers and contractors. You can just say, "we use vs code with these extensions and wsl2" and the discussion is over.
All the air is getting sucked out of software companies due to AI, I'm seeing it happen in a number of places. Though in this case it may be due to their own AI investment on internal projects.
It's purely management fault, it happened around 2022-2023. They had all the chances to become a great agentic IDE/harness at some point, if they would start in time, support plugin developers, allocate a proper team instead of 2 people and some semi-random internships. A lot of users were questioning this publicly and privately with them, we all knew how it will end this way. JetBrains lost, no one wants their Junie in 2026 (and didn't want in 2024-2025, whatever was the name of the integration at that time, it was awful). I was on Ultimate Plan since 2012, appx. I quit entirely in 2024. They asked to answer a few surveys over the last few years - even the questions there were far from reality. RIP, JetBrains, it's mostly unrecoverable at this point.
That's totally fine, I'm pretty sure people continue to use JB by inertia, requirements, personal preferences, lack of alternatives, inability to introduce some, or whatever is the reason behind. It's all for good. Most (I'd even say all) people I know jumped off paid JB products within the last two years (C#, Rust, Python, Web stacks), even being evangelists previously (I was religiously protecting and advertising JB in all possible holywars). And in 2023 we already were betting if there's a place for JB "as-is" in the current/future landscape. Too slow, too enterprisish.
Their management decisions are strange, right. They had a nice tool called Upsource, we used it for code reviews. Then they sunset it and told us to use JetBrains Space instead. After we migrated to JetBrains Space, they said, oh wait, we sunset it too. So we had to migrate to GitLab. And now, with AI-assisted coding, I don't even need their IDE anymore, because I mostly look at diffs. And that kinda brings us back to Upsource. That thing could have been grown to support AI-assisted development, like, get rid of all the heavy IDE stuff, and just have a place for code reviewing agents' output and merging things. Somewhat like GitLab Lite but fully agentic-oriented. I think it would have covered 99% of our use cases.
I heard rumors JetBrains started going downhill around 2022-2023 because they severed ties with employees in Russia's St. Petersburg, which housed their R&D and all (although many employees were relocated but who knows).
I had a chat with some of their product team. Both Upsource and Space failed to get enough market traction to justify the continuous investment. Same with Code With Me.
On Space case, I think they felt it became too complex to maintain internally while other great alternatives were very hard to compete against.
They were sad about it, as they really worked hard on these products, but it's also easy to understand why they make the decision. Despite the tools being nice, if nobody buy them, it's just a loss.
I didn't use it because it wasn't open source and didn't want to invest time and get lock in to a solution that might be shutdown (which is what happened). If they would have made it open source there would have been more people and companies going to take the risk. Not making Spaces open source was a bad decision.
276 comments
[ 3.5 ms ] story [ 22.0 ms ] threadOne such thing that Xcode has that IntelliJ doesn’t is per-pane history. In Xcode hitting back/forward navigates history for your focused editor pane whereas IntelliJ’s navigates history across all editor panes.
This might sound like a minor difference, but Xcode’s way gets me to where I want to go more quickly most of the time because I’m not having to wade through the likely-irrelevant history of the other panes. It’s a frequent frustration whenever I have to use an IntelliJ IDE.
Jumping through a stack of functions across classes and back seems like the most common case to me. I'm glad you like it but I would hate that.
The redesign they've gone for also seems like a supremely weird choice. It's like they're trying to be more like VS Code, when their probably biggest selling point was that unlike VS Code, they offered a full and traditional IDE experience.
Their trajectory has been a deeply questionable mix of change for the sake of change and nervously doing what everyone else is doing.
I’m not surprised.
It's better to be the king of a niche.
Ironically, back then they praised JetBrains for not following hype staying focused on IDE and Dev environment
Wonder what the "something big" could be that companies are throwing money into in 2026.
IIRC investments are any transactions which increase the assets in the balance sheet. Losses are outflows net of inflows.
In abstract terms, one is about stock and the other about flow of spend.
Because traders are short-sighted and demand the profit line always goes up.
They're also horrifyingly risk-averse. A temporary dip in profit because money is being spent on expanding is a negative signal to them.
I regret someone convincing me not to buy TSMC stock about 5 years ago because of their high CapEx. I would have 5x'd my money since then.
Probably AI spend and increased developer cost (salary + AI subscription cost). And the increase in memory prices means procuring IT assets has sky-rocketed too.
I would assume the margins they operated on, evaporated with the AI bubble.
Yes. Companies have been looking at nothing but revenue for over 10 years now. You realize that a sustainable company has to look at net profit at some point?
Look at the report (or point your clankers at it), not the saased helgi-pay-me-for-more, but free, full at CZ corporate registry. few tidbits from my fast (error prone) readin:
- main reason of net income loss is currency movement in 2025(CZK vs USD). eg. if they hold USD, they report loss without money moving. The other was bigger costs (but look below)
- they have 6% rev growth but ONLY in this CZK entity, whole group is whooping 25% up
- investing was lending (to subsidiaries) and outflow to bank deposits (sic!)
- cost increase impacting operating profit was from:
Looks fine for me and definitely not ai-doom-scenario.not yet ;)
Their main moat was smart refactor, and a few other nice tools to debug. regardless of what you think about coding is done, agents and your harness is the best tool. I heard they doing business accelerator to find a new business ideas. But as a company, hardly imagine anyone buying expensive IDE in 2 years. Why?
If the first part follows the second, the surprise is that revenue is up while the prevailing opinion appears to be "no-one needs to buy an IDE".
I am not moving away from JetBrains anytime soon, but it does gets harder to justify when I spend considerable time in a competing offering that has better experience and is free...
The landscape is changing significantly, and I think these types of tools will become more popular.
They could have bought out Cursor early on too.
https://www.sublimemerge.com/
Can anything serious/complex be done on mobile? I'm genuinely curious. It's seems bizzare in the context of IDE and tooling discussion.
That slow trickle of back and forth that gets our intelligent machines called "toasters" in a way not predicted by Battlestar Galactica at all, that really starts shining on mobile. Hands off on terms of signing off every little detail, hands on in terms of never being too far out of the loop, keeping the unattended steps small.
I'm usually working between VSCode and Codex/Claude Code at the same time, but find myself mostly in latter these days.
https://www.jetbrains.com/air/
Anthropic is a different story, but I think it may still be possible via the Claude ACP agent (JetBrains' support of ACP is generally pretty good; I use it with anothe harness for open weight models regularly).
Any leverage that claude could benefit from LSPs or language/AST MCPs is undone by that tooling not being able to keep up or stay fresh, so the IDE just "runs hot" for no purpose.
Which means I'm incentivised to close my IDE while claude is working, and now I've got used to not looking at the code.
Like you, I really want a system that works better. I want claude to search and edit through better tooling, it would be faster, more accurate, and should in theory be able to leverage compilers to apply edits better and more accurately.
I don't want claude wasting an awful lot of time grepping for things that a compiler cache can answer, but if that compiler cache can't keep up then it's actively harmful.
I'm sure there must be a better way, there must be a way to have smarter more change-aware cache invalidation, and smarter more cache-aware claude tool use, but so far none has happened.
Long term I'm sure the pairing will emerge, but unfortunately I don't think that's going to come from the IDE vendor side, it'll have to come out of some harness research lab, where Anthropic or a competitor finds a way to reliably leverage this stuff for a speed and accuracy boost.
It's completely bonkers to me that an LLM can almost "natively" read profiler output, but doing so involves vast amounts of text and context ingestion, when there are real tools sitting there that it ignores in preference for either reading vast amounts or iffy python one-shot scripts to parse stuff.
With Codex GUI app and Astra you can communicate through screenshosts and collages. WAY faster and more precise for many types of jobs and workflows. Literally just scribble crap into the screens and it knows... no need to write out 50 paragraphs of prose to describe a button and its position.
I was using just command line too and Orca just leveled up everything around it. Still using the cli but inside of Orca. I
Hi, we have such product already, you can try it here: https://plugins.jetbrains.com/plugin/33314-air
> Figures are the company's own (unconsolidated) statutory statements filed with the Czech business register…
Are these as reliable as the U.S. 10K or its European equivalent?
I assume that a company like JetBrains would be investing in shifting products around A.I., so it doesn’t seem too surprising that they don’t report a profit for 2025.
then Sbirka listin and download the filings. It's all in Czech so put it through GPT for translation
Personally I usually use Claude inside the Jetbrain's IDE terminal, even if I code by hand obviously less. I still like using the diff, navigation, quick access to any file path for my prompt etc but maybe that won't last.
They've also done so many pivots on AI, all of them weakly and annoyingly done. They couldn't even pull of FiTM copilot well, they were super late on it and it had all sort of bugs.
They could have just taken the loss and written an amazing GUI coding agent that integrated well with their IDE -- amazing integrations with their refactorings, etc. -- but that played well in other people's ecosystems but they refused and tried to own the whole pipe. Or something. They just confused me.
Their latest attempt is to allow you to connect to and run other people's agent harnesses inside the IDE and it works well enough but it wasn't enough to grab me since I (like you) use herdr on another machine to do the coding.
I've been using their products since ~IDEA 3.x. Almost my entire 25+ year career really. My fingers are wedded to their keystrokes.
Most recently they integrated air, which is basically an "agent management/orchestrator" where you can run any ACP-compatible agent with any model you want and it's just the single place where you manage them, see their progress, steer them, merge their results etc.
For their entire existence people have complained about JetBrains this way because they always face some competitor that isn't making money and isn't even trying. Eventually those competitors go down, but a new one instantly arises. People just really love losing money on developer tools.
Wanting to charge money for an AI service is a clearly sensible business move. If their competitors weren't shredding the world's entire supply of investable capital as quickly as possible, this would be a good strategy. Alas.
It only fits a hands-on, merely AI-assisted development approach, on one feature at a time, that is not typically productive compared to agentic development.
You might disagree, but you'll find that the proponents of the hands-on approach are losing ground every month as AI gets better at working autonomously.
Claude constantly makes poor architectural decisions, adds unnecessary and costly checks, makes wrong assumptions, etc.
Doesn't take the value out of LLMs writing code, but they need to be properly steered and reasoned with. How will you do so if you don't even browse the code it generates.
I always suspect that the people all in fully agentic codig like this are mostly creating prototypes, half-assed copies of existing products, etc.
I am glad to not work in such an environment.
I've put like 500 hours of work into it over the last 6 months, besides my full-time software engineering job.
Frankly I think I have more experience than most here at using AI.
For me it works very well to just have a conversation with the agent in order to understand issues and steer it.
Essentially I would ask the question I would otherwise try to answer by reading the code.
Obviously, this has the downside that sometimes you miss things that would be obvious when reading and understanding all the code.
Since that can take a lot of time, it is still more efficient for me to instead QA test functionality and address issues I notice during actual use.
This doesn't say much. Plenty mobile apps, even paid ones, are of shovelware quality. And even if that's not the case, it's typically something very self-contained and of relatively low complexity.
On my personal projects I also seldom need to review code very thoroughly. But it's also not super complex stuff.
At my workplace things are not like that. It's a very complex system on a highly regulated environment. Opus 5.5 constantly get things wrong in ways that are simply not acceptable.
And I am not even an AI naysayer. I accept it as another development tool.
Complexity is up for debate. The project currently has ~1500 en translations and 7 AI models I optimized for mobile.
I think the key point is being self-contained, so that QA testing is effective for catching issues.
If that's your goal, stop using the slop machine. You will never make something actually good if you are letting it drive.
There is potential to build a better UI than what's constrained within a CLI's grid of characters.
I still read all the code AI produces, and I have a specific workflow. I scaffold the API first using AI, then review it for quality. Then I write tests, and review them for quality. Implementation is last, and technically I need not review the code but I choose to.
When I’ve done agentic development, the only thing I’ve accomplished is 100x more token burn with lower-quality code. It’s also not faster, because the tokens cost time and so many mistakes are made that must be cleaned up. The agents burn so much time going around in circles, when I could’ve just steered the model to write a good implementation.
Keep in mind, this is very fast. Models still produce thousands of lines of code in mere minutes. And with tests backing them up and an API frozen, the model goes much faster as it can iterate and has a framework for what it’s doing.
Disclosure: I work on Xpoze.
I'm paid to create a product. If Claude does so without me having to look at the code, then that's what I'm being paid to do.
This of course varies by company but this is clearly where it's headed: bot pushes, bot reviews, you look at the PR title and click merge.
> What would you say... ya do here?
I have seen a bubble sort function in a PR from an engineer with 20 years of experience. Meanwhile sort from standard library is easily available with one single line.
The bar has become as low as "it works" without considering what's in the code or whether the entire feature should even exist at all.
P.S. that same engineer sent out a PR of 200-file feature. The PR is so large that it freezes the latest MacBook Pro if you try to read it. Nobody reviewed it and he merged it himself. Nobody uses that feature, and nobody in the teams wants to maintain it. Now we are considering scrapping it.
Quality, maintainability, simplicity, understandability, flexibility etc all still matter at $DAY_JOB, where you’ve got paying customers. We’ve got a responsibility to write good software that adds to people’s lives.
I’d recommend to try to raise the bar. Commit messages written by humans, no PRs above a certain size, any PR needs an introduction / explanation by author first for the reviewers.
So it's already an improvement. Should it be manually read, comprehended, reviewed? Probably. But they can get to an improvement over what they did 2 years ago, with basically no effort. And then they can get a little bit further, with massive effort?
The "LLM-yolo" is a big knee in the cost/benefit curve. It's an improvement over their "old code". The only drawback is: it's still containing bugs, and now no one understands them. But that's not hitting them until that code has aged somewhat, so a year or two down the line.
If mediocre code is better quality than what you wrote by hand, you've quickly discovered that you're incompetent.
The good part of LLMs is you don't have to worry about overloading them: you can just outline every problem with the code they produce.
The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
There's also the problem of this ultimately being my code. It isn't Claude's - Claude isn't a person.
I still read the code. I use LLMs to review it. But I also review it myself. Ultimately its faster than before, and probably better quality (because I can just give all the problems to the LLM), but slower than people doing zero review.
After I give feedback to the AI I then ask it if we learned something and then I ask it to store that guidance in a relevant skill file.
I have skill files for everything and anything in my project. Three just for testing - one for frontend, backend, and e2e. I have one just for frontend forms. I have one for project terms, which I ask it to read before doing anything, so it keeps the terms in the project right. I have one for doing db migrations and one for doing backend routes. I have many tens of skills that have been slowly built up like this.
Not my experience at all. Mediocre LLM-code, mediocrely reviewed is a loaded footgun aimed at both your feet.
Emphasis mine.
I can't phantom some that bad at coding. Using such exaggeration void your comment.
No, I find that most teams I've been on have 5% to 20% of their most artisan engineers actually giving a shit about the code, and gently coaching the other 95% to 80% of the engineers who are usually much more junior during code review to not push unmaintainable slop. If you're on a team that doesn't still have someone giving a shit, it's not a sign that there are no teams that don't give a shit, it's that you're on a shit team.
There are also teams where the incentive is to get to pull request (or merge request) as soon as possible, so that you can move the ticket across the board and relieve downward pressure. That usually means pushing subpar code to PR that you know you'll spend another few hours fixing.
Anyway, if you're on a shit team, but you're still satisfying product and nothing is blowing up yet, there's a pretty good sign that your software has no moat and will be the first to be replaced by LLM-generated software on-demand. This is probably where most niche B2B back-office, front-office software sits. Stuff that sits somewhere in the realm of "We could probably do this in Excel if we wanted to."
That is only true for bad coders, that in a prior era would have been known as script kiddies.
When you get paid to care, you will care. Unfortunately, no one cares, they just want results, any result. Bubble sort will do, especially for low volume tasks.
Use the time you save by not caring, to do other fun stuff.
That's not an option for people who "care". Like it or not, a lot of self is tied up in work. Feeling useless rots you from within.
What kind of time do you save, especially at work? At any normal software shop you have an endless list of things to do. And most often you don't get to choose the "fun" part.
The word professional im important here. I don't want to know, how unprofessional devs handle their craft.
Follow up work to generate markdown? It wrote a mess of manual string building instead of using said library lol. Even with strong AGENTS.md guidance around using existing and leading community libraries they will often take a hard left and write stdlib straight into your repo.
Y'all should scrap that feature and maybe the engineer. I believe the Shopify CEO recently referred to those types of PR as "slop grenades" that cause headaches for everyone else..
MORE MORE MORE like AI has given executives an excuse to ratchet up performance expectations by at least 3x (as in my company) up to 10x for certain start ups I've heard.
There's literally not enough time for a human to do all the activities around quality they were doing even a year ago.
Turns out, it was probably good that nobody spent time reviewing it.
Really the single biggest piece I use today is using a tool like superpowers to ensure your task is well defined. Added bonuses are its TDD implementation skills and multiple review steps baked into the workflow. Before I discovered superpowers I was manually telling claude to do these workflows, the plugin makes it easy.
In the repo itself:
* Keep agents.md focused; claude likes to really bloat it by default. The "Adding guidance for AI agents" rules go into every project and have worked pretty well.
* Aggressively use nested agents.md files. Focused rules located where they're relevant seem to do much better than having a large whole-project rule dump in the root agents.md.
* Recently I've started using the tech debt and deferred work documentation rules. Claude frequently decides on its own that some piece of functionality or issue is "deferred until later" or "out of scope". These rules help make it clear so that you can make it fix the item or at least have it documented for a followup session.
* Have it test all the things. Most of my personal projects with claude have about a 3:1 ratio of test:application code and high coverage. Claude make it easy to build test harnesses for things that most of us wouldn't have bothered with 5 years ago.
* Strict type checking, linting, static analysis, warnings as errors, etc. Anything you can turn on or add to block questionable code, do it.
* Use a claude pre-tool hook to run all of your checks before you allow a git commit command. Left on its own it can and will decide that it has a valid reason to bypass git commit hooks (husky) to commit broken code or tests.
I mean, sometimes work falls exactly at the tool's strongest suit/match.
I am trying to think of what a comparison here could be but, for example, I remember early days in my career where pretty much 80% of the work was writing boilerplate and using scaffolding/generator tools, plugging them in the various plumbing and pipes of the stack, and just ticking boxes through Jira
Lots of "CRUD" and/or similar "recipe" type of work that was really just turning your brain off and needed that grunt labour force
You may ask: why is the person even needed?
My answer is the same as before: I don't know, I didn't know why were they needed back them either, felt like all could be automated as well, maybe the cost to invest in automating and mapping that all out was never a priority and the ROI math was "good enough" for the business while leadership had other north stars they were worried about?
I've spent 1 month between august and early september writing some of the best code of my life. LLMs only provided feedback, I wrote all the code manually, still remember it by heart.
I was very delighted by the many architectural iterations that led to it. 9 files, around 10k lines of code (of those, 7k tests).
By the end of super funny exercise I kinda realized that if I had the same feature vibe coded it would've been better. I would've done much more and progressed more feature wise.
I just feel stupid hand writing my code.
It doesn't help that I work with stellar individual contributors. All of my team mates (except a junior) are either all former faang or contributed to projects we all use (from the TypeScript compiler to Linux). And they are all abandoning if not spearheading the abandonment of reading code. I'm talking people that truly loved the technical aspect of it and excelled in it.
I just feel stupid, like I'm carrying a weight that I should abandon.
Comments like yours feel would've made sense 6 months ago, but now are crumbling.
Software is essentially so cheap and throwaway nowadays that letting LLMs write it is imperative. When you find your use cases you start reviewing it or rewriting it thoroughly.
I’ve been using agents to do the code for me, but I explicitly tells it to iterate in small changes that I can review and approve as it happens, not after a 2k lines diff. It makes me understand what’s being made, and test every little change before we move on to change other parts of the code. Also helps you correct any misunderstanding right from the start.
And seen that JetBrains revenues still grew 6% YOY, it looks like after all there are still developers paying for an IDE.
I thought that by now, according to the AI kool-aid drinkers, there wouldn't be any developer anymore?
At this point of 2026, if you're reading code and still catching things, then the problem was your workflow I think. You should have decided more high level preferences like invariants before the work began.
Since the spring, I haven't actually needed to write the code, just look at it and make sure it's good.
All that I do from inside GitHub or GitLab.
I've had a JetBrains subscription forever and this is the first time I'm considering not renewing it.
Oh, boy, here we go... Sighs and pulls up a chair.
Using an IDE has nothing to do with looking at code. The best engineers I've ever known use what JetBrains aficionados would refer to as "editors", not full-blown IDEs. To a person, not one of them felt as though they were missing anything they wanted or needed. I would probably even say "Unix is my IDE". I have a terminal chock-full of advanced command line tools to search and manipulate codebases. It's always fun and convenient when a GUI gives easy access to those things, but it's just that: a convenience, and only when the GUI exposes the full option set of the underlying tool, which they almost never do. Basically, I can alt-tab to a terminal, press up-arrow to expose "cargo build", and hit enter to run it, about as easily as someone else can select the build menu in an IDE. Further, if that build menu option is any less configurable than Cargo.toml, I'd prefer the text config any day. And finally, "cargo build" works with any editor I'm using that day, even if they don't their own build system wrappers.
IDEs are fine for people who enjoy them. I grind my teeth whenever anyone hints that they're remotely necessary for, well, anything, or that people who aren't using them are somehow missing out on something. We know what we're missing, and frankly, we're not missing it.
I've always had a personal ultimate sub even though I use vscode 99%. There would be a lot more ultimate subs barely used like mine if they weren't 3-4x the price of the singles. I've never felt justified in asking for ultimates business price for how little I use it, but my teams always have a pycharm license.
There are companies where you'd rather be the owner, and others where you'd rather be an employee, or a customer. I think the JetBrain's customers are the real winners in this one.
Which is a shame really - this is similar to old blacksmithing tools.
I heard rumors JetBrains started going downhill around 2022-2023 because they severed ties with employees in Russia's St. Petersburg, which housed their R&D and all (although many employees were relocated but who knows).
On Space case, I think they felt it became too complex to maintain internally while other great alternatives were very hard to compete against.
They were sad about it, as they really worked hard on these products, but it's also easy to understand why they make the decision. Despite the tools being nice, if nobody buy them, it's just a loss.