You Own the Code Your Agent Wrote

How much of it do you actually need to understand?

There is a short post from earlier this month that reached the front page of Hacker News. Its title, Don’t be a Meat Proxy, struck me. Someone asks you a question, you paste it into an LLM, and you paste the answer back. The information travels through the keyboard but doesn't travel up the arms to your brain.

There's an engineering version of this that isn't quite as direct. You're the owner of a web app and the client asks for the ability to insert new data through the app. Seems simple enough; you already have a working app and it's just one more feature. You send it off to Claude Code to implement with specific unit and integration test objectives. It finishes and you manually test it. It works. The data gets uploaded to the backend. You open the PR.

This client request → scope → prompt process repeats itself three more times this week. Then next week your colleague wants to do the same. They ask how they should go about it, how the data flows through the app, and how the code behaves in one specific scenario. You're stumped. Or, worse, you're in a meeting brainstorming version 2.0, and no one has any ideas since no one has a deep mental model on the project. So you record the meeting transcript, feed it into Claude Code, and just build whatever it says. This will get you to tomorrow but generally doesn't lead you to the production goal three months down the road.

Ownership rights and obligations

I'm pro agentic coding. The trick is figuring out how to keep up and sometimes when to walk it back. Our original duty of owning the work, understanding the work, pitching the work, and getting to production stands. Ownership is the mental model: understanding how the code works and why. You don't want to get too far down this road without the understanding part as it gets harder to pull yourself out.

"Read every line" may be right for a 200 line pull request. For a 4,000 line scaffold an agent wrote in fifteen minutes, nobody does this. I preach that, for much of our work, you don't need to model the codebase perfectly in your head; you mostly just need a usable abstract mental model. For an ETL, that model is the data flow; for a web app, it’s the reads and transforms. But for database schema or ML work, we dig a little deeper.

How deep you go depends on how loudly the thing fails. A web app usually breaks loudly and you fix it that afternoon. A database schema with a misplaced ON DELETE CASCADE breaks quietly, and that's where you're picking up the pieces two months down the line. It's up to you to determine what needs a perfect mental model and where you can skip understanding every edge case of that chart label formatter you custom wrote for some reason.

Build on what you already know

We've gotten a lot of mileage out of older apps that we wrote before Claude Code could reliably build anything. Miles of tidymodels, targets, Shiny applications, and fastapi code. These are goldmines for our developers, not just because instructing Claude Code to copy them today results in more resilient codebases but because it results in developers not having to rebuild their own mental models of the app.

For example, most of our Shiny apps follow the same shape:

• An R package directory layout

• Shiny modules, roughly one per screen

• A data module that owns local data and caching

• R6 service classes for anything outside the app (especially Postgres interactions)

New apps can reuse these building blocks, which makes the generated code easier to review. The package layout, module boundaries, and service layer are already familiar. The new feature is the unfamiliar part, rather than the entire application.

Help yourself out

A few things we've landed on to manage owning the code.

Don't hand off your EDA. The primary output of exploratory analysis is the analyst’s mental model. The plots and tables are how you build and challenge it. An agent will produce every histogram and summary table you could want in about a minute, and you'll end up holding the artifacts without the knowledge behind them.

Be careful with unsupervised ML. Supervised work at least gives us an external check on predictive performance. A holdout set will not catch every bad assumption, but it can, ostensibly, show when the pipeline fails to generalize. Clustering and dimensionality reduction have no such thing. If the code runs, the output often looks plausible but your statistics experience is needed to critique the results. It's the same reason we're comfortable letting an agent move fast on a tidymodels pipeline and much less so on a segmentation analysis.

Own the contracts. Design your data contracts and the API between the frontend and the backend yourself, then let the agent fill in the implementation. Interfaces are where the failures compound, and they're cheap to think about up front and expensive to change once things are built on top of them.

Sandbox your schemas and ETLs. We've found agents surprisingly bad at designing real-world database schemas. Do the dozen or so deep-dive whiteboarding sessions with your colleagues and clients – refine your mental model and then sandbox the resulting schema. Build a simplified version you fully understand and prove it out. A schema you can't defend is expensive.

Know when to skip the tool. It was tempting to have an LLM write this post from scratch. Delegating that step here would have recreated the problem the article is describing. Think deeply at the start of a project where your time is most valuable and where an agent should or shouldn’t assist.

Lander Analytics can help

Not all code deserves the same level of review. For a scraper you will delete on Friday or a CLI tool only you will use, the blast radius is smaller and the feedback loop is short. You can accept less understanding because the work is reversible and no one else has to maintain it. A schema migration, shared data pipeline, or model that informs a client decision deserves a different standard.

For these bigger projects, we help teams set up the architectures and review practices that make agentic development something you can stand behind. That includes the platform layer: templated repos with automated review, test generation, secret scanning, and package inventory already switched on (Agentic DLC Start Kit). Reach out at info@landeranalytics.com.

Joe Marlo

Director of Data Science

Lander Analytics

---

Subscribe to our Substack and below to our monthly emails for practical AI strategies for your organization: what to build, what to avoid, and how to make systems reliable in the real world.

Work with us: If you want help identifying the right first workflow, building a permissioned knowledge base, or training your team to ship responsibly, reach out at info@landeranalytics.com. 

About the author: Joe Marlo is Director of Data Science at Lander Analytics, where he designs agentic workflows, statistical models, and interactive frontends that put rigorous analysis into production.