While I'm not a lawyer, the legal advice I've received on various topics include:
1. Most laws are made about humans. If it's AI, it's often treated like a tool the human is using. So, change "I did this with AI" to "I did this with (other tool here)." The case law on those situations might give hints to what will happen.
2. Intent matters. Did you intend to do damage?
3. If a tool might cause damage, but you didn't prevent that, then someone might claim negligence. There's a lot of legal articles about torts for damages due to negligence. I personally believe a lot of agent use should be considered negligent. By default, I don't connect them to the Internet or my whole filesystem because I know they might do unforeseen damage.
Those are the three that come to mind most in such cases. You'd have to ask a lawyer. There's another risk of even using a lawyer, though.
For using AI agents, you must consider civil and criminal law because its problems are spread across them. Most lawyers in my area do one or the other. You might have to pay two retainers at $5,000-$8000 each or one, expensive firm with combined expertise. Just knowing your legal risk with agents might cost more than they'd make or save you vs just using human-driven AI's.
I enjoyed the article. He has good points. I'll emphasize one and add a other.
1. CPU/memory performance on cheap or throwaway systems has a niche benefit. Mostly poor people. I'm still usually on an ancient Thinkpad with a 2nd gen i7. It runs native apps really fast to this day. Almost all GUI cuz I agree with the OP but my apps are TUI by default to keep them lean and fast.
2. Security. While I don't aim for it these days, it was much easier to make textual apps securely than GUI apps. Secure OS's from the 90's already secured console apps. TX, Nitpicker, and EROS made progress on GUI's but there's high complexity still. I'll note the OP's idea of GUI front ends is basically what we did to isolate the GUI part in a dedicated partition with messages it sends checked by the secure component.
Other than those observations, I'm with OP where I'm tired of TUI's if GUI's are that easy now. I considered trying it with some lightweight, cross-platform frameworks. Anybody tried some with cheap AI's?
My proposal was using actual curriculums to ensure that's all that's in there. Also, there could be a peformance boost if doing that first. We'd need funding to license or buy them.
Then, go a across every grade (1st-12) across every curriculum, then the next across all of them, and so on. Checkpoint it at each grade level. Also, see how many epochs we need per grade to soak up the material. Dedicated fine-tuning for each grade matched to its capabilities. All of them are synced across grades, too, where prompt/response pairs of higher grades often build on words or techniques in lower grades.
Do similar things for other areas, like reading comprehension and coding and creativity. Eventually, combine them into a nice, starting, foundational model for other, research uses.
Beware of copyright issues for API's and patent issues about reimplementations. Wolfram seems serious about his I.P.. After the Oracle case, I'm not reimplementing any language unless it's open with no patent trolling possible.
If I could justify wear and tear and electricity, I was willing to do something like this for batch processing. The batches would be a bunch of prompts whose outputs I'd look at the next day. Maybe common operations, like QA or refactoring, on whatever software I wrote.
If so, I could use a larger model than I have real-time hardware for. The largest, well-trained models can often get the output mostly right in one try. I also would be using AI's as a supplement to, not replacement for, my own brain. So, issues with the outputs wouldn't be a problem because I'm just keeping what's helpful.
If I still need to re-generate it all, it might still save money over time by avoiding cloud costs. Also, hardware that's already paid for is a sunk cost that doesn't inflate over time. Glitches in loading or destroying VM's might blow up into a big bill.
They started out that way. Keeping consistency between the formal specification and the code was always difficult. The further apart they are in distance or notation, the more difficult it is. So, the field experimented with verificatiom-oriented languages to localize changes.
I believe I proposed that somewhere because it was a small, useful app which often opened malicious payloads. People may or may not fully prove it.
What I thought would be useful is, like Ironsides DNS, a SPARK Ada or other implementation that shows no code injections could ever happen from loading, modifying, or rendering text. That's a useful subset of full verification.
If not that verified, writing things in a memory-safe, concurrecy-safe language covers lots of ground. Rust and Pony put good effort in those areas. In Rust, I think you still had to manually turn on checks for some overflows which hurt performance a lot. So, static analyzers or automated provers for range properties have a performance benefit.
Muen is the largest, production project I know in such a language:
Because you can use it to find temporal errors in your software. People in fact do. So, that proves it's worth even if one can't be sure of perfect conformance to the spec.
Far as connecting specs to code, these papers did try to combine Event-B with SPARK Ada:
1. Most laws are made about humans. If it's AI, it's often treated like a tool the human is using. So, change "I did this with AI" to "I did this with (other tool here)." The case law on those situations might give hints to what will happen.
2. Intent matters. Did you intend to do damage?
3. If a tool might cause damage, but you didn't prevent that, then someone might claim negligence. There's a lot of legal articles about torts for damages due to negligence. I personally believe a lot of agent use should be considered negligent. By default, I don't connect them to the Internet or my whole filesystem because I know they might do unforeseen damage.
Those are the three that come to mind most in such cases. You'd have to ask a lawyer. There's another risk of even using a lawyer, though.
For using AI agents, you must consider civil and criminal law because its problems are spread across them. Most lawyers in my area do one or the other. You might have to pay two retainers at $5,000-$8000 each or one, expensive firm with combined expertise. Just knowing your legal risk with agents might cost more than they'd make or save you vs just using human-driven AI's.
reply