Ask HN: How to deal with shipping AI-written code you don't understand?

Posted by rzk 16 hours ago

I saw this LinkedIn post from a Meta engineer and it resonated with me:

https://www.linkedin.com/posts/ali-hamie_im-an-engineer-at-m...

> I'm an engineer at Meta and I never felt this uncomfortable doing my job. I'm writing code these days and it all feels like a black box. This new standard of shipping with AI is moving so fast that if we're going to spend our time checking each line of code, it's going to take forever. That means you can end up with systems you've built where you don't truly understand how all the code works. You understand the high level, but not every detail. And maybe this is becoming the new standard. It goes against every instinct of being a software engineer. I'm used to understanding what I'm building. Now I'm trying to figure out how much I need to understand before I'm comfortable moving forward. Are other engineers feeling this too?

How are you handling this?

302 points | 445 commentspage 10

willio58 7 hours ago|

Flat-out, you _need_ to understand the code you're merging. If you don't, ownership then lands on whatever AI agent you're using. Ultimately, you can't fire the AI agent in the same way you can fire the person at the driver seat when shit hits the fan and they've consistently caused incidents that force people to work late hours to resolve it.

xinu2020 6 hours ago|

I agree with the sentiment but I would add more nuance; you have to pick what is important to understand and what you can delegate; not all code is mission-critical.

In any case at the end you're the owner/accountable so you need to justify your and your agent choices.

ReptileMan 4 hours ago||

Drink and pray.

adamddev1 6 hours ago||

The only answer is to not ship code you don't understand. And I think the easiest way to do that is not use AI for ANYTHING except troubleshooting and doc searching. Those that draw a land in the sand and develop this way will be slower in the short term but their work will last out in the long term because it will be more solid.

landdate 5 hours ago|

[dead]

benfidge 12 hours ago||

Generally speaking I brain storm the feature first and produce a dev plan. This includes asking it to reuse code/libraries we’ve already got! After it’s gone off ah done its thing we go back over and do a QA on what it’s built, why that approach, what can we do better etc etc?

billylo 13 hours ago||

I spend time to add extra observability, cross-checking and alerting at runtime to offset the risk.

lbrito 5 hours ago||

The secret is to stop caring.

butterisgood 6 hours ago||

I like starting with defining outcomes, determining invariants, and then consider TLA+ or Lean models, or both. It's generally not good to ship stuff you don't understand, but if you work on big legacy code bases from 20-30 years ago, there's probably no one who understands all the code all the time.

It's at least nice to be able to prove something about the code, rather than blasting it with tests which only prove that the tests that are written do not fail (and perhaps get you some amount of code coverage — necessary but insufficient for anything like quality).

How to do all of that in your environment? That can vary greatly!

ex-aws-dude 11 hours ago|

We just don't do that, I don't know why people talk like that is a given

Is it a company culture thing or a domain specific thing?

More comments...