📖The Death of Code as Craft

May 11, 2024

authors: Jon Christensen
year: 2024
url: https://every.to/p/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)

Backlinks