Since we're deep enough in this thread where we're talking about steak rather than AI, I'd like to lean into that.
I used to sous-vide a lot. It was certainly great to get perfectly-done steak. but I still didn't love the result and it took me a while to figure out.
Specifically: sous-viding at 130 doesn't reliably render fat. So it's great for a lean filet mignon like your suggesting, but kept giving me rubbery fat in anything with more fat or significant marbling. I eventually switched away from sous-vide (I usually either grill or reverse sear, depending on my effort/time availability) for most cuts these days.
Took me a minute to see the value - my first thought was "this is just cursor's cloud agents..."
But the key thing here for me is "Every sandbox boots your app on a live URL." Cursor doesn't easily have that, and that's what would allow me to ditch my local env entirely - the ability to actually try out a PR without needing to check it out locally.
So on that note: how does that work? We've had trouble with getting our dev env running in other cloud envs because it requires a few things (clickhouse, localstack, pg, etc) running which we manage via docker compose locally.
Also, some minor pricing feedback: it'd be really great if there were a version with pay-as-you-go and a cheaper fixed cost. I think your 99/seat/mo model is fine for professional work, but it's a lot to commit to for personal work.
Modal just released some features that would allow users to bring custom Docker images, and I'm working on getting your exact use case supported! Aiming to get it out by the end of the week.
Noted the pricing feedback! We're still figuring out exactly what works best so it's still very much so subject to change.
There's some good ideas and points in here, but this bit threw me:
> # We tried this
> In July 2025 we went full lights-off
Isn't it pretty well-accepted at this point that the models underwent a step-change in usefulness around fall 2025 / spring 2026? I know that I was able to start handing agents whole features after that, but not before.
I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era. TFA calls it out a few sections later with "But surely the models have gotten better since then", but then just writes off any improvement. That does not match my experience.
I had a bit of this impression when reading the post as well as the authors' product website. A lot of it does seem to be stuck in 2025.
For instance I think their post "long-context isn't the answer" on their website post straight-up isn't accurate, and gives me the impression they are just extrapolating previous performance to new models. In my experience, Opus 4.6 and newer have worked very reliably for long context to me (i don't perceive any intelligence drop at 700-900K tokens). Yeah it's extremely cost-inefficient, but it works.
> i don't perceive any intelligence drop at 700-900K tokens
I have countless examples of this for Fable 5 and Opus 4.8 at just half that many tokens. Sometimes they can't even remember the correct workflow even if they're merely an orchestrator and have been going through the same 5 step loop multiple times for pretty much their entire context window.
One of them is particularly egregious because it uses a CLI tool to step through the stages that literally tells it what to do next. How do you fuck this up? Needless to say that tool was revised to force the agents to acknowledge everything happened, but I'm sure it will find a way to eventually mess up anyhow.
And orchestration should be the easy part. It's pretty much just writing and adjusting workflow files. Don't get me started on code quality - but I realize that's subjective and my bar is unusually high. There's a reason I have them run adversarial verifiers along multiple axis before their output is even worth my attention.
FWIW, I notice the intelligence drop drastically with long contexts with Opus 4.6. It's barely usable for anything intricate and long. That long window is good for _something_, but it's not as good as a short window.
Oh yeah, that's a use case I love long contexts for. "Here's a day of prod logs, what's broken?" It's an incredible utility, but the qualities much less than with shorter contexts, and you see it much more apparently when you do similar coding tasks with progressively larger windows.
Opus 4.5 was a massive step change in capability for sure. The opinions of anyone who hasn't bothered experimenting with these things post-Opus-4.5 are not worth a damn.
They still are far from perfect but they're massively helpful.
I just listened to a podcast last week with the author (Dex Horthy) on as the guest. Humanlayer (his company) is constantly trying to push the limits with agents and he's very into using them.
He's well aware of exactly how good the models are today and I'm sure that if he thought they were good enough now to make the dark factory idea work, they'd be trying again.
The obvious statement would then be: 2025 we went all in, 2026 still nothing improved substantially. I also agree with that statement, none of the frontier models handle drift any better. Shotgun surgery and all that. You're waving him off by waving him off, but provide no arguments whatsoever.
Is your experience substantially different?
my perhaps controversial take is that opus 4.1 was smarter than 4.5 for complex engineering work, but 4.5 was faster and "squishier" - it responded better to simpler prompts, it read between the lines of user input better, and that this was really important to converting new users quickly
As I mentioned explicitly in the comment you're replying to: yes, I did read that section. Did you not bother to read my whole comment before telling me to read more?
There's a more nuanced point about capabilities improving in some ways but not others (ability to one-shot apps vs. maintenance of existing code over time).
As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense:
React is the worst JS framework except for all the others we've tried.
I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build it yourself from scratch every time" approach of Backbone. I'd take Backbone's minimal MVC structure over the classic JQuery Soup architecture. And I'd take JQuery's dom manipulations and standard-library improvements over the native apis (of that era) in an instant.
React has its tradeoffs, but we got here after a long slog of other things that don't work.
But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.
I skimmed through it, and I think the only thing that is out of date is the section on `zone` in Angular. In october 2025, they changed to `zoneless` by default, which uses signals just like Vue. This was a long time coming imo, as the major criticism of Angular was how poorly update management was handled. Also Svelte runes aren't mentioned, as that came out three months after this post. Runes are essentially also signals.
Basically every framework now has a concept of
* State - change this and the framework automatically updates UI and triggers effects
* Effects - functions that run when parts of state change (or triggered by signals)
And almost everyone solves this with signals except for React.
Any conversation which isn't dead will age fast in tech. What is the state of discussion on generating a random integer? Even that conversation advances.
Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch.
The real discussion would be between React's vdom and something like Solid's signals.
It does, if you care about ergonomics. The reactivity model is simpler and arguably less error prone.
It does have its own templating syntax, which is trivial to learn. No more cumbersome to learn than JSX, which is a templating language designed by the React team. Not sure why you chose to make the distinction between JSX and Vue’s DSL as if JSX wasn’t developed for the sole purpose of facilitating React’s virtual DOM.
JSX is <div>abc</div> turns into createElement('div', null, 'abc') and you can use that instead of JSX if you like or you can use something like hyperscript. Everything else like mapping or if statements is pure JS and works just like JS anywhere else in your app.
Vue templates mean learning Vue's custom syntax for if statements, loops, dynamic attribute syntax (with its own gotcha), binding dot modifiers, data binding, and whatever else. It requires learning its entire custom directive system. It uses custom syntax for stuff like events too.
I don't see this as remotely comparable with Vue being much closer to something like my time working with Angular 1 (a time I'd rather not repeat).
It is a massive difference. I do not like magic compilers. The JSX transform is trivial and not even necessary, just create a factory function and React.createElement becomes arguably more readable, just not HTML like.
Is it a massive difference, or is it a small difference? At the end of the day 99% of React projects have a transpilation step and utilize some form of “magic compiler” somewhere along the line.
The simplicity of JSX is overvalued. It just means more code, and typically uglier code, to achieve the same behaviour as Vue. Which is basically the theme of React when you compare the two libraries.
It is more explicit code. Something only changes when I tell it to rather than being magical like in Vue, not to again mention its proprietary DSL and API.
JSX is a very thin layer of templating logic inside JS. Meaning you have all the language features available while templating. Some arbitrary JS can result in templating.
Vue's DSL is whatever language the developer implemented. Which is probably not enough, depends how much effort they put into it and how good they are in language design. Given that they cargo cult HTML tags to organize components in a pseudo-familiar but not-valid-HTML way, I don't have much confidence in their language design skills.
While I understand the advantage of using the built-in language features (and I know why it is required to be done that way), I still think using
{enable && <Form />}
for conditional rendering, or
{collection.map(x => <Item x={x} /> }
for looping are not the most obvious choices. If you ask people how conditionals and loops are written in JS, you will get 'if' and 'for' or variants of 'while'. So I get where the v-if and v-for are coming from.
Me personally, I prefer these more functional (and more succinct) expressions. For loops are overly verbose, and not as composable. But then again, I'm a Lisp programmer.
Let's say you to render conditionally when `x` is present. You do `v-if="x"`. Now you want to refer to `x.y.z` in the body, while `y` is optional.
Can you be sure that the value is present? How do you check for it? What does Vue need to do to enable this functionality with static type checking with TypeScript?
With `{x && <>{x.y.z}</>}`, it's almost vanilla TS, it's the same as `x && x.y.z` in normal TS. Type narrowings that work in TS are guaranteed to work in React, without the framework having to do anything.
Less framework/library code required to make the same thing work. To me, that's the sign of a better abstraction and implementation.
Sorry but JS is, and always has been, a crap language many are trying to escape. So saying react has the full power of JavaScript is an antipatten as far as I am concerned. Vue is better designed.
Vue solve single source of truth much better than react though. The shape of derived data and source data (or even external data) are the same and interchangeable. So you can write an api that works with both without handling implementation quirks at all.
The company I work for uses Vue. I think the non-backwards-compatible move from Vue 2 to Vue 3 burned a lot of the current devs, so now they're stuck working on Vue 2 apps that are in maintenance mode with no viable case to clean up the mess by moving everything to Vue 3. The experiments to do it with Copilot mostly failed, although that was in the early days so another try today might work better. If we're doing something drastic to improve though, we might as well solve our "Vue devs are hard to find" problem by rebuilding it all in React at the same time.
I am in a process of upgrading fairly big Vue 2 app (technically 2 apps, where one is not traditional and the other uses Inertia) to Vue 3.
It is a fairly painful process - I am using Codex and Claude as a first pass for converting things, but everything has to be checked manually and often fixed or rolled back to try again. Too often instead of "removing" piece of code that is not necessary anymore, AI would try to add a 100 line workaround for it because it would really rather add things than remove them.
It is, however still a faster process than doing manual rewrite. Smaller components are a breeze to convert from older Vue 2 to Vue 3 composition API.
Rewriting entry point app.ts with bunch of custom plugins was a horrendous experience that eventually was done manually. Move from Vuex to Pinia was also 50/50. Some things were easy, some things were not and had to be done manually.
Then there's a process of switching from unsupported packages which is a whole other can of worms.
Overall - if not for AI I'm not sure I'd have gone with an upgrade at this point. Yes it requires careful review and testing, but a ton of trivial stuff was done very quickly.
I led a project to (successfully) migrate a Vue 2 to 3 app and while that was painful and expensive, I still find Vue more pleasant to work with than React once it was done. But TBH depending one team code discipline either could be fine or a nightmare. :)
I definitely sympathize with the feelings about the Composition API. Though I’ve moved past it because looking at React’s visible complexity (useMemo, useEffect - which apparently have changed names again since I last looked) - Vue has clearly chosen a superior API design.
Yeah you’re actually right I was looking at the API section instead of the Hooks section. Perhaps another demonstration of React’s verbose API surface.
This sentiment only really applies if you’re coming from
Vue 1/2 to Vue 3. The Composition API is definitely more like React but makes some better design decisions that make it easier to work with than React. Such as implicit reactivity.
If anything, composition API has taken the good parts from React. Once you get the hang of it, it’s amazing. Everything clicks together, is easily composable, and fully typed-safe.
Yup I'd sign this. We use Vue2 in a old codebase with options API and composition API in new projects. Both feel way better than anything I ever had to do with React (how many Hooks do you have to learn by now? 13?)
Vue just has a very simple lifecycle and combined with a simple store like Pinia it's just really fun to work with.
Agreed. Like you, I went from hand-written cgi-bin html to jquery to angular v1 to React. I will willingly reach for React as a tool - it does what I want to do.
I remember in 1999 being so psyched about changing a button image on mouseover. Went hard on jquery, little bit of angular and bootstrap. React was big for me because it’s one way data binding solved the kinds of bugs I had spent years dealing with. Vue svelte and others are cool but they are all very similar to me. I always encourage people to work at first without any framework because then you gain an appreciation for why these things exist (or you stay vanilla and constantly blog about it)
Have you used Svelte? I can’t see why anyone would like React more. The only upside I think react has it’s the IBM of frontend. No one has been fired for choosing React.
Currently rewriting nextjs app into sveltekit. It’s going surprisingly smoothly. Don’t know about svelte vs react yet BUT sveltekit is far more straightforward than nextjs has far better DX and is somehow faster
Svelte is cool although I didn't have some big epiphany. I'm not going to use Svelte because "it compiles" and "is faster" when my existing React app performs very well. Plus there are some libraries for my specific use case that didn't exist in Svelte. I know people love things besides React, and I would be happy to see it unseated. Sure I'm part of the problem but it's been good to me and I have bigger fish to fry.
> Plus there are some libraries for my specific use case that didn't exist in Svelte.
A lot of these libraries aren't needed in Svelte because 1) the functionality might already be built into Svelte, and 2) you can use any JavaScript library directly, unlike in React where you often need a React-specific wrapper.
Not saying that applies to your specific use case, but I've seen this argument way too many times.
As someone who has written both React and Svelte for many years I must interject. React is itself just a library. No, you don’t need any specific “wrappers” for it. Let’s not mislead the readers here.
I suppose. And I'm not at all saying there's nothing better today, or that it would be possible to build today's web apps using that stack. Just at that point in time and with those technologies everything was clicking.
We're still using it for our stuff (via our @beanbag/spina TypeScript wrapper for Backbone that has a few additional niceties), and I feel the same way. We can be as close to the DOM as we need (or let something manage it for our view for us), we can be smart about where data lives and how things interact with it/listen for changes, and we get a decent little object model that doesn't dictate how we think about everything.
Very happy still with the Backbone way of building webapps.
I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic.
Migrating mostly was little effort and consisted of automatic migration and walking through the provided checklist (mostly to ensure I didn't miss anything important), but I don't have any comparison in the JS SPA ecosystem.
Vue 2 to Vue 3 has been equally painful for atleast one app I know about. Compare that to last three versions of Astro (with web components) and it has been a breeze.
> I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic.
The pain varies from project to project. Mine has been touched by a generation of developers of different levels of proficiency. A more disciplined project would’ve been easier to migrate in retrospective.
I think Angular ecosystem really missed the train with schematics (even ngrx!). Schematics could tackle a lot of toil if implemented exhaustively but apart from Angular and Material, nobody else seems to implement them effectively for brownfield projects.
I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating.
Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.
"React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.
I think it's a shortcut for saying that react doesn't have an 'official' routing library (like vue-router) and state management library (like vue's pinia). So depending on what you choose to manage routing / state, one react app can be quite different from another.
Maybe nowadays there is a set of popular libraries for react so it becomes framework-y?
Vue-Router and Pinia have always been optional add-ons for Vue too, however, yet the Vue ecosystem seemed to to fine without those "aaakshually“ kinds of people that feel the need to micro-manage other people’s speech.
Generally the difference between a library and a framework is that you can use bits and pieces of a library to add functionality to your project.
A framework expects most of your project to be shoehorned into it.
Whether something is one or the other depends on which of the two most users are doing. It's not a very interesting argument, though, because debating semantics is the worst use of the limited time you have on this planet.
Yep, react is indeed a library. Part of the confusion comes from a fact that
react community was keen to hijack "react" name and slap it onto their own
projects, for example there were react router, react query, react table, etc.,
so one could have get a feeling that react was like full-fledged framework, while most
of these "react" projects were not affiliated with react the library in any way.
That’s right — the outcome is path-dependent. If we knew then what we know now, surely we’d have gotten over the idea that the web is DOM-documents-plus-REST-plus-JS-handlers-everywhere.
A lot of people did and do like that idea — I like it too — but it’s woefully inadequate for making rich web apps that a team of average devs can handle.
I enjoy React and I’d take it over all of those other things. I wouldn’t take React over htmx/data-star and server rendering if that’s all I needed, and even if I had a couple of pages that needed a little bit more.
I was a big Sevelte fan. After writing a sizeable application in Sevelte I realized that React is superior in every way overall speaking and at least you're writing 100% pure JavaScript directly. Or Typescript.
Plus the ecosystem. It's huge. Nothing comes closer.
You might be interested in solid.js. To me, it's easier to work with than React. What I like about it is that the reactivity model is small enough that you can understand it, and even implement a basic version yourself.
It also uses JSX, but since there's no virtual DOM, you can also write 100% JS, but, unlike React, you can do it without any special wrapper. So you don't need to use or write a `react-dnd`, just use any vanilla drag and drop library.
I've tried solid and it's much nicer on small projects. How well does it scale though? Modern React is also 'more functional' (for some definition) but it comes at a cost of cumbersome and leaky abstractions. Classic React walked a fine line of being 'just reactive enough'. You could make code declarative and composable while still micromanaging certain lifecycle and data dependency decisions that can be critical for performance.
I've built quite complex applications (e.g. a spreadsheet app) using SolidJS as a base layer, and in that sense it scales really well. It's very easy to separate data management from the UI, so architecturally it scales well, and performance-wise we rarely had issues with it at all.
The biggest issue is in finding people to work with it. If you're hiring React developers over web developers, they will probably struggle more with SolidJS's differences from React, in part because they just look so similar that there's more to "unlearn". But most web developer (i.e. anyone who can understand beyond just the confines of their favourite framework) should find it relatively easy to understand what's going on.
Haha, that was part of the reason we originally went down this route. In practice, as soon as you want to implement spills, you lose a lot of the benefits because the contents of a spill can depend on any other cell and affect almost any other cell, and you need to evaluate the spill to figure out which cells are relevant. In the end, we rewrote the spreadsheet engine to use a different mechanism that was simpler and that we could optimise better, and then hooked that into SolidJS for everything else.
I guess technically that part of the application didn't scale so well in SolidJS, but it scaled a lot better than it would have in any other framework, and we got to delay writing the engine "properly" until we'd already built everything else and got it running with real users in production.
How did the React community convince so many people of this falsehood? Do that many people just not know what javascript is? It baffles me that one could look at JSX and be like, “that right there is vanilla javascript”.
History is important here. React came at a time when so many frameworks used custom template libraries for variable binding, looping, conditionals, etc. Usually it was some HTML/XML-like markup language.
vanila javascript would not be far off, just replace the tags with function calls. In early versions of react, there were people who wrote code like that. For some reason web devs since collectively agreed that the xml syntax is essential to web technologies
What people mean is obviously that you use JS primitives for looping, branching, conditionals, etc. over some DSL. Everybody knows that the tags are added syntax, there is no conspiracy here.
"These burgers are pure beef! Obviously what people mean is that beef is one of the ingredients. Everyone knows that the plastic is added in, there's no conspiracy here"
It's like arguing the moon and sun are the same size because they look the same size when looking at the sky. A hamburger with added plastic is essentially a hamburger. A hamburger made out of plastic that resembles beef is not.
I don't understand how you can interpret "pure means not adding in stuff to water it down" as "everything that's vaguely similar is the same", because from my perspective that's exactly what the parent comment I responded to is doing
I had main issue with smaller ecosystem. Very limited components and everything else is geared towards React. Take React Query for example. If you want first class data caching and retry logic etc, then Svelte support was second class at least couple of years ago.
We'll set aside performance because that could be fixed with a renderer rewrite.
The biggest issue when I worked with it was weaving a spiderweb of bindings that eventually trap you. At some point, you wind up spending most of your time fighting weird bugs that show up in places very far removed from the bindings that actually caused the bug.
Unfortunately I never got around to trying it! I remember it being a contender around the time of Backbone, but then Ember and Angular were the main options thereafter.
> React is the worst JS framework except for all the others we've tried.
> React has its tradeoffs, but we got here after a long slog of other things that don't work.
I strongly believe it's because of trying to achieve the wrong goal with the wrong tool. So many websites could just be bare html pages and forms with just a sprinkle of JS for some interactivity, but they want to add JS for whatever reason.
If you can have a complete repo browser without JS (cgit), most web applications can survive without it too.
There are four culprits here and neither is due to JS.
First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component.
Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all.
Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time).
Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
>I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.
Users need interactive stuff. If your site isn't interactive and your competitor's site IS interactive, customers almost certainly will prefer your competitor.
When you try to chain that stuff across multiple backend-rendered pages, you get a whole other list of problems. If you need to track all the otherwise transient UI stuff on the BE, you have now created a whole mess of stateful APIs and turned horizontal scaling into a much bigger issue than it needed to be.
Users wants something that will help with whatever they want done. And the quicker, the better. Interactivity is nice, but I never seen anyone complains about multipages applications.
> If you need to track all the otherwise transient UI stuff on the BE
So don’t add transient stuff? You send a page or a form according to the URL, the user does whatever it wants and either request a new page or submit the form. Each page is standalone like activities in an Android app. Anything transient is taken care of on the client side.
so you argued that the need for internationalization and Accessibility was such that if you tried to add that in to bare html - css solution that you would end up getting bloated, I argued (based on my experience) that accessibility bloat actually comes from the need to support various JavaScript bits of accessibility.
To which you then argue that the JavaScript parts are needed.
If so it is the JavaSript that adds the bloat, because the accessibility bloats to support the JavaSript.
I mean I'm not against JavaSript but I have seen many sites that didn't need it; and I've been forced by work requirements to add in too much of it on sites that needed very little or even none at all.
SPAs are a monster that grew and grew; an idea that at first seemed like a clever optimization has generated huge and complex systems that are a nightmare to work with, and are bloated, slow and insecure.
Web components are the next big idea. I hope they have a chance to work.
I hate spas everywhere too but if you needed to build one for valid reasons React is probably a good bet due to large ecosystem and adoption. I personally avoided React as much as I could and luckily I won’t have to have to work with it.
Interesting! Given the obvious AI-written nature of this, I'd probably want to double-check the math, but it's a neat concept.
As a homebrewer, the standard approach is to look up / measure your tap water's profile, buy a few grams of additives (gypsum, calcium chloride, epsom salt, etc), and add them to compensate. But if you don't have your water profile handy, this could work in a pinch. 5 gallons of bottled water is an expensive approach, though!
For anyone that decides to vibe-code these kind of tools, have a generated content vs. manual labour split.
This isn't bound to AI-use, even if you scrape factual content, a million and one things can go wrong, so having some kind of checkbox that says "Yes, I have reviewed and verified it is one hundred and fifty percent certainly confidently true, a fact even" forces you to verify what you're publishing is true.
I landed on something similar for my own game, though it's been pretty tricky.
I'm building a physics-based 2d game involving slingshotting around planets. The realtime nature of it has meant that it's nearly impossible for the AI to test using a browser mcp. It'll take one screenshot, then another, and in the intervening time the player shot off the map and into deep space.
Instead I gave it both a code-level api to step forward and backward the physics engine and a browser-based, `window.game` api to do it via a browser mcp console. The former helps it work out physics bugs and the latter helps it test animation and UI issues.
It's still not great. I keep occasionally getting "I tested it and it works perfectly!" as I stare at the mcp'd browser with the player stuck clipped halfway into a planet. I think, if anything, I need to lean harder into this approach: building really solid tooling for the AI to inspect every aspect of state. I would kill for a turn-based game like OP XD
OP here, cool to see all the similar yet varied testing approaches! Your situation sounds tricky with a real time physics based game. Converting it to step based sounds like it has promise, but as you mentioned, every dilution to the full e2e harness also dilutes the validation veracity. When you were describing your game I kept thinking of Bret Victor's "Inventing on Principles" talk where he "collapses time" in a physics game to render trajectories of objects in all positions at once to visually intuitively tell if it works right. Perhaps that could apply?
An alternate interpretation of that chart is "After the microsoft acquisition, they got serious about actually tracking outages."
That said, anecdotally, it's felt much worse over the last 6 months. I'd guess it's a combination of MS-induced quality drops and AI-induced scale increases.
Well, perhaps not as long ago (e. g. from the acquisition), but if you look at the last four weeks or so, just that part alone, you can clearly see that something is not working here. Microsoft is constantly mentioned on Hacker News and not typically in a great, praising light.
If it’s just the last 4 weeks, then I would say it seems the Microsoft acquisition had little impact on their reliability.
It seems pretty reasonable that the massive surge in AI over the past 6 months has put tremendous strain on GitHub’s infrastructure, and most of these outages are as a result of that one way or another.
They're moving to Azure and had to fix up Azure first to be stable enough for GH to even consider moving.
I'm guessing its a combo of Azure still not being stable enough and a byproduct of trying to move an entire company's operations from a physical DC into a cloud while its running.
Speculation from afar: clouds are not commensurate, and high-volume cloud services are going to anchor key architectural decisions around technical benefits/realities of the cloud environment they target. Moving GitHub isn’t a tech decision, and it’s broadly a Dumb Idea.
I think GitHub is well past the complexity threshold where the reflective architecting that happens during cloud development can’t be separated from product. If the Engineers were begging for Azure it’d be one thing, but otherwise this is destabilizing churn.
I agree Azure needed a lift to even handle the job, and see the that gap as indicative of a more fundamental challenge. That change is kinda like a skeleton transplant… managements feelings and post-surgery desires don’t necessarily account for the impact and essential difficulty.
Yeah, I think all style comments should be handled by either a linter/formatter or be written in a style guide. Everything else is up to personal preference.
Then, when a style comment comes up in a PR, the answer is "Oh, do you think we should add that to our style guide? If so, let's discuss that in slack. Until then, though, that's not blocking."
Winning 2000 games in a row sounds statistically unlikely unless the Windows version of solitaire does something behind the scenes to make the game more winnable.
The Microsoft Solitaire Pack or whatever the current branding is does, indeed do something behind the scenes to ensure the game is winnable.
I suspect they have either a massive database of proven-winnable shuffles, or before the game presents a new deck to you, it solves it in the background to prove it's winnable.
Personally I dislike this feature. Yeah it sucks to get an unwinnable shuffle, but that's just how card games work. Ensuring every game is winnable just seems like addiction engineering when it's next to the Microsoft logo.
Part of the fun is the uncertainty that a game is possible to win. If you know up front that a deck is guaranteed solvable, it really colors how you play the game.
Part of the mechanism of psychological addiction is unreliable, intermittent rewards. People feel like they are in control but can't figure out the optimal win strategy. One effective means of treating gambling addiction is to just teach people how to get good at gambling. It removes the mystery of the system and puts the subject back in control. So, making every hand winnable may actually help to make the game less addictive.
I don't know of any algorithm to cull non-winnable Klondike games. Playing deal-1 instead of deal-3, and with unlimited flipping of the stock, the win chance is probably close to 50%, but that still makes 2000 in a row statistically impossible.
My guess is that the poster's mom was actually playing FreeCell, in which nearly every game is winnable and people do get streaks like that.
You don't need an algorithm. You can just record seeds that are solvable. The current version of Klondike in MS Solitaire is winnable unless you play "Random" difficulty.
It wouldn't be that difficult to make computer solitaire winnable 100% of the time actually. It would mean "cheating" by moving cards around behind the scenes though
There's an assumption with computer card games that the computer shuffles the deck once just like a real card game but that doesn't have to be true on the computer if you don't want it to be
Now, any reasonable player would notice if you reshuffle the deck in solitaire, but you could swap around the face down cards without any problem. You could have just one stack of face down cards in memory and always pop from the top when a card is flipped
Edit: Maybe this wouldn't be winnable 100%, but you could certainly nudge every hand towards being winnable
Whoops you're right it was FreeCell! I totally got those mixed up but yes it was FreeCell that she got 2000+ games in a row, she was very proud of that. She didn't even want me to play on her computer in case I ruined her streak LOL
I used to sous-vide a lot. It was certainly great to get perfectly-done steak. but I still didn't love the result and it took me a while to figure out.
Specifically: sous-viding at 130 doesn't reliably render fat. So it's great for a lean filet mignon like your suggesting, but kept giving me rubbery fat in anything with more fat or significant marbling. I eventually switched away from sous-vide (I usually either grill or reverse sear, depending on my effort/time availability) for most cuts these days.