“No Duh,” say senior developers everywhere.
The article explains that vibe code often is close, but not quite, functional, requiring developers to go in and find where the problems are - resulting in a net slowdown of development rather than productivity gains.
Even though this shit was apparent from day fucking 1, at least the Tech Billionaires were able to cause mass layoffs, destroy an entire generation of new programmers’ careers, introduce an endless amount of tech debt and security vulnerabilities, all while grifting investors/businesses and making billions off of all of it.
Sad excuses for sacks of shit, all of them.
Look on the bright side, in a couple of years they will come crawling back to us, desperate for new things to be built so their profit machines keep profiting.
Current ML techniques literally cannot replace developers for anything but the most rudimentary of tasks.
I wish we had true apprenticeships out there for development and other tech roles.
“No Duh,” say senior developers everywhere.
I’m so glad this was your first line in the post
No duh, says a layman who never wrote code in his life.
Oddly enough, my grasp of coding is probably the same as the guy in the middle but I still know that LLM generated code is garbage.
Yeah, I actually considered putting the same text on all 3, but we gotta put the idiots that think it’s great somewhere! Maybe I should have put it with the dumbest guy instead.
I guess I’m one of the idiots then, but what do I know. I’ve only been coding since the 90s
I’d be inclined to try using it if it was smart enough to write my unit tests properly, but it’s great at double inserting the same mock and have 0 working unit tests.
I might try using it to generate some javadoc though… then when my org inevitably starts polling how much ai I use I won’t be in the gutter lol
I personally think unit tests are the worst application of AI. Tests are there to ensure the code is correct, so ideally the dev would write the tests to verify that the AI-generated code is correct.
I personally don’t use AI to write code, since writing code is the easiest and quickest part of my job. I instead use it to generate examples of using a new library, give me comparisons of different options, etc, and then I write the code after that. Basically, I use it as a replacement for a search engine/blog posts.
Ideally, there are requirements before anything, and some TDD types argue that the tests should come before the code as well.
Ideally, the customer is well represented during requirements development - ideally, not by the code developer.
Ideally, the code developer is not the same person that develops the unit tests.
Ideally, someone other than the test developer reviews the tests to assure that the tests do in-fact provide requirements coverage.
Ideally, the modules that come together to make the system function have similarly tight requirements and unit-tests and reviews, and the whole thing runs CI/CD to notify developers of any regressions/bugs within minutes of code check in.
In reality, some portion of that process (often, most of it) is short-cut for one or many reasons. Replacing the missing bits with AI is better than not having them at all.
Ideally, the code developer is not the same person that develops the unit tests.
Why? The developer is exactly the person I want writing the tests.
There should also be integration tests written by a separate QA, but unit tests should 100% be the responsibility of the dev making the change.
Replacing the missing bits with AI is better than not having them at all.
I disagree. A bad test is worse than no test, because it gives you a false sense of security. I can identify missing tests with coverage reports, I can’t easily identify bad tests. If I’m working in a codebase with poor coverage, I’ll be extra careful to check for any downstream impacts of my change because I know the test suite won’t help me. If I’m working in a codebase with poor tests but high coverage, I may assume a test pass indicates that I didn’t break anything else.
If a company is going to rely heavily on AI for codegen, I’d expect tests to be manually written and have very high test coverage.
Why? The developer is exactly the person I want writing the tests.
It’s better if it’s a different developer, so they don’t know the nuances of your implementation and test functionality only, avoids some mistakes. You’re correct on all the other points.
I really disagree here. If someone else is writing your unit tests, that means one of the following is true:
- the tests are written after the code is merged - there will be gaps, and the second dev will be lazy in writing those tests
- the tests are written before the code is worked on (TDD) - everything would take twice as long because each dev essentially needs to write the code again, and there’s no way you’re going to consistently cover everything the first time
Devs should write their tests, and reviewers should ensure the tests do a good job covering the logic. At the end of the day, the dev is responsible for the correctness of their code, so this makes the most sense to me.
the tests are written after the code is merged - there will be gaps, and the second dev will be lazy in writing those tests
I don’t really see how this follows. Why do the second one necessary have to be lazy, and what stops the first one from being lazy as well.
The reason I like it to be different people is so there are two sets of eyes looking at the same problem without the need for doing a job twice. If you miss something while implementing, it’s easier for you to miss it during test writing. It’s very hard to switch to testing the concept and not the specific implementation, but if you weren’t the one implementing it, you’re not “married” to the code and it’s easier for you to spot the gaps.Devs are more invested in code they wrote themselves. When I’m writing tests for something I didn’t write, I’m less personally invested in it. Looking at PRs by other devs when we do pushes for improving coverage, I’m not alone here. That’s just human psychology, you care more about things you built than things you didn’t.
I think testing should be an integral part of the dev process. I don’t think any code should be merged until there are tests proving its correctness. Having someone else write the tests encourages handing tests to jr devs since they’re “lower priority.”
