1. Wait, in a category where the general failure rate is traditionally 75%, using a bleeding edge technology adds 20% more risk, what a shock.
2. This is an interesting study, but perhaps limited. Draws conclusions from a set of 16 developers on very large projects, many of whom did not have previous experience with the editor used in the study or LLMs in general. The study did conclude it added time in these cases. There is a reason for the large sense of value, this would be the thing of note to uncover based on these results. Study notes 79% continued to use the AI tools. Speed is not the only value to be gained, but it was the only value measured. (Study notes this.)
3. Author didn't read or used AI to poorly summarize the poorly thought out study it is based on. Also, it seems you didn't read the study.
This article was probably written by AI, because anyone with half a brain could not read the study and come to the same conclusions.
Basically, participants spent less than half an hour, 4 times, over 4 months, writing some bullcrap SAT type essay. Some participants used AI.
So to accept the premise of the article, using an AI tool once a month for 20 minutes caused noticeable brain rot. It is silly on its face.
What the study actually showed, people don't have an investment or strong memory to output they didn't produce. Again, this is a BS essay written (mostly by undergrads) in 20 minutes, so not likely to be deep in any capacity. So to extrapolate, if you have a task that requires you to understand the output, you are less likely to have a grasp of it if you didn't help produce the output.
This would also be true of work some other person did.
MojoTech | Boulder, CO; Providence, RI | Full Time Onsite
We're a software product consulting company founded by and for engineers that utilizes various technologies across the whole stack. JS/Elixir/Ruby
I've been pretty happy leaving an enterprise environment to work at thoughtful, well run company with a strong engineering culture. Feel free to reach out with any questions.
https://www.mojotech.com/jobs/
Even if it lasts for 5 years, that is still a long time to maintain and so the advice in the book is solid. As a business, you may want or need it to last longer.
I've not seen this 'common' knowledge in the field enough to call it common.
While there can be a strategic value to just getting something working, the tough part is that many times that is used as a crutch to do no more thinking or design, quite possibly because they've never been called to. And refactors happen less than they ought to. The point is to be strategic about when to turn the quality/speed dial towards speed and know you are consciously taking on tech debt.
This was a fantastic book. It is definitely not for undergrads, or just undergrads. I think it even more important for people actually working on production systems. Even better, it provides some language for people to share when doing code review about how to design their APIs better.
The irony that he cites Harvard Physics is the vanguard of rethinking how to teach Physics, and possibly the root of this article come from Harvard Physicist Eric Mazur: https://www.youtube.com/watch?v=LIFL0K184kg
