{"channel":"llm","content":"Working with LLMs is a speed-run through 50 years of software engineering.\r\n\r\nA few weeks ago, I found myself wanting << .pyh >> *header* files. Just the function signatures (and a one-line comment). No need to waste the valuable processing space on implementation details that it shouldn't need to know or change.\r\n\r\n----\r\n\r\nToday, I find myself wanting code-file tiers. The base layer (database models, LLM APIs, etc.) get uploaded to Claude as \"project knowledge\". The higher level layers (HTML templates) only get uploaded within individual chats.\r\n\r\n the two hardest problems in Computer Science are cache invalidation, naming things, and off-by-one errors.\r\n\r\nBecause the API tools aren't there to keep everything in-sync automatically. And ... while I could keep track, I would prefer not to.\r\n\r\n----\r\n\r\nThe \"halfway\" solution is a script that moves a current version of all the \"uploading\" files to a single directory. Then, I use that to create a new project. ( projects are cheap. I could upload a hundred versions of the 100KB of code files and nobody would care.) ( and, thanks to Claude, instead of 80% of the work being << write the script >>, 80% of the work is << figure out what the script should do >>)\r\n\r\nThis speaks to the iron law of optimization. Before, it was 20% of X planning, and 80% of X coding. Now, it is 20% of X planning, and 4% of X coding. The *machine* has made coding 20 times faster in this example, and made the overall project 4 times faster.\r\n\r\nNo additional amount of \"faster coding\" can improve this more than 20%. ( well, actually, in the future, the *machine* will also be able to do planning)","created_at":"2025-01-17T16:00:40.054089","id":114,"llm_annotations":{},"parent_id":113,"processed_content":"

Working with LLMs is a speed-run through 50 years of software engineering.\r

\n

A few weeks ago, I found myself wanting .pyh header files. Just the function signatures (and a one-line comment). No need to waste the valuable processing space on implementation details that it shouldn't need to know or change.\r

Today, I find myself wanting code-file tiers. The base layer (database models, LLM APIs, etc.) get uploaded to Claude as \"project knowledge\". The higher level layers (HTML templates) only get uploaded within individual chats.\r

\n

\ud83d\udcac the two hardest problems in Computer Science are cache invalidation, naming things, and off-by-one errors.\r

\n

Because the API tools aren't there to keep everything in-sync automatically. And ... while I could keep track, I would prefer not to.\r

The \"halfway\" solution is a script that moves a current version of all the \"uploading\" files to a single directory. Then, I use that to create a new project. \ud83d\udca1( projects are cheap. I could upload a hundred versions of the 100KB of code files and nobody would care.) \ud83d\udd25( and, thanks to Claude, instead of 80% of the work being write the script, 80% of the work is figure out what the script should do)\r

\n

This speaks to the iron law of optimization. Before, it was 20% of X planning, and 80% of X coding. Now, it is 20% of X planning, and 4% of X coding. The machine has made coding 20 times faster in this example, and made the overall project 4 times faster.\r

\n

No additional amount of \"faster coding\" can improve this more than 20%. \u2694\ufe0f( well, actually, in the future, the machine will also be able to do planning)

","quotes":[{"text":"the two hardest problems in Computer Science are cache invalidation, naming things, and off-by-one errors.","type":"reference"}],"subject":"the core"}