Async means I can delegate stuff to it and expect it's fixed when I come back. Also I can text it from my phone while I'm on the toilet. Very important.
OpenClaw meets this definition, but so does a 50 line Telegram wrapper around Claude Code / Codex ;)
The value of openclaw as I understand it is separate context management per venue (per dm, per channel, per platform, etc) and clever tricks around managing shared memories and state.
Well, that and skills to download more skills. It’s a lot faster and easier to extend OC than CC via prompts. It also has cron and other take-initiative features.
I had it hack up a poller for new Gitea notifications (for @ mentions and the like) that wakes up the main bot when something happens, so I have it interacting with a self hosted Gitea. There wasn’t even a Gitea skill for it, it just constructs API requests “manually” each time it needs to do something on it. I guess it knows the Gitea API already. It knew how to make a launchd plist and keep the poller running, without me asking it to do that. It’s a little more oriented toward getting things going and running than CC, which mostly just wants to make commits.
If you check the OpenClaw discord, a common sentiment there is "it works but only if you use Opus." That seems to be the actual situation now.
Grok 4 Fast told me its own internal system prompt has rules against autonomous operation, so that might have something to do with it. I am having decent results with it though.
I noticed the same thing in communication. Communication is now so frictionless, that almost all the communication I receive is low quality. If it cost more to communicate, the quality would increase.
But the value of low quality communication is not zero: it is actively harmful, because it eats your time.
In that world there's a process called "staking" where you lock some tokens with a default lock expiry action and a method to unlock based on the signature from both participants.
It would work like this: Repo has a public key. Submitted uses a smart contract to sign the commit with along with the submission of a crypto. If the repo merges it then the smart contract returns the token to the submitter. Otherwise it goes to the repo.
It's technically quite elegant, and the infrastructure is all there (with some UX issues).
But don't do this!!!!
I did some work in crypto. It's made me realize that the love of money corrupts, and because crypto brings money so close to engineering it corrupts good product design.
The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
Crypto has a perfect way to burn money, just send it to a nonexistent address from where it can never be recovered. I guess the trad fi equivalent are charitable donations.
The real problem here is the amount of work necessary to make this viable. I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals, not to mention all the potential contributors that have no access to Visa/MC (we do want to encourage the youth to become involved with Open Source). This basically means crypto, and crypto has its own set of problems, particularly around all the annoying KYC/AML that a normie has to get through to use it.
You can reduce the transactions with payment providers. Instead of money exchanging from contributor to maintainer, have a token exchange. Contributors fund tokens with real money, and pull requests cost and refund tokens. Like an escrow account. But the money never goes to the target system. There are no perverse incentives to steal tokens. If you get a reputation of not refunding tokens (which have no value to a maintainer), then contributors will dry up.
Probably just making it non refundable works almost as well (since time really is expended reading it), without the hassle of spinning up an intermediary layer blockchain.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
Plenty of businesses do the “your credit card will be charged $1 and then reversed” as a verification method that I don’t think it would be a major issue. I do wonder how much those companies are paying for that, though… I am guessing they lose some of that $1.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
…you might be right, but I do wonder if the situation would be different if “your business” was “Microsoft”. Obviously they would discuss this plan ahead of time.
> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:
A straight up non-refundable participation payment does not have this issue, and creates a different set of incentives and a different economy, while there also exist escape hatches for free-of-charge contributions.
> The real problem here is the amount of work necessary to make this viable.
Not necessarily. This article mentions Tezos, which is capable of doing such things on-chain already:
> all the annoying KYC/AML that a normie has to get through to use it.
There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.
You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.
For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.
That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.
It feels like the problem here comes from the reluctance to utilize a negative sum outcome for rejection. Instead of introducing accidental perverse incentives, if rejected your stake shouldn't go to the repo, 50% could be returned, and 50% deleted. If it times out or gets approved you get 100% back. If a repo rejects too often or is seen doing so unfairly reputation would balance participation.
> No, the perverse incentive is that there will be RepoCoin, and the people involved will be incentivized to make the price of that as high as possible.
Isn't this problem unrelated to cryptocurrency?
There will be the US dollar, and the people involved will be incentivized to keep its value high, e.g. by pressuring or invading other countries to prevent them from switching to other currencies. Or they'll be incentivized to adopt policies that cause consumer and government debt to become unreasonably excessive to create a large enough pool of debts denominated in that currency that they can create an inordinate amount of it without crashing its value.
Or on the other side of the coin, there will be countries with currencies they knowingly devalue, either because they can force the people in that country to accept them anyway or because devaluing their currency makes their exports more competitive and simultaneously allows them to spend the currency they printed.
If anything cryptocurrency could hypothetically be better at reducing these perverse incentives, because if good rules are chosen at the outset and get ossified into the protocol then it's harder for bad actors to corrupt something that requires broad consensus to change.
Sure, but your average developer doesn't have a lot of agency in if the US invades another country in order to increase the value of the coin they got for having a PR merged.
But with crypto they do. See for example all the BAGS coins that get created for random opensource projects and the behavior that occurs because of that.
Just use a stablecoin, don't float a "utility token" those things are stupid. Have a smart contract receive a USDC deposit. If the maintainer "times out" reviewing your PR, the contract returns all the deposit. If the maintainer does not accept your PR, the contract burns 0.5x of the deposit and returns the rest. Maintainers can decide to turn off the time-out for very popular projects where you probably would have devs trying to spam PRs for fame/recognition, but hopefully the deposit price can accurately reflect the amount of spam the project gets.
Utility tokens are fundamentally equities and you need to firewall equity from an organization the same way companies in most market economies are regulated.
The average developer also doesn't have a lot of agency with respect to how major chains like Ethereum are run either, but they can use them.
Creating your own chain just because you can rather than because you actually have a reason to implement the technology in a different way than anybody else should be disfavored and viewed with suspicion.
It's a huge shame that crypto has been so poorly-behaved as an industry that almost nobody is willing to touch it except for speculation. It could be useful but it's scared away most of the honest people.
The fact that people around the world are trading hundreds of billions of dollars of stable coins [1], with India, Pakistan, the Philippines and Brazil in the top five countries [2], not least of all for the purpose of "greater monetary stability" [3], I think points toward the revolutionary usefulness of its inherently non-speculative properties (as referenced in positive applications of crypto in above comments).
It really has been a shitshow of get rich schemes, and yet crypto keeps not dying, instead increasingly getting applied to extremely valuable real world every day use cases, which I think is evidence of the value of the inherent technology.
My point is that despite the incredible greed and desperation it not only doesn't die, its practical uses are growing. The numbers say that the actual value exceeds the grift.
"It's made me realize that the love of money corrupts".
Yep. How about $1 per PR. The submitter gets to choose from a list of charities. No refund if the PR is accepted.
The goal is to get rid of junk PR's. This would work. There could be a central payment system, which any open source project can integrate with. It could accept payment in say India, of the Indian PPP of $1, so you aren't shutting out poorer developers.
I would not pay any amount of money, even a trivial one, for the privilege of being able to do free work for a project - and I don't think I'm an outlier here.
Another way to think of it is: paying $1 to have your pr and concerns elevated above the supermajority sea (that which will be ai driven contributions). For that cost, it's a steal of the deal.
Then, from the perspective of "it's a donation to a project you care about" it becomes even more rational. But the project itself getting the money has all the problems others have outlined already, so that idea's a bit bust.
But I'm already donating my time by creating a PR, it definitely would disincentivize me to make PRs if I had to also pay in addition to already doing the actual work. Just always such a shame that the good people have to suffer because of the actions of the shitty people...
If that's actually the opinion of the maintainer, why even accept PRs at all? At that point, just categorically deny any. I was thinking more of actual community projects that _want_ community PRs. Those seem to have welcomed my contributions in the past, but of course they were not just AI slop or other low effort PRs.
Most of my PRs are drive-by PRs: I have an problem, maybe a bug or missing feature, that annoyed me enough to fix it. And because I want to use future versions without the work of maintaining a fork I instead invest the work to upstream the fix. A step that is sometimes more work than the fix itself. At that point I wouldn't mind paying $1 to get that PR looked at and merged.
But that is not the only type of PR. We clearly need escape hatches for people who engage with a project on a deeper level.
I think the core insight here is about incentives and friction, not crypto specifically.
I’m working on an open source CLI that experiments with this at a local, off-chain level. It lets maintainers introduce cost, review pressure, or reputation at submission time without tying anything to money or blockchains. The goal is to reduce low-quality contributions without financializing the workflow or creating new attack surfaces.
You don’t need a third party, or anybodies permission, nobody can censor you or block your transactions, you don’t need a bank account with everything that entails. The barrier of entry is the same as creating an SSH keypair. It works globally, fast, cheap. You do not need to trust anybody, all the code is open and the ledger is cryptographically verifiable by anyone. There are lots of advantages.
In this scenario, the repo owner can just merge the patch but still refuse to pay back the shitcoin. With escrow, the escrow entity would act as an arbiter
I built a side project to solve this for myself that’s basically an inbox toll system. It funnels emails from unknown senders into a hidden mailbox and auto replies to the sender with a payment link. After the sender pays, the email gets released to recipient’s main inbox. Recipient can set custom toll amounts, whitelist, etc.
The technical side of this seems easy enough. The human side, that seems more complicated.
Like, if I were your doctor or contractor or kid's schoolteacher or whoever you hadn't happened to already whitelist, and had sent you something important for you, and got that back as a response... I'm sure as heck not paying when I'm trying to send you something for your benefit.
no one paid me but didnt really have this running for very long on my inbox. was really just a poc. and you're right - the human side is weird. surprisingly hard to solve the "real human, not spam, that's also an email address you see for the first time" scenarios, which there are many of - even with LLMs
this was part of a little saas tool i was building (since retired it) so spent some time today having an LLM help me pull it into a headless service. far from perfect but sharing anyway. details in readme!
this was part of a little saas tool i was building (since retired it) so spent some time today having an LLM help me pull it into a headless service. far from perfect but sharing anyway. details in readme!
this was part of a little saas tool i was building (since retired it) so spent some time today having an LLM help me pull it into a headless service. far from perfect but sharing anyway. details in readme!
I had this idea / pet project once where I did exactly this for email. Emails would immediately bounce with payment link and explanation. If you paid you get credit on a ledger per email address. Only then the mail goes through.
You can also integrate it in clients by adding payment/reward claim headers.
Bill Gates already had this idea. All efforts to change email were already documented 25 years ago. The biggest changes are it is more centralized these days, SPF/DKIM/DMARC, JMAP innovation, oh... and one more thing! It is HUGE!! HTML email is the default...
And it would even still work for the CEO, they would just have to charge more than $1.
The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
> The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
>First you have to make it low-friction. If I want Joe Average to send me $1 in cryptocurrency, how is he getting $1 in cryptocurrency to send me?
Absolutely. You're 1000% correct. Cryptocurrency is way too high friction for stuff like that. When I wish to spend crypto, I need to:
[If you don't have an exchange account already, you'll need the 0.x steps too!]
0.0 Create an account on an exchange which is legally allowed to operate in your state/country;
0.1 Provide all sorts of KYC/AML info including photos of yourself and your government ID;
0.2 Wait hours/days/weeks for the exchange to "validate" your KYC/AML info and allow you to purchase crypto;
1. Log in to an exchange which is actually allowed to operate in the place where one resides;
2. Purchase Bitcoin or other coin the exchange deems appropriate (leaving aside the hefty fee charged for using fiat currency/traditional credit card);
3. Wait days/weeks until the exchange allows you to transfer the purchased cryptocurrency out of your exchange-hosted wallet;
4. Transfer crypto to a wallet you actually control;
5. Convert the crypto purchased on the exchange to the crypto coin required for whatever your purpose may be;
6. Transmit the crypto to the destination wallet.
Total time (not including setting up the exchange account, which can take anywhere from 1-10 days): 3-10 days.
All the setup is no worse than setting up a bank account
And technically it can be avoided through back channels if you know someone who already has it - can just pay them cash or whatever and they can send crypto to you
Crypto is very easy to transfer once you have a wallet
Its the exchange to/from real world currency where the friction is.
> All the setup is no worse than setting up a bank account
Which is a huge pain in the butt. If someone invented a new lower-spam email ecosystem that required everyone to make a new bank account, very few people would join.
I would say something about a combined account but many countries have already figured out free bank transfers without needing crypto so maybe do that?
People with very little to no skill in software development are spending hundreds of dollars on tokens to fix things for clout, will an extra dollar barrier really slow things down noticeably?
> But the value of low quality communication is not zero: it is actively harmful, because it eats your time.
But a non-zero cost of communication can obviously also have negative effects. It's interesting to think about where the sweet spot would be. But it's probably very context specific. I'm okay with close people engaging in "low quality" communication with me. I'd love, on the other hand, if politicians would stop communicating via Twitter.
The idea is that sustained and recurring communication would have a cost that quickly drops to zero. But establishing a new line of communication would have a slight cost, but which would quickly drop to zero.
A poorly thought out hypothetical, just to illustrate: Make a connection at a dinner party? Sure, technically it costs 10¢ make that initial text message/phone call, then the next 5 messages are 1¢ each, but thereafter all the messages are free. Existing relationships: free. New relationships, extremely cheap. Spamming at scale: more expensive.
I have no idea if that's a good idea or not, but I think that's an ok representation of the idea.
Haha yea, I almost didn't post my comment since the original submission is about contributors where a one time "introduction fee" would solve these problems.
I was specifically thinking about general communication. Comparing the quality of communication in physical letters (from a time when that was the only affordable way to communicate) to messages we send each other nowadays.
I'll simply never file PRs, then. I'd say 4 out of every 5 PRs I file never get a response. Some on very large projects, and I like to think my PRs are more useful than docs fixes or pointless refactors. I'm simply not going to spend money to have to float around in the void endlessly because a maintainer lost interest in the project and won't ever look at my PR, I'll simply keep my changes on a downstream fork.
Moreover, I'm not interested in having my money get handed over to folks who aren't incentivized to refund my money. In fact, they're paying processing costs on the charge, so they are disincentivized to refund me! There could be an escrow service that handles this, but now there's another party involved: I just want to fix a damn bug, not deal with this shit.
The system could be set up to automatically refund, if your PR wasn't checked for over $AVERAGE_TIME_TO_FIRST_REVIEW$ days. The variable is specific to the project, and even can be recalculated regularly and be parameterized with PR size.
there are many many examples where paying a nominal fee seems like it would get rid of the clowns. and it would. almost any place where the public can "post". but the challenge is to not inadvertently throw out the good ones.
once notable policy SQL Server enterprise support used to have was you must be available 24/7 if you submit a critical issue. Microsoft was demanding as much of their time as our time.
not sure how that could be rolled out to repos but it worked
This, but for an escrow so people can show their actual interest in GitHub Issues, instead of just demanding new features or fixes. So if it gets implemented, the devs get the bounty, if not then they're refunded. I sometimes think about how this could help fund open source at least a little bit.
No comment on making PRs paid, not everyone would react well to that, and some people might be in countries and circumstances where any amount would be problematic.
escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.
let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.
escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.
there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free
ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.
Or just don't refund it. Most people want to make contributions to open source, and everyone can afford $1. Exceptions can be made for very active contributors.
In fact, we can use an automated schedule: first PR - if rejected, 5€ are drawn from the contributor’s account, then 4€, 3€, etc (plug in your favourite decreasing function, round to 0€ when sufficiently close).
But, crucially, if accepted, the contributor gets to draw 5€ from the repository’s fund of failed PRs (if it is there), so that first bona fide contributors are incentiviced to contribute. Nobody gets to profit from failed PRs except successful new contributors. Virtuous cycle, does not appeal to the individual self-interest of repo maintainers.
One thing I am unsure of is whether fly-by AI contributions are typically made with for-free AI or there's already a hidden cost to them. This expected cost of machine-driven contribution is a factor to take into account when coming up with the upside/downside of first PR.
PS. this is a Gedankenexperiment, I am not sure what introducing monetary rewards / penalties would do to the social dynamics, but trying with small amounts may teach us something.
Well that's awfully assumptuous. So now a young college kid needs to spend time and money to be able to help out a project? I also don't like that this model inentivizes a few big PR's over small, lean, readable ones.
We're completely mixing up the incentives here anyway. We need better moderation and a cost to the account, not to each ccontribution. SomethingAwful had a great system for this 20 years ago; make it cost $10-30 to be an external contributor and report people who make slop/consistently bad PR's. They get reviewed and lose their contributor status, or even their entire account.
Sure, you can whip up another account, but you can't whip the reputation back up. That's how you make sure seasoned accounts are trustworthy and keep accounts honest.
in the 90s, before bayesian spam filtering, Microsoft proposed a proof of work for email along these lines. it would cost the server a few cents per message to sign and send emails, so spammers would not be able to afford spam, but regular senders could handle a small fee per day.
$1 might not be a lot to you, but in some countries that's the daily wage. Even in rich countries one dollar for some might be the difference between eating or not eating that day.
Paywalling without any regional pricing consideration it's just going to incentivize people from poor countries to not participate in your project. Maybe that's okay for you but it's something to consider.
You're right, I'm fortunate enough to not have this experience. But not only both food and gas are much more than 1€, but also people in this situation are too focused on finding a way to make money to care about submitting merge requests
Let's say you're a one-of-a-kind kid that already is making useful contributions, but $1 is a lot of money for you, then suddenly your work becomes useless?
It feels weird to pay for providing work anyway. Even if its LLM gunk, you're paying to work (let alone pay for your LLM).
It is a privileged solution. And a stupid one, too. Because $1 is worth a lot more for someone in India, than someone in USA. If you want to implement this more fairly, you'd be looking at something like GDP or BBP plus geolock. Streaming services perfected this mechanism already.
This might be by design. Almost anyone writing software professionally at a level beyond junior is getting paid enough that $1 isn't a significant expense, whether in India or elsewhere. Some projects will be willing to throw collaboration and inclusivity out the window if it means cutting their PR spam by 90% and only reducing their pool of available professional contributors by 5%.
Indian here. You are correct. Expecting any employed Indian software developer to not be able to spare 1$ is stupid. Like how exactly poor do you think we are?!
You misunderstood the point. The point isn't that you are poor. The point is that the burden of the money lies on average heavier on you than someone from USA. This creates an uneven playing field.
I like to compare it with donations. If you get a USD donated, that is the same USD regardless of who gave it. Right? Right?!? Either way you don't know how heavy the burden is on the person who donated. You probably don't care. But it matters to the person who donated.
I think the point was that if an aspirational minimum wage worker on a borrowed computer wants to put up a PR then it would cost them less than ten minutes of wages to afford $1USD in the US, while the same worker in India would need to put up about half a day's wages.
This is very noble in theory, but in practice you're not going to get many high-quality PRs from someone who's never been paid to write software and has no financial support.
so we continue to make the rich richer and the broke students struggle more to get valuable experience. Very easy to point in 10-20 years under the coming "engineer crisis" why 'suddenly' can't support the systems we built.
Students don't have a lot of money to burn here. They're borrowing money to study. You'll miss out on them. However, you're unlikely to notice. I mean, there is no control group in such experiment.
I think the open source ecosystem would definitely notice long-term. Most people who become regular contributors start out in university or earlier - that's wen you have the most time to spend on hobbies like oss.
>contributing to an open source project that you're likely already benefiting from.
Yes, but many people benefit for free. You see the backwards incentives of making the most interested (i.e. the ones who may provide the most work to your project) pay?
And none of that even guarantee support. Meanwhile you donate more and you get to tell people what the build. It's all out of what.
4. Do not refund + Auto-send discouragement response.
5. Do not refund + Block.
6. Do not refund + Block + Report SPAM (Boom!)
And typically use $1 fee, to discourage spam.
And $10 fee, for important, open, but high frequency addresses, as that covers the cost of reviewing high throughput email, so useful email did get identified and reviewed. (With the low quality communication subsidizing the high quality communication.)
The latter would be very useful in enabling in-demand contact doors to remain completely open, without being overwhelmed. Think of a CEO or other well known person, who does want an open channel of feedback from anyone, ideally, but is going to have to have someone vet feedback for the most impactful comments, and summarize any important trend in the rest. $10 strongly disincentives low quality communication, and covers the cost of getting value out of communication (for everyone).
I wonder if the problem of idle time / waiting / breaking flow is a function of the slowness. That would be simple to test, because there are super fast 1000 tok/s providers now.
(Waiting for Cerebras coding plan to stop being sold out ;)
I've used them for smaller tasks (making small edits), and the "realtime" aspect of it does provide a qualitative difference. It stops being async and becomes interactive.
A sufficient shift in quantity produces a phase shift in quality.
--
That said, the main issue I find with agentic is my mental model getting desynchronized. No matter how fast the models get, it takes a fixed amount of time for me to catch up and understand what they've done.
The most enjoyable way I've found of staying synced is to stay in the driver's seat, and to command many small rapid edits manually. (i.e. I have my own homebrew "agent" that's just a loop of, I prompt it, it proposes edits, I accept or edit, repeat.)
So then the "synchronization" of the mental state is happening continuously, because there is no opportunity for desynchronization. Because you are the one driving. I call that approach semi-auto, or Power Coding (akin to Power Armor, which is wielded manually but greatly enhances speed and strength).
> That said, the main issue I find with agentic is my mental model getting desynchronized. No matter how fast the models get, it takes a fixed amount of time for me to catch up and understand what they've done.
This is why I'm so skeptical of anyone running 6+ Claude sessions at a time. I've gotten to 5 but really that was across 3 sessions with 2 standing by just to commit stuff. And even with just 3 sessions I constantly lost where I was and wasted time re-orienting myself, doing work in the wrong session, etc.
>The most enjoyable way I've found of staying synced is to stay in the driver's seat, and to command many small rapid edits manually.
Same, there's a fantastic flow state/momentum I can get in a single session just knocking off features. I don't mind switching between two sessions in this state but the experience is better when it's two different projects vs two different features on the same project. The complete context switch lets be re-orient more easily
You still have to synchronize with your code reviewers and teammates, so how well you work together in a team becomes a limiting factor at some point then I guess.
Yes, and that constraint shows up surprisingly early.
Even if you eliminate model latency and keep yourself fully in sync via a tight human-in-the-loop workflow, the shared mental model of the team still advances at human speed. Code review, design discussion, and trust-building are all bandwidth-limited in ways that do not benefit much from faster generation.
There is also an asymmetry: local flow can be optimized aggressively, but collaboration introduces checkpoints. Reviewers need time to reconstruct intent, not just verify correctness. If the rate of change exceeds the team’s ability to form that understanding, friction increases: longer reviews, more rework, or a tendency to rubber-stamp changes.
This suggests a practical ceiling where individual "power coding" outpaces team coherence. Past that point, gains need to come from improving shared artifacts rather than raw output: clearer commit structure, smaller diffs, stronger invariants, better automated tests, and more explicit design notes. In other words, the limiting factor shifts from generation speed to synchronization quality across humans.
I've seen this happen over and over again well before LLMs, when teams are sufficiently "code focused" that they don't care much at all about their teammates. The kind that would throw a giant architectural changes over a weekend. You then get to either freeze a person for days, or end up with codebases nobody remembers, because the bigger architectural changes are secret.
With a good modern setup, everyone can be that "productive", and the only thing that keeps a project coherent is if the original design holds, therefore making rearchitecture a very rare event. It will also push us to have smaller teams in general, just because the idea of anyone managing a project with, say, 8 developers writing a codebase at full speed seems impossible, just like it was when we added enough high performance, talented people to a project. It's just harder to keep coherence.
You can see this risk mentioned in The Mythical Man Month already. The idea of "The Surgery Team", where in practice you only have a couple of people truly owning a codebase, and most of the work we used to hand juniors just being done via AI. It'd be quite funny if the way we have to change our team organization moves towards old recommendations.
I've mostly done solo work, or very small teams with clear separation of concerns. But this reads as less of a case against power coding, and more of a case against teams!
You can ask the agent to reverse engineer its own design and provide a design document that can inform the code review discussion. Plus, hopefully human code review would only occur after several rounds of the agent refactoring its own one-shot slop into something that's up to near-human standards of surveyability and maintainability.
Did a bit of game dev in Odin last year and it was a wonderful experience. It's very much game dev oriented and comes batteries included with many useful libraries. And the built in vector stuff is very helpful there too.
OpenClaw meets this definition, but so does a 50 line Telegram wrapper around Claude Code / Codex ;)
https://github.com/a-n-d-a-i/ULTRON
Spoiler: it just pipes the msg into claude -p $msg or codex exec $msg
You can do anything if you believe
reply