Spoiler Alert: It depends…
WARNING: This is only the result of my personal testing. It is not a scientific approach. It is just the perception of a developer with several years of experience.
As an IT Architect
Good for:
- Learning and quickly exploring new technical ideas.
- Exploring technical concepts.
- Seeing sample code and connecting the dots.
- Good for prototyping and validating a concept.
- Diagrams:
- C4 or Mermaid diagram generation. Force yourself to write the full prompt and let the CLI generate the formatting or adjust the colours.
- Code exploration. Quick speleology in the code. A very quick overview of the current concepts, as long as the code is properly named.
As a Software Developer
Pros:
- All of the above.
- Sample code. I rarely use StackOverflow or Baeldung these days. Good to learn a framework.
- For all major refactoring projects when you have exhausted all the possibilities of your IDE and you need to tackle a bit more complex task, as long as you have good existing code coverage.
- Good for boilerplate code generation.
- Good for documentation. Generate the documentation, read it, and make sure you make the generated code your own.
Cons:
- You need to constantly watch and adjust the generated code. The code gets produced in short bursts, so you need to put all your attention on it.
- It is still a very slow process. You suddenly get a lot of generated code, but you might need to wait for a long time. It is as long as a BEA WebLogic build for those old enough to remember.
- It is almost like there is an incentive for code repetition. More code output = more token output = more money spent.
- Be ready to feed the tool with more sample code. The tool, like every LLM, is always a step behind. Feed it with more recent code samples.
- Sometimes you really need a lot of iterations to achieve very little, as the generated code is not always systematically compiled or tested, and you feel you are in an infinite loop and you would probably be done if you did it on your side.
Conclusion
If you are a young developer, it is a powerful tool to learn. The only problem is the generated code is often full of code smells.
There isn’t one single, universally-agreed-upon, formal definition of a code smell. You only know and remember when you get bitten once your code is in production or when working long enough on adding features to a brownfield project.
If you consider all the pros above, it can become a very powerful tool, provided you know exactly what you want. It reminds me of the time when pair programming became popular. The only difference is the CLI always tries to please you. Even if you ask it to, you will never be as challenged as when working with your peer.
You can definitely ‘vibe-code’ a small application if you have a lot of time and a lot of money to spend, but it will never be your code or app. Good to perform a demo or demonstrate a concept, but it will never be production-ready code. You can be sure most of the corner cse scenarios have been forgotten.
My personal advice is to work with small iterations and to force your code to be production-ready after each iteration.
Possible Strategy
- Use a TDD approach to understand the requirements, write your tests, generate the code, verify it passes your tests, refactor the code with your favourite IDEA, rinse, and repeat.
Security
- Consider the produced code not secure by default, the same way a lot of code on the internet is not always secure (no validation of the inputs, etc.).
- Like all LLMs, the time stopped the moment the model was created. Older versions of frameworks get pulled out.
General Approach
Baby steps, only baby steps. Challenge every possible modification. Ask for a plan and validate the plan. Watch out carefully during the execution and commit.
Tips
- I highly recommend Claude Code in Action training: https://anthropic.skilljar.com/claude-code-in-action
- For code cleanup, specify your Python script. The CLI might use this approach, but it does not always happen. I need to explore: the usage of the CLI to generate Open Rewrite commands.
- When you feel you have achieved enough, ask the CLI to review the code as a Senior Software Engineer. Read carefully and commit when you agree with your own definition of good enough.
Claude code on the web
- Not convinced yet, or I have missed some of its capabilities.