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...
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)
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?
Despite 28 years of effort at optimization, JavaScript is outperformed by WebAssembly. There's not much coming back from that:
https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...
https://www.amazon.science/blog/how-prime-video-updates-its-...
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.
It was fascinating how much tokenization strategies could affect a particular subset of queries. A really great example is a "W-4" or "W4" Standard tokenization might split on the "-" or split on letter / number boundaries. That input now becomes completely unidentifiable in the index, when it otherwise would have been a very rich factor in matching HR / salary / tax related content.
Different domain, but this doesn't shock me at all.