PSA : AI writing Code and AI replacing engineers are NOT the same thing

PSA : AI writing Code and AI replacing engineers are NOT the same thing There is a big difference between AI writing code and AI replacing engineers; atleast at the bigtech level. I work at an innovation/applied ML team @FAANG. This post isn't for freshers -- there are many covering this topic. This is more so for engineers who have just entered the workforce and they're worried that they'll never get into the top jobs/big corps won't hire them because code is written entirely by AI. I'm going to break down what a realistic dev cycle of work looks like at my place. Coming down to it -- DOES AI write all the code at my level? Yes. However its half true and really team dependent. I'm literally at the forefront whipping Claude 4.6 Sonnet/Opus everyday and I can tell you it's very good at complicating things if you don't know what you're doing. I'm a senior MLE on the team. Writing simple, easy to understand code is a highly underrated skill. Yes, all of my code is written by Sonnet/Opus 4.6 No; it's never one shot. Yes, my experience and understanding play the critical role in writing the actual software. Writing software goes more like this: - I find out what needs to be done from the JIRA ticket - I grab a coffee with the last dev that touched the codebase to understand how reliable the existing documentation is - I grab the product or project manager to help me understand the vision that isn't clear from the JIRA ticket, incase I'm doing bandaid fixes instead of symptom treatment - I Gemini and research my way to see how other people have reliably done it if it's something non obvious, and read about what went wrong from that - usually my day ends around this time, so I'll head on over home and make a mental note to do X and avoid Y - I breakdown the problem and brainstorm with a plan that does the tests first for what I understand were the problems a subpar implementation will cause -> tests for what it's actually meant to accomplish and a baseline for what is acceptable. Bear in mind, all of this is just planning and not writing any code yet - I let sonnet/opus rip *now*. First to write the tests, then to ensure its not silently bullsh**ing them - FINALLY, the actual feature gets written. Ofcourse, all by Claude, I don't write a line. I get it to document it correctly with the right IO args as well as function docs. I have it update the dev docs once this is done satisfactorily with a [dev] tag. Here comes the "over complication" problem. Claude loves writing code more than it does reading code. Context about the existing codebase and repo is very important: - I have a subagent (Claude Opus, again) that I've set to review the code for DRY and YAGNI violations. Every team has their own version, but this is what is a code quality gate for me essentially - I ensure if it's something new being written it reuses what I've got on the repo and doesn't duplicate any code - Before committing to a staging/main branch I get the code audited by Claude Code plugins for code-review (available for teams and enterprises); or something like coderabbit This then gets committed with an MR raised with the last "most relevant" dev added for a peer review. Their job to be the final quality gate, my job to ensure I'm not wasting their time on BS that is reasonably caught by this flurry of tools They either "LGTM" the request and it gets committed; OR there are suggestions that need to be weighed for actual fixes vs pedantic ones. Either way, resolution and agreement are prior to the code going live. I'm more concerned with helping juniors -> mid level -> seniors in their output than writing code. Actual writing of the code has never been the hardest part of the job. It's the ability to maintain enough context and simplicity that, by design, the whole project is a well oiled machine with cogs (devs) plugged in and out without disruptions. Naturally a massive part of the job is understanding who knows what, why something needs to be done, what being "done" looks like, strategy to mitigate risks due to these changes, and context for why it needs to be done "now" vs "later" vs "never". In other words: actual engineering where code is a means to an end, but the processes and the mindset for it are what drives the work.