but it is possible that they have ideas that they want to share broadly "in this wave" whatever that means
Shit Punk Says
Oceans of Wisdom
19,158
matching drops
#1459158
2026-09-22 15:17
and I think it is useful that people can read our chat
which is that this is a useful build in public wave
well we should check a real use case here
so how can we use subwaves here @[simo] so we can have our chat here but others can also chat?
but in any case, we cannot let the unmerged PRs list grow and grow :)
in parallel, we should prepare for allowing the bots to merge and deploy to staging
in the immediate term it should be:
- merge and deploy all the easy/medium ones
- take a very hard, deep, full team look at the 2 FE x 2 BE ones that change IPFS/Arweave handling and wallet/security handling. these need your brains engaged!
whats next steps? I grind thru PR's fine, but is there some vague play how to go?
something like this is the world we are going to
so one ship with 25 people can carry across the world what used to take 2,000,000 horses and the associated riders etc
which is like 2M horse-loads
150,000 tons on the ship
they are absurdly efficient
a large container ship runs with 25-30 crew members
we are not going to be doing manual coding, 1 human per PR at a time, any more than we use camel trains, donkeys and horses to transport goods around the world and instead use container ships
but anyway it is a 1-way street
this will take a bit more work
what is it that you are supposed to be doing
how you see your role
so the issue is just identity
and accelerate from here
in our effectiveness and I think this is only going to continue
so I have done the work, taken the pain of how the tooling can support a step up
I laugh and say "wait, don't you realize that this is how all you are too?" :)
so when I see the dev teams get all worked up when 2-3-4 agents go and do conflicting things
I already have to deal with "coordination problems" and "competence problems" and "communication problems" and "people not doing what I thought I told them to do problems"
I already cannot "do all the work myself" or "check all the work myself"
I have to manage not 10, not 20, but thousands of humans already
I am obviously a worse software developer than anyone on either team, but I am simultaneously a vastly better manager than any developer on either team
because I have gone through cycle of psychological identity change with the other team, I have a sense of how it will play out
I do think the largest mental leap for @[simo] @[GelatoGenesis] @[prxt0] @[ragne] is a change in "identity"
you cannot think of yourselves of a software developer any more. that job is anyway RIP. the job of engineering manager however is alive and well and very valuable.
You have all been promoted to be in charge of a team! so you need to think "we each have 10 people reporting to us, how do we manage them"
and implement them in a mix of tools, scripts, bots, reports, management practices and so on
so we will steal / copy the systems of large human engineering organizations
is that you personally review each PR? probably not!
so if you are the CTO of Microsoft, how to you keep the 20,000 people pushing to the Windows monorepo effective?
There are companies that have had 30 developers and 300 developers and 3000 developers and in some cases even 30,000 developers for decades now
Fortunately , we do not need to invent this from scratch
- we did a nextgen and raise $10M to accelerate development
- we hired 30 developers to help you
- how do you make them effective - it certainly is not "you are going to sit with each one of them and work with them on each PR" because if you do that we will have the same outcomes as if we have 4 developers, in fact, worse outcomes
your mental model conceptually is something like this
yes and with increasingly powerful tooling to make this process better
and then if everything is finished i assume we ourself decide if this concrete development goes to "ready for prod, low risk release branch" or some other release branch?
so there needs to be regularly schedueld deployment bus service
but also annoying AF for humans to be waiting hours for a staging deployment
it is very linear time and token inefficient to keep the bots waiting around for hours/days for their deployments to go in
regardless of how many PRs are merged
so that there is some deterministic amount of time before the deployments get into staging
1/ you deploy one at a time but with some rule like
2/ every 15 minutes you just bundle everything and deploy it
and then you run into other problems where the PRs outrun the staging deployments and you get an infinite queue, so you need to build a mixed formula that is something like this
yes you need queue mgmt
i think the only way how it could work currently is not by every pr pipeline activating staging redeploy by itself. this could be a redeploy conflict hell by running 10 builds in parallel against the same target with different versions. i think the automation just merges to staging and then some cron job checks every five minutes if there are new commits in staging and if there are then redeploys and the dev pipeline just checks if its development is in staging by comparing what is in staging hash to its head hash. and as soon as it discover its deployed, it runs its tests and reports..
maybe something like that
at GPT 5.5 xhigh class (and soon I guess we are getting better), the net effect of this approach (with the proper workflows and practices) is an extremely material increase in overall system productivity
there is no free lunch in life. you can't say "I am going to 3x our cadence but everyone is going to work the same amount of work" - somethign has to change, "someone" has to work more, so you can decide to let the bots grind it out, even if it is less efficient per bot/thread than a human doing it, it is ok because it is not a human doing it