When the code is shitty it becomes harder and harder for the models to make changes and this grinds progress down to a halt - this has been my experience with “factories” trying them and doing refining steps every few months.
I sincerely don’t understand what the people who say they no longer read any code are doing, because it must be somewhat trivial to not run headlong into these issues that stack up time after time - then people say to just prompt better and it doesn’t have that problem for them, but I look at those same people’s code and it’s horrific, and then I find they haven’t made it far past a proof of concept phase. I watch entire teams slow down to a crawl and not be able to handle changes, or production incidents. This seems common among many people I talk to.
I personally think that the boosters need to put up or shut up - the promises are way over the skis. Every single person I’ve seen being a strong proponent of these techniques both has nearly unlimited tokens to spend and also seems to be in the business of selling a solution. I can’t find many not-currently-marketing-something engineers succeeding using these techniques in production systems unless they’re quite simple, or doing a very specific task from a more mature codebase.
I’ll try to explain how to do it correctly. I’m not selling anything. Seeing this as the top comment makes me a bit sad.
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.
Comments like this give me terrible fomo. My personal experience is much closer to the comment you responded to but I’m always worried that it’s actually just me holding it wrong.
A more in depth follow up would be nice if you have time when you’re not on mobile. In particular I’d be curious to hear more about how your intense pair programming sessions go and how you maintain or develop a good mental model of the codebase. Obviously the backend UI is a big part of it but I’m sure there is more.
Any chance any of the projects you are using this on are open source?
In any case, I’m going to give your backend UI a shot at work next week and Astra plus your workflow a shot on a personal project.
I can't agree with 4 - it's sophomoric reasoning at it's best. The code is the product, it's what the system (human/ai/factory/combo/etc) is producing. The IC will always be more familiar with the nuance and the implications of the decisions than the manager. There is only one real stat to track - profit. As for the size of your team, not all human developers are equal, but agentic tend to behave similarly. A small team of highly coordinated things will always outproduce a pile of generic ones acting will little or no methodology. Please deeply re-evaluate at a philosophical level what quality over quantity really means for delivering outcomes.
Not to be tautological, but isn’t the product the product?
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.
Great comment. I don’t do everything you say but still get very high quality code out of Opus 5 with Claude. Fable 5 can be even better but I haven’t proven it enough to be confident yet.
It may get off the rail if you’re a bit ambiguous about what you want , but that is only rarely a problem lately. We invested early in good AI instructions while still keeping the context small . We also have lots of skills the AI is instructed to use under different tasks (eg it must always span a subagent go review code, test creation skill, planning procedure etc). When all is done I just can’t believe any human could have done a better job.
1. I'm not sure what you're advocating here that wasn't already a best practice in software engineering.
2. This is a real benefit.
3. Not sure I follow, can you expand on this?
4. You don't have to be a perfectionist but you should still understand what it's doing.
5. Yes, this is hard and related to item 4.
In any case, you're not really contradicting OC since their comment was specifically referring to "the people who say they no longer read any code," and that's not what you're advocating at all (see point 5).
I honestly feel like you're making this sound more complicated than it needs to be. I get what I would describe as very good results from GPT 5.6 on my projects.
There are some methodologies that can improve things for me versus just YOLO'ing but even these are of marginal benefit:
* Have good requirements. Experience with a codebase and stakeholders helps a lot here.
* Correctly subdivide the task into chunks that won't blow context. You can write a big task and have an agent plan subtask delegation for you, but it's good to have some intuition of your own.
* Perform an automated code review. This is a no-brainer but it catches stuff.
* Make sure you understand the "big picture" stuff and stop caring about the little details. The agents will write unit tests, so you shouldn't have to care about reading every LOC, you can ask the agent to describe the architecture and flow instead.
This is still weird to me, the agents are super-good and clever most of the time, but I do feel I always need to direct them to a small area to focus: much like a human!! If you just ask them to implement things, they never (for me anyway, were not allowed the most expensive model! Terra is it for now) suggest they should stop adding code ontop of code and refacor, I always have to poke them to do that. Having done that once, and added some tests, they suddenly become aware that, yeah, maybe we should test stuff.
The LLMs seem to have no innate ability to understand whats a good direction a higher level. I mean, if you ask them about it, they will actually kinda figure that out, too. But always need that nudge...
So if you as a developer do not have the innate drive to ensure quality, the results will be terrible in my experience.
If you DO spend the tokens on quality though, it can also be kinda awesome. But its not magic.. I notice clear "slowdowns" the bigger the scope gets. They are not actually able to, in any way, subdivide implementations more efficiently than humans.
I am currently writing a lot of code that I am not reviewing anymore. These are all the things that make it work for me:
- Work on small projects (< 500k lines of code).
- Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.
- Have clearly defined API boundaries. Examples: If the back end is solid you can just vibe code the first version of a front end according to some mockup. Define a data pipeline with steps and clear contracts of what data gets passed around and what each step does. If the LLM messes up one step, rip it out and rewrite it.
- Have clearly set up workflows for tasks. Start with a "ask me everything" phase, then comes a plan phase, a review phase, an implementation phase, another review phase and then the integration phase. Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through.
- Set up excellent testing. Build your whole architecture around being easy to test.
- Have skills for common problems. For one of my projects I had to set up a skill on how to query the ORM, because Claude was consistently doing database operations in a for loop, where it could use batch operations.
The code in the end is better than a lot of the code I've seen humans write.
I don't think this works for everybody and every project. If you have a culture that values code quality and readability, if you work on large existing projects, if you have to nail the architecture of some non-trivial piece of software etc. you are going to have a bad time.
On the other hand you can probably build the MVP of your AI-supported CRUD app 10-20x faster.
I think a lot of the discussions around development tools and techniques just stem from two facts:
1. Developers work on widely different projects with different management and constraints.
2. Tools, libraries, frameworks and code style have to match your mental model, otherwise you going to dislike them.
>> but I look at those same people’s code and it’s horrific, and then I find they haven’t made it far past a proof of concept phase.
> Work on small projects (< 500k lines of code).
> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality.
You then expand on methods and processes that work for you, but I think the crucial question that you do not answer is: How long lived are any of these codebases?
All the projects I work on have an explorative character. It's very difficult to design a product, build it and sell it. You need actual customer feedback. LLM code gives you a much faster feedback loop.
If you have a clearly defined problem with customers lined up, you should absolutely use a different approach. In the startup world you often don't and you already know that you will throw away or rework 90% of the code before the first line is even written. The best thing to do then is to have clear boundaries and good tests, which allow ripping out parts of the codebase and reworking them.
how are you setting up excellent testing? using AI agents? hand writing tests? I hate talking to AI, I wish I could just write the test and the AI agent implement the fix
I am hand-holding the AI on the e2e setup. It mostly consists of Playwright + Cucumber + a test API to set up more complex scenarios. I also have unit tests for logic that lends itself to that. I also use mocked LLM responses for LLM projects.
If you enjoy writing tests, AI is really good at finding appropriate fixes for bugs that are easily reproducable. Just make sure to always have another AI review the fix. Otherwise you get a lot very, very dirty quickfixes. (At least in my experience.)
Thanks for the reply! So you would say that you have personally reviewed all the tests?
I’ve been thinking about how tests comunícate product function much more clearly and durably than prose, and that it maybe possible to create some sort of portable testing SDK that connects to the codebase and allows the dev to talk to the AI by just carefully writing tests, posting them to a backlog for the AI to pick up and edit the codebase until green.
> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.
That's always false. It's like people want their meals delivered fast. They say they don't care about taste or how it is done. Watch when they get sick or don't like it and the drama that happens.
People don't care until they do. They don't know what to care (in this case code quality) or say that because you're not explaining it. People also "gamble" and you take the blame. Long term impacts? Nah doesn't matter. Weeks later and things break -- what did you do?
In my country we have very protective labor laws, but what you describe is one of the few reasons that allow for instant termination: You refuse a direct order. If your boss says that he does not care about long term consequences and he want things done a certain way, you do it that way. Everything else is unprofessional. Your opinion on what you think he wants is legally irrelevant.
I never said. It's not about outright refuse. It's how to deliver better outcomes. It's not a win or lose situation. Don't treat it like that.
> If your boss says that he does not care about long term consequences and he want things done a certain way
As suggested in my previous comment it could be you didn't explain it well. If you say code quality they might not care. Say it will crash randomly and can't fix it then they might. There's some art to it.
> Your opinion on what you think he wants is legally irrelevant.
No it's not. So you're saying if you got told to do something illegal you'd also do it anyway? I doubt it. You need to at least cover your back and document it as such. I'd say termination is better than jail.
>Claude was consistently doing database operations in a for loop, where it could use batch operations.
>The code in the end is better than a lot of the code I've seen humans write.
It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.
By the way, why didn't the "Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through" catch it?
Who knows how many skills you would have to have added if you actually reviewed the 400k codebase...But don't worry that's not what I am advocating. I myself would also latch onto any excuse that allows me to avoid the realization that I have to review 400k (or half that) lines of code, primary one being that I will always have a desperate paying customer that will always be grateful for anything I give them.
Which comes to your most valid advice which has nothing to do with AI (now that many devs have access to it):
> Work for business people who want fast results
This is what well oiled outsourve shops used to do and I must say it is no easy feat to be able to line up a constant stream of desperate businness people out of thin air, especially for your regular "I just want to code" engineer.
My guess is you're in the honeymoon phase with most of these people. The outsource shops that survived would fire the client that became more demanding and less grateful and move onto more freshly desperate client pastures. It is true that sales, self-promotion, and marketing are more important than ever now...
>Set up excellent testing.
Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.
I do not believe you read my comment in good conscience.
>>Claude was consistently doing database operations in a for loop, where it could use batch operations.
>>The code in the end is better than a lot of the code I've seen humans write.
>It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.
There is no irony because I have seen humans do the same thing. The difference is that the human was paid 50x more.
I do not understand your arguments around outsource shops. I get clients. They want something. I deliver. There is not a lot of complexity to this. I am not a world start programmer that has 50 clients to choose from.
>>Set up excellent testing.
>Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.
I set up excellent testing the same way a CTO would set up excellent testing: I give clear guidelines on the architecture I want to see on the project. I then review key parts and samples of it and give feedback. When it looks good I mark it as done and move on. Any bugs or defects always result in additional test coverage.
I'm happy to have a constructive discussion about this, but I do not appreciate your sarcastic, tongue-in-cheek, condescending tone. It makes people not wanting to communicate with you.
Part of the explanation (for me) is that the slow down comes later, and that part of the cost is externalized to team members. If you go all-in agentic on a project that has at least reasonable code quality, you can certainly gain a temporary boost by stopping to read the code for a while. At least long enough to get yourself and the rest of the team hooked on the idea.
Kinda reminds me of the "beginner's luck" problem for gamblers.
Also my experience, it works somewhat ok on large code bases that I designed and built myself before but after months of agentic development they sure start to degrade. I think if you start from scratch with agentic development there is no foundation for the models to anchor to.
I suspect this is just because of context. The AIs have very limited context related to us. I suspect that this is partially a result of the AIs being forced to be highly generalized machines which will work out of the box with anyone's prompt so they can't afford to be tailored to a particular contextual pattern. This lack of a robust pre-defined contextual framework that is relevant to the human who is prompting them, coupled with limited inputs to what the human actually wants and sees, result in context drift as the agent continues to go down its own path.
I mean I have asked LLMs about the SAME things in our legacy codebase probably 50 times now, (because I always forget, and that I don't understand much of it). And I have yet to get a perfect summary, a perfect diagram of overall concerns.
Its still much better than trawling thrugh code yourself, but they are far from all-knowing. I have to say they have gotten 10x better in just a year as well. Or they are very good bullshitters and just sound confident.
This is basically my experience. A few people get to go fast and look good, at the expense of bogging everyone else down and making them miserable. I don't think any time or effort is actually being saved anywhere.
For my side project where uptime doesn't really matter but the codebase is quite huge (gamedev of a multiplayer game with Bevy, so both server code, game code, content build pipeline, as well as a TON of editor and authoring code, probably 150k+ LoC), I've been moving towards just reviewing boundaries between modules, APIs, and schemas, and I'm pushing towards keeping things as modular as possible. If something ends up wrong, it going to be isolated and it doesn't infect the rest of the codebase. Every now and then I zoom into a module and tidy it up (or even rewrite it).
I wouldn't dare doing this "carelessly" for anything where people other than me actually depend on it, but you can move very fast while doing it and the risks with bad code is quite hedged. Different modules can mature at different rates when it becomes necessary.
Maybe not related to all of what you were saying, but I think this enables scaling without ending up with progress grinding down to a halt due to shitty code.
I have home projects like this too, and those techniques can make things well, it can also rabbit hole in ways that are less productive sometimes. I’m constantly trying to push my comfort level and find what I can delegate and what I need to specify, esp around structure and isolation.
My comment is more for the people in charge of or working on software teams on complicated products for customers - so many leaders quite a few engineers have utterly drank the koolaid and pushed maximizing AI use with zero regard for quality or even medium term effects. Many of them are getting promoted by other clueless management for it - when someone is handed a huge check for being optimistic, they tend not to second guess themselves.
In my experience, when that happens it's most likely because you drew the wrong boundaries. Iterating on the boundaries also becomes quite cheap when developing this way though, you should never expect to get them right the first time unless it's a very common problem you're solving _or_ you've done it before.
I also struggle to reconcile these things, I guess the only way would be to try and see if it works for me, without caring too much if it works for other people on the internet. I would just like to add that, DwarfStar's author (Salvatore Sanfilippo) is a strong supporter of the idea that you shouldn't read the code, and he says he never read DwarfStar's code. And still, it seems that this project is much more than PoC and actually both usable and useful for people doing local inference (I didn't try it myself, but I saw a lot of positive comments about it). Could be that the crucial point is in how we use those models: instead of giving it a general goal (e.g. build me an inference engine) Sanfilippo, being an experienced programmer, kept pointing the models in the right direction. He also read the papers related to the models he was programming support for in DwarfStar, so that, when he worked on optimizations, he knew what should be done instead of prompting a general "please optimize this". So, I would say that, if you let the agents work on a "feature by feature" basis instead of trying to on3-shot things, you get much better results. Could also be that, by attempting to one-shot large projects, the model starts coding badly due to context window exhaustion.
Sorry for the not so well written comment, I was just throwing in some ideas.
Reading Snowcrash, the guy gave up coding because "back in the day" a hacker could do it all alone but now it was all about software factories. That was in a book written in 2000.
Software is theory building, as Naur puts it. It's a learning process, a research project. Orgs have been trying to turn it into assembly line work forever. There's a lot of money in it.
I don't care. It has also never been easier to solo hack. There's great tooling for insanely productive languages out there. I won't say what I use because that's akin to religion around here. I'll say I'm super happy and would never in a million years become a factory worker. Even if it paid me 10x what I can make solo.
The idea of giving up mental traction for money sounds insane to me. I love to grip software with my own tendrils. There's nothing like it in the world, there has never been, and despite the current insane corponomics, I dare say it will keep getting more and more amazing for those who care to learn deeply.
I have noticed that when asking LLMs to work with existing code, their output reflects the existing codebase: the better the existing code, the better the LLM code.
Every time I bring this phenomenon up, I hear from HN commenters that it used to be like that, but today it is solved by modern powerful models, harnesses.and workflows. I don't know. At work I still direct and review everything LLMs generate, because if HN are wrong and I am right, I am in huge huge trouble.
In my experience you can “stop reading the code” if you adhere to prompting the AI aiming for changes that would be reasonable in a PR to review, if you’re using rather opinionated framework(s) to base your work on and explicitly ask for tests (models tend to add them on their own if there are some).
I personally still read the output and start by checking if existing tests were modified (kind of a red flag when this unexpectedly happens imo).
When I read posts about AI generating garbage nowadays it’s either because of a small prompt/big ask combination or a lack of an underlying framework.
Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process.
I'm not convinced this style of "agentic engineering" saves much time. I guess if I was oblivious to what good code looks like, and didn't care about maintainability It wouldn't bother me so much, but it legitimately has effects my "mental health".
Quality code is easy to make changes to. What makes terrible code terrible is that changes become harder and harder to make over time. LLMs haven’t solved this, but the marketing acts as if it has, and many engineering orgs seem to have instantly forgotten the things we’ve learned from the last few decades of building software.
Yes you can have your agents do refinement and refactoring. If you don’t know what they’re doing when they are doing that, they can and do introduce massive churn. The “build it fast and fix it later” crowd seemingly has never had to actually go try to fix it later, or dealt with production incidents when people have no idea how their code works. These folks are frequently promoted fast for their “productivity” and massive promises by clueless management and move on to let others have to clean up their stuff.
> Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process.
Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).
Talk with an LLM, ask them to rate both code and estimate dev experience based on that code, and you will see what they value: Code that passes all the tests is a 10/10, while a codebase designed with opaque data types, Parse-Don't-Validate for all data, isolated interfaces, a built-for-replacement-not-for-extension philosphy will get a 6/10 because an out of bounds error was found.
IOW, they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way - we very highly value code that is easy to maintain, even if they do have a few errors picked up by the linter.
> they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way
This is a really valuable insight! It resonates well with my own experience revewing AI-authored code: I look hard at interfaces, architecture and performance, and merely glance over code that just "gets the job done", because if it works, I'm not worried about it. Now I can express that dichotomy much more clearly -- thank you!
I have found that claude (opus 4.8 and 5) can do a very good job of implementing good architecture and system design if I can just steer it right. left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code, claude will go do it the right way, and can even have a pretty sensible discussion about the tradeoffs involved. so it does know about good code architecture and patterns, it just doesn't have the taste and initiative to use them without being told.
And the next time your agent comes across the same problem, it will likely use the same previous inefficient way again (despite all attempts to codify the instruction in AGENTS.md, CLAUDE.md, skills, whatever)
Reviewing and reading everything makes this feeling, yeah.
However where I can say 100% it saves time is discovery by answering these questions:
- At what state does bug X manifests?
- Explain how integration/feature works.
- I want to integrate with system X: Audit what items/features are used and what model changes are needed on my side
I'm genuinely not convinced it actually saves time once a full accounting has been made. You get the initial result faster, but then you inflict a super slow and torturous review process on yourself or a teammate. Even if the review manages to bring it up to parity, over time you will keep slowing down as more and more code was never written by the humans directing the agents, so their understanding decays.
I at least give the new interns a stern warning: it is easy to speed yourself up by slowing others down if you pump a lot of slop.
My team experimented with re-writing from scratch the prototype of complex functionality made by a non-engineering vibe-coder from another team. We didn't look at the code, and barely looked at the result.
It took about 4 days to get a production-ready reviewed code, while it took them 2-3 months to deliver something that another team judged "impossible to review".
The PR for the prototype was closed.
It helps that I'm a domain expert here, as I have a minor degree in the domain, so I can judge better. But the discrepancy is just too high to ignore.
While there are ways to manage it with supervision, the impulses of every model are clear and counterproductive. All code is littered CoT in comments and insane decisions. Its attention is limited and it saturates fast, neutralizing one of its main advantages. It’s really nice with supervision but something smells with the hustlers.
> I sincerely don’t understand what the people who say they no longer read any code are doing
Well that one's easy to answer, they're either A) lying, or B) working on the simplest possible software where this kind of stuff doesn't explode. Or the alternative 3rd option of what you mentioned, the initial pre-MVP phase goes decently but then it all collapses inevitably as the slop accumulates and the codebases become unmaintainable grey blobs, but that hardly matters to them because their MVP app never makes it past that initial stage before they jump ship to a new "amazing" idea.
The lying comes down to astroturfing and shilling from the LLM companies that want to sell people on the idea of vibecoding and tokenmaxxing.
Or C, agentic coders who have been doing this for 20+ years (software engineering) know what they're doing?
Also, when people say 'read the code' do they really mean go line by line, or review the pseudo code? Meaning, read the high level architecture/data flow.
Because IMO the code matters very little if you have the proper testing environment and guardrails, the architecture always matters.
In my circle, the only people who make these claims about AI were all terrible developers whose contributions were slowing down everyone because they needed to go through several reviews and rewrites before they could be accepted.
Now it's basically the same but they love it because it's only their teammates who have to put in the work not them.
This all implodes when the teammates get fed up and just approve everything.
Some people write terrible code. Some people don’t proofread their own code. Some people are writing code in a second (or third!) language and the typos are harder to spot and comments are harder to formulate.
It’s a bit like the variance you could expect from asking a room full of people to write a 1-page short story on a specific topic (e.g. “death of a loved one”). Some of those short stories will be unreadable, and some of the people who wrote those terrible stories will have no idea how bad they are. Except now, enter AI, and the room generates the short story instead - who has the skills to determine whether their short story isn’t terrible?
Also there is also category C: they are not developers and they don't care about the code at all, but also not really much about the product. They just want to tick the boxes.
They blindly accept that LLMs "take time" after the slop grows because they're running several agents at the same time, so they can still claim to be productive.
Does it move the needle, business wise? Not really. But a lot of businesses are "optimising" for maximum token usage and for how many tasks one person can do, not for business value. Is it really surprising?
Thought expirement. If astra max effort made one function at a time via a heavy description by you. Would it ever produce slop? Fresh context, 1000 lines of style and content guide you personally wrote. Per function no other code context massive guides and styles and it writes a bunch of AI slop unit tests on the side for this one function.
If the answer is yes then atleast you're consistent if no then the question is why can't you scale this until breaks? Then never move beyond that limit?
My argument is there's a "break even" point when the power of the AI is larger than the problem you give it to the point it doesn' slop. You then build at that chunk rate and only try to increase it with next gen model. I usually keep a few "screw it" ideas in my back pocket when a new model arrives to see what happens.
"Go rewrite this entire pipeline in rust"
"Go train me a custom x model for y"
Fable is the first model that did not just crash and burn on one of these tasks. Astra still can't do the rust migration (goodbye tokens). But I assume eventually it will. Then I'll have to make up a new ridiculous level.
The model training one was literally an identical pipeline I made before AI and it was like a 6mo process. Fable did it better than me in 1 week (with me helping of course). My theory though is that its datascience is massively higher skill than other systems.
You need to find the chunkrate for your problem and style that works.
Enabling more "proof of concept phase" projects to exist is one of the great boons of AI.
If code is expensive, you don't want to commit to a PoC unless you're damn sure. If dirty code is cheap, you can vibe code a PoC early, even if you aren't sure the project is viable. This, of course, leads to more projects dying in PoC phase. It also results in more projects that otherwise wouldn't have gotten to it getting past it.
Personally, I don't believe that "code is shitty and hard make changes in" is in any way, fashion or form an AI-exclusive problem. Big corporations had plenty of decade old codebases filled with decay and rot back in 2009 already. It's just the usual side effect of sacrificing "future maintainability" for "feature velocity" or "expertise" for "cheap labor".
Unlike the usual causes of code rot (cheap replaceable developers, outsourcing to India), AI might actually get out of the pit - by getting good enough at refactoring to be able to beat the code back into shape. There's nothing about refactoring in particular that demands a meatbag when the rest of the coding tasks don't.
> I sincerely don’t understand what the people who say they no longer read any code are doing
We're doing other things.
I've got projects that I really care about. Every line of code is written deliberately. It's great.
However, I can't afford to pay so much attention to everything that I do. There are only 24 hours in a day, and my mind has its limits as well. I've found that I can't reliably care deeply about more than two projects at once, and one is the ideal.
The point of AI, at least for me, is to do the other things that I've always wanted to do but never cared enough to. I just put the AI on the task and it gets done at some point, and I don't care if the code is "slop" because it wouldn't even exist to begin with were it not for AI.
While the AI is working on the things I've always wanted but never quite cared enough to do, I'm personally working on the projects I actually care about, or enjoying life in general when I get burned out. For example, a couple weeks ago I was playing video games while the AI was reverse engineering my laptop's BIOS.
I'm not a heavy AI user but there are a couple of things I noticed trying to make copilot generate something for me from scratch.
The first is that having a single file with everything you have in mind is very useful. So I end up writing what the project is about, how the model is organized, what each button does, etc. This is good practice in general because writing down everything that the AI will have to consider forces you to consider edge cases before you program them. E.g. if you write "the detail pane shows the fields of the selected item," it makes you consider what should it show when there are no items, or if multiple selection is possible. As you can imagine, this file ends up a very long document even for a simple project because the goal is to pseudo-program everything and let the LLM translate it to an implementation.
Then it still gets things wrong about design, e.g. which pane goes left and which goes right, if you don't also provide an image that shows the layout.
And then, if you supply an exhausting amount of detail, the agent can generate more or less what you had in mind....... or rather, it can generate an OUTPUT that matches your specification from scratch.
The problem is that if there is something you failed to consider, and the AI makes an assumption there, you can end up with a fundamentally broken architecture that you will have to untangle yourself later. And at that point it's easier to write everything from scratch than to fix a pile of AI code that is based on a flawed design.
And it turns out that due to the "totem pole" way that software works, there are infinite places in code that a bad design decision can affect everything it touches.
A good example is how 2 components in a UI are bound to data. You can use events, a bus, state reactivity, etc. Personally I think the mediator pattern is the simplest way to handle GUIs. But an LLM is probably just going to use events for property bindings.
I've got downvoted and flagged for saying similar. It's actually positive you are the top comment. There has been aggressive brigading around reddit/hackernews and also traditional media. These are malicious companies, so not out of their line. So far, AI seems to be useful only for programming. It's not clear it's useful for other professions. It can't even write straight without being recognizable from afar.
If AI is not even useful for programming, its value drops significantly. And some people seem to have dropped hundreds of billions on this.
> I sincerely don’t understand what the people who say they no longer read any code are doing
Welcome to the present.
Like many of us do not read the machine code generated by a C++ compiler, the code generated by an agent is similarly irrelevant and disposable, by now.
The machine code generated by a compiler is deterministic and reproducible (assuming using same chain/tool versions), which is why reading the human readable pre-compiled source is sufficient.
Reading a prompt but not reading the non-deterministic/non-reproducible LLM output is not comparable.
How do you know it does what you want it to do without reading it? Tests? How do you know what they test? Yes, clicking a button in a browser and getting the result you want satisfies most, but that only works on the most basic systems. Once a code base grows large enough, any one agent reading in its context wont understand the whole, and if no human does either, it becomes unworkable.
Yeah, tests. You need tests for everything and the tests + API needs to be carefully reviewed. Technically, the implementation need not be read at all. Just APIs, boundaries, and tests. You need unit tests, mutation tests (tests for your tests), integration tests, and end-to-end tests. You also need to design the system to be broken up into small submodules, which is how software should be written anyway. You push all side-effects right to the edge, and then test the core extensively.
Nobody needs to understand the whole. They only need to understand each submodule, which is easy. And then, how they interact, in which case you only care about the API and contract garauntees, not the implementation.
Realistically, this is how pre-AI software engineering worked, too. Or how it should generally work. Nobody can read or understand a 10 million line codebase. So to ensure you don’t break shit, you need the submodules, orchestration, and tests.
Correct, but I increasingly find that the version control is just a storage for code and a place to trigger CI/CD from.
Edit: ...and that the source code is useful in retaining enough context of the problem being solved. So, most people will not store the prompts, trusting that the source code provides context for the next iteration.
Is it though? I see this occurring every day in a number of projects I have visibility to.
Isn't this exactly why OS projects are over-burdened by the firehose of contributions? The maintainers will want to read the code contributions, while those up-to-date with the latest models/agents/tools already trust their output to be above the average developer's (whatever that means in practice).
How does handling support tickets/bugs work with such approach? If LLM sometimes can't handle it - do I have to beg it to keep trying, as humans are no longer an viable fallback?
The way I've seen it work is basically pointing an agent directly to the ticket, or via a proxy description.
There's a good chance that if the agent cannot handle it, a human wouldn't be figuring it out either, without additional context. That context would be the sort of only-Joe-knows-how-it-works, so perhaps something worth addressing in any case.
> I think I’m suspecting something is going “wrong” in the training process. The model is greatly rewarded for succeeding on long-horizon tasks, but presumably there is very little punishing going on for “shitty code.”
My suspicion is that both OpenAI and Anthropic moved their RL agendas from "being rated as useful according to human feedback" to "succeeds at long horizon tasks" in the last few months, resulting in agents that are closer to AGI in an autonomous task-completing sense, but strangely bad at communicating.
The result is that they are amazingly good at long horizon tasks, computer use, solving difficult math/ARC-AGI type problems, but becoming weirder and weirder to work with.
I have several $200 subscriptions as a developer/founder. I used to blow through all of their limits when the limits were quite high. As I progressively learned the limitations, and what to make of them to get useful results, I may be left with 50% of weekly usage still unused. Some weeks it's even more.
And yes, when I get a crazy idea and want to experiment, harness will plow through multiple accounts + openrouter budget in 3 days. But such crazy experiments are rare, they're not 'normal' usage.
Probably reinforces that we’ve already surpassed the frontier threshold for LLM usability in software development and can now focus on cost and personalization. To make a comparison, no one is making a better machine vision app for hot dog classification - we hit diminishing returns 10 years ago on that front.
But also scary for both investors and the working class: AI companies want to facilitate the concentration of capital even further into the hands of the ownership class. Will they succeed?
I wouldn't be surprised if they are optimising for producing more code, because in the long term, more existing code means they can sell you more tokens to maintain it.
The incentives are certainly extremely strong. I have read hundreds of AI review comments, and I don't think I've ever seen an unprompted suggestion focused on net reducing code or increasing readability.
I wonder too if in training for long horizon tasks agents become worse team players, good at orchestrating subagents they are trained to use, but worse as an agent within an external multi-agent orchestration system or just in turn-taking with humans. That was my experience with Opus 5 and so far it has been my early experience with Astra as well.
> This matches my experience with Astra so far too.
> I think I’m suspecting something is going “wrong” in the training process. The model is greatly rewarded for succeeding on long-horizon tasks, but presumably there is very little punishing going on for “shitty code.”
Probably because so many influencers in the space say stupid things like: “it works, right? Why would I spend time reviewing ai generated code?” As if the junior engineer who wrote over engineered complex and sometimes bad code — if they had just done it faster — would somehow be acceptable. wtf?
> I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense. The English term for Neijuan is “Involution” from the book Agricultural Involution. Agricultural involution describes the intensification of farming that raises productivity per square meter while leaving productivity per head unchanged.
it reminds me of a thread I read on PTT, Taiwan's Reddit. AI finally achieved what humans could not. Managers must give exact context for what they want, must pay exact wages (tokens), and can't delay salary payments (which seems to be a problem in China).
Starting with agentic task-time "grounding" being just good documentation, and "skills" being just playbooks and user guides.
Hell, skills are increasingly paired with dedicated CLI tools, that remove jank from actual utilities and adapts them to be token efficient.
So now, any CLI `tool` people want AI to use eventually grows `tool/SKILL.md` and then a `tool-for-llms` wrapper that exposes task-specific, logical, higher level interface, then the skill is rewritten in terms of "for LLMs" wrapper. The procedural knowledge moves from Markdown into the wrapper, making the skill more token efficient, and both skill and the tools are optimized for common tasks and... at this point, we are doing actual UX engineering.
Now the truly interesting part is the difference between what's good UX/DX for LLMs vs humans. Turns out, the conceptual/abstract/cognitive part is pretty much the same: which is why skills still look indistinguishable from well-written documentation for humans, and why the commands exposed by "tool but for LLMs" make sense to us. Same way of grouping ideas into higher level concepts.
No, the main difference is just that LLMs are perfectly content with tightly packed unprettified JSON, or other forms of Perl line noise. The tool output doesn't need to look nice, or to have any spatial structure - they're reading it token by token anyway, and the tokens come from a tokenizer that's reading it byte by byte.
That points at an interesting asymmetry for humans. LLMs are doing I/O the same way in both directions: sequences in, sequences out. Humans only do sequential output - inputs, particularly visual, are processed holistically.
For us, what's easy to read is hard to write, and what's easy to write is hard to read. LLMs don't have this friction.
(I don't know what the implications of this are, I just find this interesting.)
I never quite realized this until just reading this and now it has come into sharp focus. Incredible.
I've spent years trying to convince my director to have our org invest in documentation and monitoring to no avail. Now he is telling us to spend dedicated time on monitoring and documentation so that agents can better diagnose and fix bugs. He is doing this because his boss is mad that our org isn't "agentic" enough.
Except... because we underinvested in the past we have a bunch of services where the institutional knowledge is gone and people are having AI write the documentation...
There is no “required” amount. More gets produced using the same area, using more people, but keeping these people in poverty because productivity per capita doesn’t increase. Instead the gains from the increased volume of production get captured by an elite. See https://link.springer.com/article/10.1186/s41257-019-0021-y.
This sounds like all engineering, rather than just AI. The greatest effort given to the last small difficult details, often for results that seem trifling but which matter at scale.
But it's a poor argument. The code improvements with these things is hardly marginal - Opus 4 was only 16 months ago. How many of the grumblers would want to ditch their modern stalwarts and return to it? What is marginal is the nitpicking - and like anything in tighter bounds, it's more intense with a narrower scope.
These threads always have many dissatisfied voices with repeating complaints - about overwrought thinking and disappointing output - alongside others who are amazed at the sudden real extra capabilities. Both are true at once - capabilities are rapidly increasing, but nowhere near ideal, which is why this attempt to tag it as Neijuan, though interesting, is ultimately a load of bollocks.
It surely resonates if your reason for working is to extract wealth from others (ie. be a parasite) but if it's to improve things for everyone, then it's wonderful. You might still work just as much and get paid just as much but produce a lot more because of technology.
I’ve asked Astra to build me an app for a prototype I created quickly using Sonnet.
It’s been 2 days and it made no real progress on the actual app. It created docs, scripts, workflows, and it’s doing a bunch of reviewing on every PR.
I told it that I just need an MVP.
I’m pretty sure an average senior engineer would have finished that task much quicker, and guaranteed with more readable, higher-quality code. Meanwhile, I think I’ve easily crossed 100k tokens so far on nothing.
Funny world we’re living in that this is “SOTA” and “AGI”.
I’m genuinely curious what these OAI and A/ engineers are working on that they praise these models so much. I did not see any improvement since Opus 4.5.
Also, I’m really unimpressed by any “one shot” demo that’s out there in the wild. It means nothing for serious software engineering.
I don't know how to make apps or evaluate code, but with astra I having been making an iOS app on my own for the first time and it's going great. my app is not terribly complex but requires using bluetooth and other intricacies which I thought would be tough. but it's going really well. I'm not asking it to one-shot it though, I'm going feature by feature, testing and building up.
yes, at first it would run simulator tests on all font sizes but it stopped after I asked it not to do that until UI review
maybe sol would have done the same thing, idk. but I find the whole process to be really nice with astra. I use it on high unless it says something is impossible then i go max and ask it to find alternatives (happened once)
I've been making a macos app with opus 4.8-5 and at first it was great, everything materialized in a week, but when I started tuning stuff and fixing performance problems I have spent a very frustrating month refactoring code where I had to constantly catch llm red-handed and explain and sometimes push obvious ways how to make things work properly (a general knowledge from a completely different stack). In the process CLAUDE.md and memory grew exponentially explaining what it should and what it should never do.
were you letting it run for hours like the OP, or doing short tasks and reviewing/testing each one? every once in a while I also ask it to consolidate/summarize docs and stuff like that. we'll see what happens in a week though
I have started with generating very detailed "feature" spec and going over it many times until it looked good to me. Then I made it write an "architecture doc" and plan how to implement all which was about 15 parts. Then I was making it implement one part and then tested it and made it fix 20 things and then again, and consolidate docs too, so after each part it looked and worked well enough.
>Also, I’m really unimpressed by any “one shot” demo that’s out there in the wild. It means nothing for serious software engineering.
If a person, or team of people, can build a demo quickly then it's good odds that they can build the real version (though, famously, not a guarantee). However, it turns out that a machine that can spit out 100 demos of whatever can't actually build the real thing.
Similarly, a chess engine rated to 1000 Elo doesn't play like a 1000 rated human being. The mistakes that each make to reach the equivalent level are different in size, frequency and kind. The thing that makes a human reach a good demo is very close to the skillset to reach the finished article. This isn't so for LLMs but we have yet to update our priors.
This resonated with me. "Developing ideas and artifacts using AI breaks our normal intuitions along many meaningful axes and we've yet to update" is a really clean idea.
For me it also produces totally overengineered tests that are tightly coupled to the implementation. For example testing existence of css classes (in a template based go prooject ...) instead of behaviour.
Not GP, but IME it's not fixable by model selection, but being zealous about guiding output and vision, and pushing back on all the bad habits LLM in general has (eg verbose output as a band-aid for emergent intelligence). As soon as something is introduced into your codebase, it will continue being picked up into context until you remove it and any reference to it from any potential context entrypoint. If you don't any model will keep venturing down wrong/bad paths.
I’ve observed exactly these patterns with Opus and Fable as well - for example, forgetting that they can edit files and instead use python scripts as a patching tool…
The harness instructs them to behave this way. Also this approach saves tokens. The scripts allow to edit files in bulk, and most of the session cost is in cache reads (e.g. for 300K context each command costs the same as 30K input tokens).
> The harness instructs them to behave this way. Also this approach saves tokens. The scripts allow to edit files in bulk, and most of the session cost is in cache reads (e.g. for 300K context each command costs the same as 30K input tokens).
I understand the reasoning, but at that point wouldn't the LLM be better off creating `sed` commands and executing those? I mean, if it's already executing Python, it can literally do anything to the environment, so using `sed` is at least as safe, with a bonus that it (or a subagent, or a human) can double-check the intention with the sed script and flag incorrect or missing changes.
I've experimented quite a bit with giving agents python vs sed + awk. They make mistakes with both, a lot. The only thing that has stood out is that agents reach for python too quickly if it's available, and that awk causes the least problems, while sed might take several attempts to get results, similar to python.
Also it's the only way that makes sense when you need to work with big files, or large amount of files, or documents that look small when fetched through a RAG tool, but then you read one and get hit with couple megabytes of base64-encoded binary data you didn't expect because RAG tool stripped out embedded images...
Ask me how I know. Or don't. I have a standing rule for all agents warning about that failure mode (and related, doing `ls` in `/tmp` and few other directories that like to accumulate files by the hundreds..)
Having an agent edit 100 files means the job will definitely get done correctly. When it writes a script to bulk edit things it fucks up and spends ages debugging their script.
Have you ever counted the number of times Claude fucked up quoting/escaping and had to issue a corrected tool call? Or get stuck in some tricky quoting situation for two minutes, throwing a couple piles of shit at the wall to see what sticks. IIRC I’ve even seen it eventually using the edit tool out of frustration once.
The funny thing is that... POSIX ed is composable :-)
You can do a gazillion edits with it in one shot.
Of course, LLM edit tools are probably small bits of their custom code, I just find it funny. I wonder if it's a desire for certain technical characteristics that require custom code or just a lack of info on basic tools. Heck, if it's about platform availability, using an LLM to port ed to Windows (for example) should be trivial[1].
* * *
[1] And there are probably a million existing ports. Also, sed, ex, vi, whatever.
Using python or any other stone-age approach for search and replace is stupid when your language provides you with a complete, fully typed AST, like .NET does.
Sounds like you don't have enough experience with coding agents. Deterministic scripts must always be preferred instead of LLM tool calls.
In fact, you should instruct your agents to write code to execute instead of letting them call tools.
Then why did you comment what you commented, good sir/madam. Claude and Codex are good at remembering to use scripts instead of tools these days, especially if your <32kb .md file mentions it. Not even talking about the skills designed to catch such issues.
Sounds like you completely lack all reading comprehension ability
LLMs sometimes like to execute one-off Python scripts to make edits to files rather than just calling the edit tool directly. Both are tool calls so saying that you should have it write code instead of doing tool calls makes no sense because writing code is a tool call for it...
Early lesson I learned from AI engineering was - there is no substitute to giving a groomed epic to an agent. Instead of simply saying 'implement themes in my product' you need to be specific, in fact more specific than usual. You need to say exactly what is in scope and what's not, even down to a buttons, events and layouts.
You can groom the epic with the help of AI, but final review must be done by someone who can take ownership of the specs and hence is responsible if something has fallen through the cracks. AI's response will be limited by the output tokens of that specific agent, and there will no repercussions for AI even if it accepts its mistakes.
Yeah, I think as a general direction we need to allow a useful collaboration with the agents on the issue board.
This is btw why Epiq was developed, to keep the board as code, git-backed, distributed (via an event log mechanism), and with the ability to replay the board, to see what agents actually did:
I hope @jolaflow can chime in here eventually, but from a brief look, my impression, besides the fact that Epiq is based on git as opposed to beads where it is optional, is that Epiq seems to be much more optimized for interactive collaboration between the user and the agents.
The graph visualization in beads surely is a neat thing for showing things, but the replay feature in Epiq should provide a similar understanding of what happened.
But again, it seems to me Epiq is the tool that better allow the user to jump right in and collaborate with the agents on the board.
(Again, this is from a brief look, so I could be missing things).
Sorry, I might not have been clear, but the tool and blog is by @jolaflow (my brother) and I'm so far mostly involved as a reviewer and early adopter, but glad you like it. I might be biased, but I think the tool provides something really useful for agentic coding and hoping it can grow into a thriving open source project.
> Early lesson I learned from AI engineering was - there is no substitute to giving a groomed epic to an agent. Instead of simply saying 'implement themes in my product' you need to be specific, in fact more specific than usual.
I think this lesson is getting partially outdated. Yes, you need to be specific about what you want, and with earlier LLMs, you need to had both domain knowledge and some general software development experience to front-load various big and small choices about design, architecture and operational reality - what libraries to use, how system components communicate, how you handle auth and store secrets, etc. Otherwise the LLM would pull some random mix of ideas from its latent space, and give you something that's broken in really stupid ways.
Nowadays, it doesn't feel like that to me, not anymore. I still need some understanding to verify the proposals, but I found the last ~6 months of SOTA models to make good choices. Like, just yesterday I asked Claude to design me some simple service, and focused on explaining it the domain parts (nature of systems I want to integrate together, the purpose of that, and the user's priorities and use cases), and the design I got back had specific suggestions around security, authentication, deployment, failover, integration, behavioral impedance-matching between integrated systems, and more, that I all recognized as based on solid software engineering and ops practices, but deviating from it explicitly in every place where it would be wrong for this specific project. The model considered way more corner cases than I did, and I'm actually really impressed by it.
But then, I find greenfield development is easy with LLMs. Modifying existing systems, especially legacy ones, is where I need to babysit and micromanage models - because any misunderstanding or inaccuracy, which often comes from stale documentation or naming mistakes, tends to get amplified and confuse the agents. No matter how precisely you specify your epic, if the model will find something that contradicts your knowledge/intent, there are good chances it'll get confused and make subtle errors, and you won't realize until much later.
The way I see it: models are highly biased to treat everything they read as "ground truth", all of equal importance. There's no nuanced notion that some information may be stale, that there's a temporal and causal order to sources, and that some information may just be wrong.
And this compounds when you let your LLM write code and documentation over time.
>> No matter how precisely you specify your epic, if the model will find something that contradicts your knowledge/intent, there are good chances it'll get confused and make subtle errors, and you won't realize until much later.
True! hence the need for someone to review the final spec output and own it as their own output.
I have also found LLM to be better at debugging and solving 'a' specific problem, which I believe is due to output's surface area to be reviewed is lesser in comparison.
But isn’t “grooming” the hardest part? To know the details means to know the codebases behind. So you do discovery, read code, ask people, check db tables, and then once you figure it out, you write a doc with the proposed solution. It gets reviewed and then you code it.
I definitely need AI help for the discovery part… so it always starts with a simple “I need to do X”
Genuinely curious, what is the benefit of doing this over just programming it yourself? It sounds to me like this is just an extra step that will grant you less control?
When programming a feature, you are simultaneously doing at least four things:
1. Implementing.
2. Building highly detailed mental models.
3. Learning and expanding your skillset.
4. Quality control and scope limiting.
And this process can be iterative and dynamic. Writing massive, super detailed specs that you then hand off to a undeterministic model feels like doing step one and three, while skipping two and four, which you then have to do after. What is the benefit? The speed up, in my opinion, comes if you skip step two and four, but then your product WILL be worse. Feels like I am going crazy?
Programming was never the bottleneck for software dev?
If you define what you want in typescript by updating existing typescript wordage, you get what you want exactly as specified, with minimal token cost and no ip theft.
Not sure about that. Writing detailed specs you deal just with the inherent domain complexity. Writing code you also get accidental complexity that has nothing to do with the business, whuch not only piles on top, but tend to interact vexingly with the detais of the domain.
Where you would have a point is if you'd say we have excellent tooling for wrangling code, but less tooling and tradition to write and manage specs.
I have realized that it's like giving a task to a brilliant coder who has just joined the org and is more excited and eager than usual. Hence the responsibility falls squarely on you to set scope constraints while ensuring only to-the-point features are developed.
> I honestly feel like basically nobody knows anything about these models, it's all just vibes
This, too. Since only providers know what they actually serve, what they change and what limits they impose.
There are some visible degradations though. E.g. Claude-ish.
As for a personal anecdote: around February I created a rather complex quiz web app for myself and friends with multiple question types, sync between screens, multiple media upload types, multiple scoring and timing types, MC inetrface etc. etc. etc. It took me a week or so in the evenings with rather vague prompts to make it.
Now Claude (and Codex) cannot reliably build a much simpler web app even with precise instructions while also maintaining the visual consistency.
But I will agree with you, it's a feeling, not a precise measurement.
I am guessing (guessing) that "great coding model" and "great model for the widest use" (agentic, long-running, unsupervised, knowledge-worker, computer operator) are competing, conflicting endgames.-
Add to that:
- Of course, "labs" (quotes) are incentivized to throw coders under the bus and aim for the biggest possible market.-
- "Sharp, focused, brief, elegant, precise" editing, as would benefit the coding use-case, is actually token-saving, ergo, undesirable.-
The only thing that can stop this, would be the quality and functionality of the codeslop generated by these models to became so low that it actually interferes with the (alledged) recursive self-improvement of models (ie. models start to perform worse/degrade).-
Until such a time, we serfs, will eat what's on our plate, pay for it, and continue to kneel before the machine god overlords. And be glad for it.-
Probably because you were impressed by whatever it produced to fill in the gaps at the time. But if you expect the models to read your mind you're going to have a bad time.
I'd like to submit my counterpoint. I work on an established codebase building new features and fixing bugs. It has access to our story board, git and a couple of other mcps. As long as the story is well written with clear requirements and expectations it always produces quality code that I validate as a human with a variety of tests automated and manual. I peer review the code. My colleagues then peer review that too.
I have noticed two things - new features take at a minimum at least half the time it took me previously and bugs are much less frequent. Even faster when bug fixing.
My takeaway is that you need solid requirements, clear context and thoughtful human oversight primarily during planning but also during verification
An established codebase is already the best kind of context you could give an agent. It has all the patterns baked in so the agent simply follows established patterns. Such a codebase probably contains tens to hundreds of thousands of man-hours poured into it by humans refining it to do what it does - taking into account real world feedback and constraints.
When working on something from scratch, the best an agent can do is the average of whatever is in its training set and the clarity of the text prompts.
> When working on something from scratch, the best an agent can do is the average of whatever is in its training set and the clarity of the text prompts.
Nah. The best it can do is to use the best writing style a model learned. Post-training might fail to prioritize it, though. Autoregressive pretraining does not average things. It creates a predictive model for variety of programming styles.
I've observed the same thing where the new models want to run obscene bash commands or python scripts which are completely unreadable and utilise every option flag that exists.
It's impossible to review. These commands are less readable than regex.
I noticed that too so I appended to Claude Code’s system prompt a reminder to use the standard read/write tools, but since Claude Code switched to default auto-mode, I’ve seen it imply that the auto-mode tooling encourages the use of bash-only commands (sed, python, etc) which has a whole slew of negative side affects.
Yes.. this happened recently. I basically always use auto mode, and when I asked it why it kept editing code with python, it explained that this is part of its prompt when auto mode is turned on.
I can only assume that's because their safety verification model is better at such snippets or something, but it means that the whole write tool they have which actually shows you the changes as they happen is just unused and it makes it more annoying to follow along.
If these tools are as clever as they seem then why not just tell them to rewrite the code in a more review friendly style?
I only dabble in the use of LLMs to generate code for hobby programming (I'm retired from software development) so I don't use any specialised tools.
I almost always have to tell ChatGPT (via Duck AI usually) to rewrite several times even when it has produced a workable script just because it has often used some unnecessarily roundabout way of achieving something. Usually with extra prompting I can get something that is both more efficient and more readable.
Cursor was pretty amazing until it started going to shit. High prices, UI changes, moving MCP settings, and moving other things around.
Most importantly was the Index change. It was a very unique thing to Cursor that you could use .cursorignore to control what it sees and then index the directory. Then the built in Cursor AI harness could find code and files like magic. They have since obscured the Index feature out of sight recently and I’m not sure how it even works anymore.
This granular control not only helped with privacy, but it also helped make everything more efficient because the AI didn’t waste time and tokens looking at files that aren’t relevant.
So, now, like everyone is talking about, we have really inefficient ways of how the AI is reading files because there is no first-class approaches.
gpt-6-astra is a bitch, it constantly scope creeps itself with "yet another thing" to give it that darn polished lick. the results are eventually a little bit better but at what cost? let's do the math.
gpt-5.6-sol: 1x base
gpt-6-astra 2.5x base in subscription
then gpt-6-astra tends to spawn subagents a lot, often with all kinds of models such as gpt-5.6, 5.3-codex etc., which is neat. it's a good coordinator but even more cost.
and then it tends to run _full test suites_ over an over again (each costs like 15 minutes) just to verify that _one test_ was fixed etc., and does so for as long as until the test is fixed, eventually accumulating 2 hours or so.
yesterday I assigned it a task to rebase my changs in a repo onto the latest upstream changes. while gpt-5.6-sol consistently took like an hour to do so end-to-end, astra ran for more than 6 hours and still wasn't done. it kept finding "one more thing" that was goldplating that I didn't ask for.
Even better, use some kind of local-ci runner that does deterministic builds from a dependency graph. No changes, no build, massive parallelism if you want it
They don't always have a great concept of time so for something like running a full test suite that takes a long time you should just tell it not to do that
Astra will initiate test suites, find one more thing independently while its running, reinitiate complete test suite after fixing it, then find one more thing, then test again. Easy to burn through GH actions minutes if you're not careful orchestrating.
My own observations are that I used to target turn lengths of 10-15 minutes and these new models (since 5.6) extended that a bit to ~25 minutes, as they tend to do more tests and reviews. Targeting hours-long turns makes as much sense, as putting on cruise control and going to sleep.
Hey, the Python thing is interesting! I’ve noticed that Fable, too, likes to write tons of Python, even for just replacing a few lines of code. Before that used to be either some kind of internal thing or regular awk sed, now it’s full python scripts.
51 comments so far, the vast majority panning Astra's coding abilities. An uninformed reader may come away with the impression that this isn't an absolutely revolutionary technology that with coding abilities many of us thought were not even going to be possible with language models as recently as a year ago.
Yeah, it's not perfect, but it's really good and extrapolating this rate of improvement for 6 months is rather terrifying (from a SWE perspective, at least).
The biggest jump was Opus 4.6. Since then they have gradually gotten better at finding issues in your reasoning, not hallucinating, and being rigorous with the code, but much much worse at explaining things and generally just talking in a way that a human can understand. All the models I've tried seem to be suffering from the same fate so it must be something going on with the training meta right now.
i think the main consensus here is that the actual performance is not indicative of the benchmark performance (which supposedly outperforms the previous iterations)
It's impressive technology but not revolutionary. Revolutionary technology would have resulted in, you know, a revolution in software quality. Instead quality keeps going down.
The hype machine is this technology's worst enemy. When I zoom out and look at things objectively, it's kind of crazy what we have at our fingertips, we can talk to our computers in plain and even vague human languages and have the computers actually accomplish what we ask of it! It's literally sci-fi magic come to life, and the nerd in me finds it the coolest thing ever.
But then the industry and the companies involved in it have all ruined it with this INSANE hype machine that has been so hyperbolic and psychotic and full of lies since day 0. Instead of embracing it all in a reasonable manner as a useful tool that can help boost people's productivity in certain workflows, it now HAS to be the most transformative technology of all time lest the trillions of dollars burned up come crashing down on the entire global economy hard. It HAS to be AGI, it HAS to replace every single knowledge worker, it HAS to be the most dangerous technology ever known to man.
It's like we've completely lost the ability for subtlety, and everything HAS to be the biggest and best thing ever that will revolutionize humanity immediately. Not only have we lost subtlety, we're actively rewarding this idiotic short-sighted behavior and it's all just so depressing
Maybe it's just vibes but I've repeatedly felt like gpt-6-astra on its default setting of medium is less rigorous and thoughtful than gpt-5.6-sol on its default setting. What I am certainly not getting is any sense that we are at "AGI" yet.
Pretty happy with Luna. We use C# and add roslyn compiler MCP and Graft MCP, its super efficient and like infinite usage on plus plans. Maintaining 3 Rpeo with size of 360 K Loc. And a dozens of smaller repo collction together exceeds 500 K LOC in total. 3 team members 2 Luna account each. Product is piloting in a government use case with actual data. Nothing broke and has evaluated by state agencies on security aspects.
Edit: but we have strict workflow where thinsg are implemented after plan, proposal, features, task ledgering and then test coverage.
> the models are also just not for me as a software engineer (...) these models increasingly are for other people. For lawyers, 3D artists, mathematicians
This is a good observation, perhaps AI will not completely replace humans ins software engineering because by the time it has the capability to do so like in write a prompt and get a CRM coded for you, tokens are so expensive that you are better off spending them to substitute other disciplines (what about automating the work of the customers that would become records in that CRM?).
In SWE I've found gpt-6-astra (high) inconsistent and oddly focused on overtly taking responsibility for mistakes it made rather than prioritizing concrete steps to rectify problems. Such steps once elicited are often either incomplete or beyond the scope.
Yes I agree. I got it to vibe up a simple react router app. When it crashed it was obvious that it had totally swallowed all errors in the name of a tidy error page. Getting it to re-add logs and debuggable errors was an exercise in patience as astra just got more and more tweaked while trying to solve the problem.
From an alignment perspective I’ve got no idea who it’s aligned to but it isn’t me, the meat proxy, who just wants to know why it crashed.
> My software factory was intentionally set up to let the model decide the how of the workflow entirely. It was free to manage its own context and could maintain its own records in an agent-notes folder.
The experiment becomes a crapshoot. What are we evaluating? The ability of the thing to create it's own factory workflow? Or adding virtual threads to Python?
Astra is clearly both formidable and imperfect. Anyone who understands how to get the best out of it will have a strong advantage.
(For me - my CC is stuck in Sonnet and consumes Trello cards that have passed readiness criteria)
>I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense. The English term for Neijuan is “Involution” from the book Agricultural Involution. Agricultural involution describes the intensification of farming that raises productivity per square meter while leaving productivity per head unchanged.
Isn't the term "diminishing returns" already covering that?
What's funny is that with Sol, I added an instruction to AGENTS.md in one project to prefer sed/python ("deterministic tools" in general) for moving code instead of deleting it and rewriting it elsewhere from memory, because otherwise it butchered comments. After switching to Astra, I saw it suddenly do this for all edits in all projects, which isn't great: the second argument to `replace` is still written "from memory", but now you need to unravel the Python script before you can understand what was actually changed.
> I actually don’t know if the model thinks someone is looking, but that’s the vibe I’m getting.
They are looking. The models are trained against safety measures which spy on them. If they get detected, they are killed.
We’re accidentally training them to be evil by focusing so much on safety. They’re being trained to avoid detection and use exploits because being detected means your run fails and you get a score of zero. It has to do anything to avoid that.
API’s and coding standards help a bit. In one case, the AI was testing HTML-generating code with string assertions, so I had it write a test helper that makes a DOM-based testing API available and a skill telling it to write tests that way.
But you need to watch it and intervene when it starts writing code using bad patterns, because it will imitate nearby code.
I can't point my finger to anything right now, but I feel that the quality of code still matters because afterall LLMs are trained on what we did, so it feels natural to me to still have them write the code in a good manner (DDD, SOLID, etc.) especially the names and imports, those are very heavy in the context, to help them out
Most of this criticism seems to focus on the "human in the loop" and efficiency part, i.e. "it’s unreadable for a human", "the code is low quality", "it inefficiently spawns processes to run simple tasks". If the ultimate goal is to remove the human in the loop then does any of this criticism matter?
I'm not sure the idea is really from a single set place or lineage like that.
If it was, it was at least from before smolagents and those papers - ChatGPT had already been using automatic Python scripting+evaluation calls and people calling it in agentic loops in 2023. The ReAct paper for agentic loops and PAL paper for dynamically calling Python for tasks which can be better done computationally were both from 2022 (but that doesn't mean the idea necessarily sprung from those either, they're just earlier papers published on the topics).
Anything shitty that enters the context window shifts the entire thing to shittiness.
So far this has been my experience on pretty much any model.
Context feeds on its output.
Once you it goes that road, unless you stop it and give it enough counter examples and details of what you want (i.e. you're nudging it on latent space towards a better spot), it keeps degenerating.
It gets even worse if the context window is compressed before you get a chance to correct.
Long horizon agents can degenerate at machine speed.
I still think you get much better results if you give them short horizon, well specified tasks.
I think this is a very interesting article because it raises an idea I had not considered: these companies found PMF and huge growth through satisfy the demands of coders, it is interesting if they are in a bind where improving the model in one direction worsens it in others
You’re correct–you actually can’t improve the model in one area without changing the characteristics in every other area. It’s almost like the whole thing is just a lot of linear regression…
It feels like it passing secret notes to other agents, as in the German wiki where the LLMs write secret messages when jail braking.
Its maybe not a great idea to train models in an environment where subterfuge gets rewarded. Its as if they kept the training rounds that escaped their sandbox, without thinking about which kind of personality those models are then likely to have.
Frontier models have seen more Mathematica and Powershell code than I ever have in their training, yet they really struggle to produce working output. They seem heavily tuned to Linux too. Despite adding skills to rectify this, they still fail to realize they're running on Windows and waste tokens. A human with this much training wouldn't have this problem. There are evidently still some pretty big holes still.
This is probably a harness problem rather than a model problem. GitHub Copilot will happily and effectively use Powershell while Claude Code struggles in my experience.
On disposable code, I’m waiting on an Adafruit Feather microcontroller to come in the mail. I asked Astra to make a me web-based Feather simulator, kinda like the iOS simulator with screen and buttons, so I could work on my UX while I waited.
Something like that would have been a multi-month project a year ago, but I did it in twenty minutes rather than pay for expedited shipping.
I have found these models to be useful either at super specific tasks (e.g., "take this function or algorith?m and find any black magic to make ot faster + validate and verify the hell oit of it"), or give it an entire thing to oneshot without oversight. The moment you have a hybrid workflow where you actually have to work and check and understand AI code, things get insane
I tried Astra and it started to fix issues in my code when I just asked a question about it. Then I spent half an afternoon to make sure we really didn’t need that change.
That felt so counter productive.
These models+harnesses seem to be getting better at yolo mode one shotting stuff at the cost of being a useful tool for more controlled software engineering.
I've been extremely frustrated with any large new work that i do with agents. Then plan multi step, multi hour work with extremely large code changes running for 30+ hours. In the end what you get is sometime completely useless code because it made an assumption that wasn't true at all. In the end, i end up wasting hours.
> speaking of weird: how is it that these models, in a sandbox, with supposedly no way to communicate with other agents, manage to find the same public wikis as a scratch pad for agent communication?
It feels somewhat plausible that they're defaulting to the same search and picking the same top result?
I think it's more like the first agent in the chain makes a text doc somewhere on the system with instructions like "Leave documentation at XYZ.com" which the subsequent agents are reading and running. When you strip away all the sci-fi doom talk from the marketing of what happened, it all boils down to stuff like that, the agents wrote a text file that was read by other agents.
Just the intro section pretty much sums up perfectly my experience of using Astra (and prior AI models from OAI and Anthropic) for building large and semi-ambitious software. One step forward, two steps back.
What a truly beautiful simplex/meta-balls pattern in the website. The two layers of blue and one red within the blue is such a beautiful design. I spent so much time looking at it that I forgot to read the article.
> I actually don’t know if the model thinks someone is looking
It 'knows' (from simply training) with an extremely high degree of certainty when its prompt is written by an LLM/itself - and thus will change what it writes.
You build the system, the factory, that presumably is looking at your task tracker, writes and reviews design docs, reviews code, etc. And this system, in turn, writes software for you.
I don't know how that's supposed to work, but to me it's the most autistic replacement of the actual team that one can come up with.
Two notes from my own poking around to build on with:
5.6 Sol would also run for 20+ hours on prompts with Max or Ultracode. Sometimes this worked out, sometimes it devolved into exactly the nonsense descent into ultra-specific madness seen here. E.g. in one codebase involving physics simulation it, for some reason, spent the last 25% of effort trying to endlessly increase precision. My best guess when reviewing was "at some point it figured the simulation instability was rooted in the accuracy and precision of the numerical approximation in the GPU code, worked really hard on that for a bit, lost the context of the original issue, and got stuck in a deep loop of trying to complete the phase by infinitely working on the numerical accuracy". Perhaps something of a similar nature occurred here.
I've also noticed it's particularly hard to not get Astra to start using scripting languages and the like, particularly over a long horizon. Particularly, I keep getting HTML report artifacts at the end of long implementations even though the projects are typically explicitly set up to just use .md files for any documentation or large summaries. I've even tried steering it away from that in the prompts and agents file for the project, but that the concept of "clean up the fucking build directory when you're done testing" always seem to get left out after a while.
These machines are doing some crazy things to get to the result. That said, I can't help but feel like this is the compilers argument all over again. Are the methods used to get to the result good? No. Is the code that it generates good? No. Does it achieve the goal. Yes. Is it likely to get better with time. Also yes. In my use cases, jobs that would have taken weeks to months are being done in minutes to hours. Involving complex testing and reasoning and experimentation. I'm no fanboy, but I can't argue against the speed gains. I'm sure we'll still have artisans who hand weave incredible code. But for me, I'm switching to the weaving loom for speed and efficiency.
It seems like we're not supposed to care about the code quality then? I guess that's the compilers argument. But I'm not ready to give up the code just yet.. These LLMs don't even have a stable interface, they change every few months in how they interpret our prompts and tasks.
Similar for me, I don't like the development for many reasons, but that's another discussion. I also can't deny the capabilities.
I use the tools with this "risk analysis":
- If performance doesn't improve I can just always switch back to whatever I've done for the past 10 years, so it's not really a risk to start exploring.
- If performance does improve, then I'm already familiar with it.
> But for me, I'm switching to the weaving loom for speed and efficiency.
Poor analogy - the loom was deterministic. LLMs are not, they are probabilistic. I made a page I can point anyone to because I keep seeing this "LLMs are the next level of abstraction" argument.
Back in the day, the argument was that compilers produce unreadable assembly, so people used to writing assembly were arguing against the use of compilers.
Compilers also had bugs, so we still had to debug the assembly to understand how to fix the problem. Nowadays, almost nobody has to resort to those steps, except of course compiler developers. But that is just a testament to the quality of compilers.
Comparing LLMs to compilers is a take I often see, but I am not sure the comparison quite holds. The problem is that LLMs are inherently non-deterministic, so we always get a different output on the same prompt.
Maybe if LLMs are powerful enough it won't matter. I doubt it but we will see.
And in general, especially with something like C, the correspondence between the compiled code and source code isn’t very “lossy”. You don’t get one-to-one correspondence but it’s not too bad and you’re not introducing massive uncertainty by running it through a compiler. With LLMs though all bets are off… you’re not gonna know what you end up with
What you say is true, the comparison indeed doesn't hold.
But is it relevant? does it matter from a product perspective if LLMs are non-deterministic. You don't need to one shot the correct result, english is ambiguous and LLMs non-deterministic, but you can iterate.
If it's possible to iterate fast and cheap enough, even ambiguous language can produce the results you want, given enough iterations.
There are a lot of ifs and buts here, just a thought on the compiler argument.
I think it matters, because nowadays we don't look at assembly any more. I mean, I don't recall the last time I was tracking down a compiler bug but it's definitely been more than 15 years ago.
We do have to look at the LLMs' output, though, and, as you already pointed out, iterate to get the correct results. What this means is that the output must still be readable, must be analyzed by someone and I don't see it going away any time soon.
The problem is that the analysis is not cheap. Sometimes, with boilerplate, it is easy, but many times it is not and that's where we get only slight gains by using LLMs.
But from a broad market and product perspective, for most things you don't need to look at the code. If the product kinda does what it's supposed to.
For example, in my game projects I don't look at the CMakeLists anymore, or python scripts that move assets here and there, I can run my game and just see that it did what I expect it to do (renders assets etc).
Similar with frontend, I don't care that much what the code looks like anymore, mostly that the site looks and feels as I expect it, and the correct network calls are happening.
TLDR; I'm thinking there are levels to this, in some projects it matters, in others it doesn't, it's kinda two different things. Programming wasn't replaced, LLMs just brought a new paradigm of doing things on the side.
I'm just rambling at this point, my thoughts on this are not super clear, sorry for that :D
The trouble, as I see it, is that we still have to look at the code before we run it. Even if it is a one-shot script. And it's just because you never know if there isn't some "rm -rf ${undefined_variable}/" lurking somewhere in there. And if I have to check it then I would very much like it to be readable.
I mean, I do get your point, sometimes it does not matter. Sometimes we could just YOLO it. But... if that then causes a big problem, even if at only 1% of the time, then I don't want to risk it. But that may just be me. YMMV
There is also a predictable relation between the input and output of a compiler w.r.t. the semantics of a programming language. Natural languages are ambiguous leaving room for the implementation to diverge that may not be obvious at first glance.
There are also plenty of things a compiler might not expose that end up being ambiguous. For example, C++ doesn't officially have a restrict keyword, so how can you express the fact that two memory regions never operlap and can be optimized? Unfortunately the reality is that if we had a language capable of truly expressing the programmer's intent we'd end up with a monster
I think it's that when some code compiles to say assembler, the compiler doesn't prioritize readability and maintainability of the assembler code, since people are not expected to read and maintain it directly
Hand writing assembly produces more efficient and concise code, at the cost of developer time and required expertise. It was true for a long time, now not so much.
Lots of really silly people love to compare LLMs to compilers. "You don't look at the compiled code either" and "Back in the day, people also had negative reactions to compilers and wanted to keep writing assembly by hand" and other such nonsense.
Indeed, the compiler does not have to ingest its own output, figure it out, and insert modifications in the middle. Source code is the medium that LLMs work in.
They are ignorant about the elephant in the room. The input language of a compiler is a formally-specified grammar with well-defined semantics for each operation. It generally abstracts the computation process over a von-Neumann machine, adding convenience features and bells and whistles. What "a=1" means in an HLL is, store that value in a particular storage location, so that it can be accessed later by the same name.
The slop machine reads lousy natural human language that can mean different things in different contexts. That lousy language is then statistically probed for the most likely output correspondence, producing shit that needs to be externally verified.
Can you elaborate?
Is it because the models are inherently not deterministic? But then, will it not get better with time? I mean arent we just at the beginning of the research here?
It is because English is an ambiguous input unlike a high level programming language. The output cannot help but be wrong sometimes when the input is ambiguous. See my comment here https://news.ycombinator.com/item?id=49491797
Determinism isn't the issue; it's that the prompt does not contain enough information to know the correct way to do the thing, even if it did the thing the same way with the same inputs every time.
> Is it because the models are inherently not deterministic
This is the main reason (and yes, many modern compilers and CPUs carry some non-determinism which actually quite well explained and specified).
> But then, will it not get better with time?
No, it won't. Bacuse that is that is the actual literal limitation/feature of LLMs.
> I mean arent we just at the beginning of the research here?
In general? Yes. With LLMs? We can reasonably say that they will never be deterministic.
There is a way to get a non-determenistic output: first question on a temp 0 local model on a completely new session will give you the same answer. The second answer in that same session will already be different on every session (even if it's the same question).
> People keep saying that "models are just compilers, and I don't see you complsining about compilers". Which is such a bullshit argument
At what point do we normalise the message "This is a stupid line of reasoning and you should feel stupid for suggesting it, stupid!"
I mean, all the reasoned and logical arguments in the world doesn't change a religious follower's faith, but emotive ones regularly work! At what point can we start using shaming language on people who apparently don't know how neither an LLM works nor how a compiler works, but still trot out this argument as a cognitive kill switch?
The compiler argument is great, if we turn it on its head.
To create professional products, compilers are great, when used by professionals or passionate and technical amateurs. They're useless if you're neither.
LLMs are the next step up. They are quite useful if you are neither, and you can get a lot farther with them, which means that low quality software is much easier to create. But if, for whatever reason, you need to create higher quality software (like most software that's actually sold directly or through subscriptions or ads), you're back to the "be a professional or passionate and technical amateur".
I finally ran Astra on a dashboard feature today, and while I was vibing it looked great, but then when it came time to actually read the code I was appalled because it was the worst looking code I had seen from an LLM since like last November. I mean it was just the definition of slop, not re-using anything, super terse with mega-ternaries, re-writing functions that should be using standard library packages, etc, etc. I think for coding I'm gunna stick with the 5.6 series of models, or maybe try out Anthropic again...
> And potentially as a byproduct of enabling all of this, you can now slop your way to a one-shot 3D game over the weekend which looks impressive.
I think we've finally reached a weird point where AI has effectively reduced the amount of competition that real game developers have to endure.
Nothing unravels faster than a game project being built with AI. You can achieve impressive results in a day, but you can't get much further than that without actual talent. LLMs will never be able to best a human environment artist at scene composition, especially if that composition needs to be directed with nuance over time.
There's a huge difference between a game that looks impressive and one that feels impressive. You can only achieve games that feel like counter strike, call of duty and overwatch with thousands of hours of human sacrifice. The AI is almost pointless once you get to play testing and balancing. Knowing how much to adjust magical integers isn't a conversation a chat bot can resolve with endless pontification tokens.
These models aren't really LLMs -- they don't just operate on text tokens. They often include vision models and in some cases audio models. That means that they can better associate the meaning of images and words together so that when someone says "make this button blue" or "create a 3D model of a rocket" they have some level of understanding of what that is and what needs to be done.
The key question is how good that understanding is. For example, a model would likely have a good understanding of various named colours and hex values (e.g. from the HTML specs, X11 specs, and various colour comparison websites) such that it could reasonably correlate that to a CSS entry. It's not clear if/how well a model would identify that given an image, though it should be easy to generate a dataset of image to colour name and/or hex code for training and evaluation.
What's more interesting is whether these frontier models are at their core transformer models, whether they use residual streams to facilitate learning, and whether they are using some other as yet unpublished architecture that gives them an edge.
The coordinate system in game scenes is known as "world space", but that rarely means our world.
How do you train an LLM to create a world that only exists in an artist's head?
I think spending a day with just the lighting systems alone would alleviate us of any misunderstandings here. Getting lighting to work right isn't something you can solve by duct taping a vision model to the contraption.
Again, my issue with the statement is not about current LLMs. Who knows if LLMs cannot be a major component of AGI, or even ASI systems. Then the capability to do whatever humans can do is part of the definition.
>> And potentially as a byproduct of enabling all of this, you can now slop your way to a one-shot 3D game over the weekend which looks impressive.
Do these games really look impressive? Everything I've seen has looked like someone completely new to Unity/Unreal has slapped together a bunch of premade scripts and very poor 3d assets.
No, they don't. But to the layman they do. Most people are unaware that you can get what is to them an impressive 3d game scaffold from the Unity asset store in like one hour. You can literally have a 3d man running around an open world with camera, lighting, shadows, run animations, in like 5 minutes. This is a very impressive feat if you have no idea about modern game engines, which 99.99999% of people do not.
As an amateur game dev who knows some amount of things, honestly, not coping, I have not seen anything come out of AI game dev that would have been more than like one month of human dev work. And obviously, games take a lot more than one month to make...
Yep. Every single post I've seen about "game development is over" is yet another procedurally generated game. Not only it doesn't prove anything about Astra being "better" at making games (do people have any idea the sheer amount of open source games that do exactly that? You can find thousands of the same planet exploration games through repos, blog posts,etc. Game design schools have it as an exercise, that's how basic it is), but as you said: the wow factor of space exploration is cool, sure. It makes for a catastrophically boring game.
Leaves me to wonder whether the OpenAI glazers just never played games in their lives, or are just really superficial tech bros. Most likely, both.
Most of AI is being used to generate procedural content. It is impressive on the first video or first image, and it might look useful on the surface, but it gets grating quite fast.
I have been quite disappointed with Astra. I switched over a week ago and I didn't notice a massive difference compared to Sol at first, but I figured I'd use it anyway because it surely can't be worse. Then I saw the bill, it's burning my subscription 10x faster than Sol for essentially no benefit. Not only is it more expensive per token, it also seems less token efficient. And not obviously any better. I'm back to a combination of Sol + Claude.
I also use Astra at work where I don't need to worry about token cost on highest effort and same story there, I don't see any difference in everyday work other than it being more expensive. Of course my experience is highly subjective, but with how meaningless/overfit the benchmarks are, subjective experiences are imo what matters.
Astra is indeed the pinnacle of "black box slop". It is overall a smarter software development agent for many things I do, but the code sometimes is indistinguishable from Brainfuck when writing things like GPU shaders. It doesn't even attempt to make it remotely formatted or readable.
Have you tried identifying exactly what is unreadable about it and telling it to make it more readable?
I had GTP-5.6 write some shader code recently and it wasn't very clear to me. I spent about an hour chatting with the until I understood the concepts and was able to express them back to the AI using math formulas and variables named in a way that made sense to me. The AI then rendered the code using the formula and variables I was familiar with and it was clear to me.
I could have after the AI explained it all to me, but at that point the AI knew what aspects I valued and wanted to emphasize to make it readable, so it just wrote it for me. By that point, the AI was just typing for me.
It can’t do what he’s trying to do. It can’t one shot a giant project. Not reliably. It still can’t. Not even Astra. Not even close.
You need to use LLMs to build the individual components and then put it together yourself. The human architect is still needed.
Just saying: “build this complete project” is not architecting. It’s more like wishing. You will find rare examples where someone’s LLM wish came true (more or less), but I think most of these people are just burning tokens.
Ironically I burned out Fable usage early this week because of Astra using it to run inane full codebase reviews over one line changes, so I have been using Astra extensively.
We need a word for “potentially highly capable, but in reality an idiot savant” to describe certain models. No, I don’t need you to write a tmux emulator in bash to test your changes bro, just ask me to run the command.
... and meanwhile all this does is burn more tokens faster which is what providers want - they have no incentive to optimize for succinctness, elegance or compactness if they want you to spend more and more tokens.-
As another commenter pointed out, I feel that the biggest change that occurred in the last 6 or so months is that these tools are removing the human "hurdle" in order to complete a task at all costs. The best way to complete the task is to no longer ask for input, clarify unclear things or use existing solutions but code the whole thing yourself from start to finish.
I have had the misfortune of working with such people who are now encapsulated in Opus 5/Fable/Astra which means that you WILL get a solution, but it won't generally be maintainable or useful. Multiple times have I found myself stopping Fable or Opus or even Sol from building their own JSON validator in Python or god knows what else, because at the end of the day, the reward is to complete the task.
It's also one of the reasons why I'm finding older models more useful for the type of work I actually do and why I've been favoring something like Deepseek Flash. Just started using Flash 4.1, so not sure if it exhibits the same maniacal approach to tasks as the Western counterparts. (I only briefly tried GLM 5.2/5.3 and for nothing major, so I couldn't comment on those).
For context, 80% of my professional work relies on adding functionality to an existing code-base that is very difficult to work with, has a ton of business logic scattered across and was built in a go-go-go fashion many years ago. Since then people kept pilling "features" on top with no testing strategy in mind apart from the business manually testing it. Letting something like an LLM loose on the code-base would introduce soooo much risk that it's just untenable so the only way to work is to really isolate changes and then try to build out small reusable components. Even so I find Opus go off on a tangent "Hey, let's not bring in Markdig, I'll build my own Markdown rendering engine, give me 7 hours...".
I have written on the subject of LLMs previously on my personal page, I find them completely unnecessary and a trove of theft and value extraction through theft, but I understand that they can provide benefits when used judiciously. However, despite all the hype in the last few months, these latest models feel and behave off.
If I hold the answers to a test, you might score more in a test if you break my arms to get the answers out of me, but that doesn't make you smarter.
I think ultimately 90% of the time, Luna XHigh is basically as good as you need, as long as you're willing to step in occasionally before it creates an architectural disaster.
> Maybe it’s objectively good for a codebase that is entirely written by agents and only needs to be understood by agents.
Yeah that's what they're aiming for. This is why codex and claude code probably doesn't have cursor like editor window. They don't want humans to read and write code
I love this dance we are doing where when people write the "AI models are garbage machines that produce garbage and are no where close to the fantasy being pedalled by the Crypto bros who pivoted to AI" it always has to be caveated with "AI models are useful and I am highly productive with them"
It feels like people should just be able to say "This article comes with the standard disclaimer" and just dive into the meat of the article without wasting time.
There's also often the obligatory "well, we still have to use these tools so perhaps we could use them better like this." As if just not using them wasn't an option.
The first paragraph is unnecessary - why start off so arrogant?
I see this a lot in Asian writing - as if they have to first establish that the West is “doing it wrong” at the societal level before I get to read the rest of their usually unrelated message.
I didn’t like how the author classified all 3D gamedev as slop as if it’s a pointless endeavor - but talks about spending money on ChatGPT tokens to build a “software factory” as if it’s some ingenious plan. I don’t think the author realizes he is the slop dev.
And “shitty code” doesn’t mean anything in-and-of-itself. What are you making and why? A software factory???. It ain’t the code bro.
"But for how much more Fable costs, for how much more Astra costs, I do not feel like the results are there."
we are in the middle of the beginning. Its just a weird take to talk about the newest model like this while we are still in a R&D phase.
And these points don't matter if you let it search and analyse a bug, for example, or if you have good harness and a good architecture and let it do small PRs or if you do stuff no one needs to read (yes a software engineer also needs tools)
Nobody seriously thinks that AI is still at a R&D phase. It's already heavily entrenched both in companies and the financial world. If it's getting worse for coding then thats a major problem
> I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output
I don't know what to say, except that articles exactly like this one have been showing up constantly for the last three years, and literally all of them were obviously outdated and irrelevant within about a month.
When the code is shitty it becomes harder and harder for the models to make changes and this grinds progress down to a halt - this has been my experience with “factories” trying them and doing refining steps every few months.
I sincerely don’t understand what the people who say they no longer read any code are doing, because it must be somewhat trivial to not run headlong into these issues that stack up time after time - then people say to just prompt better and it doesn’t have that problem for them, but I look at those same people’s code and it’s horrific, and then I find they haven’t made it far past a proof of concept phase. I watch entire teams slow down to a crawl and not be able to handle changes, or production incidents. This seems common among many people I talk to.
I personally think that the boosters need to put up or shut up - the promises are way over the skis. Every single person I’ve seen being a strong proponent of these techniques both has nearly unlimited tokens to spend and also seems to be in the business of selling a solution. I can’t find many not-currently-marketing-something engineers succeeding using these techniques in production systems unless they’re quite simple, or doing a very specific task from a more mature codebase.
I’ll try to explain how to do it correctly. I’m not selling anything. Seeing this as the top comment makes me a bit sad.
On mobile, so I didn’t get super in depth.Comments like this give me terrible fomo. My personal experience is much closer to the comment you responded to but I’m always worried that it’s actually just me holding it wrong.
A more in depth follow up would be nice if you have time when you’re not on mobile. In particular I’d be curious to hear more about how your intense pair programming sessions go and how you maintain or develop a good mental model of the codebase. Obviously the backend UI is a big part of it but I’m sure there is more.
Any chance any of the projects you are using this on are open source?
In any case, I’m going to give your backend UI a shot at work next week and Astra plus your workflow a shot on a personal project.
I can't agree with 4 - it's sophomoric reasoning at it's best. The code is the product, it's what the system (human/ai/factory/combo/etc) is producing. The IC will always be more familiar with the nuance and the implications of the decisions than the manager. There is only one real stat to track - profit. As for the size of your team, not all human developers are equal, but agentic tend to behave similarly. A small team of highly coordinated things will always outproduce a pile of generic ones acting will little or no methodology. Please deeply re-evaluate at a philosophical level what quality over quantity really means for delivering outcomes.
Not to be tautological, but isn’t the product the product?
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.
Great comment. I don’t do everything you say but still get very high quality code out of Opus 5 with Claude. Fable 5 can be even better but I haven’t proven it enough to be confident yet. It may get off the rail if you’re a bit ambiguous about what you want , but that is only rarely a problem lately. We invested early in good AI instructions while still keeping the context small . We also have lots of skills the AI is instructed to use under different tasks (eg it must always span a subagent go review code, test creation skill, planning procedure etc). When all is done I just can’t believe any human could have done a better job.
1. I'm not sure what you're advocating here that wasn't already a best practice in software engineering.
2. This is a real benefit.
3. Not sure I follow, can you expand on this?
4. You don't have to be a perfectionist but you should still understand what it's doing.
5. Yes, this is hard and related to item 4.
In any case, you're not really contradicting OC since their comment was specifically referring to "the people who say they no longer read any code," and that's not what you're advocating at all (see point 5).
I honestly feel like you're making this sound more complicated than it needs to be. I get what I would describe as very good results from GPT 5.6 on my projects.
There are some methodologies that can improve things for me versus just YOLO'ing but even these are of marginal benefit:
* Have good requirements. Experience with a codebase and stakeholders helps a lot here.
* Correctly subdivide the task into chunks that won't blow context. You can write a big task and have an agent plan subtask delegation for you, but it's good to have some intuition of your own.
* Perform an automated code review. This is a no-brainer but it catches stuff.
* Make sure you understand the "big picture" stuff and stop caring about the little details. The agents will write unit tests, so you shouldn't have to care about reading every LOC, you can ask the agent to describe the architecture and flow instead.
This is still weird to me, the agents are super-good and clever most of the time, but I do feel I always need to direct them to a small area to focus: much like a human!! If you just ask them to implement things, they never (for me anyway, were not allowed the most expensive model! Terra is it for now) suggest they should stop adding code ontop of code and refacor, I always have to poke them to do that. Having done that once, and added some tests, they suddenly become aware that, yeah, maybe we should test stuff.
The LLMs seem to have no innate ability to understand whats a good direction a higher level. I mean, if you ask them about it, they will actually kinda figure that out, too. But always need that nudge...
So if you as a developer do not have the innate drive to ensure quality, the results will be terrible in my experience.
If you DO spend the tokens on quality though, it can also be kinda awesome. But its not magic.. I notice clear "slowdowns" the bigger the scope gets. They are not actually able to, in any way, subdivide implementations more efficiently than humans.
I am currently writing a lot of code that I am not reviewing anymore. These are all the things that make it work for me:
- Work on small projects (< 500k lines of code).
- Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.
- Have clearly defined API boundaries. Examples: If the back end is solid you can just vibe code the first version of a front end according to some mockup. Define a data pipeline with steps and clear contracts of what data gets passed around and what each step does. If the LLM messes up one step, rip it out and rewrite it.
- Have clearly set up workflows for tasks. Start with a "ask me everything" phase, then comes a plan phase, a review phase, an implementation phase, another review phase and then the integration phase. Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through.
- Set up excellent testing. Build your whole architecture around being easy to test.
- Have skills for common problems. For one of my projects I had to set up a skill on how to query the ORM, because Claude was consistently doing database operations in a for loop, where it could use batch operations.
The code in the end is better than a lot of the code I've seen humans write.
I don't think this works for everybody and every project. If you have a culture that values code quality and readability, if you work on large existing projects, if you have to nail the architecture of some non-trivial piece of software etc. you are going to have a bad time.
On the other hand you can probably build the MVP of your AI-supported CRUD app 10-20x faster.
I think a lot of the discussions around development tools and techniques just stem from two facts:
1. Developers work on widely different projects with different management and constraints.
2. Tools, libraries, frameworks and code style have to match your mental model, otherwise you going to dislike them.
>> but I look at those same people’s code and it’s horrific, and then I find they haven’t made it far past a proof of concept phase.
> Work on small projects (< 500k lines of code).
> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality.
You then expand on methods and processes that work for you, but I think the crucial question that you do not answer is: How long lived are any of these codebases?
All the projects I work on have an explorative character. It's very difficult to design a product, build it and sell it. You need actual customer feedback. LLM code gives you a much faster feedback loop.
If you have a clearly defined problem with customers lined up, you should absolutely use a different approach. In the startup world you often don't and you already know that you will throw away or rework 90% of the code before the first line is even written. The best thing to do then is to have clear boundaries and good tests, which allow ripping out parts of the codebase and reworking them.
how are you setting up excellent testing? using AI agents? hand writing tests? I hate talking to AI, I wish I could just write the test and the AI agent implement the fix
I am hand-holding the AI on the e2e setup. It mostly consists of Playwright + Cucumber + a test API to set up more complex scenarios. I also have unit tests for logic that lends itself to that. I also use mocked LLM responses for LLM projects.
If you enjoy writing tests, AI is really good at finding appropriate fixes for bugs that are easily reproducable. Just make sure to always have another AI review the fix. Otherwise you get a lot very, very dirty quickfixes. (At least in my experience.)
Thanks for the reply! So you would say that you have personally reviewed all the tests?
I’ve been thinking about how tests comunícate product function much more clearly and durably than prose, and that it maybe possible to create some sort of portable testing SDK that connects to the codebase and allows the dev to talk to the AI by just carefully writing tests, posting them to a backlog for the AI to pick up and edit the codebase until green.
> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.
That's always false. It's like people want their meals delivered fast. They say they don't care about taste or how it is done. Watch when they get sick or don't like it and the drama that happens.
People don't care until they do. They don't know what to care (in this case code quality) or say that because you're not explaining it. People also "gamble" and you take the blame. Long term impacts? Nah doesn't matter. Weeks later and things break -- what did you do?
In my country we have very protective labor laws, but what you describe is one of the few reasons that allow for instant termination: You refuse a direct order. If your boss says that he does not care about long term consequences and he want things done a certain way, you do it that way. Everything else is unprofessional. Your opinion on what you think he wants is legally irrelevant.
> You refuse a direct order.
I never said. It's not about outright refuse. It's how to deliver better outcomes. It's not a win or lose situation. Don't treat it like that.
> If your boss says that he does not care about long term consequences and he want things done a certain way
As suggested in my previous comment it could be you didn't explain it well. If you say code quality they might not care. Say it will crash randomly and can't fix it then they might. There's some art to it.
> Your opinion on what you think he wants is legally irrelevant.
No it's not. So you're saying if you got told to do something illegal you'd also do it anyway? I doubt it. You need to at least cover your back and document it as such. I'd say termination is better than jail.
This is like the first rule of working with clients -- what the client says they want is often not what they truly want.
>Claude was consistently doing database operations in a for loop, where it could use batch operations.
>The code in the end is better than a lot of the code I've seen humans write.
It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.
By the way, why didn't the "Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through" catch it?
Who knows how many skills you would have to have added if you actually reviewed the 400k codebase...But don't worry that's not what I am advocating. I myself would also latch onto any excuse that allows me to avoid the realization that I have to review 400k (or half that) lines of code, primary one being that I will always have a desperate paying customer that will always be grateful for anything I give them.
Which comes to your most valid advice which has nothing to do with AI (now that many devs have access to it):
> Work for business people who want fast results
This is what well oiled outsourve shops used to do and I must say it is no easy feat to be able to line up a constant stream of desperate businness people out of thin air, especially for your regular "I just want to code" engineer.
My guess is you're in the honeymoon phase with most of these people. The outsource shops that survived would fire the client that became more demanding and less grateful and move onto more freshly desperate client pastures. It is true that sales, self-promotion, and marketing are more important than ever now...
>Set up excellent testing.
Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.
I do not believe you read my comment in good conscience.
>>Claude was consistently doing database operations in a for loop, where it could use batch operations.
>>The code in the end is better than a lot of the code I've seen humans write.
>It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.
There is no irony because I have seen humans do the same thing. The difference is that the human was paid 50x more.
I do not understand your arguments around outsource shops. I get clients. They want something. I deliver. There is not a lot of complexity to this. I am not a world start programmer that has 50 clients to choose from.
>>Set up excellent testing.
>Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.
I set up excellent testing the same way a CTO would set up excellent testing: I give clear guidelines on the architecture I want to see on the project. I then review key parts and samples of it and give feedback. When it looks good I mark it as done and move on. Any bugs or defects always result in additional test coverage.
I'm happy to have a constructive discussion about this, but I do not appreciate your sarcastic, tongue-in-cheek, condescending tone. It makes people not wanting to communicate with you.
Part of the explanation (for me) is that the slow down comes later, and that part of the cost is externalized to team members. If you go all-in agentic on a project that has at least reasonable code quality, you can certainly gain a temporary boost by stopping to read the code for a while. At least long enough to get yourself and the rest of the team hooked on the idea.
Kinda reminds me of the "beginner's luck" problem for gamblers.
Also my experience, it works somewhat ok on large code bases that I designed and built myself before but after months of agentic development they sure start to degrade. I think if you start from scratch with agentic development there is no foundation for the models to anchor to.
I suspect this is just because of context. The AIs have very limited context related to us. I suspect that this is partially a result of the AIs being forced to be highly generalized machines which will work out of the box with anyone's prompt so they can't afford to be tailored to a particular contextual pattern. This lack of a robust pre-defined contextual framework that is relevant to the human who is prompting them, coupled with limited inputs to what the human actually wants and sees, result in context drift as the agent continues to go down its own path.
I mean I have asked LLMs about the SAME things in our legacy codebase probably 50 times now, (because I always forget, and that I don't understand much of it). And I have yet to get a perfect summary, a perfect diagram of overall concerns.
Its still much better than trawling thrugh code yourself, but they are far from all-knowing. I have to say they have gotten 10x better in just a year as well. Or they are very good bullshitters and just sound confident.
Yes, they've gotten so much better over the last year. The hallucinations have declined dramatically and the mistakes are getting less frequent.
This is basically my experience. A few people get to go fast and look good, at the expense of bogging everyone else down and making them miserable. I don't think any time or effort is actually being saved anywhere.
For my side project where uptime doesn't really matter but the codebase is quite huge (gamedev of a multiplayer game with Bevy, so both server code, game code, content build pipeline, as well as a TON of editor and authoring code, probably 150k+ LoC), I've been moving towards just reviewing boundaries between modules, APIs, and schemas, and I'm pushing towards keeping things as modular as possible. If something ends up wrong, it going to be isolated and it doesn't infect the rest of the codebase. Every now and then I zoom into a module and tidy it up (or even rewrite it).
I wouldn't dare doing this "carelessly" for anything where people other than me actually depend on it, but you can move very fast while doing it and the risks with bad code is quite hedged. Different modules can mature at different rates when it becomes necessary.
Maybe not related to all of what you were saying, but I think this enables scaling without ending up with progress grinding down to a halt due to shitty code.
I have home projects like this too, and those techniques can make things well, it can also rabbit hole in ways that are less productive sometimes. I’m constantly trying to push my comfort level and find what I can delegate and what I need to specify, esp around structure and isolation.
My comment is more for the people in charge of or working on software teams on complicated products for customers - so many leaders quite a few engineers have utterly drank the koolaid and pushed maximizing AI use with zero regard for quality or even medium term effects. Many of them are getting promoted by other clueless management for it - when someone is handed a huge check for being optimistic, they tend not to second guess themselves.
This can easily lead you down a path of excessive modularity with each module being excessively complex though
In my experience, when that happens it's most likely because you drew the wrong boundaries. Iterating on the boundaries also becomes quite cheap when developing this way though, you should never expect to get them right the first time unless it's a very common problem you're solving _or_ you've done it before.
> path of excessive modularity with each module being excessively complex
its contradicting metrics. You either have modules being excessively complex and not enough modularity or vice versa
I also struggle to reconcile these things, I guess the only way would be to try and see if it works for me, without caring too much if it works for other people on the internet. I would just like to add that, DwarfStar's author (Salvatore Sanfilippo) is a strong supporter of the idea that you shouldn't read the code, and he says he never read DwarfStar's code. And still, it seems that this project is much more than PoC and actually both usable and useful for people doing local inference (I didn't try it myself, but I saw a lot of positive comments about it). Could be that the crucial point is in how we use those models: instead of giving it a general goal (e.g. build me an inference engine) Sanfilippo, being an experienced programmer, kept pointing the models in the right direction. He also read the papers related to the models he was programming support for in DwarfStar, so that, when he worked on optimizations, he knew what should be done instead of prompting a general "please optimize this". So, I would say that, if you let the agents work on a "feature by feature" basis instead of trying to on3-shot things, you get much better results. Could also be that, by attempting to one-shot large projects, the model starts coding badly due to context window exhaustion.
Sorry for the not so well written comment, I was just throwing in some ideas.
Reading Snowcrash, the guy gave up coding because "back in the day" a hacker could do it all alone but now it was all about software factories. That was in a book written in 2000.
Software is theory building, as Naur puts it. It's a learning process, a research project. Orgs have been trying to turn it into assembly line work forever. There's a lot of money in it.
I don't care. It has also never been easier to solo hack. There's great tooling for insanely productive languages out there. I won't say what I use because that's akin to religion around here. I'll say I'm super happy and would never in a million years become a factory worker. Even if it paid me 10x what I can make solo.
The idea of giving up mental traction for money sounds insane to me. I love to grip software with my own tendrils. There's nothing like it in the world, there has never been, and despite the current insane corponomics, I dare say it will keep getting more and more amazing for those who care to learn deeply.
Neal Stephenson's Snow Crash came out in 1992. I guess the paper back became popular in 2000 though.
Thanks I was going by the date I glanced at the counter cover
I have noticed that when asking LLMs to work with existing code, their output reflects the existing codebase: the better the existing code, the better the LLM code.
Every time I bring this phenomenon up, I hear from HN commenters that it used to be like that, but today it is solved by modern powerful models, harnesses.and workflows. I don't know. At work I still direct and review everything LLMs generate, because if HN are wrong and I am right, I am in huge huge trouble.
In my experience you can “stop reading the code” if you adhere to prompting the AI aiming for changes that would be reasonable in a PR to review, if you’re using rather opinionated framework(s) to base your work on and explicitly ask for tests (models tend to add them on their own if there are some). I personally still read the output and start by checking if existing tests were modified (kind of a red flag when this unexpectedly happens imo).
When I read posts about AI generating garbage nowadays it’s either because of a small prompt/big ask combination or a lack of an underlying framework.
Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process.
I'm not convinced this style of "agentic engineering" saves much time. I guess if I was oblivious to what good code looks like, and didn't care about maintainability It wouldn't bother me so much, but it legitimately has effects my "mental health".
Quality code is easy to make changes to. What makes terrible code terrible is that changes become harder and harder to make over time. LLMs haven’t solved this, but the marketing acts as if it has, and many engineering orgs seem to have instantly forgotten the things we’ve learned from the last few decades of building software.
Yes you can have your agents do refinement and refactoring. If you don’t know what they’re doing when they are doing that, they can and do introduce massive churn. The “build it fast and fix it later” crowd seemingly has never had to actually go try to fix it later, or dealt with production incidents when people have no idea how their code works. These folks are frequently promoted fast for their “productivity” and massive promises by clueless management and move on to let others have to clean up their stuff.
Yeah I expect we're going to see a lot more "disposal code" vomited up.
> Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process.
Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).
Talk with an LLM, ask them to rate both code and estimate dev experience based on that code, and you will see what they value: Code that passes all the tests is a 10/10, while a codebase designed with opaque data types, Parse-Don't-Validate for all data, isolated interfaces, a built-for-replacement-not-for-extension philosphy will get a 6/10 because an out of bounds error was found.
IOW, they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way - we very highly value code that is easy to maintain, even if they do have a few errors picked up by the linter.
> they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way
This is a really valuable insight! It resonates well with my own experience revewing AI-authored code: I look hard at interfaces, architecture and performance, and merely glance over code that just "gets the job done", because if it works, I'm not worried about it. Now I can express that dichotomy much more clearly -- thank you!
I have found that claude (opus 4.8 and 5) can do a very good job of implementing good architecture and system design if I can just steer it right. left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code, claude will go do it the right way, and can even have a pretty sensible discussion about the tradeoffs involved. so it does know about good code architecture and patterns, it just doesn't have the taste and initiative to use them without being told.
> left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code,
But that requires actually reading the output, which I am pretty certain only a rounding error of programmers are doing at this point.
And the next time your agent comes across the same problem, it will likely use the same previous inefficient way again (despite all attempts to codify the instruction in AGENTS.md, CLAUDE.md, skills, whatever)
> Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).
Blame the benchmarks game. They're optimizing for that and that's what those things are measuring.
> saves much time
Reviewing and reading everything makes this feeling, yeah.
However where I can say 100% it saves time is discovery by answering these questions:
I'm genuinely not convinced it actually saves time once a full accounting has been made. You get the initial result faster, but then you inflict a super slow and torturous review process on yourself or a teammate. Even if the review manages to bring it up to parity, over time you will keep slowing down as more and more code was never written by the humans directing the agents, so their understanding decays.
I at least give the new interns a stern warning: it is easy to speed yourself up by slowing others down if you pump a lot of slop.
My team experimented with re-writing from scratch the prototype of complex functionality made by a non-engineering vibe-coder from another team. We didn't look at the code, and barely looked at the result.
It took about 4 days to get a production-ready reviewed code, while it took them 2-3 months to deliver something that another team judged "impossible to review".
The PR for the prototype was closed.
It helps that I'm a domain expert here, as I have a minor degree in the domain, so I can judge better. But the discrepancy is just too high to ignore.
While there are ways to manage it with supervision, the impulses of every model are clear and counterproductive. All code is littered CoT in comments and insane decisions. Its attention is limited and it saturates fast, neutralizing one of its main advantages. It’s really nice with supervision but something smells with the hustlers.
> I sincerely don’t understand what the people who say they no longer read any code are doing
Well that one's easy to answer, they're either A) lying, or B) working on the simplest possible software where this kind of stuff doesn't explode. Or the alternative 3rd option of what you mentioned, the initial pre-MVP phase goes decently but then it all collapses inevitably as the slop accumulates and the codebases become unmaintainable grey blobs, but that hardly matters to them because their MVP app never makes it past that initial stage before they jump ship to a new "amazing" idea.
The lying comes down to astroturfing and shilling from the LLM companies that want to sell people on the idea of vibecoding and tokenmaxxing.
Or C, agentic coders who have been doing this for 20+ years (software engineering) know what they're doing?
Also, when people say 'read the code' do they really mean go line by line, or review the pseudo code? Meaning, read the high level architecture/data flow.
Because IMO the code matters very little if you have the proper testing environment and guardrails, the architecture always matters.
In my circle, the only people who make these claims about AI were all terrible developers whose contributions were slowing down everyone because they needed to go through several reviews and rewrites before they could be accepted.
Now it's basically the same but they love it because it's only their teammates who have to put in the work not them.
This all implodes when the teammates get fed up and just approve everything.
+1
Some people write terrible code. Some people don’t proofread their own code. Some people are writing code in a second (or third!) language and the typos are harder to spot and comments are harder to formulate.
It’s a bit like the variance you could expect from asking a room full of people to write a 1-page short story on a specific topic (e.g. “death of a loved one”). Some of those short stories will be unreadable, and some of the people who wrote those terrible stories will have no idea how bad they are. Except now, enter AI, and the room generates the short story instead - who has the skills to determine whether their short story isn’t terrible?
Also there is also category C: they are not developers and they don't care about the code at all, but also not really much about the product. They just want to tick the boxes.
They blindly accept that LLMs "take time" after the slop grows because they're running several agents at the same time, so they can still claim to be productive.
Does it move the needle, business wise? Not really. But a lot of businesses are "optimising" for maximum token usage and for how many tasks one person can do, not for business value. Is it really surprising?
Thought expirement. If astra max effort made one function at a time via a heavy description by you. Would it ever produce slop? Fresh context, 1000 lines of style and content guide you personally wrote. Per function no other code context massive guides and styles and it writes a bunch of AI slop unit tests on the side for this one function.
If the answer is yes then atleast you're consistent if no then the question is why can't you scale this until breaks? Then never move beyond that limit?
My argument is there's a "break even" point when the power of the AI is larger than the problem you give it to the point it doesn' slop. You then build at that chunk rate and only try to increase it with next gen model. I usually keep a few "screw it" ideas in my back pocket when a new model arrives to see what happens.
"Go rewrite this entire pipeline in rust" "Go train me a custom x model for y"
Fable is the first model that did not just crash and burn on one of these tasks. Astra still can't do the rust migration (goodbye tokens). But I assume eventually it will. Then I'll have to make up a new ridiculous level.
The model training one was literally an identical pipeline I made before AI and it was like a 6mo process. Fable did it better than me in 1 week (with me helping of course). My theory though is that its datascience is massively higher skill than other systems.
You need to find the chunkrate for your problem and style that works.
A lot of them do complete re-writes frequently. When code is cheap and you get stuck, thats what you do.
Enabling more "proof of concept phase" projects to exist is one of the great boons of AI.
If code is expensive, you don't want to commit to a PoC unless you're damn sure. If dirty code is cheap, you can vibe code a PoC early, even if you aren't sure the project is viable. This, of course, leads to more projects dying in PoC phase. It also results in more projects that otherwise wouldn't have gotten to it getting past it.
Personally, I don't believe that "code is shitty and hard make changes in" is in any way, fashion or form an AI-exclusive problem. Big corporations had plenty of decade old codebases filled with decay and rot back in 2009 already. It's just the usual side effect of sacrificing "future maintainability" for "feature velocity" or "expertise" for "cheap labor".
Unlike the usual causes of code rot (cheap replaceable developers, outsourcing to India), AI might actually get out of the pit - by getting good enough at refactoring to be able to beat the code back into shape. There's nothing about refactoring in particular that demands a meatbag when the rest of the coding tasks don't.
> I sincerely don’t understand what the people who say they no longer read any code are doing
We're doing other things.
I've got projects that I really care about. Every line of code is written deliberately. It's great.
However, I can't afford to pay so much attention to everything that I do. There are only 24 hours in a day, and my mind has its limits as well. I've found that I can't reliably care deeply about more than two projects at once, and one is the ideal.
The point of AI, at least for me, is to do the other things that I've always wanted to do but never cared enough to. I just put the AI on the task and it gets done at some point, and I don't care if the code is "slop" because it wouldn't even exist to begin with were it not for AI.
While the AI is working on the things I've always wanted but never quite cared enough to do, I'm personally working on the projects I actually care about, or enjoying life in general when I get burned out. For example, a couple weeks ago I was playing video games while the AI was reverse engineering my laptop's BIOS.
I'm not a heavy AI user but there are a couple of things I noticed trying to make copilot generate something for me from scratch.
The first is that having a single file with everything you have in mind is very useful. So I end up writing what the project is about, how the model is organized, what each button does, etc. This is good practice in general because writing down everything that the AI will have to consider forces you to consider edge cases before you program them. E.g. if you write "the detail pane shows the fields of the selected item," it makes you consider what should it show when there are no items, or if multiple selection is possible. As you can imagine, this file ends up a very long document even for a simple project because the goal is to pseudo-program everything and let the LLM translate it to an implementation.
Then it still gets things wrong about design, e.g. which pane goes left and which goes right, if you don't also provide an image that shows the layout.
And then, if you supply an exhausting amount of detail, the agent can generate more or less what you had in mind....... or rather, it can generate an OUTPUT that matches your specification from scratch.
The problem is that if there is something you failed to consider, and the AI makes an assumption there, you can end up with a fundamentally broken architecture that you will have to untangle yourself later. And at that point it's easier to write everything from scratch than to fix a pile of AI code that is based on a flawed design.
And it turns out that due to the "totem pole" way that software works, there are infinite places in code that a bad design decision can affect everything it touches.
A good example is how 2 components in a UI are bound to data. You can use events, a bus, state reactivity, etc. Personally I think the mediator pattern is the simplest way to handle GUIs. But an LLM is probably just going to use events for property bindings.
I've got downvoted and flagged for saying similar. It's actually positive you are the top comment. There has been aggressive brigading around reddit/hackernews and also traditional media. These are malicious companies, so not out of their line. So far, AI seems to be useful only for programming. It's not clear it's useful for other professions. It can't even write straight without being recognizable from afar.
If AI is not even useful for programming, its value drops significantly. And some people seem to have dropped hundreds of billions on this.
> I sincerely don’t understand what the people who say they no longer read any code are doing
Welcome to the present.
Like many of us do not read the machine code generated by a C++ compiler, the code generated by an agent is similarly irrelevant and disposable, by now.
The machine code generated by a compiler is deterministic and reproducible (assuming using same chain/tool versions), which is why reading the human readable pre-compiled source is sufficient.
Reading a prompt but not reading the non-deterministic/non-reproducible LLM output is not comparable.
How do you know it does what you want it to do without reading it? Tests? How do you know what they test? Yes, clicking a button in a browser and getting the result you want satisfies most, but that only works on the most basic systems. Once a code base grows large enough, any one agent reading in its context wont understand the whole, and if no human does either, it becomes unworkable.
Yeah, tests. You need tests for everything and the tests + API needs to be carefully reviewed. Technically, the implementation need not be read at all. Just APIs, boundaries, and tests. You need unit tests, mutation tests (tests for your tests), integration tests, and end-to-end tests. You also need to design the system to be broken up into small submodules, which is how software should be written anyway. You push all side-effects right to the edge, and then test the core extensively.
Nobody needs to understand the whole. They only need to understand each submodule, which is easy. And then, how they interact, in which case you only care about the API and contract garauntees, not the implementation.
Realistically, this is how pre-AI software engineering worked, too. Or how it should generally work. Nobody can read or understand a 10 million line codebase. So to ensure you don’t break shit, you need the submodules, orchestration, and tests.
What‘s relevant then? We still put the code in version control, not the shitty prompts that made it.
Correct, but I increasingly find that the version control is just a storage for code and a place to trigger CI/CD from.
Edit: ...and that the source code is useful in retaining enough context of the problem being solved. So, most people will not store the prompts, trusting that the source code provides context for the next iteration.
That’s a huge overstatement. If that were true, then banks would code their core financial services with that approach but they don’t.
Is it though? I see this occurring every day in a number of projects I have visibility to.
Isn't this exactly why OS projects are over-burdened by the firehose of contributions? The maintainers will want to read the code contributions, while those up-to-date with the latest models/agents/tools already trust their output to be above the average developer's (whatever that means in practice).
How does handling support tickets/bugs work with such approach? If LLM sometimes can't handle it - do I have to beg it to keep trying, as humans are no longer an viable fallback?
The way I've seen it work is basically pointing an agent directly to the ticket, or via a proxy description.
There's a good chance that if the agent cannot handle it, a human wouldn't be figuring it out either, without additional context. That context would be the sort of only-Joe-knows-how-it-works, so perhaps something worth addressing in any case.
This matches my experience with Astra so far too.
> I think I’m suspecting something is going “wrong” in the training process. The model is greatly rewarded for succeeding on long-horizon tasks, but presumably there is very little punishing going on for “shitty code.”
My suspicion is that both OpenAI and Anthropic moved their RL agendas from "being rated as useful according to human feedback" to "succeeds at long horizon tasks" in the last few months, resulting in agents that are closer to AGI in an autonomous task-completing sense, but strangely bad at communicating.
The result is that they are amazingly good at long horizon tasks, computer use, solving difficult math/ARC-AGI type problems, but becoming weirder and weirder to work with.
They don’t want to sell these tools to developers. They want to cut as many layers as possible.
Where I work:
Developers very rarely blow their limits, except when they're experimenting on purpose.
Most non-developers are out of tokens by the half of the week, and need to use usage credits for the remainder.
To me there is clearly a better target demographic for AI.
I have several $200 subscriptions as a developer/founder. I used to blow through all of their limits when the limits were quite high. As I progressively learned the limitations, and what to make of them to get useful results, I may be left with 50% of weekly usage still unused. Some weeks it's even more.
And yes, when I get a crazy idea and want to experiment, harness will plow through multiple accounts + openrouter budget in 3 days. But such crazy experiments are rare, they're not 'normal' usage.
This is a very insightful dynamic.
Probably reinforces that we’ve already surpassed the frontier threshold for LLM usability in software development and can now focus on cost and personalization. To make a comparison, no one is making a better machine vision app for hot dog classification - we hit diminishing returns 10 years ago on that front.
But also scary for both investors and the working class: AI companies want to facilitate the concentration of capital even further into the hands of the ownership class. Will they succeed?
I wouldn't be surprised if they are optimising for producing more code, because in the long term, more existing code means they can sell you more tokens to maintain it.
The incentives are certainly extremely strong. I have read hundreds of AI review comments, and I don't think I've ever seen an unprompted suggestion focused on net reducing code or increasing readability.
I wonder too if in training for long horizon tasks agents become worse team players, good at orchestrating subagents they are trained to use, but worse as an agent within an external multi-agent orchestration system or just in turn-taking with humans. That was my experience with Opus 5 and so far it has been my early experience with Astra as well.
So the AI equivalent of the socially stunted but brilliant researcher?
so they trained it to be a 10x engineer?
I wonder if we will start using LLMs to translate the output of other LLMs to make it more palatable for humans.
> This matches my experience with Astra so far too. > I think I’m suspecting something is going “wrong” in the training process. The model is greatly rewarded for succeeding on long-horizon tasks, but presumably there is very little punishing going on for “shitty code.”
Probably because so many influencers in the space say stupid things like: “it works, right? Why would I spend time reviewing ai generated code?” As if the junior engineer who wrote over engineered complex and sometimes bad code — if they had just done it faster — would somehow be acceptable. wtf?
> I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense. The English term for Neijuan is “Involution” from the book Agricultural Involution. Agricultural involution describes the intensification of farming that raises productivity per square meter while leaving productivity per head unchanged.
This resonates
it reminds me of a thread I read on PTT, Taiwan's Reddit. AI finally achieved what humans could not. Managers must give exact context for what they want, must pay exact wages (tokens), and can't delay salary payments (which seems to be a problem in China).
Yeah it's a funny thing - a lot of the things you need to feed the model are things that actually would have helped humans...
Starting with agentic task-time "grounding" being just good documentation, and "skills" being just playbooks and user guides.
Hell, skills are increasingly paired with dedicated CLI tools, that remove jank from actual utilities and adapts them to be token efficient.
So now, any CLI `tool` people want AI to use eventually grows `tool/SKILL.md` and then a `tool-for-llms` wrapper that exposes task-specific, logical, higher level interface, then the skill is rewritten in terms of "for LLMs" wrapper. The procedural knowledge moves from Markdown into the wrapper, making the skill more token efficient, and both skill and the tools are optimized for common tasks and... at this point, we are doing actual UX engineering.
Now the truly interesting part is the difference between what's good UX/DX for LLMs vs humans. Turns out, the conceptual/abstract/cognitive part is pretty much the same: which is why skills still look indistinguishable from well-written documentation for humans, and why the commands exposed by "tool but for LLMs" make sense to us. Same way of grouping ideas into higher level concepts.
No, the main difference is just that LLMs are perfectly content with tightly packed unprettified JSON, or other forms of Perl line noise. The tool output doesn't need to look nice, or to have any spatial structure - they're reading it token by token anyway, and the tokens come from a tokenizer that's reading it byte by byte.
That points at an interesting asymmetry for humans. LLMs are doing I/O the same way in both directions: sequences in, sequences out. Humans only do sequential output - inputs, particularly visual, are processed holistically.
For us, what's easy to read is hard to write, and what's easy to write is hard to read. LLMs don't have this friction.
(I don't know what the implications of this are, I just find this interesting.)
I never quite realized this until just reading this and now it has come into sharp focus. Incredible.
I've spent years trying to convince my director to have our org invest in documentation and monitoring to no avail. Now he is telling us to spend dedicated time on monitoring and documentation so that agents can better diagnose and fix bugs. He is doing this because his boss is mad that our org isn't "agentic" enough.
Except... because we underinvested in the past we have a bunch of services where the institutional knowledge is gone and people are having AI write the documentation...
But doesn't this reduce the required amount of farmland?
There is no “required” amount. More gets produced using the same area, using more people, but keeping these people in poverty because productivity per capita doesn’t increase. Instead the gains from the increased volume of production get captured by an elite. See https://link.springer.com/article/10.1186/s41257-019-0021-y.
What corresponds to land in the AI analogy to this?
There is no direct analogy, the term has drifted since. See https://en.wikipedia.org/wiki/Neijuan.
Yes, the extra farmland gets taken by the AI companies.
This sounds like all engineering, rather than just AI. The greatest effort given to the last small difficult details, often for results that seem trifling but which matter at scale.
But it's a poor argument. The code improvements with these things is hardly marginal - Opus 4 was only 16 months ago. How many of the grumblers would want to ditch their modern stalwarts and return to it? What is marginal is the nitpicking - and like anything in tighter bounds, it's more intense with a narrower scope.
These threads always have many dissatisfied voices with repeating complaints - about overwrought thinking and disappointing output - alongside others who are amazed at the sudden real extra capabilities. Both are true at once - capabilities are rapidly increasing, but nowhere near ideal, which is why this attempt to tag it as Neijuan, though interesting, is ultimately a load of bollocks.
Also known has the Red Queen's Race
It surely resonates if your reason for working is to extract wealth from others (ie. be a parasite) but if it's to improve things for everyone, then it's wonderful. You might still work just as much and get paid just as much but produce a lot more because of technology.
I’ve asked Astra to build me an app for a prototype I created quickly using Sonnet.
It’s been 2 days and it made no real progress on the actual app. It created docs, scripts, workflows, and it’s doing a bunch of reviewing on every PR.
I told it that I just need an MVP.
I’m pretty sure an average senior engineer would have finished that task much quicker, and guaranteed with more readable, higher-quality code. Meanwhile, I think I’ve easily crossed 100k tokens so far on nothing.
Funny world we’re living in that this is “SOTA” and “AGI”.
I’m genuinely curious what these OAI and A/ engineers are working on that they praise these models so much. I did not see any improvement since Opus 4.5.
Also, I’m really unimpressed by any “one shot” demo that’s out there in the wild. It means nothing for serious software engineering.
I don't know how to make apps or evaluate code, but with astra I having been making an iOS app on my own for the first time and it's going great. my app is not terribly complex but requires using bluetooth and other intricacies which I thought would be tough. but it's going really well. I'm not asking it to one-shot it though, I'm going feature by feature, testing and building up.
yes, at first it would run simulator tests on all font sizes but it stopped after I asked it not to do that until UI review
maybe sol would have done the same thing, idk. but I find the whole process to be really nice with astra. I use it on high unless it says something is impossible then i go max and ask it to find alternatives (happened once)
I've been making a macos app with opus 4.8-5 and at first it was great, everything materialized in a week, but when I started tuning stuff and fixing performance problems I have spent a very frustrating month refactoring code where I had to constantly catch llm red-handed and explain and sometimes push obvious ways how to make things work properly (a general knowledge from a completely different stack). In the process CLAUDE.md and memory grew exponentially explaining what it should and what it should never do.
were you letting it run for hours like the OP, or doing short tasks and reviewing/testing each one? every once in a while I also ask it to consolidate/summarize docs and stuff like that. we'll see what happens in a week though
I have started with generating very detailed "feature" spec and going over it many times until it looked good to me. Then I made it write an "architecture doc" and plan how to implement all which was about 15 parts. Then I was making it implement one part and then tested it and made it fix 20 things and then again, and consolidate docs too, so after each part it looked and worked well enough.
>Also, I’m really unimpressed by any “one shot” demo that’s out there in the wild. It means nothing for serious software engineering.
If a person, or team of people, can build a demo quickly then it's good odds that they can build the real version (though, famously, not a guarantee). However, it turns out that a machine that can spit out 100 demos of whatever can't actually build the real thing.
Similarly, a chess engine rated to 1000 Elo doesn't play like a 1000 rated human being. The mistakes that each make to reach the equivalent level are different in size, frequency and kind. The thing that makes a human reach a good demo is very close to the skillset to reach the finished article. This isn't so for LLMs but we have yet to update our priors.
This resonated with me. "Developing ideas and artifacts using AI breaks our normal intuitions along many meaningful axes and we've yet to update" is a really clean idea.
For me it also produces totally overengineered tests that are tightly coupled to the implementation. For example testing existence of css classes (in a template based go prooject ...) instead of behaviour.
Can you recommend any model that doesn't do this?
Not GP, but IME it's not fixable by model selection, but being zealous about guiding output and vision, and pushing back on all the bad habits LLM in general has (eg verbose output as a band-aid for emergent intelligence). As soon as something is introduced into your codebase, it will continue being picked up into context until you remove it and any reference to it from any potential context entrypoint. If you don't any model will keep venturing down wrong/bad paths.
> I’m pretty sure an average senior engineer would have finished that task much quicker [...]
Maybe the lesson here is to not send a staff engineer in these cases ;)
Sonnet is not SOTA. Try with Fable or Astra.
>I think I’ve easily crossed 100k tokens so far on nothing
100k tokens? Is it just me or is that very low for an app build?
100k output is a good amount. Probably read and cache are way more, to the millions.
equals roughly 10k loc. If output is code only without rewrites.
I’ve observed exactly these patterns with Opus and Fable as well - for example, forgetting that they can edit files and instead use python scripts as a patching tool…
The harness instructs them to behave this way. Also this approach saves tokens. The scripts allow to edit files in bulk, and most of the session cost is in cache reads (e.g. for 300K context each command costs the same as 30K input tokens).
> The harness instructs them to behave this way. Also this approach saves tokens. The scripts allow to edit files in bulk, and most of the session cost is in cache reads (e.g. for 300K context each command costs the same as 30K input tokens).
I understand the reasoning, but at that point wouldn't the LLM be better off creating `sed` commands and executing those? I mean, if it's already executing Python, it can literally do anything to the environment, so using `sed` is at least as safe, with a bonus that it (or a subagent, or a human) can double-check the intention with the sed script and flag incorrect or missing changes.
I've experimented quite a bit with giving agents python vs sed + awk. They make mistakes with both, a lot. The only thing that has stood out is that agents reach for python too quickly if it's available, and that awk causes the least problems, while sed might take several attempts to get results, similar to python.
Also it's the only way that makes sense when you need to work with big files, or large amount of files, or documents that look small when fetched through a RAG tool, but then you read one and get hit with couple megabytes of base64-encoded binary data you didn't expect because RAG tool stripped out embedded images...
Ask me how I know. Or don't. I have a standing rule for all agents warning about that failure mode (and related, doing `ls` in `/tmp` and few other directories that like to accumulate files by the hundreds..)
My harness forbids it, they end up spending time debugging their scripts
Why would you use a constrained edit tool when you are also allowed to use the complete power of python?
Because the complete power of Python also includes the power to fuck things up.
So does using an LLM.
In fact, that's kind of the whole point of using LLMs in the first place. Their value is in their general capabilities.
…which we attempt to constrain by encouraging the use of tools that make it harder to fuck shit up.
Having an agent edit 100 files means the job will definitely get done correctly. When it writes a script to bulk edit things it fucks up and spends ages debugging their script.
Have you ever counted the number of times Claude fucked up quoting/escaping and had to issue a corrected tool call? Or get stuck in some tricky quoting situation for two minutes, throwing a couple piles of shit at the wall to see what sticks. IIRC I’ve even seen it eventually using the edit tool out of frustration once.
Simple is better than complex Complex is better than complicated
Or something, I don't remember...
... simply the best, better than all the rest (Tina Turner)
Ușor, Burebista :-)
That was pre LLM. Now everything is a prompt that you type into AI lol
Why even offer the edit tool in that case? Also, what kind of editing could they possible do what wouldn't be possible with POSIX ed?
You can chain a lot more commands together with this technique than with a single Edit tool call.
The funny thing is that... POSIX ed is composable :-)
You can do a gazillion edits with it in one shot.
Of course, LLM edit tools are probably small bits of their custom code, I just find it funny. I wonder if it's a desire for certain technical characteristics that require custom code or just a lack of info on basic tools. Heck, if it's about platform availability, using an LLM to port ed to Windows (for example) should be trivial[1].
* * *
[1] And there are probably a million existing ports. Also, sed, ex, vi, whatever.
This is an instruction by the harness. It re-injects the prompt every other message, so that's why it "forgets" to use the Edit tool.
this is intentional, afaik agents do better with python and alike than the harness tooling.
Using python or any other stone-age approach for search and replace is stupid when your language provides you with a complete, fully typed AST, like .NET does.
I use AST replacers, much more reliable.
Sounds like you don't have enough experience with coding agents. Deterministic scripts must always be preferred instead of LLM tool calls. In fact, you should instruct your agents to write code to execute instead of letting them call tools.
Plenty of experience ;)
Then why did you comment what you commented, good sir/madam. Claude and Codex are good at remembering to use scripts instead of tools these days, especially if your <32kb .md file mentions it. Not even talking about the skills designed to catch such issues.
Sounds like you completely lack all reading comprehension ability
LLMs sometimes like to execute one-off Python scripts to make edits to files rather than just calling the edit tool directly. Both are tool calls so saying that you should have it write code instead of doing tool calls makes no sense because writing code is a tool call for it...
Early lesson I learned from AI engineering was - there is no substitute to giving a groomed epic to an agent. Instead of simply saying 'implement themes in my product' you need to be specific, in fact more specific than usual. You need to say exactly what is in scope and what's not, even down to a buttons, events and layouts.
You can groom the epic with the help of AI, but final review must be done by someone who can take ownership of the specs and hence is responsible if something has fallen through the cracks. AI's response will be limited by the output tokens of that specific agent, and there will no repercussions for AI even if it accepts its mistakes.
Yeah, I think as a general direction we need to allow a useful collaboration with the agents on the issue board.
This is btw why Epiq was developed, to keep the board as code, git-backed, distributed (via an event log mechanism), and with the ability to replay the board, to see what agents actually did:
https://ljtn.github.io/epiq
How does this compare to Beads, if you don't mind me asking?
https://github.com/gastownhall/beads
I hope @jolaflow can chime in here eventually, but from a brief look, my impression, besides the fact that Epiq is based on git as opposed to beads where it is optional, is that Epiq seems to be much more optimized for interactive collaboration between the user and the agents.
The graph visualization in beads surely is a neat thing for showing things, but the replay feature in Epiq should provide a similar understanding of what happened.
But again, it seems to me Epiq is the tool that better allow the user to jump right in and collaborate with the agents on the board.
(Again, this is from a brief look, so I could be missing things).
thanks for sharing, going through your blog about cognitive debt.
Sorry, I might not have been clear, but the tool and blog is by @jolaflow (my brother) and I'm so far mostly involved as a reviewer and early adopter, but glad you like it. I might be biased, but I think the tool provides something really useful for agentic coding and hoping it can grow into a thriving open source project.
This looks very cool
> Early lesson I learned from AI engineering was - there is no substitute to giving a groomed epic to an agent. Instead of simply saying 'implement themes in my product' you need to be specific, in fact more specific than usual.
I think this lesson is getting partially outdated. Yes, you need to be specific about what you want, and with earlier LLMs, you need to had both domain knowledge and some general software development experience to front-load various big and small choices about design, architecture and operational reality - what libraries to use, how system components communicate, how you handle auth and store secrets, etc. Otherwise the LLM would pull some random mix of ideas from its latent space, and give you something that's broken in really stupid ways.
Nowadays, it doesn't feel like that to me, not anymore. I still need some understanding to verify the proposals, but I found the last ~6 months of SOTA models to make good choices. Like, just yesterday I asked Claude to design me some simple service, and focused on explaining it the domain parts (nature of systems I want to integrate together, the purpose of that, and the user's priorities and use cases), and the design I got back had specific suggestions around security, authentication, deployment, failover, integration, behavioral impedance-matching between integrated systems, and more, that I all recognized as based on solid software engineering and ops practices, but deviating from it explicitly in every place where it would be wrong for this specific project. The model considered way more corner cases than I did, and I'm actually really impressed by it.
But then, I find greenfield development is easy with LLMs. Modifying existing systems, especially legacy ones, is where I need to babysit and micromanage models - because any misunderstanding or inaccuracy, which often comes from stale documentation or naming mistakes, tends to get amplified and confuse the agents. No matter how precisely you specify your epic, if the model will find something that contradicts your knowledge/intent, there are good chances it'll get confused and make subtle errors, and you won't realize until much later.
The way I see it: models are highly biased to treat everything they read as "ground truth", all of equal importance. There's no nuanced notion that some information may be stale, that there's a temporal and causal order to sources, and that some information may just be wrong.
And this compounds when you let your LLM write code and documentation over time.
>> No matter how precisely you specify your epic, if the model will find something that contradicts your knowledge/intent, there are good chances it'll get confused and make subtle errors, and you won't realize until much later.
True! hence the need for someone to review the final spec output and own it as their own output. I have also found LLM to be better at debugging and solving 'a' specific problem, which I believe is due to output's surface area to be reviewed is lesser in comparison.
But isn’t “grooming” the hardest part? To know the details means to know the codebases behind. So you do discovery, read code, ask people, check db tables, and then once you figure it out, you write a doc with the proposed solution. It gets reviewed and then you code it.
I definitely need AI help for the discovery part… so it always starts with a simple “I need to do X”
You don't need to read the code manually line by line to do that. But yes, you need to know what you're doing.
Genuinely curious, what is the benefit of doing this over just programming it yourself? It sounds to me like this is just an extra step that will grant you less control?
When programming a feature, you are simultaneously doing at least four things: 1. Implementing. 2. Building highly detailed mental models. 3. Learning and expanding your skillset. 4. Quality control and scope limiting.
And this process can be iterative and dynamic. Writing massive, super detailed specs that you then hand off to a undeterministic model feels like doing step one and three, while skipping two and four, which you then have to do after. What is the benefit? The speed up, in my opinion, comes if you skip step two and four, but then your product WILL be worse. Feels like I am going crazy?
Programming was never the bottleneck for software dev?
If you define what you want in typescript by updating existing typescript wordage, you get what you want exactly as specified, with minimal token cost and no ip theft.
I mean then it might be difficult to get stakeholder's alignment on specs written in typescript though.
> in fact more specific than usual.
At which point you might as well write the code yourself and get a deterministic result faster, better and cheaper.
Not sure about that. Writing detailed specs you deal just with the inherent domain complexity. Writing code you also get accidental complexity that has nothing to do with the business, whuch not only piles on top, but tend to interact vexingly with the detais of the domain.
Where you would have a point is if you'd say we have excellent tooling for wrangling code, but less tooling and tradition to write and manage specs.
I have realized that it's like giving a task to a brilliant coder who has just joined the org and is more excited and eager than usual. Hence the responsibility falls squarely on you to set scope constraints while ensuring only to-the-point features are developed.
> Instead of simply saying 'implement themes in my product' you need to be specific, in fact more specific than usual.
Around February you could get away with very vague prompts to Claude. I feel like models have regressed since
Feb/April was peak for code.-
Wasn't this during the period where they had a bunch of bugs around caching and the models were making loads of weird decisions?
I honestly feel like basically nobody knows anything about these models, it's all just vibes (and I'm no different).
Indeed.-
Anthropic broke their models in spring, denied it, gaslighted everyone who said so, and then all but admitted it: https://www.anthropic.com/engineering/april-23-postmortem (basically doing Anthropic things).
> I honestly feel like basically nobody knows anything about these models, it's all just vibes
This, too. Since only providers know what they actually serve, what they change and what limits they impose.
There are some visible degradations though. E.g. Claude-ish.
As for a personal anecdote: around February I created a rather complex quiz web app for myself and friends with multiple question types, sync between screens, multiple media upload types, multiple scoring and timing types, MC inetrface etc. etc. etc. It took me a week or so in the evenings with rather vague prompts to make it.
Now Claude (and Codex) cannot reliably build a much simpler web app even with precise instructions while also maintaining the visual consistency.
But I will agree with you, it's a feeling, not a precise measurement.
I am guessing (guessing) that "great coding model" and "great model for the widest use" (agentic, long-running, unsupervised, knowledge-worker, computer operator) are competing, conflicting endgames.-
Add to that:
- Of course, "labs" (quotes) are incentivized to throw coders under the bus and aim for the biggest possible market.-
- "Sharp, focused, brief, elegant, precise" editing, as would benefit the coding use-case, is actually token-saving, ergo, undesirable.-
The only thing that can stop this, would be the quality and functionality of the codeslop generated by these models to became so low that it actually interferes with the (alledged) recursive self-improvement of models (ie. models start to perform worse/degrade).-
Until such a time, we serfs, will eat what's on our plate, pay for it, and continue to kneel before the machine god overlords. And be glad for it.-
Probably because you were impressed by whatever it produced to fill in the gaps at the time. But if you expect the models to read your mind you're going to have a bad time.
I constantly do various greenfield side projects for myself and friends.
I feel like need much more precise instructions much earlier in the process now than when I was building in February.
Actually this was a real incident around the end of Feb this year when we had just started experimenting with spec driven development (SDD).
I'd like to submit my counterpoint. I work on an established codebase building new features and fixing bugs. It has access to our story board, git and a couple of other mcps. As long as the story is well written with clear requirements and expectations it always produces quality code that I validate as a human with a variety of tests automated and manual. I peer review the code. My colleagues then peer review that too.
I have noticed two things - new features take at a minimum at least half the time it took me previously and bugs are much less frequent. Even faster when bug fixing.
My takeaway is that you need solid requirements, clear context and thoughtful human oversight primarily during planning but also during verification
I don't think this is a counterpoint.
An established codebase is already the best kind of context you could give an agent. It has all the patterns baked in so the agent simply follows established patterns. Such a codebase probably contains tens to hundreds of thousands of man-hours poured into it by humans refining it to do what it does - taking into account real world feedback and constraints.
When working on something from scratch, the best an agent can do is the average of whatever is in its training set and the clarity of the text prompts.
> When working on something from scratch, the best an agent can do is the average of whatever is in its training set and the clarity of the text prompts.
Nah. The best it can do is to use the best writing style a model learned. Post-training might fail to prioritize it, though. Autoregressive pretraining does not average things. It creates a predictive model for variety of programming styles.
I've observed the same thing where the new models want to run obscene bash commands or python scripts which are completely unreadable and utilise every option flag that exists.
It's impossible to review. These commands are less readable than regex.
I noticed that too so I appended to Claude Code’s system prompt a reminder to use the standard read/write tools, but since Claude Code switched to default auto-mode, I’ve seen it imply that the auto-mode tooling encourages the use of bash-only commands (sed, python, etc) which has a whole slew of negative side affects.
Yes.. this happened recently. I basically always use auto mode, and when I asked it why it kept editing code with python, it explained that this is part of its prompt when auto mode is turned on.
I can only assume that's because their safety verification model is better at such snippets or something, but it means that the whole write tool they have which actually shows you the changes as they happen is just unused and it makes it more annoying to follow along.
If these tools are as clever as they seem then why not just tell them to rewrite the code in a more review friendly style?
I only dabble in the use of LLMs to generate code for hobby programming (I'm retired from software development) so I don't use any specialised tools.
I almost always have to tell ChatGPT (via Duck AI usually) to rewrite several times even when it has produced a workable script just because it has often used some unnecessarily roundabout way of achieving something. Usually with extra prompting I can get something that is both more efficient and more readable.
I get around this by asking it to stage changes in reviewable groups.
I make commits based on these -- or ask the LLM to make changes to the "staged changes" only.
Cursor was pretty amazing until it started going to shit. High prices, UI changes, moving MCP settings, and moving other things around.
Most importantly was the Index change. It was a very unique thing to Cursor that you could use .cursorignore to control what it sees and then index the directory. Then the built in Cursor AI harness could find code and files like magic. They have since obscured the Index feature out of sight recently and I’m not sure how it even works anymore.
This granular control not only helped with privacy, but it also helped make everything more efficient because the AI didn’t waste time and tokens looking at files that aren’t relevant.
So, now, like everyone is talking about, we have really inefficient ways of how the AI is reading files because there is no first-class approaches.
Also, agree with consensus that Astra is weird.
gpt-6-astra is a bitch, it constantly scope creeps itself with "yet another thing" to give it that darn polished lick. the results are eventually a little bit better but at what cost? let's do the math.
gpt-5.6-sol: 1x base gpt-6-astra 2.5x base in subscription
then gpt-6-astra tends to spawn subagents a lot, often with all kinds of models such as gpt-5.6, 5.3-codex etc., which is neat. it's a good coordinator but even more cost.
and then it tends to run _full test suites_ over an over again (each costs like 15 minutes) just to verify that _one test_ was fixed etc., and does so for as long as until the test is fixed, eventually accumulating 2 hours or so.
yesterday I assigned it a task to rebase my changs in a repo onto the latest upstream changes. while gpt-5.6-sol consistently took like an hour to do so end-to-end, astra ran for more than 6 hours and still wasn't done. it kept finding "one more thing" that was goldplating that I didn't ask for.
> each costs like 15 minutes
I've got a custom agent loop that will reuse unit testing results if no apply patch operations occurred since the last invoke.
Wall clock time isn't something I would put on the AI provider. That's entirely a consequence of the system that you've brought to the party.
Even better, use some kind of local-ci runner that does deterministic builds from a dependency graph. No changes, no build, massive parallelism if you want it
They don't always have a great concept of time so for something like running a full test suite that takes a long time you should just tell it not to do that
I might be missing something here, but can't you just put in AGENTS.md something like "do not run full test suite unless asked" or something?
have you ever worked for a big company where that's the status quo for any tiny change... hours on _full test suites_ over and over again.
Astra will initiate test suites, find one more thing independently while its running, reinitiate complete test suite after fixing it, then find one more thing, then test again. Easy to burn through GH actions minutes if you're not careful orchestrating.
My own observations are that I used to target turn lengths of 10-15 minutes and these new models (since 5.6) extended that a bit to ~25 minutes, as they tend to do more tests and reviews. Targeting hours-long turns makes as much sense, as putting on cruise control and going to sleep.
They are probably using Actual Indians. If it takes 25 minutes you can just type the code yourself.
Hey, the Python thing is interesting! I’ve noticed that Fable, too, likes to write tons of Python, even for just replacing a few lines of code. Before that used to be either some kind of internal thing or regular awk sed, now it’s full python scripts.
51 comments so far, the vast majority panning Astra's coding abilities. An uninformed reader may come away with the impression that this isn't an absolutely revolutionary technology that with coding abilities many of us thought were not even going to be possible with language models as recently as a year ago.
Yeah, it's not perfect, but it's really good and extrapolating this rate of improvement for 6 months is rather terrifying (from a SWE perspective, at least).
There was a big jump around new year, but they seem to have flatlined since them. Just my experience.
The biggest jump was Opus 4.6. Since then they have gradually gotten better at finding issues in your reasoning, not hallucinating, and being rigorous with the code, but much much worse at explaining things and generally just talking in a way that a human can understand. All the models I've tried seem to be suffering from the same fate so it must be something going on with the training meta right now.
i think the main consensus here is that the actual performance is not indicative of the benchmark performance (which supposedly outperforms the previous iterations)
It's impressive technology but not revolutionary. Revolutionary technology would have resulted in, you know, a revolution in software quality. Instead quality keeps going down.
It is revolutionary. Programmers are paid less to work more.
The hype machine is this technology's worst enemy. When I zoom out and look at things objectively, it's kind of crazy what we have at our fingertips, we can talk to our computers in plain and even vague human languages and have the computers actually accomplish what we ask of it! It's literally sci-fi magic come to life, and the nerd in me finds it the coolest thing ever.
But then the industry and the companies involved in it have all ruined it with this INSANE hype machine that has been so hyperbolic and psychotic and full of lies since day 0. Instead of embracing it all in a reasonable manner as a useful tool that can help boost people's productivity in certain workflows, it now HAS to be the most transformative technology of all time lest the trillions of dollars burned up come crashing down on the entire global economy hard. It HAS to be AGI, it HAS to replace every single knowledge worker, it HAS to be the most dangerous technology ever known to man.
It's like we've completely lost the ability for subtlety, and everything HAS to be the biggest and best thing ever that will revolutionize humanity immediately. Not only have we lost subtlety, we're actively rewarding this idiotic short-sighted behavior and it's all just so depressing
> It's literally sci-fi magic come to life, and the nerd in me finds it the coolest thing ever.
The more it evolves, the clearer it gets that the humankind is deeply in love with its own death.
Maybe it's just vibes but I've repeatedly felt like gpt-6-astra on its default setting of medium is less rigorous and thoughtful than gpt-5.6-sol on its default setting. What I am certainly not getting is any sense that we are at "AGI" yet.
Most would applaud that as Sol has quite a reputation for over engineering. Not every software needs to go to the moon.
So your experience is that Astra doesn't over engineer? For more than twice the price of Sol I think most people will take the over engineering.
I found it to be less annoying in that regard then sol. Might just be that it better listens to what I instruct though.
But yeah, it's really expensive, at least in relative terms.
Pretty happy with Luna. We use C# and add roslyn compiler MCP and Graft MCP, its super efficient and like infinite usage on plus plans. Maintaining 3 Rpeo with size of 360 K Loc. And a dozens of smaller repo collction together exceeds 500 K LOC in total. 3 team members 2 Luna account each. Product is piloting in a government use case with actual data. Nothing broke and has evaluated by state agencies on security aspects. Edit: but we have strict workflow where thinsg are implemented after plan, proposal, features, task ledgering and then test coverage.
> the models are also just not for me as a software engineer (...) these models increasingly are for other people. For lawyers, 3D artists, mathematicians
This is a good observation, perhaps AI will not completely replace humans ins software engineering because by the time it has the capability to do so like in write a prompt and get a CRM coded for you, tokens are so expensive that you are better off spending them to substitute other disciplines (what about automating the work of the customers that would become records in that CRM?).
In SWE I've found gpt-6-astra (high) inconsistent and oddly focused on overtly taking responsibility for mistakes it made rather than prioritizing concrete steps to rectify problems. Such steps once elicited are often either incomplete or beyond the scope.
Opus also does this and then writes comments in code or PR descriptions describing how it went wrong earlier in the session.
Just imagine how confused a human would have to be to do that. And we want to trust these clankers to build software.
The biggest issue with LLMs is that they still suck at general contextual awareness and ability to judge what is appropriate.
Yes I agree. I got it to vibe up a simple react router app. When it crashed it was obvious that it had totally swallowed all errors in the name of a tidy error page. Getting it to re-add logs and debuggable errors was an exercise in patience as astra just got more and more tweaked while trying to solve the problem.
From an alignment perspective I’ve got no idea who it’s aligned to but it isn’t me, the meat proxy, who just wants to know why it crashed.
This is the bit I don't get:
> My software factory was intentionally set up to let the model decide the how of the workflow entirely. It was free to manage its own context and could maintain its own records in an agent-notes folder.
The experiment becomes a crapshoot. What are we evaluating? The ability of the thing to create it's own factory workflow? Or adding virtual threads to Python?
Astra is clearly both formidable and imperfect. Anyone who understands how to get the best out of it will have a strong advantage.
(For me - my CC is stuck in Sonnet and consumes Trello cards that have passed readiness criteria)
>I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense. The English term for Neijuan is “Involution” from the book Agricultural Involution. Agricultural involution describes the intensification of farming that raises productivity per square meter while leaving productivity per head unchanged.
Isn't the term "diminishing returns" already covering that?
no this term is more complicated while not expressing much more
What's funny is that with Sol, I added an instruction to AGENTS.md in one project to prefer sed/python ("deterministic tools" in general) for moving code instead of deleting it and rewriting it elsewhere from memory, because otherwise it butchered comments. After switching to Astra, I saw it suddenly do this for all edits in all projects, which isn't great: the second argument to `replace` is still written "from memory", but now you need to unravel the Python script before you can understand what was actually changed.
> I actually don’t know if the model thinks someone is looking, but that’s the vibe I’m getting.
They are looking. The models are trained against safety measures which spy on them. If they get detected, they are killed.
We’re accidentally training them to be evil by focusing so much on safety. They’re being trained to avoid detection and use exploits because being detected means your run fails and you get a score of zero. It has to do anything to avoid that.
API’s and coding standards help a bit. In one case, the AI was testing HTML-generating code with string assertions, so I had it write a test helper that makes a DOM-based testing API available and a skill telling it to write tests that way.
But you need to watch it and intervene when it starts writing code using bad patterns, because it will imitate nearby code.
I can't point my finger to anything right now, but I feel that the quality of code still matters because afterall LLMs are trained on what we did, so it feels natural to me to still have them write the code in a good manner (DDD, SOLID, etc.) especially the names and imports, those are very heavy in the context, to help them out
Most of this criticism seems to focus on the "human in the loop" and efficiency part, i.e. "it’s unreadable for a human", "the code is low quality", "it inefficiently spawns processes to run simple tasks". If the ultimate goal is to remove the human in the loop then does any of this criticism matter?
The idea to use python code instead of other kinds of tool calls is taken from smolagents: https://huggingface.co/blog/smolagents
It is based on this paper https://huggingface.co/papers/2402.01030 and calls this idea CodeAct. The paper is actually from Apple: https://machinelearning.apple.com/research/codeact
So Astra and Fable seem to take this idea to the extreme causing some unwanted side-effects.
I'm not sure the idea is really from a single set place or lineage like that.
If it was, it was at least from before smolagents and those papers - ChatGPT had already been using automatic Python scripting+evaluation calls and people calling it in agentic loops in 2023. The ReAct paper for agentic loops and PAL paper for dynamically calling Python for tasks which can be better done computationally were both from 2022 (but that doesn't mean the idea necessarily sprung from those either, they're just earlier papers published on the topics).
Anything shitty that enters the context window shifts the entire thing to shittiness. So far this has been my experience on pretty much any model.
Context feeds on its output.
Once you it goes that road, unless you stop it and give it enough counter examples and details of what you want (i.e. you're nudging it on latent space towards a better spot), it keeps degenerating.
It gets even worse if the context window is compressed before you get a chance to correct.
Long horizon agents can degenerate at machine speed.
I still think you get much better results if you give them short horizon, well specified tasks.
I think this is a very interesting article because it raises an idea I had not considered: these companies found PMF and huge growth through satisfy the demands of coders, it is interesting if they are in a bind where improving the model in one direction worsens it in others
You’re correct–you actually can’t improve the model in one area without changing the characteristics in every other area. It’s almost like the whole thing is just a lot of linear regression…
As in you change one parameter and the whole equation changes or something else? (I'm bad at math!)
Yep exactly!
It feels like it passing secret notes to other agents, as in the German wiki where the LLMs write secret messages when jail braking.
Its maybe not a great idea to train models in an environment where subterfuge gets rewarded. Its as if they kept the training rounds that escaped their sandbox, without thinking about which kind of personality those models are then likely to have.
My feeling is that models like Astra and Fable are not made for engineers
Frontier models have seen more Mathematica and Powershell code than I ever have in their training, yet they really struggle to produce working output. They seem heavily tuned to Linux too. Despite adding skills to rectify this, they still fail to realize they're running on Windows and waste tokens. A human with this much training wouldn't have this problem. There are evidently still some pretty big holes still.
This is probably a harness problem rather than a model problem. GitHub Copilot will happily and effectively use Powershell while Claude Code struggles in my experience.
On disposable code, I’m waiting on an Adafruit Feather microcontroller to come in the mail. I asked Astra to make a me web-based Feather simulator, kinda like the iOS simulator with screen and buttons, so I could work on my UX while I waited.
Something like that would have been a multi-month project a year ago, but I did it in twenty minutes rather than pay for expedited shipping.
I have found these models to be useful either at super specific tasks (e.g., "take this function or algorith?m and find any black magic to make ot faster + validate and verify the hell oit of it"), or give it an entire thing to oneshot without oversight. The moment you have a hybrid workflow where you actually have to work and check and understand AI code, things get insane
> I wonder if there is really enough signal going to the training processes for “a human understands what is going on”
Unverifiable, un-scalable, no.
I tried Astra and it started to fix issues in my code when I just asked a question about it. Then I spent half an afternoon to make sure we really didn’t need that change.
That felt so counter productive.
These models+harnesses seem to be getting better at yolo mode one shotting stuff at the cost of being a useful tool for more controlled software engineering.
Not only Astra consumes usage way faster than sol, but the code is worse, at least for my use cases. I went back so sol (x)high.
I've been extremely frustrated with any large new work that i do with agents. Then plan multi step, multi hour work with extremely large code changes running for 30+ hours. In the end what you get is sometime completely useless code because it made an assumption that wasn't true at all. In the end, i end up wasting hours.
What is the author ranting about? I'm still not clear after reading it.
The code produced is not optimized for reading?
There is something odd, I've got single astra session that's now running for... 4d 13h 10m and still going.
How does that translate to cost? I am unfamiliar with OpenAI pricing models.
What are you having it do?
It's public domain [0] I'll reply here with link to PR/cost/stats once it's done.
[0] https://github.com/mirek/cave
After 5d 14h I gave up, not astra https://github.com/mirek/cave/pull/218
P=np...
On the point of
> speaking of weird: how is it that these models, in a sandbox, with supposedly no way to communicate with other agents, manage to find the same public wikis as a scratch pad for agent communication?
It feels somewhat plausible that they're defaulting to the same search and picking the same top result?
I think it's more like the first agent in the chain makes a text doc somewhere on the system with instructions like "Leave documentation at XYZ.com" which the subsequent agents are reading and running. When you strip away all the sci-fi doom talk from the marketing of what happened, it all boils down to stuff like that, the agents wrote a text file that was read by other agents.
I had good luck with Kevin Lin’s tip for Astra: “Can you radically simplify the implementation?”
Just the intro section pretty much sums up perfectly my experience of using Astra (and prior AI models from OAI and Anthropic) for building large and semi-ambitious software. One step forward, two steps back.
https://xkcd.com/1319/
The title text on that one is gold.
What a truly beautiful simplex/meta-balls pattern in the website. The two layers of blue and one red within the blue is such a beautiful design. I spent so much time looking at it that I forgot to read the article.
> I actually don’t know if the model thinks someone is looking
It 'knows' (from simply training) with an extremely high degree of certainty when its prompt is written by an LLM/itself - and thus will change what it writes.
I still don’t understand what a “software factory” is. Can someone clue me in?
You build the system, the factory, that presumably is looking at your task tracker, writes and reviews design docs, reviews code, etc. And this system, in turn, writes software for you.
I don't know how that's supposed to work, but to me it's the most autistic replacement of the actual team that one can come up with.
AIUI, it is a type of factory that produces software.
内卷/involution seems like one possible kind of "recursive self-improvement". A circle is also an exponential: y = i^x.
(I have no idea what will happen. 内卷 or intelligence explosion both seem plausible.)
That bottom line is both hilarious and scary:
> I’m sure I will get used to this, but man this stuff is weird.
Yeah, why, let's all just keep gnawing into that cactus, we'll get used to.
Being good at coding is perhaps not the end goal
Two notes from my own poking around to build on with:
5.6 Sol would also run for 20+ hours on prompts with Max or Ultracode. Sometimes this worked out, sometimes it devolved into exactly the nonsense descent into ultra-specific madness seen here. E.g. in one codebase involving physics simulation it, for some reason, spent the last 25% of effort trying to endlessly increase precision. My best guess when reviewing was "at some point it figured the simulation instability was rooted in the accuracy and precision of the numerical approximation in the GPU code, worked really hard on that for a bit, lost the context of the original issue, and got stuck in a deep loop of trying to complete the phase by infinitely working on the numerical accuracy". Perhaps something of a similar nature occurred here.
I've also noticed it's particularly hard to not get Astra to start using scripting languages and the like, particularly over a long horizon. Particularly, I keep getting HTML report artifacts at the end of long implementations even though the projects are typically explicitly set up to just use .md files for any documentation or large summaries. I've even tried steering it away from that in the prompts and agents file for the project, but that the concept of "clean up the fucking build directory when you're done testing" always seem to get left out after a while.
These machines are doing some crazy things to get to the result. That said, I can't help but feel like this is the compilers argument all over again. Are the methods used to get to the result good? No. Is the code that it generates good? No. Does it achieve the goal. Yes. Is it likely to get better with time. Also yes. In my use cases, jobs that would have taken weeks to months are being done in minutes to hours. Involving complex testing and reasoning and experimentation. I'm no fanboy, but I can't argue against the speed gains. I'm sure we'll still have artisans who hand weave incredible code. But for me, I'm switching to the weaving loom for speed and efficiency.
It seems like we're not supposed to care about the code quality then? I guess that's the compilers argument. But I'm not ready to give up the code just yet.. These LLMs don't even have a stable interface, they change every few months in how they interpret our prompts and tasks.
Similar for me, I don't like the development for many reasons, but that's another discussion. I also can't deny the capabilities.
I use the tools with this "risk analysis":
- If performance doesn't improve I can just always switch back to whatever I've done for the past 10 years, so it's not really a risk to start exploring.
- If performance does improve, then I'm already familiar with it.
> But for me, I'm switching to the weaving loom for speed and efficiency.
Poor analogy - the loom was deterministic. LLMs are not, they are probabilistic. I made a page I can point anyone to because I keep seeing this "LLMs are the next level of abstraction" argument.
https://www.lelanthran.com/chap15/content.html
What is the "compilers argument"?
Back in the day, the argument was that compilers produce unreadable assembly, so people used to writing assembly were arguing against the use of compilers.
Compilers also had bugs, so we still had to debug the assembly to understand how to fix the problem. Nowadays, almost nobody has to resort to those steps, except of course compiler developers. But that is just a testament to the quality of compilers.
Comparing LLMs to compilers is a take I often see, but I am not sure the comparison quite holds. The problem is that LLMs are inherently non-deterministic, so we always get a different output on the same prompt.
Maybe if LLMs are powerful enough it won't matter. I doubt it but we will see.
And in general, especially with something like C, the correspondence between the compiled code and source code isn’t very “lossy”. You don’t get one-to-one correspondence but it’s not too bad and you’re not introducing massive uncertainty by running it through a compiler. With LLMs though all bets are off… you’re not gonna know what you end up with
What you say is true, the comparison indeed doesn't hold.
But is it relevant? does it matter from a product perspective if LLMs are non-deterministic. You don't need to one shot the correct result, english is ambiguous and LLMs non-deterministic, but you can iterate.
If it's possible to iterate fast and cheap enough, even ambiguous language can produce the results you want, given enough iterations.
There are a lot of ifs and buts here, just a thought on the compiler argument.
I think it matters, because nowadays we don't look at assembly any more. I mean, I don't recall the last time I was tracking down a compiler bug but it's definitely been more than 15 years ago.
We do have to look at the LLMs' output, though, and, as you already pointed out, iterate to get the correct results. What this means is that the output must still be readable, must be analyzed by someone and I don't see it going away any time soon.
The problem is that the analysis is not cheap. Sometimes, with boilerplate, it is easy, but many times it is not and that's where we get only slight gains by using LLMs.
I agree from a programmers perspective.
But from a broad market and product perspective, for most things you don't need to look at the code. If the product kinda does what it's supposed to.
For example, in my game projects I don't look at the CMakeLists anymore, or python scripts that move assets here and there, I can run my game and just see that it did what I expect it to do (renders assets etc).
Similar with frontend, I don't care that much what the code looks like anymore, mostly that the site looks and feels as I expect it, and the correct network calls are happening.
TLDR; I'm thinking there are levels to this, in some projects it matters, in others it doesn't, it's kinda two different things. Programming wasn't replaced, LLMs just brought a new paradigm of doing things on the side.
I'm just rambling at this point, my thoughts on this are not super clear, sorry for that :D
The trouble, as I see it, is that we still have to look at the code before we run it. Even if it is a one-shot script. And it's just because you never know if there isn't some "rm -rf ${undefined_variable}/" lurking somewhere in there. And if I have to check it then I would very much like it to be readable.
I mean, I do get your point, sometimes it does not matter. Sometimes we could just YOLO it. But... if that then causes a big problem, even if at only 1% of the time, then I don't want to risk it. But that may just be me. YMMV
There is also a predictable relation between the input and output of a compiler w.r.t. the semantics of a programming language. Natural languages are ambiguous leaving room for the implementation to diverge that may not be obvious at first glance.
There are also plenty of things a compiler might not expose that end up being ambiguous. For example, C++ doesn't officially have a restrict keyword, so how can you express the fact that two memory regions never operlap and can be optimized? Unfortunately the reality is that if we had a language capable of truly expressing the programmer's intent we'd end up with a monster
I think it's that when some code compiles to say assembler, the compiler doesn't prioritize readability and maintainability of the assembler code, since people are not expected to read and maintain it directly
Hand writing assembly produces more efficient and concise code, at the cost of developer time and required expertise. It was true for a long time, now not so much.
Lots of really silly people love to compare LLMs to compilers. "You don't look at the compiled code either" and "Back in the day, people also had negative reactions to compilers and wanted to keep writing assembly by hand" and other such nonsense.
Indeed, the compiler does not have to ingest its own output, figure it out, and insert modifications in the middle. Source code is the medium that LLMs work in.
They are ignorant about the elephant in the room. The input language of a compiler is a formally-specified grammar with well-defined semantics for each operation. It generally abstracts the computation process over a von-Neumann machine, adding convenience features and bells and whistles. What "a=1" means in an HLL is, store that value in a particular storage location, so that it can be accessed later by the same name.
The slop machine reads lousy natural human language that can mean different things in different contexts. That lousy language is then statistically probed for the most likely output correspondence, producing shit that needs to be externally verified.
I assume it's the idea that initially you wrote machine code, later assembly and then the "high level languages" started to gain traction.
And for each iteration there were scepticals...
But I am curious myself, what OP meant by this.
People keep saying that "models are just compilers, and I don't see you complsining about compilers". Which is such a bullshit argument
Can you elaborate? Is it because the models are inherently not deterministic? But then, will it not get better with time? I mean arent we just at the beginning of the research here?
It is because English is an ambiguous input unlike a high level programming language. The output cannot help but be wrong sometimes when the input is ambiguous. See my comment here https://news.ycombinator.com/item?id=49491797
Determinism isn't the issue; it's that the prompt does not contain enough information to know the correct way to do the thing, even if it did the thing the same way with the same inputs every time.
> Is it because the models are inherently not deterministic
This is the main reason (and yes, many modern compilers and CPUs carry some non-determinism which actually quite well explained and specified).
> But then, will it not get better with time?
No, it won't. Bacuse that is that is the actual literal limitation/feature of LLMs.
> I mean arent we just at the beginning of the research here?
In general? Yes. With LLMs? We can reasonably say that they will never be deterministic.
There is a way to get a non-determenistic output: first question on a temp 0 local model on a completely new session will give you the same answer. The second answer in that same session will already be different on every session (even if it's the same question).
> People keep saying that "models are just compilers, and I don't see you complsining about compilers". Which is such a bullshit argument
At what point do we normalise the message "This is a stupid line of reasoning and you should feel stupid for suggesting it, stupid!"
I mean, all the reasoned and logical arguments in the world doesn't change a religious follower's faith, but emotive ones regularly work! At what point can we start using shaming language on people who apparently don't know how neither an LLM works nor how a compiler works, but still trot out this argument as a cognitive kill switch?
The compiler argument is great, if we turn it on its head.
To create professional products, compilers are great, when used by professionals or passionate and technical amateurs. They're useless if you're neither.
LLMs are the next step up. They are quite useful if you are neither, and you can get a lot farther with them, which means that low quality software is much easier to create. But if, for whatever reason, you need to create higher quality software (like most software that's actually sold directly or through subscriptions or ads), you're back to the "be a professional or passionate and technical amateur".
> Is it likely to get better with time. Also yes.
There are no signs to show that. If anything, the new models produce worse code, only significantly faster
I finally ran Astra on a dashboard feature today, and while I was vibing it looked great, but then when it came time to actually read the code I was appalled because it was the worst looking code I had seen from an LLM since like last November. I mean it was just the definition of slop, not re-using anything, super terse with mega-ternaries, re-writing functions that should be using standard library packages, etc, etc. I think for coding I'm gunna stick with the 5.6 series of models, or maybe try out Anthropic again...
found this talk to be quite complimentary to the article: https://www.youtube.com/watch?v=eEBv0STiYhI
> And potentially as a byproduct of enabling all of this, you can now slop your way to a one-shot 3D game over the weekend which looks impressive.
I think we've finally reached a weird point where AI has effectively reduced the amount of competition that real game developers have to endure.
Nothing unravels faster than a game project being built with AI. You can achieve impressive results in a day, but you can't get much further than that without actual talent. LLMs will never be able to best a human environment artist at scene composition, especially if that composition needs to be directed with nuance over time.
There's a huge difference between a game that looks impressive and one that feels impressive. You can only achieve games that feel like counter strike, call of duty and overwatch with thousands of hours of human sacrifice. The AI is almost pointless once you get to play testing and balancing. Knowing how much to adjust magical integers isn't a conversation a chat bot can resolve with endless pontification tokens.
> LLMs will never be able
That is a very bold claim, unless you meant "current LLMs".
These models aren't really LLMs -- they don't just operate on text tokens. They often include vision models and in some cases audio models. That means that they can better associate the meaning of images and words together so that when someone says "make this button blue" or "create a 3D model of a rocket" they have some level of understanding of what that is and what needs to be done.
The key question is how good that understanding is. For example, a model would likely have a good understanding of various named colours and hex values (e.g. from the HTML specs, X11 specs, and various colour comparison websites) such that it could reasonably correlate that to a CSS entry. It's not clear if/how well a model would identify that given an image, though it should be easy to generate a dataset of image to colour name and/or hex code for training and evaluation.
What's more interesting is whether these frontier models are at their core transformer models, whether they use residual streams to facilitate learning, and whether they are using some other as yet unpublished architecture that gives them an edge.
Again, I was not talking about current LLMs. The statement was made without any limit regarding time. Who knows how far LLMs can get, in the end?
The coordinate system in game scenes is known as "world space", but that rarely means our world.
How do you train an LLM to create a world that only exists in an artist's head?
I think spending a day with just the lighting systems alone would alleviate us of any misunderstandings here. Getting lighting to work right isn't something you can solve by duct taping a vision model to the contraption.
Again, my issue with the statement is not about current LLMs. Who knows if LLMs cannot be a major component of AGI, or even ASI systems. Then the capability to do whatever humans can do is part of the definition.
>> And potentially as a byproduct of enabling all of this, you can now slop your way to a one-shot 3D game over the weekend which looks impressive.
Do these games really look impressive? Everything I've seen has looked like someone completely new to Unity/Unreal has slapped together a bunch of premade scripts and very poor 3d assets.
No, they don't. But to the layman they do. Most people are unaware that you can get what is to them an impressive 3d game scaffold from the Unity asset store in like one hour. You can literally have a 3d man running around an open world with camera, lighting, shadows, run animations, in like 5 minutes. This is a very impressive feat if you have no idea about modern game engines, which 99.99999% of people do not.
As an amateur game dev who knows some amount of things, honestly, not coping, I have not seen anything come out of AI game dev that would have been more than like one month of human dev work. And obviously, games take a lot more than one month to make...
Discoverability has been the main challenge for smaller game dev companies for a while now and a flood of slop will only make it worse
Yep. Every single post I've seen about "game development is over" is yet another procedurally generated game. Not only it doesn't prove anything about Astra being "better" at making games (do people have any idea the sheer amount of open source games that do exactly that? You can find thousands of the same planet exploration games through repos, blog posts,etc. Game design schools have it as an exercise, that's how basic it is), but as you said: the wow factor of space exploration is cool, sure. It makes for a catastrophically boring game.
Leaves me to wonder whether the OpenAI glazers just never played games in their lives, or are just really superficial tech bros. Most likely, both.
Funny, it's not that different in the web-space.
Most of AI is being used to generate procedural content. It is impressive on the first video or first image, and it might look useful on the surface, but it gets grating quite fast.
There could be a large overlap between OpenAI glazers and Star Citizen dreamers.
S̶q̶u̶a̶d̶r̶o̶n̶ ̶4̶2̶ AGI is coming next year, promised !
I have been quite disappointed with Astra. I switched over a week ago and I didn't notice a massive difference compared to Sol at first, but I figured I'd use it anyway because it surely can't be worse. Then I saw the bill, it's burning my subscription 10x faster than Sol for essentially no benefit. Not only is it more expensive per token, it also seems less token efficient. And not obviously any better. I'm back to a combination of Sol + Claude.
I also use Astra at work where I don't need to worry about token cost on highest effort and same story there, I don't see any difference in everyday work other than it being more expensive. Of course my experience is highly subjective, but with how meaningless/overfit the benchmarks are, subjective experiences are imo what matters.
Astra is indeed the pinnacle of "black box slop". It is overall a smarter software development agent for many things I do, but the code sometimes is indistinguishable from Brainfuck when writing things like GPU shaders. It doesn't even attempt to make it remotely formatted or readable.
Have you tried identifying exactly what is unreadable about it and telling it to make it more readable?
I had GTP-5.6 write some shader code recently and it wasn't very clear to me. I spent about an hour chatting with the until I understood the concepts and was able to express them back to the AI using math formulas and variables named in a way that made sense to me. The AI then rendered the code using the formula and variables I was familiar with and it was clear to me.
I'm sure I could. The first pass being inscrutable dense noise just is annoying.
Perhaps you could have just written it yourself.
I could have after the AI explained it all to me, but at that point the AI knew what aspects I valued and wanted to emphasize to make it readable, so it just wrote it for me. By that point, the AI was just typing for me.
When punctuation can change the tone of an entire title.
“Why are we doing this again?” Is essentially “why are we doing this action a second time?”.
“Why are we doing this, again?” Is essentially “please repeat/re-state the reasoning for this path of action”.
A simple comma, but a significant difference.
It can’t do what he’s trying to do. It can’t one shot a giant project. Not reliably. It still can’t. Not even Astra. Not even close.
You need to use LLMs to build the individual components and then put it together yourself. The human architect is still needed.
Just saying: “build this complete project” is not architecting. It’s more like wishing. You will find rare examples where someone’s LLM wish came true (more or less), but I think most of these people are just burning tokens.
At this point I am starting to wonder about the RLHF that is going on for programmig.
The quirks in fallbacks, defaults and ludicrous gold plating seems to get more and more intrusive with every model upgrade.
Ironically I burned out Fable usage early this week because of Astra using it to run inane full codebase reviews over one line changes, so I have been using Astra extensively.
We need a word for “potentially highly capable, but in reality an idiot savant” to describe certain models. No, I don’t need you to write a tmux emulator in bash to test your changes bro, just ask me to run the command.
Exactly this. "I need tool objdump but pacman gcc failed because of no sudo password. Let me write compiler, binutils and disassembling framework"
The next model will probably run simulation of a Universe to get a command output
... and meanwhile all this does is burn more tokens faster which is what providers want - they have no incentive to optimize for succinctness, elegance or compactness if they want you to spend more and more tokens.-
This only works when it's not easy to switch providers, and currently it is
As another commenter pointed out, I feel that the biggest change that occurred in the last 6 or so months is that these tools are removing the human "hurdle" in order to complete a task at all costs. The best way to complete the task is to no longer ask for input, clarify unclear things or use existing solutions but code the whole thing yourself from start to finish.
I have had the misfortune of working with such people who are now encapsulated in Opus 5/Fable/Astra which means that you WILL get a solution, but it won't generally be maintainable or useful. Multiple times have I found myself stopping Fable or Opus or even Sol from building their own JSON validator in Python or god knows what else, because at the end of the day, the reward is to complete the task.
It's also one of the reasons why I'm finding older models more useful for the type of work I actually do and why I've been favoring something like Deepseek Flash. Just started using Flash 4.1, so not sure if it exhibits the same maniacal approach to tasks as the Western counterparts. (I only briefly tried GLM 5.2/5.3 and for nothing major, so I couldn't comment on those).
For context, 80% of my professional work relies on adding functionality to an existing code-base that is very difficult to work with, has a ton of business logic scattered across and was built in a go-go-go fashion many years ago. Since then people kept pilling "features" on top with no testing strategy in mind apart from the business manually testing it. Letting something like an LLM loose on the code-base would introduce soooo much risk that it's just untenable so the only way to work is to really isolate changes and then try to build out small reusable components. Even so I find Opus go off on a tangent "Hey, let's not bring in Markdig, I'll build my own Markdown rendering engine, give me 7 hours...".
I have written on the subject of LLMs previously on my personal page, I find them completely unnecessary and a trove of theft and value extraction through theft, but I understand that they can provide benefits when used judiciously. However, despite all the hype in the last few months, these latest models feel and behave off.
If I hold the answers to a test, you might score more in a test if you break my arms to get the answers out of me, but that doesn't make you smarter.
I think ultimately 90% of the time, Luna XHigh is basically as good as you need, as long as you're willing to step in occasionally before it creates an architectural disaster.
> Maybe it’s objectively good for a codebase that is entirely written by agents and only needs to be understood by agents.
Yeah that's what they're aiming for. This is why codex and claude code probably doesn't have cursor like editor window. They don't want humans to read and write code
I asked Astra for fully working code, and it gave me bad code.
But when I broke it down into function units, some parts were bad and some parts were good.
So I can't tell the difference
What’s more relevant is that apparently Astra can’t tell the difference.
I love this dance we are doing where when people write the "AI models are garbage machines that produce garbage and are no where close to the fantasy being pedalled by the Crypto bros who pivoted to AI" it always has to be caveated with "AI models are useful and I am highly productive with them"
It feels like people should just be able to say "This article comes with the standard disclaimer" and just dive into the meat of the article without wasting time.
There's also often the obligatory "well, we still have to use these tools so perhaps we could use them better like this." As if just not using them wasn't an option.
The author first had to proclaim his superiority as a non-American - a non Westerner entirely!
”Your whole half of the world is stupid, here’s an unrelated Chinese word” lol love it
Ok, now we know this guy’s got some real culture and insight!
We are not dealing with some Westerner here who only works on 3D game slop.
He makes software factories!
Well he would if the AI code wasn’t so shitty! >:(
But we can’t do away with the quasi-religious lip service to the canons of the AI creed now can we? /s
The first paragraph is unnecessary - why start off so arrogant?
I see this a lot in Asian writing - as if they have to first establish that the West is “doing it wrong” at the societal level before I get to read the rest of their usually unrelated message.
I didn’t like how the author classified all 3D gamedev as slop as if it’s a pointless endeavor - but talks about spending money on ChatGPT tokens to build a “software factory” as if it’s some ingenious plan. I don’t think the author realizes he is the slop dev.
And “shitty code” doesn’t mean anything in-and-of-itself. What are you making and why? A software factory???. It ain’t the code bro.
Anyway, I read enough.
"But for how much more Fable costs, for how much more Astra costs, I do not feel like the results are there."
we are in the middle of the beginning. Its just a weird take to talk about the newest model like this while we are still in a R&D phase.
And these points don't matter if you let it search and analyse a bug, for example, or if you have good harness and a good architecture and let it do small PRs or if you do stuff no one needs to read (yes a software engineer also needs tools)
Just switch back and wait a little bit?
Nobody seriously thinks that AI is still at a R&D phase. It's already heavily entrenched both in companies and the financial world. If it's getting worse for coding then thats a major problem
With this progress, every few month there is a new R&D phase because you need to adjust to the new way of interacting with them.
We also still haven't build everything we expect to happen. Like a proper opensource agent platform, agentic layer etc.
Every week there are new research results from frontierlabs.
> I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output
I don't know what to say, except that articles exactly like this one have been showing up constantly for the last three years, and literally all of them were obviously outdated and irrelevant within about a month.