Authored by KnorpelSenf · Sat Sep 26 2026 · based on a talk at Waterkant Festival 2026.
\nThe AI hype is as ubiquitous as it is annoying. Some say AI will beat software engineers at every task in a few months. Some say human programmers will always be better. Both extremes are wildly wrong. Can LLMs even help with hard, unsolved engineering work?
\nFor years, LLMs produced slop and wasted time. In early 2026, that changed. Instead of chasing the latest hype tool, the author took a structured approach: pick a hard problem, get budget for tokens, systematically try ways to use LLMs, and write down what happens.
\nAt the author's employer, they solve large Vehicle Routing Problem instances. One hard piece is computing a distance matrix: a web server that takes lat/lon coordinates and returns distances and travel times for every pair—e.g. 1,000 locations (one million routes) in under 100 milliseconds.
\nBuilding the replacement took about 3 weeks of full-time work by one person with around €1200 in tokens. Roughly half went to design and Rust implementation; half to testing, benchmarking, and integration. Almost everything is LLM-generated (~15,000 lines; only a handful written manually). p90 time-to-last-byte on a c5a.4xlarge (8 cores) included 75 ms for a 1,000×1,000 matrix and under 5 seconds for 10,000×10,000.
Knowing what an LLM is helps characterize the tasks they can handle. Next-token prediction is accurate but not enlightening day-to-day. Instead: understand LLMs as semantic translation machines. They translate an idea or concept from one representation to another—English to summary, detailed specification to source code, source code to summary—without having to invent the underlying idea.
\nThe process is probabilistic: every translation incurs a "debt to the truth." Facts, requirements, or genuinely novel ideas cannot be LLM-generated; they can only be LLM-translated (unless you turn the task into translation via tools like search).
\nSemantic translation can happen in several steps. A strong prompt might contain a source file name, a problem description, and a brief refactoring plan; the model translates those into Read calls, concrete steps, and Write calls. LLMs automate the grunt work—instrumentation, benchmarks, flamegraphs, sifting metrics—while the engineer still understands the problem and owns the solution.
Another helpful analogy: LLMs are seven-league boots. Amazing if you know where you want to go; if you run the wrong direction half the time, you end up where you started.
\nFull essay with footnotes: knorpelsenf.me/posts/semantic-translation.
","headings":[{"level":1,"text":"LLMs: Semantic Translation Machines","id":"llms-semantic-translation-machines"},{"level":2,"text":"A Hard Problem","id":"a-hard-problem"},{"level":2,"text":"What Is an LLM?","id":"what-is-an-llm"},{"level":2,"text":"LLMs for Software Engineering","id":"llms-for-software-engineering"}]}}