In my case it's not the CI that's the bottleneck. It's the human testing side. Does it work, sure. But does it actually do the thing we want (and more importantly) does it do it in a way our customers will understand and actually like?
Some devs are, some aren't. I've seen some numbers and its more or less a 50/50 split. HN comments kind of confirm that anecdotally.
Engineers seem to fall within a spectrum between "building" (enjoy the task of designing and programming something) and "completing" (enjoy seeing a finished product). AI enthusiasm correlates neatly with that dimension.
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.
Which is a bit terrifying and removes the ‘engineering’ component of a critical part of the job, in exchange for slot machine / pray to ai gods…which comes with disconnect from the code, something I assume will adversely compound over time.
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.
QA is not automatable. QA is about finding the things that you didn't think of and so didn't write a test for it. That many people think qa is not important shows in the bad software we have.
> QA is about finding the things that you didn't think of and so didn't write a test for it
QA is about quality. That it has been increasingly used to mean "repetitive manual testing only" is part of the very trend you decry of qa being undervalued.
Fundamentally QA is about two groups of people collaborating in an adversarial process ("you build it we break it") to achieve a common goal: a better product. QA by definition requires a relationship of equals, or the process ceases to be adversarial and becomes useless ceremony. If you're not able to assemble two distinct groups of people, one person can wear both hats (ie you test your own software) but you'll have more blind spots.
How much of QA is done by a human or automated, is and has always been an implementation detail.
If you're in charge of QA, you're in charge not just of finding new problems, but preventing regressions as well. And you're responsible for embedding as much of that work into the devloop itself, so that builders can find and remediate problems earlier and with less pressure on your limited time. How do you achieve that? automation.
I started my career doing QA and 99% of what I was doing could be automated by an AI today. Today I still do QA on my own product- I just spend all my time on the remaining 1% and my product is better as a result.
Only is a bit too strong, but it was a lot of repetitive. There has long been a trend to try to automate it - I sat in sales pitches for automation tools in the 1990s, and we were already had long been writing scripts to automate a lot of testing. While the tools have got better, the only advance since the 1990s that I have heard of is automated unit tests (which were being developed then, but hadn't yet spread). We are slightly better at using the tools, but automation of testing is a very old idea.
Despite all that, it was understood if you want a high quality product you will be spending more than half of your development budget on testing.
I have long ago concluded that it is not possible to test my own code - and nobody else can test their own code either. I know how to test code - like you I started in QA - but I can't test my own. I have too many blind spots because I'm too close to how it works.
Yes the blind spots are a hard psychological barrier...
I actually think that for a lot of software, AI can really help with that blind spot, even beyond regressions, in ways that don't replace human testers but are complementary.
For starters, not all software is used directly by humans. A good chunk was already consumed by APIs, and now an even larger chunk will be consumed by AIs. In those cases, it's very possible that AIs will be better at QA than humans, even for original problem discovery. After all, they are the users.
Even for human-facing CLIs (the kind of software I develop these days), it's trivially easy for AIs to interact with the software, and in my experience the newer models are shockingly good at understanding the principles and conventions of CLI usability, at least in the Unix world. I routinely run CLI changes through a gauntlet of AI agents, and their feedback is genuinely good.
TLDR I think in these debates over how automatable QA really is, we often tend to forget that there is a lot of software out there, and not all software is tested the same way.
No. You can automate some parts of it, but there are a lot of parts that cannot be.
What you cannot automate are finding the "unknown unknowns". That is things you don't know to look for. I have yet to see a project where humans running the automated tested code cannot find large large number of bugs that slipped passed all the automated tests that already pass.
You absolutely automate every test you can. It is boring and tedious to run through a manual test plan. What you want is to tell the testers "find what is wrong with it" and let them figure where/how to look. The act of finding new ways to try things is a large part of what makes manual testers better than automated tests.
AI is very useful in review, I won't put anything up for PR until it passes AI review.
However AI is just a tool, it isn't magic. I still find a lot of things that AI missed when I review code.
AI can likely do a lot of QA work, but I still want a real human to test the code. At least code that humans are expected to use.
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.
> The forceful executive, Henry Ford II, and the leader of the automobile workers union, Walter Reuther, both saw many examples of advanced machinery operating at the plant. The words they exchanged brilliantly encapsulated the paradox of automation:
> Henry Ford II: Walter, how are you going to get those robots to pay your union dues?
> Walter Reuther: Henry, how are you going to get them to buy your cars?
If AI takes over the job market, they’ll have to. There won’t be enough humans with income to pay for things. The machines can crank out exponentially more code each day and maybe us silly humans can find something else to do with our time.
I think you're being sarcastic, but there is actual truth behind what you're saying.
Because every developer is now a slop cannon by default, by default users will experience churn and whiplash, and things will break all over the place. As you point out, this is bad. It's also impossible to fix without deploying agents on the QA side. Like it or hate it, agentic testing is inevitable to protect users from the churn and noise caused by the slop cannon. I don't think that replaces test engineers at all - if anything it makes the job more fun. If you've ever had to keep playwright tests in sync with the target manually, and kept the CI environment up to speed with toolchain changes, you know what I mean.
Whether the "slop cannon by default" situation could have been avoided in the first place, is another question... But we're here now and there's no going back. Might as well deal with it as best as we can.
to me the last part if the most important part. product management hasn't been automated at all, and is more important than ever. you can't just keep adding features to make a great product
Me and my co-founder are building something similar but it started out as a tool to help build Lovable style prototypes for your existing product. Think Product Managers building an idea without having to figure out how to install git, VS Code, 17 other tools and then try share a URL.
Initial talks with customers resonated more with the internal tooling idea though. It's flexible enough to support both.
We're earlier along than this product though so there's a fair few wrinkles in our product.
I am speaking to initial customers and from my initial pain at my day job it was going to be a way to be "Lovable for your existing product" . But it also seems like it might turn into "internal cloud to host dashboards non-technical people are making with Claude".
I'd love to talk to anyone that's in Product or Ops or Sales or Account Management or Customer Success who'd either like to make changes to their existing product without the need for a developer. Or maybe they have thrown something together with Claude and have no idea how to "get it into production".
I'm not sure his argument holds that foundational models will no longer function after the bubble pops. There's plenty of open weight models that are competitive which are more likely to exist in a world with abundant cheap GPUs.
In addition to what wrs said, it's true that the foundation models won't necessarily stop working after the bubble pops...but if new training isn't happening, then they're not getting updated.
Day 1, that's not going to matter much.
Day 30, it's barely going to be noticeable.
Day 365, you're going to be able to tell that you're using an outdated model—whether you're using it for general world-knowledge stuff, or for coding.
Day 1826 (ie, Year 5), they're going to still have some uses, but they'll be so out of date that they'll be actively detrimental in many areas.
>When the AI bubble bursts, there will be stellar bargains on GPUs…
>these standalone models can do amazing things
>The things these open source standalone models can do will only expand, and they will become a given for our computing applications.
I think of the “big” foundation models as the “fossil fuel” of AI. Once the bubble pops and we can’t afford to train any more of them, we’ll be distilling and remixing the ones we managed to make during this weird period where they were feasible.
Quaaludes are maybe a better analogy since the original, strong ones are mostly gone and the pills being manufactured today are significantly weaker. And their effect on Wall Street's decision making is pretty comparable to AI's
Based on my experience, even the models we have now are a huge benefit when properly used. And we probably have a decade or two of significant gains we can make just with harnesses, skills, heuristics, etc. even if no further progress were made on models.
I am speaking to initial customers and from my initial pain at my day job it was going to be a way to be "Lovable for your existing product" . But it also seems like it might turn into "internal cloud to host dashboards non-technical people are making with Claude".
I'd love to talk to anyone that's in Product or Ops or Sales or Account Management or Customer Success who'd either like to make changes to their existing product without the need for a developer. Or maybe they have thrown something together with Claude and have no idea how to "get it into production".
It's nowhere near advanced as boxes.dev but it's built on the premise of running on any cloud. Indeed I have it running on two different bare metal server providers and I'm about to add a third (Azure) as I'm using my day job as my first customer.
Can I grab your contact details and schedule a demo?
Yeah on the trial page - I tried to repeat the phrase numerous times (dev console correctly showing that it was registering properly) but it didn't interact any further in terms of showing a "Sign Up" or other modal dialog boxes.
Possibly the web socket timed out for the STT. I, erm, asked lovable to add some retry logic. If you get a chance could you refresh and try again? If it still doesn't work I'll try to repro and look at the code.
This was a great read. It reminds me slightly of the book Alchemy by Rory Sutherland. I used to play Warhammer (Fantasy, not 40k) so it was really nice to reminisce.
reply