Hacker Newsnew | past | comments | ask | show | jobs | submit | yoelhacks's commentslogin

$8/100k tokens strikes me as potentially a TON if the idea is that we're going to be running this as part of the iterative local development cycle (or god forbid letting agents run it whenever they decide). As you mentioned, one of the issues with AI generated code is often that it writes too much and needs direction on shrinking down.

I could easily see hitting 10k+ LOC on routine tickets if this is being run on each checkpoint. I have some tickets that require moving some files around, am I being charged on LOC for those files? Deleted files? Newly created test files that have 1k+ lines?


> $8/100k tokens strikes me as potentially a TON

It's $8/100K lines of code. Since we're using a mix of models across our main agent and sub-agents, this normalizes our cost.

> I could easily see hitting 10k+ LOC on routine tickets if this is being run on each checkpoint. I have some tickets that require moving some files around, am I being charged on LOC for those files? Deleted files? Newly created test files that have 1k+ lines?

We basically look at the files changed that need to be reviewed + the additional context that is required to make a decision for the review (which is cached internally, so you'd not be double-charged).

That said, we're of course open to revising the pricing based on feedback. But if it's helpful, when we ran the benchmarks on 165 pull requests [1], the cost was as follows:

- Autofix Bot: $21.24 - Claude Code: $48.86 - Cursor Bugbot: $40/mo (with a limit of 200 PRs per month)

We have several optimization ideas in mind, and we expect pricing to become more affordable in the future.

[1] https://github.com/ossf-cve-benchmark/ossf-cve-benchmark


Ah sorry, you were very clear on the pricing page and I meant 100k LoC, not tokens.

In your explanation here, you mention running it per PR - does this mean running it once? Several times?


Very interesting, I like that they call out the particular areas where it is strong.


Maybe. Current prices certainly include probability that Tesla is able to pull off major transformation into more than just a car manufacturer (batteries, supercharge network, self-driving software, etc). The implicit assumption is that Musk is helpful for that - which would certainly have been true some years ago. Getting rid of him would be an admission that the loftiest dreams won't happen as fast as some would like, but doesn't necessarily mean they're out of the picture.


Panasonic makes the actual batteries at Gigafactory on Panasonic owned/operated lines that happen to lease space inside a Tesla building.

https://en.wikipedia.org/wiki/Gigafactory_Nevada#Operations


Had fun making this visualization of how security works - look right? https://eraser.io/git-diagrammer?diagramId=Gyr7VvuFOGNGsnznQ...


After seeing some really cool tools that build high-level overview diagrams of a repo, we wanted to see if we could create a tool for building any diagrams from a codebase (for the diagrams we support, which are architecture, ERD / schema, flow charts, and sequence diagrams).

Try it out on any public Github repo! A few notes: 1) Works best if you are pretty explicit with the prompt. We're only offering 2 free runs right now because of the expense involved. We have some examples built in and I've left a couple links below. 2) Works best on repos of a few hundred files or low thousands. More than that and it really helps if you can provide some explicit instructions on where to look. 3) The feature that links to specific code files is pretty fun.

Here a some examples:

Supabas real time updates: https://eraser.io/git-diagrammer?diagramId=2XXiOvPfJjtfMbWdM... Subase realtime architecture: https://eraser.io/git-diagrammer?diagramId=nIvgs2dMvarCYJ8zV... Primsa migrations: https://www.eraser.io/git-diagrammer?diagramId=uK7UptrWd4EEY...


I was also unclear what this actually did. Not sure how much this helped, but it is a nice visualization of what's happening: https://eraser.io/git-diagrammer?diagramId=ysiiD14zhpPemvoJO...


I was curious about Mistral so I made a few visualizations.

A high level diagram w/ links to files: https://eraser.io/git-diagrammer?diagramId=uttKbhgCgmbmLp8OF...

Specific flow of an OCR request: https://eraser.io/git-diagrammer?diagramId=CX46d1Jy5Gsg3QDzP...

(Disclaimer - uses a tool I've been working on)


I often see takes on this topic from the engineering side. "It's hard!". "Managers just don't understand".

It feels like as a community, it would be useful to get more articles seeing things from the other side and exploring functional approaches beyond provide-a-worst-case-scenario-estimate.

There's a reason this dynamic is so pervasive. In order for everyone in an organization to do their job well, people do often need a realistic set of estimates. Can sales promise the prospect this integration? Can marketing plan a launch for the new feature? Can the CPO make a reasonable bet on a new line of work?

In my experience, the nuance here is more about handling the mis-estimates. How do we discuss the risks up front? How much work should we put into contingency planning? How do we handle the weeks / months before a deadline when it is clear that we need to limit scope?


This is it. I'm a hardcore engineer at heart who has a lot of these sales, marketing, and product folks as friends, and can attest to the fact that they also have constraints.

The whole world runs on deadlines and timelines. Even a president is elected for a specific duration. If you're in a B2B setting, the customer demands (sometimes even contractually binding) at least the Quarter when something will be delivered.

Time is the only common denominator by which different activities can be coordinated. Without some heed to time, there will be no coherence.


Presidents are technically timeboxed, at least in the US.


Javascript is outperformed by WebAssembly in the sense that it runs faster.

A lot of things that bring a lot of value to a lot of people are still much, much faster to build via the JS / TS ecosystem.

It absolutely makes sense that calculation-heavy workloads will be ported to WASM, but there's a lot more to building an app.


> but there's a lot more to building an app.

Like what? Visual UI designers? WebAssembly's got you covered: https://platform.uno/blog/uno-platform-studio-featuring-hot-...

Running Visual Basic in a C# application compiled to WebAssembly? Sure, why not: https://bandysc.github.io/AvaloniaVisualBasic6/


The shift right parts of the article are more interesting...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: