There’s an anecdote that comes up in software about people working on missile software not caring about memory leaks because it’s going to explode anyway before that becomes an issue.
Who cares about bugs in your software if it’s a hobby project that’s going to blow up anyway.
Also, including Claude doesn’t inherently mean vibe coded, it can be for writing tests, small components, or debugging.
Tests should be written from requirements. Using LLMs to write tests after the code is written (probably also by LLMs) is a huge anti-pattern:
The model looks at what the code is doing and writes tests that pass (or fail because they bungle the setup). What the model does not do, is understand what the code needs to do and write tests that ensure that functionality is present and correct.
Tests are the thing that should get the most human investment because they anchor the project to its real-world requirements. You will have tons more confidence in your vibe coded appslop if you at least thought through the test cases and built those out first. Then, whatever the shortcomings of the AI codebase, if the tests pass you can know it is doing something right.
Honestly, never been on a team that stuck to TDD. As you test your stuff, and understand whatever libraries and apis you’re calling you modify your implementation as you go.
For public facing methods, especially ones called by customers, having pre agreed upon tests matter more but usually that’s at the integration test and system test level. I usually use AI for unit testing and read what was written. Tests end up being a lot of writing harnesses and setting up mocks that you delegate to the model and if there’s gaps or incorrect requirements, you change them.
I would never let the agent define the code structure. It doesn’t understand business processes or what might need to be extended or we’re instead about.
I’ve been doing software for a while, I know how to review code. I don’t vibe code, I let the model implement boilerplate and mapping functions while I do other stuff, like manual testing or talking with product. If done correctly, you can incorporate generative models into your workflows without fully handing over all control.
I disagree about better code. Claude has been pretty bad at understanding external context and deriving why you’re doing something from the implementation. This can result in wonky structure that you need to fix, or at the very least tell Claude to redo over and over untill it looks clean and organized.
No matter how mad this makes people, its still true.
What makes the code actually useful in most cases however, is enough understanding of the program to modify as its needed. That’s where LLMs fall flat. Even when the code works, its terrible at adjusting the code to fit a specific use case. Dont even get met started on usable documentation or maintenance.
There’s nothing inherent to small components to suggest that you have to review them. If they’re small, it’s easier to tell yourself that the LLM probably got them right and you’re justified in not checking.
Bro, if I don’t have to sit there for a half hour banging out code to map structure A on to structure B, I won’t. I’ll let someone else write it and spend 5 minutes to check that the code is clean and it works
There’s an anecdote that comes up in software about people working on missile software not caring about memory leaks because it’s going to explode anyway before that becomes an issue.
Who cares about bugs in your software if it’s a hobby project that’s going to blow up anyway.
Also, including Claude doesn’t inherently mean vibe coded, it can be for writing tests, small components, or debugging.
Tests should be written from requirements. Using LLMs to write tests after the code is written (probably also by LLMs) is a huge anti-pattern:
The model looks at what the code is doing and writes tests that pass (or fail because they bungle the setup). What the model does not do, is understand what the code needs to do and write tests that ensure that functionality is present and correct.
Tests are the thing that should get the most human investment because they anchor the project to its real-world requirements. You will have tons more confidence in your vibe coded appslop if you at least thought through the test cases and built those out first. Then, whatever the shortcomings of the AI codebase, if the tests pass you can know it is doing something right.
Honestly, never been on a team that stuck to TDD. As you test your stuff, and understand whatever libraries and apis you’re calling you modify your implementation as you go.
For public facing methods, especially ones called by customers, having pre agreed upon tests matter more but usually that’s at the integration test and system test level. I usually use AI for unit testing and read what was written. Tests end up being a lot of writing harnesses and setting up mocks that you delegate to the model and if there’s gaps or incorrect requirements, you change them.
I would never let the agent define the code structure. It doesn’t understand business processes or what might need to be extended or we’re instead about.
I’ve been doing software for a while, I know how to review code. I don’t vibe code, I let the model implement boilerplate and mapping functions while I do other stuff, like manual testing or talking with product. If done correctly, you can incorporate generative models into your workflows without fully handing over all control.
Claude writes better code than most humans and a lot faster
I disagree about better code. Claude has been pretty bad at understanding external context and deriving why you’re doing something from the implementation. This can result in wonky structure that you need to fix, or at the very least tell Claude to redo over and over untill it looks clean and organized.
No matter how mad this makes people, its still true.
What makes the code actually useful in most cases however, is enough understanding of the program to modify as its needed. That’s where LLMs fall flat. Even when the code works, its terrible at adjusting the code to fit a specific use case. Dont even get met started on usable documentation or maintenance.
Using an LLM to write tests and small components is still vibe coding.
Vibe coding is you not reviewing what the model outputs. I read every line, often give feedback and tell the model about patterns I want to use.
I probably write like 60-70% of the code myself.
Wikipedia says:
If you are using LLMs to write e.g. small components, then you are typically understanding the structure of the program, and reviewing it.
There’s nothing inherent to small components to suggest that you have to review them. If they’re small, it’s easier to tell yourself that the LLM probably got them right and you’re justified in not checking.
Bro, if I don’t have to sit there for a half hour banging out code to map structure A on to structure B, I won’t. I’ll let someone else write it and spend 5 minutes to check that the code is clean and it works
Listen to me. I do code for a living. Nobody want to write HTML