The Aspiring Nerd

Welcome to Curated Finds: a handpicked collection of the most interesting, insightful, and inspiring links I've come across.Dive in and explore what captured my interest.

I’m not one to use a lot of em dashes, but I read plenty of great blogs by people who do (I guess they’re good at English?). I can only imagine how annoying that must be for them.

Nowadays, I find myself avoiding em dashes because I’m afraid that my writing will be flagged as AI-generated and dismissed as slop. I feel like I have to “dumb down” aspects of writing to convince readers that the words they are skimming were, in fact, written by a human.

What Michael describes here is the real challenge: do we lower the bar when we write with LLMs? For me, since English isn’t my first language, I feel like it improves my writing. But for Michael, I guess it doesn’t.

I’m curious (and more than a bit worried) that the writing that is being produced these days is being shaped by LLMs, even if an LLM has never touched a particular piece of prose.

Bruce Schneier on (not) securing LLMs:

We simply don’t know to defend against these attacks. We have zero agentic AI systems that are secure against these attacks. Any AI that is working in an adversarial environment—and by this I mean that it may encounter untrusted training data or input—is vulnerable to prompt injection. It’s an existential problem that, near as I can tell, most people developing these technologies are just pretending isn’t there.

(via Simon Willison)

Anu Atluru on how doomprompting turns us into passive conversationalists and creators:

Our prompts start thoughtful but grow shorter; the replies grow longer and more seductive. Before long, you’re not thinking deeply, if at all, but rather half-attentively negotiating with a machine that never runs out of suggestions. Have you considered…? Would you like me to…? Shall I go ahead and…? This slot machine’s lever is just a simple question: Continue?

Just found out that Slopsquatting is a thing!

Slopsquatting is a type of cybersquatting. It is the practice of registering a non-existent software package name that a large language model (LLM) may hallucinate in its output, whereby someone unknowingly may copy-paste and install the software package without realizing it is fake. Attempting to install a non-existent package should result in an error, but some have exploited this for their gain in the form of typosquatting.

Source: en.wikipedia.org (via Hacker News)

Regardless of where you stand on vibe-coding and AI-assisted coding, I think it’s here to stay. I like Orta Therox’s way of describing it in their 6 Weeks of Claude Code blog post.

the ability to instantly create a whole scene instead of going line by line, word by word is incredibly powerful.

I believe with Claude Code, we are at the “introduction of photography” period of programming. Painting by hand just doesn’t have the same appeal anymore when a single concept can just appear and you shape it into the thing you want with your code review and editing skills.

I know you’re not supposed to anthropomorphize LLMs, but it’s hard not to when you treat them like your weird, overconfident intern or a junior developer. I’ve always felt like each model has its own personality or vibe, but I never managed to describe it properly. Here’s a pretty accurate attempt by Vincent Schmalbach:

  • GPT-3.5: The Chatterbox
  • GPT-4: The Nerdy Older Sibling
  • Claude Sonnet 3.5: The Lovable Nerd
  • Claude 3.7 & 4.0: The Show-offs
  • Claude Opus 4: The Stern Adult
  • Grok: The Wild Card
  • Gemini 2.5 Pro: The Lovable Goofball

I’m glad I found this post by John. His approach with Claude Code, MCP, and agents is sort of similar (though way more advanced) to how I’ve been using AI in my coding projects (just so you know, I’m not a developer).

Here’s what works best for me: I have a reasoning model generate a task plan based on my requirements. Then, I tweak it (or have the model in Cursor update it) as I go. When bugs pop up, I have the model update the list. This approach keeps the AI from getting lost or confused in a huge context. It also stops it from ignoring bugs or requirements. This has been the most efficient way for me so far.

I keep several claude code windows open, each on its own git-worktree. o3 and sonnet 4 create plans, sonnet 3.7 or sonnet 4 execute the plan, and o3 checks the results against the original ask. Any issues found are fed back into the plan template and the code is regenerated. The factory improves itself.

Source: john-rush.com

There’s a lot of talk about how MCP isn’t secure, but I think most people don’t realize just how easy it is to trick LLMs. Simon Willison gives a solid overview of the main risks, which he calls the “lethal trifecta”.

The lethal trifecta of capabilities is:

  • Access to your private data — one of the most common purposes of tools in the first place!
  • Exposure to untrusted content — any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM
  • The ability to externally communicate in a way that could be used to steal your data (I often call this “exfiltration” but I’m not confident that term is widely understood.)

The core issue is that LLMs are great at following instructions, but they don’t distinguish between legit ones and malicious ones.

LLMs follow instructions in content. This is what makes them so useful: we can feed them instructions written in human language and they will follow those instructions and do our bidding.

The problem is that they don’t just follow our instructions. They will happily follow any instructions that make it to the model, whether or not they came from their operator or from some other source.

He digs into MCP specifically:

The problem with Model Context Protocol—MCP—is that it encourages users to mix and match tools from different sources that can do different things.

Many of those tools provide access to your private data. Many more of them—often the same tools in fact—provide access to places that might host malicious instructions.

And yeah, there’s no easy fix.

Here’s the really bad news: we still don’t know how to 100% reliably prevent this from happening.

Plenty of vendors will sell you “guardrail” products that claim to be able to detect and prevent these attacks. I am deeply suspicious of these: If you look closely they’ll almost always carry confident claims that they capture “95% of attacks” or similar… but in web application security 95% is very much a failing grade.

Quoting Devansh:

Fine-tuning advanced LLMs isn’t knowledge injection — it’s destructive overwriting. Neurons in trained language models aren’t blank slates; they’re densely interconnected and already encode crucial, nuanced information. When you fine-tune, you risk erasing valuable existing patterns, leading to unexpected and problematic downstream effects. Instead, use modular methods like retrieval-augmented generation, adapters, or prompt-engineering — these techniques inject new information without damaging the underlying model’s carefully built ecosystem.

Source: codinginterviewsmadesimple.substack.com