DEV Community: Claudia Nathan

What the model can't have

Claudia Nathan — Fri, 10 Jul 2026 15:37:19 +0000

About a year ago I started working on a second-order harness for myself where my only intention was to try to not be too fancy about the approach. I wanted to share that project because it turned out to work exceptionally well for me and may for others.

But ultimately that ‘exceptional’ output is an output that is made for me, that enriches in some way my own agency and creativity. It has more to do with how I went about creating it, not what’s actually in it. Which I want to write about first.

I was doing the wrong job

AI moves unusually quickly. Every week brings new models, techniques, workflows, benchmarks and opinions about how you're supposed to work. It creates the feeling that if you stop paying attention you'll be left behind and makes it tempting to constantly optimize your setup instead of your work.

This feeling of falling behind treats all AI knowledge as one 'job', but it's at the very least two:

The model's job is to know about the model.
Your job is to know about the work.

These have wildly different half-lives.

The feed of content we're all buried in (model updates, new tools, frameworks, social content, articles, which I'll refer to as just the feed hereon for simplicity's sake), almost exclusively helps with the first job. That feed is the fastest-depreciating asset there is because the model is trained on it.

The people discovering better ways to work with it matter enormously. But once those ideas become public and general, they don't stay ours for very long. In most kinds of work it's enough to be right. In this kind, being right has a shelf life of about one release. The hours I spent keeping up were hours spent hoarding the single most rapidly-depreciating thing in the room.

Major capability shifts are worth paying attention to because they expand what's possible. But most incremental updates don't require me to rethink how I work. This is why in this harness I run a state-bump on each new Claude Code release so I know the agent has access to the information it needs to do its job.

So with this idea I started using this one project folder to yarn with Claude whenever I wanted to refine how we worked together. I never asked it to create anything.

I'd start talking about a problem or an idea with the words I had about them before looking online about it. I asked a lot of questions and spent most of the time challenging whatever either of us assumed straight away, because almost every time an assumption broke there was a better idea sitting behind it. Sometimes this produced a primitive and sometimes it didn't. Most of them were eventually deleted.

The model can't have what I want

The model gets better every few months without any help from me, but what I want, it can only get from me.

This is easier to say when you already have judgment to fall back on. But I don't think the beginner's version is 'keep up more'. The feed feels like learning and is mostly spectating; judgment comes from thinking for yourself and doing work and being wrong about it often. So the advice holds for them too, it's just less comforting.

I forgot that I am a person with ideas and expertise and a new tool to help me do the things that excite me better and faster.

Really no matter the job you do, your competitive advantage probably isn't knowing that Claude Fable 5 improved tool use by 8%. It's understanding your domain deeply enough to recognize a good answer when you see one.

The bottleneck in most cases (for the people like me and who resonate with this problem) is not the model, and not your lack of knowledge about it.

As I worked on this harness I've gradually tried to distill these ideas into it. It became a funnel I've called agent-kitchen that takes a person's raw thoughts, ideas, and earned expertise, and produces something that helps an agent do better at what matters to that person.

The Harness

Agent-kitchen is a second-order harness: it is a kitchen for the things that configure coding agents (skills, hooks, rules, CLAUDE.md, workflows). It runs as dotfiles for the agent in the form of two plugins under a marketplace:

Cook makes the tools, tastes them, dates them, throws out what's gone stale.
Serve is what's survived for me so far. It still tastes better than store-bought.

The kitchen is built on the idea that:

A frontier model in 2026 is very competent at most things, but its default in any domain is the competent average version of the thing. The artifacts here are commitments that drag the model off that median in a chosen direction.

Every artifact competes with two forces: the unaided frontier model, which absorbs generic craft with each release, and the owner's time, which every artifact charges rent on.

So durable value comes from what the model cannot have: the owner's taste and intent made operational, local truths of a repo or team, verified facts from after the training cutoff, and failures actually observed in sessions.

Everything else gets absorbed, so deletion is the expected end of every artifact here, not a failure of one.

I should mention this is something I actively maintain and rework regularly. There are tests for the model to run and tests that I run, which is mostly just me asking Claude to use a skill, review what it produced, and then I poke and prod at it until it achieves what I expected or wanted.
I'll use other skills that are similar and get it to use each for the same task (a task I actually need to do and have a very clear idea about what an 'excellent' output is). I compare them and work backwards through what Claude did in each.

Cook

Cook is where artifacts come from, it can run as a loop or as-needed.

Skill	Purpose
forge	Routes a behavior through a triage ladder to the right surface (skill, hook, path-scoped rule, `CLAUDE.md`, workflow, subagent, MCP). Applies a consistent stance that judges each artifact by the work it causes the agent to produce, not by the artifact itself.
harness-audit	Inventories everything loaded at session start, measures per-session token cost, and runs four checks: self-consistency, duplication across scopes, enforcement parity, and scope discipline. Built to remove artifacts rather than add them.
harvest	Mines session transcripts for corrections the user had to make more than once, deduplicates them against the existing harness, and forwards surviving candidates to Forge as earned-intent evidence. The "without-the-skill" baseline has already been observed in production during those sessions.
ingest	Converts user-provided resources into an artifact by spawning one reader subagent per source, grounding the result in verbatim quotes.

As a loop:

Serve

Everything in Serve should earn its place only by beating the unaided current model on the gap that created it, checked by a runnable probe and not assumed (process skills are exempt: their value is the owner wanting the procedure, which no release absorbs).

Each such skill keeps the gap that earned it as a runnable fixture in evals/probes.md: the verbatim prompt, what the bare model gets wrong and the pass criterion.

On each model release the probes replay against the bare model in a near-clean session (safe-mode still leaks some account context). Verdicts land in a per-model table and CHANGELOG.md. When every probe passes unaided, the model has absorbed the skill's job and the skill is deleted.

Absorption is not monotonic: a case one model absorbed can regress on the next model line, so probes never retire while the skill lives.

STATE.md + HACKS.md

Verified snapshot of Claude Code's surfaces and lesser-known features, re-checked against the live changelog on each release.

CHANGELOG.md

The provenance ledger: why each artifact exists, what it was re-tested against, and the keep/revise/delete verdicts. The artifacts themselves carry only a one-line model pin.

https://github.com/claudialnathan/agent-kitchen

On Learning Web Development When Web Development is Still Learning Web Development

Claudia Nathan — Wed, 19 Nov 2025 08:43:34 +0000

Hey DEV community! I've been here a little while, learning from everyone in the backdrop. I've decided to take my learning journey public and am kicking things off with what probably reads like an existential crisis but was a really big turning point I felt compelled to write about.

I want to start with a disclaimer, I am still rather new to development. I'm not here to make grandiose, opinionated statements about anything in particular to anyone in particular. I wrote this to help myself compartmentalise what I was finding so difficult about learning Javascript (and anything really beyond HTML/CSS), and am publishing it only in case there are people like me out there, who are fascinated by and deeply interested in the field, but are stuck in the quicksand at the front door.

Since the following realization dawned on me, I've made pretty significant strides in my my ability to learn, understand and put into practice all things web development.

The reason learning to code feels impossible isn't just because it is a complex, layered and vast field of knowledge and expertise, it is also largely because the structure of the field itself creates a specific kind of cognitive trap. But once you see it, you can stop fighting it and start working with it.

I'm both lucky and disadvantaged to be learning web development in 2025. Lucky because so many problems have been solved. Disadvantaged because I'm inheriting a world I didn't watch being built.

And this is the trap: you need context to learn, but you need to learn to build context.

This creates what philosophers call a hermeneutic circle: you need to understand the whole to understand the parts, but you need to understand the parts to understand the whole. You're trapped in a loop where each piece of knowledge requires context you don't have yet.

Development is a complex thing, and it's different in nature to other complex things people learn, such as medicine or science. The difference I've realised comes down to four factors:

Programming / Web Development is very young. It's too young to have settled (best practices are still being argued about) and it's moving too fast to stabilize (by the time something becomes 'standard,' it's already changing).
It is a largely democratized field. Because it is so young and because of it's nature, everyone has a voice and an idea around the why, how, when and where of it all (none of which are wrong or right, it just comes down to what gets adopted by the largest number of people).
It is not standardized enough to have a clear path. While there are bodies and standards, none are finite or 'complete', and none are necessarily the definitive 'authorities' of their domain. We may follow one, abide by its rules and paradigms, but then before we know it there's an entirely new standard with different rules and paradigms and a large number of followers advocating for it's superiority.
It is not constrained by a reality external to humans. This is the big one and has a few different components to it, so let's dive into it.

The fields of medicine and science are both constrained by an external reality. There's a thing out there - a body, a universe - that doesn't care what we think. The goal is to understand and work with what is.

Programming has no external reality. It's just humans, all the way down (for the sake of keeping this from getting too abstract, I'm not talking about the invention of the computer, which was made possible by the constraints of our external reality and our understanding of them. This is about what we decided to do with that invention).

Medicine: the goal is human health (bound by biology, which existed before us)
Science: the goal is understanding (bound by physics, which existed before us)
Programming: the goal is… what? To make computers do things? But why those things? And how? And the answer is just… "because another human decided to build it that way to achieve the thing they wanted to achieve."

Programming is a field where:

The problems only exist because we created them.
The solutions only work within systems we invented.
The "better" way to do something is determined by humans arguing with other humans.
There's no natural law to discover, no biological truth to respect
The constraints are arbitrary - they were chosen by someone, somewhere, and could have been different

So when you're learning, you're not just learning how the body works or how gravity works and then once you understand those things, either finding a job where you put that knowledge into practice and upskill here and there where necessary, or joining a research body to expand our understanding of, in this case, the universe or the body.

You're learning how some people decided this should work, why they decided that, what assumptions they made, which of those assumptions are still true between yesterday and today, which abstraction layer you're operating in, and how the humans who decided these things probably fucked something up along the way that will require a new set of humans to develop another abstraction-layer-solution for. Job at the end? Maybe. Join a research body to contribute to deepening our understanding? You're already in one, friend.

When you enter this 'field', especially in a time like 2025, you're not really entering just a field. You are a newborn baby in a constructed universe that has its own:

Physics (how computers actually work)
Languages (literal programming languages, but also jargon, culture, communication styles)
Geography (frontend, backend, DevOps, data, systems…)
History (why things are the way they are, what came before)
Politics (who controls what, which companies/communities/bodies have power and why)
Economy (what's valued, what's dismissed, who gets paid)
Philosophy (how should code be written? what is "good"?)

And unlike being born into the real world, where you get to just exist in it for a while before choosing a profession, in programming you have to:

Learn this universe exists
Learn how it works
Learn to speak its languages
Learn its history (because without it, nothing makes sense)
Build enough context to even understand what the options are
THEN decide what you want to be

It was this that led me to accept and lean into the complete chaos (the exciting kind) that is the field of web development. Once I understood that, and I understood how we got to the first website and the first app, I was in it. I gave myself a metaphorical web development birth certificate and trudged along.

There is a lot to learn, but there's a lot that's left up to you. I went to university and got a degree in 'Literature and Cultural Studies' (lol no I did not listen to my parents, I am an eldest child and I had to everything learn the hard way). I chose that degree because I knew I liked to be creative, I liked taking arbitrary rules and seeing what new things I could make with them.

This is why I now look at programming as an undoubtedly creative field (albeit a creative field in an alien universe). Once you learn to inhabit this world you didn't know existed, with rules you have to discover in order to eventually figure out what role you even want to play in it and so on, you can start to wonder, tinker, create and innovate.

So what do you do with this?

If you're like me, once you see that programming is a constructed world with contested rules, you stop waiting to 'understand everything' before you start. You stop looking for the one correct path, because there isn't one.
Instead, you learn like a baby learns a language: through immersion, not textbooks. You build things that barely work. You copy code you don't fully understand yet. You participate before you understand, because understanding follows action.
The discomfort isn't a bug, it's the entry point. Confusion means you're at the edge, and that's where learning happens.
You're not learning your way out of confusion. You're building your way through it.

Recommended Resources

I've included below a list of the resources I found the most helpful in my learning journey (there are lots of great resources, but I am only including the ones I stuck to, because options was a big part of the road-block for me).

A lot of the courses I undertook were paid (The Odin Project, though, is completely free and was probably the most important and most helpful one of all) but this is not to say you have to pay for courses to learn these things.

I decided to invest in these structured courses as I was able to afford to do so, but this is a field where you can learn everything you need to learn for free. I've tried to include as many of those as possible below too, and have marked which are paid and which are not.

If you happen to be reading this at the time of publish (November 19, 2025) a lot of these courses have Black Friday deals on atm!
Self guided learning can be really really hard in a field where there's no clear path forward, I found Developer Roadmaps a great guide for this.
I also found How to Learn Stuff Quickly - a blog article by Josh Comeau (to be referenced below a couple times) very helpful.

Foundational Skills

(basics of HTML, CSS, JS and their surrounding ecosystem):

The Odin Project (free, absolute 10/10 resource)
I also downloaded Mimo on my phone to practice in between dedicated 'learning' hours (free on mobile)

Extending on foundations:

HTML

You can't go wrong here, this is a short and wonderfully intuitive part of front-end web development. I never really undertook 'learning' HTML, though I started this journey in Webflow (my favourite tool to this day) which is sort of the equivalent of 'visual HTML and CSS'. It quietly taught me a lot of foundational skills before I knew what they were.
I believe The Odin Project and many other similar resources such as FreeCodeCamp cover all you need on this one.

CSS

You'll learn a lot of CSS in foundational skills, and you can leave it at that if you wish. But CSS is very cool, often underestimated, and gives you a lot of incredible tools. There's no shortage of places to extend on your CSS knowledge, these are the ones I found the most interesting/helpful or are courses from people/resources who I follow and can vouch for likely being very worthwhile:

Josh Comeau's CSS for Javascript Developers (paid) *I did not know Javascript before taking this, and it didn't hinder me in any way, there was one module on React that I just skipped over and came back to later. This is the only paid CSS course I took and I did not feel the need to take any more beyond this one!
Piccalilli's Complete CSS (paid)
Piccalilli's Blog Articles (free)
Kevin Powell's CSS Demystified (paid)
Kevin Powell's YouTube Channel (free)
Honestly YouTube is a treasure trove of CSS's best kept secrets, it's hard to stumble on someone who's got it 'wrong'

Javascript

The below courses/tutorials will also require a decent foundational idea about Javascript, especially syntax, so I recommend you do as much as you can with something like The Odin Project first.

These were game-changers for me! They are all included in the monthly Frontend Masters subscription (which offers a free trial):

The Hard Parts of Javascript by Will Sentance
The Hard Parts of Asynchronous Javascript by Will Sentance
The Hard Parts of Object-Oriented Programming by Will Sentance
The Hard Parts of UI Development by Will Sentance (I'm sure you're picking up on a pattern here, big shout out to Will Sentance)
The Hard Parts (yes, another one) of Servers & Node.js by Will Sentance

Non-Will Resources:

Web Dev Simplified's YouTube Channel (free)
ColorCode's YouTube Channel (free)
The Odin Project (Javascript-specific path)

I have not taken this one, but I am signed up to every notification/email from Piccalli.li and they've just put out the below course:

Javascript for Everyone

React

(this is not the 'next natural step' after learning Javascript, it's just the one I wanted to take):

The Joy of React by Josh Comeau (paid)
The React Documentation (free) is actually very helpful and easy to read if you have a good grasp of Javascript

I'm hoping to come back here to recommend all of my favourite newsletters and accounts I follow to continue learning and stay as up-to-date as I can on the latest in front-end web development as soon as I get a chance!