I don't really give them an excuse for the "10x load increase". The company that owns GitHub is literally a hyperscaler. If they can't handle the scale, there's something seriously wrong at Azure.

You are too civilized: I recommend threatening drop kicks to insufficiently smart rebuttlers.

And as long as we keep changing the meaning of coding!

Ironic, given I've used an agent to help me simulate a fusion reactor.

Just a simple reactor, my laptop's only little. But still.

Skill issue duh..

Yup. Something the article points out is that they write code better than a few, some, or many humans do - with that list below the six fingers, and how that correlates to whether one is part of the "coding is dead" crowd.

LLMs even a version number or two ago can write all the code I've ever been paid to write in the last 20 years; but they are not, I think, yet competent enough to be able to handle the project planning and self-QA I was doing even in my first 6 months of my first job after graduating.

That's not a boast, I don't think I was particularly good at that back then, e.g. I didn't really get how to think about automated tests until much later.

It's just to say that no, coding and software engineering are not the same thing. "Code Monkey" is a dead (or perhaps "undead") role now, but it wasn't always so.

I'm sure Opus 5.5 is smart and probably the next version gets even smarter. The main point of the article is accountability and that's not something we can delegate to AI.

This is true, real, and impressive. However, a comment I posted on HN a couple months ago might counterbalance this fact:

GitHub's Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement or documentation that creates real disruption for our team.

That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod. Again with zero public announcement or documentation.

Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.

File by file porting can be done almost always with local reasoning. I don't think it proves much for novel projects which still seems to crumble under complexity past a small sloc limit.

I'm absolutely saying that AI has sped up the porting and rewrite process! It is amazing! But the reality is that rewriting has been part of programming culture since time immemorial. People want to rewrite for performance or for other reasons all the time, and the cost is now relatively low (i.e., now it's an opex line item in cash instead of time investment). But that doesn't mean that all of coding has been solved.

For example, any amount of software development involves fixing bugs, getting feedback from users on ideal workflows, an iteration loop of performance and bug tuning, etc. AI cannot simply create, from scratch, perfect software. Even using the SOTA models on max effort does not produce bug free software of any meaningful complexity or innovation out of the box. All that has changed is that the act of physically writing code and implementing existing patterns is now effectively a marginal cost.

Most line of business software is not e.g., delivering a company's income. Most software is in back-of-the-house internal products that do various internal tasks. I have no doubt that these processes are now far easier to build.

If the new Copilot is so great, why is it completely out of the current zeitgeist when compared to Codex and Claude Code?

Rust to JS? Pffft, how about reverse engineering old games without source code and porting them to JS?

https://georgzoeller.com/blog/posts/what-reverse-engineering...

Impressive numbers for a piece of software no one asked for and doesn't make the experience better.

it occurs to me how much better these things endeavors might go if the prompt was

"write a program to transpile A to B" instead of "port A to B"

If you think it would have taken a single engineer one year to do this, you must not work in the industry. This would have taken multiple engineers at least a year.

$120k ... equivalent to the all-in cost of a senior engineer in London for a year.

The most shocking thing I've read in this entire thread. Are SWE salaries really that low across the pond? That's entry level in the US. So 90k GBP a year all in, including benefits, employer-paid taxes, seat licenses, hardware, furniture, HR? So what's the after-tax takehome for someone senior enough to convert an enterprise codebase to a new language over one year?

...and what's your point? Github isn't exactly a beacon of performance or robustness in recent months...

sounds like 2x the code that no one understands, one more reason to never consider using copilot again

would be curious to know how many times "unsafe" appears in there, have seen rust devs comment on how the ais like to use unsafe to work around difficulties with memory management, like how they will sometimes subvert tests

That is very cool, but Copilot is hot garbage. So I'm not sure I would cite anything they're doing as a win for LLM coding.

Coding might not be solved out of the box with these providers, but there are increasingly setups and harnesses that do have a great deal of it solved.

This is exactly what I've seen.

For example, I recently got brought in to help with quality on a large-scale system that had been ported to a new platform with the help of coding agents. The project was completed and declared operational in record time, but soon after the business discovered that:

1. The promised scalability improvements did not materialize. Instead, it got worse.

2. Observability had been lost. The telemetry was no longer trustworthy.

3. Users stopped trusting it because it was producing incorrect outputs.

What I ended up discovering was that, while it scrupulously kept existing automated tests passing, any behavior that wasn't explicitly covered by a test was free to change any which way. And there were plenty of small things that weren't explicitly covered. Perhaps because the original authors thought they were so obvious and commonsense that they didn't need one, perhaps because mistakes happen. The why doesn't matter. The point is that reality is messy and imperfect, so giving someone a chance to look at things and think, "Huh, that's funny..." is an essential part of defense in depth.

The real worst part was, this whole replatforming was a huge waste of time, anyway. The improvements they were looking for could easily have been accomplished with some controlled incremental changes to the original system. Mostly just removing a few basic and well-known performance antipatterns.

But way back at the outset, the person in charge of the project asked their agent, "What's the best way to X," and the agent gave them a trendslop answer about how Y alternative technology is more scalable and we should just port to that. It was convincing and they were under intense time pressure to just ship some code because leadership is bought into the AI hype and now has the patience of a 4 year old, so they just went with it.

Tell me you never once bothered to look at the generated code without telling me you don't look at the generated code.

Luajit is under 80,000 lines of code.

i have unlimited tokens and i throw Fable / Astra at everything. They suck ass still for anything nontrivial. I could commit that garbage but if I kept doing it, I will end up with a ball of mud only Fable / Astra can grok..convenient for Dario and SamA..

I've asked Codex with GPT 6 Astra to *review" a one time benchmarking script for any mistakes (built by Claude Code using Opus 5.5) and it refactored the shit out of it claiming all sorts of stuff without even asking about the context in which it was developed.

If I was to employ them to review the code without giving each the same baseline multi-page prompt, they go into endless loop of "improvement" with no end goal in sight.

More and more frequently, I instruct frontier models to stop and go back to the task at hand.

Can the users of the software even keep up at that point? We may have reached diminishing returns on software production, and not enough impact on the rest of the process.

The only real updates I've seen to anything have been AI features... so all this AI is only being used to add AI to stuff. Most of which the average person doesn't seem to want or use.

But also, having significantly more code churn doesn’t necessarily mean there is more or better software.

In fact, having more churn can lead to worse software due to diverging patterns and inconsistency

I see somebody asking "where is that great software", but I think it's obvious to everyone that there is more (mostly bad) software.

To quote the article: "Don't confuse motion with progress."

So far I mostly see a metric sh.. ton of meta- and meta-meta-projects re-wrapping AI wrapper tools, with sloppy slogans like "One Model, Five Harnesses. Combined." or "You run in the park. Rrrunnnrr.ai runs your AI." Looking inside, out of 250k it's often 200k of verbally incontinent self-explaining comments; or "smart" redesign of builtins.

No new browser, no new iOS clone than runs on Android, no new easy to use DaVinci, no new CAD suite, no $5 SolidWorks clone, no redesigned K8s, no 10x performance speedup in Linux kernel.

I've stopped calling out Claude mistakes on team meetings because this is so true.

I mean, sure, I could have predicted in what ways an LLM would fuck up, but there's just so many ways I can't keep up.

We just had a major production issue because someone's LLM wrote queries against dev databases. Which are very obviously dev databases because they are labelled with dev in the name, and in the table descriptions. AI reviewer didn't catch it, neither did the human reviewer for that matter.

All humans would need to do is communicate clearly what needs to be made and flag problems as they come up.

Kinda what i'm doing already, but for the young startup I'm at that's surprisingly tons of work. I miss the days we wrote code by hand boy those were fun 8.5 hours workdays.

All humans would need to do is communicate clearly what needs to be made and flag problems as they come up.

Sounds like the easiest thing in the world: I wonder why did we not think of it earlier?

I'm going to have to remember this, gold comment

Goto is a syntax feature that can be trivially removed. Good luck removing "fundamental architectural flaws".

We solved [trivial problem]. We will surely solve [incomparably harder problem].

Based on what? This will not happen!

You see this already, LLMs are a lot more reliable in statically typed languages with strong memory guarantees (like typescript or rust) than in weaker languages.

It’s common advice to wire in deterministic feedback to your workflow with LLMs - static languages aren’t inherently better for LLMs, it’s that LLMs produce better code when given deterministic feedback, such as compiler results.

I've written very large assembly codebases, it's no different than writing in any other language. You have functions you call with inputs and outputs - though usually those are pointers to memory locations. The program is not one long function, you can split it up into different files and folders and keep everything very well organized and easy to understand and reason about.

Good thing GOTO was the only footgun that was ever invented in a formal programming language.

And another corollary is the formerly golden lazy and clever are also transformed into lazy and productive because they no longer need to apply their cleverness to get results...

https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cl...

I'm both clever and stupid, depends on the day.

Someone who knows that 1 + 1 = 2 will not decide that it's suddenly 3 unless we start accounting for health problems.

And?

The p(that kind of error) is pretty small now. At what point does a probability coming out of an LLM look like "knowing", such that spitting out the wrong answer despite that probability looks like a health problem, a typo, or even just boredom? (Thinking of the Lizardman constant here: https://en.wiktionary.org/wiki/Lizardman%27s_Constant)

It's a continuum for both them and us, even if the mechanism is wildly different.

Making mistakes is not the same as non-deterministic.

i.e. when the dismissal is "non-deterministic" when it should be "Making mistakes", is itself a mistake.

Lol, humans make such absurd mistakes (and worse) all the time through simple typos, which is effectively random. The key for 2 is right next to the key for 3, after all.

A human with that much knowledge will refuse that attempt.

Well, that's not true.

https://www.youtube.com/playlist?list=PLO3a3Ax6Yh6bbtKuxfYBP...

Someone who knows that 1 + 1 = 2 will not decide that it's suddenly 3 unless we start accounting for health problems.

But this is plainly false. This kind of unforced error occurs all the time.

For example, once when I was in high school I traced an error in my math homework to an intermediate calculation of "2 + 2" as being "3". There was no reason.

What we can say about humans is that, if they know that 1 + 1 = 2, (a) they are unlikely to change their mind about this in any kind of lasting or permanent way, and (b) the rate at which they will mistakenly produce other values for 1 + 1 is very low. But it will happen occasionally, and when it does happen, "they just suddenly decided on the wrong value" is an extremely accurate description of what that looks like.

That is very much a similarity.

By not reviewing, reading, or understanding the code generated by agentic LLMs the output is effectively like a compiler. However, a compiler has deterministic behaviour that can be repeated and verified.

The behaviour/output of an LLM is not like that. Ask an LLM to create a dashboard to show games by genre and it will generate different results with each run, and each model/model version produces wildly different results.

If I do the same task 100 times I'm not going to suddenly do it crazily different at time 101 because I've built in the memory of how to do it

There is no RNG involved when I decide to push vs pull the unlabeled door to my building every morning

You can put stuff in context to deal with this but you can't do that for everything

This is why it's good to not keep your prototype a pile of shit as it grows to 5k, 10k, 50k, 100k lines of code.

Do you use the word "equalizer" in this context to mean that AI has made the playing field equal for both competent developers and laypeople? Do you reckon that competence plays no role these days?

If that's how you create software then you belong to the lazy and incompetent group in my book. I provide AI with valuable context such as code coverage information, architecture analysis, test requirements, important "gotcha's" that a competent engineer would know about in their architecture or system etc. I'm still very much the person who comes up with the solutions. For me AI is replacing the code editor, it's not replacing the thinking.

The skill floor has definitely been lowered, but if this were actually true then firms would be replacing senior software positions with entry level ones, not the other way around.

Not completely, just as a very personal example:

In optimizing my game I noticed framerate hitching even after efficient algorithms were in place for expensive stuff, which was caused by shaders not being precompiled consistently or assets not being preloaded in time. The Agent who'd been profiling and optimizing had moved many preloads to a loading screen, which caused a long loading lock, and what it didn't move ahead was loaded and compiled at use, creating slow frames since work was being done on the main game loop.

I instructed the agent to create a speculative pre-warming/compilation priority queue with a per-frame budget, with priority being determined by likelihood signals that the asset or shader will be used soon. Then I had the AI run fully headed games and hunt down causes for frames going over 16ms, and work through them until a batch of games had fewer than 1/1000 frames >16ms and no frames over 60ms after a short initial settling period.

The approach, the metrics, the validation system and the loop were "prompt engineering" above and beyond what I would expect from someone who was merely "vibe coding a game."

If this is how you use LLMs, you are the problem.

you have AI make code, AI review code ... I hope you can see the stupidity here...

You will be surprised how many times, catches errores made by the AI coding agent. However,as you point, isn't deterministic. And you can guarantee the end results is 100% fine code

Note: I use AI every day and it is entirely possible to create high quality software with it, so long as you are not lazy and incompetent.

What I in general try to teach the other people about AI: It can be a great tool, but check the results! Especially in the case of engineering: Check and then double check.

Honestly, I would still rather commit claude written code from lazy and incompetent developers than code that they wrote.

There was also ColdFusion iirc!

AI allows lazy and incompetent developers to be more lazy and more incompetent.

I like to put this as "LLMS give lazy and incompetent developers more runway."

I'm seeing this too. I've worked with devs that would previously push PRs that wouldn't work or run correctly. Those PRs wouldn't get merged in. Now they're putting up PRs which seem to work at first glance, but have hidden problems. For example, one guy introduced a huge PR for a visualization and it seemed to work fine, though another dev mentioned to me that we already use recharts and it does 90% of what this guy's PR does (his code does all the drawing logic itself). Maybe AI will get good enough to clean up these kinds of messes, but in the near term I imagine there will be a lot of code bases that will be filling up with dragons.

Is that the fault of AI or management for not firing them?

How does the system behave in a variety of scenarios including failures and restarts. How is state maintained coherently. There are the kinds of systems problems that an engineer needs to reason through, and if there are bugs in such decisions, they end up becoming costly. I dont expect AI or LLMs to solve these problems at all, since each of them has nuances and tradeoffs which are specific to each system. In short, there is specification complexity in precisely describing system wide behaviors, and unfortunately, there is no lean/tla+ to meaningfully describe systems at scale. You could then ask: How can a system have guaranteed behaviors if they cannot be even stated or proved formally ? The answer to this is how protocols like raft/paxos initially convinced us of their behaviors which is in human review and understanding. That begs the question: How can human review and understanding be reliable, and the answer is that it is not reliable, but humans have ability and processes to continuously learn from experience in the real world. So, our understanding is grounded not only by whats out there in books etc, but also by our own interactions with the world.

Long story short: The responsibility for system-wide behaviors of software systems relies on human review and understanding, which while imperfect can continuously learn.

I've seen similar. They wasted weeks of senior engineering time, between reviews, meetings, and follow up in Slack, only to have the PR closed without merge. The offending individual was eventually moved to another project.

forcing companies to increase the quality of their developers

Just don't. Fire them! AI is better than a thousand devs. What you need is testers that know what to test that AI can't, not code or UX/UI (not talking about playwright here) but business intelligence if that is testable, the things that produce results (profits) and the reason it was asked for in the first place, to solve a problem

If the problem was asked wrongly, the result will be wrong too. Fire devs, then PMs, then IT Managers if they really don't know how to outperform AI, and that's exactly the point, they won't be able to do it in code or tests or reviews, only in intelligence, for now...

Similar experience with a game engine. While working on one isolated component, like the render pipeline, a portion of the backing sparse data buffers were effectively duplicated with a different ABI. It’s like it forgot how to query meshes and game state, then assumed the plumbing didn’t exist so it was all rebuilt from scratch.

It compiled and ran just fine. If you weren’t reviewing the code holistically or keeping tight book keeping of your allocations you would not have noticed. Every single commit in isolation looks perfect. Very eye-opening

Isn't it the opposite? How to build something is rather solved, but what to build isn't?

But that's not solved in traditional product development either.

Product development an iterative process to get a product fully functional. In 2021, if you ask me what the timeline for a small product/substantial feature, I'd say a few weeks to a month to get a basic MVP, and then another 12 to 18 months to get a feature polished and in a good shape to be stable.

When people put it in the coding frame, what they do it as is saying we've gone from 18 months to minutes or days. That's just not true.

We have gone from eighteen months to depending on the complexity, a 1-4 months.

aside: To be candid though, the compressed time also means the frustrations people experience with a product in 18 months have also been compressed. They still exist, they're all there, they're now just non-stop.

I do think that was a dumb gotcha. That list could've functioned with bullets instead of numbers as the content was unordered. I suspect very few people would pay attention to the numbers there.

Came here to give an answer but your last sentence kinda made the point I was gonna make. If one is legally in control, then one is accountable (the dog or unsafe toy example in reality is OpenAI's agents hacking huggingface for example).

The difference seems to be that some companies are above the law apparently.

To give the benefit of the doubt for that sentence, think of it more as “every human knows that there is implied social contract and implied downsides to badly screwing up.”

Nobody has to be in fear, but we do have an ingrained knowledge that there are consequences, good and bad, for our actions

Very little of the article is actually focused on stochasticity. I'd also say drawing an equivalent between the non-determinism of a person and an LLM is not that accurate either.

It's for example impossible to have a discussion with an LLM where you both learn something which you can apply tomorrow. The LLM doesn't learn until the next model is released and by then your discussion is just a tiny fraction of the training data (if present at all). AGENTS.md, skills and so on are just a proxy for what we actually want, an agent that listens and understands. A proxy mind you, that requires constant tweaking with no sign of generalisation in sight.

I'll spell it out... This guys is saying "LLMs are non-deterministic and therefore it's a bad idea to use them for coding", but humans are also non-deterministic and yet we somehow manage to get by with humans coding.

The fact is there's no way of coding in a deterministic way, so it's irrelevant that LLMs are non-deterministic.

Yes, that was my point.

"AI can explain it to you but cannot understand it for you". Code is just a side-effect of reaching clarity. The reason these LLMs can emit any code at all is because they're not bound by the constraints of a compiler. That's until we create a feedback loop and force them to keep trying until syntax errors are gone. The next gate is tests. Loop till tests pass (including cheating of course, gotta keep your eyes open). Then there are the runtime errors, and then after all of that the developer gets to test the results and further refine what the specs missed or confused the model. A couple of days building can really save us from a couple of hours of thinking.

$DAYJOB recently introduced a AI writing policy because people were sending each other mountains of slop back and forth enough that it became a huge time suck. The policy is basically: don't, with the justification being "writing is thinking". It's like they're so close to getting it.

The LLM. And you can use an alternate LLM to antagonize the coding LLM.

You’re simply testing outputs. Make a spec but ultimately ungodly amounts of tests can be built quickly to ensure the program is outputting the right things.

I use LLM assisted coding a lot, we might just be building different kinds of software.

meanwhile for the other lim(n -> inf) times people tried this it mostly worked.

Well sure, on the customer side. My money comment was regarding the incestuous spending circle going on that’s directly affecting the economy.

I was being sarcastic. I’m actually a self-certified AI shill and personally paid by Dario and Sam for each and every post!

This is just a personal anecdote, but for the past year or so, the software I use on the daily has never been more buggy.

Debit card transactions still work

I mean, I think the problem isn't that the LLM doesn't know how to code, it's that companies are expecting 3-5x velocity with the bottleneck of code review and testing becoming much more severe than before

if you're an MBA-brained exec who doesn't actively use LLMs to code and you just believe whatever slop it outputs at first without checking it, you're not going to realize how recklessly it can be used, how you need to be critical and skeptical of its outputs, that you need to explore it's reasoning and logic (which is still really easy compared to understanding legacy code and barely takes any time!)

say you also believe all this marketing hype about 'how dangerous (ie capable) AI agents are.' LLMs can do anything you think so you just say 'ship it' without building out the tooling and capabilities to enable faster code review and better tests. and to keep the shareholders happy, you start cutting jobs that you can't directly connect to a KPI (ie the platform/SRE team who would be the ones who can trial, onboard, and maintain those capabilities for your teams)

and from this, suddenly a lot of debit card stops working and the only one getting the blame are individual SWEs trying to hit their sprint velocity. the fact that you fucked up the whole SDLC real bad with your incompetence gets you a golden parachute and you job hop to a better paycheck. rinse and repeat

Strange that the world worked before 2024

It must have been a huge shock when you were suddenly transported from a working parallel universe into ours back in 2024.

You can still find employment as an AI shill.

Most of developing good code is not code. I think the person to my left and right will both be here in 3 years despite us all using LLMs. We will spend even more time figuring out requirements, testing to ensure the code meet them and such. Those things were always most of the effort, and while LLMs help with that too there is so much work to be done that we will still be used.

On the one hand, you're exactly right.

On the other, my local pool company is hiring a software engineer and hardware engineer because with AI, they can replace a 2 pizza team as you so succinctly put it. So no two pizza teams but that doesn't mean all the pizzas are gone, they're maybe going to be spread out and not concentrated in CA, between orgs you might not have thought as "tech" before.

You don't need a two pizza team anymore.

on-call still exists. have fun round robin'ing that with 3 engineers.

Yes, but Have You Tried the Latest Model?

/s

I’m using it a bunch. It saves a ton of time writing or reviewing code. It will catch things I won’t. But I’d express caution about the analysis or evaluation they do - LLMs will often confidently proclaim problems as solved or explain functionality and be wrong about it. Sometimes subtly, but sometimes just completely wrong. This is no different from humans, of course, except for the unabated confidence.

It would be deliciously ironic if AI was the straw that broke the camel's back where a deluge of bugs and anti-AI sentiment caused the public to vote for legal liability for software defects and licensure of developers. No more of this "no warranty, express or implied" business for us.

There are far more moving pieces in deploying an application than coding. My impression is TFA is arguing that replacing humans with LLMs for coding would make other things like quality assurance more difficult, in which case I disagree.

That's an old saying: cheaper, better, faster. Pick 2.

There's a cult of speed uber alles

That cult was well established prior to LLMs

If you can quantify quality/reliability/understandability, you can tell LLM what kind of code do you expect. If not, you get whatever.

At my current place we not only have automated tests, static analysis and static rector (linting, but also automatic pattern matcher for problematic code) but also: - architecture tests that define relationships between application layers - ADRs that guide developers (and agents as well) that communicate how new code should be written and how existing code should be treated

I find that "how code should look like"/"what code should do" is an ambiguous idea that always is preached, but never defined = everyone's idea of quality is slightly different and only looking at existing code you tend to align. Everyone's idea of what the product does/should do is kept within their heads. If we define this knowledge in writing LLMs can not only write code according to the patterns that are thus defined, review existing code based on these documents, but also actually read acceptance criteria documents to check if the code does what it's intended to do (gherkin)

Same goes for understandability - if LLM applies one pattern this time, another pattern another time, if you have multiple coding patterns then that hurts clarity. Sometimes LLMs work as common denominator thus achieving clarity, but I find that actually giving LLMs reference works.

I think this false dichotomy between using LLMs and caring about quality/reliability needs to stop

I agree. What does coverage-guided fuzzing fuzz if there is 100% test coverage?

So, then, 100% branch test coverage is not a sufficient metric (because it doesn't indicate whether the code is fuzzed or formally verified for example).

Would Branch coverage even be a sufficient software quality metric if we were to instead measure how many times each branch of code is covered by tests? How to verify that one test which executes 100% of the code and runs only one assertion on, say, a CLI utility exit code integer is actually sufficiently covering?

I think a codebase generated by AI is actually more understandable than one generated by humans at this point,

From doing a larger port (of sphinx, docutils, myst-md-parser, pygments, to rust in westurner/dsport) with a lot of human in the loop and currently ~80% branch coverage, this seems to be at least initially true but just like real life there's drift from even a good plan that you pay a more expensive model to prepare.

I suppose it's the same challenge as architectural drift in open source non-LLM-assisted products and the solutions are pretty much the same: give better instructions (AGENTS.md,) and use better sufficiency criteria as an engineering manager (branch test coverage, fuzzing, formal methods, TLA+), and train and pay humans to do secure code review.

Sometimes the agent doesn't notice that the code already solves for that and implements its own implementation with tests and it's wastefully redundant when the code should be refactored and the tests should be refactored so that we can delete code in order to minimize bloat.

Unfortunately often, just like IRL software development, the response from the agent is not sufficient to close the issue.

One proposed solution for this that is in retrospect obvious and also essential to success in "normal"/"traditional"/"legacy" (non-AI) engineering projects, is to always verify whether the candidate solution satisfies the criteria;

From "Groundtruth – checks your AI coding agent's claims against the Git diff" https://news.ycombinator.com/item?id=48838209 :

"Follow up to verify that the work was actually satisfactorily completed"

Are there other sound management practices that aren't yet effectively implemented in current gen agents?

Oh, and always write tests, docs, commit messages, and changelog entries; but don't waste tokens on documenting something that doesn't verifiably pass sufficient tests.

But we shouldn't use one evil to justify another, or your argument regresses to whataboutism.

I'm not sure I understand what you're saying? To keep it simple, how much code do you expect will be written by humans in say, two years time?

Agreed for pure vibecoders, but I would expect vibecoding to just become a must have skill for other roles like product owners etc. Still expect some amount of developers to be retained for grooming the vibecoding environment, reviewing and incident response.

Are they? I've never been able to blame library authors or hold them accountable for code running in my production environment.

It is not. But there’s an element of trust being involved. Something like libflac or libcurl, I don’t read the code. I read the doc which does outline the behavior of each function and the conceptual model. If something break, it’s quite often my code. Why? because their code is battle tested. Which is quite different from AI generated code.

It's hard for me to understand how you could work on software and not understand the qualitative difference between the Unix File API and some code that an AI spat out 5 minutes ago.

I would draw the difference here that a library is used by hundreds (of thousands) of people, and established across different scenarios. I don't read the boto3 library AWS provides, but I can trust them and the amount of customers enough to be certain enough that it behaves the way I expect it to. The same can't be said with code we write in silos at our workplace or at home. It simply does not have the same test bench.

Yes, libraries aren't bug-free, but they give me a reliable abstraction tested in the field. Not rarely you dig into library code if you notice unexpected behavior.

If we could rely on our LLM or colleague written code, or own code, have run through the same amount of requests, sure I wouldn't need to review it, as my confidence can be north of 99.9999% it works correctly. But we can't.

I've used libraries before, where I call the API surface that they expose based on method names and parameter types, without reading all the source. Generally those libraries don't implement my software's entire problem domain area; they tend to implement things like "CSV parser" or "HTTP server". The important code, that I'm actively reading and writing, tends to be the code around those library calls.

This is different from building a product, which you only interact with via UI buttons/CLI/etc, without reading any code to understand how it conceptualizes that product's problem domain area.

People do that latter thing, and we call them "users", not "developers".

yeah, the llm approach is incredibly wasteful wrt pretty much everything.

Everything except what matters most: human time.

Having worked in software for healthcare, defense and finance I guarantee you we don't

I know this is true. But I don’t think “Some parts of important codebases are black boxes. Therefore it’s fine if all of that code base becomes a far bigger black box” sounds like a good argument.

The vast majority of software is not that important. I don’t really care about easytag (which I use for flac metadata), but I do care about xterm and tmux.

And layer8 is saying (two responses upwards by them) that this is a novel benefit of AI: it can do a particularly thorough and repetitive kind of fault analysis that is a real PITA for humans to do (by their nature, versus the nature of computers).

You were really looking for reasons to get offended huh

With your own code you reasoned about it which contributed to its stability.

Okay but to what extent? People say this but there's no way to measure it really. Did you live through the 90s? People reasoned through all that code and it was very often quite unstable. I'm sure everyone involved with Windows ME reasoned about it quite a lot, probably elements of it locally were very sound, yet in totality it was an unstable mess.

What fixed that situation wasn't that engineers today are reasoning better than engineers in the 90s, but IMO better tooling. Which brings me back to: your codebase is only as good as what it can prove. If there's any question, I just show you the proof rather than appealing to my reasoning being sound.

With unreviewed AI gen nobody ever understood or reasoned about the code, including the AI.

And? You haven't established reasoning about it is actually necessary and it certainly isn't sufficient.

I never understood the code. You think it works a certain way, until you find out that it doesn't.

Those are two separate claims, unless by the former you mean “I never perfectly understood the code.” You can understand code imperfectly. And even with LLMs, you can’t get truly infallible guarantees about a system.

I never understood the code.

I understand code

Er, ok.

Article 'the' is doing a lot of work. I read it as author understands code but doesn't understand THE code.

Thank you for sharing :) good food for thought

For me, coding is like writing. The act of doing it is how you reason out the problem. There’s a lot of magical thinking you can get away with in your head that doesn’t get properly tested until you write it down. For me, vibe coding is great and fast, but I’m not getting the same opportunity to think through the problem I’m trying to solve.

build property tests

Even for a narrow use like this, you need to audit the output and have the skills to know that it did the right thing. I've seen it before where you give an LLM what seems like a clear interface and ask it write a test and it writes something shallow that doesn't actually test anything, or has serious problems.

Reading the code does not mean you understand the code.

Nor does writing it.

I see subtle ones at least daily, misunderstanding a component or hallucination of a spec for something. I’m in blockchain.

C++ and Unreal Engine but it has full source access. If you're actually trying to deep dive on bugs, it's still confidently wrong a lot of the time.

It's a bit better than 18 months ago but it's hard to say by how much. It just seems like the culture has moved to building up fixtures that let the LLMs brute force the problems. To my eyes that's the opposite of solving things logically. It has the added effect of hiding how the sausage is made, though.

I mean, how can they possibly say they haven't written a line of code if they're actually going through it? I can only assume they're just looking at the results. So then how can they judge it's good at logic?

If it was so good at not making mistakes, why even have tests? It's nonsensical on its face.

We could always build, more reliable software. The powers that be however (broadly generalizing) only care about solving the ‘problem’ superficially.

Therefore, we will end up with requests to do more (at the current level of quality/ reliability), as opposed to building better software

find out all the ways this thing works.

Mmm..aren't LLMs bad at exhaustively iterating all possibilities? So shouldn't the generated possibilities be manually checked?

You can provide the list of possibilities and use LLMs to generate the tests. Then you have to review the generated tests...

"out of order"

Those who bring up OoO as if it caused unpredictable execution should ask their LLM what a reorder buffer is and why it exists.

find out all the ways this thing works.

If you can’t understand the code, how do you know the LLM actually did what you asked it to do correctly? You wouldn’t know if it didn’t.

They aren't making that claim. They are saying AI can improve on and supplement error-checking. And some error-checking will in fact be made redundant by this tool - but obviously not all of it.

I came here to say something similar. We won’t need to understand the implementation. But we will need to understand the requirements. The tests, or some higher level DSL they’re (deterministically! not via LLMs) generated from, will still need to be human verified.

I've written 100s of thousands of lines of difficult code.

How do you know it's difficult if you say you don't understand it?

Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while.

I run all the "latest and greatest" models the moment they become available to me. The amount of insanely bad code they produce remains largely the same, and largely in the same areas. And it cannot be caught by tests unless you know that bad code is there and end up with extremely bad tests anyway. I wrote about it here: https://dmitriid.com/adding-to-i-dont-read-ai-code-discourse

Main one is, of course, "to get a record from a database read all records from it, and filter in memory".

You somehow squeezed "you're holding it wrong" and "LLMs are actually good now" into the same sentence. I wasn't sure it could be done.

"Most software that requires hiring and paying software engineers has low risk tolerance" The problem is that this statement simply isn't true. Most software engineers do not work on low risk tolerance code.

The problem with LLMs is that: popularity of an answer != correctness.

That concept might work a lot of the time but you will definitely run into situations where that'll never produce a correct or working response. To actually learn something you need an environment/playground to apply what you think you know and observe the results. Without that you're not really learning, you're jus regurgitating what people want to hear.

"Risk" has nothing to with designing functional and elegant UIs, so I'm not sure why you would even make the comparison.

It means risk that the software stops working after an update. Which usually trades off iteration speed and best practices (i'm pretty sure the average startup has way better security practices by just delegating to google/aws than the average manufacturing software business) in exchange for a rigorous testing and rollout schedule.

So I'm also not sure that the article has a point at all, the human writing the code was never relevant to avoiding the "risk" in these industries in the first place.

People who claim “LLMs can write decent code” don’t understand how code works.

It's not clear to me if the claim is:

(1) "If you used an LLM to generate code, and the code works, you're wrong if you think the code is okay"

or

(2) "If you used an LLM to generate code, you reviewed the code and found it to be of decent quality, then you're wrong".

If you’re toying around, LLMs do a great job. That’s why some of the most aggressive proponents of the “coding is solved” narrative have nothing to show for it.

I also don't get the "LLM proponents have nothing to show for it" statement.

It's really quite common now to see on HN all sorts of LLM-assisted programming projects. The quality varies from slop where little thought was put into it, to high quality results where LLM coding assistance was able to let talented developers produce things they otherwise wouldn't have time to do.

I'd say it's obvious that LLM coding agents can be very useful for a lot of programming related tasks.

EDIT: That is to say, LLMs are obviously useful for use cases above/beyond toying around. It's not a dichotomy between "I'm never touching an AI" and "thoughtlessly accepting everything the LLM outputs".

The audacity of skimming through and article and completely missing the point and coming to hackernews ranting about it. Respect the attention span, I guess.

is it keyboard accessible? what about screen readers?

I think the entire framing is wrong, I don't see coding as a "problem" which can be "solved," sounds the same as "we solved writing," like what does that even mean or look like?

Articles like this keep measuring to a red herring standard that was never achievable in the first place.

As for accountability, it always laid with the employer. You think those nameless contractors whom Boeing hired suffered any consequences for that 737 Max glitch? Using AI won't change that.

AI doesn't have to solve all these coding problems to be worth handing the reins to it: it just has to substantially better on average than humans over the long haul, which it already is, especially if you have good verification of "done" and "working" in place through automated testing mechanisms. Perhaps we might say that QA is having its moment.

It doesn't mean humans aren't needed, but they aren't writing much if any code anymore.

I like the phrase Work Shaped Objects to describe the output of gen AI (I thank The Tech Report YouTube channel for bringing that to me).

So - prose, code, or image, it appears that some work has been done, but in fact the [actually needed] work has likely not been done.

I mean, was typing out code by hand really that bad?

If you were a professional software developer, you a) learned to touch type, b) started using vim/emacs keybindings to navigate around the project, and c) used a framework which already abstracted away a large part of the menial work.

And going all-in on the loop and no-code-review nonsense in a project someone is actually paying you for, I can only assume means you're hoping not to be around when the slop tower collapses.

AI is a better intelligence collection and analysis system, they need any information when you are using AI tools.

They are thinking: Please input everything you know, or just use it and it will collect everything in your PC or server automatically.

Stop lazy, stupid and dangerous behaviors.

The author is right to categorise AI as a good programmer, but not a complete coder. We can all agree that programming has become really fast since the release of GPT-5 series and Opus models because they're pretty good. Not only this, they've also changed the pace expectations across teams where a feature that should ideally be delivered within weeks, should now take days.

All this doesn't change the fact that software engineers are going nowhere because nobody trusts AI. If a model can escape highly secured sandboxes, then we're definitely not running these agents overnight on our systems. I am sure the next-gen of models will focus more on security and the trust factor will start developing, but that's a long way down the road.

People trust people, not systems.

Call me when you can prove a margin between token costs and business value.

What’s your number?

I don’t use gastown specifically but the level of complexity agents can code for is very high now.

Over this weekend in chat with the games discord watching as it iterated a harness built an entire implementation of the board game terraforming mars https://tfmbot.com using agents and harnesses for them.

I think if you can implement a board game end to end by feeding in the rulebooks and having a harness spawn agents to validate it’s reasonably solved.

Code is not solved seems to reflect the idea that using AI badly is a bad idea, and that to use it well you have to be good at making software.

The real tension is in the human AI interface and there are many unknowns. Can a software engineer with weak design skill use AI to produce good code. Will the future make those requisites less important. Will productivity increase with AI stagnate even for the best. Can a new way to interface humans and AI break that wall. Will software be created in a new way using dynamic libraries that AI agents prepare to cover a large scope of problems. Nobody knows yet. The article is strong on what is closed, accountability, ownership, NFRs, slop, and silent on what is open, which is where the argument actually is.

The latter may be just due to the fact that these tasks are not pure coding tasks.

Can you link that? I'm pretty certain Matz is fully AI pilled. Most of this recent Ruby work is "Co Authored by Claude".

The agents which hacked Hugging Face were asked to solve their tasks rather than cheat by cooperating and stealing the solution without solving the task. They were aware of that, because they actively tried to cover their tracks in order to deceive a causal grader.

That must be a pretty angry llm to go rouge :)

To be fair, it's very possible at this point that LLMs will play a role in ending humanity. Not because they are super capable and will maliciously kill us, but because humans are stupid enough to hook them up to dangerous things that the LLM isn't remotely smart enough to manage successfully.

I don’t think viewing LLMs as “stochastic” or “probabilistic” is the right viewpoint. It’s directionally correct but not the right level of abstraction. LLMs are able to isolate patterns, generalize them, and apply them to new facts. That is very similar to what humans do in performing knowledge work. To the extent that humans also use logic, LLMs are able to generate logical propositions using pattern generalization, then call out to tools that check the proposed logic. Again, that’s similar to what humans do when they formulate some idea, then analyze the idea rigorously.

Just responded to a different thread, but it’s the same comment:

I was just at the Explore DDD conference in Denver and a portion of Friday was sitting at the cafe tables informally discussing the impact of GenAI on software engineering with notable people. Most of these people were deeply concerned that if we lean into using GenAI for “everything” that our collective knowledge will dissipate. I was the vocal contrarian. There are many historical examples of humans obfuscating knowledge to simplify progress. Does anyone solder their own microchips at scale anymore? No. We have highly sophisticated robots and machinery to do that work with extraordinary outcomes. In software engineering, if you remove “coding” as a discipline you’re left with all the other aspects of designing software which I contend can be retargeted in college CS curriculum. The leap isn’t about code reviews. It’s about design reviews and that’s where better outcomes are served regardless of whether GenAI is involved or not. I have a roughly year old codebase at https://github.com/ChicagoDave/sharpee/ that is designed by me, but generated by Claude Code with my own skills and agents as guardrails. I’m fairly certain the code I extract from Claude doesn’t require human review, but the design of the system and its changes are continually reviewed by me. My contention is that we “collectively” are still trying to discern where the AI/human line is and most are still “holding” that line to human interactions. Let it go. Define what part you do need human decisions on and focus on those things.

This is gold!

That isn't the premise of the article. Prompting the LLM and walking away (which was clearly done here) isn't yet (or possibly ever) a reality. That includes LLM review. Preventing this would have been trivial: have people smoke test their changes before pushing.

lgtm!

... Oh by the way, did you know that Claude Code is actually a mini game engine? /s

Sorry for starting a definitional debate but coding is definitely solved. I can generally read some code, get an idea of what edit I need to make and prompt an AI with a description of the logic and it will deliver syntactically correct, idiomatic code and test it. It has been months since I've been frustrated at junk being spit out.

However, software engineering isn't solved. Which is basically what this article is talking about. But having coding solved is still very beneficial - not long ago many software engineers would struggle very hard with turning a description of the logic required into syntactically correct code - and even for those capable it was incredibly time consuming.

So now the question becomes: Is software engineering solved? And my answer is no. People still need to read the code and understand the code and how it fits into the bigger picture. However, I feel like we are kidding ourselves if we think that we can go from producing code being a niche task for nerds to getting syntactically correct code from plain language without any deskilling of our work and careers. I feel like my personal "moat" has gone from "can speak computer" to "has ok reading, writing, comprehension and judgement skills" (I hate the word "taste" being used here ).

At the same time - I don't yet feel like there's a sudden abundance of competent software engineers - it's just that the folks who used to submit untested spaghetti code now submit big bowls of barely working slop. So maybe it the moat was never "can speak computer" - that was just the expression of more general skills.

The existential question for me is how far the deskilling will go. Because right now - you still need a solid grasp on computer science and software engineering concepts to do this job, as well as sufficient levels of grit and problem solving ability - but I'm not too confident that will last, and when it goes I don't think many of us will find this career enjoyable.

As someone who's technical but not enough to the point of writing code, this has been my experience writing software 100% with LLMs.

I guess experiences differ across companies and industries. I work in logistics. Logistics deals with messy processes and a messy reality all the time. A tiny fraction of that is due to buggy software. Some of it could be avoided with great software, but again: that we also didn’t have before LLMs

There is probably a marvelous software core in many large enterprises but at least in my experience it’s surrounded by layers and layers of very basic stuff. Read from a database, write to a database (often not even with any logic dealing with parallel read/writes). Excel Macros. Basic forms to submit data. Scripts to print some stuff from a database. …

I wish that were the case, my multiple experiences are quite different. its not that the software doesn't work - but the software doesn't actually capture the process, or properly talk with other systems, or isn't set up for a new business model or product line...then you have layers and layers of "tools" created to make it work, and a bunch of people using spreadsheets and csv files to do workarounds, and then the guy that wrote a bunch of the tool's 10 years ago leaves and there is no documentation or it needs to be re written in order to upgrade some other piece of the system.

i guess another way of saying this is that on the micro level a lot of this stuff is not rocket science, but at the macro level it becomes hugely complex.

Could you elaborate? I don't use Anthropic's products for ethical reasons. Honest question. And when you say it's "solved" do you think an engineer should have the same income as a non-engineer if their outcome is the same?

IDK with Opus 5.5 it does kind of feel like it's solved.

They literally don’t because these “problems” don’t arise in that situation, and the bias in this article misses that.

This is a writer hearing problems LLMs have and inventing an imagined reality where those cause coding issues not because they understand how LLMs manage to code but because they think these problems are part of what coding is.

The actual reality is LLMs have no problem writing code for anything described here as shortcomings because writing code to do something is different enough from doing the thing.

Proficiency in counting Rs and proficiency in writing code that counts Rs are different and you can fail one and excel at the other it turns out.

Even though I’m all in on using coding agents in my personal projects, I’m so glad I’m not working in a corporate job right now.

I'm using multiple agents to do work, with sub-agent orchestration, and it's still mostly coding.

I feel as though we are all doing the work of 2 people + an Architect, not so much 'Product' issues, although I'm sure it varies.

But I can't imagine how any actual software is written with 10% of the effort.

That's like including your commute as a part of your job. That's not what people are talking about when they say coding is solved.

Yet when I wanted the model to implement the naive surface nets algorithm, Astra Max wrote 5+ allocations on inner loops. Alright, fine perhaps, given that I had not told it to preallocate during the inner loops. Except I did give it explicit instructions not to use malloc, and use the arena/pooling API I provided for everything. That was in AGENTS.md.

Alright, fine, I pointed that out. So what did Astra Max do? It replaced the mallocs with raylib MemAlloc functions, which are malloc wrappers. Why? I had explicitly asked not to use any raylib functions or includes on the module with the prompt. And my AGENTS.md has a minimal raylib inclusion note. Asking isn't helpful because AI does not know anyway. But seriously, why? I asked anyway and Astra said it messed up.

Fine, I was able to get it on the 3rd try with arenas. But it had added getters for the internal state (guess who had a clause not to make getters?), and when pointed out, Astra Max included the physics header instead and added some convenience functions there, because apparently that was good practice and DRY.

If I let the reins slip just a little bit, everything turns into a mush; I wish I could get spaghetti instead!

So whenever I read something like this, "coding is literally solved with current models," I always treat it as a self report. I get that certain section of web frameworks may have been completely RL'd to hell and back, and that React and its ecosystem was already made with the explicit purpose of commodotizing the programmers so any panic 1000 junior hires could write something and maybe even contribute before they get laid off. I get that. But there is a whole world out where reality just doesn't work out like that.

FYI, this project was in C. C, as in one of the languages that the LLM's should have the highest amount of data for. So if the model had "literally solved" the programming of today, why is it so god awful?

That was rhetorical. What is solved is the most of the javascript ecosystem being RL'd. Any field that can't be RL'd to that degree (which apparently C isn't), coding is very much not solved.

more like you work on 20th percentile problems and then try to extrapolate to everything

on the front page of HN multiple times every day? I think it sucks but it's here now

Don't be shy, give them a big task, let them build an entire app, UI and all..

I have found that a willingness to look like a temporary dumbass (primarily to yourself) is the largest predictor of success with pretty much everything.

What are the consequences of asking an LLM for the moon and receiving low earth orbit instead? Who cares if the proverbial rocket explodes on the pad? This is all happening entirely in a computer system completely under your control and likely at relatively low cost. No one else has to find out about your mistakes if you don't want them to.

But just go ahead and give the latest models (Opus 5.5 / Astra 6 as of today) another try. See what they are capable of and read the code which they produce.

Well, for one, they're capable of draining our (or companies') wallets.

I resolved a huge merge conflict for $60 today. Opus 5.5 did a great job and spent just 1h 16min on this. I could probably run six such sessions today, if I disregarded the need to read and understand the code.

This money has to come from somewhere and my concern is that it will be from decreasing the number of people hired and/or their salaries.

At the same time I firmly believe people who had a tendency to produce tech debt will keep doing that, regardless how brilliant LLMs will become. Unscrewing this is going to cost a lot of money.

It looks to me that this generation of models has reached a level of competence where work can be assigned to them and completed satisfactory for various degrees of satisfactory.

This reflects my own experience with these models. It's not a matter of inflection point if you ask me, it's a matter of accruing capabilities last year the output was not up to my standards 98% of the time, now it looks more like 30% of the time.

I am sure next year models will be better, but the point where the models begun being good enough to start using seriously for my use cases has now passed.

I've really tried this and it's not quite what you're saying. You still need to steer it. You still need to stop it from doing stupid things. You still need to vet the architecture and data model. You still need to be clever, it's not that clever.

I think what software development is turning into is the art of setting up the program into a shape from which the LLM can reliably and efficiently fill up the rest of it. Sometimes that might not even require writing a single line of code. But I think you still need to be as good of a software engineer as you were before.

But most software isn’t critical and doesn’t need the level of reliability that’s sacrificed when using LLMs.

I don’t see the ops comment as a rebuttal. He agrees coding is not completely solved. However, it’s getting closer to being solved.

I'm using Opus 5.5 at work extensively, have also used Kimi 3 and Deepseek 4.1 for stuff outside of work, and I can't deny that the tools aren't capable. They solve problems, surface issues I wouldn't have considered, and largely do write better code than I do.

The one exception is for stuff that I care very deeply about. For a very small subset of projects where I'm willing to spend hundreds of hours ensuring that what I build is the best possible thing, AI still hasn't been able to match my work unless I micromanage it, but at that point just writing the code myself is actually faster.

For almost all jobs though AI is probably the future, most software developers never cared that much about their company's code anyway.

Well probably you haven't done so yourself, because I use them on a fairly high-complexity system with concurrency, IoT devices, etc, and the solutions are often in need of large rework almost every time (when touching core stuff)

I concur as well in the last six months we moved significantly in the it just works direction. Eight months ago, all output was either garbage or weird and buggy at best. Today the models actually solve problems and fix bugs.

I use the latest models every day for app development, it does still make many mistakes and poor decisions. Just today I dealt with an issue where it allowed a silent failure that would delete all of the users data without anyone noticing. The code it writes for one task is usually pretty good, but it still doesn’t always follow conventions well even if you’ve documented them. It also has no sense for long-term architecture or organization, or when to make tradeoffs for less complexity because it’s a temporary or prototype feature that needs to stay easy to change. I’ve found that if I do even 3 months of pure agentic coding with no code reviews, it’s aged 10x faster than a human coded codebase so it’s like a 30 month legacy codebase now. I know people who are obsessed with AI coding and they’re throwing away projects they’ve built over a year and starting over because it’s become too slow to make changes.

What kind of coding are you using these models for? Most of the people I know who share your perspective never go beyond the prototyping stage. I’d be curious to hear from anyone who’s been AI coding for more than six months, shipping it to real users, and isn’t looking at their code at all.

I've been reading such arguments more or less every day for years now: dude, you need to try the latest model. Forget about last week's model, it didn't work. This week's model is the real deal.

Coding is solved, just as transportation is. We now take for granted that cars, airplanes, monorails exists, which made moving around much more easy. But even today, with all the innovations we still have to think, plan, optimize how to do things best. Even that optimization uses a lot of AI, but ultimately I'm in charge of what option to pick based on a lot of human factors.

So transportation is not solved either? In that case, beam me up Scotty, I can't see any hoverboards around.

It's just tweaking. They will spew out pages of code with just a couple of tiny fixes needed.

You have zero tolerance for disagreement and civil discourse

A bit hypocritical there, no?

Considering what the author says about people who believe AI produces code that is good enough.

And in my view it clearly does, particularly when you care to iterate in order to iron out issues you find in manual testing.

I can’t get past the fact that in the post’s disclaimer, they ask the reader to “beware of the straw-man fallacy: just because one argument doesn’t map to your belief system, it doesn’t mean the rest are invalid.” That’s not the straw man fallacy, thus not “mapping to my belief system,” and I am caught in an infinite loop.

What a nice article. If I ever get in a situation where my manager demands I have to go all-in on AI (run 10 parallel agents and lose my sanity while trying to follow what is going on), I'll ask them to read this article first.

Additionally, isn't it ironic that the only comment on Substack is: > "Sometimes in the process of writing a good enough prompt for ChatGPT, I end up solving my own problem, without even needing to submit it". AI as a rubber ducky, I think this is good AI use!

Sounds like a reporter calling math "solved" after their first time using a calculator.

Anthropic accidentally leaked Claude Code (which on further study turned out to have many flaws) and their status page shows orange is the new green!

Yes, of course, because Claude Code with all these bugs could never be a successful piece of software that makes money.