If You Push It You Own It

Ownership in an Agentic World

Agentic coding assistants increase the risks of engineers pushing chaotic mismatched and poorly-designed changes. That long slow process of reasoning about a change, implementing that change, writing tests for that change, manually testing that change forced you to develop a complete mental model about the change before pushing it.

Agentic assistants can dramatically reduce this timeline and allow you to skip some of these steps making it a lot easier to push a change you don't understand.

Ownership:

More than ever you need to be constantly thinking about how your change fits into the cohesive whole. The current codebase, but also the greater constellation of tools that are deployed around this one. Architectural thinking has to be elevated because the speed that architecture can drift has increased. Everyone doesn't need to become a product engineer, but we all need to have a deeper understanding of the business goals and how our change contributes positively or negatively. If English is the next great programming language, we all need to get better at reading writing understanding and speaking it.

Work with the agent to break up your change into smaller chunks that you can easily understand. Get those smaller changes pushed and reviewed separately. Putting your name on the change and submitting it to version control tells your peers you personally have vetted the change. Did you type every line yourself? That question matters less than your confidence in the quality of the change. If you did use a tool to generate the change (or copied from Stack Overflow) you are still staking your personal reputation on the work. You trusting this tool definitely doesn't mean your peers would extend that same trust. Make sure you are prepared to defend every line of the change. As an individual contributor your reputation is currency in an engineering organization. Submit enough broken or half-baked changes and reviews will start coming more slowly, offers of help will become less frequent. If you stay diligent and honest about your contributions, and do your fair share of reviewing others changes you'll have plenty of reputation in reserve for when you (or your agentic assistant) inevitably pushes a bad change.

How do we build context if you didn't build it up while writing the code?

Pairing:

You now have an always-on pair programming companion that is infinitely patient. Don't hesitate to hammer them with questions, dive into a single line and have it explained 10 different ways. Ask your LLM to explain how dependency injection is used in the codebase using Star Wars metaphors. Ask it to explain the change using language a 10 year old would understand if you are tired and needing a mental break.

Refactoring just got a whole lot cheaper. If you don't like the initial implementation, tell the agent to start over. If both of you need a jolt of creativity, jump out of your agentic IDE and ask LLM chat to generate three competing designs with an explanation of the tradeoffs in each design. Ask a different LLM what it thinks about your current change and how it would implement it differently.

Context:

More recent models can hold a very large codebase in their context window. Modern agentic IDEs combine sophisticated RAG techniques to keep the current codebase, recent changes, and open files in the context window. This represents powerful information that may have taken you years of working in the same codebase to easily match on your own. Take advantage of this new source of information by constantly querying it. Ask questions like: "Where was the library that implemented AWS authentication?" Just as the value of typing out long swaths of code from memory has diminished, so has the value of holding all this context in your own short-term memory. Getting really good at querying a codebase means you can quickly refresh your own memory when getting back to a change. You can work in many different codebases in a single day without huge switching cost or quickly jump into a brand new codebase with confidence. Everyone knows that feeling of coming back to a change after a couple days of meetings or a long weekend pulled you away, what if that painful timeline for catching up your brain could be dramatically reduced?

README:

Your project's README just became a critical English-language resource for both your project's users and contributors but also for the agent to use as a central source of context. Make clear your projects goals, its intended usage, how it is tested, how it is compiled, and encourage your agentic partner to prolifically contribute to this documentation well. The cost of maintaining good documentation just dramatically decreased.

Rules:

Floating a level above READMEs are rules files directly targeting your agentic partner. Tired of the agent suggesting a library you don't ever want it to use? Tell it to never suggest it again. Seeing changes that don't match your particular style preferences? Make that style explicit. There are no strict formats, although some loose standards are starting to be developed. Resources on prompt-engineering might help inspire you how to "speak to the LLM" but as these models become more sophisticated, clear succinct English language instructions are usually good enough. Tell your assistant to always include new tests and remember to update the README when it adds new functionality or changes existing functionality.

Tests:

Your new assistant is also infinitely patient when writing tests. If your codebase doesn't already have tests now is a great time to add them. If you have decent test coverage ask your assistant for ways for it be improved. Tests need continuous maintenance and its easy to fall into the trap of assuming that existing tests represent some previous perfect state of the application, don't hesitate to work with your agentic partner to refactor and redesign tests that aren't clear or straightforward.

Continuous Integration:

Any vetting or validation that can happen automatically saves human reviewers time, and saves you the potential embarrassment or burning some of your reputation capital. If there are tools that already run in your CI pipeline make sure you also run them locally. Linting, vetting, and static analyzing are cheap compared to LLM calls and their output is easily fed back to the agent

Conclusion

These tools don't inevitably mean you are giving up direct control or understanding of your changes. Agentic IDEs are extremely malleable to opinions and advice. You absolutely can rely on your own opinions and experience and enforce quality with every change. Work slowly and deliberately ensuring you are confident and understand the implications of your suggested change. Keep the size of each change small for the benefit of your own brain's context window as well as your reviewers.

The type of person that was going to put minimal effort into a change and push it expecting others to find bugs may abuse these tools, but lets not kid ourselves, you were never going to see great work from them anyway. Be diligent, be curious, and use these new tools to elevate the quality of your work.