the argument is productivity gains are increasingly driven by technological advances, which are spurred by capital investment. for example, if a company purchases software that increases their accountants productivity by 5x, should those accountants immediately be paid 4-5x more?
I would contend that the accountant should not - it should flow to who bore the cost of the input (capital owners). however, if you starve labor of those gains, it destroys the consumer base that capital relies on to buy its goods and services. therefore, society requires broad wealth distribution to function, which implies some level of redistribution by the state is needed.
2% is average. 1-1.5% is considered a slump, while anything over 2.5% is considered a boom. for instance, the post-ww2 boom (1947-1972) averaged 2.9%. at that rate of growth, a country's total output per worker doubles in roughly ~25 years.
he's referring to labor productivity, e.g., the economic value produced per unit of labor input. it also _has_ changed significantly, as seen here: https://fred.stlouisfed.org/series/OPHNFB
AI usage will directly impact said margins. Moreover, for the scenario you describe, companies need to have the capability to precisely estimate the cost of a given deliverable - not something possible with current tooling + models. You're also underestimating the market trend towards vertical integration: companies are not going to be constrained by a sector or niche. They will expand to capture as much value as they can, because now their capacity to do so is partially decoupled from labor.
It will certainly be a cutthroat landscape for engineers, but companies will be building _more_ capacity, not less. In other words, the demand won't disappear for skilled technical labor, it will just move higher up the value chain.
I don't know, even if AI allows two engineers to do the work of six, companies will likely just use that efficiency to expand their scope. I think we'll see short-term layoffs and a more stratified engineering field during the transition, but the fundamental need for deep technical expertise isn't going away.
tests are an important signal of course, but the use case you describe doesn't necessarily mean you need to follow TDD. the data suggests that creating the tests after the code is just as or even more effective, and at significantly cheaper input cost.
I've been finding enforcing integrations and behavior structurally (e.g., through codegen/schemagen, e2e tests, etc) more reliable than simply instructing the models to write tests. oftentimes these tests are pretty low quality anyway, and results in its own form of tech debt.
I was a big proponent of encoding TDD red-green-refactor methodology into my agent workflows until recently when I made the same realization after reading this study: https://arxiv.org/pdf/2602.07900
TLDR; it found test-writing volume only weakly correlates with success and that encoding test-writing principles did not move resolution rates but _did_ materially change cost. Encouraging tests cost +19.8% output tokens for 0% gain; discouraging them saved 33–49% input tokens for ≤2.6pp accuracy loss. Separately, imposing the TDD procedure specifically seems like it can backfire: it actually _increased_ regressions from 6.08% to 9.94%.
IMO, where tests clearly help is primarily as an "oracle" applied after generation. It gives the models a signal that enables them to verify and self-correct if necessary.