That’s just generally how long relatively-complicated software engineering projects take. As a general rule, if a software project takes longer than 18 months, it’s because the engineers ran into unsolved fundamental research problems. (Or because of managerial incompetence/organizational dysfunction, but I’m assuming a reasonably competent team.)
Not sure if it was clear, but the reason I asked was because it seems like if you think the fraction changes significantly before AGI, then the claim that Thane quotes in the top-level comment wouldn’t be true.
Oh, I see. Certainly if the time required to implement our current best idea goes down, then the timescale at which we care about timelines becomes even shorter.
I’d be interested in your reasoning on that.
That’s just generally how long relatively-complicated software engineering projects take. As a general rule, if a software project takes longer than 18 months, it’s because the engineers ran into unsolved fundamental research problems. (Or because of managerial incompetence/organizational dysfunction, but I’m assuming a reasonably competent team.)
Shouldn’t 18 months be a upper bound, rather than your estimate, on the length of a software project then?
It is an upper bound. That’s why I said in the OP:
Ah, I see. Thanks.
Same—also interested if John was assuming that the fraction of deployment labor that is automated changes negligibly over time pre-AGI.
That’s an interesting and potentially relevant question, but a separate question from timelines, and mostly not causally downstream of timelines.
Not sure if it was clear, but the reason I asked was because it seems like if you think the fraction changes significantly before AGI, then the claim that Thane quotes in the top-level comment wouldn’t be true.
Oh, I see. Certainly if the time required to implement our current best idea goes down, then the timescale at which we care about timelines becomes even shorter.