Jetbrains has been pushing Junie real hard, my guess is that they've been giving out too many cheap tokens to try to stay relevant as Claude and friends pull people away from the IDE.
In everyone's day jobs where they used an IDE 5 years ago, or even a year ago, are those jobs abandoning the IDE?
I still use Visual Studio in my day job, where Claude's output while VERY helpful, requires my ownership of everything, meaning I am inspecting every single line it changes. If a change is bigger than I think it should, I kill it before I commit.
I know I don't HAVE to use an IDE for that, but if the change is small enough, I am faster than asking Claude to understand the subtext behind my personal context of the product, and the IDE is supremely helpful for making a quick change across a handful of files.
> meaning I am inspecting every single line it changes.
I think this is changing fast. Pressure is increasing on devs for output, and most devs I know are no longer inspecting lines. I have devs in my business unit who claim to not have looked at code for months, except on certain rare occasions. I am not a developer and this week I've been given access to the repo to build my own apps and extensions. There's a "review" between commit and deploy, but there's no chance the Tech Lead can manually review everything, so that's getting done by AI too.
I know this horrifies a lot of devs, but these tools are shockingly good and we are not seeing an increase in bugs. In fact our automated detections (also AI assisted) are reducing the number of customer reported critical bugs.
I really think the days of inspecting every line are over.
This type of codebases will become a goldmine for cybersec in the near future. Except by then, only few people will be able to detect them or fix them. LLMs will leave the hardest problems and most difficult bugs plus and plethora of devs who either have skill atrophy or haven't learn these things in the first place.
Actually, cybersecurity seems to be the area that LLMs shine the most at; though it needs directing to actually look for the problem, LLMs have been able to find security faults in code that is well-vetted and written by experts.
It's an interesting philosophic question. LLMs tend to be overly verbose and defensive in coding. It's not a ton of extra complexity but it makes the code harder to follow for a human. But if a human is not writing the code how much does that matter?
I agree that they have gotten shockingly good. It's been a long time since I've seen them do something that is objectively wrong. Once we get closer to the "too cheap to meter" cost level things will change radically again.
Have you ever tried to use an LLM to add a feature to a really nice, pre 2023 codebase? It’s incredible how much easier it is to do, how much of a difference you instantly feel
> It's not a ton of extra complexity but it makes the code harder to follow for a human.
It is. I have seen Claude chasing after endless amount of edge cases that are just irrelevant in real usage especially for the kind of users we are supporting. At some point you need to stop reasoning about all those cases because it has zero benefit.
But it IS a ton of complexity and blows out context windows. Less code good. More code bad. Both for human and agent. Somehow, still only human can make code less.
Yes and….no. I have seen this play out at a large corp to spectacularly awful results. Talking 60k line react nextjs apps where every use effect has a linter silenced because the ai gave up on writing correct react code.
I have seen millions wasted because someone trusted an ai scripts calculation of a metric from the bottom of the org that led the top of the org to make a wrong decision only to laugh about ai. There is value but ffs read the god damn code. You can have the cake and eat it too. If the volume of code is so large you cannot read it, maybe it isnt worth shipping?
Or are you one of the ones pushing the real code reading on to others which seems to be common. Yes i can have agents vibe out 10 features and have my coworkers suffer fixing it in reviews.
What IS useful are the AI reviews. They catch bugs, not all are bugs but they do catch some. It is almost like they are better at finding logical issues across millions of tokens but not good at writing streamlined logic.
The number of times ai gives me a 800 line dif only to replace it with a 5 line dif after i read it and notice it grossly overcomplicated the ask and scoped in a bunch of nonsense from training data.
I'm beginning to abandon the IDE (vscode in my case). I've always been very comfortable with (or at least not scared of) the command line so the Claude app with a terminal pane open is handling much of my IDE use cases. What I really need to do is get better at using find, grep, and other search tools from the terminal and then create a good .vimrc for editing and i'm set. heh what's old is new again!
> I am inspecting every single line it changes.
Honestly, when I'm looking at ClaudeCode's output 75% of time i'm doing it to learn and understand and not just check for correctness. I'm confident enough to admit I don't know everything and I've learned a lot from reading Claude's code.
IMO what's being called an 'Agent Development Environment' solves this issue for you. I like Orca but there's a few dozen of them.
Basically they give you a way to view the code the llm has generated/changed easily, annotate that code for the llm, and manage multiple agents and at once.
And with LLMs you can just create your own pretty easily that matches your exact workflow and integrates with all your tools. I've gone through a few iterations, first using the Unix small tools that talk to each other philosophy, then a single TUI app running in a pane next to my agent cli and now a Go server that has a cli and web ui with xterm embedded terminals and has its own chat sidebar in the web ui that can use tools and interact with running sessions in terminals. I'll probably have something new in 6 months.
I had personal subscriptions to WebStorm and GoLand and cancelled them not long after getting Windsurf. Just don't need the IDE abilities like I used to... Still use 'go to definition' but that's pretty much it.
Yes that is a real problem at work. A lot of stuff is done in containers or virtual devices and jetbrains remote developping workflow takes too much time due to this transfer. VsCode is much faster there.
Yes. Github draft PRs for giving inline feedback to agents, then going back to chat window with agents in Cursor, Claude, Codex, etc. to say 'review my comments and address them'.
I tried it in DataGrip on a messy database. It hallucinated about which tables and columns to use. Had better results using Claude in the terminal and having it give me the SQL to run.
I use it daily, but I'm also the AI consumer that is looking for something like a hammer and a saw (it's clear what their job are and they're doing their job fine). I'm absolutelty not looking for the next-gen-stuff, so I avoid Codex/Claude/...
I think Junie is comparable to something like Claude Code or Codex, but moving a little slower feature wise. It's perfectly adequate for developers who want to use AI but don't want to keep up with the bleeding edge of tooling.
It felt quite competitive about a year ago. But haven't tried it since, no idea how it has held up with the other advancing. What I liked was the tight integration with the IDE. I don't particularly like the way I work with Claude now, still wanting to check the changes, navigate code, ask questions, write some code myself etc. Feel claude mostly is for the "bigger" changes. Sometimes I just want to select some text and refactor it, or ask a stupid simple question without the "chat".
Worked fine as a free tool, but as long as AI companies are selling their slopware tokens below cost with subscriptions, it's not really that interesting in my opinion.
The Jetbrains integration is nice, but if you rely on the tool you're probably not going to use the IDE much anyway.
Not personally but Junie was what made the fellow developer I respect most in the world actually start taking notice of LLMs as something useful instead of bad.
It is alright to get an LLM review on code I write myself, but getting extra tokens is expensive, and it was not clear if I could configure it to use one of the API keys I have from GLM, MiMo, etc.
I tried Air as well. It was alright, but I found it a bit more cumbersome to use then Pi. I tried configuring Pi to be accessed though ACP, but it felt like going through a hoop to have a worse experience. Then again, I am not someone that manages multiple agents in parallel, at most I have one agent implementing something in a different repository while I am doing my own things.
Air could maybe be useful for me if I could plug in the LLMs I actually use directly, it is too tied to ChatGPT, Claude, etc.
I enjoyed it a lot early on. In particular it didn’t have all the confusing and anxiety inducing options that other agents have to use more expensive or less expensive models, I liked the way it approached “plan mode” [1] and I didn’t feel like I had to stress it about token costs the way I do with the other models…. Jetbrains now gives me a choice of agents which I don’t like because having to think about it makes feel like one of those “ai bros” who is overthinking their relationship to ai and underthinking their code.
I would like to see one more ide-integrated, like I think running commands like ‘grep’ with the shell is really for the birds (creates a risk that some other command line might be run, the wrong files might be accessed, all that) and rather there should be a specialized toolbox.
[1] … I reject vibe coding. Token costs be damned but I always like to have a talk before it starts like “I think…, maybe you should…, does this make sense?, do you have any questions for me before you start?” and later “what are you doing in the code in the selection?”
> 1. Why does neverssl.com use Javascript to redirect to a random subdomain?
> Over the last year users reported that some networks aggressively cache the fake DNS and pages they use for wifi capture. Neverssl.com now works around this generating a request to a random subdomain - this will bust any DNS cache, and any HTTP cache. It also means that if your browser or ISP caches the Neverssl.com page itself, that's fine.
I've been having issues with kernel updates because Nvidia dropped support for my GPUs. Apparently 9 years was the threshold for their "very old card" support because Pascal is now over.
The community can't fix it because their drivers are proprietary blobs. Open source drivers are essentially useless. I'll have to stick to something like Ubuntu to keep the hardware working without fighting DKMS every update.
This is the reason my next GPU will be either AMD or Intel.
AMD put a lot of effort into supporting common features every GPU should support, like OpenCL/OpenGL/Vulkan. Nvidia put a lot of effort in proprietary crap that only worked on their cards.
For various reasons, people flocked to CUDA and other proprietary crap. Then, when that proprietary crap became a money maker, people blamed AMD for not supporting their favourite proprietary crap.
AMD did the right thing and was punished for it. They're still doing the right thing and people still complain that their free full re-implementation of Nvidia's runtime, designed for completely different hardware, isn't good enough.
AMD is not a saint of a company but it's consistently better than Nvidia, every time. Doing the right thing just isn't rewarded and it shows.
on older (read: older than RDNA) AMD GPUs the OpenGL drivers are so poor that half the games just either crash outright or have colourswap bugs (RGBA -> BGRA i.e. your game turns blue and orange)
On Linux at least you can use Mesa to fix it up. On Windows you're.... out of luck I guess unless someone writes a binarypatch or something?
There are many words to describe my experience with Nvidia on Linux, but "just works" isn't one of them. For modern cards it usually mostly works most of the time, but getting basic features such as "decode H.264 on the GPU" working still requires unofficial third-party wrappers.
On Windows you may be right, I haven't had to deal with Windows drivers for a few years now.
I've seen the bug with my very eyes because I wrote that renderer and I did test on all three vendors:P
Zero debuginfo-related warnings on any driver (except the usual "buffer location is VIDMEM" spam), NV is fine, intel is fine, my (RDNA) AMD card is fine on both Windows and Linux, user with a Vega 64 isn't fine.
We dug into it together and it literally swaps the colours somewhere, and the user said that it crashes randomly on games (confirmed by others, not one-off HW failure), does the same colourswap or have very glitched rendering.
I guess the only salvation is that people usually play DX games under Windows and the bug didn't happen over DX11. But the same rendering restricted to even standard GL3.3 just got BGRA-swapped.
I haven't tested Apple's access model, but is there something that's stopping Gemini from launching `ghostty -e /bin/sh malware.sh`?
Windows' Vista-era UAC protections have been bypassed through lolbins since the day of its inception (although officially UAC is not a security boundary according to MS) and apps like Ghostty might punch a hole through disk access controls in the same manner.
Having had the (dis)pleasure of working with SELinux, it's clear that there are systems out there that can work to solve these problems. On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
I don't know if Apple has something like that. Surely they must do; Windows FACLs have been available since NT was part of the name, Linux has had them since Linux 2.5, and Apple invented a whole new filesystem relatively recently. They've also compartmentalised iOS apps since they were first released.
I'd be surprised if the currently available APIs aren't usable for applying effective restrictions just yet. Rather, I think Apple's choice is part of a process to move desktop applications towards the iOS model instead.
> On Linux the problem is in the UI/UX layer (actually configuring SELinux rather than working around it is a massive pain) but Apple/Google/MS have the money to solve that.
That assumes it can be solved and even then it requires research, so you cannot know how much effort it takes to find a solution.
Also, and IMO highly likely, any solution will be unusable for mere mortals. i thin that’s why you are saying “(dis)pleasure” and “configuring SELinux […] is a real pain”
SELinux was originally designed by the NSA to serve their needs, which are probably a bit more intense than "normal" users, and that was over 25 years ago. I'm not convinced a fresh effort couldn't do better, though I'm more skeptical that anyone is willing to invest the resources.
The ICC issued an arrest warrant for Netanyahu because of the genocide Israel is committing, that's what upset the Americans. I doubt even Trump would go this far if it wasn't for that.
Which Americans? I think it just upset only the Zionists, Epstein class, members of congress bought and paid for by Israel(AIPAC) including the US presidential administration, plus the boomers who've been brainwashed by decades of Zionist propaganda on TV, but I imagine a large part of US voter base, especially under-35s, don't agree with this if polled.
At least every American I know in Europe(not a representative sample size, I know) is vehemently against supporting what Israel is doing.
While there is arguably still some influence from democratic pressure on some areas of US Federal policy, foreign policy and warmaking (including financial warfare like this) are not among them. These have been insulated from public opinion since approximately the the 1940s. It took a massive organization against the draft to (arguably, possibly, maybe -- we'll never really know) shorten the Vietnam war (which, incidentally, was never declared a War by the democratically elected Congress), and that was the high water mark of democratic influence on the security state since WW2.
In short, the opinion of Americans is just not relevant to America's foreign policy decisions. Even a 100% anti-Zionist Congress would be unable to stop supporting the genocide.
>Even a 100% anti-Zionist Congress would be unable to stop supporting the genocide.
Yes, they would be able to if the majority party actually wanted to. Trump could be impeached for so many things I can't count. It's not happening because Republican members of the house and senate don't want to or are afraid to.
>Every American is 100% culpable for everything their government does.
I disagree. I'm EU citizen and I am not culpable for everything my and the EU government does, because while being democracies on paper, I don't get to directly vote on the leadership of the EU(Ursula) nor the individual policies of my country and the EU decide to take, especially on external politics, which are often against my choices, but I have no say in it.
Sure, I can try to vote those people out, but that means a delay of at least another election cycle(provided the majority is on my side), in which time they can legally keep doing what I don't want them to do.
My point is, democracy isn't some magic wand that does the peoples' wishes at current time, but has plenty of flaws known and documented since the ancient greeks.
> are HNers aware that the US has changed to a first strike nuclear policy, coupled with Trump now having tactical, low-yield nukes as an accepted policy?
Updating an app to not require the Play Store is a lot easier than switching payment provider backend.
Wero can fix the dependency on Google in a day, I don't think the dependency on Google is as bad as the broader dependency on Mastercard/Visa is.
That said, I'd much prefer a European implementation of the same remote attestation APIs that Google uses to convince payment processors that phones can be trusted to manage finances.
On iOS you don't really have a choice so until someone runs Linux on an iPhone, iPhone users are just screwed.
> I'd much prefer a European implementation of the same remote attestation APIs that Google uses to convince payment processors that phones can be trusted to manage finances.
You're basically talking about "government Android phone" since it is built into the chips on the device.
I wonder how 330 million average Europeans will respond to not being able to use iPhones or Google Android phones anymore because they are instead being forced to use "government Android phone" for safety from USA.
I think they'll actually just revolt against the government instead
Loads of bugs aren't CVE-worthy. If you tell the computer to make a light green but it makes the light red, that's a bug but no DoS or other CVE-worthy bug.
However, the Linux kernel is supposed to run any userland program without crashing, so anything that crashes the kernel is a local DoS and there are a lot of them. It's also supposed to shield processes from each other and maintain privilege levels correctly, so many incorrect memory leaks are also CVE worthy. Whether a CVE applies depends on the people and programs using the kernel, and the kernel team can't read your code to tell you if it applies or not.
People reading CVEs wrong ("it's got a high number so we must patch within a day") must be going crazy over this, but the point of CVEs is to let you make judgement calls, not to be a cool statistic about how secure something is.
Most CVEs are irrelevant to most people, that's always been the case.
If only the user can tell whether something is potentially dangerous, then either every bug or none of them should get a CVE. There are countless systems out there that are commonly used in ways beyond what even the developer intended, how should a third party authority like the CNA be able to discern this?
They can't. Which is why security discussions are such a hot mess.
The vendors fixing them arguably prioritize these reports right. Most of the CVEs, even severe ones, are irrelevant in practice, and as parents note, are more like regular bugs with security flavor in reporting. The CVE label instead of regular bug tracking number makes them seem important.
Linux Kernel may be one of the few legitimate exceptions, indeed, due to the position in which it sits in the software stack. Also LLMs make previously unexploitable-in-practice vulnerabilities exploitable (by making targeted / personalized attack cheap enough to give them positive ROI), which complicates things.
I think you have to make a distinction between bugs and actual vulnerabilities. Therac-25 killed people, but I wouldn’t consider anything about it to be a security vulnerability. In my mind, the distinction between a bug and a vulnerability is that a bug is triggered during “normal” operations and can do anything. Whereas a vulnerability requires an adversary to “trigger” the vulnerability, and can do this to achieve some cognizable malicious goal. There’s probably some overlap on the edges; whether an issue in a library is a bug or a vulnerability may depend on how it is used, for example.
But I think the most important thing to keep in mind is that a bug isn’t necessarily less serious or less important than a vulnerability. A serious bug should be patched just as urgently as a serious vulnerability.
And not only that, remember the hn crowd is not at all representative of the average.
Even more realistically, many admins do not have the background to be able to reason (by themselves) about the actual risk of most CVEs, so just going along with specialized media coverage is often a sound strategy.
Yes, it is a bit of a stretch, I desperately hope programmable navigation lights are not a thing. And I also don't think every bug needs a CVE. But in the correct context nearly any bug could be critical.
Computer Weekly in the UK did some pioneering journalism into a helicopter crash[1] that had initially been blamed on the two pilots but seems very likely to have been caused by a failure of a computer system that was controlling the fuelling of the engines. Iirc this system seems to have crashed causing engine failure of both engines in heavy fog, bringing the helicopter down with a loss of everyone on board, however for reasons somewhat unclear, the MOD wanted to cover the failure up by blaming the pilots.
Now this was a windows system[2] rather than linux but the point remains - if there was an external vulnerability in a crucial control system and this system was part of a network (eg to connect telemetry) then any exploit of that system could result in loss of life.
After an assessment of the Fadec software the Superintendent of Engineering Systems said that the density of deficiencies was so high that the software was unintelligible.
[2] Which, why? Why build the fuel controller for a helicopter engine on windows?
A windows system controlling the refuelling ? Worked in aviation software for a while and the certification for flight control (or similar) systems is subject to rigorous path testing/inspections/approvals etc DO-178C (level A or B likely). Not sure if any windows OS is certified to level A?? Typically certifiable RTOS'es are procured for those purposes
reply