When I started learning, everyone around me had ChatGPT open in the next tab. Every bug, every "how do I center this thing," straight into the chat. And honestly it annoyed me. I had this stubborn idea in my head that if I could only write code with AI holding my hand, then I hadn't really learned anything, I'd just learned to ask.

So I did something kind of dumb looking back. I banned myself from AI for my whole first year. No ChatGPT, no Copilot, nothing. Just docs, Stack Overflow, and Google at 1am.

Some bugs took me like 10 hours. Not exaggerating. There was this one TypeScript error I chased across an entire weekend and it turned out to be something so small I don't even want to say what it was. AI would've caught it in four seconds.

And here's the part I can't really explain to people: that year kind of sucked and I'd still do it again.

Not because suffering makes you a better person or whatever. But being lost in my own code for 10 hours forced me to actually get how the pieces fit. I learned to actually read a stack trace instead of just copying it somewhere and waiting. Learned to guess what was probably broken before I started changing stuff. That stuck in a way I don't think it would've if something just handed me the answer every time.

I use AI a ton now btw. Not anti-AI at all, that's not what this is. Tests, boilerplate, responsive css, translations, all the boring stuff, I just hand it over. It's great at that. But I can usually feel when its answer is off, and I think that's only because of that dumb year building up some sense of what "right" looks like.

The thing that kinda worries me is people starting out now where the AI writes everything from day one. Their credits run out and the work just... stops. Not because there's nothing to do but because doing it without AI was never actually a skill they built up.

I'm not saying refuse AI like I did. That was probably overkill honestly. But maybe give the bug an honest 20 min yourself before pasting it in. Just to keep the muscle.

Anyway. Curious if anyone else did something like this or if I just wasted a year being stubborn about it. How do you all balance using AI vs actually learning the thing?

When I started learning, everyone around me had ChatGPT open in the next tab. Every bug, every "how do I center this thing," straight into the chat. And honestly it annoyed me. I had this stubborn idea in my head that if I could only write code with AI holding my hand, then I hadn't really learned anything, I'd just learned to ask.

So I did something kind of dumb looking back. I banned myself from AI for my whole first year. No ChatGPT, no Copilot, nothing. Just docs, Stack Overflow, and Google at 1am.

Some bugs took me like 10 hours. Not exaggerating. There was this one TypeScript error I chased across an entire weekend and it turned out to be something so small I don't even want to say what it was. AI would've caught it in four seconds.

And here's the part I can't really explain to people: that year kind of sucked and I'd still do it again.

Not because suffering makes you a better person or whatever. But being lost in my own code for 10 hours forced me to actually get how the pieces fit. I learned to actually read a stack trace instead of just copying it somewhere and waiting. Learned to guess what was probably broken before I started changing stuff. That stuck in a way I don't think it would've if something just handed me the answer every time.

I use AI a ton now btw. Not anti-AI at all, that's not what this is. Tests, boilerplate, responsive css, translations, all the boring stuff, I just hand it over. It's great at that. But I can usually feel when its answer is off, and I think that's only because of that dumb year building up some sense of what "right" looks like.

The thing that kinda worries me is people starting out now where the AI writes everything from day one. Their credits run out and the work just... stops. Not because there's nothing to do but because doing it without AI was never actually a skill they built up.

I'm not saying refuse AI like I did. That was probably overkill honestly. But maybe give the bug an honest 20 min yourself before pasting it in. Just to keep the muscle.

Anyway. Curious if anyone else did something like this or if I just wasted a year being stubborn about it. How do you all balance using AI vs actually learning the thing?

Had a diagram problem last week that turned out to be a principle I'd never articulated, so writing it down.

I had an architecture doc in markdown - eleven backend modules with their dependencies - and generated a diagram from it. Auth, multi-currency, e-commerce, refunds, payments, inventory, notifications, reporting, admin. What came out was correct in every particular and completely unreadable. Eleven modules, twenty arrows, most of them long diagonals crossing the whole canvas.

I spent way too long fixing it one overlap at a time. Move a label, shorten another, nudge a box. Got marginally better, stayed unreadable, which in hindsight is the tell that you're working on the wrong problem.

What actually changed it was looking at diagrams I find readable and counting the arrows. A domain-oriented backend map I like uses roughly eight arrows for twenty-five boxes. Mine had twenty for eleven. That ratio is the whole thing.

The principle: clean diagrams don't route long arrows well. They have almost no long arrows.

Three rules that follow from it:

Containment replaces arrows. A box inside a labelled "commerce domain" container already says it belongs to commerce. An arrow saying the same thing costs a line across the page and buys nothing. Cross-cutting concerns like security become an outer boundary rather than eleven arrows.

Right angles only, and keep connectors short. If two things need a long connector they're probably in the wrong place. Move them closer instead of routing better.

One flow per horizontal lane. Separate bands for checkout, refund, sign-in, admin action, webhook, reporting. Flows in separate bands physically can't collide with each other. This is the one that scales - the other two clean up today's diagram, this keeps it clean when you add the twelfth module.

The thing I didn't expect was the annotations. I labelled each step in a flow lane with what that module does in that flow, not what the module is. So the multi-currency box in the refund lane says "reuses the rate snapshot taken at purchase" rather than "handles currency".

That one exposed a coupling I'd never written down: refunds depend on a rate captured at purchase, which means the snapshot has to outlive the refund window. Always been true of the system. I'd just never seen it sitting next to the thing that depends on it.

Which makes me think the value of a diagram isn't documentation. A diagram that makes you argue with your own design is worth more than one that records it.

(For what it's worth I generated these with Claude Code driving an Excalidraw canvas, but the layout rules came from human-made diagrams and aren't tied to any of that.)

TL;DR - count the arrows on any diagram you find readable, compare to yours, and if the ratio is off the fix is structural, not routing.

Does anyone actually track something like an arrow-to-box ratio deliberately, or is this the kind of thing everyone arrives at by feel?

Had a diagram problem last week that turned out to be a principle I'd never articulated, so writing it down.

I had an architecture doc in markdown - eleven backend modules with their dependencies - and generated a diagram from it. Auth, multi-currency, e-commerce, refunds, payments, inventory, notifications, reporting, admin. What came out was correct in every particular and completely unreadable. Eleven modules, twenty arrows, most of them long diagonals crossing the whole canvas.

I spent way too long fixing it one overlap at a time. Move a label, shorten another, nudge a box. Got marginally better, stayed unreadable, which in hindsight is the tell that you're working on the wrong problem.

What actually changed it was looking at diagrams I find readable and counting the arrows. A domain-oriented backend map I like uses roughly eight arrows for twenty-five boxes. Mine had twenty for eleven. That ratio is the whole thing.

The principle: clean diagrams don't route long arrows well. They have almost no long arrows.

Three rules that follow from it:

Containment replaces arrows. A box inside a labelled "commerce domain" container already says it belongs to commerce. An arrow saying the same thing costs a line across the page and buys nothing. Cross-cutting concerns like security become an outer boundary rather than eleven arrows.

Right angles only, and keep connectors short. If two things need a long connector they're probably in the wrong place. Move them closer instead of routing better.

One flow per horizontal lane. Separate bands for checkout, refund, sign-in, admin action, webhook, reporting. Flows in separate bands physically can't collide with each other. This is the one that scales - the other two clean up today's diagram, this keeps it clean when you add the twelfth module.

The thing I didn't expect was the annotations. I labelled each step in a flow lane with what that module does in that flow, not what the module is. So the multi-currency box in the refund lane says "reuses the rate snapshot taken at purchase" rather than "handles currency".

That one exposed a coupling I'd never written down: refunds depend on a rate captured at purchase, which means the snapshot has to outlive the refund window. Always been true of the system. I'd just never seen it sitting next to the thing that depends on it.

Which makes me think the value of a diagram isn't documentation. A diagram that makes you argue with your own design is worth more than one that records it.

(For what it's worth I generated these with Claude Code driving an Excalidraw canvas, but the layout rules came from human-made diagrams and aren't tied to any of that.)

TL;DR - count the arrows on any diagram you find readable, compare to yours, and if the ratio is off the fix is structural, not routing.

Does anyone actually track something like an arrow-to-box ratio deliberately, or is this the kind of thing everyone arrives at by feel?

Claude Code kept rewriting the same fix. I stopped using a log.

When I first set up Claude Code, I gave it one simple rule in CLAUDE.md:

>After every change, write what changed, why, and the benefit into a single RESULTS.md.

For the first few days, it worked perfectly.

A week later, RESULTS.md had grown to 407 lines.

There were 11 entries for 8 actual fixes, including four versions of the exact same fix:

F1 - Server-render all commercial content (partial)
F1 (revised) - done, one regression flagged
F1 (final) - done, one gap flagged
F1 (complete) - done

To understand what actually shipped, I had to read all four and assume the last one was correct.

Then something more subtle happened.

As the file got longer, Claude stopped rereading it before making changes because it became expensive in context. New entries started contradicting older ones.

A log that becomes too large to read back eventually stops being a reliable source of truth.

The interesting part is that the solution wasn't a better prompt or a bigger model.

I stopped asking Claude to log work.

I started asking it to file work.

The setup

I connected Claude Code to Obsidian through the Local REST API MCP server.

Setup took about five minutes:

1. Install Local REST API in Obsidian.
2. Copy the API key.
3. Register the MCP server.
4. Verify with claude mcp list.

The only things that tripped me up:

• The default HTTPS endpoint uses a self-signed certificate.
• The server only exists while Obsidian is running.
• Use --scope user, not --scope project (unless you want your API key ending up in .mcp.json).

The real change

Instead of maintaining one growing history file, Claude now creates two kinds of notes.

Goal notes

Goals/
    SEO Improvements.md

One note describing the overall goal, current status, completed work, and open questions.

Fix notes

SEO Improvements/
    Server Rendering.md
    Sitemap.md
    FAQ Generation.md

One note per change or decision.

Every note has exactly four sections:

1. Changed - files modified
2. What changed - 2-4 plain-language sentences
3. Benefit - why the change matters
4. Verified - what was actually run and what happened

The Verified section turned out to be surprisingly valuable.

Instead of saying "build should pass," Claude has to record what it actually executed.

In one case it even documented that our local backend returns price: 1 for every plan, meaning prices could only be verified in preview. That's exactly the sort of context that normally disappears into chat history.

Two rules made this work

1. Update notes instead of appending

If a fix changes, Claude edits the existing note.

There aren't four versions of "Fix #1."

There's just one note whose status changes from in progress to done.

2. Document decisions, not just code

Some notes describe architectural decisions that changed zero files.

Months later, "why we chose this" is often more valuable than "which files changed."

Result

The same eight fixes that previously produced a 407-line log are now:

• one goal note
• nine small linked notes

Together they're less than half the size, easier to navigate, and much easier for Claude to keep consistent because it only opens the notes relevant to the task.

Monday morning, I don't read a changelog anymore.

I open one note and immediately know where the project stands.

It's not really an Obsidian idea.

Any linked-note system could work.

The important shift was simply:

log -> file

Instead of building one ever-growing history, every change becomes a small document that can be updated without rewriting everything else.

I'm curious how other people are handling long-running agent projects.

• Still using a single RESULTS.md or CHANGELOG.md?
• Keeping notes in docs/?
• Using memory files?
• Something completely different?