yes but people instinctively understand mechanical devices wear out. There is/was no natural reason to assume that about software. For the first decades of computing most of the public encountered that wasn't the case, quite the opposite in fact in 1995, the COBOL program you wrote in 1965 still worked fine. The DOS program you bought in 1985 still ran on Windows 95 just fine (well it was as likely to work as it ever was on any given DOS machine ;-) maybe more).

Software right seem to people like book, and their experience with books had been they were quite readable sometimes across several generations if they were cared for and protected (see the family Bible).

The rule here should not be that you can't 'sell' clients for your game server. I don't think the government should dictate the business model, but it really should make sure consumer understand WHAT specifically they are getting and not getting in exchange for their dollar.

There should be some limitations that come along with license terms that are not open ended, that is you are providing a binary(ies) or source code that will run on a given platform, ie a computer with a given instruction ISA and operating system with a given set of libraries and syscalls. If there is something else you need to make 'effective use' of the product that isn't either provided or made availible by a disinterested third-party, like a server component, vendors should be required to be up front and in your face about that.

This ^^

We do not live in a command economy. It is not the role of congress to decide what business models are appropriate. It is the role of congress to make sure free citizens are able to make informed decisions.

What is really need here IMHO is good warning labels like what is placed on a pack of cigarettes.

WARNING - This software does not function without access to components not included, with no certainly of future availability or access pricing.

WARNING - This product contains digitial rights management, the license terms represent an open end RENTAL agreement, revocable by the issuer not a sale.

Require those to appear DIRECTLY above the check out button for online sales, and be on the face of boxes and printed manuals if they apply.

That supposed newer software has fewer vulnerabilities than older software.

Broadly speaking that is likely true, you python backed REST service with SPA front-end, is not probably going to suffer from memory saftey issue like the C based CGI program it replaced. I'll grant you that, but I don't see any evidence at all out there to supposed it is not as target rich in terms of authorization/authentication/business logic flaws as anything it replaced.

I don't have experience with BOA but I do have system experience in other megabanks and I can tell you most of them have a front-end/backend architecture where the system of record that actually does settlements has quite a lot of isolation in front of it and separately enforces transaction rules. If for example you found an IDOR in the web banking application and you swapped your account ID in an internal transfer for an account not your own which you discovered by whatever means as the funds source to one of your other accounts as the destination, it *might* let move the money. The system might treat you like you have the money for the rest of the day. So you might be able to pay other people within the institution etc (where they can roll it back) or take money from an ATM. However when the backend processes all the transactions from the day to do settlements it will be REJECTED by some old hunk of COBOL or maybe...Java..

They will clean it up and come after you.. That is real reason a lot of these bugs don't probably get exercised. It isn't that people using the public components of these systems don't see interesting things breeze by their browser consoles or even burp suite instances, they probably do, they just know even if it worked they are 100% going to be caught; and their Jubilee would last about a day before turning into something that looks more like Revelation.

I meant to say "What really smells is the why DIDN'T the pipeline/workflow"

My question is how do they actually know anything is fixed?

Fundamentally hiring contractors to write a lot quick patches, has the same problems as having AI write a lot quick patches. We are talking about systems that have man-years of development and maintenance in them newly on boarded contract workers lack the context and social authority to make invasive changes.

They only way you could get thru a really large volume of scatter shot patchwork across the enterprise is if you let people read a bunch of AI summaries of the issue, and work from that. That then leads you with a lot of code reviews and merges to do, as the new bottleneck those people also need to understand what they are looking at to really be sure it is right, so again what do they read an AI evidence summary and just sign off, if not that is just the next bottleneck?

What really smells is the why did the pipeline/workflow just have claude-agents authoring the patches too? I think I know the answer, Anthropic probably told them 'No' even though really it is the smallest and after all the analysis work is done best specified part of the job. Real architects don't get blame the framers, when the building collapses because the dimensions of the materials were unspecified, and real mechanical engineers don't get blame the lather operator when the crank shafts wear prematurely because they did not account for unavoidable heating while machining and the effect it would have on the metal surface. That is what Anthropic wants here though, they want to be able to say it was the guys writing the patches and the people who approved them that screwed up, even as their faulty tools fed them bad information and reviewers were handed an impossible volume of work.

This seems like a massive CYA on the part of Anthropic and it is really disingenuous. If it works they get to claim they are heroes that enabled what would have been impossible to achieve before, if it leads to any serious problem, its the fault of those 'contractors' and or the reviewers who did not take their responsibilities seriously, without mention of how unrealistic that likely was.

Try GPT-OSS or one of the 4-bit quanitized qwen3.8 variants

Sure that is a tiny expense compared to salary. However $200 a seat is still quite a lot of spend if you have 1000 employees or so.

Now suppose for 800 of those 1000 you could put a *slightly* better Ps on their desks. Maybe the dollar cost on those is $1200 more than basic mini pc to run a browser you were buying them anyway. Figure you replace those at most every 3 years, you are already ahead! If you can stretch that five years way ahead. Don't like the capex, and prefer opex for accounting - lease the PCs

Bonus your are not sending your data to the AI labs, or paying even more for ZDR or whatever upsell option where they pinky-swear they won't swipe your stuff.

This step one in the inevitable campaign against open models and FOSS agent/harness systems.

These bit AI labs are better but for Joe public gpt-oss/qwen3.8/deepseek/granite4 are good enough for a lot of stuff. All of them will work on $600 GPU installed in PC from this decade. The open models will only improve, the layered specialist models will become more efficent. The GPU hardware and memory prices will come down eventually.

$200+/monthly subscripts just are not going to make economic sense for the majority of personal and general office worker users. - That is unless Anthropic/OpenAI/X can keep self hosted AI out of the public's hands.

You think that is really more of a marketing stunt to be employed beyond the race capture all the big pharma contracts before OpenAI does? I don't..

This ^^^ much more succinctly stated than my comment above.

Once the change volume is so large no 'people' would ever do bisect there really is no point in having it. I don't think it is 'useful for the agents' either because they might as well just run the tests, consume stack traces and fix the glitch given the way they work and how they have to bring the repository context in to make the fix. All wanking about with 400 rounds of source control operations does is burn more tokens.

For vibe coded projects, might as well go back to 1988 style and do your version control like tar -cvf myProj.1.tar myProj ... tar -cvf myPraj.2.tar myProj ... once an hour :-). When something breaks call do a diff between the current repo and the last one where changelog.txt says the feature was implemented, to narrow the scope of the debug operation.

Interesting how these guys are not dog flooding their own stuff.

I have seen a lot of OpenAI training material recently and Anthropic materials that seem far more designed to set tokens on fire than accomplish everything.

Notably everything it encourages you to do is around building 'workflows'. They almost always heavily utilize source control (especially git). With a lot of dedicated agents that because they are dedicated have to re-read the repository content every step of the way thru the CI/CD pipe. It is almost like they are trying to get their customers to set as many tokens on fire as possible.

The other effort part of it of course is to build a lot of CYA gates. Where 10 different people have to sign off on things they were supposed to 'fully review' but realistically because AI is removing them from so much of the process and the entire point is to do more faster they can only ask more AI some questions about things and hope, so it all gets pencil whipped. I think this actually to make sure that no mid-level manager actually gets in trouble. After all the moment some Director Of Product development gets called on the carpet and loses his quarterly bonus, they might actually say my teams will not be using Codex to do ... in the future, but that won't happen as long the blame can be laid upon some fantastically over burdened test engineer or project architect. OpenAI and Anthropic probably know maintaining the asymptotic growth in token spend to justify their datacenter investments means helping 'customers' ensure that if they footgun themselves with the products, they are always blame the people and the fix is always add more AI.

It does raise a lot questions now doesn't it.

We'd have to decide what has person-hood as well. Like does the model have person hood or the agent. if it is not the model but the agent, what are we allowed to do to the agent.

Can I change the model from Fable to Opus, or do I have to get the current agent's consent first?

What If I don't need the agent anymore. Can I delete chat? Is it "my laptop my choice?"

Right; that is really what this is about. Nobody there seriously thinks pile of matrix math has feelings.

They just don't want their training data poisoned.

There is also a lot of other work that it can do really well.

I was asked to create a little one page process flow chart for some stuff my team maintains. We had all the documentation for everything as handfuls of markdown files in each code repository. The thing is not complex. I could have opened Visio and created a nice looking chart in probably 1/2 an hour to an hour.

Instead I told Claude to do it. It was done in seconds, took be me about five min to look it over and conclude there were no major errors, incorrect over simplifications, or serious omissions. Another few min to propose some minor edits and then it was done.

Now we have nice executive level one pager to quickly explain to anyone business side roughly how the system works, rather than a collection of technical documents i have sit in a meeting with them and go over. No it can't do everything. Yes there are serious problems when it comes to authoring code etc that will quickly become serious problems with any project where the person doing the vibe code does not have real experience and understanding as far as software development.

That does not mean this stuff isn't really useful and valuable. My advice to the people screaming claude/codex/etc are not good tools is rethink that or you're going to get left behind by someone who probably isn't half as skilled as you are but isn't refusing to use tools that make the job better. You're that guy inserting assert()s and printf()s into code every other line and doing 25 build-run-test turns while the rest of your team has moved on to an debugger and and IDE that will let them step thru. Seriously that is who you are right now.

RAM will get cheaper at some point. There is money in memory manufacturing right now. There is also a risk the chip makers see that the demand will taper. If the demand actually proves durable, I think it will at this point, they will decide to meet the market; because if they don't someone like Zukerburg or Elon really will decide to build their own chip fab without the help of TSMC if that is what it takes.

In 1982 you're PC had 32K or maybe 64K of memory. Today it has 32G or maybe 64G of memory, more if you are an enthusiast or self employed using it for specific work loads. I don't think it is really unreasonable to expect home desktops with frequently be equipped with a 1TB of memory by the middle 2030s. Which is the point that good enough model you can run at home will be Fable class at that point. I think we can also count on at least some efficiency gains over the dense models mostly being used today, so getting their on single PC is realistic.

Will there still be hosted models in time sharing data-center environments sure but they will be packed with IT services or back ending massive operations like facebook, not answering "why didn't my cake rise" or "Please review this stack trace, the uncaught illegal type conversion should not have happened, the dataAPI should never have exposed retainageAmount as a string, the record should have been copied to rejected_inputs blob store and skipped, why did it think "Chris.S.A" could be parsed as a float? Please to no propose adding an argument error exception handler at presentation layer, the data should already be strictly validated by the dataAPI, if we have a type problem here we don't want to swallow the error and there is no reasonable corrective action to give us accurate results and a proper audit.".