A good chunk of what my company has been doing with AI falls into either burning down our known tech-debt and "easy wins" that no one ever had the bandwidth to approach... And improving / automating our processes. The former is having a direct and meaningful impact on the quality and availability of our services.

Our QA, formerly a fairly frequent blocker of all our releases, are doing more in-depth reviews and catching issues earlier in our release process. They have become unblocked to the point they are actively chasing down work that starts to slip.

We have cleaned up and tuned both our security alerts and operations logs and improved our tenant isolation in our service in a way that makes customer and formal audits SIGNIFICANTLY easier.

We're setting ourselves up for faster human development of the hard-things. Our development environment and infrastructure are faster, cleaner, more auditable processes, and cheaper overall to operate.

These fixes mostly don't show up in our product change logs, and definitely don't fall into "new features". It would largely be invisible to the outside world, but our costs are going down (though to be fair, not offsetting the spend on AI to date), internal productivity has improved, operational incidents are down, and customer satisfaction is up.

PS5 emulation has gone from barely working to running Dark Souls at 10+ FPS with virtually no graphical glitches… in 6 weeks. If you’re not familiar with normal emulator development time, this is… quite extraordinary. There have been insane progress on decompilations and many other things in the emulator space.

Everyone’s trying to figure out how to convert this speed to product features at scale, but enterprises are like container ships. Lots of might but slow to turn. The littler companies can actually take advantage of this and produce higher quality products at much faster speed. I think you’re expecting too much in the short term and too little in the long term. AI-native companies are gonna eat everyone’s lunch, once they figure out how to actually do it reliably.

Last year people were asking "if AI is so great then where are the new apps?". Then data for 2026 came out and now the IOS app store has a 84% percent year-over-year increase in new app submissions.

For the question where are the alternative OSes? Here is one that I've seen. There's probably more - https://www.reddit.com/r/ClaudeAI/comments/1wfpydl/i_asked_c...

For that other stuff you mentioned like the right click menu. Those huge corporate projects suffer more from layers of institutional dysfunction and will be very very slow to show any improvement. Their dysfunction can't be solved with just faster coding.

Using AI to build more features is easier than using AI to improve existing projects. People will gradually figure out how to do latter too, it'll just take longer.

Probably for the same reason that SV companies hiring thousands of developers struggled to improve their product much past the original product, that was built by a handful of people.

Scale in headcount was a tactic to get investment, then you had to find stuff for everyone to work on. Suddenly people have the time to engineer so hard that we get runtime JSON defined CSS rendering engines to produce the same buttons we've had since 1995, instead of just writing a stylesheet and html.

Code output velocity from AI threatens to be useful, except it's also prone to over-engineering and burning tokens on the unnecessary. It's learned from the best after all. My suspicion is there is a lot getting done, but it's just not that impactful to flagship products.

As others have noted, there is a lot of new work going into passion projects that would have never happened otherwise, and that is cool. But I wouldn't hold my breath for SV tech to become super pragmatic and effective.

> Why have we not seen an improvements in products? [..] Is everyone just running full speed in circles or something?

The simplest explanation is that they don't give a flying flamingo about what you or I consider "improvements to products".

This report is an example.

There are several changes that modify CI behaviour, where the article gives no corresponding quality measurement.

They replaced type aware custom lint rules with AST-only static analysis. They don't say anything about what those new rules detect, didn't do old-vs-new rule comparison. They switched the TypeScript check from tsc to tsgo. Again, they are very proud of the performance improvement, but don't seem to care about diagnostic equivalence. The list goes on. They don't even report pass/fail agreement between the old and the new CI. They have 4x more tests, but no idea whether this big test suite works any better than the smaller old one, or even whether it works at all.

I feel no one talks about this, and yet it is glaringly obvious. Are we even solving the right problem? No one cares. Push code. Number go up.

I feel like if anything LLMs have reduced coding/software to "throw as much as possible at the wall and see what sticks". It feels quite shortsighted and wasteful, especially considering that humanity needs to get better about how it produces and consumes energy. It's sort of bleak.

Think of it as a layered problem. If the bottom layer (CI) cannot keep up with the output of agents, then solving problems at a higher layer - like user experience checks - will be exponentially slower and less reliable. Kind of like how optimizing tight inner loops makes your whole program faster.

I was just discussing with my team that this exact thing maybe brings back to relevance the idea of "behaviour driven development" and I was reminded of this Cucumber/Gherkin lib & language that defines a kind of executable prose you can use to specify how the software should behave. It's an interpretable programming language but designed to be close to how a human might just write down their specs of what kind of actions and responses are expected from a software system.

The idea is to drive actual testing from this, but in this era, I think it's interesting as a way to use AI to generate tests, and to cross-check those tests with the natural language descriptions, in a bit of a cycle that helps refine the highest level definition of the software.

Once that's nailed down, the implementation is just details.. normal engineering concerns like maintainability etc notwithstanding of course, but you can trust more and more the AI agents to get it right. The design specs being natural enough for humans to deal with but interpretable/specific enough to actually generate tests is pretty interesting for the bottleneck you are talking about, I think.

Clearly you have to replace obsolete human testers with agentic AI testers, duh.

At some point, with all this velocity, human users become the bottleneck, unable to keep up with and learn all the changes and new features. Luckily, there's a simple solution: just replace the human users with agentic AI users.

> If you even review PRs still: when was the last time you didn't just skip over tests?

The opposite. Reviewing PRs is now about just reviewing the tests, as the code is very likely to be fine if tests are relevant and they're passing.

The main enabler of agentic coding is heavy end-to-end/characterisation testing.

We can ask AI to do very large-scale refactors, for example, because if tests pass, it's 99% that everything is fine.

I was (luckily) not reviewing PRs even before AI.

It's a practice, it's not the best practice. It depends on the team/org/codebase/feature/etc. It always costs time and money and effort. Lots of it from multiple people.

You can get much better output by shifting that cost into hiring much better professionals, not better developers, but overall professionals.

The kind of people you can blindly trust that the software they are writing will be good, you don't need to get involved.

Of course there are exceptions. The author may actually want a review. Or the piece of code might be touching something extremely critical to the business but also easy to get hard.

But besides that? PRs are just productivity porn, or "we do engineering right because we follow Twitter" porn.

The best performing teams I had you hired individuals that removed work and responsibilities off your shoulders without you ever having to regret it. Never added it.

I laugh off engineers that "no you have to review, because it spreads information, enhances quality" and yada yada yada, while in the real world way more critical decisions are made by a single individual without requiring somebody reviewing their work.

I actually look at the tests first. But for this to work, you have to have good hygiene. If the test makes sense, fails without the PR but passed with the PR, I'm almost happy.

Boss: full branch code coverage testing is the best way, make it so!

Boss: whoa, that's a lot more testing than we'd like to pay for, can you cut it down?

Probably half the generated tests in my app are for markdown files.

I wonder how much faster GitHub actions could be if they weren’t running on Azure. Because Azure is either slow or very expensive.

I wonder why larger companies don't use self hosted github runners. You can buy a pretty beefy machine (TB of RAM, 256 cores, fast NVMe disk) and tests will run faster than on any hosted platform. Plus you don't have to shard as aggressively because more fits into one machine, benefit of shared page cache, shared persistent disk, can easily preserve working directory (for example my pnpm install takes 0 seconds, because the node_modules folder is already present from the previous run).

My company did this a couple of years ago to some machines we host ourselves. It is a bit of trouble to set up but it is not that bad and can easily save a 1000+ dollars per month since GHA runners are very expensive.

It is that grey zone where it is kinda worth it to pay someone to do it, but also might not be worth it the headaches of managing that person and the infra (like what happens if they go on vacation). The improved speed is the thing that tilts the balance.

We switched our Actions workload to blacksmith.sh (not affiliated) and have been pretty happy with how fast and inexpensive they are. I wouldn't be surprised to see this trend continue.

Agree, and it's already happening. Mostly smaller orgs so far though, they can just swap the runner label and move on. Larger orgs are starting to look into it but it's slow, lots of red tape (security review, procurement, "we're already paying GitHub").

I’m conflicted about Linear’s progression. I dislike some of the features but on the whole they’ve managed to keep the software pleasant to use, it doesn’t feel to me that it is drifting towards Jira territory, rather, it feels like it is losing the carefully considered product design because now code is cheap to generate. I’m not worried about it turning into Jira but it has lost its soul. Still a great product.

All software becomes popular because it's not the old behemoth, but it's new, fast, and simple. All software then grows and grows until it becomes the new behemoth, and the circle of life begins anew.

How could it be different?

Linear is essentially a small subset of Jira.

It's liked and works because it's simpler and covers most of the needs of teams without huge need of defining their own processes.

But be in business long enough and you find out that appealing to small teams and small orgs that don't require flexible and custom process definition doesn't make enough money and doesn't grow you forever.

So they will keep eventually growing in features and flexibility till they cover the reason Jira is so successful: it is more powerful and adaptable.

I'm no fan of Jira, but I've tried and seen enough of these tools to understand why it has the success that it has.

This is even more clear when you go beyond software development and need processes for teams like sales, HR, legal, etc. Jira can fit all of them.

Linear? It's a joke.