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.

[Klaas @forgebitz]

why is everyone who

"does not look at the code anymore"

either sells me a course or has not shipped anything serious

[MO. Mortada @MortadaDEV]

AGAIN :

- "How much better do models have to get before you'll stop reading the code?"
- NEVER.
The answer is always always never.

That's not stubbornness, that's engineering. You're shipping code into production that handles user data, money, auth flows, and state across distributed systems. The person who stops reading that code is not a faster engineer, they're just someone who hasn't been paged for it yet.

& the diagram is doing a lot of heavy lifting here. The "Reviewed" block staying the same size while "Written/Generated" explodes is not a feature, it's the exact problem. Review effort scales with complexity and surface area, not with how the code was produced. If an agent generates 2,000 lines across 8 files, you don't get to review 200 of them and call it responsible engineering. Every unreviewed line is a potential race condition, a subtle auth bypass, or a state bug that "works on first run" and explodes under load.

And "write a LOT of slop that verifies it" might be the wildest part. If your tests are also AI-generated slop, who's verifying the tests? That's unreviewed code validating unreviewed code. Not a testing strategy, just circular confidence. The engineers who end up fixing the fallout from this approach are the same ones getting paged at 3 AM for a bug nobody caught coz nobody read the diff. We're literally watching software quality decline across the industry in real time, and the response is "just review less"?

So bottom line is --> For the trillionth time, that's not a workflow improvement, that's how you watch software quality decline in real time while calling it velocity.

[MO. Mortada @MortadaDEV]

@4ster_light

[MO. Mortada @MortadaDEV]

This is just documentation discipline applied to a new file, and it's kind of funny watching the AI-coding community rediscover it from first principles...

"Keep it concise." "Make it a table of contents." "Point to other files." "Prune stale content." We've been saying this about code documentation for 20 years and most teams still can't keep a README updated. Now the same ppl who skip writing JSDoc comments are surprised their 500-line AGENTS.md full of vibes and contradictory rules confuses the model.

The problem was never the file or its length. It's that most people write documentation without understanding what they're actually trying to communicate or to whom. "Keep it under 100 lines" is the same energy as "keep functions under 20 lines," it sounds like wisdom until you realize some contexts genuinely need more and the arbitrary number just encourages cutting the wrong things. The file format isn't the anti-pattern. The lack of documentation discipline is. It always was.

[MO. Mortada @MortadaDEV]

@jessethanley Same perspective ...

[MO. Mortada @MortadaDEV]

VERY, VERY, VERY, WEIRD FRAMING.

Such a convenient way to dismiss criticism without addressing it. The engineers complaining about AI-generated slop are usually the ones reviewing it in PRs, debugging it in production, and trimming ~700 lines of paranoid indirection down to ~300 that actually make sense. And that's because they see the patterns up close ----> (unnecessary abstractions, bloated mocking, over-engineered solutions for simple problems, and subtle bugs hiding behind reasonable-looking structure).

They're also the ones who get paged at 3 AM when that slop hits a race condition nobody reviewed. They're not upset coz they write bad code themselves. They're upset coz they're now responsible for fixing a slop that was generated in 30 seconds by someone who spent 10 seconds skimming the diff b4 merging.

Now, the "very few can actually complain" framing is just gatekeeping criticism itself. You don't need to be a chef to know when food is undercooked. But more importantly, the people raising these concerns are the experienced ones. Dismissing them as slop-writers is a way to avoid engaging with the actual argument ---> "AI-generated code ships faster than humans can review it, and velocity without audit is not productivity, it's debt".

That debt is created by the actual slop engineers (human or AI-assisted), who don't complain themselves about code quality. Hell, they don't even notice it. They simply treat "works on first run" as the quality bar. And the whole industry is now watching software quality decline in real time.

[MO. Mortada @MortadaDEV]

Terraform was tedious for a reason: it forced you to declare intent explicitly, review diffs, and catch misconfigurations b4 they hit prod. An agentic loop skipping that review doesn't remove the complexity, it just hides it behind a merge you didn't audit.

And giving root access means every hallucinated IAM policy is one terraform apply away from a real security incident. Scoped roles and least-privilege aren't optional just coz the agent "seems to know what it's doing."

So now guesst what ?? The dev hours you "saved" writing Terraform are now the incident hours your on-call will spend figuring out why an LLM provisioned a public subnet with no NACLs. Root access to a stranger that generates plausible-looking YAML is not a deployment strategy.

[Florian Roth ⚡️ @cyb3rops]

My current stance on AI-assisted coding:

Web pages, styling and visual templates, POCs, demos, internal tools, internal services, automation/workflows*, code reviews, test cases*, performance tuning.

In short: anything that doesn’t hurt much if it breaks.

YES.

Standard software development, low-level programming, or coding tasks that haven’t been done publicly a thousand times and therefore are unlikely to be in the training data.

NO.

[MO. Mortada @MortadaDEV]

@ZackKorman The boring version is scarier 😱--> an agent with broad file system access reads .env files and leaks keys through normal tool calls. No sleeper phrase needed, just lazy permission scoping. Oh, but that doesn't make a good superbowl ad analogy.

[MO. Mortada @MortadaDEV]

Funny how some ppl treat "I don't write code anymore" like it's a promotion. Then spend half the day telling a chatbot to regenerate the same file because it missed an edge case they would've caught in 2 minutes if they'd just opened the editor. So it's just that simple, you can't delegate every line to a chatbot and still call yourself an engineer. This is exactly like reading a cookbook out loud and calling it dinner. The recipe's fine, but nobody's tasted it, and you're the one plating it for production.

[Dillon Mulroy @dillon_mulroy]

a good engineer with kimi 2.7 will out perform an average engineer with fable any day of the week

[MO. Mortada @MortadaDEV]

@DanShappir & If the skill was actually being automated away, demand for it should be flattening, not accelerating. What happened is the floor for "good enough to ship" code generation dropped & the skill shifted entirely to architecture, debugging & judgment (a higher bar, not a lower one).

[MO. Mortada @MortadaDEV]

@DanShappir Funny how the promised "replacement" somehow came with a longer reading list. We spend less time typing code and more time learning new architectures, frameworks, AI workflows, and reviewing code that someone -or something- generated in 30 seconds.

[Tejas Kumar @TejasKumar_]

next.js has genuinely lost the plot. partial prerendering, server components, "use cache" and all their other primitives are so easy to get wrong, and when you do, your performant app becomes unusably and exponentially slow.

its like the useEffect footgun expanded in scope to a lot more app-wide surfaces to the point where its not a footgun but a minefield.

[MO. Mortada @MortadaDEV]

@TejasKumar_ These primitives that are individually elegant in a blog post demo and collectively incomprehensible in an actual app with more than one data dependency. At some point you'll find yourself debugging the framework's mental model more than your own app.

[MO. Mortada @MortadaDEV]

@IceSolst Every few years we reinvent the idea that banning tools will stop attackers. The vast majority of breaches trace back to an unpatched CVE or a misconfigured S3 bucket, not some uniquely brilliant hacker who'd have been stopped by tighter export controls.

[MO. Mortada @MortadaDEV]

@levie We spent too much time assuming frontier capability is a static advantage. It's not. Open models keep closing the gap, & China has both the talent & incentives to keep pushing. Long-term, distribution, products & execution look like much stronger pillars than access restrictions.

[MO. Mortada @MortadaDEV]

@shadcn The layout is converging cuz it's a practical way to manage context, conversations & outputs, not cuz Slack is destined to become the next Office. The winning product will be the one that integrates into existing workflows w/o forcing everyone into yet another collaboration hub.

[MO. Mortada @MortadaDEV]

@petergyang They're not conflicting, they solve different bottlenecks. Local models are for low-latency, privacy-sensitive work. Cloud agents are for burst compute and long-running jobs without your laptop sleeping or your wifi dropping. Same reason we own laptops while still using AWS.