Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Can someone please explain to me how do people build these kind of tools? My background is classic Java/C# backend development and SQL. A bit microservice using Spring Boot. Its 8:30pm and I'm watching React tutorials to understand better how modern websites are built - e.g. use useState, useRef etc.

    Now, how does any of my experience translate to building tools like cmux? I genuinely want to understand how.

    Is the answer to go line by line of cmux code base or make an attempt to open a PR on one of the bugs issues on cmux and, by magic and time, I will eventually understand?

    by mattfrommars
  • What would you recommend to someone new in your team who had only ever used python and a bit of SQL, and had never touched Java or Spring Boot?
    by rahimnathwani
  • High level: hit github api, feed code to llm, display results in web app.

    If you want to learn web apps start with the docs, eg. Official react docs or even just learning vanilla JavaScript if you don’t know it.

    Start with little pieces like hitting the github API and displaying some json in the terminal

    You could also just start prompting an llm to scaffold a project for you and then trying to debug whatever issues come up (and they will)

    by joshribakoff
  • If your goal is to make something useful, I think the fastest way is probably to build a CLI only version since you can theoretically render heatmaps and make a task manager in a CLI form factor. And your background in Java/C# helps here.

    Use Claude Code or Codex for everything, learn how to prompt well. >90% of cmux and 0github.com was written by LLMs. Most of it was just me asking the LLM to implement something, testing it to see if it works, and if it doesn't, I'll ask the LLM to write logs, and I'll paste the logs back to the LLM. Ask gpt-5-pro for architecture choices, like what tech/dependencies to use.

    But if your goal is to learn React, I'd recommend going through the official getting started documentation, it's pretty good.

    by lawrencechen
  • Your experience in coding is enough, you need more practice in "problem solving" with crazy ideas and working through them to the finish line.

    Besides, this is just a thin layer on an LLM, with questionable actual quality. Learn to do the real work, no magic machine can take learning and skill building off your shoulders.

    by rf15
  • I suggest that you ask Claude Code to build such a website for you with a minimal set of features, with tons and tons of comments and design/architecture documents plus tests. Once that is done, you can start reading the code. You can even read as it is working.

    Then, you can point Claude Code to a file/a function/a few lines and ask follow-up questions.

    After that, there are even more things to do. If you want a different perspective, you could try completely reimplementing the thing. My guess is that Claude will use Next.js. You can ask Claude not to do that but instead use a different UI framework/no framework combined with C#, if that's something you are interested in. If you want to actually learn all the details, you can start setting things up yourself and write the website. You can add features or try making the site scalable, under AI-assisted or vibe coding mode.

    It will not produce the most elegant code or have the best architecture, but will be good enough for your purpose. I think it's the most efficient way to get some learning that is specifically suited to your needs in this age.

    by rs186
  • This is really useful. Might want to add a checkbox at a certain threshold, so that reviewers explicitly answer the concerns of the LLM. Also you can start collecting stats on how "easy to review" PR's of team members are, e.g. they'd probably get a better score if they address the concerns in the comments already.
    by jtwaleson
  • Change the domain name, you will likely get a cease and desist otherwise.
    by petralithic
  • Maybe add some caching? I clicked one of the example PRs and it kept loading forever...
    by ramonga
  • pushed a fix, should work now
    by austinwang115
  • Shoot, we should have caching in place already. Taking a look now
    by lawrencechen
  • This is something I have found missing in my current workflow when reviewing PR's. Particularly in the age of large AI generated PR's.

    I think most reviewers do this to some degree by looking at points of interest. It'd be cool if this could look at your prior reviews and try to learn your style.

    Is this the correct commit to look at? https://github.com/manaflow-ai/cmux/commit/661ea617d7b1fd392...

    by cdiamand
  • https://github.com/manaflow-ai/cmux/blob/main/apps/www/lib/s...

    This file has most of the logic, the commit you linked to has a bunch of other experiments.

    > look at your prior reviews and try to learn your style.

    We're really interested in this direction too of maybe setting up a DSPy system to automatically fit reviews to your preferences

    by lawrencechen
  • I tried it on a low-complexity Rust PR I worked on a few months back and it did a pretty good job. I'd probably change where the highlights live (for example x.y.z() -> x.w.z() should highlight y/w in a lot of cases).

    For the most part, it seems to draw the eye to the general area where you need to look closer. It found a near-invisible typo in a coworker's PR which was kind of interesting as well.

    https://0github.com/geldata/gel-rust/pull/530

    It seems to flag _some_ deletions as needing attention, but I feel like a lot of them are ignored.

    Is this using some sort of measure of distance between the expected token in this position vs the actual token?

    EDIT: Oh, I guess it's just an LLM prompt? I would be interested to see an approach where the expected token vs actual token generates a heatmap.

    by mmastrac
  • Happy to hear!

    > Is this using some sort of measure of distance between the expected token in this position vs the actual token?

    The main implementation is in this file: https://github.com/manaflow-ai/cmux/blob/main/apps/www/lib/s...

    EDIT: yeah it's just a LLM prompt haha

    Just a simple prompt right now, but I think we could try an approach where we directly see which tokens might be hallucinated. Gonna try to find the paper for this idea. Might be kinda analogous to the "distance between the expected token in this position vs the actual token."

    by lawrencechen
  • This is very cool and I could see it being really useful especially for those giant PRs. I'd prefer it if instead of the slider I could just click the different heatmap colors and if they indicated what exactly they were for (label not threshold). I get the underlying premise but at a glance it's more to process unless I was to end up using this constantly.
    by timenotwasted
  • Currently tooltips are shown when hovering on highlighted words. Need to make it visible on mobile though. Was wondering if you were thinking of another way to show the labels besides hovering?
    by lawrencechen
  • > Under the hood, we clone the repo into a VM, spin up gpt-5-codex for every diff, and ask it to output a JSON data structure that we parse into a colored heatmap.

    Wait, you're consuming the energy a small town needs for a week just so you don't have to write a couple of lines to parse your content into a heat map of whatever strings you're looking for? This is crazy, and given our climate shituation, should be illegal.

    by isodev
  • You’re not going to be able to keep the domain name 0github.com for too long. I’d suggest you start finding a new one immediately.
    by otterley
  • why?
    by personjerry
  • > https://0github.com/stack-auth/stack-auth/pull/988

    Very fun to see my own PR on Hacker News!

    This looks great. I'm probably gonna keep the threshold set to 0%, so a bit more gradient variety could be nice. Red-yellow-green maybe?

    Also, can I use this on AI-generated code before creating a PR somehow? I find myself spending a lot of time reviewing Codex and Claude Code edits in my IDE.

    by n2d4
  • Perhaps more time that you would spend writing code yourself.
    by blks
  • Yeah we definitely want to make the gradient and colors configurable.

    What form factor would make the most sense for you? Maybe a a cli command that renders the diff in cli or html?

    by lawrencechen
  • It’s an interesting direction, but feels pretty expensive for what might still be a guess at what matters.

    I’m not sure an LLM can really capture project-specific context yet from a single PR diff.

    Honestly, a simple data-driven heatmap showing which parts of the code change most often or correlate with past bugs would probably give reviewers more trustworthy signals.

    by kburman
  • A large portion of the lines of code I'm considering when I review a PR are not part of the diff. This has to be a common experience - think of how often you want to comment on a line of code or file that just isn't in the PR. It happens almost every PR for me. They materialize as lose comments, or comments on a line like "Not this line per-se but what about XYZ?" Or "you replaced this 3 places but I actually found 2 more it should be applied to."

    I mean these tools are fine. But let's be on the same page that they can only address a sub-class of problems.

    by nonethewiser
  • > Honestly, a simple data-driven heatmap showing which parts of the code change most often or correlate with past bugs would probably give reviewers more trustworthy signals.

    At first I thought this to but now I doubt that's a good heuristic. That's probably where people would be careful and/or look anyway. If I were to guess, regressions are less likely to occur in "hotspots".

    But this is just a hunch. There are tons of well reviewed and bug reported open source projects, would be interesting if someone tested it.

    by cerved
  • Premise is amazing. Wonder if there are tools that do something similar by looking at diff entropy.
    by ivanjermakov
  • Yeah this is honestly pretty expensive to run today.

    > I’m not sure an LLM can really capture project-specific context yet from a single PR diff.

    We had an even more expensive approach that cloned the repo into a VM and prompted codex to explore the codebase and run code before returning the heatmap data structure. Decided against it for now due to latency and cost, but I think we'll revisit it to help the LLM get project context.

    Distillation should help a bit with cost, but I haven't experimented enough to have a definitive answer. Excited to play around with it though!

    > which parts of the code change most often or correlate with past bugs

    I can think of a way to do the correlation that would require LLMs. Maybe I'm missing a simpler approach? But agree that conditioning on past bugs would be great

    by lawrencechen
  • This is not that expensive with Gemini, they give free keys that have plenty of req/day, you can upload your diff + a bundle of the relevant part of the codebase and get this behavior for free, at least for a small team with ~10-20 PR's / day. If you could run this with personal keys, anyhow.
    by CuriouslyC
  • Why does it require signing and granting you full access to act as me on Github to use?

    cmux-agent requires access to your Github account:

        Verify your GitHub identity
    Know what resources you can access
    Act on your behalf
    View your email addresses
    I would have logged an issue for this but I see you've disabled logging issues on the repo. Seems a bit sus to me.
    by smcleod