Being responsible for a system requires understanding it well enough to make effective decisions about the system and its evolution.

Code review has traditionally served as an important part of maintaining an understanding of the systems we're responsible for. But this practice, as we've known it, seems to be going away.

What other mechanisms exist for building and maintaining system understanding?

Observability

Observing a system in production is arguably one of the best ways to understand how it behaves. Reading the code is one thing, but seeing what actually happens when it runs in its interconnected context can be much more insightful.

But it requires being intentional about instrumenting the system, which itself requires some understanding of how it's built and how it operates.

Going through the process of establishing telemetry starts with knowing what questions you need to answer about your system in production.

That process alone kickstarts a cycle of curiosity that will build on itself over time. Ask questions, instrument, observe, repeat.

Follow the changelog

Pay attention to the PRs happening in the system, read their descriptions, understand the motivations behind the changes and why the particular approach was chosen.

In general, read the code! Maybe not at PR time, maybe not line by line. But keep your ability to navigate the codebase sharp. Be able to make sense of it, and answer questions about it.

Talk about it

Spend time with your team discussing the system, asking questions about it, reviewing the changes that have happened and understanding their impact.

Discuss plans for changing the system. Invest in the plans and specifications for upcoming features and necessary refactors. Think about what in the system's current design and architecture may make those changes easy or difficult.

Solo engineer? Talk about it with an LLM! AI is great for much more than just work delegation. Use it as a tool for thought. Explore patterns, understand tradeoffs, don't just take what they give you and move on.

Above all, be curious

This is the quality that underpins everything else. Ask yourself how certain features work, or why things were implemented in a given way, or where the module boundaries live and what the interfaces are.

Then follow that curiosity to find answers. Use an LLM to help, but don't just take it at face value. Go look at the details, confirm its findings, and ask follow-up questions.

Don't let go of your desire to understand. It's one of the most valuable assets of a good engineer. There will always be competing pressures, don't let them get in the way of retaining your understanding.

The job is about responsibility

As AI changes how work gets done, make sure you don't lose the practice of building and maintaining that understanding. Be intentional and carve out time for it, both for yourself and for your team.

Our job as engineers is to be responsible for the creation, evolution, and operation of the systems within our scope. Meeting that responsibility requires a quality understanding. Take time to nurture it, and stay curious!