Forem: Eli_coding

I Keep Telling Claude the Same Things. So He Started Writing Them Down Himself.

Eli_coding — Fri, 10 Apr 2026 11:24:23 +0000

A small moment that changed how I think about AI coding tools.

If you've used Claude Code for more than a week, you know the pattern.

You tell it something. It does it. Next session — gone. You tell it again. It does it. Next session — gone again.

For me, it was always the same three things:

"Keep components dumb. Logic goes in services."
"Use constants instead of string literals."
"Every new service or helper needs a unit test."

I said these things so many times they started to feel like a ritual. Open Claude, remind Claude, work, close Claude, repeat.

Then one day I was watching the terminal output — and I saw something I didn't expect.

What happened

I was working on a mid-sized Angular project — forms, validators, lazy-loaded modules, the usual stuff.

I'd just corrected Claude again on the dumb components rule. Nothing unusual. But instead of just applying the fix and moving on, I watched the terminal and noticed Claude was still running.

It was writing files.

Not code files. Not component files. Its own internal files.

Right there in the console output, I could see it creating memory.md, then feedback_dumb_components.md, then feedback_unit_tests.md — one by one.

I hadn't asked for any of this.

The files it created

Claude Code had built its own memory index and a set of structured feedback files — one for each rule it had learned from our sessions together.

Here's the actual memory.md it wrote:

# Memory Index
- [Project: Users Management](project_users_management.md) 
  — Angular frontend for Users Management; tabs, forms, validators
- [Feedback: OnPush + forms](feedback_onpush_forms.md) 
  — How to correctly update OnPush components when reactive form state changes
- [Feedback: No inline styles](feedback_no_inline_styles.md) 
  — Never use style attribute in HTML; always use scss files
- [Feedback: Dumb components + constants](feedback_dumb_components.md) 
  — Components must be dumb/agnostic; logic in services/helpers; always use constants
- [Feedback: Unit tests required](feedback_unit_tests.md) 
  — Every new service, helper, or util file must have a .spec.ts unit test file

And here's what it wrote inside feedback_dumb_components.md:

name: Dumb components + constants rule
type: feedback

Components should be dumb and agnostic — they bind signals/inputs from services 
and delegate all logic elsewhere. Business logic, form orchestration, and state 
management belong in services or helper functions, not in component classes.

Never use string literals in TypeScript code where a constant exists or can be created.

Why: User explicitly requested this as a project rule.

How to apply:
- Move any non-trivial logic (subscriptions, form manipulation, state derivation) 
  into a service or helper.
- Before writing a string like 'address', 'postalCode', etc., check if a constant 
  already exists. If not, create one.
- Components should only: inject services, expose signals/computed for the template, 
  and forward events.

And feedback_unit_tests.md:

name: Unit tests required for services, helpers, and utils
type: feedback

Whenever a new service, helper, or utility file is created, a unit test file 
(.spec.ts) must also be created for it.

Why: User explicitly requested this as a project rule.

How to apply: After writing a new .service.ts, helper.ts, or utils.ts file, 
immediately create the corresponding .spec.ts file with at minimum a basic 
test suite skeleton covering the main logic.

It didn't just remember the rules. It documented why they exist and how to apply them. Like a junior dev writing up notes after a code review — except nobody told it to.

Why this moment stuck with me

Watching it happen in real time in the terminal was different from finding files afterwards.

I saw Claude finish applying my correction, then immediately pivot to: "I should make sure I don't repeat this mistake." And then it built a system to prevent that.

That's not autocomplete. That's not even a smart assistant. That's something closer to a collaborator that takes feedback seriously.

We talk a lot about prompting — how to write better instructions, how to get better output. But what Claude did here is different. It turned my feedback into its own system, without being asked.

What changed in my workflow after this

Since seeing this happen, I've started being more deliberate about corrections. When Claude makes a mistake I've seen before, instead of just fixing it in the moment, I now say:

"This is a pattern I always want you to follow. Make sure you remember this."

And it does. It updates its own memory files.

The result is that my sessions now build on each other instead of starting from zero. The tool gets more useful the longer I work with it — which is exactly what you want from any collaborator.

The honest take

Claude Code still makes mistakes. It still occasionally ignores its own memory. It's not perfect.

But watching it write those files in real time made me realize I'd been thinking about AI tools the wrong way. I was treating each session as isolated.

Claude was treating them as a relationship.

One of us was doing it right.

10 years of Angular. Now learning from my own tools.

Follow @eli_coding on Instagram for weekly posts on Angular, AI and real engineering.

I've Been a Frontend Engineer for 10 Years. Here's How Claude Changed My Workflow in 30 Days.

Eli_coding — Tue, 07 Apr 2026 18:02:38 +0000

A practical, honest account from an Angular developer who was skeptical — and then wasn't.

I'll be upfront: I was one of those engineers who rolled my eyes at AI coding tools.

"It hallucinates," I'd say. "It writes mediocre code." "I can do this faster myself."

10 years of Angular, TypeScript, RxJS, and hard-won debugging instincts will do that to you. You build confidence in your own way of working, and anything that disrupts it feels like noise.

Then I gave Claude a real chance. Not a toy project. My actual work.

This is what I found.

What I was building

I was working on a mid-sized Angular 17 app — signals, standalone components, the whole modern stack. The task: a complex data table with filtering, sorting, inline editing, and real-time updates via WebSockets.

The kind of component that takes a full day to get right, and another day to test properly.

I decided to treat Claude as a pairing partner for the whole thing, from architecture to final polish.

The part that surprised me most: it's not about autocomplete

Before this experiment, I thought of AI coding tools as fancy autocomplete. Type a function signature, get a suggestion, accept or reject.

That's not what Claude is.

The real shift was using it as a thinking partner — before writing a single line of code.

I described the component requirements in plain language and asked: "What are the tradeoffs between using a single datasource with BehaviorSubject vs leveraging Angular Signals with computed state here?"

The answer was genuinely useful. Not because it was magic, but because it forced me to articulate my problem clearly — and then gave me a structured way to think through it. Like a good code review, before the code exists.

Concrete example: the filter logic

Here's a real case. I needed to combine three independent filters — search text, status dropdown, and a date range — into a single reactive stream that the table datasource consumes.

My first instinct was something like this:

// My initial rough sketch
filterByText(items: Item[], text: string): Item[] {
  return items.filter(i => i.name.toLowerCase().includes(text.toLowerCase()));
}

I described the full requirement to Claude and asked for an approach using Angular Signals. It proposed this structure:

export class DataTableComponent {
  private items = signal<Item[]>([]);

  searchText = signal('');
  statusFilter = signal<Status | null>(null);
  dateRange = signal<{ start: Date; end: Date } | null>(null);

  filteredItems = computed(() => {
    const search = this.searchText().toLowerCase();
    const status = this.statusFilter();
    const range = this.dateRange();

    return this.items().filter(item => {
      const matchesSearch = !search || item.name.toLowerCase().includes(search);
      const matchesStatus = !status || item.status === status;
      const matchesDate =
        !range ||
        (item.createdAt >= range.start && item.createdAt <= range.end);

      return matchesSearch && matchesStatus && matchesDate;
    });
  });
}

Honestly? This is close to what I would have written. But it took me 4 minutes instead of 25.

Where it saved me the most time

1. Boilerplate I hate writing

Unit test stubs. Interface definitions from API response shapes. Error handling wrappers. I started pasting in API JSON responses and asking Claude to generate the TypeScript interface. Three seconds. Done.

2. Explaining why something is broken

I'd paste a broken piece of code and describe the symptom — not ask for a fix, just ask for an explanation. The process of getting a structured explanation helped me spot the bug myself, faster than if I'd just stared at the code.

3. Writing tests for things I'd already built

Claude is excellent at generating a first pass of describe/it blocks from a component's public API. They're not perfect, but they're a solid 70% starting point.

Where it still falls short

It doesn't know your codebase. Without context, suggestions can be technically correct but architecturally wrong for your project.

It can be confidently wrong. Especially with Angular-specific APIs that changed in recent versions. Always verify anything touching the framework internals.

It doesn't replace judgment. That's still on me.

What actually changed in my workflow

Three habits I've kept after 30 days:

Before writing a component, I describe it to Claude and ask for an architecture sketch — not code, just the approach.
After writing a function, I paste it in and ask: "What edge cases am I not handling?"
For any PR I'm unsure about, I ask Claude to review it before I submit.

The honest summary

I'm faster. Not 10x — that's marketing speak. But meaningfully faster on the tasks that used to drain me.

If you're an experienced frontend engineer who's been skeptical — I was too. Give it a real 30-day trial on actual work, not toy examples. That's where the value shows up.

Follow me on Instagram @eli_coding for weekly posts on Angular, AI and real engineering.