Overview
There is a strong counterargument to harness-first optimization. The "bitter lesson" framing is that increases in raw compute and model capability can outrun hand-built optimizations. A more powerful model can overcome weaknesses in the surrounding system, require less steering, notice deeper bugs, and produce useful behavior that was not explicitly engineered into the harness.
The correct response is not to ignore model improvements. It is to avoid treating them as a substitute for engineering. A stronger engine improves the system, but a poor chassis still wastes capability. The model and harness should be improved together, while recognizing that the harness is the component the team can shape most directly.
Future models may reduce the amount of handholding they require. That possibility does not justify waiting or neglecting fundamentals. Clear tasks, coherent codebases, tests, and observability remain useful under the current workflow and are designed to remain useful when the model changes.