It is SO NICE to see people working on making fast, nice-to-use tools. It's a lovely experience to use diffshub. Thank you for creating it, and than you for the great write-up! (I made it "that far" )
Have you split your 100k loc codebases into smaller crates? If you take a look at eg gitoxide's repo, they've split it in many smaller crates. I think that might help with keeping the scope for the ai small and maybe help with keeping contracts tight and well-defined.
Yes, that absolutely helps (and yes, doing that :) ), I'm going even further and basically hard-enforcing a LOC limit per file too, which helps a lot as well.
The complexities LLMs end up putting themselves in is more about the bigger architecture/design of the program, rather than concrete lines, where things end up so tangled that every change requires 10s of changes across the repository, you know, typical "avoid the hairball" stuff you come across in larger applications...
You could probably use just an X-scanner, and instead of a CCD line sensor, use a regular 2D image sensor if you used a "1 pixel wide" slit aperture to crop the image perpendicularly to the direction that the prism disperses the light. So instead of a single pixel being dispersed, you disperse a line.
You would reduce the time required by the root of the number of pixels you want (assuming a square image).
(This is what we do in momentum-resolved electron energy loss spectroscopy. In that situation we have electromagnetic lenses that focus the electrons that have been dispersed, so we don't have as bad a chromatic aberration problem as the other response mentions).
I would love to see e.g. a butterfly image with a slider that I could drag to choose the wavelength shown!!
> I would love to see e.g. a butterfly image with a slider that I could drag to choose the wavelength shown!!
Here[1] are some 31-band hyperspectral images of butterflies. Numpy/pillow can unpack the .mat files into normal images. Then perhaps vibecode a slider, or just browse the band images?
I knew of the site having explored "First-tier physical-sciences graduate students are often deeply confused about color. Color is commonly taught, starting in K... very very poorly. So can we create K-3 interactive content centered around spectra, and give an actionable understanding of color?"
This is called chromatic aberration, for those who are intrigued.
Given that regular phone cameras have sensors that detect RGB, I wonder if one could notice improved image sharpness if one had three camera lenses (and used single-color sensors) next to one another laterally, with a color filter for R, G and B for each one respectively. So that the camera could focus perfectly for each wavelength.
This is very interesting, but like sibling comments, I'm very curious as to how you run this in practice. Do you just tell Claude/Copilot to do what you describe?
You don't need most of this. Prompts are also normally what you would say to another engineer.
* There is a lot of duplication between A & B. Refactor this.
* Look at ticket X and give me a root cause
* Add support for three new types of credentials - Basic Auth, Bearer Token and OAuth Client Creds
Claude.md has stuff like
"Here's how you run the frontend. here's how u run backend. This module support frontend. That module is batch jobs. Always start commit messages with ticket number. Always run compile at the top level. When you make code changes, always add tests" etc etc
I used it to map out storage locations and refill stations at our online grocery picking stations, then export it to read in using geopandas in order to calculate the shortest distances between all locations!
I'd recommend using git switch instead of checkout, since the checkout command is so overloaded. And restore instead of checkout for restoring changes.
I know it's just my opinion, but even though 'checkout' is overloaded with meanings, I always find it the most unambiguous. Some of my coworkers keep telling me to use 'switch' instead, but every time I try it, I find myself wondering how it works
I get it but I think you're essentially saying "I learnt it this way and it's hard to change once I learnt it that way". My argument is that "when teaching others, it's better to teach them to use switch and restore rather than checkout".
Unfortunately, muscle memory cannot be changed that easily. And thanks to the git maintainers, the checkout command still exists, because apparently they know that.
Any suggestions for «orchestrating» this type of experiment?
And how does one compare the results in a way that is easy to parse? 7 models producing 1 PR each is one way, but it doesn’t feel very easy to compare such.
For comparison, there's a `review` command that launches a sandboxed agent to review a given run and rank the various implementations. We usually run 1–3 review agents, pull the top 3 diffs, and do manual review from there.
We're working on better automation for this step right now.
You need something "more" on the website before you ask people to create an account. "Team workspace that stays fast" isn’t clear enough for me, at least. What is a workspace? What does the interface look like? Is it in the browser? Is it an app?
People will go "what is this?", "huh, I’m not gonna make a user for this, can’t tell what it is". Those are my 2 cents.
+1 to that. As a user, I am tired of having to sign up for an account on a SaaS website or installing an app from Github, only to realize the UI isn't a good fit for me. This will usually result in me bouncing from the app website instead of trying it out.
Suggestion: have a non-login demo available on your website, and high-res screenshots/animed gif of the app in action on your Github repo.
Thanks for being receptive to the feedback :-) I actually checked out your demo now because it didn't require a login, and was impressed by what I saw. Nice work here!
reply