Can't tell you how many times I have heard about a friend's company needing to send an apology email to customers about downtime and flakiness due to AIgen commits that were poorly reviewed and misunderstood
-
Can't tell you how many times I have heard about a friend's company needing to send an apology email to customers about downtime and flakiness due to AIgen commits that were poorly reviewed and misunderstood
-
Can't tell you how many times I have heard about a friend's company needing to send an apology email to customers about downtime and flakiness due to AIgen commits that were poorly reviewed and misunderstood
Hell even Microsoft did it https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/
-
Hell even Microsoft did it https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
-
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
You can use these tools for red teaming (caveat: you will get a lot of false positives also). You can sort of use them for prototyping (though a lot of the value of understanding building through the prototyping process may be lost during that time; still, it is one place where things can increase). Those two categories don't create huge and unresolved copyright output questions in your codebase, and I think you can justify them.
But if you're using them to actually write the software itself, you're borrowing against the future, against stability, and against institutional understanding of your own stack.
-
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
@cwebber Even the first book about software project management, agrees 100%. I've always asked by project managers if they know "Mythical Man Month", and it was a decent predictor of their performance - especially, if they knew it and never read it.
-
Can't tell you how many times I have heard about a friend's company needing to send an apology email to customers about downtime and flakiness due to AIgen commits that were poorly reviewed and misunderstood
@cwebber and I have the feeling that these are just the humble beginnings.
-
Hell even Microsoft did it https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/
-
You can use these tools for red teaming (caveat: you will get a lot of false positives also). You can sort of use them for prototyping (though a lot of the value of understanding building through the prototyping process may be lost during that time; still, it is one place where things can increase). Those two categories don't create huge and unresolved copyright output questions in your codebase, and I think you can justify them.
But if you're using them to actually write the software itself, you're borrowing against the future, against stability, and against institutional understanding of your own stack.
@cwebber I've described previous attempts at work to Increase Velocity as strapping on rocket skates so we can careen headlong into a brick wall faster.
With AI codegen I think we've decided the rocket skates weren't fast enough or the brick wall big enough, and are going full Saturn-V-Into-The-Sun.
I'm sure it'll be fine though. Really. What could possibly go wrong?
-
You can use these tools for red teaming (caveat: you will get a lot of false positives also). You can sort of use them for prototyping (though a lot of the value of understanding building through the prototyping process may be lost during that time; still, it is one place where things can increase). Those two categories don't create huge and unresolved copyright output questions in your codebase, and I think you can justify them.
But if you're using them to actually write the software itself, you're borrowing against the future, against stability, and against institutional understanding of your own stack.
@cwebber I've recently made the weird decision to hand-write `AGENTS.md` files for my repos so people can use those things to debug & query. I guess using `/init` is fine too since if there's a copyright issue, I can simply remove that one file...
-
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
@cwebber What we are still lacking is a good taxonomy for maintenance.
Whilst "new code" can be easily measured by "lines of code" or through "new features" there is no metric for maintenance.
Because maintained code is a non-functional feature.
@d3sre did some amazing work on the other non-functional feature info-sec, to make the work of SOCs visible, see:
GitHub - d3sre/IntelligentProcessLifecycle: The Intelligent Process Lifecycle of Active Cyber Defenders
The Intelligent Process Lifecycle of Active Cyber Defenders - d3sre/IntelligentProcessLifecycle
GitHub (github.com)
Would you happen to know if anyone works on this?
-
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
@cwebber I posit that writing code itself is never the bottleneck (otherwise it would have been solved with cheap offshore programmers long ago).
The hard work making software is designing it, including from a user experience point of view, your business needs and operational constraints.
Using generative AI to add code you don’t understand (or worse, features you don’t know why you add them) will make all of these things cumulatively harder.
-
You can use these tools for red teaming (caveat: you will get a lot of false positives also). You can sort of use them for prototyping (though a lot of the value of understanding building through the prototyping process may be lost during that time; still, it is one place where things can increase). Those two categories don't create huge and unresolved copyright output questions in your codebase, and I think you can justify them.
But if you're using them to actually write the software itself, you're borrowing against the future, against stability, and against institutional understanding of your own stack.
@cwebber i had said it before about LLMs in other contexts, but a few videos i watched today made me realise this absolutely applies to the LLMs writing software case: It’s gambling addiction
-
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
@cwebber AI has proven very good at fixing two problems humanity didn't have: a shortage of labor and a shortage of cobbled-together first drafts of things being used in production.
-
You can use these tools for red teaming (caveat: you will get a lot of false positives also). You can sort of use them for prototyping (though a lot of the value of understanding building through the prototyping process may be lost during that time; still, it is one place where things can increase). Those two categories don't create huge and unresolved copyright output questions in your codebase, and I think you can justify them.
But if you're using them to actually write the software itself, you're borrowing against the future, against stability, and against institutional understanding of your own stack.
Oh yeah the other caveat about using them for prototyping, as @tamzin highlights below, is that "quickly thrown together prototypes" often become production code, to their authors' dismay.
In many ways, whiteboard prototypes are much better, as they are immune from this problem.
-
R relay@relay.infosec.exchange shared this topic
-
-
@kaye curse you someone has a startup for this right now don't they
-
-
@kaye curse you someone has a startup for this right now don't they
-
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
@cwebber
I want you to tattoo this onto some corporate executives... -
The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.
If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.
@cwebber There's the GitHub nines, but I'm wondering when we will start seeing more hard numbers that things have generally gone to shit. The data is probably out there but siloed and guarded in hushed tones.
using the power of Copilot
