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 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.
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.
Kinda reminds me of the "beginner's luck" problem for gamblers.
- 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.
> 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?
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?
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.
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.
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.
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.
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.
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?
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".
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.
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.
But that requires actually reading the output, which I am pretty certain only a rounding error of programmers are doing at this point.
Blame the benchmarks game. They're optimizing for that and that's what those things are measuring.
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 sideI 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.
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.
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.
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.
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.
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.
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.
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).
> 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.
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.
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?
This resonates
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.)
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’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.
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)
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.
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.
I definitely need AI help for the discovery part… so it always starts with a simple “I need to do X”
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.
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.
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:
At which point you might as well write the code yourself and get a deterministic result faster, better and cheaper.
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.
Around February you could get away with very vague prompts to Claude. I feel like models have regressed since
I honestly feel like basically nobody knows anything about these models, it's all just vibes (and I'm no different).
> 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.
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.-
I feel like need much more precise instructions much earlier in the process now than when I was building in February.
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.
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..)
Or something, I don't remember...
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.
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...
How dared I to imply that some LLM output is more deterministic than the other, your LLM majesty. Shame on me and my entire family! For generations to come!
So sorry I implied that the code that doesn't work and has to be fixed later is deterministic in its execution and can be reused later instead of being re-generated from scratch!
Will I ever wash it off my name, your grace?
I wonder, is it easier to modify a script that agent wrote before to satisfy your prompt, or is it easier to write a new one from scratch each time a retry happens?
Are input tokens more expensive than output tokens?
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 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.
It's impossible to review. These commands are less readable than regex.
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.
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 make commits based on these -- or ask the LLM to make changes to the "staged changes" only.
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.
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.
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 issue with LLMs is that they still suck at general contextual awareness and ability to judge what is appropriate.
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.
But yeah, it's really expensive, at least in relative terms.
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
The more it evolves, the clearer it gets that the humankind is deeply in love with its own death.
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?).
> 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)
Isn't the term "diminishing returns" already covering that?
> 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’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.
(I have no idea what will happen. 内卷 or intelligence explosion both seem plausible.)
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.
Unverifiable, un-scalable, no.
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.
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.
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.
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.
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.
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.
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 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.
And for each iteration there were scepticals...
But I am curious myself, what OP meant by this.
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?
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".
There are no signs to show that. If anything, the new models produce worse code, only significantly faster
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.
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.
That is a very bold claim, unless you meant "current LLMs".
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.
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.
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.
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 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.
The quirks in fallbacks, defaults and ludicrous gold plating seems to get more and more intrusive with every model upgrade.
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
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
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.
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.
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.
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?
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.