notnullorvoid

No. I think it'll mostly cause a dip in the average intelligence of knowledge workers.

We will recover when we realize the valuable workers in a field are the ones who want to be there and actively increase their knowledge rather than offload work.

> has me questioning how much longer I want to remain in the industry.

It's not a bad time to take a break from it. Keep yourself from cognitive decline, then in 2 or 3 years when the industry has come to its senses you'll be able to impress in a sensible interview. Compared to the slop addicts that won't know how to tie their own shoes without asking Claude each time.

It'll only get worse unless companies start having strict policies around it, making repeat offenses fireable. Juniors should have a little more wiggle room, but there's no excuse for senior engineers to participate in such carelessness.

This is the kind of thing that spreads. If you have to deal with it all the time you're going to start dissociating out of necessity.

> The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.

It was/is a struggle to get them to recognize and balance tech dept, we must now push to balance cognitive dept as well.

Some employers will eventually get it as they have with tech dept. And those will be the ones we see succeed.

> that makes me wonder if the trillion dollar valuations for OpenAI and Claude are even justified.

They aren't, not even if we forget about the capable Chinese models.

I suspect Anthropic will implode soon when employees are unable to get the cash-out that they expected. Having so much compensation locked up in company stock is risky on a good day.

Models can be trained with seperate contexts for these things, but the companies with all the resources are so focused on racing to AGI and "scaling laws" that they don't actually care about research into fixing security risks. Fixing those risks would even negatively affect their marketing.

If you look at the data 25% of the people who reported attempting a task without AI did not complete it. Seeing as the time spent on AI tasks was not that much higher than the time spent on completed Non-AI tasks, I suspect it was less about unwillingness, and more about inability.

We should really be studying AI related cognitive and/or skill decline more heavily.

Have you looked at the raw data of the follow-up? It doesn't paint a pretty picture, many tasks attempted but not completed, refusal to attempt without AI, higher overall estimates and completion times than the previous study (both for AI and Non AI).

There's no definitive conclusion about productivity that can be drawn from the followup. However I think it's reasonable to argue that AI use overtime has made devs worse without AI.

> One thing I've noticed is, that coding manually is exponentially more stressful than the slow AI approach.

I find the exact opposite. Typically the AI will make too many mistakes (even with latest advanced models), they usually aren't major/program breaking mistakes, but they still require fixing if I want to keep the code quality good enough, and make future changes possible without a falling house of cards. In order to describe the correct approach I have to write more English to describe the problem than the amount of code I could write myself. I could maybe see it working by writing rough pseudo code and having the AI translate, but then I loose out on any code analysis or tab completion as I write. It's also just innately frustrating to have to babysit and correct somethings work all the time. This all may be in part caused by the nature of my current work for the last couple years, which has mostly been on library code rather than application code.

I suspect I'd have a very different experience if I was working on CRUD related tasks like making new API endpoints, interfacing with a DB, or writing FE components. Not to make light of those tasks, I enjoy that work, though it is much more repetitive.

I agree with the parts about using AI to ask questions and gain better understanding though. I do that constantly for APIs and languages that I don't have a clear mental model of. It's like an interactive search.

Also agree on POCs, sometimes there are small tools, demos, or prototype features that I don't need to care deeply about.

People pleasing is a component for some, some also like the technical challenge. The biggest factor though is that as a software engineer "No" is basically never an accepted answer (even from management with an engineering background). They'll either counter with "we need to do X, so find a way", or they'll move along the line to the next person until they get an answer they were looking for.

Edit: There are some rare competent managers who will stop the enquiry before even asking the engineers.

> So their survival rests on the presumption that AI progress will fall between these two extremes.

That feels like a very generous framing. There's very little opportunity between the extremes that would paint a convincing outlook of survival for either company.

Perhaps if they were able to scale down their spending drastically they could survive, but that requires acknowledging their current valuations are BS. Doing so is a major risk, that will piss off all share holders. There's also the employees they would need to fire or reduce salary. The shift of focus internally to sustainability would be a major challenge.

I dislike their practices, but the main motivation for hoping they'll crash is that I think their immense overvaluation posses too much economic risk.

Always nice to see more open-weights in the heavy model class. I can only hope this trend continues, causing OpenAI and Anthropic to crash and burn.

I wouldn't be worried so much about those examples. One could take the open weights and fine tune them to either fix the poisoning or omission of obvious topics.

It's the subtle topics that we should be concerned about, and double so with closed models where even if oddities are identified they are harder to research further and impossible to fix.

I mostly agree with the prediction though maybe a bit more pessimistic about the timeline. Also I'm not sure our current usage of parameter count would make sense in this scenario, such a feat would require compressing current parameters in a manner much different then something producing a bit count per parameter. A hypothetical example would be using a single seed parameter per layer which then passed into a noise function produces the functional weights for that layer, able to reduce per weight size to sub bit levels (256 bit seed, producing 16K weights).

The Google Play store did (maybe still does?) allow installing some PWAs advertised as light versions of the apps.

On desktop or on mobile?

On mobile it's rare for apps other than web browsers to allow multiple tabs/windows and the ones that do (Ex: Gmail allows a draft to be a second window) have many multi window related bugs.

No defense for not writing or reading code if want to call yourself a software engineer or programmer.

However I do think there is reason to use Java or Python (as much as I loathe both) they have GC, and it'd be a lot easier for AI to fuck up memory safety in something like assembly or C.

Neither is mutually exclusive.

They get lock-in, and through that lock-in are more effectively able to inflate token usage.

If China is able to undercut Nvidia on high performance local AI hardware, they will pop the AI bubble in a matter of days.

They wouldn't even need to make something equivalent to the latest hardware. A Chinese RTX 3090 equivalent would be enough.

I think all 3 are pretty important for using TS in online sandboxes and IDEs.

Performance of tsc wasn't an issue for small projects, and for larger projects it could be fixed by using incremental build option, and/or TS project references. Most either didn't care enough about the perf or were too lazy to set it up. TS7's perf boost will give people less of a reason to use these options.

Boolean attributes are less about types and more about syntax convenience IMO, even HTML treats them as empty strings. <tag attr> is a shorthand for <tag attr="">, which then in your program you can decide if some attributes should handle empty strings as a truethy value. Some cases like <person name> the program would still make sense to treat it as an empty string.

> If HTML 5 is indeed not even used directly, that makes the argument for the _stricter_ format like XML-based XHTML even more attractive

True however those who control the HTML spec are unlikely to let it go. Since XHTML has been treated as effectively deprecated some feature like incremental document streaming do not work in XHTML, this makes it unlikely for libraries that abstract away HTML to adopt XHTML as a target.

I'm going to choose to look at this in a positive light. In the long term this talent will feed into more indie games and studios, and perhaps studios will be less inclined to get acquired by Microsoft and other big orgs going forward.

Much of the gaming industry outside the indie space has stagnated, making sequels that don't offer much outside of slight increases to graphical fidelity and the odd thematic switch.

Meanwhile valid XHTML like having custom elements as table children, in HTML gets silently "corrected" to an malformed document.

I'd much rather have the stricter syntax parsing of XML, vs the complex and outdated structural correction rules of HTML.

The one good feature of HTML 5 was the introduction of boolean attributes. It's a feature XML could and should adopt.

The whole handling of custom elements was fumbled beyond belief. The HTML spec is a disaster particularly it's parsing rules the complexity of which is used as excuse by HTML spec authors not to improve the language.

XHTML was a better path.

I think the reason we don't see too many people complaining about HTML 5 is because not many web programmers use it directly, most are using JSX.

It bothers me that these popular UI toolkits render copious amounts of divs. I went to look at Base UI and for nearly every component it's "Renders a <div> element", when there are native elements that can achieve the same thing like details/summary for accordion.

I'm far from a native web evangelist, I think there's a lot the web APIs especially HTML gets wrong, but div overuse is also wrong.

I've yet to update to Android 17, but I ended up disabling haptics on 16 because the annoying pop sound feels like a gimmick compared to what haptic feedback used to be.

I run podman for local dev containers or for isolated sandboxes mostly. Anything needing orchestration and I go straight to k8s, never liked docker compose.

I hear this argument all the time, but I've always found it lacking connection with the human behaviour I observe as someone growing up low-middle class, now middle-upper class.

It completely misses the mark on human behaviour of those living in scarcity. Inflation forces them to save whatever they can in the most stable and liquid medium (cash). As a result it creates a very strong force pushing low income individuals further down, it takes a lot of hard work and luck to get out.

Those with enough wealth don't need the same liquidity or stability, they have the luxury to invest and see their wealth grow and outpace inflation. As a result of this security they are more willing to spend on products and services.

Inflation causes scarcity for the poor and security for the wealthy.

The lower inflation is the less scarcity for the poor, and they will be more willing to spend and invest. Even in a environment with 0 inflation the wealthy still have incentive not to hoard cash. The incencentive to invest was never about the devaluation of cash, but rather the outpacing return of value that investment brings. Theoretically that still exists even in a deflationary environment, though I do suspect high enough deflation would have drastic negative impacts on the market to the point where returns are too low to justify the risk.