It's so tempting to write a feature description into Claude on agent mode, hit go and watch from the sidelines.. When I create a new feature in a product, I can feel myself want to slip into this easy mode of doing things to just let the robots do all the work for me.
It looks something like this: I describe my feature or pasting a user story into Claude and telling it to build me this feature. After the feature development is complete, I tell it to make some tests. If all the tests pass, create a PR. Then push to source control and automatically merge into the trunk branch. When that's complete the system kicks off the CI pipeline and the ticket is closed.
After all this is done, I have no real idea of what we just did. I don't like not knowing exactly what was coded, tested and pushed. I've become a meat proxy and that's exaclty what I want to avoid.
Therefore, I remain the human in the loop when building software with AI. I can easily lose track of what my systems do or what we're trying to say if we continue to just hit accept on whatever AI outputs for us. If I review the AI output that puts me in a place to understand what is being produced and to catch issues that AI might have created.
By not automatically accepting the code that's changed, I've caught multiple changes where key features were deleted from source when they shouldn't have been. I've de-Clauded my PRs, READMEs and DevOps tickets so they can be more easily understood by the other humans on my team.
By simply doing my own code reviews or PRs, I've been able to double-check the work to verify what's being developed is accurate so I understand what is going into production. If I were not able to catch the issues that AI has introduced, it could lead to a host of problems and I'd be held responsible.
AI can easily replace the mental model of the software systems we are paid to understand. I can't make architectural or systems decisions if I don't know how the system works.
Some other things we lose by becoming a meat proxy: 1. Understanding of code and what it does. 2. Domain expertise. With each ticket or feature that's created where I don't fully understand the function, I veer just a little further away from fully grasping the subject. Over time I can veer so far off I have no clue what our systems do.
Reviewing the AI outputs (content or code) requires a significant effort on our part. That effort makes it so tempting to just hit accept and trust that the robots are correct 100% of the time.
To not accept what AI gives us without fully understanding the solution costs us time and energy, the very thing AI is promised to save us. That's ironic, but true at the same time. I gain time by offloading coding and other manual tasks, but lose time because I can't trust AI output to go to production without me verifying what it's created. I think this is a fair trade-off. The effort is worth it to keep our minds sharp and our systems in check.
We shouldn't view AI as a complete engineer or a replacement for one. It is a wonderful tool that lets engineers get coding done and shipped faster. The trade-off for now is that we must all be software architects to verify what's being pushed to production.