joshAg

You're right that as a person moves into management/staff+ that individual details matter less for them, because they begin to deal at a more strategic or operational level, but someone still needs to obsess over the small details (to make things easier, let's assume we're only talking about the details that actually matter and that there's broad agreement what that set is). It's not that those details stop mattering to them, it's that they have to depend on the assumption/promise that someone else is going to mind those details for them, so that they can work on things with a broader perspective.

The problem comes when no one is actually minding those details anymore. If those details aren't actually minded, then the work at the higher levels will be much less useful and effective, and in the worst cases won't matter at all.

It didn't seem like it, because section 2 directly discusses the issue you raised and why individuals aren't in a position to adequately prevent deskilling on by themselves. OK, you disagree with it, but you don't even engage with the actual argument it makes.

I don't personally like LLMs for research assistance (yet?) because i can't get over the hallucinating or rather, waste too much time validating that it's not currently overcast when they tell me the sky is in fact blue.

But, especially as code gets flung over the wall faster and with less care, I do think they are getting to be pretty great at reviewing code for specific things that a linter can't easily catch and for looking for security, implementation, and architectural flaws before I have to look for them. A couple examples of what i mean: 'does the code use knex.raw with a template literal?', 'does the code do n+1 db lookups instead of something better?' 'do all the added/modified tests follow the test case template defined here?'

> According to the empirical literature on deskilling, automation bias, and skill decay, many professionals rely on artificial intelligence much more than is necessary when it is available, and the effects of such overreliance on skill decay are unlikely to be entirely understood by the professionals themselves. I argue that this – what I call the insidious nature of deskilling – supports a normative view, according to which the responsibility for tackling deskilling should not be ascribed to the individual professional but the risks of professional deskilling should be tackled by the professional community instead. Mitigating the risks of deskilling should start from an intra-field analysis of the core skills of the profession that should not be outsourced to artificial intelligence. Then, the individual professional would not be left alone to determine how and when to prevent deskilling during the adoption of artificial intelligence within her profession.

You're lucky. Every single person (n of around 10) I've been unlucky enough to review code for lost between 0.5 and 3 promotion levels of competence when they started using LLM code generation, and it's been worse for the better programmers because they have more capacity to lose skills.

My personal "favorite" was when the lead engineer who onboarded me half a decade prior forgot the written policy he'd put in place of "no raw js dates. use this library for everything date related instead" and sent up an MR that not only used javascript dates, but did complex operations on them (incorrectly at that, because it didn't account for timezones, daylight saving, years that had a leap day, and months that weren't 30 days).

From what I can tell, it's the exact same reason people drive faster than is prudent or use their cellphone while driving. It feels safe and good right up until it isn't and you crash. And because most places don't have anywhere close to adequate specification detail, test coverage, or review coverage, the broken bits aren't even noticed until much later.

> But there was never a general principle about scale and automation articulated in the Constitution because it just wasn't a thing to worry about in the 1700s.

> We're left to hope that courts agree that just because something is okay for one police officer in one place to do, that doesn't mean the police department can perform that same task a thousand times in a thousand places with a thousand machines and still have it be okay.

There are multiple court cases that have done this exactly this. Carpenter v. United States and Chatrie v. United States are the ones you want.

Lemon, it's wendesday

those are ada. Don't worry, they'll forget about ada until the defense contractors pay them to remember

Unless the scantron corporation is so antisemitic they invented a time machine to participate in world war 2, I think you mean IBM.

Think of it like a trip.

When you're learning/internalizing existing knowledge, you tread a defined path skipping unnecessary stops and diversion and heading instead directly to the destination. The destination, not the journey, is the point.

When you're discovering new knowledge in the form of proving/disproving, there's no defined path to follow, so there can be quite a bit of backtracking and diversions and detours into other areas you weren't planning on going initially and while there might be some well-defined paths to follow, you might have to cut your own path through uncharted desert or jungle.

All those diversions and detours make the journey just as if not more important than the destination because they create new destinations of their own for future travel that would not have been spotted or noticed for a while longer (if ever) otherwise.

So to bring it back to math, transitioning from having to develop proofs for theorems to validating/learning extant proofs completely changes the scope of future discovery. Everyone will tread the exact same path to a proof/theorem and then stand in the same place to look for future destinations and then use AI to build them a path to that new destination and then everyone will follow the same path to the new destination and repeat the process, so the chances of finding something curious along the way plummets. And something curious could be an entirely new field of math, or maybe just a new problem that isn't relevant to the intended destination but gives a view of many new never before seen destinations for future trips.

As much as it sucks for the ecosystem that's built itself up around the world wide web, good ad blockers and fingerprinting protection are as important as firewalls and antiviruses now. There's no more babies in this fetid bathwater.

cool. I don't want a crime-free society. It's not that I want crime, it's that at a certain point I'd rather allocate government attention/money/time at issues other than crime because the benefit to that other thing is greater than getting crime asymptotically closer to 0.

Mocks/stubs definitely have a smell to them, but especially if you want to do more than just unit tests can be necessary. I've found that setting up the mainline architecture so that components that are allowed to be mocked have a single access path in the code makes it easy to mock at a level low enough that the only thing being mocked is that component and then preemptively building out those mocks into the test framework works decently well. For me, 3rd party services are usually fine to mock, but things like DBs and redis are usually not. I'd rather spend the time to make a test container the devs can run locally so that they can't skip over checks/constraints and the integrations with services/components we have full control over.

That way you can tell at a glance of the test file change just how bad it is. Seeing new raw mocks (eg sinon in the test file at all) instead of the existing mocks is an instant no, and seeing an existing mock getting added requires at least investigation for necessity.