Don’t let AI rust your engineering muscle

Amr El-Helw has spent 14 years inside the database engines that run the world — Google, Meta, MongoDB, and now Databricks. His PhD at the University of Waterloo focused on query optimization. He’s seen what happens to engineers who outsource their fundamentals to AI — and he has a simple, almost old-fashioned remedy.

Amr El-Helw’s career has been a tour through the layer of software that almost no application engineer thinks about — the inside of the database itself. After Computer Engineering at Alexandria University, a Master’s in Egypt, and a PhD at the University of Waterloo specializing in query optimization, he chose industry over academia. Fourteen years later, he’s built and maintained query engines at MongoDB, Google, Meta, and Databricks.

The session covered a lot — database design, system design, code reviews, testing — but a single thread runs through all of it: the difference between a good engineer and a great one is what you choose to do the hard way, even when you don’t have to.

Writing SQL that works vs. SQL that performs

Most developers learn to write SQL until it returns the right rows, then stop. Amr argues that’s where the real learning should begin. Knowing the syntax gets you a working query. Knowing how the database executes that query gets you a query that doesn’t bring production down at 3 a.m.

His checklist for writing a fast query starts with reading the query plan. Every database (Postgres, MySQL, Databricks, BigQuery) will show you exactly how it intends to execute your SQL: which indexes it’ll use, where it’ll sort, where it’ll do an expensive join. Most engineers never look. The ones who do find these bottlenecks routinely:

Unnecessary sorts. If your query has an ORDER BY you don’t actually need, it’s costing you. Remove it.

Joins on dead tables. Queries grow by copy-paste. The original author needed all 15 joined tables. You only need 3. The other 12 are still in the plan.

Missing indexes — or worse, wasted ones. An index that’s never used is overhead at write time and a lie in your design.

The database design step almost everyone skips

When Amr asks junior engineers how they designed a database, the most common answer is variations of “I just started building it.” That, he says, is the single most reliable predictor of pain six months in.

A proper database design has steps. He walked through them — they sound bureaucratic, but he’s emphatic that skipping them costs you 10x more later than spending an extra week now:

1. Requirements first. Not a schema. Not tables. What does the system need to do? Who’s entering data? What reports come out? At what frequency? Daily, weekly, monthly?

2. Entities and relationships. Before writing a single CREATE TABLE, identify the entities (patient, doctor, prescription, hospital branch) and how they relate. Use entity-relationship modeling. It’s old-school. It still works.

3. Permissions, early. Who can see what? A doctor sees their patients, not the colleague’s. HR sees doctor records, not patient records. If you bolt this on later, you create leaks. Bake it into the design.

4. Iterate with your team. The design isn’t finished when you finish it. Share it. Get feedback. Revise. The day you start writing migration files is the day after you and your team agree on the design — not before.

The AI question every engineer is now asking

When asked whether AI helps or hurts engineers writing SQL, Amr is careful. AI does help — saving hours, summarizing big PRs, suggesting fixes, accelerating debugging. He uses it daily.

The problem is that engineers, especially juniors, are quietly atrophying. He uses the gym analogy: you don’t build a muscle by watching someone lift. If you read AI-generated code every day but never write your own from scratch, you stop learning. You can still ship features — until the day production breaks in a way the AI can’t debug for you, and you realize you don’t actually understand the system you’ve been “maintaining.”

His prescription is unusually specific and pleasingly simple: one day a week, don’t use AI to write code at all. Pick a day. Take it as a workout day for your brain. Write from scratch. Debug by reading the actual error. Look up the actual docs. The point isn’t to be a luddite. The point is to keep the muscle alive so that when the AI gives you something subtly wrong — and it will — you can catch it.

Where AI genuinely can’t replace an engineer

Amr is clear that AI struggles with three things in real engineering:

Design. AI can break a known problem into tasks. It can’t look at a 200,000-line codebase, understand the load profile, the team’s velocity, and the business priorities, and tell you which of three approaches will be the right one. That’s a judgment call. A senior engineer is essentially someone who’s made that call wrong enough times to make it right.

Requirements gathering. The customer asks for X. They actually need Y. Sometimes the request itself is wrong. Translating “please make this faster” into “the join order is suboptimal because the cardinality estimate is off in this specific table” is not what AI does well.

Knowing the existing system. The codebase has decisions baked into it that are five years old and unwritten. AI doesn’t know the history. You have to. The engineer’s job is to be the human pointer between AI’s output and the actual context.

Code review and testing — the discipline that scales

Two practices that Amr sees universally at Big Tech (and often missing at smaller teams):

Code review. No code ships without another engineer reading it. The reviewer catches the obvious. The reviewer also asks “wait, why is this written this way?” — and that single question forces the author to articulate their reasoning, which is half of why review works. Comments matter, too: the author understands the code; everyone else has to read it cold.

Testing. Unit tests, integration tests, the whole stack. He admits he didn’t fully appreciate this in school. Once you’ve worked on systems where a regression in one corner can break a feature three teams away, you don’t skip tests anymore. They’re not optional in production systems — they’re what lets a team of 50 ship without stepping on each other.

Speed vs. quality — the global-system answer

The classic question: do you ship fast or ship right? Amr’s answer depends on where you’re shipping. A startup proof of concept needs to find product-market fit; speed wins. A query engine running tens of thousands of customer workloads at Databricks needs to be right; a regression costs everyone money simultaneously.

As companies scale, processes that feel like bureaucracy — design docs, code reviews, multiple test layers, design revisions — aren’t there to slow you down. They’re there because someone got burned, and the process exists to keep the next person from getting burned the same way. The trick is to revisit those processes regularly and prune the ones that no longer earn their keep.