> There seems to be a desire for a narrative that AI really just can't replace productive work, and that it's all a mirage.
Yes, and juniors aren't known for their productive work in the beginning. That's not their purpose. Their purpose is to do the mundane work, because it is important for them to become less junior and more senior.
That is robbed of them.
Which in 5-10 years means the need for senior developers is gonna shoot through the roof.
> All the software engineers we need for the next 20-30 years are already in the current workforce.
There's no way of knowing what the industry will look like decades from now. Even assuming the prediction that seniors become 10x more productive, that would mean software becomes much cheaper to produce. Does that induce enough demand for additional software that keeps employment levels high? Could be, who knows.
Alternatively, maybe software hits a saturation point where there just isn't as much new ground to cover and employment levels crater. That could happen too.
This was the case in Belgium a couple of years ago.
Everybody had to go to a store and have their ID read by the system, and if they didn't, the phone number would be shut down.
Unsure how that worked for MVNOs though.
Now I live in the USA and am well-familiar with the spam calls. I wonder if this new rule will reduce/prevent them. I think in general the ability to spoof numbers should be banned / controlled. Someone from India should not be allowed to call me with a caller ID from Mayo Clinic.
> I think in general the ability to spoof numbers should be banned / controlled.
This has absolutely nothing to do with burner phones and the proposed changes won't do anything to change that.
~5 years ago there was a big push (in the USA) to try and solve it with STIR/SHAKEN but I've not been involved or paid attention since then, so don't know if anything came of it. It's a legitimately hard problem to solve though. Lots of engineering and backwards compatibility technical problems, but also political, logistical and commercial issues are abound. You've also got some turtle issues too; it's attestation all the way down.
> This has absolutely nothing to do with burner phones
That is not correct. There a phone farms operating purely on burner phones / disposable sims.
Even for legit use cases, this path is often way easier/cheaper than go through official channels.
Use cases range from carrier-NAT proxies at < $1 per GB to text message spam.
But... what does your comment have to do with burner phones?
A burner phone is a phone number whose owner is not officially registered somewhere as the owner.
A spoofed phone number is a false declaration that you're calling from number XXXXXXXXXX when in fact you're calling from YYYYYYYYYY.
You might notice that there is absolutely no relationship between these two ideas. You can be registered and lie about your phone number. You can be unregistered and not lie about your phone number.
>>> I think in general the ability to spoof numbers should be banned / controlled. Someone from India should not be allowed to call me with a caller ID from Mayo Clinic.
>> This has absolutely nothing to do with burner phones and the proposed changes won't do anything to change that.
> That is not correct. There a phone farms operating purely on burner phones
This is total nonsense. A phone farm that doesn't spoof caller ID isn't presenting false caller ID.
Wish I could recall the podcast I listened to a few years ago that was telling the history of robo-dialers and caller ID spoofing. The general gist was that AT&T was making money off it from 1-900 operators so they weren't eager to self-regulate. So even though ending spam calling is a bipartisan issue, feet were dragged on the implementation.
If anyone's eager to do podcast archaeology, IIRC one of the angles was investigating dead government agency phone numbers, and some lady entrepreneur in the 80s. Might have been Reply All, but the market regulation angle makes me think Planet Money.
of course, politicians exempt themselves from the spam call category. Political speech is the most important speech!
Probably not the issue isn't knowing who owns a number it's that the actual number for the call is just a data field that's not validated or required to be correct. Spam calls would be a lot less annoying if they had to come from real numbers that could be blocked instead of being able to spoof as many numbers as they want.
Spam calls are a different issue (spam is usually VOIP). Spammers also often use spoofed numbers since STIR/SHAKEN is somehow still not properly implemented.
I just asked Siri a few weather questions and named the city where I live, nailed it. My favorite digital device is my Apple Watch and if Siri improves over the next hear or two, that will be great for me.
And I am absolutely sick of having to justify my job against people who feel they can now vibecode an application without understanding the code.
Kinda like how someone thinks they can build a house without understanding the different layers.
And it's made worse that the way these applications are now built: from the outside, with zero regards towards how it's actually put together.
I understand that execution speed matters over elegance of code. I'm not looking for elegance. I'm looking for code that is clear, well abstracted, well reasoned, so that it not only serves the business purpose, but is also technically sound, non-DRY, with clear indicators of where YAGNI was invoked etc.
I'm genuinely tired of having to defend my job. And the world is using the AI revolution to get rid of so many people. When you call 911 in my city you now talk to AI. You call the local dealer, you get AI.
So AI is presented as this 10x modifier, but I'm not working 1/10, I'm working the same if not harder to verify my PM's slop, because it's me who gets paged at 2PM, not my PM.
You can use LLMs in multiple ways, from very hands on to make local changes to completely hands-off.
I've seen plenty of code that was LLM generated but the commit message itself did not have the co-author attached to it. This only seems to happen when someone's interface to the codebase is completely though Claude/Codex/..., and those are usually the most verbose commits, and yet they say the least, because they just summarize the code changes, not the why.
On the other hand I've seen developers using Claude as a tool. They have VSCode open and a terminal window with Claude and go back and forth, ensuring they write correct code, and leave the plumbing to Claude.
So maybe the author of the code started off small and it grew over time?
I would expect a mature code base like rsync to have a lot of unit tests and integration tests and frankly if there's not enough that such bugs haven't been caught; that should be your first use of LLMs in order to setup some deterministic guidelines when you do start making changes to your actual code.
I have been experimenting with both aforementioned styles with interesting results.
> I would expect a mature code base like rsync to have a lot of unit tests and integration tests
You might be surprised. C applications which interact heavily with the system - like rsync - can be tricky to test comprehensively, as it's nontrivial to inject faults into system calls. If the application is architected to support this kind of testing, or uses a HAL, that may make matters easier - but an older codebase like rsync probably isn't.
reply