Ok the computer on your desk then? I guess it’s probably a laptop and not on all the time, but that shouldn’t prevent it from working for you when you need it. Probably want a good backup strategy though
Yep. This is basically an ad for their "Artifacts" product. They are probably hoping to make more off of the spend of contestents than they pay in the prize to the winner.
And only if you are a US or Canadian citizen/team and doubly so only if you use a permissive license like MIT, Apache-2.0 or BSD-2/3. Having even a moderate degree of control over your project is too much to ask for. But you do get a dinner, which might make it all worth it.
A hero hacking for free food and a chance to swap Cloudflare credits for stolen goods on the black market. That is W.Gibson's original cyberpunk spirit.
> So in this new world where you have hundreds, or even thousands, of agents working on the same codebase at the same time, what does the foundation look like?
So, would it maybe make sense to question this whole bit, before we starting creating platforms for something like that?
Why do you need hundreds of thousands of agents working on the same codebase? In my experience, and what I see around me, quality code that actually works in production isn't produced by "software factory autonomously run by 1337 agents", but instead one human sitting and interacting with maybe 1-3 agents max, back and forth, pair programming rather than letting hundreds of them output million of tokens over hours.
Are others seeing the same thing, or am I in my own little bubble here? All the "software factory with agents" approaches I've spent time looking into, literally produces trash on top of trash, while I see senior developers 10x their productivity while producing better code than before and they have one terminal open with three panes, a text editor, a agent TUI and a general shell, that's it. Is what I'm seeing no the typical situation out there in the wider world?
It would make sense for a monorepo at big tech company, where a single source control system contains many thousands of common libraries and the apps that use them. And now with AI, maybe a small company could build a large, sprawling monorepo?
But I don't think it's actually a good idea. Keeping everything on the same version is difficult. We have package managers that do a better job.
Not to take anything away from your point, but TFA said hundreds or thousands - not hundred of thousands. Couple orders of magnitude of difference there…
You’re still spot on - even thousands of agents working on a single codebase would mean hundreds of humans directing them…
Thank you for pointing this out! I always love a good competition and since I already have a workers paid plan it seemed fun. But I'm not eligible, so I guess I'll rebuild github without giving any IP to Cloudflare
I'll be honest: I saw the prize was a trip to SF and — while I was vanishingly unlikely to enter anyway — that was enough to kill any idea of entering. It's been over 20 years since I was last in the USA, and I have no intention of visiting again any time soon.
Sometimes I think back to Google Wave, that beautiful glimmer of real-time collaborative canvases, announced in 2009 when Angular and Backbone hadn't even been invented, and think it launched almost two decades too early.
We're now in a world where we expect real-time interfaces to be developed and immediately deployed for our feedback by agents, in business-critical settings where classic SDLC timelines are far too slow, but code quality is becoming more difficult to manage at scale.
Git, at its core, is a fundamental notion that behavior is an auditable tree of immutable changes, where any participant can rearrange or rewind or remix this sequence on a local machine to show, and interact with, a provisional combination of those changes.
Google Wave, with its operational transformation (OT) systems, was similar in many regards. We have CRDTs now, and far better techniques for auto-merging workstreams - including agentic systems that can resolve conflicts intelligently!
Wave fundamentally had a concept that people would come together and evolve a simple chat interface, into a customized real-time application for their use cases, and that that iteration could happen in real-time. Wherever Git and the broader notion of SDLC goes, I hope it brings the best of this thinking.
The Wave release was the event that really kicked off my starting to rethink my own framing of what Google's engineering culture actually produces. I was so excited for its release, possibly moreso than any major innovation before then, & what was delivered was pure crap implementation wise. The idea was brilliant, & open, so theoretically someone could have done it well, but Google poisoned the well by releasing such a turd.
Throughout it's existence Google has been revered as a company for its engineering output, but if you interrogate that even a little bit, you end up with a very small minority of gems among a massive ocean of over engineered crap. Even the huge objective open successes like k8s are to this day sold with the massive caveat of "it's heavy & over engineered, but": nobody's calling k8s elegant. Pretty much all of their good products are acquisitions, many of which they've subsequently degraded.
One can certainly make this argument about almost any large corporation, but I do think there's very few with such a stark divide between how the quality of their engineering work is revered & the reality.
Most of the tech unicorns are like this. Zuckerberg caught lightning in a bottle one single time and everything they’ve tried since has sucked. Instagram was an acquisition. So were oculus and WhatsApp.
Amazon hasn’t built anything innovative since the Kindle.
Surely it’s a consequence of being publicly traded that these companies cease to be able to develop good novel products rather than acquire competitors or iterate on past successes.
Why would it be a consequence of being publicly traded? Apple has less concentrated ownership than Facebook or Google and has been far better at developing novel products.
I think releasing Wave as its own product, via private beta, was a mistake. If they wanted to reinvent email, they should have done it with Gmail, similar to what Apple did with iMessage.
Gmail could operate as it always has, being an email client that integrates with every other email client. But when a Gmail user emails another Gmail user (or a group of them), have the thread automatically turn into a Wave, with everything that entails. This gets the new features where people already are, creates an incentive for people to move their email to Gmail, and doesn’t create yet another inbox for a person to manage.
I always saw Wave as a business failure, not an engineering one, for this reason.
This would've been great but given what they came out with on a greenfield project, I strongly suspect an in-Gmail approach would have ended up qualitatively worse from UX & design perspective, likely driving users away from Gmail as a whole, & not just Wave. It would've resulted in a backlash from the mainstream, rather than Wave which was simply a damp squib the mainstream mainly ignored.
In an ideal world you're right, but I still think it was an engineering failure as, theoretically, it should be easier to make something usable on a greenfield project, & it was a horrific mess.
It was the type of product that was an engineering impossibility to launch at the time. Mobile browsers of the time (and many users' desktop browsers!) couldn't run JS quickly enough to allow for the real-time experience - and reportedly Wave would consume 300-500 MB of RAM at the time, which was a ton for 2009!
So they would have needed to invest in native mobile apps, and in significant levels of optimization. And none of this, not web or mobile, had the developer experience necessary to iterate quickly enough as the UI would inevitably evolve upon contact with customers, and you'd end up having many widgets reflecting a centralized global state.
Not to mention that you needed sticky server-side sessions to run the operational transformations efficiently, which harkens to the KV caching challenges that still challenge us today.
But it was an incredible dream, and it was a key source of inspiration to me to choose CS as a path.
There were plenty of apps at the time doing real-time experience, they just weren't running 300-500mb of RAM while doing so because they weren't overengineered by idiots.
There was nothing about the wave protocol or concept that necessitated the bloated mess of JS they churned out. A big part of the problem with optimisation, on top of it doing way too much in poorly thought through ways, was simply that nobody in Google even knew JS, because they were just transpiling Java to JS.
I didn’t remember Buzz, so I looked up a video about it. It looks more like a social network than an evolution of email. I think that was the issue there. They tried to shove social networking into email. I don’t know about anyone else, but I always wanted social networks to be an island, especially in that era. The social contract and expectations with email are different from social networking.
Huge mistake! I loved Wave, and used it very successfully on one creative project. When I tried again, with some of the same people, we'd collectively burned all of our invite tokens and couldn't get any more, so we had to revert to emailing things back and forth so the new folks weren't kept out of the loop. That killed it, as far as any of us were concerned. I think I used it one more time, to plan a party or something with my sister, and never again. Integrating it into Gmail, as you suggest, would have been a better path, but hardly necessary. It was great as a stand-alone product, but destroyed itself because the damn invite system stopped the network effect cold.
In other words, you wish Google had EEE'd email. And also stopped supporting normal emails between two Gmail users, and completely redesigned the product.
You think this wouldn't get people who just wanted email to quit Gmail and use something else instead?
If you could attach or insert a wave into an email, that would make more sense.
Having gone through AOSP source code multiple times in the past, I really ask myself where those top engineers that make it through Google's famous hiring practices land.
The way they code Java, the C style C++ in some parts, the Android Studio stable releases that are always as buggy as preview releases (to the point of becoming a meme among Android devs), and so on.
> I really ask myself where those top engineers that make it through Google's famous hiring practices land.
Can I question the quality of said hiring practices?
I have been rejected for a project that was starting from scratch on something exactly like I had been building for 6 years at a competitor, based on such famous hiring practices (not at Google though). I was literally more experienced than the whole team on what they were building.
Because you hire people who are really good at leetcode doesn't necessarily mean that you always get the best candidates for the job?
My sense is that it likely made sense before Campbell's law took effect. IIRC they developed a reputation in the early 2000s for only hiring very bright people who could solve those kinds of problems on the fly. Then 1. the company needed more employees and 2. people started grinding away practicing those problems so they could pass tests that were intended to filter them, and you got what you have now. Lots of other companies cargo-culted them in the meantime and thought the studying was the point, or maybe for them it was (measuring compliance instead of brilliance).
having worked on AOSP for 3 years. I can attest most developers are capable but are not incentivized correctly. The appearance of improvement (demo quality code) is good enough in many circles to "complete" a project and move on. Net effect - the tragedy of the commons. Compound over a decade and 10-20 minute builds and 5-10 minute test time is the norm, and at that point even properly motivated - "would die for clean code" - sort of devs have a hard time. Put in place completing management chains all behaving the same (want to appear more productive/useful than others) and the mess is very hard to get out of. People were allowed/encouraged to cut corners I would let a junior dev cut on any project (duplicating resources from different parts of the build), building tool that demanded duplicate configuration, etc. Not a problem of capability (in some cases, yes, but rare), a broken selfish set of senior devs and leadership. Likely because it's not in google's interests for the project to be easy to work with/productive on. Open source washing was useful early on, now it's something of a liability. Only data gathered from devices and a little bit of cash from the play store are assets.
Whats crazy ia that Wave i. its alpha/beta form whatever it wqs back then to me was marvel if engineering and atm I would be able to release it in a day or so thanks to AI.
It lives on as Google docs. Go to http://docs.new and then share the link to collaborators. It's so smooth. It's sticky. I have hope that Google will figure out how to evolve that into a bigger platform, but maybe someone else will come along and do it.
lol, spec work anyone? For maybe-maybe-not $25k, you build something that could create millions in enterprise value.
Advice for everyone considering this: if you're passionate about ideas in this space and have access to an LLM — build it yourself and start your own company. In fact, message me easting.exe [at] gmail. I'll throw in $25k to get us started. I'm a prior founder with an exit. Because this offer from Cloudflare is ridiculous.
The problem is git is three things, a command line interface, a wire protocol, and a database format, and you can't replace all three at once if you want to gain any acceptance. So you have to chip away at the individual pieces. The real problem though is that AI makes version control invisible because the agents are capable of producing the artifacts. AI makes git's data model all wrong. What you want is then a way for AI to be able to make, say, 1,000 views into the codebase, cheap. That involves spinning up VMs/containers and is a much different problem than hey, let's make github2.com.
Same, but the real question is how. At this point, the things they are proposing are genuinely useful for the environment that we are finding ourselves in? How does one even begin to allow for less dependency here without appropriate substitute/mitigation for what cloudflare renders relatively painless.
> How does one even begin to allow for less dependency...
One remembers that during the vast stretch of time that Cloudflare wasn't offering the new whiz-bang service, one was doing just fine in one's endeavors.
If one is fine with CloudFlare being the MITM for most of the Internet, then this doesn't matter at all to you. But if that or any other aspect of how CloudFlare does business and what their capabilities allow them to do concerns you, then that's how one begins.
It's true that setting up a service without Cloudfare is painful. But there will be a day in which anyone that has set up something using Cloudfare will go through some pain either by something breaking or because Cloudfare will show their true colors.
Consider Nostr ngit. There will eventually be decentralized alternatives for GitHub that are better than GitHub, but not for a while. ngit is about the best we can do for now. And to truly get rid of civilization-scale cancers such as Cloudflare, we have to shrink the fab (i.e. put the equivalent of ASML, TSMC, and Shenzhen into a single box and sell it as a home appliance), because the root problem is hardware manufacturing, as explained here:
https://news.ycombinator.com/item?id=49690354
HTTP provided a means for multiple clients to fetch resources from a central server. If centralization was antithetical, the clients would have been P2P.
I am curious what people think about the use case that is different for AI agents compared to humans. Aside from the things people use SCM for already that is.
Fossil fits the bill if you ask me because it has built in forum and stuff too, so Agentic discourse can happen there, commits happen in the SCM history. And it has auto sync so they can automatically sync their state.
I looked into beads but I didn't see a way to make it work any better than fossil, and fossil does more stuff. My typical setup is to use the repo as a working directory, the tickets for todo, wiki/forum for conversation. There is also a chat interface, but I haven't tried that with agents yet.
But I love fossil for this. You can create users for all of the agents (or agent roles). The CLI for fossil is just a binary and it compiles nearly everywhere.
+1 over here for agentic fossil. With fossil the "work" is integrated in with the code. Beads separates this out, the beads are instances of work that agents can consume, and they aren't part of the work repo. I could see why you might want this, but I still think that fossil gives you more utility.
i feel like dropping the review and test phase -- especially in the agentic context - is incredibly spicy though.
So if I wanted to use fossil scm, i'd have to find a way to glue that on, and now ... we'Re basically in the same situation as with any other solution: it supports only a subset of the feature we want.
and especially CI pre "merge" is a hard requirement, and fossil doesnt have any concept for that i think?
But the last time i evaluated it was in the mid 2010s, so things may have progressed since? but couldn't find anything on cursory glance and AI confirmed that position, but we all know how often its wrong... so how did yall solve that issue?
yes, I agree: architecthre design, linting, commit msg structure, unit testing and other ci gates helps to direct the agents into building better software.
Fossil doesn’t have GitHub PR capabilities per-se. But its design philosophy is different with a focus on smaller groups of devs and not so much drive-by patches. I think in the case being discussed for AI agents, it can be simplified.
If you want human review on the code I’m thinking keep it simple and just review in branches/tags before merging OR even just have loose patch files.
As we’re seeing with resurgence of command-line utility by agents, that extends equally well to the O.G. diff/patch. A PR is literally just a diff with commentary and an approval process prior to merging. Diffs can be attached to forum topics and so-forth.
Lots of possibilities, but I think the main thing discussed here is how is version control better suited to AI agents moving forward.
in my case, i use opencode with oh-my-openagents. Omo has an orchestrator in charge and manage all the intetactions between agents. ADRs store decisions and beads store decisions as well (including design ones), then multiple agents work on a single bead.
Of course cloudflare wants you to bring more data and money to cloudflare. Is any of this actually useful though? Do agents need git? Are agents even useful?
203 comments
[ 0.24 ms ] story [ 16.7 ms ] threadthe computer under your desk!
Roll your Own, don't depend on billionaire platforms to get your work done...
Orchestrating an agent free for all tends to invite more chaos management.
At the same time there’s folks who quietly have this working.
25k seems like a small bounty for such a large prize.
https://www.cloudflare.com/git-competition/?cf_page=next-git...
The human wallet
I’m tempted to ask an agent to submit an entry for me.
What an offensive slap in the face.
Tone deaf to the nth degree.
This is basically aimed at AI startups who are in SF anyways and need a platform for marketing. So no shortage of contestants.
So, would it maybe make sense to question this whole bit, before we starting creating platforms for something like that?
Why do you need hundreds of thousands of agents working on the same codebase? In my experience, and what I see around me, quality code that actually works in production isn't produced by "software factory autonomously run by 1337 agents", but instead one human sitting and interacting with maybe 1-3 agents max, back and forth, pair programming rather than letting hundreds of them output million of tokens over hours.
Are others seeing the same thing, or am I in my own little bubble here? All the "software factory with agents" approaches I've spent time looking into, literally produces trash on top of trash, while I see senior developers 10x their productivity while producing better code than before and they have one terminal open with three panes, a text editor, a agent TUI and a general shell, that's it. Is what I'm seeing no the typical situation out there in the wider world?
But I don't think it's actually a good idea. Keeping everything on the same version is difficult. We have package managers that do a better job.
Not to take anything away from your point, but TFA said hundreds or thousands - not hundred of thousands. Couple orders of magnitude of difference there…
You’re still spot on - even thousands of agents working on a single codebase would mean hundreds of humans directing them…
Cloudflare is perhaps most famously and most significantly an international, global platform. That's kind of the whole point.
Only in the smallprint does it mention you must be a United States or Canada resident to enter.
https://en.wikipedia.org/wiki/Google_Wave
https://youtu.be/v_UyVmITiYQ?t=3850
https://www.usenix.org/legacy/event/lisa09/tech/slides/berli...
We're now in a world where we expect real-time interfaces to be developed and immediately deployed for our feedback by agents, in business-critical settings where classic SDLC timelines are far too slow, but code quality is becoming more difficult to manage at scale.
Git, at its core, is a fundamental notion that behavior is an auditable tree of immutable changes, where any participant can rearrange or rewind or remix this sequence on a local machine to show, and interact with, a provisional combination of those changes.
Google Wave, with its operational transformation (OT) systems, was similar in many regards. We have CRDTs now, and far better techniques for auto-merging workstreams - including agentic systems that can resolve conflicts intelligently!
Wave fundamentally had a concept that people would come together and evolve a simple chat interface, into a customized real-time application for their use cases, and that that iteration could happen in real-time. Wherever Git and the broader notion of SDLC goes, I hope it brings the best of this thinking.
Throughout it's existence Google has been revered as a company for its engineering output, but if you interrogate that even a little bit, you end up with a very small minority of gems among a massive ocean of over engineered crap. Even the huge objective open successes like k8s are to this day sold with the massive caveat of "it's heavy & over engineered, but": nobody's calling k8s elegant. Pretty much all of their good products are acquisitions, many of which they've subsequently degraded.
One can certainly make this argument about almost any large corporation, but I do think there's very few with such a stark divide between how the quality of their engineering work is revered & the reality.
Amazon hasn’t built anything innovative since the Kindle.
Surely it’s a consequence of being publicly traded that these companies cease to be able to develop good novel products rather than acquire competitors or iterate on past successes.
The number of products under the AWS that are more impactful to society and more profitable to Amazon is vast.
Gmail could operate as it always has, being an email client that integrates with every other email client. But when a Gmail user emails another Gmail user (or a group of them), have the thread automatically turn into a Wave, with everything that entails. This gets the new features where people already are, creates an incentive for people to move their email to Gmail, and doesn’t create yet another inbox for a person to manage.
I always saw Wave as a business failure, not an engineering one, for this reason.
What Meta got right with Muse - https://news.ycombinator.com/item?id=49946526 - October 2026
In an ideal world you're right, but I still think it was an engineering failure as, theoretically, it should be easier to make something usable on a greenfield project, & it was a horrific mess.
https://theappslab.com/2009/10/05/google-wave-the-aftermath/
So they would have needed to invest in native mobile apps, and in significant levels of optimization. And none of this, not web or mobile, had the developer experience necessary to iterate quickly enough as the UI would inevitably evolve upon contact with customers, and you'd end up having many widgets reflecting a centralized global state.
Not to mention that you needed sticky server-side sessions to run the operational transformations efficiently, which harkens to the KV caching challenges that still challenge us today.
But it was an incredible dream, and it was a key source of inspiration to me to choose CS as a path.
There was nothing about the wave protocol or concept that necessitated the bloated mess of JS they churned out. A big part of the problem with optimisation, on top of it doing way too much in poorly thought through ways, was simply that nobody in Google even knew JS, because they were just transpiling Java to JS.
You think this wouldn't get people who just wanted email to quit Gmail and use something else instead?
If you could attach or insert a wave into an email, that would make more sense.
The way they code Java, the C style C++ in some parts, the Android Studio stable releases that are always as buggy as preview releases (to the point of becoming a meme among Android devs), and so on.
Can I question the quality of said hiring practices?
I have been rejected for a project that was starting from scratch on something exactly like I had been building for 6 years at a competitor, based on such famous hiring practices (not at Google though). I was literally more experienced than the whole team on what they were building.
Because you hire people who are really good at leetcode doesn't necessarily mean that you always get the best candidates for the job?
Advice for everyone considering this: if you're passionate about ideas in this space and have access to an LLM — build it yourself and start your own company. In fact, message me easting.exe [at] gmail. I'll throw in $25k to get us started. I'm a prior founder with an exit. Because this offer from Cloudflare is ridiculous.
Single point of failure, for both technical and political failures.
One remembers that during the vast stretch of time that Cloudflare wasn't offering the new whiz-bang service, one was doing just fine in one's endeavors.
If one is fine with CloudFlare being the MITM for most of the Internet, then this doesn't matter at all to you. But if that or any other aspect of how CloudFlare does business and what their capabilities allow them to do concerns you, then that's how one begins.
Do you want the pain now or later?
We want more Cloudflare.
Also, HTTP came much later after the internet was created.
All of this is documented extensively—I recommend reading up on internet history; it's fascinating.
I am curious what people think about the use case that is different for AI agents compared to humans. Aside from the things people use SCM for already that is.
Fossil fits the bill if you ask me because it has built in forum and stuff too, so Agentic discourse can happen there, commits happen in the SCM history. And it has auto sync so they can automatically sync their state.
But I love fossil for this. You can create users for all of the agents (or agent roles). The CLI for fossil is just a binary and it compiles nearly everywhere.
+1 over here for agentic fossil. With fossil the "work" is integrated in with the code. Beads separates this out, the beads are instances of work that agents can consume, and they aren't part of the work repo. I could see why you might want this, but I still think that fossil gives you more utility.
More info on beads if you are curious: https://github.com/gastownhall/beads
So if I wanted to use fossil scm, i'd have to find a way to glue that on, and now ... we'Re basically in the same situation as with any other solution: it supports only a subset of the feature we want.
and especially CI pre "merge" is a hard requirement, and fossil doesnt have any concept for that i think?
But the last time i evaluated it was in the mid 2010s, so things may have progressed since? but couldn't find anything on cursory glance and AI confirmed that position, but we all know how often its wrong... so how did yall solve that issue?
If you want human review on the code I’m thinking keep it simple and just review in branches/tags before merging OR even just have loose patch files.
As we’re seeing with resurgence of command-line utility by agents, that extends equally well to the O.G. diff/patch. A PR is literally just a diff with commentary and an approval process prior to merging. Diffs can be attached to forum topics and so-forth.
Lots of possibilities, but I think the main thing discussed here is how is version control better suited to AI agents moving forward.
Strangest tech announcement ever.
None of this is very clever or very compelling.