Unfortunately, this is one of those HN submissions where people are just knee-jerking to the title without even checking what the submission is. Of course, it doesn't help that it's a long video conference presentation with a "handout" that's beautiful but a little hard to read through on its own.
However, for those that are actually curious, the submission is not itself a cynical or dismissive take. The question in the title is interrogative and contextual, not rhetorical and universal, and the presentation tries to break down some of the bottlenecks and challenges that are leading to AI integration having a different impact on software engineering output than some people might expect.
Rather than suggesting those bottlenecks/challenges are universal or intractable, it just enumerates some of them and presents some survey analyses on how widely encountered they are.
It's actually pretty interesting and the kind of thing that engineers and those who work with them want to be reflecting on, so that they can better engineer their usage and processes around AI itself.
Thanks for the comment. As the author (but I didn't submit it to HN) I see in hindsight that the title should have been a little more informative rather than feeling so click-bait-ey.
My goal was not to imply that we're not shipping faster than we were prior to AI, as I think that's beyond debate at this point. What we investigated is why we're not shipping faster than we are today. If (high quality) code is being written at five times the rate it was before and we're shipping "only" twice as fast, then what's the reason for the difference? The talk shares results from studies that help improve our understanding of why.
This is something that Brooks had reflected on already in "The Mythical Man Month":
"One occasionally reads newspaper accounts of how two programmers in a remodeled garage have built an important program that surpasses the best efforts of large teams. And every programmer is prepared to believe such tales, for he knows that he could build any program much faster than the 1000 statements/year reported for industrial teams. Why then have not all industrial programming teams been replaced by dedicated garage duos? One must look at what is being produced."
Brooks argues that the coding that happened in the garage is only a fraction of what you need for the final product:
"It costs nine times as much. But it is the truly useful object, the intended product of most system programming efforts."
What we're seeing right now does not feel much different. You can greatly accelerate a first draft, a greenfield project, an experiment, or at least the initial iteration of one. Changing a live production system or a widely used library is an entirely different proposition.
People are running away with it in hilarious ways using all sorts of storyboarding, 3d environments, gameplay, etc etc.
I work in a highly regulated environment. My AI spend is ~$300/week and it has been tremendously helpful in troubleshooting incidents(!), increasing test coverage, gaining understanding of legacy/inherited code, applying fixes, etc. But shipping new features is something that impacts us in many many many ways and the uptake there has been quite slow.
Over the years many people built clones of things like Twitter, Dropbox, uuhh. Loads of things really. The core of Twitter is trivial, it's basically like my first PHP tools creating shoutboxes for websites.
Then the next challenge is scaling it to the world - and Twitter themselves struggled with that, the first years were full of fail whales, or stories of servers churning for ages whenever Justin Bieber made a tweet because (for some reason) they updated everyone's feeds even if they weren't actually online / looking at them.
But solving that also wasn't what made Twitter or Facebook popular, and no LLM will ever solve that because none of the successful software projects were successful because of code, code volume, development speed, number of people involved, or anything like that.
(That said I am convinced you can do the same amount of coding with less people at good enough quality, and said quality will improve over time as we've seen in the past ~2 years. The providers just need to add the software quality guardrails that we as software engineers learned over the years, and I'm sure there's dozens of companies working on just that)
That argues for immutability of production throughput, and yet most professional SWEs this days would be ashamed to deliver only 1000 statements/year of production code.
Clearly, acceleration is possible. So maybe we should move on to the conversation of what will make further acceleration possible, instead of arguing it only works for iteration one.
I am shipping so much more, but I don't know that our customers would necessarily know it. Total rewrites that needed to be done but were getting pushed off due to the scope are now getting done. Security issues are getting patched. Support ticket open to resolution time is dropping. So yes, shipping a lot faster to create a much better project rather than just focusing on features.
As we’ve seen happening in the open source projects with the piles of bugs being reported to them so much of what’s going on doesn’t seem to be new features, but just longstanding technical debt coming to the fore.
Maybe AI can’t write that new feature for us really fast. Maybe we asked. Maybe the code was complete garbage and it made it clear we really don’t want to keep piling on top of it and need to fix the issues we’ve known about for a long time. Adding new features at the old pace was a problem. We can’t handle the new.
Between that and the fact that some kinds of tech debt are much easier to pay off now that’s where a lot of our “new capacity” is going. Shoring things up.
> Total rewrites that needed to be done but were getting pushed off
I am doing this now with a massive internal app. Our internal customers see this as a drop-in performance because one of the senior team members, me, is not adding new features. But we are addressing a massive technical debt in about one-fifth the time it would've taken without the use of LLMs.
do those rewrites really need to be done still? what are you gaining?
In the old days we rewrote for a gain in productivity by humans or a gain in performance which resulted in non-trivial dollars. If AI is writing and testing the code, what benefits are you getting from the rewrite?
If it's actually fixing performance metrics in a way the user can feel or that hit the bottom line it's worthwhile. I'm a lot more suspicious when it is said that the user wouldn't notice them, though.
This is why what we as software developers would describe as quality or reliability improvements are so difficult to sell to people making the decisions about what to spend our time with.
And worse, they're right - developing a feature can increase baseline profits more and faster than rewriting some old code can. The effects of software quality and the like are long-term.
But I can almost guarantee that all the unicorn companies we've seen in the past decades, the now trillion dollar companies, didn't become that because of code quality or diligence.
Since AI has gotten good, I've also done some of the rewrites to fix the past lack of budget/planning, hubris or sometimes devs who didn't know any better.
Oh, they will lead to more profits. Some bad human-made architecture decisions were tying us down trying to keep our product stable instead of being able to focus on what would drive new customer growth.
I would guess, uncharitably, you would surmise your downvoters are just navel-gazing engineers who, given their druthers, would endlessly polish some irrelevant bauble rather than ship something genuinely useful to customers. But good products can only extend so far from their foundations.
The core Dropbox idea was clearly good. But in order for it to really be a multi-billion dollar business it needed a platform that would support lots of users. Postgres: a pretty good idea. But it needs an underlying OS that provides things like processes and storage. iPhone: cool idea, made possible entirely by hard won engineering gains in processing efficiency, battery tech, touchscreen tech, cellular network buildout, etc etc.
Not literally everything can be product/profit thinking. There is a lot of engineering work underlying great products that yielded tremendous profits.
One dynamic that AI coding has introduced is that features grow and are more "complete" or "complex" after their first development iteration compared to coding pre-AI. An example of this is that I recently built a web crawler for an internal documentation site at my company. My design for scraping, parsing, vectorizing and indexing the data was far more complex/complete than if I had not used AI. This is primarily due to my lack of knowledge in the space and general time constraints for the project.
That increased complexity, while less costly than before, still added time/cost to the project in terms of cognitive load and testing that otherwise wouldn't have been there had the design been "dumber". This notion of increased design complexity could be thought of as a form of Parkinson's Law where the complexity of the design grows to fill the time available.
I think AI is certainly making us write code faster but how much time is really being freed up now that writing code is cheaper? I get the impression that we are often just finding other things to fill that freed up time with, increased design complexity being one of those things.
Yeah, what it produces - if you let it - can be a bit overcomplete. I find it doesn't tend to do this too much if you focus on small, incremental features instead of the bigger tasks or complete applications.
Sometimes it's handy though - the other day I had it built a map tool (show travel times as a gradient on the roads from a certain starting point), not only did it do that exactly as I imagined, it also added features for automatically finding the perfect starting point, varying traffic speeds (using bus / taxi lanes - it was for emergency services), loads of things I didn't specify but were all convenient given the context.
But for an employer / enterprise I really wouldn't
What’s the diff between “increased design complexity” and “increased capability” for a given project?
AKA idk if anyone expected time to be freed up, vs just doing more in the same amount of time… feelsa bit like the Keynesian shorter-work-week prediction
More tickets and larger tickets, full migrations that used to take 4 weeks coordinating with 3 teams are now a single PR done in a day.
edit: if you're seeing a slow down in PRs, it's more likely that 10 of your 10x'ers are slinging code in 3-4 plus accounts in codex on the side during their shift on 8 startups.
In the past splitting diffs was an important process to speed up and simplify code review.
But now I would rather make one PR per service to simplify CI and deploy. As a result PRs become much much larger.
Exactly, big PRs are where review turns into skimming. I thought that since agents raise most of the PRs now, they should attach the full change context with reference paths. Then a review agent with full project memory can flag anything off on it, also give a short summary to reviewer as well so reviewer only has to review the summary and decide the approval.
If you're still writing migrations you're still not on the edge and are missing out on some good gains. We got rid of our database and now just get the LLM to manage markdown files containing all our customer PII etc. Our delivery speed has quadrupled this last week alone
I’m not sure I’ve really seen it within the community of programmers. It was certainly more there early on when the models were much worse, but I’ve seen it fading.
I have seen it among “the general public“. I’ve seen normal people complain about things in open-source projects or other contexts where to whatever degree they accepted programming took time before now they think it’s all just a magic wand with Claude, no matter the level of complexity.
I haven’t heard a single person at my company in management at any layer complain that we’re not working fast enough now that we have AI. One of my friends has 100% told me their management is pulling that. The management over there is on the everyone should do four times as many tickets, and use at least X amount of tokens per day. otherwise you’re slacking off train.
That’s not the case at my company at all. It’s available to use but they’re not forcing it or firing people who aren’t using it. It’s just a tool we can use.
If you follow various data sources like the StackOverflow developer survey or DORA from 2023 onwards, by this theory about 77% - 90% have been fired or pushed out of the industry.
What do you mean software development was arduous? It was pretty chill. You will start working on something, start crafting code carefully with time to review, optimize, etc.
Now it feels like everyone is in a rush and there is no time for crafting anything. Just vibe code a pile of shit that looks good but it's unnecessarily complex.
You are going to see how arduous software development is in a few years when no one understands the systems they have built
> I think people already have forgotten how long and arduous software development was just a few years ago.
Was it? Behind any arduous development process, I'm ready to bet there's a very inefficient communication channel that has nothing to do with code or any technical matters, but still impact productivity. Think how hard it is to get a Definition of Done alongside the Change Request even in the business jargon.
> The biggest bottleneck now is CI/CD/Experimentation with respect to engineering, and product alignment with respect to the business.
It's like building crooked houses, then saying that the biggest bottleneck is inspection. Do a 5 why[0] around the "bottleneck" and the answer is likely not there at all
> I'm ready to bet there's a very inefficient communication channel that has nothing to do with code
That is what I'm saying though. Shipping to production is mostly bottlenecked by product/business leaders who haven't described a clear vision/communication of what is wanted.
I've been a SWE for far longer pre coding-agents than post. The actual development of software was arduous. So much of tech was/is a long list of heavily scoped down tasks that eng takes an order of magnitude longer than today.
A quirk of coding agents is how they assess timelines. Ask it to scope a project you want done and it will answer in engineer days from pre-ai days. In actuality it can be done with a prompt and a few hours in claude
> So much of tech was/is a long list of heavily scoped down tasks that eng takes an order of magnitude longer than today.
I disagree. Based on my personal experience, a lot of time is spent on fine tuning code and double checking the docs. The first pass can be very quick especially if you already have sample code (from the docs or other parts of the project). But when it came to fine tune, that's where the other 90% of the time is going.
A lot of daily activities of engineering is massaging code, either from bug reports or requests after someone tested the features. And a lot of time is spent gathering details, comparing it with what already built, and then apply correction.
From what I've seen with people doing agentic coding, that feedback loop in the development phase is very superficial. Then the most important feedback loop (the one with the user) is distorted as the software is constantly changing.
Not everyone has the process and positioning needed to take advantage of AI, so it’s not surprising that some people swear it doesn’t help. But those people need to understand that other people do have the process and positioning and AI is dramatically changing things.
Personally, we’re just beginning to ship faster because we’re a big ship and turn slowly. We’re still getting up to speed but we’re also bogged down with bug fixes, security fixes, and the review bottleneck. Reviews are especially tough now that every commit is much larger because it is now much more correct than the crap we were submitting before AI.
Also, many people are simply lying and hate AI. There are people I’ve encountered who look for any evidence to justify not embracing it. It’s frankly tiring but I understand some people cannot handle change and are frankly terrified of what is happening to their careers and their concept of self-worth.
The excitement of LLMs has been around the productivity of the engineers, not the quality of the projects. Traditionally, we have bottlenecks at review and QA stages for new work, and a lot of orgs turn on the firehose of new code without fixing those bottlenecks.
If you want to drive at high speed, you need to build a highway first.
these models with passable agent performance have been around for a year now. how many months of days is that? are you saying you're getting an entire year's worth of programming done every 12 days? more than two years' worth a month? over 12 months thats more than 24 years, practically an entire career.
Do you think you've achieved that output of your entire career before ai this year?
For me at the current moment in time its more like 2 days of work turned to one day, give or take. And I'm not that good of a programmer.
I think so! From my point of view I don't think that these models have been passable for around a year now. Seems to me that opus 5.5 and fable 5.2 are really ramping things up.
Especially on the vision side of things, and being able to be steered in a direction I'm finally happy with.
Give you a few examples:
- Couple of projects at work that where shelved due to being too long, have been merged in a few weeks.
- I generated a whole icon pack in a weekend using fable 5.2 (haven't been able to make this with any other model)
- On the personal side, I build a few smart devices (PCB included and housing printing) in a few days. Something that would have taken me who knows what long!
- I have agents roaming the app findings ~20 visual quirks at work per day. I used to take a whole day to patch between 5-10.
Obviously for some projects things don't change and it's still 1:1 speed, but other 1:100 even..!
Don't simply answer the question from the title -- you won't be addressing the substance of the presentation or really any other substantive issue.
Either watch the presentation if you want to spare the time (a big ask even at 2x speed) or move on.
The presentation is about the results from an actual investigation on why a particular group only saw modest improvements in shipping. It will probably be more relevant to groups more like the group studied (a large dev org) than others.
The general idea is that there is a process pipeline between code change and shipping, and LLMs don't necessarily speed up all the steps at the same rate, especially in large, mature products.
I'm shipping much more when I don't care about code quality. I've built a bunch of fun, greenfield side projects. And prototyping at work is also much faster. But when it really comes down to the details, conversations with colleagues, and really delving into what we want to build, designingthe userexperience, getting the details right, still take time.
I liked the segment about productivity-pressure paradox. I think there is definitely resistance to change from a wanting-ness perspective, but there is also an element of burnout to this stuff.
In my own dumb corporate job, I haven't had a single enablement session of memory in the last 8-12 months that didn't incorporate AI. It's burnout. It's what's relevant to my actual productivity versus what's relevant to a company's goals and model buying justification.
We are shipping faster. Shipping speed depends on a variety of factors. That said, the ability to generate and validate designs, code, tests, data, performance and security evals, etc is increasing the speed of delivery for many organizations - I'm a consultant and I see it every day.
I also see companies that don't know what they want to build, suffer from toxic culture etc -- they are not faster because their core problems never had much to do with software development.
Sure, there are plenty of developers clinging to the "old way" or using AI in ways that add complexity and slow things down but I don't see this as the dominant group.
I'm shipping new features to my SaaS customers sometimes as quickly as the same day they bring it up. These are usually fairly small, obviously. I actually posted this story on LinkedIn, as one does:
> Customer email, 9:42 am: "I have a partner asking for our SSH2 public key. I tried using Tediware help but eventually it said to contact support. Are you able to assist?"
> Response, 10:47 am: "You need to generate a key pair yourself and keep the private key. Tediware does not issue SSH keys. Here's what you do. [instructions follow]"
> Follow-up response, 12:20 pm: "Generating your own key pair is now part of the app."
> Time from support request to new feature designed, coded, tested, deployed and announced: 2 hours, 38 minutes.
Side note, this feature has been solid in prod ever since (that story is a couple of months old).
Obviously, some things take weeks still, but they're hard. I just finished writing an X12 translator/parser, from scratch, in Rust. The old translator/parser was written in Ruby and ran documents at 175 kb/s. The new one handles 1 MB/s. It took me seven weeks of on-again/off-again dev work, fuzzing, testing, etc. It went live in prod yesterday.
This last week, I was able to delete considerably more code than I would have been able to before LLM assistance.
Specifically, I was able to consolidate some CSS because I could ask Claude to calculate the cascade before and after and verify that nothing had changed about rendering.
I’m sure there was a way to do that before by scripting a headless browser, but I didn’t have to learn that tool to unlock this capability.
I'm sure the release cadence on browser updates has gone up; and thanks to all the CVEs getting found now, there's definitely real value from them, even if we simply wouldn't have known about all the risks if it were not for the same AI solving them.
For entertainment, it's definitely been huge for gaming. In Roblox the majority of games now are AI generated. Of the top 100 games, 80 used AI in some way or another and there's 70,000 AI generated games total. Roblox has a huge number of players too (~380 MAU) so tons of people are playing AI generated games.
I think it would be more widespread if there wasn't as much pushback against AI. Big Walk disclosed they used ai to fix a bug and it immediately got review bombed. Kids on Roblox don't care as much, so you can see just how transformative it has been there.
The IGF really dropped a grenade into the discussion heh. What happened was IGF clarified that "using AI" includes using it for coding "help" and research, which Big Walk had disclosed. This does not align with Steam who doesn't require disclosure of those particular uses, and in general using it for programming has been arbitrarily deemed OK by players and the industry.
Personally I think Steam should either get rid of the label or expand it to any usage because the carve-outs are arbitrary and pervasively widespread in use - I don't find it believable House House's developers are still almost entirely coding by hand and only leaning on AI for the hardest problems lmao. The stigma isn't sustainable once full disclosure is normal, and then games can be judged simply on their merit either they're good or bad.
Failing that it's hard to imagine what IGF looks like next year because everything currently in development will be using AI in some fashion, either they're going to have no candidates or no honest ones.
> “Programming is a creative discipline whose labour deserves the same respect we extend to any part of making a game. This extends to the past work used to train these models without the creators’ consent.”
It feels to argue the point that ai doesn’t have visible outcomes you’d have to go down the path of the no true scotsmans fallacy pretty hard.
“Sure there’s a massive increase in the number of apps on the app stores, there’s new examples of decompiled and recompiled games popping up all the time not to mention all the vibe coded games, many companies are reporting they have new bespoke vibe coded tools to do some task they used to do manually, people are just cloning popular apps like photoshop with bespoke customisations to their needs..” etc.
I already know the tiresome response to any such example given by people of this mindset. “Yeah but those aren’t TRUE examples of users getting features faster!” Whatever.
Places where this gets stuck: IT services firms. I work for a software vendor that only sells through them, and most of them still bill by the day (at least in Europe).
For a service firm billing days, cutting the team in half because the shipping pace is the same would clearly breaks the business. So nobody there is in a hurry to measure outcomes, and the client’s procurement team compares day rates anyway. At least up to now.
We can build an app in minutes with Claude Code, Codex, Cursor but deployment of new apps still requires a human to sign-up, browse a dashboard, create API keys, enter a credit card, etc. This means for less technical users, deployment might not even happen.
I would want to see more cloud providers embracing fully-autonomous deployments for new users, I created this benchmark to track progress here: https://github.com/cloudishai/ai-deploy-bench
In order to ship faster, we need significant improvements in efficiency when it comes to reviewing code.
That may or may not include shipping without reviewing code. Something I think is a real option to consider as LLMs and agents become more capable.
The reality is, any point where a human is involved is now a bottleneck. Even when that human is using an agent to write code. This will apply to the review process as well.
It feels this way, doesn't it? At least until we focus on something besides pure efficiency.
I'm shipping faster, but not as fast if the output was the same as before. AI allows for deeper code, all the nice to haves you wouldn't normally do. Test coverage is now fully complete as well, and I mean full tilt mocks and every edge case, not just the happy path plus bugs found in testing.
I'm a one-man operation with an equities markets analysis product. I'm definitely shipping faster. Fixing bugs and adding features literally 100x faster as well as implementing some very complex math that I likely could not have done on my own previously.
Most if the issue I’ve faced working on production software in team environment is to be able to defend you PR and story the changes and understand it to a level to be able to defend it. For PoCs and demos it can accelerate a lot but not for many other use cases.
We need better systems and frameworks for composing 1 person made and owned systems into multi person systems. To be able to trace and manage and reason about the properties kf the side effects as needed
I am writing code 5-10x faster and I can feel it go, but I'm still waiting 2 days for the IT to install something on my useless locked down laptop, still waiting a week for a trivial corporate firewall change, still waiting 2-3 weeks for business to make up their minds about whatever the hell they want to sell now. So I am shipping faster, but actually not.
Yeah, our CI/CD pipeline is still a dumpster fire. Management refuses to use AI even though it would help them more than us. Our build team hasn’t really used it to improve our build times.
The trillions-dollars question is how come software itself doesn't get improved by (at least) an order of magnitude, if not more.
More to the point, the price of RAM that has gone berserk. Easy solution, let's then make our OSes, browsers and almost all the relevant software that we use day to day an order a magnitude more nimble, for example if a Chrome instance now eats 1-2GB of memory then make it eat at most 100-200MBs of said memory while doing the exact same things (if not more). The much lauded AI revolution in code-writing hasn't created that, not sure if it will ever do, it will just add slop after slop after slop, in fact it wouldn't surprise me if the memory requirements for something like Chrome won't increase as a result of the recent vibe-coding mania.
But by this point the AI zealots are already running the asylum, so nothing to be done.
> The trillions-dollars question is how come software itself doesn't get improved by (at least) an order of magnitude, if not more.
The sad thing is those using AI to code (and I certainly do) don't realize they're producing more but just more of the same turds they were already producing.
And in addition to that they're producing turds nobody gives a shit about (ah!).
Where, indeed, are the both less memory-hungry, less CPU-intensive and more secure rewrites of the pigs we work with on a daily basis?
Nowhere to be seen.
Because the AI zealots are way too busy adding crap features over crap features.
You can't go half-in with AI; need to go all-in. At 10:39, he's talking about how humans are reviewing the code. No. You cannot go half-in; have to go all-in and set up AI reviewers that match the best human code reviewer's heuristics. You cannot go half-in and have QA doing manual integration testing. You have to go all-in and AI driven, automated QA.
Speeding up delivery of code is forcing a lot of orgs to face a reckoning of inefficiency that they've built up over years that need to be fixed.
It wasn't until after factories were redesigned from the ground up to take advantage of electricity that the benefits of electrification were realized.
There's a persistent question in my circles: "what does it mean to be AI-native".
Your analogy here is apt because AI-native teams are the ones that are doing the impossible. I know 4 non-technical solo-founders (all had previously courted me pre-AI coding to be a technical co-founder) that are effectively shipping real products with no engineering team. One has 4 large universities signed.
These guys are all-in on AI because they could not exist without it; by necessity every leg of what they do is AI.
Unfortunately, this is one of those HN submissions where people are just knee-jerking to the title without even checking what the submission is. Of course, it doesn't help that it's a long video conference presentation with a "handout" that's beautiful but a little hard to read through on its own.
However, for those that are actually curious, the submission is not itself a cynical or dismissive take. The question in the title is interrogative and contextual, not rhetorical and universal, and the presentation tries to break down some of the bottlenecks and challenges that are leading to AI integration having a different impact on software engineering output than some people might expect.
Rather than suggesting those bottlenecks/challenges are universal or intractable, it just enumerates some of them and presents some survey analyses on how widely encountered they are.
It's actually pretty interesting and the kind of thing that engineers and those who work with them want to be reflecting on, so that they can better engineer their usage and processes around AI itself.
Thanks for the comment. As the author (but I didn't submit it to HN) I see in hindsight that the title should have been a little more informative rather than feeling so click-bait-ey.
My goal was not to imply that we're not shipping faster than we were prior to AI, as I think that's beyond debate at this point. What we investigated is why we're not shipping faster than we are today. If (high quality) code is being written at five times the rate it was before and we're shipping "only" twice as fast, then what's the reason for the difference? The talk shares results from studies that help improve our understanding of why.
Thank you for the good talk and research results!
What are some verification methods that you would share for a future talk?
[dead]
Let's swap in the subtitle instead. It's blander, so it might be harder to react reflexively* to.
(* https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...)
lol that's why I couldn't find the post again
This is something that Brooks had reflected on already in "The Mythical Man Month":
"One occasionally reads newspaper accounts of how two programmers in a remodeled garage have built an important program that surpasses the best efforts of large teams. And every programmer is prepared to believe such tales, for he knows that he could build any program much faster than the 1000 statements/year reported for industrial teams. Why then have not all industrial programming teams been replaced by dedicated garage duos? One must look at what is being produced."
Brooks argues that the coding that happened in the garage is only a fraction of what you need for the final product:
"It costs nine times as much. But it is the truly useful object, the intended product of most system programming efforts."
What we're seeing right now does not feel much different. You can greatly accelerate a first draft, a greenfield project, an experiment, or at least the initial iteration of one. Changing a live production system or a widely used library is an entirely different proposition.
This is my thinking as well.
Low risk work is tremendously accelerated. Just look at the memes that people re building. One of my favorite right now are derivations of this thing: https://x.com/jamesonhodge/status/2118733265372860826
People are running away with it in hilarious ways using all sorts of storyboarding, 3d environments, gameplay, etc etc.
I work in a highly regulated environment. My AI spend is ~$300/week and it has been tremendously helpful in troubleshooting incidents(!), increasing test coverage, gaining understanding of legacy/inherited code, applying fixes, etc. But shipping new features is something that impacts us in many many many ways and the uptake there has been quite slow.
If anybody is interested in trying the app from the tweet:
https://chimera-vocal-synth.vercel.app/
Thanks for the share, I love it.
Over the years many people built clones of things like Twitter, Dropbox, uuhh. Loads of things really. The core of Twitter is trivial, it's basically like my first PHP tools creating shoutboxes for websites.
Then the next challenge is scaling it to the world - and Twitter themselves struggled with that, the first years were full of fail whales, or stories of servers churning for ages whenever Justin Bieber made a tweet because (for some reason) they updated everyone's feeds even if they weren't actually online / looking at them.
But solving that also wasn't what made Twitter or Facebook popular, and no LLM will ever solve that because none of the successful software projects were successful because of code, code volume, development speed, number of people involved, or anything like that.
(That said I am convinced you can do the same amount of coding with less people at good enough quality, and said quality will improve over time as we've seen in the past ~2 years. The providers just need to add the software quality guardrails that we as software engineers learned over the years, and I'm sure there's dozens of companies working on just that)
That argues for immutability of production throughput, and yet most professional SWEs this days would be ashamed to deliver only 1000 statements/year of production code.
Clearly, acceleration is possible. So maybe we should move on to the conversation of what will make further acceleration possible, instead of arguing it only works for iteration one.
[dead]
Yup the test is not playing chess or dota or math proofs. Run a bank or the power grid. Then you pass.
I am shipping so much more, but I don't know that our customers would necessarily know it. Total rewrites that needed to be done but were getting pushed off due to the scope are now getting done. Security issues are getting patched. Support ticket open to resolution time is dropping. So yes, shipping a lot faster to create a much better project rather than just focusing on features.
That’s my immediate thought.
As we’ve seen happening in the open source projects with the piles of bugs being reported to them so much of what’s going on doesn’t seem to be new features, but just longstanding technical debt coming to the fore.
Maybe AI can’t write that new feature for us really fast. Maybe we asked. Maybe the code was complete garbage and it made it clear we really don’t want to keep piling on top of it and need to fix the issues we’ve known about for a long time. Adding new features at the old pace was a problem. We can’t handle the new.
Between that and the fact that some kinds of tech debt are much easier to pay off now that’s where a lot of our “new capacity” is going. Shoring things up.
> Total rewrites that needed to be done but were getting pushed off
I am doing this now with a massive internal app. Our internal customers see this as a drop-in performance because one of the senior team members, me, is not adding new features. But we are addressing a massive technical debt in about one-fifth the time it would've taken without the use of LLMs.
do those rewrites really need to be done still? what are you gaining?
In the old days we rewrote for a gain in productivity by humans or a gain in performance which resulted in non-trivial dollars. If AI is writing and testing the code, what benefits are you getting from the rewrite?
> what are you gaining
Fixing performance bottlenecks caused by bad architecture. Fixing bad architecture so that we can ship even faster in the future.
If it's actually fixing performance metrics in a way the user can feel or that hit the bottom line it's worthwhile. I'm a lot more suspicious when it is said that the user wouldn't notice them, though.
If they aren't leading to more profits then you're tilting at windmills here.
This is why what we as software developers would describe as quality or reliability improvements are so difficult to sell to people making the decisions about what to spend our time with.
And worse, they're right - developing a feature can increase baseline profits more and faster than rewriting some old code can. The effects of software quality and the like are long-term.
But I can almost guarantee that all the unicorn companies we've seen in the past decades, the now trillion dollar companies, didn't become that because of code quality or diligence.
I've seen outages caused by bad architecture.
Since AI has gotten good, I've also done some of the rewrites to fix the past lack of budget/planning, hubris or sometimes devs who didn't know any better.
Oh, they will lead to more profits. Some bad human-made architecture decisions were tying us down trying to keep our product stable instead of being able to focus on what would drive new customer growth.
I would guess, uncharitably, you would surmise your downvoters are just navel-gazing engineers who, given their druthers, would endlessly polish some irrelevant bauble rather than ship something genuinely useful to customers. But good products can only extend so far from their foundations.
The core Dropbox idea was clearly good. But in order for it to really be a multi-billion dollar business it needed a platform that would support lots of users. Postgres: a pretty good idea. But it needs an underlying OS that provides things like processes and storage. iPhone: cool idea, made possible entirely by hard won engineering gains in processing efficiency, battery tech, touchscreen tech, cellular network buildout, etc etc.
Not literally everything can be product/profit thinking. There is a lot of engineering work underlying great products that yielded tremendous profits.
If the rewrites needed to be done but they were getting pushed then maybe they didn't need to be done
One dynamic that AI coding has introduced is that features grow and are more "complete" or "complex" after their first development iteration compared to coding pre-AI. An example of this is that I recently built a web crawler for an internal documentation site at my company. My design for scraping, parsing, vectorizing and indexing the data was far more complex/complete than if I had not used AI. This is primarily due to my lack of knowledge in the space and general time constraints for the project.
That increased complexity, while less costly than before, still added time/cost to the project in terms of cognitive load and testing that otherwise wouldn't have been there had the design been "dumber". This notion of increased design complexity could be thought of as a form of Parkinson's Law where the complexity of the design grows to fill the time available.
I think AI is certainly making us write code faster but how much time is really being freed up now that writing code is cheaper? I get the impression that we are often just finding other things to fill that freed up time with, increased design complexity being one of those things.
Yeah, what it produces - if you let it - can be a bit overcomplete. I find it doesn't tend to do this too much if you focus on small, incremental features instead of the bigger tasks or complete applications.
Sometimes it's handy though - the other day I had it built a map tool (show travel times as a gradient on the roads from a certain starting point), not only did it do that exactly as I imagined, it also added features for automatically finding the perfect starting point, varying traffic speeds (using bus / taxi lanes - it was for emergency services), loads of things I didn't specify but were all convenient given the context.
But for an employer / enterprise I really wouldn't
What’s the diff between “increased design complexity” and “increased capability” for a given project?
AKA idk if anyone expected time to be freed up, vs just doing more in the same amount of time… feelsa bit like the Keynesian shorter-work-week prediction
[dead]
More tickets and larger tickets, full migrations that used to take 4 weeks coordinating with 3 teams are now a single PR done in a day.
edit: if you're seeing a slow down in PRs, it's more likely that 10 of your 10x'ers are slinging code in 3-4 plus accounts in codex on the side during their shift on 8 startups.
In the past splitting diffs was an important process to speed up and simplify code review. But now I would rather make one PR per service to simplify CI and deploy. As a result PRs become much much larger.
Exactly, big PRs are where review turns into skimming. I thought that since agents raise most of the PRs now, they should attach the full change context with reference paths. Then a review agent with full project memory can flag anything off on it, also give a short summary to reviewer as well so reviewer only has to review the summary and decide the approval.
I've been doing this too; it feels like a natural change due to the incentives changing.
Yeah, but you will not working on migration if there is no ai in the first place.
If you're still writing migrations you're still not on the edge and are missing out on some good gains. We got rid of our database and now just get the LLM to manage markdown files containing all our customer PII etc. Our delivery speed has quadrupled this last week alone
My online sarcasm detector has been thorough destroyed by the age of AI.
I feel like I'm going crazy with all the people questioning the impact of AI in software development.
I think people already have forgotten how long and arduous software development was just a few years ago.
The biggest bottleneck now is CI/CD/Experimentation with respect to engineering, and product alignment with respect to the business.
I’m not sure I’ve really seen it within the community of programmers. It was certainly more there early on when the models were much worse, but I’ve seen it fading.
I have seen it among “the general public“. I’ve seen normal people complain about things in open-source projects or other contexts where to whatever degree they accepted programming took time before now they think it’s all just a magic wand with Claude, no matter the level of complexity.
I haven’t heard a single person at my company in management at any layer complain that we’re not working fast enough now that we have AI. One of my friends has 100% told me their management is pulling that. The management over there is on the everyone should do four times as many tickets, and use at least X amount of tokens per day. otherwise you’re slacking off train.
It’s all in who you talk to.
I think it's an age thing as well.
Engineers that have only started full time work post 2023 haven't experienced the counterfactual of not having AI.
They see all the mundane business/eng bottlenecks that are pervasive now and don't truly know how much better it is now than before
I think a large part of it is that the programmers that aren’t using AI have already been fired or pushed out of the industry in other ways.
The programmers who are left is an artificial selection of AI boosters.
That’s not the case at my company at all. It’s available to use but they’re not forcing it or firing people who aren’t using it. It’s just a tool we can use.
If you follow various data sources like the StackOverflow developer survey or DORA from 2023 onwards, by this theory about 77% - 90% have been fired or pushed out of the industry.
What do you mean software development was arduous? It was pretty chill. You will start working on something, start crafting code carefully with time to review, optimize, etc.
Now it feels like everyone is in a rush and there is no time for crafting anything. Just vibe code a pile of shit that looks good but it's unnecessarily complex.
You are going to see how arduous software development is in a few years when no one understands the systems they have built
Same. If we had twice as many PMs as our current number (we have multiple open seats) we’d be easily able to do way more with the same eng team.
> I think people already have forgotten how long and arduous software development was just a few years ago.
Was it? Behind any arduous development process, I'm ready to bet there's a very inefficient communication channel that has nothing to do with code or any technical matters, but still impact productivity. Think how hard it is to get a Definition of Done alongside the Change Request even in the business jargon.
> The biggest bottleneck now is CI/CD/Experimentation with respect to engineering, and product alignment with respect to the business.
It's like building crooked houses, then saying that the biggest bottleneck is inspection. Do a 5 why[0] around the "bottleneck" and the answer is likely not there at all
[0] https://en.wikipedia.org/wiki/Five_whys
> I'm ready to bet there's a very inefficient communication channel that has nothing to do with code
That is what I'm saying though. Shipping to production is mostly bottlenecked by product/business leaders who haven't described a clear vision/communication of what is wanted.
I've been a SWE for far longer pre coding-agents than post. The actual development of software was arduous. So much of tech was/is a long list of heavily scoped down tasks that eng takes an order of magnitude longer than today.
A quirk of coding agents is how they assess timelines. Ask it to scope a project you want done and it will answer in engineer days from pre-ai days. In actuality it can be done with a prompt and a few hours in claude
> So much of tech was/is a long list of heavily scoped down tasks that eng takes an order of magnitude longer than today.
I disagree. Based on my personal experience, a lot of time is spent on fine tuning code and double checking the docs. The first pass can be very quick especially if you already have sample code (from the docs or other parts of the project). But when it came to fine tune, that's where the other 90% of the time is going.
A lot of daily activities of engineering is massaging code, either from bug reports or requests after someone tested the features. And a lot of time is spent gathering details, comparing it with what already built, and then apply correction.
From what I've seen with people doing agentic coding, that feedback loop in the development phase is very superficial. Then the most important feedback loop (the one with the user) is distorted as the software is constantly changing.
> "Ask it to scope a project you want done and it will answer in engineer days from pre-ai days."
As an aside, this is yet more evidence that LLMs are pattern prediction mechanisms rather than performing some kind of reasoning.
Not everyone has the process and positioning needed to take advantage of AI, so it’s not surprising that some people swear it doesn’t help. But those people need to understand that other people do have the process and positioning and AI is dramatically changing things.
Personally, we’re just beginning to ship faster because we’re a big ship and turn slowly. We’re still getting up to speed but we’re also bogged down with bug fixes, security fixes, and the review bottleneck. Reviews are especially tough now that every commit is much larger because it is now much more correct than the crap we were submitting before AI.
Also, many people are simply lying and hate AI. There are people I’ve encountered who look for any evidence to justify not embracing it. It’s frankly tiring but I understand some people cannot handle change and are frankly terrified of what is happening to their careers and their concept of self-worth.
The excitement of LLMs has been around the productivity of the engineers, not the quality of the projects. Traditionally, we have bottlenecks at review and QA stages for new work, and a lot of orgs turn on the firehose of new code without fixing those bottlenecks.
If you want to drive at high speed, you need to build a highway first.
What enables you to drive a car Really Fast™ are its brakes: https://manuel.kiessling.net/2011/04/07/why-developing-witho...
We are. A month of work turned into one day.
these models with passable agent performance have been around for a year now. how many months of days is that? are you saying you're getting an entire year's worth of programming done every 12 days? more than two years' worth a month? over 12 months thats more than 24 years, practically an entire career.
Do you think you've achieved that output of your entire career before ai this year?
For me at the current moment in time its more like 2 days of work turned to one day, give or take. And I'm not that good of a programmer.
I think so! From my point of view I don't think that these models have been passable for around a year now. Seems to me that opus 5.5 and fable 5.2 are really ramping things up.
Especially on the vision side of things, and being able to be steered in a direction I'm finally happy with.
Give you a few examples:
- Couple of projects at work that where shelved due to being too long, have been merged in a few weeks.
- I generated a whole icon pack in a weekend using fable 5.2 (haven't been able to make this with any other model)
- On the personal side, I build a few smart devices (PCB included and housing printing) in a few days. Something that would have taken me who knows what long!
- I have agents roaming the app findings ~20 visual quirks at work per day. I used to take a whole day to patch between 5-10.
Obviously for some projects things don't change and it's still 1:1 speed, but other 1:100 even..!
We are definitely shipping faster. Does that turn to better products? Not necessarily.
Don't simply answer the question from the title -- you won't be addressing the substance of the presentation or really any other substantive issue.
Either watch the presentation if you want to spare the time (a big ask even at 2x speed) or move on.
The presentation is about the results from an actual investigation on why a particular group only saw modest improvements in shipping. It will probably be more relevant to groups more like the group studied (a large dev org) than others.
The general idea is that there is a process pipeline between code change and shipping, and LLMs don't necessarily speed up all the steps at the same rate, especially in large, mature products.
We definitely see more broken features that was removed after a short amount of time.
I'm shipping much more when I don't care about code quality. I've built a bunch of fun, greenfield side projects. And prototyping at work is also much faster. But when it really comes down to the details, conversations with colleagues, and really delving into what we want to build, designingthe userexperience, getting the details right, still take time.
I liked the segment about productivity-pressure paradox. I think there is definitely resistance to change from a wanting-ness perspective, but there is also an element of burnout to this stuff.
In my own dumb corporate job, I haven't had a single enablement session of memory in the last 8-12 months that didn't incorporate AI. It's burnout. It's what's relevant to my actual productivity versus what's relevant to a company's goals and model buying justification.
Interesting thought to ponder.
We are shipping faster. Shipping speed depends on a variety of factors. That said, the ability to generate and validate designs, code, tests, data, performance and security evals, etc is increasing the speed of delivery for many organizations - I'm a consultant and I see it every day.
I also see companies that don't know what they want to build, suffer from toxic culture etc -- they are not faster because their core problems never had much to do with software development.
Sure, there are plenty of developers clinging to the "old way" or using AI in ways that add complexity and slow things down but I don't see this as the dominant group.
Aren’t we?
Remembering that LOC and commits don't count, what metrics or even personal experience show that users are getting more features faster?
At least in entertainment I only see cancelled products rapidly increasing.
I'm shipping new features to my SaaS customers sometimes as quickly as the same day they bring it up. These are usually fairly small, obviously. I actually posted this story on LinkedIn, as one does:
> Customer email, 9:42 am: "I have a partner asking for our SSH2 public key. I tried using Tediware help but eventually it said to contact support. Are you able to assist?"
> Response, 10:47 am: "You need to generate a key pair yourself and keep the private key. Tediware does not issue SSH keys. Here's what you do. [instructions follow]"
> Follow-up response, 12:20 pm: "Generating your own key pair is now part of the app."
> Time from support request to new feature designed, coded, tested, deployed and announced: 2 hours, 38 minutes.
Side note, this feature has been solid in prod ever since (that story is a couple of months old).
Obviously, some things take weeks still, but they're hard. I just finished writing an X12 translator/parser, from scratch, in Rust. The old translator/parser was written in Ruby and ran documents at 175 kb/s. The new one handles 1 MB/s. It took me seven weeks of on-again/off-again dev work, fuzzing, testing, etc. It went live in prod yesterday.
> > Time from support request to new feature designed, coded, tested, deployed and announced: 2 hours, 38 minutes.
What about risk assessment? Are the customers guinea pigs?
Haven't they always been?
Ergo the famous:
Everyone has a testing environment. A lucky few also have a production environment.
Paul Graham talked about fixing bugs on the production server while the customer was still on the phone, because it was written in Lisp.
This last week, I was able to delete considerably more code than I would have been able to before LLM assistance.
Specifically, I was able to consolidate some CSS because I could ask Claude to calculate the cascade before and after and verify that nothing had changed about rendering.
I’m sure there was a way to do that before by scripting a headless browser, but I didn’t have to learn that tool to unlock this capability.
I definitely see more broken features!
Maybe this time we get people to abandon the big, dysfunctional companies that were never actually able to write software.
I'm sure the release cadence on browser updates has gone up; and thanks to all the CVEs getting found now, there's definitely real value from them, even if we simply wouldn't have known about all the risks if it were not for the same AI solving them.
For entertainment, it's definitely been huge for gaming. In Roblox the majority of games now are AI generated. Of the top 100 games, 80 used AI in some way or another and there's 70,000 AI generated games total. Roblox has a huge number of players too (~380 MAU) so tons of people are playing AI generated games.
I think it would be more widespread if there wasn't as much pushback against AI. Big Walk disclosed they used ai to fix a bug and it immediately got review bombed. Kids on Roblox don't care as much, so you can see just how transformative it has been there.
Roblox is played exclusively by children. Children have the taste nuance of insisting chicken nuggets with ketchup are the epitome of cuisine.
The IGF really dropped a grenade into the discussion heh. What happened was IGF clarified that "using AI" includes using it for coding "help" and research, which Big Walk had disclosed. This does not align with Steam who doesn't require disclosure of those particular uses, and in general using it for programming has been arbitrarily deemed OK by players and the industry.
Personally I think Steam should either get rid of the label or expand it to any usage because the carve-outs are arbitrary and pervasively widespread in use - I don't find it believable House House's developers are still almost entirely coding by hand and only leaning on AI for the hardest problems lmao. The stigma isn't sustainable once full disclosure is normal, and then games can be judged simply on their merit either they're good or bad.
Failing that it's hard to imagine what IGF looks like next year because everything currently in development will be using AI in some fashion, either they're going to have no candidates or no honest ones.
> “Programming is a creative discipline whose labour deserves the same respect we extend to any part of making a game. This extends to the past work used to train these models without the creators’ consent.”
https://www.videogameschronicle.com/news/big-walk-studio-say...
It feels to argue the point that ai doesn’t have visible outcomes you’d have to go down the path of the no true scotsmans fallacy pretty hard.
“Sure there’s a massive increase in the number of apps on the app stores, there’s new examples of decompiled and recompiled games popping up all the time not to mention all the vibe coded games, many companies are reporting they have new bespoke vibe coded tools to do some task they used to do manually, people are just cloning popular apps like photoshop with bespoke customisations to their needs..” etc.
I already know the tiresome response to any such example given by people of this mindset. “Yeah but those aren’t TRUE examples of users getting features faster!” Whatever.
Who is not shipping faster? We definitely are.
Places where this gets stuck: IT services firms. I work for a software vendor that only sells through them, and most of them still bill by the day (at least in Europe).
For a service firm billing days, cutting the team in half because the shipping pace is the same would clearly breaks the business. So nobody there is in a hurry to measure outcomes, and the client’s procurement team compares day rates anyway. At least up to now.
We can build an app in minutes with Claude Code, Codex, Cursor but deployment of new apps still requires a human to sign-up, browse a dashboard, create API keys, enter a credit card, etc. This means for less technical users, deployment might not even happen.
I would want to see more cloud providers embracing fully-autonomous deployments for new users, I created this benchmark to track progress here: https://github.com/cloudishai/ai-deploy-bench
In order to ship faster, we need significant improvements in efficiency when it comes to reviewing code.
That may or may not include shipping without reviewing code. Something I think is a real option to consider as LLMs and agents become more capable.
The reality is, any point where a human is involved is now a bottleneck. Even when that human is using an agent to write code. This will apply to the review process as well.
It feels this way, doesn't it? At least until we focus on something besides pure efficiency.
[flagged]
I think the recent article by Rober Haas on why Postgres release is delayed is giving a very good insight into the general "why".
I must say the handout PDF backgrounds are adorable and clearly convey each of the speedup and slowdown points in the process.
At least in our case, we are shipping faster. The rate of bugs has gone up, but still proportional to the behavior changes.
I'm shipping faster, but not as fast if the output was the same as before. AI allows for deeper code, all the nice to haves you wouldn't normally do. Test coverage is now fully complete as well, and I mean full tilt mocks and every edge case, not just the happy path plus bugs found in testing.
I'm a one-man operation with an equities markets analysis product. I'm definitely shipping faster. Fixing bugs and adding features literally 100x faster as well as implementing some very complex math that I likely could not have done on my own previously.
Most if the issue I’ve faced working on production software in team environment is to be able to defend you PR and story the changes and understand it to a level to be able to defend it. For PoCs and demos it can accelerate a lot but not for many other use cases.
We need better systems and frameworks for composing 1 person made and owned systems into multi person systems. To be able to trace and manage and reason about the properties kf the side effects as needed
We're shipping at the same rate but with a team of 10 instead of 24 we used to be
I work for a midsize company within retail and we are definitely shipping faster?
We are.
At least at Block our velocity have gone way up. One big unlock was designers building their own features not making it a developers problem.
Our biggest bottleneck is PR reviews but we are also gradually solving that.
I am writing code 5-10x faster and I can feel it go, but I'm still waiting 2 days for the IT to install something on my useless locked down laptop, still waiting a week for a trivial corporate firewall change, still waiting 2-3 weeks for business to make up their minds about whatever the hell they want to sell now. So I am shipping faster, but actually not.
Yeah, our CI/CD pipeline is still a dumpster fire. Management refuses to use AI even though it would help them more than us. Our build team hasn’t really used it to improve our build times.
The trillions-dollars question is how come software itself doesn't get improved by (at least) an order of magnitude, if not more.
More to the point, the price of RAM that has gone berserk. Easy solution, let's then make our OSes, browsers and almost all the relevant software that we use day to day an order a magnitude more nimble, for example if a Chrome instance now eats 1-2GB of memory then make it eat at most 100-200MBs of said memory while doing the exact same things (if not more). The much lauded AI revolution in code-writing hasn't created that, not sure if it will ever do, it will just add slop after slop after slop, in fact it wouldn't surprise me if the memory requirements for something like Chrome won't increase as a result of the recent vibe-coding mania.
But by this point the AI zealots are already running the asylum, so nothing to be done.
> The trillions-dollars question is how come software itself doesn't get improved by (at least) an order of magnitude, if not more.
The sad thing is those using AI to code (and I certainly do) don't realize they're producing more but just more of the same turds they were already producing.
And in addition to that they're producing turds nobody gives a shit about (ah!).
Where, indeed, are the both less memory-hungry, less CPU-intensive and more secure rewrites of the pigs we work with on a daily basis?
Nowhere to be seen.
Because the AI zealots are way too busy adding crap features over crap features.
We're shipping bugs at light speed
[dead]
A lengthy construction of "conventional wisdom" and "talking points" for mgmt who need apologia for their spending.
I don’t want to watch a 21 minute video right now.
But does it say what quantifiable evidence they have to show software teams are NOT shipping faster now?
> why aren't we shipping faster now?
We are. ~300% as of late-summer when I calculated. Models have gotten markedly better since then.
We are but it’s weighted towards the independent and never-coded-before side of the ecosystem at the moment.
I don’t know who your “we” is, but the “we” I’m involved with is shipping faster.
We are shipping at a significantly faster rate both internally and externally.
Who are we?
Google Search: 1998
Gmail: 2004
Google Map: 2005
Google Docs: 2006
Chrome: 2008
vs
Claude 3 (+ tool calling, web search): 2024
Claude Code: 2025
Claude Design, Sheet, Data: 2026
"We" (whatever it means) are shipping faster now, no?
[dead]
We definitely are.
I'm more productive a shaving Yaks.
You're not shipping faster?! holy moly. I'm orders of magnitude faster with fewer scope-cutting calls.
Speak for yourself, mate
The bad guys are. :-)
AI has accelerated coding but what happens before and after coding has not accelerated much.
Pre coding : Requirements, grooming, solutioning (cross product specially), design, LLD
Post coding: Cross product testing, E2E integration testing, CRQ approvals, Deployment, pilot, roll out.
SWEs don't just do coding. AI has only solved that and testing to an extent.
Because we spend time writing clickbait articles
We are.
You can't go half-in with AI; need to go all-in. At 10:39, he's talking about how humans are reviewing the code. No. You cannot go half-in; have to go all-in and set up AI reviewers that match the best human code reviewer's heuristics. You cannot go half-in and have QA doing manual integration testing. You have to go all-in and AI driven, automated QA.
Speeding up delivery of code is forcing a lot of orgs to face a reckoning of inefficiency that they've built up over years that need to be fixed.
It wasn't until after factories were redesigned from the ground up to take advantage of electricity that the benefits of electrification were realized.
There's a persistent question in my circles: "what does it mean to be AI-native".
Your analogy here is apt because AI-native teams are the ones that are doing the impossible. I know 4 non-technical solo-founders (all had previously courted me pre-AI coding to be a technical co-founder) that are effectively shipping real products with no engineering team. One has 4 large universities signed.
These guys are all-in on AI because they could not exist without it; by necessity every leg of what they do is AI.
And also the other bottlenecks start to emerge, like product management & design.
The question should be: why isn't software improving?
Claude Code TUI, probably the poster child for AI-driven coding, itself is still going to sh*t.
we are...
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
We are. This has got to be clickbait.
[flagged]