The only Rust section is the one on storage improvements about the struct that stores the hash, but do they really need that many hashes that 2 bytes makes that big of a difference? Article doesn't expand, but I guess it's a hash for every task on every computer, so maybe yes.
That's exactly his point/the area of cost saving - that they didn't actually need as many hashes as they had started with. The trick was in finding out how many hashes they could cull without degrading load balance.
That's the entire contention here. It's a double standard. Companies will sue the living hell out of anyone taking their IP, whether it's code or art, yet they have no qualms taking all the data they need from anyone and everyone. It was already a problem before, i.e. artists getting paid very little for work that companies profit a lot from like musicians or digital artists, but now with AI it's on steroids.
I agree. The double standard is the problem. People have been imprisoned for IP theft, but when these companies commit IP theft on the grandest scale ever imaginable, they're rewarded with trillion dollar IPOs. Either IP isn't protected, or it is. Legislators need to pick a lane. Right now it appears that poor people go to prison, and rich people get rewarded.
IP does not protect the little guy. This is nothing new. Draw a picture and then people start putting it on t-shirts and posters without paying you? Great, you can't do anything about it unless you have enough time and money to hire a lawyer to go after them. Self publish a book and then people start uploading PDFs of it? Better hope your real passion is filing takedown requests instead of writing.
AI training is the clearest example yet that companies are allowed to get away with what is treated as a serious crime only when an individual does it. There are many more examples of this, of course, but this one seems to be the most stark and obvious.
Other companies have no qualms about distilling the first. Let's hop on gear and get the market to deliver a distilled Fable that runs on a smartwatch. Sooner is better.
I think the difference is that the companies are dumping billions of dollars into transforming that data into something useful, so they would like a return on their profits. Opening up the models for free is not a good business model if you want to make money.
I think the difference is that people are investing significant amounts of time, effort, and money into transforming their work into something useful, so naturally they would like some return on that investment. Giving away that work for free is not a particularly good business model if those people expect to be compensated for the value they create.
If corporations weren't already owning the consumer, with AI it does this by many orders of magnitude. If something isn't done to prevent AI from being used to farm the masses for data, we will be living in a sci-fi dystopia without a doubt.
> it could fix the app in one of two ways: it could either change the code, or change the model itself. It chose the latter, replacing the model powering both the application and future instances of the agent itself.
Nah, common. It was given a task of which part of it could be fixing an AI model, so it does what it does and replaces or modifies the model to complete its task.
They're making it sound like out of nowhere it just decided to change. They are not agentic (actually) in any way.
> How can a team combat this, so that we can simultaneously avoid premature abstraction and broken windows leading to overdue abstraction?
From experience, premature abstractions are rarely premature unless you really try and anticipate years into the future. What happens is that abstractions can go in the wrong direction, and when they're not useful then they're called premature incorrectly.
For all the reasons outlined in the article, you want to anticipate how the software will scale, to allow room for growth. As a simple example, if you need one component, think what are the likelihood of similar components in the future, then parameterize that component so it avoids duplication. There is some risk in doing this if you get it wrong, but that's what skill and experience gives you (if you do lots of software design).
The broader pattern goes like this: spend some extra time building out the software to accomodate potential future growth, and be explicit about the assumptions so you know when the growth will start to strain the system again. At that point anticipate that next abstraction point, and plan accordingly to then abstract everything to the next level, adding even more room for scaling the software (not the users, but the actual code and features). This creates slow periods of development, followed by big spikes of productivity as the abstractions are used, i.e. creating a new feature is as simple as importing and using a few functions or maybe even just configuration.
> That's where another answer comes in: we can understand to participate.
> You can learn what the agent is doing to make sure you can be an active participant in the creative process. Here's why this matters…
Well, this isn't really a requirement to participate. It wasn't even a thing until AI. The real reason here is that AI is just not actual intelligence.
If AI could simply be trusted like an actual intelligent agent, none of this would be necessary. If it said something like "Ok, I did XYZ, but it is not a good idea to do this in this way, so I did it this other way that is better". Instead it just follows instructions into oblivion.
I highlight this because either AI keeps getting better and all of this is irrelevant, we will not need to understand, just like managers used to not understand (relatively speaking) the tasks they gave software engineers, OR AI stays in this robotic/tool mode in which case I suspect it will drastically change the way it is being adopted. If this is as good as it gets in terms of agency (as oppose to knowledge, which it is already god-like), then it will still create an impact (already has) but it won't restructure the entire industry.
The skill to distinguish on whether the extra work will help you get paid more in the future is essential. Developing this skill makes it a bet instead of just working more.
It's not possible to do everything. That's when your coworker that dedicates every waking moment to the job will outpace you and then set the standards.
I guess I should add "for someone else". In that case it's just bad negotiating skills, but at the same time companies have a lot more bargaining power over individual employees, and it's especially bad in the software industry.
it seems clear to me that one can slack off at certain times, and work hard at the important times, and overall come out about the same (or with less overall work). IMO as a developer in a large corp, if you know the right team to talk to, it can save you MONTHS of work yourself
reply