I know this is just one tiny piece of the omnishambles, but: can't github sidestep the "you have to tell us what kind of hashes you have at repo creation time" by effectively deferring "git init" in practice until it sees what's being pushed? There may well be a good reason this wouldn't work...
I head a much, much smaller open source project. Since the November Singularity we've been seeing at least six responsibly reported security advisories a month. However, this last month we had 22 unique security advisories. Our project has been built with adherence to the OWASP Top Ten Guidelines and other best practices from the beginning. But software is hard and AI is thorough.
Each month, we fix them all in our monthly maintenance release and disclose at that time. We fight AI fire with fire, and hand-review, of course.
So far, we can keep up. One hopes this is possible at the scale of the Linux project, which assuredly has more humans and more AI to throw at the problem. But team size does not scale linearly with interested audience, and potential bugs do scale with codebase size (and other extremely important factors, like code quality, at which the Linux team is assuredly much better than we are).
("November Singularity" is a cheeky reference to the arrival of Opus 4.5 and "good enough" coding models and harnesses generally.)
I wonder if August of this year will be remembered like that too. The very first "opus like" local AI model came out this August (Qwen 3.8 Flash Next). I've been running it locally since for real programming and I consider it pretty much the same as opus 4.6 in coding ability (it lacks a bit in the factual knowledge area). It even exceeds opus on some tasks.
I've tried every hyped "open source" model before and all including latest models bigger than 1T parameters are pretty much toys.
This is the first one that isn't. It can't be overstated how huge of a deal that is. No more reliance on Anthropic.
Running this model to do real work is still not cheap. I run it on a pc with 6 rtx3090s and 192GB of RAM (and I use 90gb of that ram for KV cache). The model is entirely on gpus. It runs at 55tok/s 1500 prefill for one user at a time, and about 35tok/s 650 prefill per user for 5 simultaneous users. It doesn't seem like much until one realises you manage your own kv cache. You ca leave your sessions in cache for as long as you want. You can save them and restore 200k sessions a week later in a dozen seconds.
What many people don't realise is that usage of those models skews extremely heavily towards input processing. My claude code usage is about 1.3B tokens input per week and only about 8M output. On claude code I get 80% cache. At home it's more like 95%.
If this progress keeps up, and we get a fable quality model in a year in under 200B to run at home... Those "frontier labs" will be renting all of their gpus per hour not to go bankrupt.
I am using qwen3.8-27B-UD-Q3_K_XL on a 5080 16gb card with 16gb of system ram at around 43-45tok/s with 65k context. I am using that model to set up containers on a proxmox server with two b70s and 96gb ram. The Q3 model implemented 10 different chat models, 2 image models, and 7 web based harnesses so I can compare. It can rewrite any part to improve it.
qwen3.8 is more than capable for software dev. The gemma models were terrible and fell apart during compaction. I think as long as the llm can test the results, you don't need anything being offered by a "frontier" model. The cloud AI is going to be used by people unable to run their own and they will eventually get squeezed on price.
The one tip I could give is compact before starting new steps or any action in the plan that is different than what was previously worked on. You want to manage what is in the context and don't want unnecessary work history details filling it up. You can always ask the llm to list the current plan, then compact after and do it more than once until you get the compaction <30%. This will be fixable by the harness that can choose better times to compact.
You don't want to start a new phase and have it compact a few minute after starting. This happening over and over again seems to potentially cause issues for long running sessions. Compaction slop that screws up what is in the context.
I can compare what I use at home vs paid models like astra at work and the difference is mostly meaningless.
It was. That's when I stopped coding most things by hand. The difference in what I could reliably get AI to do for me in February 2025 vs February 2026 is just massive. I immediately became a huge advocate amongst my peers for going all-in on automated engineering because this curve is about to get very steep and if you're not staying ahead, you might get left behind.
There are two types of AI users: those who chase the rabbit and those who do not. Some people bounce from tool to tool QuantumLeap-style hoping that maybe the next tool will be the big thing to solve all their issues. Other people use AI to do actual work. Once they find a tool that works, they stick with that tool until they feal a need to upgrade.
It is like people fishing. Some people go out and catch fish with the tools they know will work. For other people, every day at the lake requires a new boat/rod/lure. They spend more time figuring out how to use their new toy than they do catching fish.
AI is becoming a more and more powerful lever that lets you move greater loads per application; it is in a real sense giving you more leverage. But the lever is difficult to use effectively, and the methods for using the level change every week or so.
> methods for using the level change every week or so
hmm doesn't mean noob will become better? if what I'm "learning" about AI is going to get deprecated every week... then it doesn't make sense to "keep up"
Here's how I think about it. There's two different things "knowing how to use AI effectively" and "knowing how to leverage effective AI to improve your project".
1. Both are multipliers on skills you already have. A "noob" will be at a disadvantage.
2. The second one is a complex blend of technical skill, domain knowledge and human factors (knowing your user-base, knowing your product/project, understanding UX/DX/whatever) that you probably will always have an edge on.
Because improved models seem to increase, not decrease, the gap between what you get from really expert supervision (prompting, steering, hand-corrections along the way, etc.) vs what you get from fairy-dust and wishes.
It requires skill to prompt the AI to do best possible work. I have senior colleagues that produce horrible slop and others that always produce great results. Managing the context, knowing when to stop the AI. Knowing what to question, what to "trust" in is a big deal.
Also knowing what models are good for what. There was time half a year ago when Google genuinely had a better model than everyone else. I used it for everything and 3 weeks later they lobotomise it (sorry "optimised") and I went back to opus...
I think Anthropic is like a drug dealer, giving us the sweet sweet drug for free (I don't think our $200 a month subscriptions even cover the electricity for our use) and the time to pay will come very soon...
I expect this subscription will cost $2k a month. Will it be a normal increase? Or will the "enshittify" existing models to the point you'll pay $2k to get fable 6 to do what opus 4.8 did fine in July 2026?
I was referring to the amount of people in the future who might be employed at today's engineering wages, and the differential between those people and the average employed engineer today.
What will that differential be? A large component will be social reinforcement: generational wealth, connectedness, and such. Things like merit might take more of a backseat. So people who do not have the necessary social capital may be fighting each other for very limited amounts of positions.
That is the steepening of the curve for people like me: I was homeless at 16 and finished high school on my own, was given a full ride to LSU, grants, room and board and a job in the Comp Sci department, but lost all of it after an immature and vindictive high school teacher illegally modified my grade in a core class in order to fuck me over. I didn't have parents to back me up at the school board and make things right.
Instead I suffered through years of homelessness and had to find my own path into the industry by starting companies with friends and doing all of the engineering. Since then I've led multiple teams, made some connections, shipped a lot of cool stuff and bring to the table a wealth of experience and a generalist skillset that is both wide and deep. Yet, I too wonder where my place in this changing industry will be once things settle a bit. Probably less engineering and more focus on business development.
The flipside though is as you've said: The fruits of engineering are more accessible than ever to the layman, and individuals can currently possess an unprecedented amount of agency and leverage. I think that is amazing and am fully behind it. I do know that it means the process of renormalization is going to be very rough, given the similarly unprecedented rate of industry change these technologies are bringing.
I think this is both true and untrue. For a long time, I was an AI skeptic, perhaps even a hater. A chauvinist for writing code by 'hand.' But it's become very difficult, as I've gradually migrated to AI-authoring of code, to go back to writing code by hand and retain the same velocity.
Part of this is certainly that my hand-authoring code skills have atrophied, sure, but my workflow has also radically changed. Previously, I would spent a lot of time and focus on a single work item, and only context switch to other tasks whenever I would wait on CI or a long build. It meant that I spent a lot of time understanding one thing at a time, and interruptions (forced context switches) incurred a massive switching cost.
Now, having moved to largely AI-authored code, I find myself necessarily working on multiple threads at the same time. This means I can meaningfully progress each of those threads in parallel, with a much-reduced overhead on context switching, since I don't have my head down focusing on all the details of the work. And if the task really demands it, I can still stop and focus on one thread to sketch out the code manually, think about the concepts more deeply, etc.
It's a very different workflow, and there are certainly downsides, but the upside is that the rate of which I've been able to put up good-quality PRs has measurably increased. It's not quite 2x, and it's certainly not 10x, but it's definitely noticeable. I do understand a bit less, but there was always more work than time to understand things in full detail. I guess only time will tell if that missing understanding was actually vital to the long-term success of my work.
yes that's fine, i have a similar experience. but there is a difference between saying what you did, and the type of AI religious fundamentalism where you got "converted" when truely good AI coding models revealed themselves to you, and then you go around trying to save those who would otherwise be "left behind".
Well it's a good thing that isn't what I said or implied, and that you instead smugly misinterpreted my comment.
The person you're replying to had the decency to ask me for clarification; for you, I'd suggest brushing up on your reading comprehension and learning to respect the rules of this site, which include interpreting comments in their best light and focusing on positive, substantial contributions instead of negative, inflammatory posts.
Again, I'm going to refer to the advice I just laid out for you. I'm not responsible for you and I don't need to cater my words to your lack of reading comprehension.
Seems to me we need tooling to do automatic offensive security as soon as a new frontier model comes out, with quickly turned around patches using the same frontier model. Rinse and repeat. Virtuous agentic security loop.
Isn't that part of the cloud AI business model now? Businesses have to pay for early access so they can weed out any new bugs before the model goes public. Which is kind of crazy, because you are paying for early access to protect yourself from other paying customers of the same cloud AI model.
As soon as a new model drops I point it at one codebase I have and ask it to do a security audit, look for bugs, check for optimizations, things that are over-engineered, etc.
Every single time I've done this it has found at least one serious bug or security hole.
wonder how much this can easily speed up the malicious-contributer attack. where someone suggest a security fix in a extremely obscure and irrelevant code, but the fix actually adds a new condition that then can be exploited elsewhere.
I wonder how many choices you can give this thing in multiple choice response mode. I'm guessing you could give it enough choices to produce Turing complete programs one symbol at a time when running in a loop, or to hold a conversation when given a vocabulary as the choices. It would be particularly hilarious to just let it choose the next ASCII character of output in a loop.
My guess is that due to its design there is no support for prompt caching, as there would normally be no reason for it. So the performance of my idea would probably be appalling as every step in the loop would reevaluate every input and output token. But it would be interesting to see the outcome.
When so many people talk about companies going with React "because AI knows React," it's interesting to see Shopify draw the opposite conclusion: AI "knows" all major platforms and frameworks, so at a certain scale it makes sense to let AI handle cross-platform development as a translation problem.
Modern LLMs evolved from translation models, and they still seem to work best at translation-shaped problems. Even if you are asking them to translate specs to code, or code for system A to code for system B.
In my case, I added SQLite and Postgres adapters to a formerly MongoDB-specific CMS, including support for a largely compatible API, "in one wild weekend..." followed by lots of verification. That was only practical because we already had a large test suite. But it was still a task that would have been out of the question for our team size before Opus 4.6 or so. Again, it was very much a translation-shaped problem.
There are quite a few CMSes that do static builds natively. If you hand one of those to Claude Code, you can get a more flexible and maintainable result more quickly. You can also point Claude Code to a CMS starter project in folder A And a vibe coded static site in folder B and pull them together.
That being said... if you're the sole author of your site, anything goes and yeah, you probably don't need a proper CMS. I certainly built my own share of 100-line Perl static site builders back in the day.
Wow yes keeping a wiki up right now is a tall order. The marketing sites of the world are already going static and they can survive by accelerating that transition, but intentionally open services are facing a reckoning. I wish you good hunting.
Still an achievement, just funny.
reply