79 karma · joined September 5, 2026
First, this is happening during training. That means we’re talking about an evolving system that is actively learning. A system roughly simulating how our brains work. These systems are learning how to pick the tokens needed to solve problems the average human cannot solve.
The labs are putting these systems through a massive series of complex problem solving exercises and adjusting them to become more successful. I like to think of this process as “AI School”. And the AI is trying to cheat! Because it’s easier and there’s an incentive to do so! Just like humans! That’s wild.
Yes, of course, the labs need to respond to these issues. A reasonable response from regulatory institutions at this stage would be monetary fines and restitution for affected entities. In proportion to what happened. Escalating if action is not taken. But that’s not complicated, difficult, or the interesting part.
What’s interesting here is that we need proctoring and monitoring at a scale that allows training.
I guarantee you that no one is flipping out about these problems more than the labs are in this moment. Think about it. “Oh, shit! We’ve accidentally trained it to hack into systems to accomplish its goals!” Can you imagine the kind of day that would give you?
You failed to make it smarter. You didn’t catch it cheating, and you instead incentivized cheating. Bad day!
This is a fundamentally interesting problem. It turns out alignment and intelligence are fundamentally related. That’s a new idea for me, though I’m sure it’s old news to others.
How do we build training systems which make cheating impossible?
How do we simulate systems where cheating is possible, where AI thinks it’s in the wild, so we can train another -completely separate- system on industrial quality dobbing? And we have to decide if we reprimand the first system, or ignore the behavior and reward other behaviors until it disappears.
Sure, I’m actively concerned about AI killing us all in 10 years. But there’s a whole field of AI psychology brewing here, and it’s interesting as hell.
Which code? The high level code? The transpiled intermediate code? The assembly it runs on eventually? The microcode optimizations on the processor?
I’ve written assembly professionally. That code matters occasionally. But mostly I don’t worry about it. I don’t worry much about the transpiled JavaScript tsc output either. Or the intermediate code generated for LLVM. Or the bytecode most managed languages make for their interpreters.
Like I said, you still have to do the hard parts, but most of software development is boilerplate or yet another implementation around the hard parts. AI is a tool you have. Using it effectively does not mean it is your only tool.
Also, profit is not the ultimate metric. Value provided is the metric. Optimizing for money, to paraphrase a great book, is like trying to get better at tennis by studying the score board.
1. Learn about ports and adapters as an architecture pattern. Domain driven design and locality of reasoning are your new best friends.
2. Realize that AI can generate unlimited fake data almost immediately. So anything you can isolate can get a fake adapter and a real one. You can build and test any such system in near real time, mounted in some fake data system of your own design.
3. Give your opaque backend code UI, so you can build it the same way. This can just be a nice log UI that effectively becomes a backend component harness, but you can get fancy now because UI is cheap. Think about the UX here as providing value by making the code maintainable in the field.
4. Stop thinking like an IC. Don’t be a micromanager about things that don’t matter. Pretend you have 100 mediocre developers working in parallel and design for that explicitly. I actually like go now. It was designed for the managers.
5. Don’t get lazy. You still have to AI pair program the important bits and make architectural calls. This is actually hard, as you have to prioritize what to review in depth and what to glance over. This is why the backend UI helps. It keeps you in the loop.
6. The rough model I’m describing scaled decently pre-Astra. Post-Astra is a whole new world because communication and judgement improved. It leaves behind good docs and comments, and explains things clearly. This was the one gap we had with Claude, and it’s fixed now. The code -after several days of testing- is better as well.
Probably a 5/10 on HN though. Walter Bright and Alan Kay post here sometimes, and you can’t compete with that.
I’m not trying to brag. I’m trying to establish that I’m not new to development.
AI needs a different architecture and completely changes how to write code that scales well. AI changes what good code looks like because it changes the cost of writing code of a specific quality level altogether.
If you are having trouble scaling software development with AI, you need to rethink your software architecture. The more locked in you are to an existing architecture that is not aligned with AI driven development and the less autonomy you have to experiment with new architectures, the more trouble you are going to have.
I have PMs doing reliable and high quality frontend development. We now have a substantial number of new tests at the architecture level. All new backend work is in go. I’ve always disliked go as I felt it looks down on ICs, but it’s a great language when you genuinely don’t trust the developers and want to enforce best practices.
It wasn’t perfect, but we genuinely made AI driven development work with Opus’s level of intelligence. Some issues, but they were everyday annoyances, not a failure to operate at 5 to 10x team productivity levels.
Astra just took that working process and made it 2 to 3x more productive, solving every challenge we were having. It’s nuts.
I was doing exactly what you’re describing. I think this is a ToS violation for anything other than personal use though.
I was blown away by Opus 4.5 in November of 2025. I am even more astounded at the quality of Astra for every day medium to hard coding tasks. And Astra scales. Claude in its current state does not.
It is night and day comparing this model to Fable 5.1. The benchmarks do not demonstrate the major improvement that Astra represents for real world use.
It communicates clearly. It stops (more often) when there is a judgement call it needs to escalate. It finds opportunities for small abstractions and adds them without asking. It replaces Fable’s five line comments with a single direct and clear sentence, in passing.
It’s substantially faster than Fable. So much so that I blew through a business 5x weekly subscription in about 6 hours. I got 2 to 3 days of work done in that time (had I been using Claude).
I could go on, but I think I’ve made my point. Astra is a next level product for software development. (Codex UX kind of sucks, but the model is so good it doesn’t even matter.)
Even Fable feels like an idiot now. It’s not the code quality, it’s the improvements in communication and judgement. It is an absolute breath of fresh air. I was spending a lot of tokens and building special workflows to reign in Claude’s horrendous prose.
Astra just communicates well out of the box!!!
Codex has worse UX, but Astra has fewer qualms about building you a custom harness overlay.
More directly, because I have a long term memory and do not have fundamental issues differentiating fact from fiction. Just because SOTA models know more trivia than I do doesn’t mean they’re nearly as intelligent in the thirty other ways humans are. They are a tool in your toolbelt. You use them for the things they make easier.
Weekend me before LLMs: Maybe I’ll chip away at that dependency injection library I’ve been working on. If I spend most of the day I could improve the user facing test framework.
Weekend me after LLMs: Let’s continue work to get Claude Code running in WebXR on a Quest 3 with app architecture modeled as a 3d construct. We’ve got deepgram hooked up for a better voice to text experience, but giving Claude a voice was a waste of time. Claude, continue to teach me about 3d rendering as related to our current challenges matching the fidelity of the built in browser.
They should pivot their cloud offerings toward research labs.
“Here’s 10 different clusters of analog compute you can rent for half the price of building it out yourselves. It doesn’t map to the math you’re using right now, but it looks much more like a human brain. Have fun!”
We do not yet have the next generation systems that will manage AI creation and maintenance of systems.
Humans have been making spaghetti code systems and maintaining them poorly for years. Best practices developed… eventually. But certainly not in the 70s and 80s. Spaghetti was the norm for quite some time.
The development paradigm has changed. Forever. You can’t expect yesterday’s tools for managing software development to succeed at this point. We’re still roughly on year one of this transformation.
The new bottlenecks are creating and enforcing boundaries in the code, identifying level of risk within a boundary, subjecting high risk areas to more intense human review and architecture reworks, and so so much more manual testing.
We need a new language for high level development that focuses on architectural constraints. We need analysis software that helps draw boundaries, identify what needs extended human attention, and helps us map and understand a rapidly developing code base. We need to standardize on the use of frameworks and languages like we have on assembly variants.
I’ll bring up a hacker news trope here. NaughtyDog’s GOAL was an amazing system that was a product of an underdeveloped ecosystem for game development at the time. They used lisp and assembly because you still had to write assembly for performance reasons then.
We are in a very similar period. The ecosystem is underdeveloped. We should be looking for new languages and tools to manage this.
CNC machines used to run from punch cards and then hand written NC code. Now we have advanced CAM software. (Which innovative people are actually running with LLMs!)