jopsen
> a culture that strongly believes internally written software sucks. This is Invented Here syndrome
It's the inverted invented here syndrome ;)
But it is oh, so true. Entirely, unsurprisingly -- an internal software stack has captive audience, and never compete with anyone else.
They can good, but exception to the rule.
And its the same reason you'd rather have a SaaS vendor, than asking an agent why the cloud bill keeps climbing and then have to debate the impact of delete such and such VMs or databases that nobody knows what do :)
You also don't ask your agent to start from assembly.
Things you can get upfront as libraries or services are things you and your agent don't have to worry about.
I'm not even sure there is anything new here, just that we have a capability jump with LLMs, you'll probably prefer spending it on building features, not replacing vendors (unless they are crazy expensive).
Indeed nobody wants to review LLM generated slop.
So being able to know that this code cannot contain memory bugs, race conditions, etc is extremely valuable.
I might go a far as to claim: I'd be okay with the AI using an obscure language, if I can know the code is free from memory issue, race conditions and has no side effects, etc.
The argument that with LLMs pure functional language that I didn't bother to write before is now viable.
Wow, cops certainly know how to produce a confession.
CA has the key, if it wanted to give someone a backdoor, it wouldn't issue a weak key.
That doesn't mean, you can't invite your neighbors over pizza or coffee, be friendly and one day mention that you think X, Y or Z and you wouldn't mind helping, and if they they aren't interested you'll totally respect that.
Don't be a Karen. But being considerate the old school way can go far. The rest you just have to live with :)
But you have to beat the team with vision + strategy who is also blasting out code with LLMs.
Certainly, the time it takes to figure out that an idea is bad had been shortened :)
To be fair, when I was a kid we'd connect the editor to the server using an unencrypted ftp connection and modify php files in production.
This worked perfectly fine, and phpmyadmin made schema changes super easy.
These days we do tests, schema migrations, terraform, staging sites, traffic migration, monitoring, logging, revision control, etc.
... it's a lot of boring work, and for most CRUD apps, its entirely unnecessary :)
That said: I doubt we'll abandon these practices for things that matter.
Because while modifying php files in production can increase velocity, it can also get very "exciting" if you have a few co-workers on the same project :)
But profitable enough to justify the ludicrous valuation?
Smaller than the one in Ukraine today.
I don't know I have some hopes that maybe it'll play out more with economic tools.
Oh, and I don't think western alliances and trade relationships necessarily need to collapse. But Trump certainly tries :(
But since the industrial revolution 80 years is something.
I hope it's a trend: but living in Europe right now, I do feel like our strongest ally are giving our enemies reason doubt the deterrence we've collectively built over the past 77 years.
We had to deploy armed troops to Greenland to deter an ally from invasion.
The deterrence to war we've spilled blood building for 77 years.
Economics is part of why we haven't had wars, collective deterrence probably had something to do with it too. Without NATO who is to say how many smaller nations Russia/USSR would have invaded for the fun of it.
I might want the REST API for a webshop to be solid, payment and checkout process, sure.
But the UI. So long as the LLM doesn't falsify product information, why customize the layout, theme, look and feel for each and every single customer.
Okay, maybe don't, but point is: you could take bigger risks, you maybe don't need to review UI changes as much.
Not because everyone writes bad code. They do, at-least the do first time you read their code. You only think someones code is decent when you spent 3 hours trying to refactor their PR, and realized that the compromises they made were perhaps reasonable. (This is an important lesson to learn)
Whether code written by others is poor or not is also besides the point. You cannot keep everything in a large project in context (biological or not).
Software engineering (not computer science) is about: managing complexity. Structure your project in layers or abstractions or packages or silos or verticals or objects or whatever.
But break complexity into bits, so that everything isn't in mind all the time.
Nothing new about that. And poor engineering can be papered over with hard work. It's just easier to reach the point where poor engineering really bites ;)
But prospects for a positive outcome where probably always slim.
IMO, it is particularly dumb when there is a full scale conventional war happening in Ukraine.
For the record, it's not all the big corps that are this bad.
Many are borderline paranoid about privacy, both for appearance and compliance perspectives.
If your platform/sdk/browser/standard-library comes with zlib/gzip/.. then it's often easier to just pick that.
No new dependencies is always a win. App size. Security, etc.
Otherwise, if zstd is easy to add, IMO I would always prefer, zstd, lz4 or brotli.
Because JSON is an inefficient text encoding, compression (with custom dictionary) are likely to really well on those.
Books have recurring words, but probably much less.
Which was the real crime. To be fair, many places outside the US not respecting the police is a illegal -- but genuinely not enough that an office would be justified in as much as indicating that the officer is armed (which usually counts as use of force).
Regulation that cannot practically be implemented or complied with (example: forks of open models), this leads to selective enforcement and by extension corruption and loss of rule of law.
Regulation before the market has even settled down, we don't know if AI will be datacenter only, or open models everybody forks, modifies and runs locally.
And we won't know for a couple for years to come.
It'll just punish the bad actors running the scrapers. As the original poster mentions that they are using TVs as proxies to get residential IPs, one really can't think of these bots as criminal enterprises.
Sadly, if the bad actors has two cents for brain, they'll limit how much importance each domain name can have on training data. To mitigate impact of bad data like this.
(Note I'd suggest only linking to them from robot.txt as pages to not be indexed, that way no human or well behaved not ever will see them, which is kind of the point).
That's bad for static content.
Try adding search, with pagination and 16 filters that can toggled on off. And 1000 tags, give each page 5.
The only punishment would be unique text that trains their models to be degenerate. And even then you'd probably have to serve across many domains.
I think it's a few bad actors really. Because nobody serious about indexing content will do what these crawlers are doing..
They are consume lots of content that is unoriginal or duplicate or duplicate with minor modifications.
Not sure how to block, but maybe a little bit of law enforcement could dramatically reduce the number of TVs being used a proxies.
But if bots a crawling diffs between all possible commits it's crazy.
CDN will do nothing, because it's new urls each time. You can maybe find a CDN provider that block bots.
Granted some human will likely have to review it. Or packages flagged by Al could require users to explicitly allowlist them.
That's a really good description, I should update my linkedin profile :)