Humans will need to have visibility into application code, sure, but not likely optimized visibility - compiling and transpiling are good precedents for this. There was(is?) likely an argument to be made that humans need to be able to directly review bytecode or minified JS, but these certainly aren't optimized for humans. I do think there would be some version of an IDE that makes human traversal of a bot-optimized codebase easier, but the more we expect the LLM to do, the more we will need to favor optimizing for the LLM over optimizing for human developers.
I think if we swap “human” with “worker” that is spot on with this line of thinking. In the case of LEAN manufacturing, the system is optimized for the thing doing the work (the worker). If our goal is for the “worker” to be an agentic process and not a human, then we should be optimizing the system for that worker’s needs and not forcing the process to do complex movements around a code base optimized for humans.
I know we had a 486 at some point when I was a kid, but this code would have predated that machine by a few years so I'm not entirely sure. There were also machines at the school (where he worked) but not 100% sure what they had when.
I got fortunate with the disks - I just bought a USB 3.5mm reader and hooked it up to my Ubuntu machine, and there the files were, no corruption that I can tell. I'm glad other people are also enjoying the find!
These scripts were written by my father in the 1980s, he was a middle school science teacher and wrote these to help him manage classrooms. I think it’s a cool example of the way personal computing changed life in that era; he was never a software engineer, just a guy that needed to automate some tedious work. I encoded the BAS files in utf8 so they are easier to read.
One of the better ways I've seen dbt described is very similar to an MVC framework for data (I didn't see that mentioned yet, if it has been sorry I missed it).
Where a rough mapping would be:
model >> source
controller >> ephemeral model
view >> materialized (view, table, incremental) model
Like many MVCs it provides abstractions and helpers for common tasks such as performing incremental updates, snapshotting time series, common manipulations like creating date spines. Like many MVCs it supports a robust ecosystem of plugins that make it easy to re-use stable transforms for common datasets. Where Django passes you the request object instead of hand-parsing http responses, dbt allows you to loop through a set of derived schemas and dry out your SQL code.
You would generally use dbt as a transform framework for the same reason you'd use Ruby on Rails or Django etc as a web framework - because it provides you with a ton of otherwise repetitive non-differentiating code pre-baked and ready to go. You could keep a folder of sql files you arbitrarily run, and you could roll your own web framework from scratch. Personally I wouldn't do those things.