I beg to differ. Let's say you're right. Code producers should turn to agriculture and let their managers and product owners prompt AI to produce code. How about code maintainers? Ever heard the mantra "You build it, you run it"? Lets say that AI can build it. Can it run it though? All alone, safely, securely and reliably? No. It can't. We can keep dreaming though, and when will AI code production services turn profitable? Is there a single one which turned profitable?
Agents are monitoring metrics and logs.
A bug is introduced into the system.
Error rates go up and the agents notify diagnostic agents.
These agents look at recent commits and figure out the problem.
They instruct another agent about how to fix the issue and deploy the change.
The problem is fixed before an engineer even has time to start looking at logs.
If you aren’t seeing this, you’re not keeping up with what others are already doing. It’s not just people vibe coding ToDo apps.
Calm down buddy, maybe you're confusing code producers with something else. It's 2026 we don't bother with maintenance no more, we /new to keep context clean and start over.
Just don't forget to comment - never delete - old code. Always keep dead code around to please shareholders, line numbers up always.
We produce code, that is the main thing, never forget.
One could argue we could achieve the same goals by appending \n to a file in a loop, but this is inefficient nowadays with generous token offerings (but could change in the future than I highly suggest just outputting \n to a file an call it productivity increase)
I didn't understand your point about product owners. Who the fuck would ever need one when code produces itself?
Because Microsoft, Google and Amazon, to name a few, sell the story of the cloud to decision makers who can sign a subscription contract. Developers go with the flow, not daring to question the setup. Meanwhile, they host their own servers on a r-pi and ship sideprojects. Devs are not at fault here. It’s the management.
Having been on both sides, nope, it's 100% the devs pushing for this. I've had innumerable discussions trying to convince developers to simplify things, but their reaction was basically "how can we go against best practice?! Unthinkable!". It was a huge uphill battle.
Meanwhile, management didn't have an opinion, it was up to the teams to architect things how they liked, and they liked sprawling microservice everything, because they wanted to own 100% of their code, any other concern be damned.
I found a way to cheat. The fire which is meant to force you doom scroll actually disappears if you scroll down then back up. This means that you can just chill out in the “easy area” and get your powerups and kills. Scrolling down (doomscrolling) is not mandatory.
Yeah, a relentlessly advancing deadly wall of fire becomes much less scary without the "relentless" part...
Another way of decreasing the difficulty is to enlarge the "playfield". I actually did that by chance, because my browser window is usually only half of my 4K monitor, so it's taller than wide. Because the monsters always start off at the bottom, you have much more time to shoot them.
With an iPhone, when you click on an input field, the on-screen keyboard pops up, and you can type right away.
On an android (latest samsung flagship), the keyboard shows up but is frozen for a second before you can type.
I feel this and I’m guessing iOS is a lot more closer to the hardware, while android runs on top of Java, so there is more to process. Maybe its just me.
This must be a glitch particular to Samsung phones. I use flagship Google Pixel phones and have NEVER witnessed such a lag. I tap on an input field with my left thumb, immediately the keyboard shows up, and I immediately smash any letter with my right thumb and it does register it. So, blame Samsung, not Android.
I am not too surprised though. Samsung has a reputation for bloating their Android stack with junk.
Yes, I’m used to this too. But lately on my 13 mini, there is a slight delay between the keyboard showing and it registering key presses. I would say it misses the first key press 60% of the time when the keyboard pops up…
The keyboard pops up, but is not responsive right away. This very thing happened today on my work phone (which has a bunch of MS defender/enterprise policies and apps managed by the company, forced background app updates etc, which could explain this) but I recall it also being a regular thing with all Samsung flagships I've had over the years. It's the feeling of a very slight delay (it could be a matter of as low as 200 ms) for important components which are operating-system controlled, such as the on-screen keyboard. It feels laggy, as if an app or a background process impacts the responsiveness of low level OS features.
On iOS, this was never something I had to experience. Slow apps are killed, iOS is brutal in this regard, but it protects the core OS-level components such as the keyboard. Try it out, load a few apps and try switching between them, where one of them had the keyboard uplled up. This is something regular users will likely never feel, but if you've been around since amiga 500, you'll definitelly feel it.
People really aren't going to like this, but OP is directionally correct.
At 100 dev shop size you're likely to have plenty of junior and middling devs, for whom tools like CC will act as a net negative in the short-mid term (mostly by slowing down your top devs who have to shovel the shit that CC pushes out at pace and that junior/mids can't or don't catch). Your top devs (likely somewhere around 1/5 of your workforce) will deliver 80% of the benefit of something like CC.
We're not hiring junior or even early-mid devs since around Mar/Apr. These days they cost $200/mo + $X in API spend. There's a shift in the mind-work of how "dev" is being approached. It's.. alarming, but it's happening.
reply