Latest / AI Fire Daily / #673 Neil: 4 Claude Code Tips to Make Better Project Decisions Fast

Transcript

#673 Neil: 4 Claude Code Tips to Make Better Project Decisions Fast · AI Fire Daily

• 0:00
  Most of us are paying for genius level AI. But
• 0:03
  we honestly treat it like an overworked intern.
• 0:05
  Yeah, exactly. You have one of the smartest coding
• 0:08
  assistants in the world, I mean, Clud Code. And
• 0:11
  you are probably using it like a very expensive
• 0:13
  copy and paste machine. That is a harsh truth
• 0:16
  to confront. It really is. Welcome to this deep
• 0:19
  dive. Today, we are exploring a framework used
• 0:21
  by Anthropics' own engineers. It completely changes
• 0:25
  how you build software. We will cover four specific
• 0:27
  strategies. These techniques will help you get
• 0:30
  significantly better results. And you will do
• 0:32
  it with far less effort. Just massive time savings.
• 0:36
  Absolutely. And honestly, I still wrestle with
• 0:38
  micromanaging the AI myself. It is a really hard
• 0:42
  habit to break. Oh, I get it. We are so used
• 0:45
  to being the ultimate bottleneck. Right. We grew
• 0:48
  up on standard autocomplete. But Anthropix team
• 0:51
  approaches this entirely differently. D -Let
• 0:53
  Claude suggests better ideas. Exactly. They let
• 0:56
  it architect and plan entire projects. They hand
• 0:59
  over the heavy cognitive lifting. Most of us
• 1:02
  are still doing that completely manually. It
• 1:04
  is a profound psychological shift. We have to
• 1:07
  move from assigning tasks to assigning goals.
• 1:10
  You can't reach a destination if you just yell
• 1:12
  directions. Without ever sharing the map. Right.
• 1:14
  Let's unpack that first strategy. Give goals,
• 1:17
  not tasks. OK. So think about the classic red
• 1:19
  button approach. Let's say you want to increase
• 1:22
  your newsletter signups. OK. You go to Claude
• 1:24
  Code. You tell it to make the subscribe button
• 1:27
  20 % bigger. You tell it to change the color
• 1:30
  to bright red. And Claude follows your instructions
• 1:32
  perfectly. Yep. The button is now massive. It
• 1:35
  is bright red. It does exactly what you asked.
• 1:37
  Exactly. But did you actually get more subscribers?
• 1:42
  Nobody knows. Right. Nobody knows. That is the
• 1:45
  fundamental trap right there. You came up with
• 1:47
  a proposed solution first. You just assumed your
• 1:50
  idea was the correct one. Yes. You made the most
• 1:53
  critical architectural decision upfront. The
• 1:56
  AI never even had a chance to evaluate the problem.
• 1:59
  It is honestly like hiring a master architect
• 2:01
  just to hammer nails. That is a great way to
• 2:04
  put it. It is a complete waste of cognitive potential.
• 2:07
  So how do anthropics engineers actually fix this?
• 2:10
  They use a technique called goal -oriented prompting.
• 2:13
  Instead of asking for that red button, you shift
• 2:17
  the focus entirely. You give Claude a clear,
• 2:20
  measurable goal. Exactly. You tell the system,
• 2:22
  I want to improve the sign up conversion rate.
• 2:25
  You point it at the landing page. Then you step
• 2:28
  back. You ask the AI to review the current page
• 2:31
  architecture. Yeah. You ask it to identify the
• 2:34
  specific friction points, what stops visitors
• 2:36
  from subscribing. And crucially, you require
• 2:39
  it to explain its logical reasoning. Before it
• 2:42
  writes a single line of code. Exactly. So by
• 2:45
  doing that, the AI might notice the form is completely
• 2:48
  hidden on mobile. It suggests moving the input
• 2:50
  field higher up the page. It actually fixes the
• 2:53
  underlying problem. Right. And this leads directly
• 2:56
  to the goal -first project advisor prompt. Which
• 2:59
  is a very specific instruction set. It is. You
• 3:02
  feed it to Claude before starting a sprint. It
• 3:05
  explicitly instructs the AI to aggressively evaluate
• 3:08
  your initial idea. It maps your proposed feature
• 3:11
  against the core user problem. Yep. If they don't
• 3:13
  align, it recommends entirely alternative approaches.
• 3:17
  It acts as a strategic filter. It forces the
• 3:20
  AI to challenge your fundamental assumptions.
• 3:22
  In the source material, the author actually used
• 3:24
  this technique. They used it for their Dayboard
• 3:26
  project. Right, the productivity application.
• 3:29
  The developer went in wanting to build a massive
• 3:31
  calendar feature. They were absolutely convinced
• 3:33
  it was the perfect solution. But because they
• 3:36
  used that goal -first prompt, Claude actually
• 3:39
  pushed back. Yeah, it evaluated the core goal.
• 3:42
  The goal was to reduce user overwhelm. And Claude
• 3:45
  pointed out that a giant complex calendar usually
• 3:49
  increases anxiety. Exactly. It suggested a much
• 3:51
  simpler next up feature instead. Which was designed
• 3:54
  to just help users focus entirely on the immediate
• 3:57
  next task. Nothing else. And that simpler feature
• 4:00
  was actually the superior solution. It aligned
• 4:03
  perfectly with the psychology of the user. Think
• 4:05
  about the mechanics of that for a second. By
• 4:07
  challenging the initial premise, Claude saved
• 4:10
  that developer days of work. Maybe even weeks
• 4:13
  of unnecessary custom widget coding. It pointed
• 4:16
  out the architectural flaws before any bad decisions
• 4:18
  were hard -coded. It is huge. But I have to ask,
• 4:23
  why is it so hard for us to let the AI define
• 4:25
  the solution? Honestly, I think it comes down
• 4:28
  to human ego and deep -rooted professional habits,
• 4:32
  you know? We have spent our entire careers proving
• 4:34
  our value by coming up with the correct answers.
• 4:37
  Handing that creative control over to a machine
• 4:40
  just feels deeply unnatural. We're addicted to
• 4:43
  controlling the process, not just the outcome.
• 4:45
  Exactly. But once you do swallow your ego and
• 4:49
  you establish that right goal, how do you evaluate
• 4:53
  the AI's proposed solution? Because text descriptions
• 4:56
  of user interfaces are notoriously terrible.
• 4:59
  They really are. You need to actually see it
• 5:01
  before you build it. Reading a 10 -page planning
• 5:04
  document is utterly exhausting. It is practically
• 5:07
  impossible to visualize a final product from
• 5:10
  a flat text chat. That is exactly why visual
• 5:13
  planning is so incredibly powerful. Let's move
• 5:16
  to our second strategy, plan visually. Right.
• 5:19
  Instead of arguing over text, you ask cloud code
• 5:22
  to generate interactive prototypes. You have
• 5:24
  it spit out clean HTML, CSS, and JavaScript.
• 5:28
  You essentially force the AI to compare tangible
• 5:30
  designs. You do this before writing any real
• 5:33
  production code. This visual mockup acts as a
• 5:36
  solid anchor. It definitively stops the AI from
• 5:39
  hallucinating user interface details. It stops
• 5:42
  that massive 30 -message threat of confusion.
• 5:45
  You just build a dedicated visual planning page.
• 5:48
  The underlying prompt for this is fantastic.
• 5:51
  You explicitly ask Claude to create three genuinely
• 5:54
  different design options. You aren't asking for
• 5:57
  minor tweaks here. You ask for realistic mockups.
• 6:00
  They need to be populated with actual sample
• 6:02
  content. You demand both desktop and mobile previews,
• 6:06
  side by side. And you require interactive controls.
• 6:08
  You need to actually click around and explore
• 6:10
  each distinct option. You also instructed to
• 6:13
  include a built -in feedback panel. Yeah, that
• 6:15
  part is brilliant. So you can simply select your
• 6:18
  preferred design right there on the page. You
• 6:19
  leave comments on individual UI sections. The
• 6:22
  AI then automatically summarizes all your feedback.
• 6:24
  And it uses that summary in the actual build
• 6:27
  phase later. The author of our sources tested
• 6:30
  this specific method. They used an application
• 6:32
  called MealMap. Right, it is a complex meal planning
• 6:36
  app. Now, meal planning requires intricate drag
• 6:39
  -and -drop interfaces. Describing that behavior
• 6:42
  in a text prompt is awful. It usually results
• 6:44
  in a confusing, tangled conversation. So, instead
• 6:47
  of that text mess, Claude just built three side
• 6:50
  -by -side layouts. Interactive web layouts. They
• 6:53
  could actually click through each distinct design
• 6:55
  in their browser. They could feel how the drag
• 6:58
  -and -drop features actually worked in real time.
• 7:00
  It completely eliminated the translation gap.
• 7:02
  The gap between the human's imagination and the
• 7:04
  AI's output. It is a tangible, testable prototype.
• 7:08
  And if you really want to give granular feedback,
• 7:11
  the source is mentioned using Lavish. Oh, Lavish
• 7:13
  is great. It is an open source tool designed
• 7:15
  specifically for commenting directly on these
• 7:18
  visual plans. You literally point at a button,
• 7:20
  you click it, and you critique the padding, or
• 7:22
  you critique the color. It saves an unbelievable
• 7:25
  amount of frustration. The mechanics of Lavish
• 7:28
  are brilliant. It captures the exact DOM elements.
• 7:32
  It translates your clicks into highly specific
• 7:34
  coordinate -based prompts. If Claude keeps getting
• 7:37
  a layout wrong, you have to stop texting it.
• 7:40
  Right. Ask it to show you a functional mockup
• 7:42
  first. It is so much easier to explain exactly
• 7:45
  what needs fixing, especially when you can literally
• 7:48
  point at it on your screen. Wait, hold on. Does
• 7:51
  making a separate HTML page slow down the initial
• 7:54
  momentum? Not really. Because AI generates boilerplate
• 7:57
  HTML in seconds, that tiny momentary delay up
• 8:01
  front is absolutely nothing. Compared to the
• 8:03
  countless hours you save. Exactly. You completely
• 8:06
  avoid refactoring thousands of lines of tangled
• 8:08
  production code later in the week. A slight pause
• 8:11
  up front prevents massive coding detours later.
• 8:13
  Absolutely. We are going to take a very quick
• 8:15
  break right here. We will be right back. Sounds
• 8:17
  good. And we are back. Now, having beautiful
• 8:22
  visuals is excellent. But if the AI doesn't know
• 8:25
  your specific project constraints, it will fail.
• 8:27
  Yeah, it will just generate generic, unworkable
• 8:30
  designs. It needs the right environment to operate
• 8:32
  successfully. Which naturally leads us to our
• 8:35
  third strategy. Provide access, context, and
• 8:39
  feedback. We often assume that giving clear,
• 8:42
  isolated instructions is enough. It absolutely
• 8:45
  isn't. Claude needs to deeply understand how
• 8:48
  your specific architecture actually works. We
• 8:51
  are talking about context engineering. Yes. Context
• 8:55
  engineering. Giving the AI background information
• 8:58
  so it never guesses. There are three distinct
• 9:00
  pillars to this strategy. The first pillar is
• 9:03
  access. You have to connect your daily tools.
• 9:06
  Gmail, Notion, GitHub. You use the official Claude
• 9:10
  connectors to bridge these systems, but, and
• 9:12
  this is critical, you must limit those permissions
• 9:15
  strictly. If Claude only needs to read a requirements
• 9:17
  document, restrict it. Right. Do not give it
• 9:20
  permission to delete or overwrite your files.
• 9:22
  You have to treat it like a brilliant but slightly
• 9:25
  unpredictable contractor. The second pillar is
• 9:28
  context. It is all about establishing the unwritten
• 9:31
  rules and goals of your code base. It is so important.
• 9:34
  It is honestly like dropping a Michelin star
• 9:36
  chef into a pitch black locked kitchen and demanding
• 9:40
  a perfect souffle. That is a perfect analogy.
• 9:44
  They might be an absolute genius. But they still
• 9:46
  need to know exactly where you keep the ingredients
• 9:48
  and who they are actually cooking for. Exactly.
• 9:51
  If you are building a specialized app for elderly
• 9:54
  beginners, you have to tell Claude. Explicitly
• 9:57
  tell it upfront. Tell it to keep the interface
• 9:59
  elements large and simple. Tell it to actively
• 10:02
  avoid complex, hidden swipe features. You have
• 10:05
  to rigorously document your internal decision
• 10:07
  -making rules. And the third pillar revolves
• 10:10
  around AI feedback loops. Claude must continuously
• 10:14
  learn from your real -world project constraints.
• 10:16
  It needs to actively review resolved GitHub issues.
• 10:20
  It needs to analyze customer support emails.
• 10:22
  It needs to look at crash reports. It separates
• 10:25
  verified real -world feedback from mere developer
• 10:28
  assumptions. To manage all this complexity, Anthropic
• 10:31
  engineers use a specific prompt. The workflow
• 10:35
  advisor prompt. Right. It asks Claude to systematically
• 10:40
  audit its own access permissions. It scans the
• 10:43
  repository to find missing contextual pieces.
• 10:46
  It groups your scattered feedback into coherent
• 10:49
  themes. Then, it establishes reusable permanent
• 10:53
  rules in a centralized file. In most modern projects,
• 10:56
  that is simply a claw .md file. Yep, just a simple
• 10:59
  markdown file. It essentially creates a permanent
• 11:02
  searchable memory for your specific project.
• 11:05
  By referencing that file automatically, the AI
• 11:07
  stops asking the exact same clarifying questions
• 11:10
  every single day. Every single day. The author
• 11:13
  actually ran this automated audit on their own
• 11:16
  active project. And Claude found glaring contextual
• 11:19
  gaps they hadn't even noticed themselves. It
• 11:21
  organized everything so beautifully. All future
• 11:24
  coding tasks were perfectly framed from the very
• 11:26
  first prompt. It fundamentally changed how the
• 11:29
  AI interacted with the code base. I do struggle
• 11:32
  with this part, though. How do we balance giving
• 11:34
  enough context without overwhelming the token
• 11:37
  limit? Well, you rely heavily on that markdown
• 11:40
  file. You define your absolute core, unchanging
• 11:43
  rules right there. Things like always use Tailwind
• 11:46
  CSS. Exactly. Or prefer functional React components.
• 11:50
  Then for individual daily tasks, you only pass
• 11:53
  in the specific dynamic new feedback. Just the
• 11:56
  issue data that actually matters for that exact
• 11:58
  moment. Right. Keep the token count manageable.
• 12:02
  Keep the core rules static. and only feed in
• 12:04
  relevant new feedback. Exactly. Okay, so now
• 12:08
  Claude has the correct goals, it has the visual
• 12:10
  blueprints, and it fully understands the precise
• 12:13
  context of our kitchen. It is time to scale this
• 12:16
  up. We are moving from managing a single smart
• 12:19
  assistant to orchestrating an entire automated
• 12:21
  team. This is our fourth and final strategy,
• 12:25
  build custom AI workflows. This is where things
• 12:28
  get genuinely wild. We are officially moving
• 12:31
  into Harness engineering. Oh, yeah. Harness engineering.
• 12:36
  Setting up a structured workflow to guide the
• 12:38
  AI. Historically, we would just ask Claude to
• 12:42
  review an entire sprawling project. With one
• 12:45
  massive, poorly defined prompt. Because doing
• 12:48
  that just gives you a long, messy, unstructured
• 12:51
  list of generic issues. You still have to manually
• 12:54
  sort out the critical security flaws. You have
• 12:56
  to separate them from the trivial UI bugs. It
• 12:58
  barely saves you any time at all. So, instead
• 13:01
  of that chaos, you utilize Cloud Code sub -agents.
• 13:05
  Yes. Cloud Code sub -agents. Smaller AIs focused
• 13:10
  on one specific project job. You literally divide
• 13:13
  and conquer the workload. You give each individual
• 13:15
  agent a very narrow, highly defined scope of
• 13:18
  responsibility. Let's look closely at the mechanics
• 13:21
  of a multi -agent workflow. You split the auditing
• 13:25
  tasks. First, you deploy a functionality agent.
• 13:28
  Its sole purpose is to check whether the new
• 13:30
  features actually work as expected. It aggressively
• 13:33
  identifies weird edge cases. It looks for testing
• 13:36
  coverage gaps. Then in parallel, you deploy a
• 13:39
  security agent. It isn't looking at the UI at
• 13:41
  all. It looks purely for vulnerabilities. It
• 13:44
  rigorously checks your input handling. It reviews
• 13:46
  your authentication tokens. It flags any risky
• 13:49
  third -party dependencies you might have accidentally
• 13:51
  imported. Finally, you spin up a performance
• 13:54
  agent. It completely ignores security and focuses
• 13:57
  purely on speed. It identifies inefficient database
• 14:00
  queries. It looks for front -end rendering bottlenecks.
• 14:04
  It reviews your caching configurations. They
• 14:06
  all run their specific analysis completely independently
• 14:09
  of each other. The author did exactly this for
• 14:12
  their stock desk project. Claude acted as the
• 14:15
  master orchestrator for all three distinct subagents.
• 14:18
  They scoured the entire codebase simultaneously.
• 14:21
  They independently found 18 entirely different
• 14:24
  architectural issues. Then the main master Claude
• 14:28
  instance collected all those raw findings. It
• 14:31
  intelligently deduplicated them. It delivered
• 14:33
  one single highly actionable executive report.
• 14:37
  Imagine three specialized AIs debating your code
• 14:40
  silently. It is genuinely incredible to watch
• 14:42
  it operate. You get the profound depth of a dedicated
• 14:45
  security audit. Plus the exact precision of a
• 14:48
  performance review. and a rigorous functional
• 14:50
  check all at the exact same time. And as the
• 14:53
  human developer, you just sit back and read the
• 14:55
  synthesized executive summary. But what happens
• 14:58
  if these subagents fundamentally disagree on
• 15:00
  how to fix a bug? That is the true beauty of
• 15:03
  this specific workflow architecture. The main
• 15:05
  master prompt explicitly forces the orchestrating
• 15:08
  agent to synthesize the conflicting data. So
• 15:11
  if the security agent strongly suggests a rigid
• 15:14
  fix... A fix that completely ruins the app's
• 15:17
  performance? Yes. The master agent detects that
• 15:19
  semantic conflict. It flags that specific tension
• 15:23
  for you, the human, to decide on a compromise.
• 15:26
  Exactly. It prevents the system from accidentally
• 15:28
  breaking the build. The master agent acts as
• 15:30
  a judge, merging conflicts into one clear report.
• 15:34
  Yes. This completely and utterly redefines the
• 15:39
  fundamental role of a software developer. It
• 15:41
  really does. You are no longer manually writing
• 15:44
  every single line of syntax. You are designing
• 15:47
  and tuning the intelligent systems that write
• 15:50
  the lines for you. You create a robust, reusable
• 15:53
  workflow. You run the exact same multi -agent
• 15:56
  workflow every single time you update your project.
• 15:59
  It scales your personal output exponentially.
• 16:02
  Let's synthesize this entire journey we just
• 16:05
  took. You aren't just an individual code contributor
• 16:08
  anymore. You are drastically elevating your perspective.
• 16:14
  By setting clear goals instead of dictating tasks,
• 16:17
  you empower the AI to actually solve complex
• 16:20
  problems. By asking for interactive visual proofs,
• 16:23
  you prevent incredibly costly architectural mistakes.
• 16:27
  By providing deeply structured context, you give
• 16:30
  the AI the proper environment to succeed. And
• 16:32
  by deploying specialized subagents, you massively
• 16:35
  scale your own capabilities. You evolve from
• 16:38
  an exhausted AI micromanager into a high -level
• 16:41
  AI orchestrator. It is a massive structural upgrade
• 16:46
  in your daily productivity. You just have to
• 16:48
  trust the framework and let go of the steering
• 16:51
  wheel a little bit. You don't need to change
• 16:53
  everything about your workflow today. I want
• 16:55
  you to pick just one single strategy we discussed.
• 16:59
  Try using the goal -first project advisor prompt
• 17:01
  on your very next build. Just see what happens
• 17:03
  when you give the system a little more room to
• 17:05
  breathe and think. I bet it successfully challenges
• 17:09
  a core idea you were absolutely certain about.
• 17:12
  If an AI can now successfully challenge your
• 17:15
  ideas, generate its own interactive visual prototypes,
• 17:19
  and rigorously audit its own code using a team
• 17:21
  of sub -agents, what exactly is the unique human
• 17:25
  skill left in the workflow? That is the big question.
• 17:29
  Maybe it's simply the courage to define the right
• 17:31
  goal. Take care and happy coding.