With 1000 engineers and most PRs bein housekeeping we’re down to 10 prs per day per engineer. And as they said - this is engineers core job now. It’s a new kind of job.
Personally I can easily imagine one or two orders of magnitude more than that. They crossed the rubicon of not gating PRs on tests. In that land you can just roll out changes to production, a small subset of it, during code review to assess behavior. Or during key moments of coding.
I’ve been thinking a lot about this recently: what can we get if every change goes to production in 100ms, and what do we need to do to maintain stability?
> Most interesting thing about Scion is how quickly it was deployed
Yes . And also they optimized for orders of magnitude more throughput and less latency, and fixing errors after the merge. This is new - they see enough benefit in velocity that justifies merging bugs and dealing with it later.
And it reminds me of when git came out and Linus said that git being super fast locally created a qualitative change in engineers head - it became a new way of working back then.
> You’ve gone from extreme to another. From “it’s just a tool that be skillfully wielded” “to it’s an agent which do the task you gave it”.
I'm responding to your comment because I need your help in rephrasing my comment above to make my point more clear, because the way I wrote it obviously misled you.
No, I didn't say the extreme (what would the extreme even be?).
What I literally wrote down is what I said, which is that using anything (be it a tool that is not autonomous or a fully autonomous agent like a very smart, capable human being) requires skill.
Imagine you and I are working on a team project together. In majority of real-life situations I'm not just going to point at a writing with my fingers to you and from there you figure out what needs to get done and you would magically do it without any further feedback. That's not how anything remotely useful and productive in this world works.
What's more likely to happen is we have a conversation, figure out how to break the task down, together, how to coordinate, how to cooperate, and how to stitch our results back together to complete the job.
As you can see this requires skill at every point.
Hence, the point I was making is that the article is either clickbait or the author doesn't understand how the world works: anything remotely useful and productive in this world requires skill (be it the use of a dumb tool like a welding torch or cooperation, working with something as smart as a very capable autonomous agent or human being).
> because I need your help in rephrasing my comment above to make my point more clear
Sure. The bulk of your post reads as sharp criticism of “AI is a tool and needs requisite skills to operate”, promoting the idea that “AGents will do the thing for you”. Suddenly
the last paragraph landed with “both AI and tools need requisite skills to operate”. By the time I got to the last paragraph I already made up my mind about your message and the contrast between two positions was far too small to jolt my attention.
The key improvement you can make is to spell out juxtaposition earlier.
Reverse engineering your original argument, and with benefit of your second comment, the juxtaposition is that the skill of wielding a hammer and the skill of operating AI are on the opposite ends of control / cooperation spectrum. The distance is in fact so huge that using hammers at starting point is naive at best and clickbait at worstt.
This brings me to my second point. Both of your comments are emotionally charged with incredulity. This did not put me, or you, into the mode of curious thinking.
As to the substance. If we were to stick with the frame of control / cooperation I would take a position closer to yours. The author is not clueless, they are early in their “journey” from left to right. We all are early, meaning that no matter where you are there is someone else right of you.
However, I found that frame far too constrictive yand left it behind about a month ago. I’d be happy to elaborate if you’re still reading. :)
> This did not put me, or you, into the mode of curious thinking
Touche. Guilty as charged. I have been very frustrated with a lot of writing that seems to put forth "AI" as something all new on its own.
I cannot imagine why. To me, it's just cheaper labor and all the baggage that comes with that.
I have been hiring and working with outsourced talent for decades and the progression of "AI" has been eerily the same. Around 2000, quality of outsourced talent was poor with a few exceptions. They had a hard time producing a good product unless micromanaged. Their error rates were frustratingly high and it required a lot of late nights (for me) and back and forth.
Outsourced talent from the exact same cities and countries are now a night and day difference. It's like talking to a co-worker - the work quality is now on par but the price has gone up significantly too.
This transformation took about 26 years.
This is why to me, "AI" is just cheaper labor and all the baggage that comes with that. It's following the same trajectory, on an expedited basis.
We’re all grappling with a good mental model to navigate this new world.
Your model is outsourced labor, moving from micromanagement to co-worker.
My model is a genius intern, who needs tools to exceed me in some areas and lean on me in others.
The authors model is wielding a hammer and moving to a press.
The diversity is shaped by a dozen factors - we solve different problems or even types of problems, under different constraints, amount of time invested so far, past experience and so on.
We’re not taking face to face, so forgive me if I guess wrongly… I guess your frustration comes from trying to coax wide variety of behaviors into a single framework. I’d given up on that, so I just try to pay attention. To results people achieve to reset my expectations of what is possible. Naturally I’m heavily biased by my mental model, and it has to be that way or else I will go insane.
You might be thinking along the lines of the O-ring theory. Indeed long supply chains accumulate errors exponentially.
However the origins of theory explored the outcome of disastrous and irreparable outcome of space shuttle exploding, lives lost, and billion of dollars destroyed.
When LLM goes off the rails the cost is much lower, and retry is on the table. In fact our core competency shifted from writing code to creating environment where agents can retry cheaply and course correct based on feedback.
A modest increase in the number of turns it takes to reach decorehenve could make a difference between
Decoherence and reaching the a grounded checkpoint.
If failure is essentially guaranteed somewhere in that chain, success becomes impossible. You don't need to lose lives to have simply have a fruitless endeavor. And when we're talking about law, we're talking about more than a fruitless endeavor. Law also isn't software that can have tests crafted and fed back into the loop.
Since Feb 2026 I noticed among software engineers at
big tech there a huge dispersion of attitudes and outcomes, and it was widening at the time. Since about August the tide turned - my acquaintances are moving closer together.
A human has painful memories of past mistakes and knows which of their own thinking process needs to be double checked and which can be accepted on faith. An llm has no such memory, it can either verify every single word or none of them. And verification itself needs to be verified. So they have to stop somewhere.
This is why llm usually produce text that’s too shallow or too detailed.
When you ask the agent to double check something you gave it the missing piece - intuition about which part needs to be checked.
By way of differentiation, consider that a single GUI can seamlessly and visually manage agents across several machines, while TUI is likely to remain separate terminals. In the fullness of it I don’t want to think which machine is hosting which agentic conversation (or a group of related conversation). A diffrent UX paradigm.
I am looking for agent-world feature flags, but not in a post on source control. Feature flags belong to wider SDLC.
reply