2001zhaozhao

The question is what they plan on doing with all their scientific knowledge once they succeed.

Sure, they'll keep it internal for a while to make sure their knowledge bank is more thorough than everyone else's, and because oftentimes discoveries can be far more convincing internally than externally (you need fewer sigmas for it to update your belief in a certain direction). But then how do they intend to profit from it in the end?

> Note that Jeff and crew have cleverly structured their company to avoid problematic uses of AI

Do you have more sources/info on this?

I'd intuit that for an AI video editor workflow you'd probably want something in the middle of this CLI solution and a full GUI? I'd take a crack at making one if only i had some expertise in the field.

Would something like "services deflation" even show up in the numbers? That's what I'd expect to happen first

Agreed, i forked a devtool (vibe-kanban) months ago for my own use but keeping up with upstream was a significant burden even with LLMs. The benefit of a well designed plugin system in the devtool is not only to allow sharing of customizations, but also to make users' private customizations cheaper to maintain.

A PWA might be well suited to your needs. Even Apple's restrictive model leaves plenty of room to build useful apps especially if they are designed to connect to a backend (like the ones in the post).

But why build your own from scratch when you can do it on top one extensible UI platform that already has all of your organizational context, not to mention coding agents already built-in that you can just tell it to build & deploy your personalized workflow softwaree from scratch? ;-)

you probably still need a human for oncall but the llm can try to solve any issues first before the human gets paged

It's really hard to focus on the unique aspect of your tool because it runs the risk that people will think it's unfamiliar and therefore not useful to them. That's why a lot of the tool marketing pages look the same even though the tools themselves might be different or innovative

I'll need to explore how they're doing org wide context and security for sure. This seems extremely complementary to my own coding tool which currently gives the best AI interface for individuals.

Would be cool if in a few epic tickets i'll have both their org wide architecture AND a productive individual coding interface :)

i think it makes perfect sense and I'll probably adopt the same posture for my open source project.

The idea is that the core dev team is the one with the AI harness. If someone contributes an idea they can just feed it to their AI to implement it and it probably costs 10 minutes of human time, because they trust that their harness will be able to implement the feature competently.

So, because the implementation effort is so low, the only aspect that matters if the quality of the idea. It's way easier to screen human written text than a bunch of code in a PR. If you just give them code, they would not know if you made it with a competent harness. If you gave them a AI written design they would have a lot more to read through to decide whether it's slop. If you just give them an idea it's a lot easier to determine whether it's high quality.

These Todo items on the side in the video seem to be useful.

I'm not so sure about that tool toolbar. It might as well just be a tool selector dropdown in a typical chat window.

I think they definitely have the IDE vision in mind and are trying to move off of terminals, based on two parts of the original article

> so you can close the application, reconnect from another device, and pick up exactly where you left off.

I think this is the remote IDE development dream that no one could quite get right, partly because there wasn't enough reason to run things on a 24/7 device. I think with coding agents that can run in the background this changes.

> Sessions can be accessed through the web and native macOS/iOS applications, and sharing a live session with other people is built in from the start.

I'd really like to point out that "Sharing a live session" is horrible UX for a terminal multiplexer because the terminal has to be the same size (# of rows/cols) on all viewers' screens, and some of these viewers may be on a phone and others on a laptop. Believe it, I tried myself and there's no good way around the problem.

What is interesting is that they added this sentence anyway. This tells me that their long-term endgame is not the terminal. They're most likely trying to build a GUI-based agent IDE and then eventually expand to other work (per their headline of being the "multiplexer for all work") as it all gets more and more agent-based anyways. Well, they're not alone in having that vision.

Right now there is about a 95% chance that when I manually review an agent's code I find nothing that needs changing.

I find it plausible that an extra agentic review pass and more testing can bring this number up to the point that one never needs to review code again. AI writes pretty good code nowadays.

(You still need to be diligent and decide the architecture during the planning, and read the gotchas and "things to note" that the agent will spit out at the end of implementation if it had to diverge from the plan.)

The thing is, one could probably create a specially-prompted "agentic homework cheating" harness that catches all of these professors' trick attempts 100% of the time while also making the response look more human.

The only solution imho is 100% course weighting on in-person proctored exams

I wonder how long it will take for this to get fully decensored and for bad, BAD things to happen

I write almost all code with GenAI nowadays. I'd like to say it's not slop, but I guess now there's no way to get Codeberg to agree.

It is probably from randomness. The benchmark tasks nowadays are so long that you can't really afford to run a large number of samples of them per model & effort combination

I thought the cache length was 1 hour, not 5 minutes?

Yep i aim to split my work into tickets that are <=1k lines of code each. In the end it all gets squashed into a mega 10k commit regardless but i can keep track of the quality much more that way.

(more precisely the sub-tickets merge into a bigger feature branch, which in turn gets squash merged into the main branch at the end. i have a tool that automates this flow with a gui and ticket management.)

I had a bit of this impression when reading the post as well as the authors' product website. A lot of it does seem to be stuck in 2025.

For instance I think their post "long-context isn't the answer" on their website post straight-up isn't accurate, and gives me the impression they are just extrapolating previous performance to new models. In my experience, Opus 4.6 and newer have worked very reliably for long context to me (i don't perceive any intelligence drop at 700-900K tokens). Yeah it's extremely cost-inefficient, but it works.

> When I say maintainability, I mean the specific thing where it becomes really, really hard to change one part of the codebase without breaking another part.

The corollary of agents being bad at maintainability but good at coding is that you can vibecode all the parts where maintainability doesn't matter.

So if you build a (domain-specific) modular architecture for your software first you can then just let your software factories loose on building the modules.

I think the right shape is to review and merge directly from the agent window.

They seem to be doing this to disincentive people who spam bug reports with AI where only 10% of them are actually real.

Instead, now you probably need to be actually vetting your bug reports yourself so that a large percentage of them are real, before they let you in the verified program, where you get a normal amount of payout.

So it incentivizes high quality AI bug spamming (if you can manage it) over low quality AI bug spamming. In turn since less people are doing low quality AI bug spamming, Github gets to spend less time filtering the low quality reports.

I feel like the simplest Pelicanmaxxing method is just to teach the model that whenever a user asks for a svg illustration of something with no other clarification, it should default to making it as detailed and pretty as possible. This would make every single svg from that model look better and not just the pelican on a bicycle

bro literally tried to make satire and ended up laying out an actual compelling case for AI management

AI 2027 was right.

> Cheap

> Hetzner cloud

> published in December 2025

which means that it's twice as expensive now as it was when the article was published

I think a tool with this kind of UX is the future of engineering orgs. It reminds me a lot of JetBrains Space (which I already thought was a good idea back then), but with agents.

I don't see a lot of information about the Git hosting aspect of the product on the website, though. Somewhat doubtful that they will be able to make a Git forge with similar polish to GitLab

It subjectively seems to me that integrating with an existing forge (e.g. Forgejo) on the API layer and rebuilding the auth and frontend is a better bet. You get stable features like PRs, permissions and CI actions out of the box and they stay synced with known formats in the community and so make your tool easy to adopt. Though making a forge from scratch does have advantages especially for internal company use cases.

Another problem I see with Buzz is that the tool doesn't seem to be taking advantage of its vertical integration inside its UX enough. There is a lot more you can do with full control over Git hosting, project context, and org-wide chat in a single tool than what this tool attempts to do right now.

I wonder when they are going to start realizing that on-premises self-hosted is the solution over local