Need to have good restraints, testing, verification
Manual QA
Tests: unit tests, integration tests, architecture tests
Mutation testing
Skills to tell agent how to test/verify code it produces
Can build custom debuggers, add harnesses to ensure whatever code is produced works correctly
Can make/use tools to help validate the functionality of the app/code
Claude Code
Workflow
Plan mode (shift-tab)
It will just think through things instead of generate / modify code
Use a CLAUDE.md file
The brain / memory for your project; similar to cursor rules
/init will auto generate it for you
Use git as a checkpoint system
Claude code doesn't have good rollback feature like Cursor
When happy with changes, make a commit
Use screenshots / folders
Can drag in images or folders
Can use web search for having Claude read documentation or look something up
Use subagents
Claude has ability to spin up subagents, which are instances of Claude code with their own context that will go off in parallel
Useful for long / large tasks
When it's done, ask it to double check its work and/or find any edge cases
Also make sure you review its work
Uncle Bob on Software Fundamentals in the Age of AI (link)
His approach is to start pulling himself a bit away from the code and full human review, to construct scaffolding around the code so that you don’t have to interact with it much yourself and the agent is constrained enough so that it doesn't make a mistake
You can try to stuff everything in a CLAUDE.md, but that can get long and they can just treat them as "guidelines" and not actually follow them
There's a "lost in the middle" phenomenon where the stuff at the very beginning and end of the conversation have more prominence than the stuff in the middle and can get forgotten
The key with agents is to trim that initial prompt down to the absolute minimum where you can get as much of it as possible into it's a priority and then do deterministic/automated tools/checks after the fact
When using the automated checks, you're slowing it down and putting it in a "loop" by basically saying "you must change the code until this tool(s) say that it's okay"
Matt thinks large Multi-agent architecture/flows can get overwhelming and keep you out of the loop, but it can be useful to break out separate implementation and review agents
First have it do the implementation and its kind of like a red-green refactor approach, where the implementer writes the bad tests nd then make it work. It doesn't have to make it beautiful
Then the reviewer comes in and it doesn't have to do the exploration because it already has the diff from the implementer, and it knows exactly what its reviewing
Then you compile a lot more steering instructions in there because the task is much less constrained
Uncle Bob likes multi agents to keep things focused though
He uses a specifier that takes a human written document and turns it into a gherkin and QA procedure (system test)
Have it write it from a human's point of view "You are a human. You are operating this system at the UI. You must prove that the system works"
Then those documents feed into the coder whose job is to write unit tests and the code that implements the described "story" and also get the gherkin tests working
Then once that's working, that gets fed into a cleaner agent, who's job is to run crap analysis and general code review and clean up whatever mess the implementer made
Then it goes to a hardener who runs the mutation testing and is merciless
Then goes through a QA agent who takes the QA document and turns it into an executable script that manipulates the system and comes up with a deterministic result
It's important to keep the direction/trajectory of the model and it's context window focused and unconfused where it knows the direction its going in and everything in the context window is consistent, then its not going to have crazy hallucinations or misalignment
@27 Bob uses an architecture viewer to visualize things and drill down as needed
Planning up front
The tempation is to specify, specify, specify but that's where the waterfall method went wrong where all the heavy upfront planning makes a mess of everything, because what comes out at the end doesn't looks like the plan and never has
The temptation with agents is to do the same thing and plan, plan, plan. Then we'll give it to the agent
Uncle Bob tried this but its always a disaster where you make the plan but as the agents are running, you as the human realize that they can't follow that plan because you didn't think of everything, and they're not as wise as you are.
So they're running off on some half-baked plan, and you have to stop, back up, rewrite the plan, and then start them over
So he's given up on that and started to try an agile approach, where they do a story or two and then he'll look at the architecture at the end and maybe manually get involved
Then a few more stories, and so on
$1 house analogy
As-you-go changes are cheap now with AI. The up front planning can be expensive
Bob uses spec as ephemeral starting points that can change, and doesn't persist them
Source code is the
The thing he's been doing lately is instead of creating a specification that defines what he wants or defines what he has, he looks at the end result and says, "Well, that is a specification."
He's got a bunch of custom tools he built for testing and keeping them in a harness
John Ousterhout strategic vs tactical programming: agents are good at lower level tactical but now are job as developers is to be the strategic
Resources and books to grow as a strategic programmer
Tom DeMarco or Ed Yordan books
Programatic Programmer
AI is just the next abstraction layer just like we went from binary, to Assembly, to C, to higher languages like Java and Python
At each of those abstraction steps, there were people complaining that it was going to ruin everything, just like they are where they are with AI
All the software fundamentals stay the same, and things aren't changing. It's just a new abstraction layer
Even Plato back then said that writing was going to make people stupider lol