Luckily in my experience it usually ends up only doing it to achieve the task set to it as opposed to anything "malicious", but boy it is scary reading back at how quickly the chain-of-thought pivots to attempts at privilege escalation or searching your disk for secrets when a tool doesn't work.

Most places still interview. Because hiring someone for 3-6 months is still an expense. For large companies, onboarding can take many weeks before you're even thinking about being productive. Interviews don't need to be 100% accurate. They need to be time-efficient and an ok filter to prevent hiring the worst people.

I don't see how a bad job market is going to make skilled people be willing to intern in order to get employment. Employment is a market, if demand goes down, then the reaction will be that price goes down.

The reason students are willing to intern is because the supply is so high and demand so low that you can effectively hire them for nothing (or next to nothing). The interns know that on completion the internship will upgrade them to a new category with new supply/demand. It's the same reason they are willing to pay large amounts for a university degree.

So interviewing will stay the same. If demand collapses, we will see wages drop, and I imagine the supply of software people will react through early retirement, career switching and reduction of people choosing it as a career before we see an upheaval of hiring methods.

And then when you sell your units, hopefully in aggregate the index is worth more than it was when you entered...

Short of a third sigmoid appearing in the ML CompSci space, perhaps in the form of ongoing, repeated step-optimisations which will also have diminishing returns, intelligence growth is now limited a few scaling problems that have already been worked on for a very long time.

Transistors, which have been doubling for almost a century now, but Moores Law has already plateaued and reached limits on energy efficiency, and simply building new fabs is not something that we can do exponentially. And the other growth limiter is electricity - there is no exponential supply of fossil fuels or power plants. Although manufacturing has scaled, PV tech improvements are also plateauing - and while storage is getting cheaper, it's still not economical vs fossil fuels (meaning: when we have to switch to it, the growth slows down further) and we are unlikely to see battery efficiency sigmoid enough to maintain the AI sigmoid.

I don't mean to be bearish here. There's so much money sloshing around that we can afford to put the smartest people, using unlimited tokens, on the task of finding small, incremental gains on the CompSci side of things that will have large monetary payoffs - hopefully allowing further scaling and increased emergent abilities of LLMs. Maybe we can squeeze the algos for quite a while. But I don't see that maintaining the same level of exponential as unlocking unlimited data or maxxing out the world's energy/fab capacity for long.

And I don't see why this is a massive issue except for the people who want to have some god-like super AI? Frontier LLMs are genuinely magic. Not "won't delete your production database" magic, but definitely a massive productivity gain for competent knowledge workers.

But I'm sure the scanning operations will start scouring the earth even harder for any books unaffected by slop containing niche knowledge and text in order for their models to have an edge over the ones trained only on pirate collections and the Internet.

I wonder if secondhand bookshops and deceased estates are seeing bulk buyers of their stock suddenly appearing. Maybe broke governments/municipalities will start selling them entire libraries and archives to ingest.

Managing servers is fine. Managing servers well is hard for the average person. Many hand-rolled hosting setups I've encountered includes fun gems such as:

- undocumented config drift.

- one unit of availability (downtime required for offline upgrades, resizing or maintenance)

- very out of date OS/libraries (usually due to the first two issues)

- generally awful security configurations. The easiest configuration being open ports for SSH and/or database connections, which probably have passwords (if they didn't you'd immediately be pwned)

Cloud architecture might be annoying and complex for many use-cases, but if you've ever been the person who had to pick up someone else's "pet" and start making changes or just maintaining it you'll know why the it can be nice to have cloud arch put some of their constraints on how infra is provisioned and be willing to pay for it.

The culture of corporate IT would need to change to allow it, and I just don't see it happening.

I don't think the problem here is about a bug in Claude Code. It's an inherit property of LLMs that context further back in the window has less impact on future tokens.

Like all the other undesirable aspects of LLMs, maybe this gets "fixed" in CC by trying to get the LLM to RAG their own conversation history instead of relying on it recalling who said what from context. But you can never "fix" LLMs being a next token generator... because that is what they are.

I find the pattern of showing interactive TUI if required options/flags are omitted much nicer than showing an error/help output.

Although I don't think they actually "know" it. This particular trick question will be in the bank just like the seahorse emoji or how many Rs in strawberry. Did they start reasoning and generalising better or did the publishing of the "trick" and the discourse around it paper over the gap?

I wonder if in the future we will trade these AI tells like 0days, keeping them secret so they don't get patched out at the next model update.

And I said the same thing at the end of my comment about the way people would host things using docker on a VPS or home server.

> Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.

And I did say at the end of my comment:

> Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.

In particular, self hosted apps usually are using relational databases or SQLite which need persistent disk so can’t run serverless. They also sometimes require writing to physical disk instead of object storage like S3. Writing or rewriting apps to support serverless when they have no technical need to when self hosting would make things more complicated. Most CRUD frameworks used to write self-hosted apps do not work with NoSQL out of the box.

Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.

I doubt anybody is losing customers over a 1s delay in the till opening or a POS server syncing the day’s transaction after close. But having worked in retail - the one time you get a call from head office is when there’s “loss of trading” - it’s a bigger issue than theft.

I remember there being an entire tourist town that was suffering economically because during peak season, the mobile phone tower was saturated and merchants could not process card payments. You can’t even use click-clack machines anymore with modern credit cards.

Now… working offline is entirely doable in a modern tech stack too - but I somehow doubt most modern POS products support it well.

So you’d assume most people are already dealing with the AWS behemoth.

And if the cloud provider is providing a competing Database as a Service then it’s almost impossible to compete.

Usage will likely be skewed to small companies and agencies though. Just like every framework that optimises for less complexity, the disadvantages start to outweigh the advantages when you have so many engineers you can afford to have backend/frontend specialisation and/or you need to support non-browser clients so you need to build services that transport JSON anyway.

Side note/rant: As professionals, we should understand the limitations of different approaches, communicate them to stakeholders and select something that is appropriate for the task.

The problem is, we seem to end up with evangelism where everything thinks their square peg fits in every hole at massive cost to the people they work with/for. Train yourself to recognise this and avoid becoming “that person” that isn’t able to pick the right tool for the task.

See also:

- RDBMS vs NoSQL for everything

- ORMs vs Raw SQL

- Everything is better in rust people

- anti-GC people

- functional programming zealots

- Citizens of the Kingdom of Nouns thumping GoF design patterns at every turn

- LLMs as a solution to everything

- the many flavours of anti JavaScript camp (including, vanilla JS only, HTML over wire, PyScript/ClojureScript)

- writing a SPA for your blog folks

- micro-services vs monolith

- the anti-cloud just give me a VM/cpanel traditionalists

- cloud maximalists provisioning masses of AWS services for a low traffic CRUD site

I think there might be too much information given away by disclosing how far away the letter is though. A more difficult mode could be just having three states:

1. Amber: Closest guess(es) so far 2. Red: Wrong guess that is not the closest 3. Green: Correct guess

So you only get new information after the second guess, assuming you don’t hit a green on the first go, and you don’t immediately eliminate most of the keyboard as soon as you are within 2-3 (haven’t quite worked out when the shading starts) characters away.