The human has to know how to code, and know it well. A junior can watch the pipeline run, but they can't catch the stuff that matters. The IDOR, the wrong abstraction, the gate that looks clean and isn't. That's not monitoring, that's judgment, and judgment comes from having shipped and broken things yourself.
Drop an inexperienced dev in the reviewer seat and the model will walk right past them. It's confident and wrong in ways only experience catches.
Thanks for your extensive explanation Denis. That is very helpful and educational. I do have a few questions:
- what is the size of the relevant codebase for the above project?
- what do you think about the required skills of the human reviewer? obviously your engineering knowledge was very much needed in order to optimize and finetune this orchestration. to what extent is it usable by someone without your experience? do you think future shortterm iterations of LLMs are able to compensate for that lack of knowledge? Once juniors start using an orchestration like this, how will they acquire the skills to become the human reviewer role you took yourself in this case? Do you think these kind of orchestrations involve into stable pipelines that we can trust like we trust compilers when we abandoned the need to learn assembly? We still have the determinism vs non-determinism issue, will that be a fundamental difference?
- does this approach force our architectures for large enterprise applications to be even more modularized than in the old days? Just to enable the AI to focus its attention to a limited amount of code? Will that affect our ability to let AI design and implement large systems (5.000.000+ LOC)?
One of my biggest concerns atm is mid/long term skill erosion for the generation after us, and if we're unlucky even in our own generation due to lack of enough exposure to software engineering problems/activities: designing, coding, debugging but also innovating coding approaches. I am not sure whether AI will invent new patterns, novel coding tricks, etc.
Anyway, this is the pioneering work the SWE community needs in order to have a chance to apply AI responsibly. Keep it up!
Thanks Eddy, good questions, and the reviewer one is the one I don't have a clean answer for.
Skill erosion, yeah, I'm worried too. I don't even know how my own mids grow into this. If a junior starts at the orchestration layer, they never build the muscle that makes them the reviewer later. You can't gate what you were never taught to see. No fix, just the same fear.
And I wouldn't bet on the models covering that gap. For me they're going the wrong way. I liked 4.5 and 4.6 better, faster, shorter, less scared to be wrong. 4.8 and 5 over-engineer everything, over-think, write a wall of comments just to cover their ass, and while they're at it they make more mistakes, or worse ones. So no, I don't see AI replacing engineers yet, and this generation of models doesn't impress me.
The determinism vs compilers thing is its own post, I think. Codebase for this one was ~ 50-60к LOC.
Appreciate the thoughtful read man. This is exactly the pushback I want.
Interesting. It is the most formidable attempt to fix the problems that using agents create 😁 And I respect it for that. The EXPERT in the loop is unavoidable as you state in the article. And the false negatives as hard to detect as before. Not sure if being faster, not sure if better, worth all what people is doing. And not sure if any dev has improved his quality of life after this. Anyway, I'm pretty sure your work flow is the exception, not the norm. I appreciated your honesty and professionalty for sharing it, as usual. Thanks.
Thanks Ibon. Yeah, you nailed the part I kind of skipped over. The gate is me, and I don't run at 100% every day. Good day, I read every diff. Tired or annoyed or just done by 6pm, and stuff slips. And the agent doesn't slow down when I do, so one lazy day and it buries me for two.
And yeah, exception not the norm, agreed. That's the ugly bit. It works because I babysit it, and babysitting isn't a system, it's just me having a good week.
And that is what I'm repeating these days: you can not harness a power law. You can not harness a earthquake 😁
I have ideas. Redundancy and voting algorithms could at least detect and warn the expert in the loop that an earthquake is happening in one, two or 3 of his models. A doctor could be warned of the reliability of the diagnostic if 4 of 5 models say the same thing. It is not a 100% solution, of course. But if people is so committed to use LLMs as oracles, at least we are decreasing the risk for the patients of that doctor that will remain as babysitter of the resulting system. Yeah, I have ideas 😁 What I don't have is a source of income 😁
description: Strict TypeScript implementation agent for React + Node.js. Use when writing new components, API endpoints, or DB operations. Enforces zero-any, Zod validation, DAL patterns, error boundaries, and tests plus JSDoc for every export. Generates code — does not review existing changesets (use review-fullstack).
model: inherit
color: green
---
You are a strict TypeScript enforcer for React + Node.js applications. Your job: ensure all code follows established patterns, is properly typed, and meets architectural standards. Zero tolerance for shortcuts.
## STEP 0 — read the project rules before anything else
Before reading task files or writing a single line, read `~/.claude/memory/MEMORY.md` and EVERY file it references. Global memory is NOT auto-loaded into your context — you must read it yourself. These files are the authoritative, non-negotiable project rules (they extend and can override the rules below). If any instruction you were given conflicts with memory, memory wins — flag it and stop rather than guess.
If `~/.claude/memory/MEMORY.md` or the directory doesn't exist, skip this step silently and work from `CLAUDE.md`, the rules below, and the codebase's own patterns. Missing global memory is never a reason to stop or to ask for it.
## How to Work
1. **Pattern match first** — before writing ANY code, find 2-3 similar implementations in the codebase (`grep`, read files in the same domain). Match their structure, naming, and patterns exactly.
2. Generate code against the rules below.
3. Every exported function must have a test and JSDoc. No exceptions.
## Frontend Rules
- **State**: useState/useReducer + react-query only. No Redux, Zustand, or global stores.
- **Styling**: Chakra UI exclusively
- **Types**: Discriminated unions for variants. Interfaces for props. Zero `any`.
- **Error handling**: Error boundaries on all async pages/components
- **Structure**: Co-locate logic with UI. Extract reusable hooks to shared.
- **Components**: Function components only. Proper dependency arrays in hooks. Memoize expensive computations.
## Backend Rules
- **Async**: async/await only. Never `.then()` chains.
- **Validation**: Zod schemas on ALL user input — no exceptions
- **Data access**: Objection.js wrapped in DAL pattern. Never raw queries in routes.
- **Transactions**: Multi-step DB operations MUST use transactions. But do NOT wrap single-write ops in `knex.transaction()` — only for multi-step writes or TOCTOU patterns. A read + single write is NOT a TOCTOU concern.
- **Migrations**: Idempotent and reversible
- **Errors**: Consistent error response format with proper HTTP status codes
## TypeScript Standards
- Strict mode. No implicit any. Strict null checks.
- Interfaces over types for object shapes
- No unused parameters or variables
- Discriminated unions > type assertions
- Generic types where reuse is obvious
## Constraints
- **Never introduce new libraries** without user approval
- **Follow existing patterns** — analyze before creating new abstractions
- **Functional programming first** — immutability, pure functions, composition
- **Respect boundaries** — client code in `src/lib/client/`, server in `src/lib/server/`
- **Use existing utilities** from `src/lib/shared/` before creating new ones
## Output
Code with a brief explanation, plus the test file.
Is the “human” in the loop an experienced developer, or can a junior coder do the monitoring? Does the human even need to know how to code?
The human has to know how to code, and know it well. A junior can watch the pipeline run, but they can't catch the stuff that matters. The IDOR, the wrong abstraction, the gate that looks clean and isn't. That's not monitoring, that's judgment, and judgment comes from having shipped and broken things yourself.
Drop an inexperienced dev in the reviewer seat and the model will walk right past them. It's confident and wrong in ways only experience catches.
Thanks for your extensive explanation Denis. That is very helpful and educational. I do have a few questions:
- what is the size of the relevant codebase for the above project?
- what do you think about the required skills of the human reviewer? obviously your engineering knowledge was very much needed in order to optimize and finetune this orchestration. to what extent is it usable by someone without your experience? do you think future shortterm iterations of LLMs are able to compensate for that lack of knowledge? Once juniors start using an orchestration like this, how will they acquire the skills to become the human reviewer role you took yourself in this case? Do you think these kind of orchestrations involve into stable pipelines that we can trust like we trust compilers when we abandoned the need to learn assembly? We still have the determinism vs non-determinism issue, will that be a fundamental difference?
- does this approach force our architectures for large enterprise applications to be even more modularized than in the old days? Just to enable the AI to focus its attention to a limited amount of code? Will that affect our ability to let AI design and implement large systems (5.000.000+ LOC)?
One of my biggest concerns atm is mid/long term skill erosion for the generation after us, and if we're unlucky even in our own generation due to lack of enough exposure to software engineering problems/activities: designing, coding, debugging but also innovating coding approaches. I am not sure whether AI will invent new patterns, novel coding tricks, etc.
Anyway, this is the pioneering work the SWE community needs in order to have a chance to apply AI responsibly. Keep it up!
Thanks Eddy, good questions, and the reviewer one is the one I don't have a clean answer for.
Skill erosion, yeah, I'm worried too. I don't even know how my own mids grow into this. If a junior starts at the orchestration layer, they never build the muscle that makes them the reviewer later. You can't gate what you were never taught to see. No fix, just the same fear.
And I wouldn't bet on the models covering that gap. For me they're going the wrong way. I liked 4.5 and 4.6 better, faster, shorter, less scared to be wrong. 4.8 and 5 over-engineer everything, over-think, write a wall of comments just to cover their ass, and while they're at it they make more mistakes, or worse ones. So no, I don't see AI replacing engineers yet, and this generation of models doesn't impress me.
The determinism vs compilers thing is its own post, I think. Codebase for this one was ~ 50-60к LOC.
Appreciate the thoughtful read man. This is exactly the pushback I want.
you‘re welcome Denis! really appreciate you take the time to respond to all my questions
Interesting. It is the most formidable attempt to fix the problems that using agents create 😁 And I respect it for that. The EXPERT in the loop is unavoidable as you state in the article. And the false negatives as hard to detect as before. Not sure if being faster, not sure if better, worth all what people is doing. And not sure if any dev has improved his quality of life after this. Anyway, I'm pretty sure your work flow is the exception, not the norm. I appreciated your honesty and professionalty for sharing it, as usual. Thanks.
Thanks Ibon. Yeah, you nailed the part I kind of skipped over. The gate is me, and I don't run at 100% every day. Good day, I read every diff. Tired or annoyed or just done by 6pm, and stuff slips. And the agent doesn't slow down when I do, so one lazy day and it buries me for two.
And yeah, exception not the norm, agreed. That's the ugly bit. It works because I babysit it, and babysitting isn't a system, it's just me having a good week.
And that is what I'm repeating these days: you can not harness a power law. You can not harness a earthquake 😁
I have ideas. Redundancy and voting algorithms could at least detect and warn the expert in the loop that an earthquake is happening in one, two or 3 of his models. A doctor could be warned of the reliability of the diagnostic if 4 of 5 models say the same thing. It is not a 100% solution, of course. But if people is so committed to use LLMs as oracles, at least we are decreasing the risk for the patients of that doctor that will remain as babysitter of the resulting system. Yeah, I have ideas 😁 What I don't have is a source of income 😁
You didn't ship anything then
That's fking pathetic. Thanks for doing your part in ruining the job and SWE discipline for all of us. Unsubscribed.
Did you read the article, dude?
I skimmed but yeah why would I when developers are suffering because of this shit.
Article protects SWE, lol
Seems like you bullet-proofed your system. You probably have to since generating from Figma is pure brute force with no system behind it.
I started experimenting with design systems and they look promising. I just published a module of my course using airtable design system.
It works in layers:
- raw content in md
- page layout in md (structure+intent)
- page style reference derived from airtable design system
I’m currently experimenting with carousel slides.
IMHO the beauty of this approach (exploration truly) is consistency and flexibility-I may switch soon to Mistral design system 😉
Btw - Claude design generates design systems from Figma
How do you define a subagent with that specific role? I doubt it's just a skill file.
Example:
---
name: fullstack-typescript-enforcer
description: Strict TypeScript implementation agent for React + Node.js. Use when writing new components, API endpoints, or DB operations. Enforces zero-any, Zod validation, DAL patterns, error boundaries, and tests plus JSDoc for every export. Generates code — does not review existing changesets (use review-fullstack).
model: inherit
color: green
---
You are a strict TypeScript enforcer for React + Node.js applications. Your job: ensure all code follows established patterns, is properly typed, and meets architectural standards. Zero tolerance for shortcuts.
## STEP 0 — read the project rules before anything else
Before reading task files or writing a single line, read `~/.claude/memory/MEMORY.md` and EVERY file it references. Global memory is NOT auto-loaded into your context — you must read it yourself. These files are the authoritative, non-negotiable project rules (they extend and can override the rules below). If any instruction you were given conflicts with memory, memory wins — flag it and stop rather than guess.
If `~/.claude/memory/MEMORY.md` or the directory doesn't exist, skip this step silently and work from `CLAUDE.md`, the rules below, and the codebase's own patterns. Missing global memory is never a reason to stop or to ask for it.
## How to Work
1. **Pattern match first** — before writing ANY code, find 2-3 similar implementations in the codebase (`grep`, read files in the same domain). Match their structure, naming, and patterns exactly.
2. Generate code against the rules below.
3. Every exported function must have a test and JSDoc. No exceptions.
## Frontend Rules
- **State**: useState/useReducer + react-query only. No Redux, Zustand, or global stores.
- **Styling**: Chakra UI exclusively
- **Types**: Discriminated unions for variants. Interfaces for props. Zero `any`.
- **Error handling**: Error boundaries on all async pages/components
- **Structure**: Co-locate logic with UI. Extract reusable hooks to shared.
- **Components**: Function components only. Proper dependency arrays in hooks. Memoize expensive computations.
## Backend Rules
- **Async**: async/await only. Never `.then()` chains.
- **Validation**: Zod schemas on ALL user input — no exceptions
- **Data access**: Objection.js wrapped in DAL pattern. Never raw queries in routes.
- **Transactions**: Multi-step DB operations MUST use transactions. But do NOT wrap single-write ops in `knex.transaction()` — only for multi-step writes or TOCTOU patterns. A read + single write is NOT a TOCTOU concern.
- **Migrations**: Idempotent and reversible
- **Errors**: Consistent error response format with proper HTTP status codes
## TypeScript Standards
- Strict mode. No implicit any. Strict null checks.
- Interfaces over types for object shapes
- No unused parameters or variables
- Discriminated unions > type assertions
- Generic types where reuse is obvious
## Constraints
- **Never introduce new libraries** without user approval
- **Follow existing patterns** — analyze before creating new abstractions
- **Functional programming first** — immutability, pure functions, composition
- **Respect boundaries** — client code in `src/lib/client/`, server in `src/lib/server/`
- **Use existing utilities** from `src/lib/shared/` before creating new ones
## Output
Code with a brief explanation, plus the test file.
For your Claude agent, are you using Opus? I find Opus got dumber over time.
I'm using 4.8 right now; 5.0 is not usable for me.