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

I’m surprised I haven’t see anyone say this yet, but I don’t let the LLM design the code at all, I let it implement a design I have created.

By that I mean that, rather than let the LLM do the entire structure, I take the time to create the full hierarchy of abstractions and actors that I want my code to do. I decide, at the UML level, how abstractions will sit and interact — and then I make the LLM implement those gaps.

The key thing here is that, by doing this, I DO know how the code works. I may not know how each unit is implemented, but I know each unit’s responsibilities and how they interact with one another. I’ve found that LLMs are HORRIBLE at writing decent abstractions, regardless of how much prompting and skills I’ve given it. It will always get the job done, but it will often be unmaintainable and require bigger and heavier refactors as I introduce more and more requirement changes.

But by flexing my basic design skills, I don’t have those issues. Future refactoring fit into easy abstractions that I’ve designed. And by documenting it up front, I also have what becomes a living document on how this work will turn out.

It takes a few hours up front to plan ahead, but it makes the LLMs job easier and use less tokens, and it makes the code better long term. I don’t care if one unit is suboptimal, as long as the abstraction is right — because at worst I can change an implementation for a better one later.

I was once employee nr. 1 at a startup and the lead engineer. For a number of years I understood every nook and cranny of the system and knew what every line of code did.

The company got successful. At some point I had a team, and then multiple teams. Gradually, I had to let go of that level of understanding and delegate it to others. When I was overseeing 50+ engineers, I only had a high level understanding of most the systems, and only got involved in lower-level decisions rarely. All the new code was created by my team, and it varied in quality.

If I had AI tools back then I could ask it to explain things to me that my team did and have a 2nd set of eyes which had a different set of biases and abilities.

That's how I deal with it right now. I ask one AI to gen the code based on a design. I work with the AI tool and see how it builds the system out. I intervene where it starts doing things I don't want it to do. I ask another AI to review the PR after the code is written. I sometimes dig into design choices and ask it to explain them, rate them, and offer other alternatives. I sometimes change things, and occasionally scrap the whole thing and start again with better guidance.

So far I've written more code without an outage this way than ever before with a team of human developers. AI screws up too. But right now, at Opus / ChatGPT Sol and higher models, on average, it makes fewer mistakes than humans did. Any time they slip through is because I am rushing too quickly. In a pre-AI human dev team we would call this a process or management failure.

The more dangerous a decision and the harder it is to roll back, the more time I spend reviewing it. This has served me well when managing people who write code, and seems to work well with AI.

AI is a tool that needs to be managed. It won't do all the work for you, but it can speed you up greatly.

I've been a Principal Engineer for a while, so this is how I've worked for a while. Sometimes when you're a PE, you either design something and then junior engineers implement the details, or you're dropped into a project that was already designed and built by more junior engineers, and you have to quickly understand the design an as many details as you can.

With AI, everyone now gets to act like a PE. Your job is to design, the AI builds like the junior engineers. Then you review their work. You may never understand the details, and that's ok, as long as you know the main ideas and where to ask for the details (in this case the LLM instead of a human).

I’m slowly coming around to the idea that if it works, I’m good with that. I never used to personally check all my colleagues work, either, I just trusted that they’d done a good job.

That’s not to say I blindly trust an LLM - my project is an autovectorising compiler. I have it write a bazillion tests, and I have real, non-trivial programs that it compiled. I have it run a ‘gate’ before releases that takes literally hours on 5 different architectures. To say this code is tested is … masterful understatement.

I think what helps is a long planning session, going into details, working out corner cases, designing test-cases, you know work and effort. Once that’s done it’s easier to let it work through the night and do a major production feature.

I still review the code, but hand on heart I couldn’t say I’d reviewed everything, sometimes I miss something in a complicated check-in. I try to keep checkins small and contained, but sometimes that’s not easy to manage alongside the “don’t break stuff” rule as well.

So it comes down to: I’ve been working on this for 6 months or so, and so far this has worked out for me. You know, kind of like getting used to a colleague’s idiosyncrasies over a period of time.

I will say that in my experience the code quality is fairly high. Maybe that’s down to the effort put in ahead of time in the planning stages, I don’t know, but I don’t seem to suffer from the ‘slop’ that people complain of. YMMV.

Testing.

Lots and lots of testing. I usually interactively test with the LLM. Now that I'm spending less time, coding, I get to spend more time, testing.

In my experience, I test more, with an LLM, than I did, with my own code. I don't find coding errors, but I do find implementation errors.

On another note: I ran an LLM on a bunch of really mature code that I wrote, and could swear was "perfect," and it found a number of issues.

Nobody's perfect. Trust; but verify.

The comments are horrifying. They do everything they can to avoid reading the code they are responsible for.

You must read the code before shipping it to production.

"But I don't have time!" That's not even an excuse. At least one person in your company should be able to explain the code! How would you answer when reviewer asks why did you use this very algorithm?

"We have tests." They could help. But don't rely on them entirely because there's a high possibility that the tests are wrong.

I can't believe how many people proudly admit that they don't read code. I'm not entirely against using LLMs to write or review code, but not even trying to read it should be prohibited. Someone responsible have to review it.

Edit: I know that LLMs are very good at writing code these days. My point is that this is less a matter of quality and more a matter of responsibility.

What I don't understand is that for most SE jobs on mature codebases, writing code is maybe 5-10% of the work. And it's that 5-10% coding that keeps you 'grounded' in the code and keeps your tacit understanding up to date.

Get rid of that and you get a basically invisible productivity increase (call it 10% to be generous) but you've now lost tacit understanding. No amount of half-assed code review (or getting the LLM to generate "code quizzes" etc for you) is ever going to substitute for the tacit understanding you get from doing the 10% of coding yourself.

I really just don't get it. I mean, I can believe that using coding agents gives people a rush of power and fleeting illusions of increased productivity, but it's a mirage.

A lot of the comments here are trying to find some middle ground, i.e. trying to find some way to preserve tacit knowledge. But it seems to me that it's a waste of time. You either need to write the code yourself or completely give up on even reading or attempting to understand it. I just don't think there's any middle ground. Any well-intentioned attempt to preserve understanding of the code will fall afoul of human laziness and understanding drift

I work for a company that’s all in on AI right now. For all intents and purposes - I have unlimited budget, but I’m spending may only $50 per day on the busier days.

Right now I have 8 agents open in my terminal and I know I'm on the more-sceptic end of AI users. Some folks here pull thousands of lines of changes, day after day.

With this many agents I don't even have time to read what they output, not talking about the code - just their output. My work today has been (sadly) degraded to: 1. Ask AI to explore the repo. 2. Pick a solution that works for the 3 solutions that AI proposed. 3. Maybe do few rounds of follow ups. 4. Create PRs. 5. Ask agent to verify if everything works post merge.

Some of my colleagues apparently skim through the code. I pretty much don't look at the code anymore.

It's just sad. I'm self taught programmer, hobbyist. I always liked working on my stuff and always were trying to deliver high quality. I no longer can't say that, despite my best efforts.

I literally have tasks right now where not only I don't understand what the agent is doing, I don't fully understand the problem either. I could invest time to understand it and agents do a pretty good job themselves, but remember, I don't read the damn output.

That said, I work in the infra team, not in the product team, so there's that.

In short: I "pick my battles carefully", and I'm not afraid to refactor after the fact. I'm also not afraid to make changes by hand when needed.

Picking battles: I lean heavily on AI for the mindless, boilerplate changes that used to take 2-4 hours; but instead AI can do it in 2-4 minutes. Then, I pay closer attention to performance critical areas, or areas that require deeper thinking. Finally, I lean on AI to review the changes. It gives me a better review than a human, and often thinks through things that require "superhuman" intelligence.

Refactoring after the fact: This is similar to working with a team of subordinates or lower-cost contractors. They (people or AI) write the first version, get it working, and then I pick the few areas that need cleanup. I work closely with AI to refactor it to be more readable; possibly to handle corner cases that weren't anticipated earlier in the design.

I'm also not afraid to make changes by hand when needed: The fact is that sometimes, changes are so minor or otherwise require a particular understanding that it's easier to do the change by hand instead of describing it to an AI. I hope where you work understands this and supports it.

This is how every product manager feels every day.

If you're an LLM prompter shipping products, you're outputs are more akin to a product managers, not an software engineer's.

It's not too dissimilar to life as a Principal level engineer pre-AI. You technically oversee the work of many engineers on their own systems, but you couldn't possibly review all the code yourself. You appreciate that human code review reduces, but does not eliminate, the number and severity of bugs shipped to production. You don't have the low-level details in your head, just the high-level ones. You design how all these engineers interact with each other, without stepping on any toes.

Time will tell whether we were right to move from a system where we trusted humans to understand the low-level system, to one where we trust fancy calculators. But so far, it's working.

The closer the code gets to the user's eyeballs the less I care about anything specific.

HTML/JS/CSS is basically entirely vibe coded. I won't even try to reorg the 4000 line ui.js file. I can just redo the whole thing from a new prompt in a few minutes.

For things like the SQL schema I am still doing things entirely by hand. The consequences of getting this part wrong tend to be far more catastrophic than something in the UI layer.

These threads kind of rule. Lots of different answers!

For my part: I've put some of my tooling energy into code comprehension tools. You can get remarkably far quickly by just replacing the Github PR viewer! I started with a (native SwiftUI) read-only front end for tree-sitter and SCIP (the code-indexing standard). Then: as I reviewed PRs, I tried to catch myself doing annoying repetitive things and just building out additional features, like "show me all the knowable call chains for this function", or "show me every implementation of this trait".

You can get a fair ways just by thinking of things to hide in a PR viewer, just to clear space for the things you need to comprehend.

Creating rigid boundaries is the key. You can create the architecture doc along which the code can be built and any deviations needs to be approved first.

I lost my ability to fully explain the systems I work on around the time I transitioned from next-edit-prediction AI running in my IDE (early Copilot) and working primarily via Codex/Claude CLI's.

The further away I got from the implementation details, the fuzzier the semantics became. To the point that now I could not in good faith say I understand the system I have built from the ground-up and worked on the last ~4-5 years.

The solution to this, in my mind, is not to revert back to reviewing implementation details. The economics of that from a business/productivity perspective don't play out well.

The only viable solution in my mind is adapting code/languages themselves to the shift by making programs formally verifiable. That way you can be sure that the code "does what it says on the tin", and provably so.

I feel so strongly about this I've written on it:

https://gavinray97.github.io/blog/design-by-contract-and-eff...

I can think of so many times this has happened before. People getting used to MVC, Dependency Injection, ORMs. Sometimes the code is so large you only work on a part of it, so you have to get used to a lot of not knowing.

So how do we build confidence anyhow when we can't know everything?

I think first, standard checks - does it compile? What do static analysis tools say - code quality, passes SAST analysis? Linters? Style checkers?

Do the tests run? I'm not comfortable with the tests I write let alone the AI.. by adding fault injection (fuzzing, chaos), and mutation testing, I have a better degree of confidence in the tests and code.

Spend even more time getting to know the product instead. Maybe I don't know the code as well as I used to, but I know the product backwards and forwards. That helps me have some new confidence that I didn't really have before. Knowing the greater whole.

I always try to think how product owners deal with this. I used to write a lot of code, so did my colleagues, but the product owner was the one driving the effort - they definitely didn’t know how to code, but they “shipped” results regardless - they develop relationships with individual engineers, make sure to understand their strengths and weaknesses, insist on automated testing and then hand verify results, whenever on assumption the engineer expressed but turned out to be not true they push to extract the uncertainties.

Slowly build understanding of what is possible, push back on engineers suggestions and don’t approve stuff blindly, but relying on results to guide them not the implementation.

It is very very similar feeling. -you need to know your models and harnesses (e.g. your … team). You don’t need to know the specifics of the code but doublecheck with different personalities if the assumptions are correct, test them.

And ultimately shipping bugs is a given , human engineers do it _constantly_ it’s the resilience systems you build around that which saves you, tests, canaries, rollbacks, feature flags, everything we already know how to do - just use that and imagine yourself the product owner.

I'm miles away from all of this as a non-user of AI and it seems like a mania to me.

Technically it's just a role change. You're now the project manager or something, not the developer. It isn't a project manager's job to understand the code, only to ensure it does what it should and doesn't do what it shouldn't. And to ensure the developers, etc str unblocked and doing well. Embrace the new role.

you never understood every detail of what you were building. There was always code written by others, colleagues, open source libraries, etc. You would depend on that code every day. And now the scale is much bigger.

What I do: I have a mental model of the system and how it works, at different levels of abstraction, in all the ways I think matter. I test that mental model against reality by making the agent proof it's real, looking at the implementation myself and seeing how it behaves in production.

Every day I'm making hundreds of mini risk assessments on what happens if I get a specific assumption wrong. If I'm not comfortable with the risk, I figure out a way to de-risk it. Maybe a slower rollout, maybe I read the code for longer, etc.

It's certainly a different job. As a startup software engineer it doesn't feel against my instincts though

Software Engineers work has never been coding but using structured systems to solve problems, we have gotten so used to the grunt work that we think that is the main work, I believe AI has brought clarity to that, which is a good thing, where it goes wrong is when the system used to solve this problem is faulty, unstructured or inaccurate due to negligence, that is where we need to watch out.

Here's my strategy:

The codebase I work on was designed to be split by features. Architecture is well thought and each feature has the same high level abstractions, all code is in one folder. This bring several interesting guarantees: code is scoped to this folder, each feature is "not too big" and fits in the llm context easily, and a design document explains architecture choices, that is well respected by the llm.

When the llm works on a feature, it is instructed to do several things to help me catch errors before shipping. Write a templated description of the change: interactions with external systems, sequence diagram, happy path, corner cases, deploy checklist, settings change, etc. I review high level choices, and not the code.

Finally, the llm add review threads to the code everywhere it made suppositions and related to untested assumptions. Each of this comment says: what could not be teste, what the llm thinks, what happens if I don't change anything and release the code.

Finally, on parts where I want to be sure, I do llm-instructed testing. It can build complex test benchs in no time, fetch data from production "provide me the command to fetch data, and a script to anonymise it", do a before/after comparison, ... It costs few tokens but it buys the peace of mind.

This way I have a workflow where the code is fully written by the llm and I don't go crazy reading its code.

Ask the AI how it works!

It's totally fair to load up some open source project into an agentic IDE and instead of asking it to write something ask questions like "how does X happen when I use feature Y?" or "can you explain how client code could accomplish Z"

All the time I see an AI use a language feature or library feature that I never used before or I see some code I don't understand and it does much better than a lot of humans do at explaining what it did.

I use LLMs and agents to only do what I could have done myself, given enough time and hands and keyboards.

If I'm working with something I don't understand, I ask the LLM to teach me first, with as many references and correlations as I need to fully know what's going on.

I also do the architecture myself, but ask for periodic suggestions for improvements and checks on how other systems are doing it. If I see a newer system I think makes sense, again I ask for explanations until I understand it.

Idea is always that the agents assist me in doing something I could have done myself if I didn't happen to only have 24 hours in a day and other parts of my life to live.

I only find this is a problem when it writes code in a language I deeply understand. I can’t help but look at it, get the LLM to change it, etc. But when it writes me a Cloudflare worker in Typescript that I don’t understand, I couldn’t care less. It works, that’s good enough.

So I suppose we just have to care less and let it get on with it. Not easy tho, for sure.

At our company hackathon I led a team focused on this issue. What we landed on is in the future looking at code diffs is going to continue to go down. AI can write the code and AI can review the code and we are going to see bug rates go down at a "tactics" level.

What matters are the high level decisions in the code such as "Deleting an account removes the row for good", "Email becomes the user’s permanent ID", etc.

We imagined a completely new concept for code reviews where you review the decisions not the code diffs. Also if you want to review the code it is grouped by concept not by random file diffs.

This is coming from someone that likes manually coding btw but our PR size and velocity is increasing too fast to meaningfully review all the diffs forever.

1) Need to triple down on infrastructure (safeguards, tests, sandboxes, etc.).

2) Ask agents to do more than just code.

They need to fully demonstrate and prove that their PRs are rock solid. Ask for screenshots, videos, code reviews, detailed architecture diagrams, etc.

It would be an insane amount of work for humans, but AI can do it easily for each PR.

Merging any PR from an agent should be a no-brainer if there's real proof that the feature is built correctly and working.

If there's still doubt, then the agent needs to do a better job of proving that the feature is built correctly, doesn't introduce regressions, etc.

I don't think this is even new. If you ever made the career transition from a dev, to lead, to managing lead in the same project, you are already familiar with that.

In the beginning your had your hands deep in the code, knew every corner and every pattern. Then you became teamlead, coaching other devs and only reviewing their code. Then you became managaing lead taking over more projects - now you don't look at code anymore, but you still manage the people that write the code and make sure the code fulfills its requirements and delivers on product roadmap. You develop trust in your team, you barely every read their code. If individual teams or devs ship bad code, you will only learn from prod defects, but the measures are mostly the same - fix the team.

Well, it's simple. Don't do it.

My job barely changed, except I’ve replaced dog shit “offshore” contractors with an LLM, deliver more features faster with a smaller team and fewer bugs.

I was struggling with this today. Working on a feature and AI review flagged something so I need to fix that. I iterated multiple times throughout the day and was completely exhausted cause each iteration was always complicated with the fix being ~1k lines. Finally landed on a one I felt at least a little comfortable submitting for review but a work day like this is super draining and I felt like crap the entire evening (I am about to go to bed, I am probably gonna have nightmares about pressing enter and enabling auto mode on plans that make no sense in a true nightmare sense)

I try to understand WHAT all code does rather than exactly HOW it does it. Large scale design choices, how it is tested (and that it is) etc.

Even if you have a 20 file 5k line change set, it's still not impossible to just grok what's being done, what the purpose is, and what it works like on a high level.

LLMs don't change the fact that such a review is difficult, but I'm more confident that there are no hidden off-by-one issues in 5k lines of LLM code than in 5k lines my colleague (or myself) wrote. So it's a welcome change in reviewing to do it on a higher level.

My workflow involves research, then technical design documents, then implementation, and a very heavy emphasis on E2E testing.

Having had to use Meta Ad Manager recently, it's all starting to make sense.

If you continue down this path, your golden goose is COOKED

For me personally, iterating is huge. You can't arrive at a hugely complex system in one shot. I think of the LLM as someone I'm running software engineering "experiments" with. As requirements become clearer, I discuss with it more and more and over time I'll gain a stronger understanding of the problem and possible solutions.

You'll also discover over time which systems the AI can handle fine on its own and which abstractions and systems it just has no ideas on how to design. Often I find I have no idea how to design those too. It's then useful to try different designs, test tradeoffs and refactor aggressively if needed.

Just as I handled using a full text editor instead of punch cards. Or C instead of assembly. or higher-level languages instead of C.

You always need to understand a bit of the past technological layer before saying your goodbyes to it and moving on to the next progress phase. That's life for a programmer.

Actually, it is quite similar to a /compact with a harness: you need to "sum up" you current knowledge (aka abstractions, design patterns, ...) from time to time to carry it along with you in your journey.

I think it’s basically true that the job is now that of a manager with worse but more obedient underlings that you need to micromanage.

A manager never read all the code, you just need to find the level at which you are getting good results. For some tasks you need to read every line, even write every line, for some tasks you let it do everything and just test the feature.

Test driven development and the testing pyramid.

If the agent has written tests and crucially - witnessed them fail before starting the work to make them pass - you have a lot of confidence.

Review of your own work's easier too - test and production code tend to mirror each other, giving you a much more complete picture. Confused by the production code? Go read its tests for a bit, then come back.

It's also easier to understand the change if you were there for the build, watching the transcript, checking in every so often. Doesn't have to be your primary task - leave it on a second monitor, it'll catch your eye naturally.

And finally, on top of test-driven development, have the agent first (before the first test driven development cycle) build out an end-to-end test covering the work it'll do. Once that test is green (test driven word for "is passing") you're done with your work and can clean up at will.

Play with it before shipping, get it real nice. It's never been easier to clean the tech debt up and make the UI perfect.

Eventually you'll be ready to package it up into a PR!

Now's you can leverage agents and get creative. Make your colleagues froth to review your work. Consider making a Loom video to walk them through it. Consider reworking it into a commit series; it only takes a few second for your agent and you can tell a story for humans. Maybe you want to sequence it according to your struggles; maybe it's better to show the different layers emerge with each commit - it's up to you. Consider also that your agent can easily do one-off visualizations of the change for your colleagues if you think it'll help them, and you can attach those too - mermaid charts or even whimsical AI generated images. All this is because motivation is driven entirely by other humans' motivation and you want them frothing with excitement every time you drop a review. Make it fun, it takes seconds and gets your stuff merged fast while making your teammates smile.

This is a brand new job and we will work out how to do it together :)

> if we're going to spend our time checking each line of code, it's going to take forever.

How many more lines of code are Meta engineers shipping that they don't have the time to check the ones they _didn't_ write?

This makes no sense to me. So I spend vibe coding some app. I barely know code. It's 40 000 lines without comments. Say it's my job, and pays the bill at the end of the month. Say the LLM and I would have done the vibe coding within a week. I'd need one more week to check every line and understand everything. I'm a noob, this dude's a pro, so complexity is irrelevant. What the hell are they doing the rest of their time? Shipping more code?

And if that's true, and again, I'm a noob: shouldn't their "instincts" tell them to write tools to increase comprehension speed? Better interfaces? I hate everyone single one out there and designed a better one. Now I have to port to Rust/Actix/GPUI and some vibe coded redis because that thing is laggy as hell ... but I HAVE TO UNDERSTAND HOW it works because otherwise I cannot improve/customize the stuff/frameworks already out there and that people build with ...

What are they doing with their time? There are all these posts out there of programmers and systems people not doing anything 90% of their time? If it's already shipped, don't you try to understand the details afterwards?

"Great leaders hire smart people and step aside so those experts can guide and solve problems instead of being micromanaged"

- Ask questions, clarify and ask "Do you have any questions".

- Build systems for robustness, like you would build when delegating to human engineers. Tests are just an important but small part of it. (Take ownership)

- Lead with examples (not just skills.md or what-i-want.md). It cannot understand your abstractions.

- Peer reviews (Across agents or across models)

- Clear division of responsibilities (Context engineering - Agents/SubAgents)

One of the approaches I'm taking is to try hard to simplify the code generated by LLMs. If you can reduce its complexity, it usually means you have a fairly good idea of what's going on in the code change. I consider which edge cases are getting unnecessarily handled, which new vocabulary was introduced where existing or simpler vocabulary would be fine, etc. etc.

I also have a /simplification-check skill I run after pretty much every large change, and that already helps surface the murky areas of the code and sometimes remove complexity before I even start reviewing, thus accelerating the review.

I created this VSCode extension. I call it Guide-coding. Works well for me

https://marketplace.visualstudio.com/items?itemName=novian.g...

I do what I call a shallow review. I don't look at every line to find bugs, but I want to understand the intent and see if model doesn't cut corners (of course you want to use 5th carousel element as a profile picture, great UX right?)

You don't. If you do then please stop calling yourself an engineer because no self respecting engineer would ever sign off on something they don't understand.

I've gone through multiple phases.

Phase 1 (mid 2025): Have AI write the simple stuff if you want, but hand-write the important core stuff.

Phase 2 (late 2025): OK, let AI write the important core stuff, too, but review every line of code.

Phase 3 (early 2026): Wow, AI is making virtually no mistakes, so only review the important core stuff that it writes.

Now (since mid 2026): If using newer models like Opus 5.5 or Astra, no need to review its code as long as the behavior is as expected. I'm no longer a software developer or coder, I'm a software creator.

I wrote a local code review tool to help me understand it - https://github.com/imron/crt/

Tests, observability metrics/alerts, and backups. Worst case, I can rollback everything to a point-in-time where the system is stable. Its a tradeoff I'm ok making for the increase in speed of features to market. Also depends on your industry. If my app handles money movements in a ledger I wouldn't feel as comfortable with AI development. But incorrectly handling like counters or reposts at Meta is low stakes wrt AI.

Welcome to my life! I'm a System / Platform Engineer working with 90% proprietary products. Understanding just enough of the systems we run is a skill.

In the last few years we've shifted into building more things in-house. It's awesome and we can solve even more specific needs for the organization. But the situation with understanding just enough does not really change. We just don't have time to dig into every line of code like you say.

I don't know if this is the correct way but it is the pattern I have fallen into.

Written code is the new compiled code. You never look at it, not even once. Documentation is the new written code.

Every repo has a /docs folder that holds the full specification of the code. Full architectural block diagrams, edge case behavior, style, problem statement, etc. I closely review these docs and make sure that the agent follows these specs and ensures the specs are updated after every code change. In theory an agent could fully rebuild the system from scratch using this documentation.

Maybe this is just pearl clutching, but it helps for when people ask architecture questions and I can answer and pretend I know what's going on.

The time that I would have spent typing in the code is now time I use to test the code. I really like to poke at things and ensure that my understanding and reality match.

I agree with the advice to design your system before implementing it. It is pretty easy to iterate on a design with your favorite coding assistant, and this is your chance to be ultra-picky and make sure you get exactly what you want. This was always where the "software engineering" was done, but in practice it's easy to have a vague idea and refine your (internal) list of requirements / tradeoffs as you type in the code. I find it harder to do that when the LLM is generating the code, just because one turn can change so much.

Keeping it under control requires discipline, just like before LLMs were a thing. You set a bunch of engineers loose on your codebase with no vision or supervision, you get spaghetti. You just get a little bit more control now. Agents don't feel shitty for the rest of the day when you tell them to do it some other way, so you are free to review as critically as you want without hurting anyone's feelings. I think it's a good thing.

The traditional answer is the same for engineers going into engineering management because managing a team and managing a set of agents is highly similar, only managing agents is far easier. One only ever has the illusion of control, and so you have to set your mind to containing the worst possible outcomes and looking at the net efficiency and efficacy of the team with the understanding that they will, on average, never be perfect.

I'm surprised by a lot of the commenters here. People that are saying just wait for all these codebases to crumble for us to be needed again refuse to acknowledge the reality of what is happening around us. If that is your take, I advise you to become really, really good at programming and work somewhere in the realm of critical infrastructure or financial institutions where presumably agent written code will be last to permeate.

I do get the sentiment but the conclusion doesn't make sense to me. We have been solving problems as engineers at different layers of abstraction for a long time. Pre-AI, I used frameworks that abstracted lower level concepts away which made it faster to develop the solutions that mattered (aka solving problems for the end user). I could, given enough time, write the underlying database adapter to convert my business logic form into a database query and back out but I didn't need to because someone else abstracted that part away. Did I know how well that adapter was written? No. Were there bugs in it? Occasionally you run into a limitation or bug the author hadn't considered that required a patch or fix. Going a step deeper, the programming language itself is an abstraction that compiles into machine code or bytecode. Do I understand machine code or kernels? Definitely not. Some programmers do, especially if you have a compsci background, but I'd wager the number has been decreasing over the years. The point is, now agents are writing code and they are now pretty damn good at it. Better than the "average" programmer out there. Now we get to "program" in natural language by telling the agents what we want and they get to worry about nailing the syntax and all those details while we focus on the higher level decision and direction of what's happening. If your agent written code is sloppy and terrible, that's a skill issue not an agents write bad code issue. You need to setup the systems that result in code to your standards with the checks and balances to test and QA appropriately before it hits production.

Complaining about the state of things while sitting back with your arms crossed refusing to adapt to this bold new world is a risky strategy. People saying just don't use AI and do your job as normal are also going to have a difficult time. The devs that can leverage AI effectively and get a lot done will out leverage you to the point where it doesn't make economical sense to keep paying you to not use AI (unless you are in one of those super critical fields I mentioned earlier and even then I'm not sure those are safe). Isn't it more fun to embrace this new technology and figure out how to use it effectively vs complaining and refusing to acknowledge it? Help shape the future instead.

>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.

"This new way of piling bricks is so fast that I can no longer afford to check the buildings integrity".

I just don't understand how the fuck we ended up with this narrative. Somehow the machine making things twice as fast forbids us from spending time ensuring quality? Surely if it does things faster you have more time and tools to check!

I'm half convinced this frenzy is the marketing work of AI companies at this point.

One of the keys for me was the use of types. Typestate when functions mint witnesses that can only come from it and are required to proceed and newtypes where you use custom types instead of strings so the agent can't forget. You can also use it to force the agent to use the implementation rather than reinvent the wheel by simulating linear types. Types are a much smaller target to optimize and provide constraints that fail loudly at compile time. (https://news.ycombinator.com/item?id=49806799)

I maintain a SPEC_SHEET.md file while asking the agent to keep teaching me the detail of the changes made or feature built after every iteration. This gives me a small handbook after I finish the project. I keep reading it like a book and learn how things are working inside the codebase and sometimes when required, I follow the code side by side while reading the spec-sheet.

You have to design your process for writing code to handle more code than you could ever read. To do this you also have to accept that you will not be able to hand manage all of your agents and all of your projects. The key thing is to figure out how to manage your time better and spend your efforts unblocking your agents.

What I did was build my own process for this: https://github.com/mhalstrom/maximizepm

The main take away is: 1. You need an agent to manage your agents that you mainly interact with. 2. You need a durable way to manage tasks and the dependencies between them. 3. You need agents with multiple roles ie manage, build, review etc 4. You need to manage yourself across projects so any system you build needs to take that into account

I still read most of the code agents right, so I am good. If I won't have time to do it , I will make sure at least I understand how different systems communicate with each other and what each of them do.

Maybe what makes me more comfortable with it is that I'm in Operations. 95% of what I ship to production is not code I've written, and a huge part of what I ship to production is not code I even understand. Day in and day out I'm responsible for tens of millions of lines of code involved in running a service: Linux kernels, userspace, application servers, databases, monitoring. I'm responsible for reliably running this whole stack.

So, for me, end of the day, it's all about testing, monitoring, soaking in staging and promoting to production.

This might be why I'm fairly comfortable shipping AI generated code.

If you work at Meta you should ask at Meta.

For my own projects I’ve limited my exposure points by picking which projects and what scope I ship. I have to iOS apps in the App Store and I simply removed high exposure surfaces - right now neither use accounts because I don’t want to manage account systems, and Apple prefers it anyway. I downrisked my projects from what I could ship and I’m perfectly happy with my production projects.

Most of my other AI written projects are internal apps and systems. I have another project going public soon where I ship the output of LLM written code, without running the code in any user accessible area.

And tests, of course.

In time things will mature, tooling will be better, and we’ll have a different risk quotient.

I'm currently working on a combined Aero sim/CAD/CAM software for designing, simulating, and performing DFM optimization specifically for Group 1 to 3 winged UAVs.

What I do is ask Opus/Gemini to explain the parts I don't understand. And I do some of my own research to verify accuracy of the explanations.

In addition:

* Every new feature has a Feature Design document which I review, modify, and approve. And a corresponding Implementation Plan which I also review and approve.

* Every fix has a RCA document and fix Implementation Doc which I review, modify, and approve.

* There's a global high level Architecture and Design document with additional sub component design documents which are always kept in synch after a new feature or bug fix is done. Synching it is always a step in the Implementation plan.

This does adds some overhead but it allows me to have have check point gates. This has often allowed me to catch misunderstandings and align properly before any code gets edited by the AI agent.

Having the above docs also helps when it comes to referencing them as context to properly ground new features or bug fixes.

I shipped code I didn't understand when I copy pasted from Stackoverflow before. At a level if it works it works.

Built a tool that helps me at least get a better gist of complex changes: https://github.com/sshah03/perspica

It's not perfect, but it's helped so far.

Some code implements architecture, it is the skeleton of the program. Some code implements features, it is the flesh. The "flesh" is often isolated, if it is broken it can be replaced without major impact. The "skeleton" on the other hand needs to be correct. I make sure to understand the skeleton as well as critical features. I don't take the time to understand non-critical features implemented using AI, I just make sure it writes lots of automated tests.

Maybe a bit unorthodox but I have it plant 1-3 bugs into the code it writes (depending on the size of the MR I'm working on); they range from simple one-off issues to something more structural.

It then gives me a hint on the area or a typical code flow that would hit the bug - whichever gives me less info. I can obviously ask for more hints as I read along.

Obviously all honour-code based since I could just ask it to fix the bugs itself. I think this is something that can't be fixed systemically - either you're going to bother reading and thinking through the code or not.

Other than that I guess reading the tests - to make sure they fail without the code / fix, to make sure the setup makes sense etc.

I saw that post on LinkedIn and my immediate thought was just use AI to explain the code to you before committing. I do that and it's quite good and fast. I personally prefer to understand every line of code that's committed with my name on it, or in a repo that I own. I guess it's passe now to expect this of everyone?

Basically, don't let the AI coding era peer-pressure you into being a bad engineer.

That would explain a lot about the latest news.

If Facebook is hiring and looking to replace the idiot who made that linked in post, I'll be honest, my ethics are at an all time low, I would work for you. Plus, I can guarantee I am capable of doing BOTH no-shits-given programming and FULL-shits-given, so I'd be perfect for your payroll where a straight upgrade is warranted.

I've been spending a lot of time iterating on feature implementation plans with Claude (at work) and GPT (for personal projects).

I then make sure they write a lot of tests and that if functionality is changed or added/removed then tests are updated alongside.

Generally I try to review changes myself and ask it to explain the changes.

It's not perfect but I feel like the planning step being iterative isn't all too different from my old research -> think about implementation -> implement loop.

At that point, reviewing any code changes goes hand in hand with how I coded before LLMs.

The major difference is I usually have it make any changes for things I don't like.

I think there's a balance to be had. Leaving everything to agents when it comes to throwaway prototypes, one-off test env. scripts, extra tests I'm fine with. Doing the same with features - absolutely not - especially when it comes to financials. Seems like Meta is pressuring engineers into becoming expensive spec generators because they want to be in the cool kids club. Time will tell if that's a good play but to me it just sounds like a quick and dirty way to obliterate their engineering culture.

It’s very disconcerting. I think this will largely be solved by going all in on AI and use it to test and review the code in an adversarial manner. That won’t be cheap but it’s the only way I see this work. But a lot of companies will probably save money and use AI mainly for writing code and then skimp on review and testing. I bet we will see some huge blow ups with AI written code and hopefully the industry will learn.

It also took the industry quite a while to accept that server code needs to be secure even if that requires a lot of extra effort. AI will probably be the same.

Im currently building a ui framework for unreal. I dont enjoy ui work so I wanted a way to have to write less ui.

For me I dont look too closely at the implementation but I look at the api where if a human was using my framework how is the code they'd have to write and engage look at. Then I also do plenty of performance against a comparable target in my case slate (default unreal) and keep overhead minimal.

So good performance and reasonable public facing api are the 2 main pieces im focused on. Less with the internals.

Care about the seams and interaction and the things you can measure or count.

Claude to Prod. Every day.

I had same problem, but after a while I just accepted that is inevitable

I've seen a few people who lean into what the leadership wants as a form a accelerationism.

I think the standard cyber liability insurance that companies buy will go up for AI generated apps in the near future. They and other business insurance companies are on the hook when things go south.

What the worst case penalty of the bad code/app?

Whenever i stuck creating a project by AI Agent or vibe coding tools. I take a rest and go for a walk and make mood fresh. Then i came back with a power and this works alot for me. I have used this to add best attractive sectioins to my site : animeflvv.com

I quit my job at a large corpo, and moved to a smaller company that doesn't try to push velocity at cost of quality.

You need to get on top of that code. Read it, understand it and rebuild the parts you don't understand.

That's essential as you should really "own" the solution you sell and take money for, as you're responsible for what it does on your customers' hardware.

It comes down to the blast radius of a failure happening in your system. Some stateless frontend won't require much beyond visual inspection, but if you introduce some client-server architecture or require payment processing, you must consider the cost of a security intrusion when auditing code changes.

we've been working on an open-source ide that is just meant for code review. https://github.com/devdotfast/whiteboard/

your coding agents can draw interactive architecture diagrams with it that reference the underlying code so you can get familiar with a diff from a high level and drill down if you need to. we've found it super useful to quickly get a sense of your own changes before sending to colleagues or shipping.

This is as much a top-down issue (managers incentivising AI use and high velocity) as much as it is a bottom-up issue (devs knocking out issues faster than they can review)

It's a problem that requires a united approach from both sides.

A need to pace oneself, as it were.

I built and use https://smalldocs.org, which is a rich document format (mermaid diagrams, nice formatting, etc.) for agents. So I’ll be like “sdoc me the architectural ideas for this feature” and it helps.

* Focus on the data models. Design them carefully.

* Review any code that modify the data (when possible, avoid migrations that can't be rolled back)

* Staging/PR deployments/feature flags

* Observability

* End-to-end black box integration tests for the main features (unit tests are mostly useless)

You hit deploy and hope for the best, if it goes bad You just prompt the model again....

Just kidding, it's de same as with any other Open source plataform You install from their repo. It will be hard at the start but then You Will be very aware where it starts to fail and how to fix it.

I don't ship code I don't understand. I fully review every line if it's going to prod.

My dumb little utils in ~/.local/bin? Those get merged after a quick functional test without my having read a single line of it. Still, the skill I maintain for such a job directs agents to write such throwaway scripts in anything but shellscript because I might want to extend some day and fuck shellscript

We should never have cost cut away proper QA departments. I suspect they'll be back

I've been playing with this https://getchronosphere.com. It will (attempt to) rebuild a PR in a coherent journey rather than a massive blob. It's been somewhat helpful up to this point, and still improving.

I think the solution is leaning on static types and hard to abuse abstractions to make programs correct by construction. It does mean that you’ll still have to use your brain to design the internal code architecture, and just use LLMs to fill in the boring bits between the safe abstractions.

Force to always use TTD, at least validate the tests.

Recommend reading (All though a little self serving): https://www.linkedin.com/pulse/ai-code-quality-jorge-varas-a...

Maybe the new meta should be reviewing new code at the end of the week/month rather than at each merge? But even that might be too much of a bottleneck. The alternative is to talk to your agent to understand changes at a high level without reading every line of code.

I'm calling it: the next (or soon-to-be-next) step forward is finding ways to understand AI-written code. For now, you can ask a frontier LLM, they've become much better at avoiding hallucinations.

build the contracts on the test and verification side around critical paths and things you want to optimize for. everything.. honestly, let it go lol. at some point it becomes another level of abstraction.

Write it in a theorem prover! No really!

This kinda makes me think about the transition from writing machine code by hand to using a compiler. Did people feel similar at the time that they didn't understand the machine code that the compiler was writing for them?

Bin it and start again but this time without AI.

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?

I believe it's the management's responsibility. If the management is in the state of AI psychosis and wants slop shipped as fast as possible - so be it. It's their area of responsibility, not your's. If they don't care about quality at all - why should you? I mean this literally: why should you? Quality is not a universal value and for some projects iterating quickly truly makes more sense than shipping something that actually works.

During my 30+ years career I have never worked in a project where shipping slop (AI or pre AI, doesn't matter) was an acceptable solution. That's my choice and I'm pretty happy I have always had the opportunity to focus on quality of the product.

PS: LLMs are wonderful. We should learn to differentiate between AI-generated slop and AI-generated code.

Tbh if it's really crucial I let the PR sit there for a while and sleep over it, poking at it every now and then over the course of a cple days, until I'm comfy w it ...

I just think that the level of abstraction, or black-boxing, we are experiencing nowadays, is the same experience that developers felt when they switched from assembly to C...

Build tools to help you understand. Build metrics that are proxies for the things you'd care about. Add constraints to the agent's work related to performance, error monitoring, language and architecture choices, review bots (that you tune and eventually, trust). If you don't have good ideas for tools, ask Fable what the best coders and industry experts would look at to establish trust, then feed that into models to build it. Don't sleep on how useful something like a (data-backed) claude artifact can be - i setup one today to track dependency and known vulnerabilties with a burndown chart and (agent) run log, one prompt, it was usable 5 minutes later. A colleague of mine did the same, but as a datadog notebook that also wires in relevant API metrics depending on what code has gone out in the last week, and suggests new longer term metrics to monitor as a result. Etc etc. its a crazy world but this has helped me cope so far.

Someone said it in a (Hacker News) post the other day, incredibly simple formula:

Brain AI Brain

You start the thinking, you tell Claude what to do, you think about what it built. It's that simple.

My Jira tickets are written by AI started just feeding the ticket into AI (shrugs)

No I only do that for unit tests so far

I went through like a mid-life crisis when the thing I learned/spent last 13 years on became meaningless.

> How to deal with shipping AI-written code you don't understand?

Stop shipping code you don't understand.

Is there really any other solution? You can either ignore it and pretend like it's the new era of software like half the other commenters are, or you can sit down and understand the code and what you're shipping.

Why not ask AI to explain it all line by line and write sequence, high level and low level docs? But I prefer not giving 100% control to AI

That's the neat part, you don't.

Or at least, I don't think people should.

To me this completely goes against the whole point of engineering.

IMO If you don't understand the code, then you're just a manager now. Soon your salary may also reflect as such, assuming you get to keep your job.

The same rules from 10-20 years ago:

have an architecture

Be consistent. All parts of the app should look like all other parts of the app.

Dont allow clever code

break things into modules

do true unit testing, meaning test the smallest unit of code possible.

Formal verification, pick a language that has it integrated and prove relevant post conditions.

AI still does not know how to even write code that makes impossible state unpresentable so testing won’t help.

It's simple: you don't. You slow down. It's essential to understand what you ship, before you ship, as there are real world consequences for not doing so, ranging from wasting the time and energy of yourself and others, up to failures which cause a great deal of harm to people and the world. To knowingly ship code you don't understand is grossly negligent, regardless of how common it becomes.

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.

Maybe a related question:

How do you keep the IEC 62443-4-1 auditors happy?

This is how we end up with "regulations written in blood", btw.

That and "oh, it's just software for a website that doesn't do anything important that couldn't actually damage anything".

I don't. I understand it, and if there's anything I don't, I ask it about it and research until I do.

Just don't - simple as that.

>How are you handling this?

easy, don't write code with LLMs. If my job forced me to do so I would quit.

By taking responsibility of it, maybe by saying "Hey this is not a good idea", and if that doesn't work perhaps by switching jobs if that's an option?

The mental gymnastics developers are willing to go through just so they can avoid standing up for something is quite perplexing.

I went exactly through the same process. And that's why I developed agent-squad: https://github.com/gzurl/agent-squad

My conclusion was I had to elevate myself and make sure another agent reviews and tests the code (QA) under the supervision of a third agent (CTO) that defends my vision.

If you want psychosis to end sooner, just approve it so they realize speed is not the answer.

Literate programming like Knuth and flesh out every aspect of the design.

Product doesn’t care. And most of us will get replaced by agents. I guess around 30% of the engineering workforce will keep their jobs which will be mainly to keep the product up and running, doing whatever it takes (so using agents to fix stuff basically).

The ones who get to keep their jobs will be rebranded as Maintenance engineers with a lower salary. VPs and Heads of will keep their cozy job (bc there are not so many of them), and they are not that dumb to fire themselves.

Code understanding doesn’t matter anymore (or won’t matter soon)

I remember less than 1% of the code I ever wrote. AI hasn't changed anything for me.

I don't understand how my residence was built. I don't understand how my car was built. I don't understand how politics works. I barely even understand how humans work.

I am perfectly comfortable prompting AI and then seeing the end result and not questioning any of the code. I've looked at code for nearly 20 years or longer, I can't even keep track how long anymore. Started with QBasic and DOS scripts. I just always accepted it as an annoying necessity, and then the world changed two times. Once when they started paying us good of money for it.

A second time when programmers became an insufferable bunch. It wasn't about the art of the product anymore. It wasn't about working with the other parts of business to understand the customer's needs and building to that. It became this weird gatekeeping bullshit where we turned on each other and started asking people to reverse binary trees and implementing search on a white board after 2 weeks of interviewing. And then rejecting them because "culture fit". Add in all the other misogynistic racist stuff, and yeah, this industry is messed up and it's rotten from the inside.

Ever software is a "I don't know what those previous engineers were doing, it's poop, so we have to refactor and rebuild with this new tech", and repeat endlessly. And quite honestly, every piece of code (mine especially) is garbage.

So I think this is great. Programming was a means to an end. It became over glorified. Now it's dying. I'm here for it and I support it. Now anyone can build an application no matter how complex, and the only thing that really decides success from failure is the actual business around it.

I love using AI, but any feature it creates I test the hell out of it, i become the QA testers I hated and do all sort of ways to break the app, and after 100 or so hours, I have a bug free and fully working app, now will this app scale as I add more features that to be seen.

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?

A major part of my job (and this was true before the "AI boom") is saying no.

No we can't call the CRM from our client side using a static bearer token even though their docs say we can. No we can't simply switch to Postgres even though it supports 99% of the same SQL we currently use. No we can't simply block usernames which are "clearly" profane.

But if we can chat about it, then we can see what the REAL problem is, and then we can come up with a fitting and simple solution.

The problem is that I have an AI colleague who is way more energetic and willing than I am. They love to talk, they seem to ramble on endlessly about any subject. And its the kind of solution oriented talk my PM loves to hear. And indeed my <insert senior role here> talks to them (or really, lets them talk), and draws up a comprehensive and confident plan to do X. I pick up the plan and discover problems with X, let alone the plan to do it.

I feel nervous about raising issues with X or going through the plan again though, because my other human colleagues are already speeding through the work for Y and Z that my AI colleague is aiding with.

And so maybe I'll raise my biggest concerns with X and not sweat the small stuff. Maybe next time I won't raise my neck at all, noting the gleaming axe sitting in the corner.

I don't know, I just consider quitting, but the money is still keeping me here.

I only ship code I don't understand if it comes with a proof of correctness

I'd quit. and I did, even before getting my first job that was not an acquaintance's startup, not counting this summer. in fact, I got fired this summer for having called Claude Code "a decent search engine" afther the first two weeks. I fell in love with making code run fast on poor hardware back when I was 8, and now there is a high likelihood that I'll end up a truck driver.

my only response to those who remain and try to control the slop is

  Praise the Omnissiah!

and really, you should have an Imperium/Mechanicus-level devotion (whether it's to money or to AI itself) to survive this and not burn out. in my region, though, you are not getting money - salaries were slashed in half across the board over last two years.

https://t.me/djinni_official/2163 (go in with translator; infographics are in English but explanations are not)

at this point, for a junior, it's easier to find a well-paying blue-collar job than to get into tech, and the ceiling is falling at the speed of sound.

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

if you have to maintain it, you will still have to get an understanding of it when it breaks.

not understanding the detail is quite similar to a coworker writing the code and another coworker approving and merging the changes.

An engineer from Meta not knowing what they're doing is exactly how I imagined engineers at Meta. Thank you for confirming it's an actual reality.

On the other hand, not even surprised anymore most people even try to provide serious answers to this. Welcome to the pure insanity.

Say amen and hit push!

Wait WHAT! I am struggling to review the deluge of AI-written code (I assume like everyone else) but I never ever considered shipping something I didn't understand? I sometimes need the AI to walk me though it a bit; and I am not saying it couldn't smuggle though obfuscated code; but I at least an understanding of its apparent function.

Not sure if your engineering quality culture has gone backwards or not, but I would never ship code I do not understand, no matter who or what wrote it.

That is the road to hell. Even if your higher ups think it isn't, this strategy will for sure blow up in their faces soon.

I predict that Meta is soon going to be going on a hiring spree to fix all of the issues this strategy is going to create.

I'm building a high level code explorer, like the CASE systems of a long time ago I suppose. I also built a facility called zork that lets me and an agent explore the code system together like a dungeon, taking notes as I go and if you want to take the metaphor too far, 'invoking spells' or rather commands like code references, call flow, data flow, exception flow, profiling, labelling design patterns and validating implementation, etc.

With zork I can also just start typing in a code file and leave instructions for the agent to fill in or fix parts of the code while I'm editing it. So I can lay out what I want the class shape to be and don't have to implement all the annoying little parts. This feels more like the GitHub Copilot days.

I honestly believe more of us will pair program with agents, not just yelling at a chat window.

The car vendor does sell you cars he doesn't understand. You drive a car you don't understand.

At least someone in the chain has to take over the responsibility in respect to litigations. That one has an interest to understand the inner workings of AI generated artefacts.

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.

It feels like another layer of "conceptual compression". I'm not sure who/when that phrase came around but in context of Rails is where I heard it and its things like ActiveRecord or really any ORM. You aren't writing the SQL directly, something else is and for the most part it works. Then it doesn't work or your database grows too much and you need to optimize table structures with indexes, etc.

My point is if you don't understand the fundamentals of the underlying code (SQL in the example above), you're more likely to have issues in the future. Or maybe not if that app doesn't reach a usage pattern or complexity where the nuances under the hood matter.

It really depends on what you're shipping. Meta ships social media apps where in the grand scheme of things if something is broken software wise it largely doesn't matter. What's the worst case? lost ad revenue? Users can't do things? If that were software for MRI machines or aerospace where software issues/bugs can result in lives lost then it matters much more in understanding what is going on at all levels of the software and potentially hardware.

At the end of the day it's really about developing a feel for it:

You will know intuitively if it's worth taking a closer look or if u can safely close your eyes and just commit it right away.

I usually know which meta questions are crucial to clarify with colleagues and where to check the code punctually.

If you never LGTM’d when a colleague dropped a hefty PR on your lap, why would you do the same if it were a robot

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!

The conclusion I came to is we are going to move from a hard science where everything is known, to being more like social science where everything is a guess based on confidence intervals. It's what happens when no one human mind knows the system well enough to predict what any small change will have on the rest of it. We call such computer systems "balls of mud". [0] says most deployed computer systems are balls of mud, so it's not the end of the world.

All vibe coded systems are balls of mud by definition if you use the conventional definition. If you allow "understandable by an AI" then right now not much changes because AI aren't so hot at designing systems and even if they could, they make poor use of their limited context. Whether that changes in future is the big unknown.

We already know how balls of mud evolve. New features are "bolted on the side", making the system more inscrutable. These bolted on systems often grow interdependencies on each other, creating a spaghetti of relationships no one is aware of. This means every change could introduce a bug whose blast radius is the entire system. Changes get harder and harder. A death of sorts, or at least a growth limit is reached when on average every bug fixes introduces more bugs than it fixed.

Google Chrome is a fine example of this happening right now. It used to be a highly modular combination of mostly independent systems that had their own champion who understood them intimately. They left, Google management insisted the client platform that supports most of eco-system continued to evolve and grow. The ball of mud was formed. It's been evident for years chrome has a higher bug injection rate than Firefox. As complexity grew it became too hard to move to new tool versions, so compilers and libraries got pinned to known working version. That made it too hard to use as a component, so projects like ChromeOS are being replaced with Aluminium OS. Now the that Matt Jolly has thrown in the towel [1] it's hard to see how distributions like Gentoo and Debian that used his work can continue to ship chromium. Debian can use ungoogled chromium, but vendored libraries, obsolete tool chains, inability to do forky mandated reproducible builds make it look like it's a foreign object bolted into a true open source project. This is what software death looks like. It's not a bang, projects cease to evolve, then can't meet new requirements, and then are replaced.

It doesn't have to be that way. Projects like the open source kernels are decades old, but their strong stewardship has ensured they remained decomposable, so people can work independently on different sections without too much fear of stomping on each other's toes. Open source stewardship seems particularly good at this, possibly because open source projects can take a very long term view. A manager in a large organisation on the other hand is usually around for only a few years. They take the short term wins that come from features bolted on the side safe in the knowledge the long term death of the software will be somebody else's problem.

[0] https://www.researchgate.net/profile/Brian-Foote-2/publicati...

[1] https://lwn.net/Articles/1097760/

the guidance / guardrails, agent roles, etc are the critical thing now, it's kind of like meta programming AI to get the outcomes you want. Any problems need addressing at this level. You don't need to understand all the code, but you should understand how the system is building up and adjust as needed. This would be an architectural review process you go through with AI. Features to code that should plug into existing architectural structures are generally no problem. It's just boilerplate code AI is generating. But architecture is only one aspect, you should have lots of guidance for all kinds of thing. There's security, performance, correctness, QA, Ux, Deployment, Process, Monitoring etc and having feedback systems for everything. You keep refining and reviewing your guidance and the impact it is having. As well as this you are molding the product for the things you want via feature development. What I'm not sure of is if you are some cog somewhere in a company like Meta whether whatever slice you become responsible for becomes a bit meh if you are mostly just prompting a feature and not much more. As a developer in a smaller company (we are global with a smallish tech team) I get to do a lot of things from interacting with our customers through to the entire backend and get to make critical decisions about nearly everything. Nearly everything in the company is starting to be driven via guidance and feedback loops (including on the guidance itself).

The secret is to stop caring.

If you are a senior engineer then there is no need for you to be shipping code that you don't understand. People can definitely generate code a lot faster than before, but you also have a magic genie that can help you critique and improve the code that you're reviewing, including when that code was written by agents.

An experienced senior engineer with access to a coding agent is the most powerful code-understanding system that has ever existed. There's no excuse for shipping or approving anything you don't fully grok.

Don't.

This is why I (QA eng) became the most important guy at my job. My tests are the glue that keeps the AI slop working together. If not for the comprehensive testing framework that I have running in every CI the company would have collapsed by now.

Don't.

By doing so, you debase your own profession.

You are accountable.

You're going to have to understand it one way or another, either at writing or at debugging. Even if you delegate all debugging to AI, you'll still need to determine what is "right".

If you don't understand the code at writing or debugging, you'll pay the architectural price (where it degrades). That price may be worth paying, but that depends on the system you are building.

I will get downvoted for this comment on this forum but I will call it out.

You wont be able to review or understand code for much longer.

There will be just too much of it. The vastness of code libraries in 5 years are hard to imagine by today's standards.

We need to develop tools that help us understand.

If you take a step back here, there has always been a group of people who have "shipped code to production" — in the sense of being responsible for the software that was produced -- without ever reading it or knowing it in detail. I am talking about your engineering management. Maybe not your line manager but certainly your director.

I think a useful perspective is "How does engineering management control software quality?" You will know the answers to this question: testing practices, design documents, SLAs, release management. You will know this because you almost certainly have to comply with some of these as a SWE. All of those practices exist because code produced by humans is not perfectly reliable and thus there need to be checks and risk reduction steps to manage the software that is shipped.

The way I view agents is that all of us have become engineering managers now. So those tools are now your tools. You set up the practices and frameworks and make the agents use them. If you set them up right you can be very confident in what the agents wrote without ever reading it.

Now you're not going to go from nothing to "Hey I ship code I've never read" overnight. It takes work. You have to set up your project carefully so that the agents can’t make mistakes. But all you have to do is be systematic about it. Every time the agents do something stupid or they ship a bug, you think, "How do I put something in place to prevent this entire class of bugs from happening again?" As you iterate this process, you will continuously be ruling out entire classes of bugs and eventually you'll be able to trust the agents.

Example: I had a bug, or a class of bugs, where agents would write a database migration and it would be wrong. It would get rolled out and the database would be broken. I fixed this by putting in a migration testing framework where there was data written in an old schema, then the migrations would run on that data. Then you could write tests on the expected result at any point after any migrations. Then, I put in place a rule: if you write a database migration you have to write a migration test. That fixed the problem. I have never had a migration failure since.

So this is not some magical process. It's going to take you hard work to set up your system with all of this infrastructure to make the agents maximally productive. But as you iteratively improve your system, you can reach a place where you can have agents ship code without reading it. It's not just about making the system work but it's also about building your trust in the system that you have. I routinely ship code without reading it now and I think I've shipped about two bugs in the past two months (and I’ve written ~500k LOC in that time). And one of those bugs was very explicitly my fault for telling the agents they could violate one of the frameworks in place (oops).

I don't.

A lot of comments here saying “don’t do it.” I think that’s shortsighted. The speed gains from LLMs are massive, and the code they produce (Opus 5.5 at least, in my experience) is correct most of the time. Once a developer or a company realizes that, there’s no going back. There are two problems, however:

1. If you keep shipping AI-written code you don’t understand, you become entirely dependent on the AI to maintain it, because you lack the mental model you’d need to jump into it quickly.

2. You can afford to do this as a senior, because you can tell when the AI does something suboptimal. But how is a junior supposed to develop that intuition when all they start out with is AI-generated code?

Drink and pray.

I just don't do it. If I'm paid to be responsible for the code, which I am, then I've got to understand it all. I'm gradually developing an instinct for when it would be good to outsource something and when it would be better to think it through and do it slowly and consciously. We all need to learn to do this.

This week I've actually learnt something at work. This is what feels good. Building yourself. There's no long term joy in building things you don't understand, especially if you're building them for someone else.

Peter Naur in 1985 wrote that programming is the act of building a working theory of the system in our minds, and this often takes form as tacit knowledge in the head of programmers. Even if you handed the complete codebase and perfect documentation to a completely new team, they would often need to go back to the old team and ask questions.

And before agents, we often built this working theory of the system by writing the code by hand. It helps us figure out the "grain" of the codebase so we have a better idea of how to extend it.

So what happens when agents are writing the code? The main avenue with which we built the working theory of the system in our mind is now taken away, and we're left feeling like our understanding of the system is blinded.

I ended up more or less changing my entire workflow. Four main principles:

1. Interrogation/interview-based design and specification

2. Make the decisions that matter and leave the rest to the agent.

3. Use agent to generate explainers, quizzes, and simulations.

4. Use verifiers and guardrails in the coding loop.

Interview-based design and spec

When I tell the agent what I want to build or extend, there's naturally ambiguity. But the agent knows what is ambiguous to it, so it can ask me. /grill-me is one way to do this. You'd think this would be commonplace now, but it's actually not. Some people are still wondering why they're getting bad results. It's because they're not resolving the ambiguity.

Making the decisions that matter

Not every decision matters in a product. Agents are fast at writing code and pretty good at some of the nitty gritty details, so I let it make those decisions. Also, if a particular subsystem is commonplace and undifferentiating, such as login, then I also let it make architectural decisions for that subsystem.

For decisions that are product differentiators, where that differentiation is supported by technology, I make decisions on the stack, the architecture, and the approach. This is the design phase. Because agents tend to make the mainstream decisions, they almost always take a midwit approach which doesn't leverage the technology in a way that makes a difference for the customer.

Some try to build this understanding from code reviews. I personally don't think it's the way to go, because it's not motivating. I find that I'm more motivated to learn how the system works today, because I want to change how it works tomorrow--and it sticks in my head better too (no different than pre-agents).

Generating explainers, quizzes, and simulations

As I'm doing design for an improvement and I don't know how a part of the system works, I can ask questions of the agent in chat. If I still don't get it, I can ask for diagrams (either ASCII or mermaid). But if it's an entire subsystem, I have a skill in which I can ask for visual and interactive explainers. It'll generate a markdown page (or html) that has these interactive components that help demonstrate a concept.

To help make the concept stick, there are quizzes after each section and at the end.

With the computational simulations, I generate a throwaway tool in which I can explore the state space. This doesn't happen as often, as I try to keep state spaces small, and for those explainers tend to work well.

With the design simulations, a same-model agent and a cross-model agent and I will talk about an explainer, and we'll name things that we understand or notice about the design and the intended direction we want to extend it. Then, we'll use subagents to generate options and then discuss the pros and cons. I find this is a good way for me to understand the dead-ends of a design.

Using Verifiers and Guardrails

I define guardrails as mechanistic checks that doesn't change with the feature. such as linters, typecheckers, and pre-commit hooks are all guardrails. Verifiers are mechanistic checks that will be different with each feature, such as unit/integration tests.

For more complicated states or concurrent parts, I'll ask the agent to use formal methods to write a proof. Then use the proof to generate a trace (a series of steps that demonstrate a happy or unhappy path). Then I run that trace in unit tests (kinda like property-based testing--so I guess this can be called trace-based testing), and the code has to adhere to the trace.

I also wrote a design verifier, where the requirements in the spec can be converted into a series of mechanically checkable rules. Then during testing, the verifier fires up the headless browser and uses the DOM measurements of the page to see if it matches up to the rules. This was completely impractical before agents.

All of this so a) I can be sure that the agent is doing what it's supposed to with the decisions that it's making b) I can be out of the coding loop, so that I'm not up at 2am begging, "you fixed this, but you broke that. pls fix." The agent can check for itself.

---

If any of this sounds helpful, lemme know. I've been wondering if other engineers care about understanding the code that's being written, or if people just don't care anymore. I've spoken to a few, and it seems to be split. And it may just be a matter of degree and detail. Some like it at a higher level. Some like it nitty gritty.

Why not just force the llm to be much more concise and require that every line is worth its code. LoC is a inability after all.

> it all feels like a black box.

I have some work in Lean4 that I'm certainly unqualified to validate; Layer Coding QEC derivation, Positive Grassmanians and the Fresnel-Kerchhoff correction to the Parallel-Axis theorem, Huygens intensity as an alternate model for simulating photonic and electronic interference in a double slit experiment, for example.

It was a black box but I'm letting it tutor me about it so

Visual proofs, Tools for logic and formal methods in distributed systems

Things that compile logic!

> That means you can end up with systems you've built where you don't truly understand how all the code works

Though AI coding and system development can be overwhelming due to information overload and rapid growth in complexity (and concern for unwittingly embedded mistakes, the unsecurability of agent-based development, and number of LOC of code per day), not understanding the whole system sufficiently is normal and expected in engineering.

I deal with it by not doing it.

You just stop caring. Everyone else did about three months ago. Time to find something new to care about.

If it's important code (and much isn't), then I spend a lot of time using Matt Pocock's /grilling first, and then I get the agent to kick off peer-review with other agents, and surface any disagreements. Some models are better at it than others. This usually forces me to broadly understand the architecture, and I spend most of my time answering the design questions for which there isn't an obvious solution. I have been pretty happy with the code I've launched to production, as measured by the ways it breaks, and by how agents who weren't part of the original committee describe it.

This is the state that founders and decision makers are usually in at a startup. Sure, sometimes you have the coder founder who wrote the first iteration of the product, but many times the founders have no clue how the product works under the hood. They entrust that to the engineers. That was then. Now, much of that engineering layer has been removed, so the founder just needs a smaller team of people who understand how to structure the software and interact with the LLM. LLMs do the rest.

The problem here is that you're trying to do a job that is already being done for you. Maybe you don't yet trust it to do a good job, but that is quickly changing.

Anyone who trusts the output of LLMs uncritically, even after the impressive level models and harnesses have gotten to, is borrowing against their future.

Models and harnesses have gotten really good, but they still are hard-capped by the operators that use them. The sycophancy of models is perhaps their greatest weakness, as when a user who might be experienced in one area attempts to use AI to build within an area they are less familiar with, the model does not take a step back and examine the "why" of what is being built from an architectural standpoint, it simply performs the expected task in a direct manner, ultimately creating sloppy work that may be easy to ship but difficult to maintain.

A good example of this was a recent interaction I had with a Dev who was very familiar with how to develop embedded and system level applications. He and every other dev are being asked for increasingly more due to AI, and he had to bring something he had built as a single-user desktop application into a distributed cloud environment. He ended up rsyncing a copy of his working directories including multiple credentials and sensitive internal project documents to a virtual machine binding it to a public ip address. Thankfully our tooling detected this before he could get any farther but it illustrates how the AI model isn't doing any real thinking or engineering at the end of the day. Unless the operator knew to instruct the model about proper cloud architecture and understood best practices around deployment of public systems, the model simply did what it was being told to do by a user who didn't know any better.

Another example of this is the sheer amount of unsophisticated users we've been detecting using Javascript injection into their web browser sessions as a form of automation for web services they may use. These users would never know to ask how to request an API token which may allow them to accomplish things in a much easier and approved way, and instead are relying on the frailest possible automations that expose them to risks of credential exposure.

We've got to be careful with how we engineer things with AI models. Just because we've made boilerplate easier to generate doesn't mean that we can avoid the actual engineering of what we do. And I can't help but think that firms which are fully committed to AI code generation, won't just be introducing an avalanche of slop into their product which will explode the costs of maintenance over time.

When you code, do you understand the asm code being built? What are the cache line access patterns? Most software developers have already given up the details of how things work, and lean on tools to handle them.

Which is fine, usually. Depends on what you are doing.

The things that always mattered were the core system, the trunk of a tree if you will. The branches less so, and the leaves not at all (though that is what people see and appreciate! The irony!).

Now the question becomes what happens when those LLM become very good at abstraction?

How do you deal with code other people wrote you don’t understand?

Same method.

if i was working for meta i would be more concerned about my culpability in undermining american democracy.

If you don't understand it, then you haven't built it.

Do not

It's Meta. Shipping crap is par for the course. You're fine.

This was something I personally struggled with for a very long time, so much that we ended up abandoning the product we were working on to build a solution:

https://theseus.dev

Basically, Theseus reads your pull request and your codebase, categorizes the kinds of edits that were made, and writes human-readable documentation that describes what changed. Then, it shows the explanation side-by-side with the code, but presented in a way where you can decide what you want to skim and what you want to deeply review.

I don't think engineers should have to choose between wading through thousands of lines of slop and just smashing LGTM on every pull request. The problem is that the tools for code review are built for an age where code was expensive to write. Now that code is cheap, we need to start experimenting with tools that allow us to stay in sync with what's going on, while also not needing to review every single line individually.

no one can force you, take responsibility for what you ship, what you choose to ship, how you choose to work, you signed that contract you go to work every day, your company is composed by people like you

don’t wash your hands, or at least don’t expect us to wash them for you

Replace "AI agents" with "a bunch of human coders" and you'll see the answer. Your product needs decent testing and it's your job as the responsible person in charge to make sure that's in place and working properly. So if anything you probably want to be reviewing the test code. But often that isn't necessary since you can do things like introduce bugs deliberately and see if tests fail; check test logs for information that confirms the tests were run as expected; try some manual testing once in a while; ask for new more advanced tests (e.g. test performance not just functionality); and so on.

> How to deal with shipping AI-written code you don't understand?

Recognise you aren't the one shipping it.

The part that makes me uneasy is when the AI writes both the code and the tests. They might agree with each other and still miss the same thing. How are people here checking for that without doing the whole job twice?

> I'm writing code these days and it all feels like a black box.

When you write C++ or Rust do you try to understand the generated assembly code?

Any software engineer shipping A.I. code should stop calling himself an "engineer."

Imagine the carnage if real engineers started vibe-designing bridges.

This is OT and a cheap shot, but if I were an engineer at Meta I would have felt pretty uncomfortable well before AI showed up...

The people doing this work as a career and not performative art, who were already good at their job, had no worries about this to begin with.

The code was always a black box. Always.

Specs come in, passing tests come out. If you find an issue, your specs were shit.

Anyone that has ever had to outsource work to someone else knows this. If you've ever worked with another team whose codebase you didn't touch - you know this.

You write your specs, you launch an agent to implement them. You launch a 2nd agent to keep the first one honest. When done, you launch as many agents as you have budget to try and poke holes in the implementation. As it always was the case.

You can thrash around (and you will), you can fight it (and you will). Like it or not, the genie is out of the box, and the realization you were never really good at your job to begin with is gonna set in eventually.