Most people are thinking about AI the wrong way.

They imagine it as a coworker:
Something you assign tasks to… wait for… and hope it delivers.

Sounds reasonable.
But it’s also why so many teams are disappointed.

There’s a better mental model:

👉 AI is not your coworker. It’s your exoskeleton.

And once you see it this way, everything clicks.

What an Exoskeleton Actually Does

Think about a physical exoskeleton.

It doesn’t replace the worker.
It doesn’t think for them.
It doesn’t act independently.

Instead, it:

• Makes them stronger

• Reduces fatigue

• Helps at specific points of strain

• Extends what they’re already capable of

Factories, hospitals, and the military use exoskeletons for one reason:
they amplify humans instead of replacing them

That’s exactly how AI works at its best.

The Big Mistake: Treating AI Like an Employee

When you treat AI like a coworker, you expect:

• End-to-end solutions

• Independent thinking

• Reliable autonomy

And then you get frustrated when it:

• Hallucinates

• Misses context

• Makes weird decisions

That’s not a bug. It’s a mismatch in expectations.

AI isn’t failing.
You’re using the wrong mental model.

The Right Way to Think About AI

Instead, think like an exoskeleton designer.

They don’t ask:

“How do we replace the human?”

They ask:

“Where does the human struggle? and how do we support that?”

That’s the shift.

What This Looks Like in Practice

Let’s make it concrete.

❌ Bad approach (coworker mindset)

“AI, build this entire feature.”

Result:
Messy output, lots of fixes, frustration.

✅ Better approach (exoskeleton mindset)

Break the work into pressure points:

• Generate boilerplate → AI

• Refactor repetitive code → AI

• Explore edge cases → AI

• Write tests → AI

But:

• Define architecture → you

• Make tradeoffs → you

• Own quality → you

AI handles the heavy lifting.
You stay the pilot.

Why This Works So Well

Because AI is incredible at:

• Speed

• Pattern recognition

• Repetition

• Expanding ideas quickly

But weak at:

• Judgment

• Context

• Taste

• Responsibility

So the winning combo is simple:

👉 Human = direction
👉 AI = amplification

The Hidden Insight Most People Miss

The real power of AI is not “doing work for you.”

It’s this:

👉 It removes friction from thinking and building

You can:

• Explore 10 ideas instead of 1

• Prototype in hours instead of days

• Iterate without fatigue

That’s not replacement.

That’s leverage.

Why “Autonomous Agents” Often Disappoint

There’s a lot of hype around fully autonomous AI systems.

But here’s the reality:

The more autonomy you give AI, the more you lose:

• Control

• Predictability

• Trust

And once trust drops, usage drops.

That’s why many “AI agents” feel impressive in demos…
but break down in real workflows.

The future isn’t fully autonomous systems.

👉 It’s tightly integrated systems that feel like an extension of you

The Best Teams Already Get This

The teams seeing real results with AI aren’t trying to replace people.

They’re doing something smarter:

They’re building workflows where:

• AI is always present

• Always assisting

• Always accelerating

Not as a separate tool…

But as something you wear.

A Simple Test You Can Use Today

Ask yourself:

“Where am I doing repetitive, mentally draining work?”

That’s your exoskeleton opportunity.

Start there.

Not with “build an AI agent.”

Not with “automate everything.”

Just:

👉 Remove one point of friction.

Then another.
Then another.

The Future of AI (The Part That Actually Matters)

The biggest wins won’t come from AI that replaces humans.

They’ll come from AI that:

• Feels invisible

• Fits naturally into workflows

• Makes you faster without thinking about it

Like a great exoskeleton:

You don’t notice it.
You just feel stronger.

Bottom Line

Stop asking:

“What can AI do for me?”

Start asking:

“Where do I struggle? and how can AI amplify me there?”

That one shift will put you ahead of most people still chasing the wrong idea.

Source: https://www.kasava.dev/blog/ai-as-exoskeleton

If you’re a builder, engineer, or curious technologist, you might recognize yourself in this story.

Phase 1 - Dismissing the Hype

When modern AI tools first exploded onto the scene, I wasn’t impressed.

Yes, they could generate text.
Yes, they could answer questions.
But most outputs felt shallow, generic, and occasionally wrong in confident ways, the worst combination.

As someone who cares deeply about craft, correctness, and depth, I didn’t see how this could fit into serious work. It felt like autocomplete on steroids, not a real collaborator.

So I ignored it.

Big mistake.

Phase 2 - Curiosity Wins

Eventually curiosity got the better of me. I started experimenting cautiously.

Not for important work. Not for anything critical.

Just small tasks:

• Brainstorming ideas

• Summarising articles

• Generating rough outlines

• Exploring unfamiliar topics

And something surprising happened.

AI wasn’t useful because it was perfect.
It was useful because it was fast.

It became a thinking amplifier.

Instead of staring at a blank page, I now had a messy draft to react to.
Instead of spending hours researching basics, I had a starting map.

The value wasn’t in the answers, it was in momentum.

Phase 3 - First Real Use Cases

Then came the turning point: using AI for real work.

Not toy tasks. Not experiments.

Actual productivity.

I started with areas where speed mattered more than perfection:

Writing

Drafts that used to take hours suddenly took minutes.

Not publish-ready but close enough that editing was faster than starting from scratch.

Coding

AI didn’t replace engineering skill.
But it removed friction:

• Boilerplate code

• Test scaffolding

• Documentation

• Refactoring suggestions

It felt like having a junior engineer who never got tired and responded instantly.

Learning

AI became the fastest tutor I’ve ever had.

Instead of hunting through documentation, I could ask:

“Explain this concept simply.”
“Give me examples.”
“Compare approaches.”

The feedback loop shrank dramatically.

Phase 4 - Changing How I Work

At this point, AI stopped being a tool and started becoming part of my workflow.

I began to think differently about tasks:

Old mindset:
“How do I do this?”

New mindset:
“How do I collaborate with AI to do this faster and better?”

This shift is subtle but powerful.

AI works best when you treat it as:

• A brainstorming partner

• A rapid prototyper

• A tireless assistant

• A second brain

Not as an oracle.

The biggest unlock was learning to iterate.

The first output is rarely great.
But the fifth interaction often is.

Phase 5 - Discovering the Real Superpower

Here’s the insight that changed everything:

AI compresses the distance between idea and execution.

Things that used to feel like “maybe someday” projects suddenly became weekend experiments.

You can:

• Explore new domains without months of ramp-up

• Prototype ideas quickly

• Validate concepts before committing

• Move from thought → artifact almost instantly

It lowers the cost of trying.

And when trying becomes cheap, innovation accelerates.

Phase 6 - Accepting the Limitations

AI is powerful but not magical.

It still:

• Makes mistakes

• Lacks true understanding

• Requires guidance

• Needs verification

Blind trust is dangerous.

But total skepticism is equally limiting.

The winning strategy is informed partnership:

Trust, but verify.
Use it aggressively, but critically.
Leverage speed, guard quality.

Phase 7 - Where I Am Now

Today, AI touches almost everything I do:

• Writing

• Coding

• Research

• Planning

• Learning

• Decision support

Not because it replaces skill but because it multiplies it.

The best way to describe it:

AI is like giving your brain a high-speed interface.

You still steer.
You still decide.
You still own the outcome.

But the friction is dramatically lower.

Lessons for Builders and Professionals

If you’re still on the fence, here’s what I wish someone had told me earlier:

1. Start Small

Don’t wait for the perfect use case.
Use it for low-risk tasks first.

Momentum builds confidence.

2. Learn to Prompt by Iterating

Good results come from dialogue, not one-shot questions.

Start from something. Refine. Clarify. Push deeper.

3. Use It Where Speed Matters

AI shines in early stages:

• Exploration

• Drafting

• Brainstorming

• Prototyping

4. Keep Your Expertise in the Loop

Your judgment is the quality filter.

AI without human oversight produces mediocrity.
AI guided by expertise produces leverage.

5. The Biggest Risk Is Ignoring It

Not using AI today is like ignoring the internet in the late 90s.

You might survive for a while.
But you’ll slowly fall behind people who amplify themselves.

Final Thought

My AI adoption journey wasn’t about discovering a magic tool.

It was about discovering a new way to work.

AI doesn’t replace builders. It upgrades them.

And the people who learn to collaborate with it early will have an unfair advantage for years to come.

===

Source: My experience plus https://mitchellh.com/writing/my-ai-adoption-journey

That’s exactly what NanoLang is.

It’s a tiny, experimental language created by veteran engineer Jordan Hubbard, with a bold idea:

What if we made a programming language specifically for code-generating AI?

And here’s the twist: even if you don’t care about AI, NanoLang is still a fascinating playground for learning how languages, compilers, and testing really work.

Let’s dive in.

Why NanoLang Exists

Modern programming languages are messy.

They’ve grown for decades, accumulated quirks, and contain endless edge cases. Humans learn them slowly; but AI models struggle even more.

NanoLang flips the approach:

👉 Instead of forcing AI to learn complex languages like C++ or JavaScript
👉 create a simple, unambiguous language that AI can generate perfectly

The project’s goal is to reduce ambiguity in code generation by simplifying syntax and semantics so AI tools make fewer mistakes.

Think of it like:

• Esperanto for programming

• or LEGO blocks instead of random scrap metal

• or training wheels for compilers

What Makes NanoLang Special

NanoLang isn’t just “small.” It’s intentionally designed around a few radical ideas.

1. Syntax That AI Can’t Misread

NanoLang uses very explicit, structured syntax (including prefix notation) so there’s almost zero ambiguity.

That matters because:

• AI models often misinterpret punctuation and operator precedence

• humans rely on intuition

• AI needs strict clarity

NanoLang removes guesswork.

2. Testing Is Mandatory (Yes, Really)

Here’s a wild feature:
every function must include tests.

These are called shadow blocks, and they run at compile time.

So instead of writing tests later, NanoLang forces you to think:

“How do I prove this works?”

This bakes testing discipline directly into the language itself.

For junior devs, this is gold. It trains the mindset of:

• specification

• verification

• correctness

Not just “it compiles.”

3. It Compiles to C (for Speed)

NanoLang doesn’t run on a VM.

Instead, it transpiles to C, which then compiles to native code.

That gives you:

• portability

• performance

• interoperability with C libraries

Basically: modern language ideas + proven C backend.

4. Self-Hosting: The Compiler Is Written in NanoLang

One of the coolest achievements:

👉 NanoLang can compile itself.

This is called self-hosting, and it’s a milestone in language design.

It means:

• the language is expressive enough

• the compiler is mature enough

• the ecosystem is real

Many famous languages went through this stage (C, Rust, Go).

Seeing it in a tiny experimental language is seriously impressive.

NanoLang + AI = A New Way to Code

NanoLang was designed for LLM code generation from day one.

The repo includes:

• formal language spec

• training references

• examples

• tests for all constructs

This makes it ideal for AI tools to learn.

And it works.

In one experiment, an AI generated a Mandelbrot fractal CLI tool in NanoLang (after some debugging) showing how AI can learn and use entirely new languages.

That’s huge.

Because it suggests a future where:

👉 AI doesn’t just write existing languages
👉 it writes AI-native languages

Why Junior Developers Should Care

You might be thinking:

“Cool… but I’ll never use NanoLang in production.”

Probably true.

But that’s missing the point.

NanoLang is valuable because it teaches fundamentals better than most real languages.

Here’s what you learn fast:

How compilers work

Because NanoLang is tiny, you can actually read the compiler.

Language design trade-offs

Why immutability? Why prefix syntax? Why no globals?

Testing mindset

Mandatory tests change how you think about code.

AI-assisted programming

You can watch an LLM learn a language from scratch.

That’s incredibly rare.

A Glimpse of the Future: AI-Native Programming

NanoLang hints at something bigger.

Right now, AI writes code in:

• Python

• JavaScript

• C++

• Rust

But those languages weren’t built for AI.

NanoLang represents a new category:

AI-first programming languages

Languages optimized for:

• generation accuracy

• verification

• formal specs

• low ambiguity

As AI coding tools evolve, we may see:

• AI-native DSLs

• auto-verified code languages

• test-embedded syntax

• machine-friendly compilers

NanoLang is an early experiment in that direction.

The Creator’s Perspective

NanoLang’s creator describes it as both:

• a serious experiment

• and a creative exercise

Designing a new language forces you to think deeply about programming itself; what’s essential and what’s accidental.

And that’s exactly why projects like this matter.

They expand how we think about software.

Should You Try NanoLang?

If you’re a junior developer, absolutely.

Not because it’s practical; but because it’s enlightening.

You’ll gain:

• compiler intuition

• language design awareness

• testing discipline

• AI coding insight

Few projects offer all of that in one place.

Final Thoughts

NanoLang is tiny.

But the idea behind it is massive.

It asks a simple question:

What if programming languages were designed for both humans and AI?

And then it actually builds one.

Whether NanoLang itself succeeds doesn’t matter.

Because experiments like this shape the future of programming.

And as AI becomes a bigger part of software development, understanding these ideas early could give you a huge advantage.

So if you’re curious, experimental, or just love learning how things work under the hood:

NanoLang is a perfect rabbit hole.

Source: https://github.com/jordanhubbard/nanolang

These techniques go beyond “add an index and pray,” and they really help in situations where the database planner isn’t doing exactly what you want.

🎯 1. Stop Wasting Time Scanning Tables When You Don’t Have To

Imagine a table of users with a plan column that is only allowed to be 'free' or 'pro' because of a check constraint:

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  username TEXT NOT NULL,
  plan TEXT NOT NULL CHECK (plan IN ('free','pro'))
);

Now someone runs this:

SELECT * FROM users WHERE plan = 'Pro';

That returns no rows but PostgreSQL still scans every row! Why? Because the planner doesn’t automatically assume your constraint means some values are impossible.

🧠 Clever Fix: Enable Constraint-Based Planning

By turning on:

SET constraint_exclusion = on;

PostgreSQL figures out up front that 'Pro' (capital “P”) can’t match the check constraint. It returns the result instantly, no table scan!

Why this matters: In reporting environments where analysts craft queries by hand, mistakes like casing can cause huge performance hits. Constraint exclusion can stop that.

📉 2. Make Indexes Smaller & Faster with Function-Based Indexes

Let’s say you have a sale table:

CREATE TABLE sale (
  id SERIAL PRIMARY KEY,
  sold_at timestamptz NOT NULL,
  charged int NOT NULL
);

And analysts run queries to sum sales per day. Without an index, PostgreSQL must scan all 10M row; slow!

The common solution is:
👉 CREATE INDEX ON sale(sold_at);

That helps: query time drops but the index is huge, and PostgreSQL still considers time even though you only care about dates.

🧠 Better Solution: Index Only What You Need

Instead, index just the date part:

CREATE INDEX ON sale ((date_trunc('day', sold_at)));

This makes the index much smaller and faster, because PostgreSQL only needs to index dates, not full timestamps.

Why this matters:

• Smaller index = less disk usage

• Faster scans = quicker aggregations

• Better performance without huge overhead

💡 This is called a function-based index: a powerful tool junior developers often overlook.

🧪 3. Avoid Human Errors with Virtual Generated Columns

Function-based indexes work great if programmers always use the exact same expression in queries. That rarely happens!

🧠 Safeguard with Virtual Generated Columns

PostgreSQL 18 lets you define a column that computes itself:

ALTER TABLE sale
  ADD sold_date DATE GENERATED ALWAYS AS (date_trunc('day', sold_at));

Now every row stores a date value that matches the index expression exactly. Later queries like this use the index automatically:

SELECT sold_date, SUM(charged)
FROM sale
WHERE sold_date BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY sold_date;

No mistakes. No confusing expressions. PostgreSQL just uses the index.

Why this matters:

• Less manual SQL discipline

• Faster by design

• Cleaner schemas

🔐 4. Enforce Uniqueness with Less Overhead Using Hash Indexes

Suppose you have millions of URLs and want to ensure you never process the same URL twice.

A naive way is to use a unique B-Tree index:

CREATE UNIQUE INDEX urls_unique ON urls(url);

That works but B-Tree indexes can get big and slow if your values are long strings.

🧠 A Better Fit: Unique Hash Index

Hash indexes store a fingerprint of the value instead of the full string. For long or complex text values (like URLs), this can be:

• much smaller

• slightly faster for equality checks

Hash indexes aren’t used everywhere, but when you only need uniqueness, they can be perfect.

🔍 5. Think Like the Planner: Help PostgreSQL Know What You Really Care About

PostgreSQL’s optimizer makes choices based on statistics it has about data. Sometimes these stats are outdated, especially if:

• the table gets updated frequently

• auto-ANALYZE doesn’t kick in quickly enough

🧠 Tip: Fine-Tune Auto-ANALYZE

By lowering thresholds for a specific table, PostgreSQL refreshes statistics faster so the planner stops guessing and starts knowing.

This won’t magically speed every query but in high-write environments it can prevent bad plans from becoming permanent performance problems.

🧠 Final Thoughts for Junior Developers

Here’s what to take away:

✅ Don’t just index everything blindly
👉 Know why an index helps specific queries
👉 Smaller indexes often outperform bigger ones
👉 Planner hints like constraint_exclusion can eliminate needless work

These “unconventional” ideas are unconventional because most developers don’t think about them but they can make dramatic differences in real workloads.

🎓 Quick Cheat Sheet

If you want to explore this in depth, try using EXPLAIN ANALYZE on your queries. It’s the best way to understand what PostgreSQL is actually doing before and after your changes.

Source: https://hakibenita.com/postgresql-unconventional-optimizations

The Good Old Days (Of Terrible Ads)

Back around 2000, the internet was a warzone. Visit any website and BAM!!! random windows would explode onto your screen, covering everything with ads for stuff you never wanted. It was absolute chaos.

So what happened? Browser makers stepped up. Firefox made it a headline feature in 2004. Internet Explorer followed. News articles celebrated. Pop-up blockers became standard. We won!

...Or so we thought.

The Ads Evolved. The Browsers Didn't.

Here's the twist: Pop-ups never actually died. They just changed clothes.

Those old pop-ups opened new browser windows. Easy to block. Today's pop-ups? They're built inside the webpage itself, floating boxes, full-screen takeovers, fake "sign up for our newsletter" modals that ambush you the moment you start reading.

Same annoying behaviour. Same tricks (tiny close buttons, misleading designs, popping up mid-scroll). But now browsers don't even try to stop them.

The ad industry adapted. Browser developers moved on to other things. And here we are, back to square one, except worse.

Why Isn't Anyone Fixing This?

The original pop-up blockers weren't perfect either. There were edge cases, false positives, workarounds needed. But browser teams solved those problems because they wanted to make browsing better.

Today? Crickets. Firefox still has documentation about those 2004-era pop-up settings that nobody uses anymore because websites stopped using actual pop-up windows.

Meanwhile, every shopping site, news article, and blog hammers you with in-page pop-ups that browsers completely ignore.

The Fix We Need: Pop-Up Blocking 2.0

The author's argument is simple: browsers need to start this fight again.

Yes, it's technically harder. Yes, some website developers will complain. But here's the thing: they complained in 2004 too. We ignored them then, and websites adapted.

A browser that actually blocked these modern pop-ups? That would be headline news. People would switch browsers for that feature alone.

The Bottom Line

Browsers decide how they show you websites. They're not just passive windows. They can choose to protect users from garbage experiences.

Twenty years ago, they chose to fight for us. Now it's time to do it again.

The ball's in your court, Mozilla. Chrome. Safari. Want users to love you again? Build something worth talking about.

Source: https://www.smokingonabike.com/2025/12/31/web-browsers-have-stopped-blocking-pop-ups/

✅ Your job is this: Deliver code you have personally verified works

No ifs, no maybes, no “let reviewers find the bugs.”

😬 The Problem Today

We’ve all seen it: a huge AI-generated pull request lands with no evidence that it actually works. Someone else, usually a reviewer or maintainer, has to chase down bugs, figure out if it even runs, and fix it. That’s not teamwork, that’s dumping your mess on someone else.

That used to be forgivable. Today? There’s no excuse.

🧠 Real Software Engineering = Proof

A real engineer doesn’t just hope code works. They prove it. There are two essential steps every time:

1️⃣ Manual testing first

You must see your code do the right thing yourself.

• Run it

• Try it

• Break it
  If you haven’t seen it actually work with your own eyes, it might as well be imaginary.

A smart trick: capture a terminal log or short screen recording that shows your change working and include that in your pull request.

2️⃣ Then write an automated test

Tests are your safety net, they prove your change still works tomorrow, next month, and after someone else touches it.
Modern tools make this easier than ever. Skip this only if you love bugs.

Manual testing + automated tests = Proof.

🤖 Even If AI Wrote the Code

Yes, modern coding assistants like Claude Code and Codex CLI can write and test code for you. But that doesn’t mean you can trust them blindly.

You still need to:

• Teach the tool to show it tested the code.

• Understand the test results.

• Add proper automated tests to your repo yourself.

In other words: AI assists, you’re responsible.

💡 Why This Matters

Submitting unproven code:

• Wastes reviewers’ time

• Introduces hidden bugs

• Shifts the real work to someone else

Proving your code works:

• Saves time

• Builds trust

• Makes you a stronger engineer

It’s not optional. It’s the real definition of professional software development in an AI-augmented world.

🔥 TL;DR: The New Rules of Quality Code

✔ Run your code yourself
✔ Show it works
✔ Add automated tests
✔ Don’t submit anything unless it’s proven

Treat your evidence of working code like gold. Anyone can write lines you prove results.

Source: https://simonwillison.net/2025/Dec/18/code-proven-to-work/

The Problem We All Know

You've got two typical choices for building interactive websites:

Plain HTML: Simple and reliable, but what happens when you need a button that updates part of a page without refreshing everything? Or a search box that shows results as you type?

React/Vue/Angular: Sure, they work. But suddenly you're managing hundreds of dependencies, waiting ages for builds, and debugging why something called useEffect runs twice.

For most projects, dashboards, admin panels, forms, e-commerce sites this feels like overkill.

Enter HTMX: The Sweet Spot

HTMX is refreshingly simple. Here's what it does:

• Any HTML element can make HTTP requests

• Your server returns actual HTML (not JSON)

• That HTML gets swapped into your page automatically

• You write zero JavaScript

• The whole thing is just 14kb

That's it. Seriously.

Here's a working example:

html

<button hx-post="/clicked" hx-swap="outerHTML">
    Click me
</button>

Click the button, HTMX sends a request, the server returns HTML, and it replaces the button. No complicated setup. No build tools. No npm nightmares.

Real Results From Real Teams

A company called Contexte rebuilt their React app using HTMX. The results?

• 67% less code (21,500 lines → 7,200 lines)

• 96% fewer dependencies (255 packages → 9 packages)

• 8x faster builds (40 seconds → 5 seconds)

• 50-60% faster page loads

They deleted two-thirds of their codebase and the app got better.

Quick HTMX Facts

• Created by: Carson Gross in 2020 (evolved from intercooler.js)

• Philosophy: Hypermedia-driven applications, the way the web was designed

• Works with: Any backend language (Python, Ruby, Go, Java, PHP, you name it)

• Learning curve: About an afternoon to get productive

• Key attributes: hx-get, hx-post, hx-swap, hx-trigger, hx-target

When HTMX Shines

Perfect for:

• Admin dashboards

• E-commerce sites

• SaaS applications

• Content-heavy websites

• Internal tools

• Any "forms and tables" application

When to Skip It

Be honest: HTMX isn't ideal for:

• Real-time collaborative editing (think Google Docs)

• Heavy client-side computation (video editors, CAD tools)

• Offline-first apps

• Genuinely complex UI state

But here's the thing: most of us aren't building those. We're building apps that are pretending to need that complexity.

Try It This Weekend

Here's the pitch: pick a side project. Add one script tag. Write one hx-get attribute. See what happens.

html

<script src="https://unpkg.com/htmx.org@1.9.10"></script>

If you hate it, you've lost a weekend. But chances are, you'll wonder why web development ever got so complicated in the first place.

Resources:

• htmx.org Official docs

• hypermedia.systems Free book on the approach

The web was built on simplicity. Maybe it's time to get back to that.

This post will show you what to put inside your CLAUDE.md, what to avoid, and how to write it in a way that Claude can understand and follow easily.

Claude starts with zero knowledge

Large language models do not automatically know your repo. Every new session is basically an empty mind.
The CLAUDE.md file is where you introduce the AI to your project: what it is, how it works, how to build it, and where important things live.

Think of it like a short onboarding note for a new colleague.

What to include

Keep things simple and direct. If someone could read it in a couple of minutes and feel ready to contribute, you are on the right track.

A useful CLAUDE.md should cover:

1. What the project is

2. Why it exists and what problem it solves

3. How to work with it (install, run, test, deploy)

4. How the folders and main parts of the repo are structured

This is not documentation for users. It is guidance for a developer stepping into the codebase for the first time.

Short is better than long

Claude does not read everything just because it is there. It tries to use what feels relevant. If you add too much detail, you increase the chance that important parts get lost inside the noise.

Keep it light. Trim anything that is not essential for understanding the project. A shorter file is easier for humans and AI to absorb. Many good CLAUDE.md files are far under 300 lines. Some teams keep theirs closer to one page and still get great results.

Put extra details in separate docs

If your project is large, do not try to squeeze every piece of knowledge into one file. Create small, focused documents that Claude can read only when needed.

Example folder:

agent_docs/
  build.md
  tests.md
  architecture.md
  migrations.md

Then inside CLAUDE.md you can simply say:

If you need more detail, check the agent_docs files above.

This approach keeps the main file clean and gives Claude the option to pull more context when required.

Avoid turning Claude into a linter

Code style rules, formatting choices and long lists of do this, don't do that make CLAUDE.md heavy and unhelpful.
Let your linters, CI and formatters handle style. Claude is better used for reasoning, planning and writing code, not nitpicking style.

If you want Claude to fix formatting, just show it the linter output directly. That is faster and more reliable.

Write it yourself rather than auto generating it

Yes, you could ask an AI to generate your CLAUDE.md for you. But since this file shapes how the agent interacts with your code forever, spending time to write it well is worth it.

A clear, human written document will reduce confusion later and help your workflow scale. You do not need it to be perfect on day one. You just need it to be useful and kept up to date.

Quick checklist

A strong CLAUDE.md:

• is short, friendly and easy to skim

• explains the project goal and structure in simple language

• describes how to run, build and test the app

• contains links to deeper files instead of dumping everything inside

• is updated occasionally rather than forgotten

Final thoughts

CLAUDE.md is not just documentation. It is how you teach an AI to think inside your codebase. If you treat it like onboarding instead of a rulebook, you will get faster and more reliable help from Claude every time you open a session.

If you want, tell me about your tech stack and what your app does. I can help you draft a clean CLAUDE.md that fits your project perfectly.

Amazon, Meta, UPS, Big Tech is raking in record profits while quietly replacing humans with algorithms. Great for shareholders. Terrifying for government budgets.

Here‘s the math that should keep politicians up at night: over 80% of US federal revenue comes from taxing working humans; income tax, payroll tax, Social Security, Medicare. When those humans get replaced by software? That money vanishes.

The Bill Gates Bombshell

Back in 2017, Bill Gates dropped a radical idea: make robots pay taxes.

Not literally (R2-D2 won’t be filing returns anytime soon). But companies that automate away human jobs? They should pay what those workers would have contributed. Nobel laureate Edmund Phelps backs him up.

The logic is brutally simple. Fire 100 customer service reps, deploy a chatbot instead? Pay the equivalent of their tax burden. Call it a "robot tax" or an "AI levy" either way, it forces companies to share the gains from automation.

Two Camps, One Problem

Team Robot Tax says we need a financial buffer. The Industrial Revolution was chaos; displaced workers, riots, decades of suffering before new equilibria emerged. We can be smarter this time. Tax automation, fund retraining, cushion the blow.

Team Free Market (including Brookings researcher Sanjay Patnaik) argues a targeted AI tax is a bureaucratic nightmare. How do you define "AI"? How do you measure job displacement? Better solution: just raise capital gains taxes on the companies benefiting from automation.

Why This Matters NOW

The UK is already debating this. MP Neil Duncan-Jordan is pushing for companies using AI to cut jobs to face special taxes. His pitch: this isn’t about someone using ChatGPT to plan a meeting. It’s about corporations replacing entire departments.

And the IMF? They’re warning that this isn’t some distant future problem, it’s happening today.

The Bottom Line

We're watching the biggest shift in how work happens since the Industrial Revolution. The question isn’t whether AI will transform the economy, it’s whether we'll have any tax revenue left when it does.

The robots are getting smarter. It’s time our tax policy did too.

What do you think? should AI pay its fair share? Drop your take in the comments.

That simple idea that something can look flat up close even if it's curved overall led to one of the most important concepts in modern math: the manifold.

The Quiet Genius Behind the Idea

In 1854, a shy mathematician named Bernhard Riemann gave a lecture in Germany that almost didn’t happen. He was terrified of public speaking. He had even planned to become a pastor like his father.

But that day, he introduced a new way to think about shapes and space. Riemann suggested that you could study complicated spaces by zooming in on small pieces that look flat and familiar. At first, people didn’t pay much attention. Decades later, his idea became the foundation of modern physics.

So… What Is a Manifold?

A manifold is any shape that looks flat if you zoom in close enough.

• Walk along a circle as an ant. Up close, it feels like a straight line. That’s a one-dimensional manifold.

• Walk across the Earth. It feels flat, even though it’s curved. That’s a two-dimensional manifold.

But not everything counts. A figure-8 doesn’t work because the crossing point is messy. No matter how much you zoom in, it doesn’t look like a simple line. An ant would know something strange is happening.

Why Does This Matter?

Manifolds show up everywhere in science and technology.

• Einstein used Riemann’s ideas to describe spacetime a four-dimensional manifold. Gravity, in his view, is just curvature.

• Engineers use manifolds to model complex machines.

• Data scientists use them to find hidden structure in huge datasets.

• Roboticists use them to plan smooth, safe movements.

As one mathematician said: asking how scientists use manifolds is like asking how they use numbers; they’re that fundamental.

The Clever Part

The true power of manifolds is that they turn hard problems into easy ones.

Because every small patch looks flat, you can use simple math on each patch, then piece everything together; just like using many small paper maps to represent the whole Earth. Each map is a “chart,” and all of them together form an “atlas.”

From a nervous lecture in 1854 to the very shape of the universe, manifolds show how a simple observation can unlock an entire world of ideas.

Sometimes the ground does look flat. You’re just seeing a tiny part of something much bigger.

The Single Assignment Principle

There’s one tiny rule that can massively boost your code quality: give a variable one value, once, and then leave it alone. Unless you’re doing actual iterative math in a loop, treat variables as write-once, read-many treasures. This isn’t some ivory-tower purity test, it's survival wisdom forged in the fires of 2 AM debugging sessions.

Picture this: you're stepping through a debugger, and every calculation you ever made is still there, neatly preserved. You can follow the trail from userAge to adjustedAge to finalAge like breadcrumbs through the forest. Overwrite those variables, and poof; the trail vanishes. Now you’re staring at a single variable that’s been shapeshifting like a superhero.

The real nightmare hits when you refactor. You extract a chunk of code, move it somewhere else, and suddenly that reused variable name either doesn’t exist anymore or means something totally different. The code breaks silently, and you spend hours hunting a ghost bug that never would’ve existed if you’d created userAge2 instead of bulldozing userAge.

The Language Landscape

Languages all treat immutability differently. C and C++ give you const, which might honestly be one of the most powerful keywords ever invented. Marking almost every variable const should be the default. In fact, I wish the languages had flipped the rules: everything immutable unless you explicitly declare it mutable. Imagine the bugs that would never be born.

Functional languages like Haskell and Erlang go all-in: variables never change, full stop. It sounds harsh, but it wipes out entire classes of state-related bugs before they can bite. Rust takes a similar stance (immutability first) forcing you to mark variables as mut when you really mean it.

JavaScript tried to clean up its act by adding const and let to replace the chaotic var, though const still lets you mutate objects under the hood. Scala and Kotlin offer val (immutable) and var (mutable), gently steering developers toward safer patterns without yelling about it.

Then we have Python, beautiful, flexible, dangerously forgiving. It hands you a flaming torch and says, "Try not to burn down the house." No built-in immutable variables, just conventions and discipline. Turns out I needed to relearn both.

The Bottom Line

Immutability isn’t about being a zealot, it’s about being kind to future you. When every variable has a clear purpose and never secretly changes, your code becomes simpler to read, easier to debug, and far safer to refactor. Some languages enforce this for you, others leave you on your own, but the lesson is universal: variables that stay put lead to programs that stay solid.

A few years ago, new coders faced "tutorial hell", watching endless YouTube tutorials, copying every line perfectly, then freezing when trying to build something new, alone.

The solution was simple: write more code, watch fewer videos. Learn by doing, not by following along.

But today, we face a new problem.

The New Problem: Vibe Coding Hell

AI coding assistants like ChatGPT and GitHub Copilot are everywhere. They're powerful tools, but they've created a new trap.

What is "vibe coding hell"?

Building projects quickly with AI help, but not understanding the code you're writing.

The symptoms:

• "I can't build anything without my AI assistant"

• "My project works, but I have no idea how"

• Feeling lost when AI makes mistakes

Why This Matters

A 2025 study found developers using AI thought they were 25% faster, but were actually 19% slower. When AI does the thinking, your brain doesn't do the work.

Worse, it creates a dangerous mindset: "Why learn this when AI already knows it?" This leads to developers who can't solve problems without AI assistance.

Two Problems with Learning from AI

Problem 1: AI Agrees with Everything

AI rarely challenges you or points out flaws. But real learning requires friction; that uncomfortable struggle where growth happens.

Problem 2: AI Gives Wishy-Washy Answers

Responses like "Some prefer X, others prefer Y" don't help beginners. You need clear direction and strong opinions when learning.

How to Escape Vibe Coding Hell

❌ Avoid These Habits

• Letting AI write entire code blocks

• Using AI agents to complete learning projects

• Copy-pasting without understanding

✅ Use AI This Way

• For explanations, not solutions: "Explain how this works" not "Write the code"

• For debugging help: Show your code and ask what's wrong

• With challenging prompts: "Ask me three questions before answering"

🔥 The Golden Rule: Embrace the Struggle

Real learning feels uncomfortable. When you're stuck and frustrated, that's when your brain grows.

Remember: Only coding yourself teaches you to code.

Your Action Plan

1. Type every line yourself: Even if AI suggests it

2. Break things on purpose: Then fix them

3. Ask "why": Understand every line of code

4. Build without AI: Try one project completely alone

5. Use AI as a tutor, not a crutch: Ask questions, don't request solutions

Real developers aren't the ones who can prompt AI best. They're the ones who understand how their code actually works.

I take all my notes in Bear (it’s like Notion, but simpler). A few months ago, I realised something big: since my notes are just text, why not let Claude Code work with them?

Now I’ve got Claude helping me take notes, organise research, and think through ideas. I even set up a little home server so I can access it from my phone.

What Makes Claude Code So Good

People often ask why I’m so obsessed with it. Here’s why it stands out:

1. It speaks “Unix.”
Unix is the language of the command line; those tiny, powerful tools developers use to make computers do things. Claude Code knows how to use them really well. While most AI tools get lost in complicated tasks, Claude just connects simple commands and gets the job done fast.

2. It actually remembers stuff.
This is huge. Most AI chat tools (like ChatGPT or Claude in the browser) forget everything after each chat. Claude Code doesn’t. It can save files, read them later, and build on past work.

Think of it like this: regular AI tools are geniuses with short-term memory loss. Claude Code is a smart coworker who takes notes and remembers what you did yesterday.

The Big Idea

Claude Code shows that sometimes, it’s not about making AI smarter; it’s about giving it better tools. By letting it use a filesystem and basic Unix commands, you unlock a whole new level of ability that’s been hiding there all along.

We’re just getting started with what’s possible.

A Tiny Group Controls Everything

While experts argue about whether social media divides people, something bigger is happening: a tiny group of users has figured out how to control what goes viral and change how we all think.

The numbers are crazy. Only 3% of accounts create one third of all posts. Just 10% of users write 97% of posts about current events. These aren't normal users; they're influencers and content creators who discovered the secret to going viral: making people angry.

Studies show that every angry or emotional word in a post makes it 20% more likely to spread. Posts about anger and disgust spread the fastest. Why? Our brains are wired to pay attention to danger, and these creators have learned to use this against us.

You Can't Escape It

The scary part is, even if you don't use social media, it still affects you. Studies found that older people who barely use social media changed their behaviour the most. How?

Your friends who use social media influence you. TV news repeats viral stories. Everyone talks about what's trending online. The effects spread through society like a virus.

When researchers paid people to quit social media for six weeks, it barely changed their views. Why? Everyone around them was still using it, still influenced by it, still talking about what they saw online.

How Anger Goes Viral

Studies in Germany, Italy, and Russia all show the same thing: when more people in an area use social media, extreme things happen more often more protests, more hate crimes, more people voting for extreme candidates.

One study found that normal increases in social media use matched up with 32% more hate crimes. Another showed that 10% more users in an area made protests almost 5% more likely.

The Fake Reality Problem

Social media creates what researchers call a "fake shared understanding." We think people around us are way more extreme than they really are. Surveys show most people are pretty normal and don't care much about politics,but social media makes the angry voices louder, so it seems like everyone is outraged.

The dangerous loop: when we think others are extreme, we become extreme too. Studies show people who see angry comments start writing angry comments themselves. Users copy the anger they see in their feeds. We're teaching each other to be angrier.

Why Experts Got It Wrong

Old research looked at whether different groups hate each other more. But social media's real damage is bigger it makes everyone angrier, more scared, and more tribal, no matter what they believe.

The system is designed this way: attention equals money. Content creators get paid based on how much people interact with their posts. And nothing gets more clicks than fear, anger, and outrage. We built a system that pays people to make us feel terrible.

The Bottom Line

Social media isn't just showing us reality: it's warping reality while making rich a tiny group of people who've mastered fake outrage.

Studies from many countries agree. A small group of people who post constantly, chasing money and attention, is changing how we see each other and how we act.

And this is just the beginning.

You’ll say the wrong thing.
Make a bad call.
Lose your cool.
Forget a promise.

That’s not failure; it’s human.

The real question is: what do you do after you mess up?

👶 The Lesson That Changed Everything for Me

I read a parenting book called Good Inside.
One idea blew my mind:

Being a great parent isn’t about being perfect
it’s about repair.

You mess up → you go back → you make it right.

That’s exactly what great managers do.

Your worst boss wasn’t the one who made mistakes.
It was the one who never admitted them.

⚖️ The Fork in the Road

You promise a tight deadline without asking your team.
They grind.
Stay late.
Burn out.

Now you’ve got two choices:

🚫 Bad manager: Pretends nothing happened. Trust fades.
✅ Good manager: Says,

“I messed up. I should’ve checked with you first. I won’t do that again.”

That simple honesty builds trust.

🔧 How to Repair

1️⃣ Be specific.
Don’t say “sorry! things got messy.” Say what you actually did.

2️⃣ Own the impact.
No excuses. Focus on how it affected them.

3️⃣ Show change.
A repeated mistake isn’t a mistake anymore.

4️⃣ Be patient.
One apology helps, consistency heals.

🔥 Why It Matters

When you know you can fix mistakes, you stop fearing them.

You move faster.
Lead braver.
Show up more human and not a robot.

Management isn’t about perfection.
It’s about trust, repair, and growth.

You’ll get it wrong.
You’ll fix it.
You’ll get better.

That’s the skill that changes everything. 💙

You’ve seen it: that smug little number in Task Manager or Activity Monitor. “Don’t worry, I’m only at 50% CPU utilization!”

Yeah… about that. It’s lying to your face.

The Experiment That Blew the Lid Off

One curious engineer decided to put their AMD Ryzen through the digital equivalent of Navy SEAL training using a tool called stress-ng (translation: “let’s break the CPU and see what happens”).

They wanted to know: if the CPU meter says 50%, does that really mean the chip is working at half its capacity?

Short answer: nope.
Long answer: your CPU is gaslighting you.

The Numbers That Don’t Add Up

Here’s what’s really going on when your CPU swears it’s “half busy”:

• Regular tasks: already chewing through ~60 -65% of what the chip can handle.

• Math with integers: jumps to ~65 to 85%.

• Matrix math (heavy-duty number crunching): up to 100%.

So yeah, your computer can claim it’s “only halfway there” while secretly sweating like a student pulling an all-nighter before finals.

The Dirty Tricks Behind the Lie

Two big reasons your CPU meter is about as trustworthy as a toddler with chocolate on their face:

1. Hyper-threading: The Fake Roommate
Your CPU pretends it has more cores than it really does by splitting them into “threads.” Imagine 12 bathrooms. Great! Then it says, “Surprise, here are 12 more bathrooms!” Except those extra ones are just people sharing the original bathrooms. When workloads pile up, half those “extra” cores are mostly waiting in line.

2. Turbo Mode: The Bait and Switch
When only a few cores are active, they can sprint at full turbo speed (say, 4.9 GHz). Fire up all the cores, and suddenly everyone slows down to 4.3 GHz to avoid overheating. That means your CPU meter is counting cycles, but the cycles themselves keep shrinking in value. It’s like measuring distance while someone keeps changing the length of your ruler.

How to Outsmart the Lie

Stop blindly trusting CPU percentages. Instead:

✅ Benchmark your system — test how much work it can really do under load.
✅ Measure completed work, not just utilization.
✅ Compare against the real max, not the fairy tale number your CPU reports.

TL;DR

CPU utilization numbers are about as honest as someone saying “I’m fine” when they’re clearly not.

If you trust that 50% figure, you’ll end up underestimating how close you are to the edge. Measure real performance, not just utilisation, and your future self will thank you.

This isn’t your dusty high school timeline of inventions. It’s a massive, living map of 1,780 technologies spanning 3.3 million years, all stitched together with over 2,000 connections. Imagine seeing the wheel evolve into cars, or ancient glass-making techniques laying the groundwork for your smartphone screen. It’s not a list. it’s a web. A story. A chain reaction of human creativity.

What makes it even cooler? He is building it in public. He’s tweaking, refining, and expanding it based on feedback. Every time you check in, the map has grown a little bit more. like technology itself.

The best part is how approachable it feels. Instead of staring at today’s mind-bending tech and thinking, “How on earth did we get here?”, you can trace the path step by step. It’s history, but alive, and it reminds you that every breakthrough, no matter how tiny, can spark the next revolution.

Head to historicaltechtree.com to see this for yourself. but once you dive in, you may not resurface for hours.

How We Think

Good programmers follow a kind of loop:

1. They figure out what they need to build. Not just “make a login page,” but how it fits with everything else (the big picture), what could break, and what users expect.

2. They write code to do that task.

3. They step back and check what their code actually does. Not what they hoped it would do.

4. They spot the gap between what they wanted and what they got, then fix it.

The key here is that developers can hold multiple versions of reality in their heads. They know what the goal is, what the code currently does, and how the two compare.

Where AI Struggles

AI is great at spitting out code fast. It can read your codebase, add tests, even write logs. But it can’t keep track of what’s really happening.

It’s like a brilliant but forgetful friend. They’ll write code and assume it’s perfect. When tests fail, they guess randomly is the test wrong, the code wrong, or something else? And if things get too messy, they just start over.

That’s the opposite of real programming. Humans pause, think, test, and adjust. They know when to rewrite and when to debug deeper, AI doesn’t.

Will AI Improve Soon?

Tens of billions of pounds are being poured into Startups all trying to solve this problem. So, probably, but not just by making models bigger.

When coding, humans don’t keep everything in their head at once. They zoom in on details, then zoom out to the big picture, and juggle priorities. AI doesn’t do this well. Instead, it:

• Misses obvious but unstated things.

• Forgets details from earlier.

• Makes up fake features or errors.

These aren’t minor issues. To really build software, you need to track what you want, what you have, and what to change. You need to have a mental model of your code as a whole, be able to divide it into smaller parts while connecting the dots between them. AI just isn’t there yet.

So What Now?

AI is still very useful. It’s like a super-fast intern who never gets tired and knows every language. For niche, clear tasks, it’s amazing. For example if you want to write a client for AWS SES to use and send emails in your app, it’s just a matter of seconds to have it.

But for bigger problems: debugging, design, or real problem-solving you’re still in charge. AI can write the code, but you need to make sure it’s correct and actually does the job. I would say, you are the driver and AI is the car. You can use it however you want to speed up and deliver the output much quicker, but at the end of the day, the car can’t drive itself.

The future will likely be humans and AI working together, with humans leading. AI is a strong tool, but it’s still just a tool. You wouldn’t let your text editor design your app, and you shouldn’t let AI either.

At least not yet.

At the heart of this technological revolution lies an intricate web of calculations known as neural networks. These complex systems mimic the human brain's architecture, enabling computers to learn from vast amounts of data in ways we once thought were exclusive to humans. In this blog post, we'll embark on a fascinating journey into the realm of neural networks. Whether you're a tech enthusiast or simply curious about how today’s AI marvels work behind the scenes, join us as we break down these powerful frameworks and unveil their essential role in shaping intelligent systems that are redefining our interaction with technology!

The Building Blocks: Understanding Neural Networks

Neural networks are computational models inspired by the biological neural networks that constitute animal brains. Just as our brains consist of billions of interconnected neurons that process and transmit information, artificial neural networks are composed of layers of interconnected nodes, or "artificial neurons," that work together to recognise patterns and make predictions.

Each connection between nodes has a weight that determines how much influence one node has on another. Through a process called training, these weights are adjusted based on the data the network encounters, allowing it to learn and improve its performance over time. This learning process is remarkably similar to how we humans learn from experience, gradually refining our understanding through repeated exposure to information.

The Transformer Revolution: Architecture That Changed Everything

The specific type of neural network architecture that powers GPT and most modern LLMs is called a transformer. Introduced in 2017, transformers revolutionised natural language processing by introducing a mechanism called "attention" that allows the model to focus on different parts of the input text when generating each word in its response.

Unlike earlier neural network architectures that processed text sequentially, transformers can examine all parts of a sentence simultaneously, understanding relationships between words regardless of their distance from each other. This parallel processing capability, combined with the attention mechanism, enables transformers to capture complex linguistic patterns, understand context across long passages, and generate coherent, contextually appropriate responses that seem almost human-like in their sophistication.

Scale Matters: From Networks to Large Language Models

What transforms a neural network into a large language model is primarily a matter of scale and training methodology. Modern LLMs like ChatGPT contain trillions of parameters, which are the adjustable weights and biases within the neural network.

These massive models are trained on enormous datasets containing text from books, articles, websites, and other sources, learning to predict the next word in a sequence based on the preceding context. Through this seemingly simple task of next-word prediction, the neural network develops an understanding of grammar, facts, reasoning patterns, and even creative expression.

The "large" in large language models refers not only to the number of parameters but also to the computational resources required to train and run these systems, often requiring specialised hardware and significant energy consumption.

What’e next?

I will write more about LLMs, how they work and their applications. Follow me to stay up to date!

The core principle of diffusion models is to gradually remove noise from an initially random input. Stable Diffusion first encodes an image into a lower-dimensional latent space using a VAE, reducing computational complexity. Then, a U-Net, conditioned on a text prompt processed by a CLIP text encoder, learns to predict and remove noise step by step. This denoising process is governed by a stochastic differential equation, which enables the generation of coherent and visually meaningful images from pure noise.

A key innovation in Stable Diffusion is its ability to operate in the latent space instead of the pixel space, making it significantly more efficient than earlier diffusion models like DALL·E 2 or Imagen. By applying denoising steps in a compressed latent representation, the model reduces the computational cost while preserving image fidelity. This allows it to run on consumer GPUs with as little as 4GB of VRAM, making high-quality image generation accessible to a wider audience.

Text conditioning in Stable Diffusion is achieved using a cross-attention mechanism that aligns textual features with visual representations. The CLIP text encoder translates text into a latent representation that guides the image generation process. This enables users to create highly specific outputs by modifying prompts with keywords, weights, or negative prompts to influence style, composition, and details. The cross-attention layers in the U-Net allow the model to dynamically adjust image features based on the input prompt.

it has numerous applications, including digital art, concept design, and image inpainting. Additionally, its open-source nature allows developers to fine-tune the model for specific tasks, such as generating medical images or architectural designs. Despite its advantages, the model also raises ethical concerns, such as bias in training data and potential misuse for deepfake generation. Researchers continue to explore ways to improve safety, controllability, and fairness in AI-generated content.

You can learn more about Stable Diffusion here: https://sdtools.org/

P.S: Took a while :-)