I find it interesting that folks are so focused on cost for AI models. Human time spent redirecting AI coding agents towards better strategies and reviewing work, remains dramatically more expensive than the token cost for AI coding, for anything other than hobby work (where you're not paying for the human labor). $200/month is an expensive hobby, but it's negligible as a business expense; SalesForce licenses cost far more.
The key question is how well it a given model does the work, which is a lot harder to measure. But I think token costs are still an order of magnitude below the point where a US-based developer using AI for coding should be asking questions about price; at current price points, the cost/benefit question is dominated by what makes the best use of your limited time as an engineer.
We already shipped 3 things this year built using Claude. The biggest one was porting two native apps into one react native app - which was originally estimated to be a 6-7 month project for a 9 FTE team, and ended up being a 2 months project with 2 people. To me, the economic value of a claude subscription used right is in the range of 10-40k eur, depending on the type of work and the developer driving it. If Anthropic jacked the prices 100x today, I'd still buy the licenses for my guys.
Edit: ok, if they charged 20k per month per seat I'd also start benchmarking the alternatives and local models, but for my business case, running a 700M budget, Claude brings disproportionate benefis, not just in time saved in developer costs, but also faster shipping times, reduced friction between various product and business teams, and so on. For the first time we generally say 'yes' to whichever frivolities our product teams come up with, and thats a nice feeling.
Who's going to review that output for accuracy? We'll leave performance and security as unnecessary luxuries in this age and time.
In my experience, even Claude 4.6's output can't be trusted blindly it'll write flawed code and would write tests that would be testing that flawed code giving false sense of confidence and accomplishment only to be revealed upon closer inspection later.
Additionally - it's age old known fact that code is always easier to write (even prior to AI) but is always tenfold difficult to read and understand (even if you were the original author yourself) so I'm not so sure this much generative output from probabilistic models would have been so flawless that nobody needs to read and understand that code.
I am not sure how others are doing this, but here is our process:
- meaningful test coverage
- internal software architecture was explicitly baked into the prompts, and we try to not go wild with vibing, but, rather, spec it well, and keep Claude on a short leash
- each feature built was followed by a round of refactoring (with Claude, but with an oversight of an opinionated human). we spend 50% building, 50% refactoring, at least. Sometimes it feels like 30/70%. Code quality matters to us, as those codebases are large and not doing this leads to very noticeable drop in Claude's perceived 'intelligence'.
- performance tests as per usual - designed by our infra engineers, not vibed
- static code analysis, and a hierarchical system of guardrails (small claude.md + lots of files referenced there for various purposes). Not quite fond of how that works, Claude has been always very keen to ignore instructions and go his own way (see: "short leash, refactor often").
- pentests with regular human beings
The one project I mentioned - 2 months for a complete rewrite - was about a week of working on the code and almost 2 months spent on reviews, tests, and of course some of that time was wasted as we were doing this for the first time for such a large codebase. The rewritten app is doing fine in production for a while now.
I can only compare the outputs to the quality of the outputs of our regular engineering teams. It compares fine vs. good dev teams, IMHO.
The part about refactoring is very interesting and reassuring. I sometimes think I'm holding it wrong when I end up refactoring most of the agent's code towards our "opinionated" style, even after laying it out in md files. Thank you very much for this insight.
Thanks! In our limited experience, Claude does not focus that much on guardrails and code quality when building a feature - but can be pretty focused on code quality and architecture when asked to do just that. So, one a few hours to iterate a feature, a few hours to refactor. Rinse and repeat.
Very nice insight, that’s where the value is, even with a lot of time refactoring, testing and reviewing the compressed code phase is so much gziped than it’s still worth it to use an imperfect LLM. Even with humans we have all those post phases so great structure around the code generation leads to a lot of gains.
It depends on industries and what’s being developed for sure
I don't want to defend LLM written code, but this is true regardless if code is written by a person or a machine. There are engineers that will put the time to learn and optimize their code for performance and focus on security and there are others that won't. That has nothing to do with AI writing code. There is a reason why most software is so buggy and all software has identified security vulnerabilities, regardless of who wrote it.
I remember how website security was before frameworks like Django and ROR added default security features. I think we will see something similar with coding agents, that just will run skills/checks/mcps/... that focus have performance, security, resource management, ... built in.
I have done this myself. For all apps I build I have linters, static code analyzers, etc running at the end of each session. It's cheapest default in a very strict mode. Cleans up most of the obvious stuff almost for free.
> For all apps I build I have linters, static code analyzers, etc running at the end of each session.
I think this is critically underrated. At least in the typescript world, linters are seen as kind of a joke (oh you used tabs instead of spaces) but it can definitely prevent bugs if you spend some time even vibe coding some basic code smell rules (exhaustive deps in React hooks is one such thing).
Well it's all tradeoffs, right? 6 months for 9 FTEs is 54 man months. 2 months for 2 FTEs is 4 man months. Even if one FTE spent two extra months perusing every line of code and reviewing, that's still 6 man months, resulting in almost 10x speed.
Let's say you dont review. Those two extra months probably turns into four extra months of finding bugs and stuff. Still 8 man months vs 54.
Of course this is all assuming that the original estimates were correct. IME building stuff using AI in greenfield projects is gold. But using AI in brownfield projects is only useful if you primarily use AI to chat to your codebase and to make specific scoped changes, and not actually make large changes.
I do greenfield in fluid dynamics and Claude doesn't help: I need to be able to justify each line of my code (the physics part) and using Claude doesn't help.
On the UI side Claude helps a lot. So for me I'd say I have a 25% productivity increment. I work like this: I put the main architecture of the code in place by hand, to get a "feel" for it. Once that is done, I ask Claude to make incremental changes, review them. Very often, Claude does an OK job.
What I have hard times with is to have Claude automatically understand my class architectures: more often than not it tries to guess information about objects in the app by querying the GUI instead of the data model. Odd.
Only small businesses and startups pay $200/month, most medium+ sized companies will have an enterprise plan and pay by token usage to access the security, privacy, and compliance guarantees that their legal and security teams require.
Also, I think the $200/mo plan is subsidized by VC money and is likely hemorrhaging money for Anthropic, so it's not really meaningful to reason around that.
This is hard to say definitively. The new Nvidia Vera Rubin chips are 35-50x more efficient on a FLOPS/ megawatt basis. TPU/ ASICS/ AMD chips are making similar less dramatic strides.
So a service ran at a loss now could be high margin on new chips in a year. We also don’t really know that they are losing money on the 200/ month subscriptions just that they are compute constrained.
If prices increase might be because of a supply crunch than due to unit economics.
Honestly some of this info is quite hard to parse. I think the efficiency is ~35X on the system level but 10X on the hardware level. I think this is due to Nvidia bringing in Groq in addition to chip improvements.
Given the massive costs on training, R&D, and infrastructure build out in addition to the fact that both Anthropic and OpenAI are burning money as quickly as they can raise it, the safe bet is on costs going up.
Seems like the real costs and numbers are very hidden right now. It’s all private companies and secret info how much anything costs and if anything is profitable.
That's like saying driving for Uber is profitable if you only take into consideration gas mileage but ignore car maintenance, payments, insurance, and all the other costs associated with owning a car.
Not sure which exact model you're talking about, but I've run the 30B and the 3.5 32B models and both can get some things done and can waste tons of time getting some things completely wrong.
They're fun to mess around with to figure out what they can and can't do, but they're certainly not not tools in the way I can count on Codex.
Yeah completely agree. Even out of my own pocket I'd be willing to spend ~1k a month for the current AI, as compared to not having any AI at all. And I bet I could convince an employer to drop 5k a month on it for me. The consumer surplus atm is insane.
Since Anthropic has capacity problems I'm pretty sure they're limiting the $20/month guys to serve the $200/month business plans. I'm afraid coding will increasingly become pay-to-play. Luckily there is good competition.
I mean, my openclaw instance was billing $200 a day for Opus after they banned using the max subscription. I think a fair amount of that was not useful use of Opus; so routing is the bigger problem. but, that sort of adds up, you know! At $1/hr, I loved Openclaw. At $15/hour, it's less competitive.
If your revenue doubles every month, then in the first month where you make $2.5B, your total lifetime revenue has been $5B ($2.5B this month, $1.25B the month before, etc. is a simple geometric series). But your current revenue run rate for the next year will be $2.5B x 12 = $30B.
They're not quite growing that fast, but there's nothing inherently inconsistent between these claims... as long as the growth curve is crazy.
1) It's in their interest to distort numbers and frame things that make them look good - e.g. using 'run-rate'
2) The numbers are not audited and we have no idea re. the manner in which they are recognising revenue - this can affect the true compounding rate of growth in revenues
The numbers are certainly audited by their investors. Anthropic isn't foreign to PR talk, but investors know what to look for in their book. They aren't stupid unlike how they are viewed on HN.
There are more investment money than Anthropic need. They can pick and choose.
I do, and I do trust the numbers. I doubt Anthropic is pursuing fraud given that they already don't have enough compute to serve demand. What is the point of lying to the public, investors and risk going to jail?
I have some feedback that's annoyingly non-specific.
I used Zulip a few years ago as a contractor. It seemed _fine_, but I didn't love it. Specifically, the UI felt sluggish and generally the experience was somewhat unpolished. Maybe things have changed, a lot happens in a couple years, but there you go
Thanks for sharing the channel. I was using Zulip 1 year ago in my MacOS. It crashes every a few days. Later we give it up and switch to something else. I could submit issue next time I use it. I don't know when though.
I recommend that anyone who is responsible for maintaining the security of an open-source software project that they maintain ask Claude Code to do a security audit of it. I imagine that might not work that well for Firefox without a lot of care, because it's a huge project.
But for most other projects, it probably only costs $3 worth of tokens. So you should assume the bad guys have already done it to your project looking for things they can exploit, and it no longer feels responsible to not have done such an audit yourself.
Something that I found useful when doing such audits for Zulip's key codebases is the ask the model to carefully self-review each finding; that removed the majority of the false positives. Most of the rest we addressed via adding comments that would help developers (or a model) casually reading the code understand what the intended security model is for that code path... And indeed most of those did not show up on a second audit done afterwards.
I have a few skills for this that I plug into `cargo-vet`. The idea is straightforward - where possible, I rely on a few trusted reviewers (Google, Mozilla), but for new deps that don't fall into the "reviewed by humans" that I don't want to rewrite, I have a bunch of Claude reviewers go at it before making the dependency available to my project.
I'm curious: has someone done a lengthy write-up of best practices to get good results out of AI security audits? It seems like it can go very well (as it did here) or be totally useless (all the AI slop submitted to HackerOne), and I assume the difference comes down to the quality of your context engineering and testing harnesses.
This post did a little bit of that but I wish it had gone into more detail.
The HackerOne slop is because there's a financial incentive (bug bounties) involved, which means people who don't know what they are doing blindly submit anything that an LLM spots for them.
If you're running the security audit yourself you should be in a better position to understand and then confirm the issues that the coding agents highlight. Don't treat something as a security issue until you can confirm that it is indeed a vulnerability. Coding agents can help you put that together but shouldn't be treated as infallible oracles.
That sounds like the same problem (a deluge of slop) with a different interface (eating straight from the trough rather than waiting for someone to put a bow on it and stamp their name to it)?
Seems very similar to turning on compiler warnings. A load of scary nothings, and a few bugs. But you fix the bugs and clarify the false positives, and end up with more robust and maintainable code.
I've found it's pretty good. It's really not that much of a burden to dig through 10 reports and find the 2 that are legitimate.
It's different from Hacker One because those reports tend to come in with all sorts of flowery language added (or prompt-added) by people who don't know what they are doing.
If you're running the prompts yourself against your own coding agents you gain much more control over the process. You can knock each report down to just a couple of sentences which is much faster to review.
You also probably have a much better idea of where the unsafe boundaries in your application are. Letting the models know this information up front has given me a dozen or so legitimate vulnerabilities in the application I work on. And the signal to noise ratio is generally pretty good. Certainly orders of magnitude better than the terrible dependabot alerts I have to dismiss every day
The question still is: will enough useful stuff be included, to make it worth to dig through the slop? And how to tune the prompt to get better results.
I assume it's just like asking for help refactoring, just targeting specific kinds of errors.
I ran a small python script that I made some years ago through an LLM recently and it pointed out several areas where the code would likely throw an error if certain inputs were received. Not security, but flaws nonetheless.
That depends on how the tool is used. People who ask for a security vulnerability get slop. People who asked for deeper analysis often get something useful - but it isn't always a vulnerability.
[claimed common problem exists, try X to find it] -> [Q about how to best do that] -> "the best way to do it is to do it yourself"
Surely people have found patterns that work reasonably well, and it's not "everyone is completely on their own"? I get that the scene is changing fast, but that's ridiculous.
There's so much superstition and outdated information out there that "try it yourself" really is good advice.
You can do that in conjunction with trying things other people report, but you'll learn more quickly from your own experiments. It's not like prompting a coding agent is expensive or time consuming, for the most part.
that's kinda what I was looking for tbh. I didn't know that was an option, and nothing in the thread (or article) seemed to imply it was.
I was mostly working off "well I could ask claude to look at my code for security problems, i.e. 'plz check for security holes kthx', but is that really going to be the best option?". if "yes", then it would kinda imply that all the customization and prompt-fiddling people do is useless, which seems rather unlikely. a premade tool is a reasonable starting point.
* Specification extraction. We have security.md and policy.md, often per module. Threat model, mechanisms, etc. This is collaborative and gets checked in for ourselves and the AI. Policy is often tricky & malleable product/business/ux decision stuff, while security is technical layers more independent of that or broader threat model.
* Bug mining. It is driven by the above. It is iterative, where we keep running it to surface findings, adverserially analyze them, and prioritize them. We keep repeating until diminishing returns wrt priority levels. Likely leads to policy & security spec refinements. We use this pattern not just for security , but general bugs and other iterative quality & performance improvement flows - it's just a simple skill file with tweaks like parallel subagents to make it fast and reliable.
This lets the AI drive itself more easily and in ways you explicitly care about vs noise
My approach is that, "you may as well" hammer Claude and get it to brute-force-investigate your codebase; worst case, you learn nothing and get a bunch of false-positive nonsense. Best case, you get new visibility into issues. Of _course_ you should be doing your own in-depth audits, but the plain fact is that people do not have time, or do not care sufficiently. But you can set up a battery of agents to do this work for you. So.. why not?
IMO the key behavior is that LLMs are really good at fuzz testing, because they are probabilistic monkeys on typewriters that are much more code-aware than a conventional fuzz tester. They cannot produce a comprehensive security audit or fix security issues in a reliable way without human oversight, but they sure can come up with dumb inputs that break the code.
The results of such AI fuzz testing should be treated as just a science experiment and not a replacement for the entire job of a security researcher.
Like conventional fuzz testing, you get the best results if you have a harness to guide it towards interesting behaviors, a good scientific filtering process to confirm something is really going wrong, a way to reduce it to a minimal test case suitable for inclusion in a test suite, and plenty of human followup to narrow in on what's going on and figure out what correctness even means in the particular domain the software is made for.
>the key behavior is that LLMs are really good at fuzz testing, because they are probabilistic monkeys on typewriters
That's exactly what they're not. Models post-trained with current methods/datasets have pretty poor diversity of outputs, and they're not that useful for fuzz testing unless you introduce input diversity (randomize the prompt), which is harder than it sounds because it has to be semantical. Pre-trained models have good output diversity, but they perform much worse. Poor diversity can be fixed in theory but I don't see any model devs caring much.
Because if you want the work done correctly, you WILL put the time you thought you were saving in. Either up front, or in review of its work, or later when you find out it didn’t do it correctly.
It depends whether anyone was ever actually going to spend that week doing it the "hard" way. Having Claude do it in a few minutes beats doing nothing.
Put another way: I absolutely would have an intern work on a security audit. I would not have an intern replace a professional audit though.
It's otherwise a pretty low stakes use. I'd expect false positives to be pretty obvious to someone maintaining the code.
The problem is that this is a decision that costs money. Relying on a system that makes money by doing bad things to do good things out of a sense of morality when a possible outcome is existential risk to the species is a 100% chance of failure on a long enough timeline. We need massive disincentives to bad behavior, but I think that cat is already out of its bag.
I appreciate that the HN community values thoughtful, civil discussion, and that's important. But when fundamental civil liberties are at stake, especially in the face of powerful institutions and influence from people of money seeking to expand control under the banner of "security", it's worth remembering that freedom has never simply been granted. It has always required vigilance, and at times, resistance. The rights we rely on were not handed down by default; they were secured through struggle, and they can be eroded the same way.
Power corrupts, and absolute power corrupts absolutely.
On a long enough timeline literally everything has 100% chance of failure. I'm not trying to be obnoxious, I just wanna say: we only got this one life and we have to choose what to make of it. Too many people pretend things are already laid out based on game theory "success". But that's not what it's about in life at all.
It's an interesting idea. The current endowment size of less than $1M is immaterial; the question with a project like this will always be how it is able to raise capital.
A way something like this could be interesting is if founders started donating 5% of equity when they started a company to an open source foundation like this one.
It doesn't impact the founder much financially: Success is very binary for founders. But in aggregate, if thousands of startup founders do this, there would be some hits and some of those hits could generate a significant endowment.
(You can also try to get people to donate who feel their success was built on top of open source, but I feel that after 10 years building a company to IPO, one's attention as a founder has likely been on business metrics and spending time with business people, not on technology and spending time with technologists, and that shift in attention can reduce people's feeling of gratitude for the amazing inheritance that is open-source software).
Consider this as a nonprofit startup that has just raised a pre-seed round. The current size of $700K is indeed immaterial, as our plan is to scale it significantly in the coming years.
The closest real-world comparable to what we are building is the Wikimedia Endowment, whose former Director is among OSE’s advisors. Like Wikimedia, we aim to be supported not only by large donations but also by contributions from large community — in our case, 150M+ GitHub users.
Our target audience is diverse - from highly successful founders to everyday developers. The Open Source Endowment is prepared to accept donations in both cash and stock from these groups.
While 5% of equity may be too much, 1% seems achievable. I am personally ready to commit 1% of the carried interest from my own VC fund to the endowment.
"Preseed round" is just the small funding when the project is a very early stage. We expect to raise more funding when the endowment matures. There is no ROI, it is a pure charity.
There are many existing projects like this, I'm not going to pick the one started by a former VC
Ask if those have not changed things, why would a VC run thing make things better? The last 2 decades have shown us what VC centeredness has brought us
Can you point out some existing ones with traction? I'm looking more at the list of people who are on board with it ("Trusted by open source creators" section) than who is actually running it, which I think is more important to get buy in than whoever is pulling admin strings in the back.
You said: "There are many existing projects like this", directly followed by "That's kind of the point, there are none." when asked for an example. Which one is it?
It's seems like a pretty thankless fundraising job but one where having connections to companies, banks and experience with distributing funds comes in handy. What's in it for a VC? I'd assume incoming deal flow and connections to new open source companies.
Seems more promising to me than a technical open source maintainer stepping up to do it on the side. But time will tell.
Not the former VC, but an active venture capitalist: https://kvinogradov.com. I earn money by investing in open source / AI / infra software startups, and I spend money by donating to nonprofit open source projects :-)
Also, it is not a VC who run things, but the team which consists of people with diverse backgrounds (founders/executives/devs x OSS/nonprofit) and the donor community (which everybody can join): https://endowment.dev/community/
It's the VC "class", similar to the Epstein Class, nowhere near as bad or vile, but have definitely been one of the primary reasons the wealth gap and inequality have risen and continue to rise
It's not a competition, but it is faux pax for GGP to make the comment the way they did. I would hope you all would know that having been here more than a decade
We all - the OSE donors - are donating personal savings to make this work, and are directly interested to make this org as efficient as possible. Having skin in the game is best way to keep such nonprofits accountable. There is no leftovers or fees - all investment income from donations goes to open source, except for minimized operating expenses (e.g. accounting). It is run by the team of volunteers without salaries, and we require $1000+/year donations from all directors of this org.
You have to give them at least some benefit of the doubt.
I have my own questions yet which I haven't materialized, about the bylaws and selection criteria. But at least they are proposing a new approach.
I'd at least give them a year tryout to see in what it materializes.
At the current state of things I'm a bit in doubts about the market, and how that will change across the year. Though, it would also be interesting, as an idea, to participate in such a process as a member.
I'm not an expert here on equity, 5% feels a bit high. I like the idea - even 1% would be significant. In general, could we start to hold accountable and start using public status and tracking of organizational commitment to the open source software they use and make profit off of - that might help a lot as well.
We in general are too naive and fail to hold accountable others and ourselves from contributing back when we use resources from the common public. Open source is like imo the common welfare/public resource. If others are abusing it, its time to call them out for what they are really doing: framing, abusing and stealing from the public and maybe we need to be more serious about this and change the public access (maybe hybrid-open source for companies who use OS software) and create systems to legally enforce these.
The companies listed there have all paid at least $2000/eng on staff/year to OSS maintainers. Real accountability. Endowment accepts corporate donors but is primarily geared towards individuals at this point. Pledge members are all companies. Both/and ... to the OSS moon!
I feel like the articles on this have been very negative ... but aren't the Anthropic promises on safety following this change still considerably stronger than those made by the competing AI labs?
So that seems about what you should expect.
reply