Well, you could use jsDoc to hold your types instead of writing them in typescript. The typescript compiler can still check types in jsDoc comments but you do not need a build step and the javascript you ship to the browser would be the same you write in your editor.
This month I worked on my own AI agent written in POSIX shell. It's been surprisingly useful for debugging command line problems on an old laptop running linux, like fixing an apt problem.
Seems to me this would get easier or harder depending on how you write the code. Like if you write the code in something standard and unchanging like POSIX shell scripts or C99 or ES5 javascript, at least the ecosystem won't change out from under you. If you use rust or python or a bunch of node.js dependencies then you might have to edit the project just to keep up with ecosystem changes.
Just spit balling: could you have the agent pre warm the cache as part of your workflow? Like at the start of working on the code have the agent run a compile in the background. That way when the agent is ready to "really" compile there is a warm cache
You should not underestimate how confusing those CLI tools are to people who have never used them before.
For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.
I'm curious but don't know much about the internals of LLMs - could you use a similar architecture with other models that have "layers"? I mean, could you have one layer do its work, then remove that layer from RAM, load the next layer from disk, and have that layer activate on the result of the first layer?
Seems like for a hobby project $1 or $2 per task would add up a bit, depending on how many tasks you need to do. I mean it makes sense for a software company
I believe that while the file system does not have journaling, that can be offset by applications. I.e. I think the SQLite Write Ahead Log would still protect you against data loss even if there's no journal in the file system, assuming you set various settings correctly. So I think it kinda depends on how the applications store data.
Over the last week I wrote a simple AI agent using ~1000 lines of POSIX sh. Makes sandboxing scripts an AI wants to run on your computer relatively straightforward. Lets you prompt the AI by llama.cpp or curl to an OpenAI API endpoint. Feels like a unix util.
If we assume everyone has access to the same AI tools and those tools do help improve output a lot then you get the same prisoner's dilemma as ads.
The people using the AI tools to improve their output will set higher consumer expectations for their product or service. If you do not also use AI, you will not be able to keep up, and so you will lose business over time.
So you have to pay for AI just to keep up with the other people who pay for AI.
But then if everyone is paying for and using AI to improve their product or service, no one can steal market share from each other. So you are all now paying a lot and AI is doing a lot and the buyers are getting better results, but that does not necessarily lead to better financial results in terms of market share, revenue, costs or profits for the business that is now using AI
There does not seem to be a big penalty for going slow anyways. People seem to just switch on cost as soon as a model can do a task well enough. There do not seem to be strong network effects or vendor lock in.
Seems to me that going slow is the better long term tactic. China can just let the USA pay the high R&D costs to figure out what works, then just copy what works.
I wasn't there but this seems like the same feelings people would have had in the Rust Belt when the first factories started closing and getting a job started getting harder.
You could think of the top as translation too. Translate user feedback into a profitable business model. Then translate that business model into a series of projects to make the business model happen.
AI can certainly look at more user feedback than executives can...
github.com/patrickjh