DEV Community: Tarek Mostafa

Stop Rubber-Stamping "LGTM": Why Pull Requests Are Operational Contracts (Especially with AI Code)

Tarek Mostafa — Sat, 19 Sep 2026 00:20:52 +0000

Be honest: when was the last time you opened a 400-line PR, scrolled through a sea of clean-looking green diffs, thought "looks fine to me", typed LGTM, and hit merge?

I've been guilty of it. Most of us have.

Especially now, with AI coding assistants churning out syntactically plausible code in seconds, the temptation to rubber-stamp pull requests has skyrocketed. The formatting is neat, the unit tests pass on happy paths, and everything feels safe.

Until Saturday at 3:00 AM, when an unhandled edge case drops production.

When an outage happens, the postmortem doesn't care which AI generated the syntax. And the accountability doesn't just fall on whoever opened the branch.

The very first question senior leadership and SRE ask is:
"Who reviewed and approved this to go live?"

Every Approval is a Binding Signature

I recently mapped this reality into a 1-page visual blueprint for our engineering practices:

The Myth of the Casual Thumbs-Up

In software engineering, clicking Approve is not a friendly thumbs-up or an administrative chore to clear your notification queue.

It is a sworn claim:

"I have audited this architecture, I understand its failure modes, and I am willing to defend this code at 3:00 AM with my name attached."

With AI tools making code generation essentially free, raw code output has zero scarcity. Anyone can prompt a 500-line feature in 30 seconds.

Because syntax is now a commodity, code review and architectural verification become the single highest-leverage, highest-accountability acts in the entire software lifecycle.

If we treat PRs like rubber stamps, we turn our repositories into synthetic sludge dumps. If we treat them like contracts, we safeguard the system and build real engineering trust.

The Monday Morning Move

Here is a simple test I started running before clicking "Approve" on any pull request—especially AI-assisted ones:

Ask yourself aloud:
"If this breaks production tomorrow, what is my documented rationale for allowing it to ship?"

If you don't have a clear, defensible answer ready, you aren't finished reviewing.

I put together 30+ visual, one-page blueprints like this covering blast radius, distributed boundaries, and human engineering ownership in my new book: *The Unshakeable Developer: Why AI Won't Replace True Software Engineers*.

Quick Discussion:

How is your team handling code reviews lately? Have you noticed "review fatigue" creeping in with AI-generated diffs? Would love to hear how you deal with it in the comments below!

Senior Engineering is Not Making Code Work. It's Deciding How It Fails.

Tarek Mostafa — Fri, 18 Sep 2026 23:50:59 +0000

Senior engineers know a quiet truth that junior developers (and AI code generators) often miss:

Writing code that works on the happy path is easy. Any LLM can scaffold a service in 5 seconds that passes local tests.

The real engineering begins when things go wrong:

What happens when the payment provider returns a timeout?
Does that timeout exhaust the connection pool?
Does that connection pool lock up the checkout API?
Does that lock crash the entire product catalog?
This is The Blast Radius Doctrine (Blueprint #6 from my new systems architecture field guide).

The Two Types of Systems:
The Fragile Cascade (Tightly Coupled): A single service throws an unhandled error, triggers retry storms across dependencies, and takes down the entire cluster. This is what happens when code is generated without architecture.

The Sovereign Bulkhead (Fault-Tolerant): Failures are anticipated and contained. If the recommendation engine crashes, the cart still works. If the database stutters, circuit breakers trip, read-replicas take over, and users get a cached fallback.

The Engineering Law:**
"A senior engineer does not write code to make it work. A senior engineer writes architecture to decide how it fails."

AI models have no concept of organizational blast radius. They generate isolated functions, but you must define the walls that contain the blast.

🛠️ Your Monday Morning Move:
Tomorrow when you review a Pull Request—whether written by a human or generated by an AI:

Don't just check if the syntax works.

Ask: "If this specific line throws a timeout exception, what is the maximum radius of the damage?"
If the answer is "the entire service crashes," you need a circuit breaker or a bulkhead before hitting Merge.
PS: This is 1 of 28 visual blueprints from my newly released field guide: The Unshakeable Developer: Why AI Won't Replace True Software Engineers.

If you like this style of visual, bite-sized architecture guides, you can grab the full 45-page book on Amazon: 👉 https://www.amazon.com/dp/B0HK2PCRJK

What about you?
What’s the worst cascading failure you’ve ever witnessed in production? Let's trade post-mortem stories in the comments! 👇

Why AI is not going to replace software engineers (from a dev who uses it daily)

Tarek Mostafa — Fri, 18 Sep 2026 23:39:19 +0000

Hey everyone! 👋

Over the last few months, I've had the same conversation with dozens of fellow developers.

Almost everyone is asking the same question: "If Claude, ChatGPT, and Copilot can write code in 5 seconds... what are we even doing here? Is our profession doomed?"

I get the anxiety. I really do.

A year ago, I spent a good chunk of my day writing boilerplate DTOs, CRUD endpoints, and regex patterns. Today? An LLM generates that before I can even finish my coffee.

At first, it felt intimidating. But after using AI daily on real projects, I had a big realization:

AI is very good at writing code. But writing code was never the real job

Here is why I stopped worrying about AI taking my job, and what I think we should actually be focusing on as developers.

The difference between "typing syntax" and "software engineering"
Think about what we actually do during a normal work week.

How much time do you spend literally typing for loops or syntax? Maybe 15% to 20%?

The rest of the time, you are:

Trying to understand what the product manager actually wants versus what they wrote in the ticket.
Figuring out why the legacy auth service randomly returns a 502 error every third Tuesday.
Deciding whether adding Redis is worth the operational overhead or if PostgreSQL can handle it.
Protecting the system from breaking when another service goes down.
AI models are basically super-fast human translators: you give them a detailed prompt in English, and they transpile it into JavaScript, Python, or Go.

That is awesome! It saves us hours of boring typing. But the hard part of software engineering has never been the typing. The hard part is knowing what to build, why to build it, and how it behaves when things go wrong.

The "3:00 AM" Reality Check

Here is a simple question I like to ask:

When production goes down at 3:00 AM on a Friday, who gets paged?

Is your company going to page ChatGPT? Is the CEO going to say, "Well, the AI model hallucinated a database lock, so nobody is to blame"?

Never.

Companies do not pay software engineers to type text. Companies pay us to own the consequences of that text.

Software engineering is about trust and accountability:

If customer credit card data leaks, an engineer has to explain why.
If the payment gateway fails during Black Friday, an engineer has to roll back and patch it.
AI has no skin in the game. It doesn't care if the company loses $50,000 in revenue in 10 minutes.
As long as businesses run on real money and real risk, they will always need human engineers who understand the architecture and can take responsibility.

What actually matters now? (The stuff AI can't do)

If you want to stay relevant and thrive in the coming years, here are three things that become more valuable as code generation gets cheaper:

A. System Boundaries and Blast Radius Senior engineering isn't about making code work; it's about knowing what happens when it fails. If Service A dies, does it take down the whole platform? Where are the bulkheads? Where are the circuit breakers? AI can generate the code for a service, but you have to design the boundaries.

B. Understanding Data Gravity and State Code is cheap and disposable. Data is expensive and permanent. Writing a migration script is easy; migrating a 5TB live database without downtime or data corruption requires genuine engineering judgment.

C. Translating Human Ambiguity Business stakeholders rarely know what they need in technical terms. They speak in business goals, messy trade-offs, and half-formed ideas. Your job is to sit between messy human reality and brittle computer logic.

Final Thoughts: Stop Competing on Syntax

If your daily goal is to be the fastest person at typing React boilerplate or solving LeetCode algorithms from memory, yes—AI will outpace you.

But if you shift your mindset from "coder" to "systems thinker", AI becomes the best junior developer and assistant you've ever had. It does the tedious typing while you focus on architecture, reliability, and business impact.

A small note: Because I care deeply about this topic and wanted to help fellow developers navigate this transition, I recently put together a practical, 45-page visual field guide called "The Unshakeable Developer: Why AI Won't Replace True Software Engineers". It's packed with 28 system architecture blueprints, mental models, and checklists.

If you're interested in the deep dive, you can check it out on Amazon: https://www.amazon.com/dp/B0HK2PCRJK

Let's chat in the comments! 👇 How has AI changed your daily routine as a developer over the past year? Are you writing more code, doing more reviewing, or spending more time on architecture?

I’d love to hear your experiences!