Like many other engineers in the field I have started using Claude Code to be more familiar with the tech and to keep up with the trends. I have used Claude Code in several personal projects at this point. The more I used Claude Code, the more I noticed that both my ability to write code by hand started to get rusty. Throughout my time working in those projects I have noticed that it became difficult to keep up with understanding of the entire project and the codebase, since I didn’t write it. And because I have not been writing code while using Claude Code, I started to forget even the basic statements and structures of the language that I was using.
Making Claude write all of the code leaves developers in a code reviewer seat. And to review code one needs to know how to code well in the first place. If I do not practice writing code, I start to lose the ability to evaluate the code well. This fact is further fueled by the desire to trust that the model knows how to code better than I do since it seems so “intelligent”. And I believe that this is a dangerous path, which could lead a lot of software engineers into becoming “LLM babysitters” instead of experts in the domain of building efficient applications accomplishing niche business needs.
It is very easy to embrace that AI will give you a solution at the click of a “Submit” button after you provided the prompt. The feeling of convenience and ease slowly creep in and lull you into a feeling that you are still “engineering”. But as time goes on, we see more and more examples of AI being ok at prototyping and “one-shotting” features, but not precise engineering. Engineering is a science. Prompting is an ever-evolving “art form”, which rarely yields the precisely expected result. At best the results could be described as “good enough”.
On the positive side of working with Claude, I noticed that instructing Claude Code made me better at instructing and managing devs on my team. I felt as if I became more direct with my requests, especially when doing code reviews. It made me realize that I should approach managing my team with the same sense of ownership as I would my projects made with Claude. If I know what is good for the product, I can ask my team to implement it in the way that I best understand. I should provide as much context for the requests as possible to get the results that I expect. And I should talk about the code with my developers who work on different specific areas and know it well if I need more input on some decision making. I do the same things with Claude: I manage it, I provide context, I ask it questions about the code.
Working with a team of devs is a lot more fulfilling and engaging than managing an AI agent. At the core of working with the developers lies the relational aspect. When I work with my team, I develop meaningful relationships with them that fuel our work. It is a place where professionalism and expertise meet with collaboration, passion, and care. My teammates care about the product and have a deep domain context and experience that is specific to the problem, and not generic. They provide meaningful feedback to implementation plans, and help with my blind spots - much better than any current LLM ever would - even Fable. They understand not only the local code context, but also a broader business and product context that is the impetus for all of the changes to the application in the first place. They are constantly on a lookout for improvement opportunities. And the care for their craft, the results that we deliver, the challenges that we overcome, and the victories that we achieve - all of that makes for fulfilling and purpose-driven work that no LLM will be able to simulate.
Working with Claude could be fun when you get near instant results and feedback. Working with a team of dedicated to their craft developers leads to much better results for the product that we are working on, for the team cohesion and chemistry, and for a deeper understanding of the end product. I’ll take my team over AI any day of the week.