I have artist friends - asking AI to draw something similar to subjects they've drawn ends up making, line for line, the exact image they created, hallucinated alongside a couple others. They spent decades getting good at their craft. They spent so many years getting paying patrons and customers to commission them.
You'll never agree but I think you underestimate how many people consider all that the AI companies have done to be the wealthy stealing and selling things back.
> nor are the people involved selling it back in any form
I am convinced that the longer one works in AI the less one has any grasp on reality
> too cheap to meter
Its the most expensive buildout in human history - you can't just split half the cost. The spending is the only significant growth in the US economy. Unless you think that all the datacenters and all that capex are for training?
I have horse & wagon friends - they spent decades understanding the ins and outs of roads, some of them also creatively made up their own routes and roads.
However ordering a car with Uber through your phone just gets people to the destination faster, cheaper, more comfortably and reliably using those same roads.
Depends what you’re doing. Constraints are different between projects, and advice given for how to utilize AI rarely takes that into account.
Don’t sling when you need to craft, and don’t craft when you need to sling. Knowing the difference matters more, and you can spend your entire career on one side or another.
Craft was premised on the idea that a good writing and composition matters because it would be easier to read and comprehend (sometimes accepted by orgs because it was sold as cheaper).
Now AI can read the code so the craft-leaning people would need to somehow sell it as 'fewer tokens will be spent on a well factored code' or 'well factored code reduces AI hallucinations'?
Now a Slinger (using your terminology) can just ask AI to make the code look 'craftier' - and that is the best case scenario.
In other words, they will not buy what we sell and if they will they can now produce the results for cheaper. Overlooking the devil in the details, as usual.
If they were the moral people they say they are, and believed what they say about it killing humanity they would stop unilaterally. These are the “rationalists” but they act like the fundamentalist church I grew up in. Every fact serves the same conclusion.
> Biological misuse is one of the most serious risks of frontier AI models. It has long been a concern that AI models might one day reach the level of capability where they can help to make existing pathogens more dangerous—or create entirely new ones. Without the correct safeguards, such capabilities could have catastrophic consequences.
Results from evaluations of older models (for example Claude Opus 4 and Claude Sonnet 4.5, from 2025) clearly showed that these models were well below the threshold where they could meaningfully assist a sophisticated user in carrying out dangerous biological research. As a result, safeguards on these models were less stringent, directed mostly at preventing access to content that might uplift novices in recreating known bioweapons. But for today’s models—which are capable of assisting in a range of complex scientific research tasks—the evidence is no longer certain, and we cannot make that same assurance. For this reason, and out of an abundance of caution, we have launched recent models (most notably Claude Fable 5) with stronger safeguards that restrict access to a wide range of dual-use biological research queries.
...
Here, we present five case studies of actors using our models in ways that could support biological weapons development. These examples are illustrative of the kinds of tasks to which our models are put, and the often-difficult judgements we have to make when assessing whether or not a given biological use is dangerous. They also convey that we encounter what would otherwise be non-public insight into the risks associated with biological misuse from AI
No, previously a single person could effect only a single person's worth of terror. Now, a single person can effect thousands or hundreds of thousands of 'persons' effort towards terror.
This isn't really a fear of technology, it's a fear of one person being able to harness an entire country of geniuses towards some bad end.
I haven't found anyone who isn't working for OpenAI/Anthropic, or isn't selling a solution. There seems to be very little organic takeup - either out of budgetary reasons, or more likely ineffectiveness relative to ephemeral jobs.
I find this explanation has a lot of applications for programmers within companies. It’s one thing to get your LLM to give an answer, it’s another to bring a group of people into shared understanding of a domain.
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.
We're what, several decades into this modern software engineering thing and even stuff like DRY, let alone SOLID or whatever, still isn't an universal thing.
Do whatever works for you, talk to other people, see what they do day to day, watch other people whose products you've used or whose architecture/code you've read and liked do, and don't fret too much.
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.
No company is measured by "value provided" on any market, it's a feel-good metric. And you\re playing word-games now despite even saying you're not trying. Like I stated earlier, it's entirely a sophomoric take. And now I understand why.
I’ll try to explain value provided a bit. I think it’s a useful concept to share.
A company or organization, generally speaking, has a purpose. It either produces something for or provides a service to end customers which they perceive as valuable. Over time, a company figures out what that purpose is and what it is not. If you are trying to manage a company and you are fixated on dollars, you’re usually not adding anything useful. You’ll likely make decisions completely misaligned with the purpose of the company. If you run a business by jumping from department to department trying to figure out how to maximize profit, you’re just an administrator looking to squeeze efficiency out of existing processes. You want some employees who do this, but it’s certainly not going to keep your company alive and relevant for the long term in an evolving market.
Instead, you want to be jumping between departments trying to figure out if the core value proposition of the company is being realized. Are you maximizing value provided to your customers? Is your value proposition still relevant?
Chasing value is targeted and intelligent. You’re correct that it’s much harder to create metrics for this, but the metrics you find are substantially more useful than profit margins. These metrics tell you if you’re succeeding.
If you’re providing value and profit is an issue, then you either charge more or you never had a viable business model in the first place.
Early stage companies chase cashflow by necessity. But once you’re no longer early stage and you have a margin of safety and some success, you can start to think differently. Chasing dollars at this point might put you out of business. Chasing value provided to your end customers leads to substantially more opportunities for continued success.
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.
> 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.
> There is no irony because I have seen humans do the same thing.
Your original comment started with the sentence:
> I am currently writing a lot of code that I am not reviewing anymore.
Then you give an example of catching a bad pattern the LLMs used when you actually reviewed the code, after you mentioned you had multiple agents set up to catch each others mistakes. That is the irony. You're mentioning that LLMs engage in basic bad coding patterns that are not caught by multiple agents, hence underlining the importance of human review.
> There is no irony because I have seen humans do the same thing.
Yes, but you were reviewing the humans. You're not reviewing the LLMs.
> I set up excellent testing the same way a CTO would set up excellent testing.
Knowing LLMs can make basic coding pattern mistakes (as you mention) but still unleashing them on your tests without routine human review that makes sure that test suites have not been negatively affected after each iteration seems like the polar opposite of consistantly maintaining excellent testing throughout the software development process.
So, only use it for small codebases, don't use it if you value code quality or readability, and it's really good at building a CRUD app demo? I'm shocked. This is all completely new information.
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.
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.
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 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.
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.
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.
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.
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.
> 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?
The problem is the litany of people below this comment say “they get great results”, with zero sources or examples to back any of it up. Is there a showcase, or “Claude’s Hall of Fame” with a list of Git repos full of production-ready, rock solid code to shut up the naysayers? If not, then I can only think of one reason why not (such examples don’t exist).
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.
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.
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
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.
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.
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)
> 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!
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.
> 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.
reply