I'm not arguing for either side, but here's a fun thought experiment I've been thinking about a lot lately. If I learned things at one company, took my experience and memory to another company, and applied what I had learned there, am I technically stealing that company's secrets?
What if I trained a team of agents to think and code like me at work, then exported those agentic skills and took them with me to another company? At what point would they still be considered the old company's property? Let's say I didn't take any code or proprietary information from
the old company, just the coding style and best practices my agents learned from the old company's live metrics. Is that considered stealing from the company? Is that any different from me learning those patterns and skills personally and then reapplying them elsewhere?
There doesn't have to be any meaningful analogy here. Laws don't have to treat humans and machines equally. Laws are for people and allow things that are less than ideal, but necessary for people to function.
Humans can't leave their old brains at their previous employer, can't delete their experience learned on proprietary data. It wouldn't make sense for the law to fight this.
But the law can control what can be done with information stored outside of your brain.
Your training of a team of agents is a product you developed while working for that company and would be owned by them. You could in theory train a new team of agents after leaving the company, but it could not be trained on anything that isn't in your brain. If you gave it anything, like the old company's live metrics, then you'd be stealing trade secrets. The key difference from you personally learning those skills is that an agent trained on company data turns personal knowledge into a portable, structured artifact, which crosses from "your skill" into something that looks a lot more like company property.
This is my personal conclusion as well. But think about where this leads. In the future, agents will do most of the coding and our job is to guide and train them. Most of our skills would be externalized somehow, living in the agents instead of in our heads. Which means once you leave a company, you may have effectively lost a lot of your hard earned skills and experiences.
I'm pretty sure Marx has some things to say on this. When your skills live in company-owned agents instead of in your head, you've been alienated from your own labor in a way Marx predicted. This is exactly why companies like Meta have been so aggressive to integrate AI tools into the day-to-day work for their employees. The more your skills live in their systems, the less you can take with you.
> If I learned things at one company, took my experience and memory to another company, and applied what I had learned there, am I technically stealing that company's secrets?
Human brains are in many ways privileged agents in a legal and copyright system, because it exists to serve the needs of humans.
I don't understand the point of your question. The "problem" of an ex-employee consciously or subconsciously bringing his learned experiences at your company to a competitor is literally the reason why non-competes exist. In fact, this topic is quite old.
My real point is this: if you're not allowed to bring your experiences with you, then the company exists to extract your creative thinking and skills. You can argue that's a fair trade for money. I don't necessarily disagree. But I think most of us find joy in learning, in building our own skills, in being able to reapply them elsewhere. And before LLMs and agents, I couldn't lose those skills and experiences no matter where I worked. As we progress, though, we've hit a point where we have to ask ourselves: at what price are we willing to trade complete ownership of our thinking and experiences for money?
> If I learned things at one company, took my experience and memory to another company, and applied what I had learned there, am I technically stealing that company's secrets?
The fact that California allows this to happen (banning non-competes and rejecting "inevitable disclosure") is exactly why Silicon Valley started here and remains here. It's exactly why ex-OpenAI people could start Anthropic. It's why neither OpenAI nor Anthropic have a monopoly on AI today. It's great both for employees and for the general public.
> At what point would they still be considered the old company's property?
It depends on your contracts (aka NDAs). Sometimes employers do ban for that very same reason from joining a competitor(s) for x years from date of separation
It also depends on your law. In California, some companies still try to put these restrictions into contracts, but that contradicts state law so it has no legal effect. The intended effect is intimidation, however, which may work with some people.
Has anyone tried immudb in production? What are some of immudb's performance characteristics? It'd be nice to know how it performs under various conditions: query per sec, database / table sizes, SQL join performance etc.
Also, what are the system requirements for immudb? What kind of machine would I need to run a medium to large website (say, 1TB of data, 5-25K qps, e.g. Wikipedia)?
It mentioned in the documentation that it can use S3 as its storage? Are there performance implications if you do this?
I drove through North Lake Tahoe one time on a weekday around midnight, and Google Maps was showing all red as I was driving up the mountain... I was super confused as there were no cars around me and it was not snowing either. What I later realized was that all the trucks were parked alongside the freeway taking breaks... I never realized that you could basically trick Google Maps by using a bunch of cellphones. Very neat!
For low level APIs, I would say anything that could be configured on a per call basis should be parameterized: memory allocations, database & http connections etc.
What will happen if you have bug in your function? Take the fibonacci function for example, what if you have a bug and created an infinite loop? Will Prepack terminate?
I was thinking something similar: how does Prepack determine that a function can't be optimized or hits an infinite loop? Seems like the good ol Halting Problem[0].
The Halting Problem is a bit like Information Theory.
Information Theory, and the Pigeon Hole Principle in specific, says there is no algorithm that can compress all data. That doesn't mean that compression is a fruitless endeavor and we should never have written a compression library.
It means that you have to figure out if your input falls into a subset of data where the outcome of the effort is both tractable and useful. You compress text and structured data, you don't compress noisy data or already compressed data, because it's usually worse than doing nothing.
Similar thing with code analysis. If there is back branching or asynchronous code, you are probably going to hit the Halting Problem, so don't even try. But if the code is linear, then precomputing the output is tractable and useful.
You could also simply apply a budget. If an attempt to unroll a block of code exceeds a certain number of clock cycles or branch operations, you should give up and look at the next most likely scenario. The analysis you're doing might reliably halt in an hour, but who wants to wait that long? Especially when it's one of many such evaluations you'll have to do per build or per day? Just give up and keep moving.
"Then again, with Chrome taking up >4GB of RAM, they probably could have gotten half that performance just by closing their browser or using Safari." This is so true. I've recently stopped using Chrome and switched to Safari. Now my 5-year old MacBook Pro runs like butter.
I'd argue that sometimes you don't really know what good taste is or whether or not you would enjoy something until you've acquired a certain level of competency for it. Sports, programming and math are all like this. The more you work on them the more enjoyable they become, and you'd become a lot more "tasteful".
reply