281–284 of 284 posts
The bar to beat is time it takes for human intelligence + Cursor Tab to complete a task, but in practice the bar becomes "feeling" like its faster
One thing I find frustrating with these conversations is the _strict_ focus on single-task productivity. Arguably, on a single coding task, I don't really move that much faster. However, I have much, much more brain capacity left both while coding and when I'm done coding. This has two knock on effects: 1. Most simply, I'm productive for longer. Since LLMs are doing a lot of the heavy lifting, my brain doesn't have t…
> I can do other things while coding Context shifting while trying to code seems like a bad idea to me Maybe you're some incredible multi -tasking genius able to change tasks rapidly without losing any of the details, but I suspect if most people tried this workflow they would produce worse code and also whatever their other output is would be low quality too
This type of stuff is great to have an LLM tackle while I work on something else.
> To compute the actual speedup – or, rather, slowdown! – provided by AI tools, the researchers compared the developers’ predictions of how long each task would take to the measured completion time. I'm sorry, but it feels to me like this research has only proven that developers tend to underestimate how long a task is supposed to take, with or without AI. In no way did they actually measure how much faster a specifi…
What I understand they did is. You have two tasks: - Task 1 - 3h - Task 2 - 1h You ask the dev to estimate both. Then you randomly tell the dev, ok do Task 1 without AI, and Task 2 with AI. Then you measure the actual time it took. Their estimate for AI task missed the mark by 19%, but those without AI were done 20% faster then estimated. At the time of estimating they didn't know if the task would need to be done wi…
Earlier quoted context omitted.
Not the OP, but: https://repo.autonoma.ca/notanexus.git I don't know the PDF.js library. Writing both the client- and server-side for a PDF annotation editor would have taken 60 hours, maybe more. Instead, a combination Copilot, DeepSeek, Claude, and Gemini yielded a working prototype in under 6 hours: https://repo.autonoma.ca/notanexus.git/tree/HEAD/src/js I wrote maybe 3 lines of JavaScript, the rest was all prompt…
> Writing both the client- and server-side for a PDF annotation editor would have taken 60 hours, maybe more. How do you know? Seems to me you’re making the exact same estimation mistake of the people in the study. > Instead, a combination Copilot, DeepSeek, Claude, and Gemini yielded a working prototype in under 6 hours Six hours for a prototype using four LLMs? That is not impressive, it sounds insane and a tremend…
I have over 20 years of web development experience and 40 years of general experience writing software. I wrote the authors and they confirmed my thoughts:
"I totally believe it! Per the paper abstract, we find many factors driving results - and one of the factors is how experienced the developers are on the codebase, and how big/complex the codebases are.
"Given that this was a new and unfamiliar domain and new codebase, I would expect there to be much more speedup than the domain we studied!"
> Six hours for a prototype using four LLMs?
They have limits on the number of queries, so I used four different LLMs in tandem to circumvent query limits. I didn't write it four times using four different LLMs.
> it sounds insane and a tremendous mess
I posted the code. It's well organized, has few (if any) encapsulation violations, sticks to OOP quite well, works, and---if I knew the PDF.js API---would be fairly easy to maintain.
Yes, I stand by my claim that writing this annotation editor (PHP, HTML, CSS, and JS) would take me about 60 hours by hand and about 6 hours using the LLMs.