Thankfully, these times are over.

Are they? For me a natural response to being forced to be honest about the broken state of most systems software would be massive rewrite efforts with better tools (memory-safe language, capability-based security, judicious use of formal methods, etc.). But what I see happening in practice is more “exhaust ourselves fixing all the LLM-found issues and then when the current stream dries out we can claim victory, without otherwise changing our programming approach”. And duh, of course, this is more incremental and the upcost front is smaller, and the result is worse, so of course everyone does it.

score 1 · canonical

I read that the University of Sidney is moving to a “dual lane” approach where some assignments are meant to be done using AI tools, and others are done is strictly controlled conditions where AI usage is forbidden – this would be a way for students to both practice for themselves, yet also become fluent in AI tooling usage.

Maybe a similar approach could work in software companies: mandate that a certain share of tasks be done without AI tools. For example the company could have a control where company-funded AI usage is available from Monday to Wednesday, and shut off Thursday and Friday. Would such a hybrid approach avoid some of the downsides? Of course this relies on companies being willing to accept a short-term productivity hit (assuming that AI-assisted days are indeed noticeably more productive), for the benefit of long-term skills and work dynamics. I don’t expect most companies to be able to make this choice…

score 1 · canonical

There is a weird disconnect between the first part of the post, which suggests that we should de-emphasize applications and can now focus on “the beautiful ideas, the insights, the beauty”, and then the second half, which presents the following three examples:

1. Getting a machine to generate a possibly-correct (who knows?) declarative description of a programming language from an implementation of the language.
2. Helping Amazon verify their proprietary software faster by adding LLMs in their verification tools.
3. Asking a machine to produce a declarative specification of a programming language in a problem domain that we don’t understand, because we do not allow ourselves to spend the time to learn it (but can still serve as an expert to help the system authors assess the resulting spec).

I am sure that being able to work on all of these faster than before can be exciting and satisfying – this is the main point of the article. But I fail to understand how they relate to the proposal of worrying less about applications/adoption and focusing more on things that are beautiful and insightful.

(I also think that the post is tone-deaf and weird as a follow-up on the TYPES discussion, but oh well, this is a discussion to have with the author.)

score 5 · canonical