📖The Death of Code as Craft

Programming used to be perceived as a second-class intellectual activity ⟶ Programming used to be perceived as a second-class intellectual activity

• programming had local effect as programs would only run on a single machine (because there were too many different architectures). programs weren’t long-living either as the machines weren’t

Position coding as a craft was a marketing tool for companies to attract talent (signaled that company cared about code, so that was a good place to work)

LLMs can handle repetitive/boring tasks and help expedite the progress, unlock developers to work on more creative stuff. LLMs can also help understand code or suggest improvement. At least for less experienced devs. → LLMs can expedite software development by offloading simple tasks

For experienced developers, LLMs produce a code of subpar quality and don’t take into account larger system context, so LLM-generated code introduces a risk to code quality and stability of the system.

LLMs like more explicit (verbose?) code because it needs to remember less context. → LLMs work better with explicit/verbose code

LLMs also work better for static/typed programming languages because type checks can help catch errors earlier. → LLMs work better with static/typed programming languages

(Unison must be a good language for LLMs. Statically, strongly typed. You can also generate lots of code/tests and keep them in “background”)

An LLM-aware software development tools would be great, keeping four layers of context: developer intent, code, tests, and runtime output.

Monolithic architecture is better suited for LLMs as microservices require keeping more context.

• (it will also become easier to maintain a lot of code with LLMs with less developers)

LLMs automate low-level details of coding, so higher-level skills will become more valued (creativity, problem-solving, systems thinking)