It's a self-solving problem, though. At that point, every remaining senior+ engineer will be paid a bajillion dollars (like they are now) and companies will start to invest in actual training.
What makes a vulnerability saleable? Is this one not valuable because the government clients of someone like Memento Labs don't care about a MITM attack on desktop computers?
Generally the vulnerabilities you can sell for money are ones that somebody can easily use to make money, as part of an existing money-making scheme they have.
If the vuln can’t be used to make money, or the way it makes money requires that a criminal enterprise make up a whole new set of workflows, it’s not going to have much of a market.
Accelerationism is an established political philosophy. Why is it obvious that they are insincere when they could equally think that the only way to control it is to be the ones building it?
History has shown over and over that that strategy is doomed to fail - see communism, nuclear energy, or meddling with the Middle East for some arbitrary recent examples.
For me it feels less like filling out reports, and more like mentoring an intern who can search for stuff really quickly but forgets everything at the end of the day due to anterograde amnesia.
Except the intern is trapped inside an iron lung and must communicate entirely by text. And also has zero real creativity or self-motivation.
The one time I worked at a large corporate, my time was split between failing to find useful projects that I was allowed to work on, and failing to deliver much on the useless projects I was given because I didn't understand that it would e.g. take six weeks and two review meetings to provision an extra half a terabyte of storage on a db cluster.
I eventually worked out that the bureaucratic red tape was a hurdle rather than a deliverable and everyone else on the floor was dodging it. I'm still not sure why they hired me then put me on a team with no work in the funnel and a scope too narrow to make my own work, though I was grateful for the ridiculous pay.
Sometimes teams get a req to hire someone and it’s use it or lose it. They’d rather get someone in the seat that will hopefully be useful at some point, and simply retain or grow the team size, than to give it up and be short staffed down the road.
Why would it be weird? My grandmother dreamed of being a school teacher, never did it, and talked about it until she died. The closest she ever got was teaching Sunday School for a few months.
It's common to have a dream and do nothing concrete about it. That's part of why we call it a dream. Sometimes it's less about the thing itself and more about the unfulfilled and unrealistic expectation.
I "hate" AI[0] because I believe that elegant code is a different bulding material to ugly code. Ugly code is harder to change. At some point, it becomes impossible to change.
I notice that a lot of people say they'll be able to write 2.0 faster than I can write 1.0. This means that their 1.0 must have been so bad that they had to rewrite it. Why, then, would their 2.0 be any better? Because they got some feedback? At some point, your users are just going to leave for a competitor.
[0] Meaning I use it, think it's neat, and will continue to use it, but would prefer to use it a lot less than my boss wants
> I believe that elegant code is a different bulding material to ugly code. Ugly code is harder to change. At some point, it becomes impossible to change.
I believe the same thing and it’s also the main reason I hate AI code.
AI tends to not have much regard to “architecture” or even really considering how code should be organized. Need a function to read a base64 string into a private key? “fn base64_to_key” right there next to the code that needs it. Need to take that key and encrypt a blob? “fn encrypt_blob” right next to it. No thought about maybe pushing that code to a crypto module, or representing the invariants as types, or even just putting the functions where they might logically belong, just spews them out everywhere.
But, I have a problem trying to prove why this is an actual problem in the end product. You can say “it’s harder to refactor later” but the LLM is already pretty good at just changing bulk amounts of code to behave differently. In fact, having utility functions “nearby” the code that needs it might be better for its own context management. Most of the reason humans prefer the “single responsibility principle” and “modular design” are to make the code easier for us to change and reason about, but an LLM with a finite context window may actually do better with code that doesn’t match this premise.
I find myself reviewing code that others on my team generated with an LLM, and I tend to focus on these sorts of architectural “problems” the most because it’s the biggest gap between the way I program and what the LLM executes. But sometimes I worry that I’m fighting a losing battle, and that the focus on good architecture isn’t as important as I think it is. Or at least, I’m having trouble proving that it actually matters tangibly. Will it result in an unmaintainable mess? Maybe. It’s not guaranteed that LLM’s have the same limitations we do when it comes to maintaining code.
It's a useful construction. "It's not true love, you matched with her on Hinge last week and have never met her, please don't send her $1000 in Apple gift cards" is punchy.
reply