Context, not code, is the future of software development
bozhao.substack.comThe value of software never came from code or the means to produce it. The value always comes from solving problems, increasing efficiency, reducing costs. That happens mainly by gathering and clarifying requirements and setting priorities. The process produces code as an artifact.
That may not seem obvious because programmers often do both jobs, and frequently in a haphazard or incremental fashion, discovering requirements along the way as they iterate on versions of code. We do that because working software very often represents the most complete and unambiguous representation of requirements — we don’t have a better language for describing software. Prompts in English won’t make that better.
Thinking that the best use of LLMs comes from writing more code seems to lack imagination. Why not use AI to solve the business requirements, rather than having it write code? Instead of “write the code for a metrics dashboard” why can’t we just ask the LLM to show us the dashboard? Because LLMs can’t reason or easily integrate real-time raw data into their model. All they can do now amounts to mimicking a human programmer by looking up similar tidbits of code from the training data.
Yep. I agree. And that's what I am trying to tell folks. Focus on higher value work.
> Software development is experiencing its "assembly line moment,"
I disagree, the history of software engineering is a constant series of "assembly line moments", because we're always making new machines to make the old machines. Compilers, macros, garbage-collecting memory management, and libraries upon libraries.
There's nothing new about seeking to automate oneself out of a job.
We always want to go higher leverage/value tasks. This time is teaching others, not just writing code.
We are not automating ourselves out of the job, we are changing the nature of the job. From writing to teaching.
Referring to LLM-usage as "teaching" is both kinda-insulting to actual teaching--a task not entirely new to senior engineers--and also a rather grand exaggeration of LLMs ability to be-taught.
Twiddling with prompts is not "teaching", it's guess-n-check whack-a-mole until you get something barely good enough to ship, at least temporarily... until it Disregards All Previous Instructions and barks like a chicken or the training data shifts enough that you need to throw on a new set of arbitrary influential phrases.
The lack of easy analogies for controlling an LLM isn't really because it's an amazingly good control scheme, but because it's so weirdly unreliably awkward that it's something humans don't even try to make in our other machines and systems. It'd be like designing an industrial stamping machine so that its controls were buttons on a Twister™ sheet: It'd be quite novel, but not in a very good way.
You have a wrong assumption of what context and teaching means with twiddling with prompts.
The job of human is providing teaching via feedback. Your manager does the same thing to you too. And you can distill those feedback into learnable experience for your llm to be better next time.