MO. Mortada

I wish there was a way to know you're in the good old days before you've actually left them ...

[MO. Mortada @MortadaDEV]

The "even if X could do Y, you'd still cope" template is unfalsifiable by design. It pre-dismisses any technical objection as emotional instead of rational, which is a neat trick for avoiding the actual argument.

But let's engage with it anyway. Let's think through the hypothetical instead of using it as a dunk. Say Fable 7 regenerates an entire production codebase from a single prompt. What do you have?

"You have code. You don't have context."

And boy oh boy, how this part keeps getting skipped in these takes ---> Code generation was never the bottleneck. Nobody in 2016 was sitting at their desk stuck because they couldn't physically type the characters fast enough. The hard part was (and still is) deciding how to build sth.. decompose it across services.. handle failure modes under load.. evolve a database schema without downtime.. ensure your auth flow doesn't introduce a bypass when requirements change.. debug a distributed race condition at 3 AM that only reproduces under a specific traffic pattern.

And so, if you don't have the context, you know nothing, Jon Snow.

You don't know why the retry policy on the payment service uses exponential backoff with jitter instead of a fixed interval (because a third-party gateway rate-limits aggressively during peak hours). You don't know why there's a seemingly redundant null check on line 847 of the order processing pipeline (because a specific vendor's webhook occasionally sends malformed payloads that pass schema validation but break downstream). You don't know why the database query uses a specific index hint instead of letting the optimizer decide (because the optimizer makes the wrong choice when the table exceeds 50M rows).

This is institutional knowledge. It lives in postmortem docs, PR comments, Slack threads, and the heads of engineers who were on-call when things broke. No model has access to that, and no amount of code generation replaces it.

Now multiply that by every repo on GitHub. These repos are not just code files. They're the accumulated result of thousands of architectural decisions, production incidents, discovered edge cases, migration strategies, backward compatibility constraints, and debugging sessions that shaped every conditional and every retry policy. A model can regenerate the text. It cannot regenerate the understanding of why that text exists.

So ... The engineers raising these concerns aren't coping. They're the ones who've spent enough years in production to know that "it compiles and the tests pass" is where the work starts, not where it ends. And that code generation was never the hard part!!

Dismissing that experience as cope is a lot easier than engaging with the actual argument, which is probably why it keeps happening.

[Ben Dickson @bendee983]

Agreed that a large volume of code before AI was slop. But I don't think that's the main point.

The main problem is that before AI, slop was being generated at human scale and it could be contained/controlled through management.

Now, AI causes several problems:

1- An AI coding agent can generate more slop in a day than a human would in their entire lifetime
2- A lot of people are entering software development jobs who have near-zero knowledge of code, and they are shipping AI-generated code to production. So now we have more people generating slop at the scale of AI
3- There is immense pressure on software companies to ship more code to avoid falling behind, so they don't have time to develop the mechanisms to control the quality of AI-generated code (including with the help of AI code review tools)

[Khalid Warsame @KhalidWarsa]

It’s funny seeing DHH speed run the psychosis cycle. Been there, done that.

He’ll eventually realize no amount of AI pseudoscience (prompt tweaks, skills, adversarial reviews, etc.) is gonna make any difference. Sacrificing understanding for acceleration isn’t worth it.

[Mitchell Hashimoto @mitchellh]

I'm so incredibly tired of seeing low-effort AI-designed web pages. I basically bounce off any new product immediately when I see it (never get a chance to judge the product itself). Lots of thin lines, glowy styles, inconsistent fonts, lots of monospace. You know who you are.

[Matija Sosic @MatijaSosic]

Please stop posting "I'm not reading the code anymore" with absolutely zero information on what you're building.

If you're building a local tool no one will use but you, of course you're not reading the code.

If you're working on something bigger and with more people, let's talk.

[terminally onλine εngineer @tekbog]

LLMs have finally hit the skill ceiling of an average software engineer who thinks that test are proof of working software

[Gergely Orosz @GergelyOrosz]

And this is exactly why “SaaS replaced by AI coded software” is not viable for any company that has a an ACTUAL business.

It’s a fun exercise to rebuild ticketing/o11y/feature flags etc… but do you really want to maintain it? Do you want updates, oncall etc to be YOUR problem??

[Adam Rackis @AdamRackis]

Got ‘em!

[Xiaoyin Qu @quxiaoyin]

Anthropic had the biggest miscalculation in AI 2026:
1. They underestimated the progress others made, and thought they can win forever.
2. Thus, they assumed their customers will continue to tolerate their terrible policies (pricing, random usage limits, bad data retention, arbitrary access removal etc.) and cocky PR because they are AGI. They didn't invest in building customer trust because they thought they didn't need to.
3. They also assumed by simply painting open-weight as dangerous and unsafe, they can persuade enterprises to not touch them and persuade government to ban them.
4. They knew user data in Claude Code is how they win, yet their bad user policy/pricing gave aways their already-sticky users to Codex/Grok/etc, enabling others to capture equally valuable user data on their own.
5. Meanwhile, they didn't invest enough in owning their compute, instead putting itself in a vulnerable position at the mercy of @elonmusk, their competitor.

When a strong open-weight provider catches up(@thinkymachines, Kimi, GLM etc.), people suddenly realized Claude has 1. no pricing advantage 2. no compute advantage 3. no branding advantage (already broke enterprise trust, pissed off prosumers, and consumers don't know Claude exists)
Anthropic needs some serious strategy pivots. The status quo won't work at all for them. They still have the highest caliber talents, so I am still hopefully they will change for the better. But simply a better model than Fable isn't going to be enough to turn things around IMO.

[Arseny Kapoulkine @zeuxcg]

one person is 10x'ing their output with Claude while the rest of the org is busy dealing with the resulting mess

[MO. Mortada @MortadaDEV]

Sir, that's exactly the argument you think you're pushing back against!!

The whole point ppl are trying to make is that ---> AI generates code that needs to be read & understood, reviewed & tested, b4 it gets merged... exactly like that one generated by human.

That process has been, and still should be, the industry standard for decades. Not a single sane software engineer would ever say that "human code is flawless while AI code isn't". They're simply saying they're those steps that we enforced for 20+ years, and we shouldn't just skip them coz the author is an LLM instead of a junior.

[MO. Mortada @MortadaDEV]

Mostly agree, but "quiet backend stuff" undersells the real line.

Frontend engineers debugging loading races, responsive edge cases, and interaction states that no scaffold handles are doing the same production-ownership work.

The actual split is engineers who own what happens after deploy vs engineers who stop at "it runs." And that second group is about to grow fast coz AI just made "it compiles" trivially cheap.

The hard part was always the hard part... architecture, failure modes, debugging under load, knowing why a weird null check exists on line 379. That's stack-agnostic.

[Lunens @Lunens__]

Software engineers - the moment is coming when everyone realises it was never about MVPs and toy applications, and that your true value lies in architecture and the quiet backend stuff that makes things work. The revolution is coming. Keep your powder dry. Double down on humans being lazy and not following through. You are the vanguard of the new age.

[MO. Mortada @MortadaDEV]

This ---> "If I need to use my own AI to interpret what your AI wrote then something is wrong"...

This is the whole post distilled into one line 🫡

The diff already shows WHAT changed!! And that's why the description exists... to carry the context the diff misses. So, if you can't write 2 paragraphs about what you built & why, then you don't understand it well enough to ship it.

Not to mention this part --> "looks structured and thorough", which is actually the real trap. It pattern-matches to professionalism so ppl accept it w/o noticing it says nothing a reviewer couldn't get from reading the diff for 30 seconds.

[Kenton Varda @KentonVarda]

I just declared a moratorium against AI-written change descriptions (e.g. PR and commit messages, also issues/tickets) from my team.

AI was writing change descriptions that were worse than useless to me as I tried to review PRs: outlining details of the code that could easily be seen by looking at the code, but omitting the higher-level framing needed to understand broadly what the code is doing.

I think people like having AI write these things because the output looks structured and thorough, which makes it feel professional in a way. But this isn't actually valuable. Concise, high-level descriptions are better for everyone. If I need to use my own AI to interpret what your AI wrote then something is wrong. Let AI write code, sure, but for the description, I'd rather see your prompt than your output.

We could maybe have extended agents.md with guidelines on writing descriptions, but this seemed a bit pointless since a good, concise change description only takes a few minutes to write -- not a significant time savings to delegate to AI. At least, it doesn't take long if you understand the code -- and if you don't understand the code, then I'm definitely not merging it.

[MO. Mortada @MortadaDEV]

The "even if X could do Y, you'd still cope" template is unfalsifiable by design. It pre-dismisses any technical objection as emotional instead of rational, which is a neat trick for avoiding the actual argument.

But let's engage with it anyway. Let's think through the hypothetical instead of using it as a dunk. Say Fable 7 regenerates an entire production codebase from a single prompt. What do you have?

"You have code. You don't have context."

And boy oh boy, how this part keeps getting skipped in these takes ---> Code generation was never the bottleneck. Nobody in 2016 was sitting at their desk stuck because they couldn't physically type the characters fast enough. The hard part was (and still is) deciding how to build sth.. decompose it across services.. handle failure modes under load.. evolve a database schema without downtime.. ensure your auth flow doesn't introduce a bypass when requirements change.. debug a distributed race condition at 3 AM that only reproduces under a specific traffic pattern.

And so, if you don't have the context, you know nothing, Jon Snow.

You don't know why the retry policy on the payment service uses exponential backoff with jitter instead of a fixed interval (because a third-party gateway rate-limits aggressively during peak hours). You don't know why there's a seemingly redundant null check on line 847 of the order processing pipeline (because a specific vendor's webhook occasionally sends malformed payloads that pass schema validation but break downstream). You don't know why the database query uses a specific index hint instead of letting the optimizer decide (because the optimizer makes the wrong choice when the table exceeds 50M rows).

This is institutional knowledge. It lives in postmortem docs, PR comments, Slack threads, and the heads of engineers who were on-call when things broke. No model has access to that, and no amount of code generation replaces it.

Now multiply that by every repo on GitHub. These repos are not just code files. They're the accumulated result of thousands of architectural decisions, production incidents, discovered edge cases, migration strategies, backward compatibility constraints, and debugging sessions that shaped every conditional and every retry policy. A model can regenerate the text. It cannot regenerate the understanding of why that text exists.

So ... The engineers raising these concerns aren't coping. They're the ones who've spent enough years in production to know that "it compiles and the tests pass" is where the work starts, not where it ends. And that code generation was never the hard part!!

Dismissing that experience as cope is a lot easier than engaging with the actual argument, which is probably why it keeps happening.

[MO. Mortada @MortadaDEV]

It's EXTREMELY DISAPPOINTING how benchmarks became the new "it compiles!" these days... One dimension of quality presented as the whole story, and conveniently the dimension that's easiest to put in a bar chart.

Everywhere you go, the "rewrite-in-Rust" post is becoming its own genre at this point. Nice flamegraph, 40x faster on a synthetic benchmark, zero mention of whether it handles the 200 edge cases the original tool accumulated over 8 years of actual use.

[MO. Mortada @MortadaDEV]

"Write the code yourself, like a caveman." You mean... do the job?
The fact that writing your own code is now framed as primitive tells you everything about where the hype went... If companies are already capping tokens at $100/week, that's a quiet admission that the ROI isn't as obvious as the pitch deck said.
We went from "AI will save millions in engineering costs" to "we need hard spending limits so ppl stop burning tokens on bloat" pretty fast. Crickett's right, measure the value first then allocate.

[MO. Mortada @MortadaDEV]

Funny how the same conversation keeps splitting into two completely different arguments that ppl treat as one...

T here's a massive difference between what Prime is saying: "I write code, then I ask AI to roast it.", and what Theo is saying: "AI writes code, and I should review less of it."
One of these workflows treats AI as a second pair of eyes on code you already understand, so then the final output will be a better software. The other workflow treats AI as the author of a code you never read, and so the output will be faster merges.

THEY ARE NOT THE SAME THING ... THE RISK PROFILES AREN'T EVEN COMPARABLE.
And Prime's point about surfacing 1-2 mistakes in almost every change is the real signal here. That's an experienced engineer with years of production judgment, and the model still catches things he missed. Now imagine someone with less experience, letting the model write the code instead of reviewing it, and then reviewing even less of the output. The failure modes don't add, they multiply. Using AI as a reviewer has a soft floor (worst case: it misses something you would've also missed). Using AI as an unreviewed author has no floor at all.

And, another thing that the "validation slop" framing in Theo's tweet also misses ... AI-generated tests and type guards around code you wrote are useful because you can verify them against your intent. AI-generated tests around AI-generated code is circular: one model's output validating another model's output, with no human who actually understands the intended behavior anchoring either side. The human in the loop is not a nice-to-have. It's what turns pattern matching into engineering judgment.

[MO. Mortada @MortadaDEV]

That's not a contradiction, it's the entire point...

Context is hard to capture in text. Humans are bad at documenting it. That's a known, universal problem in every engineering org that has ever existed. But the engineer who was on-call during the incident, who sat in the design review, who debugged the flaky third-party API for two weeks, still has that context even when they didn't write it down. It lives in their head.
A model that can only access text artifacts will always have an incomplete picture, precisely because humans under-document.
The imperfection of human documentation is not an argument for AI understanding. It's the reason AI understanding has a hard ceiling.

And yeah, AI writes cleaner commit messages than most humans. No argument there. In fact, it is a real improvement, genuinely.
But a well-structured description of what changed is not the same as understanding why it changed. An AI can generate "refactored payment retry logic to use exponential backoff with jitter." Clean, accurate, better than "fix bug." But it doesn't capture that the change happened because a specific payment gateway started rate-limiting during during the Black Friday before last, that three other approaches were tried and failed, and that the jitter values were calibrated against that vendor's specific throttling behavior. That's the context that matters when someone touches that code 18 months later, and no commit message (human or AI) contains it.

[MO. Mortada @MortadaDEV]

As for "AI can go through commit history and link to GitHub issues to pull context," sure, it can traverse the history, the same way that I can read a medical textbook and link to case studies. Doesn't make me a doctor!!

The model can traverse text ... But understanding context is not the same as reading text. Most commit messages are "fix bug," "update," or "WIP." The real context lives in incident postmortems, Slack threads, verbal handoffs, and domain knowledge that was never written down. A model linking to a GitHub issue cannot reliably distinguish between a design decision that was carefully considered and one that was a rushed hack that nobody got around to fixing. It can't tell you that the weird timeout value on line 312 exists because a specific third-party API was flaky for 6 months in 2024 and the team learned the hard way that the default timeout caused cascading failures. That's not in the commit message. That's in the head of the engineer who got paged for it.

The tools are genuinely impressive at surface-level context retrieval. But "impressive at surface-level" is exactly the kind of capability that creates overconfidence. It looks like understanding, it reads like understanding, and it works right up until it doesn't, usually in the exact scenario where understanding actually matters.