I don't understand why we keep on building right next to highways which are some of the worst things for our health. You don't need to live in the countryside for that. Just stay roughly 1km away from them and the situation is significantly better.
There is evidence of a lot of ugly diseases caused by this, without even mentioning the constant 40+ dB background noise.
> so there will be a displacement of medium to large companies by much smaller ones.
There are so many regulations EE companies follow and offer that no startup owner or worker could ever deal with. The moment your company shifts to that sort of work, you're automatically not anymore a startup (by definition).
Only if you get super smart robots that can manage a lot of bureaucracy etc. Starting from multicloud/region deployments, local regulations, accounting, taxes, laws, etc. Which is what companies like SAP (but not only them) do basically.
But if that happens we are all in a situation that we don't need companies anymore (the way we know them).
My field is lightly regulated but it is regulated and LLMs have helped massively in producing the documentation but also in reviewing the same documentation on the regulators side. This was always a disadvantage for small companies where the fixed regulatory cost couldn’t be amortized over a larger staff size and now because of LLMs it is less of a disadvantage.
I think we are living in a temporary window where the volume of bureaucracy hasn't caught up with token processing rates. In a few years it'll be increased, I'm sure.
I’m sure there will be attempts but I think our future will be dominated by separatist / spinoff societies. There is an economy of scale in functions of governance as well as a diseconomy of scale in bureaucracy. Using LLMs to make the expensive parts cheaper makes smaller self governing societies much more viable.
All you need to do to understand what task is more complex (for a robot to solve) is just to ask a 6-8 years old child to do it. It takes days before they "understand".
So it cannot be that simple (for the reasons you mentioned).
Of course, you can mention all the things they can't do (what if there are stairs, what if the doors are smaller than the robot, etc) but it's mindblowing to see what they can do - and also the chat panel is really nice and makes it more interactive.
Why does this obvious falsehood get repeated so much on hn Everyone can look up what the CDU did, it's not like they did it in secret.
It's bad enough that nuclear proponents ignore the massive cost of nuclear compared to renewables once you factor in building costs, insurance and storage imho. But then to pretend like the conservatives didn't have a choice but to bungle the nuclear exit really is too much.
The CDU never listened to the greens when it came to not killing the solar industry and serving it to China on a golden platter. Or not killing our rail infrastructure by continually delaying maintenance so that we would have to do much more costly repairs later.
But in this instance, they do, and do it in a way that is a gift to the energy companies, and instead of noticing the obvious corruption at play, people still blame the greens.
Sure, SPD didn't have anything to do with it. Schröder and the Greens didn't have anything to do with it at all.
The Green party itself was literally born out of a protest against nuclear reactors in the 70's (Whyl).
CDU tried to slow down the phase out, but when Fukishima happened Merkel thought about staying in power rather than doing the right thing (= not shutting down the power plants).
I don't care about CDU, which as usual never misses a chance to disappoint, but not saying that the phase out was planned and executed by the Greens (and obviously SPD) is just factually wrong, because they initiated it all and implemented it. It wasn't just a draft, "let's see if it gets amended, etc..".
EDIT: I was talking just purely about energy and such reforms. The last 30 years have been ... to say the least... "weird" and short term.
Disabling a technology is a huge mistake, no matter what. No country did it the way it was done in Germany.
Yeah it's crazy, in every post about Germany inevitably the nuclear phase out will get brought up and the comments/discussions always seem like a shit show of misinformation to me. And it's always how nuclear is being phased out in favor of coal and gas and that's why energy is expensive, industry is dying, and the Greens and or EU are to blame for all of it. It's tiring, really, and I have the impression that these posters are not acting in good faith, but posting to reproduce a narrative.
As we are supposed to strongman other commenters arguments here, I'd say they are not posting to produce a narrative, but rather that they have allowed themselves to believe that they are the "obviously right", and everyone who believes otherwise is driven to do so by ideology instead of logic.
By painting the opposition to nuclear energy as emotionally driven, they can assure themselves that their position is rational, and this allows them to subconsciously ignore the evidence against it.
EU did the Green Deal, though, which is way worse than shutting down a few nuclear reactors that after all didn't produce that much energy anymore and were anyways planned to be shut down.
We pollute right outside our block, give credits to companies claiming to be "green" so that we can sell hardware here that is certified, so that we can go to sleep a bit happier as human beings, because we believe we're doing the right thing.
In all this, they make tons of money, make our economy worse than it ever was with no end game.
OP used the word "lifetime" which makes a key difference.
I don't want to be responsible for a bug in my 8 years old code, which I probably even forgot how it worked etc. I probably don't even work anymore in the same team or on the same service.
Why the hell should I be responsible and how is this sustainable?
I am not even sure if your criticism makes any sense at all anymore nowadays. AI is writing 80% of the code, if not more. It's technically not even your code anymore, although there is your name on the commit. Why should I be responsible for that 3 years from now, when I have again moved team or service etc.
Accountability ok, but you should not retire with your code.
> Why the hell should I be responsible and how is this sustainable?
Well, it works for professional engineers, you know, the people designing bridges, tunnels, heavy machinery, aircraft, spacecraft or medical instruments. When something happens and they can't show that their work adhered to the generally accepted best standards at the time... they're held liable. And sometimes, that liability includes jail time, particularly when people are seriously injured or die.
And how it is sustainable? Simple: legal requirements that force managers to allot enough time and tooling to their engineering teams, because engineers whose professional license is on the line will rather quit than be forced to sign off something that is unsafe.
In the software world, this might result in AI not being used at all - simply put: no matter what, AI in its current form is always going to be vulnerable to in-band attacks, or to use an older term... phreaking [1]. It might result in software having to go through formal proof programs, fuzzers, whatever. It might result in entire programming languages just being outright banned in production code in favor of programming languages that eliminate entire classes of vulnerabilities.
And before the usual "but China/India/... would outcompete us" complaints come... well, have you ever seen a Chinese widebody airliner in Western airspace? No. Because China is not able to pass over the engineering gates we have set in place. We could easily do the same with software.
Requiring at least some sort of quality gates on software would not be bad for you as a programmer. Quite the contrary: it would hand you power over your incompetent beancounter boss.
I think the problem I see with your argument is that people simply do not value reliable and secure consumer software as much as they'd value reliable and secure airplanes.
Of course, software that is in charge of things where people value security a lot, such as the software in airplanes, is much more scrutinized and adheres to better standards. This is the case precisely because when it goes bad people die in ways that attract a lot of attention.
You can't enforce those same policies on most consumer software because people consume it the same way they do food. You can have Michelin starred restaurants with the best practices but most people can't afford to eat there so instead they will buy hot dogs on the street.
The idea of "high quality hand crafted artisinal software" is closer to luxury products than it is to the engineering of planes, trains and bridges.
> You can't enforce those same policies on most consumer software because people consume it the same way they do food.
The government can. GDPR was an attempt in that direction, it wasn't enough of a hint to software developers, that's how we got the Cyber Resilience Act that's beginning to take first effects in a few months.
> Whose engineers developed MCAS? Were any of them held liable? Are any in prison?
Given that Boeing had been granted wide leeway to audit itself and write its own standards... the engineers couldn't be held liable and the corrupt US government dropped the corporate case [1].
So, the supposed code of ethics that would have applied to these "real engineers" did not stop them from designing and implementing a system that violated aeronautical engineering principles in several ways.
At my company someone has introduced an internal tool that should help understand and give a "score" to design documents from teams.
Needless to say, this tool gives scores exactly like the article mentions. Same document, same LLM, same prompt, and different results. It becomes even more ridiculous once you switch to other models, or if you ask a model to review the work of another model.
I am not sure why we insist on making LLMs do the work they are not supposed to do and/or in a way they are not supposed to do.
The worst part is that people are aware of the problem but they just ignore it and consider it as "a reference number, just to have an understanding".
If it were like that, it would be less of a problem. The issue comes from the fact that eventually someone without enough knowledge will trust the output (so X points out of Y is how it is), or someone will stop challenging the output and consider it for their process - like in this unfortunate case of hiring.
At a certain point, people who don't know what they are doing give a tool that doesn't know what its doingto people who don't know what they are doing. A pure mess. And everyone has to comply and applaud. If you go against, you are against AI.
This is what I hate the most about AI. Not the tool, but the shortcuts we're willing to take to justify its existence.
I am not against AI but putting automation tools is in a different category than "AGI, you only need specs and they do the work for you".
20 years ago even with automation etc you needed armies of people to make something work. It was more of a transformation of the type of work. Look at the amount of work Amazon as a company has created. It changed how people buy stuff etc, but behind the scenes there is always human workforce, to deliver, to invent the recommendation algorithms, to package the items, etc (although here there is heavy automation).
Now the idea is that we need AI so we can replace humans, so "people can spend more time on what they like to do". Which is what, searching for jobs on LinkedIn?
Amazon have gone back to having senior engineers review all code before production. Don't believe the hype about AGI when your own eyes have seen how fast the Tesla self-driving progress was until it almost hit a wall a few years ago.
This is true, but security teams often work on tooling dedicated to reduce the n. of CVEs so that a company can keep compliance. That is in fact part of compliance itself to have an automated/reliable processo to tackle CVEs...
Not as a metric, but it basically becomes one, like with Fedramp.
You need to fix also moderate/low CVEs within a certain time frame.
So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is.
It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed and new ones discovered), but more like "a few exceptions".
PCI doesn’t mention cve by name but does require vulnerability accounting and requires action if they are found, the action required driven by severity. I could see a (poor) control being written around keeping counts down.
I've met good auditors. I mean, I've met terrible auditors too, but the good ones stick in my mind more because they ask insightful questions about my software or sometimes software in general. It's a problem that this is often seen as a box ticking exercise, done right it can be a really great opportunity to improve but so often instead the priority is to get the paperwork done and too bad if you achieved nothing by it.
If we're talking about actual auditors, not tech consultants who call themselves auditors but people actually trained as auditors, I'd take it as a bad sign if they asked a bunch of specific unbidden questions about software details. That's not the job.
The specific example I'm thinking of most strongly is when we were purchased one of the auditors looking over our software noticed that unlike most of the big company's other software at that time (about 2012) ours was HTTPS-only. Their checklist told them they need only to check there's HTTPS for authentication pages, and they asked if that's actually enough, is it fine if everything else is just plain HTTP as they've seen elsewhere and as their checklist asks?
I of course said it isn't, because as we both know, it isn't.
"That's not the job" is I think the most useless possible observation here. The best outcome from audit isn't that you checked all the boxes, that's just resources expended for no benefit, the best outcome is that audit found a nasty problem early so that you could fix it now. The biggest problem we have in the Web PKI with auditors is that they'd so much rather tick boxes than tell their client - who they are billing $$$ - where the problems are. This presumably feels good to the suits, but if there's a problem and the auditors don't tell you the chances are somebody else finds it and then you're in worse trouble.
No, I mean, it's literally not the job. An auditor reconciles controls against reality. A "security auditor" parachutes into an environment and tries to flag as many security issues and gaps as they can find. They're very different jobs.
But that's not a wrong approach. First you want to as many vulnerabilities as you can, than you want to fix as many as you can. If you rate the developing department for that, that's another story.
In my experience it is becoming basically ridiculous that we disallow compliance based on a number of cve, their level, etc. It's just a checkbox, but it has nothing to do with security.
I'd like to know how a "critical CVE running in your software for 29 days" is acceptable from a security standpoint. With nowadays tooling, these AI agents can take you down in no time if they target you.
Compliance the way is done today is basically outdated, but everyone has to follow these rules to sell software basically.
So lets take some recent examples from the sprawling systems my team looks after
1. There's a "critical" severity security issue because we have an obsolete version of some Perl library on a machine that's exposed to outsiders (ie has a public HTTPS website)
1a. The perl library isn't used by any of the software running on that machine, it's presumably either left over from software we no longer use or it was installed to run somebody's one-shot Perl script, possibly years ago, maybe even for a prior incarnation of that system, with the present one installing that library because it's just easier than figuring out which libraries are still needed...
1b Severity CRITICAL. Actual threat: ZERO
2. .NET 8 is obsolete, machines with the .NET 8 CLR are flagged as insecure.
2a. .NET 10 isn't obsolete, that's still supported, in many cases the exact same code, re-compiled with a 10.x version not 8.x was shipped by Microsoft. Is that true for all the cases we care about? Nobody knows, nobody is even interested in working out. Flagged instances will be turned off if they're not fixed so "just" fix it. Busy work.
2b. Severity HIGH. Actual threat: Unknown, possibly negligible?
As with Mythos these "AI agents" which can "take you down in no time" can't do the impossible, this isn't a Hollywood movie, mumbling about AI and critical severity CVE doesn't turn that Perl library nobody was using into an actual threat.
If the code is unreachable is obviously not a threat, Mythos or not. Can you do this analysis for all your 200+ services, libs etc?
This is the main issue about compliance nowadays. In a fedramp scenario you would very likely have to prove that it's unreachable, and you might even risk compliance over it.
From an attacker perspective they don't know the lib version you're using, but bruteforcing / finding patterns faster than a hacker can? That's what I believe AI can do. This is why for me CVEs are a useless metric, the number and/or criticality. It's a simple security control but they are giving it so much importance. Then you "forget" to secure access to your mcp server and this leaks company info, but hey, zero CVEs, soc2 compliance check check check.
I think it's a good practice to fix as many CVEs as possible, to have a clean/updated codebase, but I am of the opinion that if someone wants, with the tools they have nowadays, they will find a way in. Of course, using a lib that has obvious security issues for input validation, for example, should be a no-go. However, we're reaching a point of ridicule (like you said above, a critical CVE but unreachable).
Yep, at work my team's vulnerability dashboard constantly shows hundreds of critical and high vulnerabilities. Fortunately/unfortunately, 99% of these issues are for Javascript dependencies in websites that are not server-side rendered... so we look bad, even though we have no exposure to most of these vulnerabilities.
Just yesterday I made myself a NuGet package analyzer tool -- okay fine, I vibe coded it -- that has convenient buttons for filtering out client-side packages, test projects, and dev-time tooling like Aspire.NET.
There is evidence of a lot of ugly diseases caused by this, without even mentioning the constant 40+ dB background noise.
reply