You'd open your phone and nothing would work, not even the connection to the cellular network since your phone company has management components running on AWS.
You might have that problem, but us-east-1 going dark is unlikely to impact my Australian carrier enough to knock cellular service out. But granted, I might notice something is up if I tried to use my phone for much. If us-east-1 vanished at the right time of day I might notice on my phone first, sure.
> You'd open your phone and nothing would work, not even the connection to the cellular network since your phone company has management components running on AWS.
I'm pretty confident, sitting here on a different continent, that I wouldn't have that problem at all.
I think parent is trying to say that the number of services that rely themselves on AWS or some of their internal services is enormous and potentially impacts many.
That problem is as old as commercial programming; it doesn't matter that now your actors are prompt engineer and LLM, the same story can be told with manager and programmer.
Indeed. And this is also why I've never once believed the "no-code" would replace developers. And why I see a clear role for software (prompt-, context- ?) engineers at least for a while.
I've worked for CEOs and managers that would insist on ridiculous ideas. Like that time a CEO (let's call him Cedric) came in with a printed powerpoint slide that had a screenshot of the website with a "login form" drawn on top of it.
Cedric: "I need you guys to put this onto that scrunt board thing and make this before friday".
Me (tech lead at that time): "But what features would users need login for? Where or whom needs the profile data? We'd need to work this out in detail and plan it. Certainly not even this month".
Cedric: "I don't know, it's for you to figure out". and then "It can't be hard, it's just two squares one for a username one for a password" (he forgot about the submit-button, the third "square", he didn't even fathom the idea that something has to lie "behind" the "squares").
I recall this anecdote whenever I feel anxious about whether soon "stakeholders" can just chat to an AI agent and have it build features, rather than hire me to do so. Sure, a lot of them will be able to. But there's always Cedrics. Those who not only fail to communicate their ideas in a way that even an AI agent would understand, they lack any understanding of what tradeoffs of their requested features are.
The Cedric's would be happy with an AI agent that complies and starts churning away. An agent that blindly accepts any request and builds feature upon feature. Making their product worse in every sense: unusable, unmaintainable, debt-ridden, security-nightmares.
Their agent will build features that are plain illegal. Or features that users hate, or confuse them. It will oblige requests that drive users away, or changes parts that users/integrations rely on. Their AI agent will gladly add a "form" to extract all PII from their database, but on request, will remove the authorization from it. Because "you are absolutely right. If we don't link to the page from the menu, no-one can reach it".
I'm not making the last one up. Another "Cedric" alike recently hired me to look at his vibe-coded app because his go-to developer gave up and dropped the project. It had loads of such extractors, dashboards and overviews. Online. Unauthenticated. His claude, however, did add the pages to the sitemap, so a customer found their private data on google and contacted "Cedric", after which he asked me.
No, AI is getting smarter, but as long as the "Cedrics" remain as stupid as ever, I don't fear for my job.
I would agree. The AI system has destroyed junior job roles, but to understand the output from a LLM and ensure it is useful and correct, you need to be a senior/experienced developer.
AI merely makes certain folk stay at the start of the Dunning-Kruger curve for longer and longer. Having zero understanding of a system and only see the user-interface and concluding that is somehow all that is involved means people end up thinking everything is far, far simpler than it actually is.
And nothing (and I really do mean "nothing") is simple. We have layers and layers of complexity and idiocratic systems with complex interworking and are creating the opportunity to create things based merely on the appearance of the icing on the cake, or the output of a sausage machine without understanding anything about farming cows.
I am pretty sure we have always been able to add holes faster than we can find them and fill them, and that this has not changed with the advent of faster hole finding tools that are also faster hole producing tools.
SQLite has gone into a frenzy of bug fixing this past year, changing long stable processes to ease things up: opening a specific report channel just for these kinds of bugs, adding features to Fossil to help manage things on their end (and that's just the visible stuff).
And with all that, the latest release has unfortunately been the buggiest I've experienced so far.
I skipped the .0 because of a crash, and only released .1 after giving up waiting for a .2 that never came, with a patch to fix a serious performance regression.
I spent a month supposedly shipping old bugs no one had a problem with, rather than shipping new bugs that instantly crashed things or caused measurable regressions.
That's on a software with stellar testing, and a good engineering team known to favour stability over the new shiny.
Do you think AI is as good at writing bug-free code as finding bugs? If that's the case, this should be a one-time event during human coders -> AI transition. It's like catching a lot of bugs during a handover review.
What categories of bugs would you say we eliminated going from macro assemblers to compilers?
(Operating systems, by the way, are the exception to the rule for assembly: the Linux kernel today has an x86/x64 assembly source component around the same size as MSDOS 5.0: ~250kloc of it. Windows is smaller, based on the NT4 kernel leak at around 70kloc. As a percent of total they're much less, of course, but they also do much more. And have correspondingly more bugs, too.)
> What categories of bugs would you say we eliminated going from macro assemblers to compilers?
Entire classes of 'safety' bugs that just don't exist in modern compilers.
E.g.: forgetting to "POP" something you "PUSH"-ed, especially when it was a conditional allocation for a temporary.
Similarly, type errors were much more common, especially signed/unsigned, or accidentally overwriting things in scenarios that just don't occur even with ordinary C code. Function args were easy to push "correctly enough" that it "worked", but not really.
The code it writes in the first attempt is at least as buggy as a human's. So the question is more whether it is as good at spotting bugs in its own code as it is at spotting bugs in human code
I'm tempted to say "no, it isn't". But I don't have numbers to back that up
It feels like we need AI methods to write provably correct code, along with a way for AI to automatically translate existing code into corresponding provably correct code.
(And hope performance stays in the same ballpark as the old code.)
Yes. Allowing a naive agent to fix bugs can quickly become pollutive.
I suspect both old codebases and new ones that have a very intentional architecture are both dangerous to let loose.
The agent doing the fixing must have not only an incredible map of the project and how it is put together, but the ability to reach into annotated examples in the past and refer to them as it goes about a fix.
I’m seeing that frontier models will not follow intended patterns or know when to deviate if their primary charge is “fix this bug.”
It is perhaps a better idea to have agents’ primary job be “maintain this codebase” and one way that they do it is to fix bugs, and “oh by the way here is a bug.”
I don't think this is exactly true; adding holes only happens when adding features, and while LLMs can add features fast, deciding what features are actually wanted and needed is still a human factor.
So the amount of new code added is limited by processes and product management. Add to that that newly added code can get a lot more checks on it now, and new code will be more secure too.
I also don't think your main premise (adding holes faster than we can find them) holds up, but that's another matter. TL;DR I think we're in a high intensity period right now, but this time next year it'll be quiet in comparison - possibly quieter than before AI code scanners were a thing.
Most day to day programmers prefer to keep the source code to their programs rather than the executable file, so I think it's not absurd at all, it just takes a brief moment of reflection.
I call an electrician to change a wall switch since an unlicensed handyman making a mistake that starts an electrical fire voids my home insurance.
Plumbing is fractionally less regulated where I am and I am allowed to change my own taps washers, but a whole tap assembly falls under similar issues as a power switch.
I tried #2 from here in Australia, but the experience was incredibly poor despite fibre to the home at 500mb/s. You'd be better off buying one of the gaming mini-PCs with 32GB DDR5 and a 760/780M iGPU for ~3-4yrs worth of monthly costs, but the Vimes theory of economics might prevent that.
(I wound up building a gaming PC, much more capable but much more than the cost of streaming over an equivalent lifetime - IF streaming services don't enshittify to cost more and deliver less over time, which we all know they will.)
There's a vast number of operators who won't even look at their site when its performance craters due to a scrum of crypto miners all competing for resources. Why waste time on sophisticated attacks trying to fly under the radar of competent admins who will detect you by your egress traffic anyway?
If you use an Either instead of a List, then you can write an or combinator, which accepts two parsers and tries the second if the first fails. It branches on the Left/Right of the Either.
If it's a List, wouldn't you be forced to write the Cartesian product of two parsers instead?
You’re going to write a monad and alternative instance for whatever structure you use. A list is a Cartesian product, but that’s just the join of parser B over each remaining input of parser A, it’s still a one-liner.
The question is capabilities. Either gives you an error result that might be useful. List gives you backtracking and, depending on your grammar, multiple parses. Maybe is like a weaker Either. Other monads might do other interesting things, but from the perspective of accepting strings satisfying a grammar, List is the choice that supports non-determinism.
(Laziness strongly recommended.)
The poem is not mine, I believe it is Conor McBride’s.
It's cute so I had to look it up. According to this guy [1], it's a poem from Graham Hutton's Haskell book [2]. I don't have the book so I can't check, but it sounds plausible.
The list represents the possible parses and the remaining input for each. In most cases you might prefer an unambiguous grammar, so a successful parse is a singleton list of a pair of the full parsed result with an empty input sequence.
But parser combinators build your final parser out of little bits, and sometimes those little bits might be something potentially ambiguous, like "any number of leading zeros followed by a number" which needs to parse "0" as no leading zeros and the number 0, but "00" as one leading zero and the number 0.
Non-deterministic parsers can easily blow out with backtracking much like careless recursive descent parsers, though.
I think these days it's easier to run Steam in Wine than it is to run Wine in the first place. If you're running a commercial packaging of Wine for gaming, both things are trivial.
(Successfully running Windows games is its own issue: I think "Steam Deck" compatibility badging is a pretty reliable tell for Linux gaming, but on a Mac, having the game be playable is a gamble on install and again with every patch.)
reply