AirBnb just did a 1.5 year engineering migration in 6 weeks thanks to AI.
"Vibe" coding is here to stay and it's only devs who don't know how to adapt that are wishfully hoping for otherwise.
"Vibe" coding is here to stay and it's only devs who don't know how to adapt that are wishfully hoping for otherwise.
You might not be good at estimating, but professional software teams at the most successful tech companies in the world generally are.
If you read the blog post, they were able to manually migrate 3% of the tests in 1 week. Extrapolating that gives you an estimate of less than half of the 1.5 year estimate.
I’d also say there’s a pretty good chance that the 3% of tests the automated process couldn’t handle were more complicated than average and the devs would have gotten faster at doing these migrations after the first week.
It’s very unclear what was actually being compared. A team did a POC in 2023 and then some work in 2024 and then spent 6 weeks tweaking the pipeline and a final week manually migrating the tests that the automated process couldn’t handle.
But they don’t specify how many people worked on this or how many people were going to work on the original project. It could have been 1 guy on the team.
As for looking at what the actual work was, it was migrating from one test framework to another one. I’d be surprised if a team couldn’t have written a compiler to do something similar in a similar amount of time.
Color me unimpressed - it converted some test files. It didn't design any architecture, create any databases, handle any security concerns or any of the other things programmers have to do/worry about on a daily basis. It basically did source to source translation, which has been around for 30+ years.
and we don't know what is the quality of end code, it is possible that tech debt created by migration is well higher than 1.5 eng/y.
I’ve done something similar to this type of work with an llm. It produces code that is often too idiomatic, in that it introduces conventional approaches that are overkill for the task at hand. But this is almost an ideal scenario, because if the previous tests run clean, the newly converted tests can only fail by being wrong.
They can also silently reduce the tested scenarios, but that’s what code reviews are for.
> They can also silently reduce the tested scenarios, but that’s what code reviews are for.
code review of complicated scenarios is about as resource demanding as actually writing code, so shrinking time spent from 1.5y to 6 weeks totally can produce lower quality.
Seriously, the wishful thinking around this stuff is embarassing.
But given your comment history, backing up your arguments doesn't seem to be your strong suit...
I doubt that error free code is outnumbering code with errors in the training data.
1. Nobody cares. It's still worth the insane productivity improvements.
2. There is no proof that it's going to lead to long-term issues, because why would it?