> From September 2026, Mathias Breistein has taken over as CEO, with a focus on new customer acquisition
Mathias, if you are here and listening, I'm interested but $35 / month is the wrong price point for this. $420 for year.
I can buy DataGrip for $261 for three years and it has a perpetual fallback license that would let me pay for the first year and then stop and just not get updates.
IMO, to start, you want your product to be so good and so reasonably priced that it's easy for someone to decide to give it a try. You are coming in with a uber premium price and I think that's going to severely hinder your customer acquisition efforts.
Also, I almost never get a license to a tool like this where I'm not entitled to keep using it if I stop paying for it. There is just too much incentive on the part of the vendor to just keep driving the price up to the breaking point. With a fallback license like JetBrains has, if they get unreasonable about price, I can just exit.
Finally, in the age of LLMs, if this gets popular and the price point is wrong, someone is going to do a good job of producing a competitor and make it open source or much less expensive. Make the official version a reasonable enough price that there is no reason to not support you to make it better.
Just my $0.02 but hope it helps at some level.
Finally, I looked at the website and there was no way to contact you to tell you this personally. So...might want to fix that. Small org, easy contact should be part of the perk.
Yeah, I just looked at the price if it's anything I'm even remotely interested in paying if I found the trial enticing... and decided to not even bother with the trial. So there's this effect of a price set too high
I agree on the price. At least for my needs, I doubt I would be a heavy enough user to justify the price. (I probably would use this a handful of times a year; because I get similar-ish navigation in LINQPad.)
---
I did kick the tires with a free trial; and would probably recommend this to anyone who needs to navigate a SQL database in a point-and-click manner.
Came here to say something considerably simpler but essentially the same: for a solo dev, it’s just not affordable unless that solo dev does intense DBA work day in and day out or earns stupid money for the work they do.
In some ways, I think that's true, especially with AI. But, as another commenter pointed out, before that it was crypto stuff. So, popular things are discussed a lot. I personally think that's ok.
And, regarding AI, it's profoundly changed our lives especially for software devs. And we are in the infancy stages so there is a lot new and trying to be figured out still. So while it is somewhat fatiguing to see so much AI stuff, I actually welcome it. I've learned a lot here because of it.
Finally, while there is some tension in the comments, and a decent amount of negativity and pessimism in the comments, there are usually high quality comments that get voted up and people who are violating the guidelines often get voted down. Which makes me feel like the community as a majority still cares a lot about keeping HN reasonable.
I spend a lot of time here because I like it here. There is a lot of good and the bad is reasonable/manageable for me. I especially appreciated all the love for TNG and Patrick Stewart when he passed. My family doesn't share my affinity but it was clear a lot of the HN community did. I was comforted.
This reflects my experience as well. There are a lot of high quality comments if you dig into the threads. I've applied many to my daily workflows.
One of the more annoying things to me now about AI is in the real world, where many non-software loud-working people are in a sort of AI-induced psychosis, relentlessly self promoting. They are software/AI experts now, when they couldn't even write a for loop or tell you what concurrency means. I usually just stay in my lane, but it's something I've noticed anecdotally, similar to the rise of MLM schemes of the 2010s.
There is no evidence the repo creator is trying to earn anyone's trust. This could be a personal project that they have no intention to try and "sell" to anyone. They may not be trying to earn the public trust and have no interest if anyone besides them uses it.
I don't know how it is currently, but you used to have to make GitHub repos public to access the full feature set (i.e. things like CI runners) on free accounts. Some of us just got in the habit of making things public
I didn't realize the first round through that each game was for the same episode. I also didn't realize I could search for plot keywords. That made it a lot easier and I haven't missed one yet.
> Good developers’ caution about agentic development comes from knowing that built isn’t the same as working in production...I always felt there was something else, another fear hiding behind those obvious ones.
It's not fear. It's experience. I've seen the kind of code agents write. And it's too often crap even when it "works". This isn't about beautiful code. It's about what we've built actually making sense to a, hopefully talented, software engineer.
Maybe more important than that, it's about taking the time to build the mental models that facilitate product development and the next iterations of coding. When agents write all the software, the majority of engineers I've seen, including myself, lose almost all context to what is actually going on at anything but a very high almost laughable level. And they then become almost completely dependent on the agent for the next iteration of development b/c they don't really understand what is there currently.
Does this matter? From a software perspective, it depends on what you are building and for whom.
From a human perspective, it depends on the human. I've seen good developers that I trust historically churn out crap code with agents because it was just too much to review. And there is some kind of weird addiction like thing happening in our brains when using AI that makes it incredibly difficult for us to slow down and review all the code it writes. In part b/c agents are great at crapping out 3K line PRs like it's nobody's business. But it needs to be someone's business to understand what we are shipping for anything but non-trivial projects. And truly understanding 3K line PRs hour after hour is just not sustainable for most of us. Our eyes glaze over and we just ship it because that's what we do now as an industry.
I think wary is the wrong term. I've learned agentic development's strengths and weaknesses. And the tools, as they work currently, churn out code at a rocket's pace that any good software engineer would immediately reject in years past. I don't like their code, I don't like how their code development process interacts with my brain. It's not waryness, it's dislike and mistrust.
So, yes, they can be assistants. And they can even write code. But I think in much smaller chunks than most people are using them these days.
The idea that we should build software factories and/or otherwise just turn agents loose and isolate humans to the product/QA level is insane to me. But I understand why we are here and I realize that a large portion of the business and dev community likes this new model.
I'm hoping that not doing it that way will end up be a competitive advantage in the long run. Both for the software we are producing and for the devs that are creating it.
> Maybe more important than that, it's about taking the time to build the mental models that facilitate product development and the next iterations of coding.
For me this is the big one. When you code by hand something (especially at the start of a project / feature), it gives you times and opportunity to evaluate different approach, like data-structure or overall architecture. When you're given agentic-generated code to review, those choices are already been made implicitly by Claude, and while it give you the impression that you understand the codebase, you actually haven't been able to process the tradeoff.
Of course, not 'hand-generated' code has the same ROI, and when you're about to do something derivative of something you already understand, agentic development is truly a huge productivity gain.
For me this is the difference between 'vibe coding' and 'coding with AI': Am I able to predict in advance the code that Claude is going to generate, and more importantly, am I able to be surprised when Claude doesn't generate the code I thought it would have (sometime for good technical reasons), or am I just looking at plausible-looking code diffs, and accepting thing without being able to understand the impact on the rest of the codebase. This for me is way more important than what percentage of code lines have been generated by AI.
I've had the opportunity to try both approach: one where I was given a vibecoded project and told to maintain it with Claude: I knew the details of some features, but haven't worked with the codebase enough to really understand the architecture, or be able to mentally reason about the codebase when I'm asked a question during a meeting.
On the another re-implementation of the same product, I've been given more leeway to develop how I wanted, so I've handcrafted the first few features in a transversal way (handling the file architecture, the routing, the way data and components are splitted, and how the API calls are handled), and then I've used Claude to generate the other feature (most of them I knew to be derivative of the first one). In the end something like 90% of the code is generated by Claude, but the end result is both much simpler because I knew where things should be simple and where edge case where, and most importantly I trust what I've put in production.
Do you review and understand every byte of machine code being generated by your compiler? Do you understand all the implications of how it could interact with the underlying hardware, pipelining and prediction, etc?
Maybe you do, but most of our industry doesn't and hasn't for decades. Isn't this just the next step up the ladder of abstraction?
Not OP, but the issue for me is that for the longest time doing software development meant translating potentially nebulous requirement into strict computer logic.
The process of creation is often a back-and forth between that fuzzy concept in your head (or an natural-language spec that is often ambiguous), and the (usually reduced) physical object / drawing / computer program you've created to materialize this idea. That imperfect projection of your initial idea then helps you refine what this idea implies, and what are the different tradeoff you could take [0].
That back-and-forth has to be made when writing the computer code, even if it's going to be compiled after, because code needs to be detailed enough to force you into expressing the desired behavior with clarity. Prompting Claude on the other hand usually means that you let the LLM resolve this ambiguity for you.
In some case the details don't matter, and it's a productivity gain, and in other case the devils are in the details, and you've let Claude make important technical decision for you, even though Claude doesn't know how much those decision match the needs of the project.
Personally I think of my role as a software developer as someone who know technical possibility (and technical limitations), and weight the different tradeoff it implies to propose code that solves a business problem. And that's the crux of the issue with only creating code by prompting Claude Code: it gradually robs me of my ability to understand the technical possibility and limitation of the system.
[0] This idea has largely been taken from the very good book "Sketching User Experiences: Getting the design right and the right design", about the processus of ideation / sketching.
And, for what I do, Python web apps, it's almost never a problem. It doesn't affect runtime performance, accuracy, maintainability, or bug frequency except in the rarest of cases. Finding non-determinism is even rarer. And, in almost all adverse cases, it would be considered a bug.
I therefore find your suggestion to compare machine code and LLM output questionable. I find them qualitatively different paradigms, not simply another step up in abstraction.
You can’t abstract away the need to capture requirements in a symbolic language. It doesn’t matter which programming or formal language you choose to specify your requirements in, but it cannot be natural language.
It's not the fault of the researchers that the general media misinterprets studies like this. Maybe we should instead cast blame on the semi-scientifically-literate people who push attention grabbing headlines regarding promising, but yet far from actionable, study results.
I think the important bit is that, from my understanding, mouse models of alzheimer's dont translate as reliably to humans as it does for other diseases
This is correct, mice don’t naturally experience alzheimer’s or other dementias during their lifespans and the structure of their amyloid beta protein is different as well. To continue using them as model organisms, we have to induce the disease in them by either introducing human genes that are linked with alzheimer’s, or chemically inducing a disease state that we believe to be similar. Mice are much better models organisms for studying metabolism or cancer, by comparison.
It's utterly unimportant. It's all research and all progress and all works towards our benefit eventually. The fact that an important discovery is still in the mouse stage and not yet in the human stage doesn't make it any less important or interesting, unless you are unutterably simple.
Put another way: the "in mice" doesn't matter because they are studying alzheimers, not mice. the mice are just the lab equipment of the moment. I don't care what kind of glassware or computers they use either.
It depends on what's being studied. There are mice studies on diet which obviously don't carry over to human beings since we don't have similar digestive systems. It may be true (arguable) that all research data is of some benefit, but don't expect people to be as excited about mouse research as human research.
How do they get the alzheimers mice? Article doesn't say. Usually in studies they take healthy mice and induce the condition artificially. That can be a confounding factor since the condition isn't induced in the specimens we care about (human beings). Is it even the same condition?
It doesn't matter how they give mice alzheimers, or any other condition. That's just part of controlling variables to test for one thing. It also doesn't matter that they were fed processed food rather than having to find things in the wild, unless the effect of diet was the specific thing they were examining.
It does not matter how they give Alzheimer's to a lab mouse providing they give Alzheimer's to a lab mouse – not a different disorder that happens to have the symptoms of Alzheimer's.
If this was a website for fundamental biology research I’d agree.
As it stands, the headline is misleading and clickbaity.
> the "in mice" doesn't matter
Of course it matters, because that has a direct bearing on how applicable it is to humans and how much time it’s likely to take to be of any benefit to humans, if it ever is. That’s the whole point being discussed.
Also see this comment to help understand why “in mice” is a huge qualifier in this case, because mice don’t naturally develop Alzheimer’s: https://news.ycombinator.com/item?id=50218606
The "... in mice" qualifier is somewhat overdone, but for Alzheimer's in particular, it's actually extremely important: mice do not experience Alzheimer's. We test Alzheimer's drugs in mice by artificially inducing something that produces similar dementia symptoms, and then seeing how the drugs influence that progression. If that model is different from how Alzheimer's works--and there's pretty decent suggestions from the history of failed Alzheimer's drugs in humans that our models of Alzheimer's are in fact wrong--then anything that fixes that model has suspect utility.
This is the fifth breakthrough I've seen reported here this year, we'll have an Alzheimer's cure before Christmas!
I despise the current research system for making anyone on the road to progress fight for research budget by publishing wild headlines to get attention.
For people outside of academic circles, this just gives false hope that a cure for their loved ones is right around the corner.
> the rest of us can vote with our votes instead, and get much better results
Not sure where you live or what votes you are making, but "much better results" is hardly what I've seen or expect from US politics, politicians, and the uber wealthy that run the corporations that dominate many of the most important aspects of our daily lives.
I noticed that Firefox didn't show any connections on that page (good) but when I ran the curl command, it did connect (bad) and I had to update my Ubuntu packages manually to resolve.
Mathias, if you are here and listening, I'm interested but $35 / month is the wrong price point for this. $420 for year.
I can buy DataGrip for $261 for three years and it has a perpetual fallback license that would let me pay for the first year and then stop and just not get updates.
IMO, to start, you want your product to be so good and so reasonably priced that it's easy for someone to decide to give it a try. You are coming in with a uber premium price and I think that's going to severely hinder your customer acquisition efforts.
Also, I almost never get a license to a tool like this where I'm not entitled to keep using it if I stop paying for it. There is just too much incentive on the part of the vendor to just keep driving the price up to the breaking point. With a fallback license like JetBrains has, if they get unreasonable about price, I can just exit.
Finally, in the age of LLMs, if this gets popular and the price point is wrong, someone is going to do a good job of producing a competitor and make it open source or much less expensive. Make the official version a reasonable enough price that there is no reason to not support you to make it better.
Just my $0.02 but hope it helps at some level.
Finally, I looked at the website and there was no way to contact you to tell you this personally. So...might want to fix that. Small org, easy contact should be part of the perk.
reply