Just like it does when given an existing GPL’d source and dealing with its hallucinations, the agent could be operated on a black box (or a binary Windows driver and a disassembly)?
The GPL code helped here but as long as the agent can run in a loop and test its work against a piece of hardware, I don’t see why it couldn’t do the same without any code given enough time?
Presumably one would like to use the laptop before the million years it would take the million monkeys typing on a million typewriters to produce the Shakespearean WiFi driver.
Consider that even with the Linux driver available to study, this project took two months to produce a viable BSD driver.
Seems very promising but then you realize the LLM behind said agent was trained on public but otherwise copyright encumbered proprietary code available as improperly redistributed SDKs and DDKs, as well as source code leaks and friends.
In fact most Windows binaries have public debug symbols available which makes SRE not exactly a hurdle and an agent-driven SRE not exactly a tabula rasa reimplementation.
Your ISP will cut your account when you saturate the upstream pipe 24/7 for weeks on end... which will only happen if you host video.
And your home insurance will not know/care if you're operating a desktop-sized computer or even a single server (it is perfectly fine and expected a developer might bring an actual server home for troubleshooting). Home insurance only cares if you're running dozens of them.
> Perhaps someone at their end screwed up a loop conditional, but you'd think some monitoring dashboard somewhere would have a warning pop up because of this.
If you've been in any big company you'll know things perpetually run in a degraded, somewhat broken mode. They've even made up the term "error budget" because they can't be bothered to fix the broken shit so now there's an acceptable level of brokenness.
The orgs are not ruthless like that, anything less than a certain % of the org revenue is not worth bothering unless it creates _more_ work to the person responsible for it than fixing it does.
Add some % if person who gets more work from the problem is not the same as the person who needs to fix it. People will happily leave things in a broken state if no one calls them out on it.
In my opinion, if something isn’t actually an error, you modify your logging to not log it as an error. Your error logging/alerting pipeline should always stay clean.
If something shows up in there, you should only have 2 options: 1) it’s an actual error and you fix it and make sure it never happens again, or 2) it’s not an error and then you fix it by adjusting the log level to make sure it isn’t one.
If someone suggests an “error budget” on my watch they get the door. You can have a warning budget (and the resources to adjust the log levels or remediation protocols to fix said “errors”) but actual errors should remain errors - otherwise they’re delivering broken software and that’s not what I’m paying them for.
Of course, companies who have the common sense to do this already do it and nobody in their right mind would suggest an “error budget”, but for those that don’t they have a serious problem that needs to be rectified.
The danger otherwise is that you’re making your observability pipeline useless if “errors” no longer actually mean errors. That’s really bad because now it opens the door to actual errors being ignored until it’s too late and then remediation is more costly.
At Facebook a full outage is accompanied by "first time?" Memes. Unless you are on the specific team responsible you would indeed not really have any reason to care
In my 3rd year of enterprise now and learned that there are many engineers who will purposefully not fix/improve their problematic applications as a weird sort of job security. It kind of blew up in their faces last year when we moved most of the affected on-premise applications to cloud. Seems like when you introduce tons of friction on-premise it makes the cloud look even better to the suits.
It's not a matter of "can't be bothered." Engineers are constantly fixing things and rolling out new features. "Error budgets" are an acknowledgement of the tradeoff between these two things, and making a conscious choice about the balance between them, according to the business requirements of the application in question.
Keep in mind that "fixing things" is essentially a Sisyphean task - no matter how much you do there's always more you can do. Just like adding features. You have to have some kind of guideline on when enough is enough.
> the maximum fine for this is 4% of last years total revenue or 20 mio €, whichever is the larger number.
The maximum fine wasn't even achieved by Facebook, after years and many blatant GDPR cases. Do you really think someone is getting a fine for not replying to a subject access request in due time? If so I have a very good bridge to sell you, and that bridge has more probability to exist than Amazon getting any kind of GDPR fine for not acknowledging a SAR.
The badge could (I don't know, haven't done it yet) help you differentiate yourself in a sea of monkeys slinging ChatGPT'd profiles from a third-world boiler room.
(whether it actually does or the monkeys now got a steady source of fake/stolen IDs is another matter)
EU GDPR has very little enforcement. So while the regulation in theory prevents that, in practice you can just ignore it. If you're lucky a token fine comes up years down the line.
Are you saying that you reuse the same password everywhere, but a different email address every time, and you feel confident that having your password leaked won't have repercussions?
I am genuinely confused. Sounds like holding a gun from the wrong end and feeling protected by it.
My advice is that there's a big difference between "software engineering" as a career where you're employed by companies and "software engineering" where you're delivering solutions for yourself or clients.
The career track feels like it's being obsoleted by AI/LLMs, and that's because a lot of the work is either genuinely superfluous and not actually needed, or rote memorization (where LLMs indeed excel at), or are a sign of over-hiring during the pandemic and even earlier during the ZIRP era and AI/LLMs are merely a convenient excuse to lay them off. Technically-speaking the career track still exists but it's saturated, so let's assume it doesn't anymore.
The "problem solving" track is nowhere near obsoleted. LLMs can be used to automate away typing, but unless it's a specific task where you already expect to do a lot of typing, LLMs (from my experience) tend to produce worse results than just writing the code yourself directly. So software engineering expertise is still valuable.
The career track is threatened for several reasons:
* the hiring market is outright broken (I'm hiring and feeling it). Any job posting is going to be flooded with monkeys (or agents) slinging ChatGPT'd resumes left and right, which are indistinguishable from genuinely skilled candidates. There is no way to tell them apart short of interviewing them, which is difficult when a job posting is going to be DDoS'd with 1k applications a day. And even the interviews themselves are fraudulent - candidates using LLMs and screen-capture/speech recognition to answer the questions, or outright outsourcing the interview to a skilled person, but the actual candidate is a monkey that doesn't know how to print a hello world. This doesn't mean the demand is reduced, but the hiring is happening behind closed doors with people referring other people they already know and trust, so it's impossible to get into for a new entrant.
* A lot of "software engineering" jobs were genuinely just rote typing with little agency. The frontend sphere is especially affected - not surprising because a lot of "frontend" was just trying to reimplement native browser behaviors that were perfected 2 decades ago and could be invoked with just HTML if only the architects had the pragmatism of settling on a mixed "static HTML for the boring bits, and React/$JS_FRAMEWORK_OF_THE_DAY for the interactive stuff".
Now, what do you want to do?
* you want the career track? Well the issue is that a lot of the rote typing stuff (which nevertheless yielded many six-figure jobs just a few years prior and helped push software engineering from a nerd thing to a mainstream easy-money career) is going away, so it's probably not gonna happen. And the genuine roles are hard to get in because the hiring market is both broken and saturated from all the layoffs.
* you want to build products? That's still valid, but requires a different skillset (which includes marketing yourself). There's just as many clients who need pixels put on screen (if anything, there's even more now that LLMs allow any non-technical founder to prove product-market fit using a vibe-coded prototype before committing to an actual production-grade codebase), but the skills required are different.
On the second point, you need to have an end-to-end understanding of the stack to succeed. Not super specialized, but you need to be able to go from the pixels on the screen all the way to the server (databases and stuff), networking and all the way to interacting with any third-party APIs you might use (do you know about idempotence and the CAP theorem? Well if not an LLM can elaborate and make you learn it, but as you can see you still need an initial understanding to know the right questions to ask).
LLMs are actually a boon in this case - they're like your own personal tutor and senior colleague you can ask anytime anywhere. But you still need to put in effort to build and refine products and you'll learn over time.
My advice is that software engineering (and generally being good with tech/computers) is a superpower that can greatly help you in your existing business. As freelancing, it can work as long as you have enough skill (even if LLM-assisted) to deliver things someone will actually pay good money for. But purely as a career track (without a direct, profit-supported deliverable tied to it), it's dead, and LLMs aren't even to blame, they're just a convenient scapegoat to get rid of all the over-hired employees from the ZIRP era.
Good luck. Email in my profile if you want to chat further - just don't expect any miracles, I don't have any particular good news for a junior, and even for seniors it's really difficult right now.
Just like it does when given an existing GPL’d source and dealing with its hallucinations, the agent could be operated on a black box (or a binary Windows driver and a disassembly)?
The GPL code helped here but as long as the agent can run in a loop and test its work against a piece of hardware, I don’t see why it couldn’t do the same without any code given enough time?
reply