When I blogged about the challenges and opportunities of AI assisted coding, there were a fair number of questions about details of our experience. I know many are eager to learn more, and we can’t wait to share details of what we are building in a few weeks at re:Invent. However, among the questions, there was one that caught my attention:

Looking at the git activity heatmap, you started coding on the weekends. Why the sudden change?

I wanted to dig into that question, because in many ways the answer captures how AI assisted coding has changed my approach.

For starters, I recommend folks find their own personal balance, and working on the weekends is generally not a great idea. Personally, I really love what I do and have always been energized by finding opportunities to write code, even as time became hard to find at the more senior levels. To that end, I’d often carve off an hour or two to write code on the weekends, if not for work then for personal projects. But that time was often insufficient - an hour isn’t enough to get into flow, page in context, make meaningful progress, and wrap up cleanly.

However, the biggest factor is that agentic coding has changed my approach to writing code in a fundamental way. Coding has always been a synchronous activity for me. I’d start working on a change or a feature, make some progress, gain new insights that would cause me to alter my approach, and keep iterating. When finished, tests wouldn’t always pass on the first try, so I’d spend some time debugging and fixing problems.

Over the past 7 years, I’ve also been primarily developing in Rust. Rust is famous for prioritizing correctness, and that’s what I like about it. The compiler will let you know if your code is potentially incorrect, which is great when trying to build robust software. However, that tends to add time into the implementation phase, as you work through the issues flagged by the compiler (the upside being that catching these issues at compile time beats catching them in production). Lastly, as I’ve grown more senior, finding continuous “focus” time has been a challenge too. Working on a coding task would often span multiple meetings, each time requiring me to page-in all the context again.

My coding flow would typically look something like this:

With agentic coding, my flow has changed in a fundamental way. Instead of synchronous flow of continuous attention, I usually spend five minutes breaking down the problem and getting to a place of “shared understanding” with the agent on how to tackle the task (that in itself is an interesting topic!). I then give the AI agent green light and disengage. I’ll admit, for the first few months I stayed glued to my screen, watching the agent work through each implementation. That initial hand-holding helped me build intuitions for structuring requests in ways that help the agent succeed. These days though, I genuinely step away.

The agent then gets to work to implement my request, run the build (sparring with the Rust compiler instead of me!), run the unit and the integration tests, and iterate a few times until it believes it has succeeded. Within our project, that can take anywhere from 15 to 30 minutes. Once done, I review the code produced by the agent, and decide if it meets my bar. This review is a critical step, because I need to verify not only correctness and implementation choices, but also that the agent interpreted my request correctly within the broader context. Occasionally, I may decide that my request was too ambiguous or ambitious, so I would throw away the results and try again with a narrower request. Most of the time, I give the agent feedback, point out issues or parts that could be improved and let it go another round. In the end, my coding flow now looks more like this:

The net result is that my coding style switched from synchronous to asynchronous, with only needing to spend focused attention a few times throughout the implementation of the change. At work, these “idle” times is when I do all the other things a senior IC would typically do. On the weekends, the asynchronous approach allows me to do something I enjoy, without needing to block continuous time or step away from my other commitments.