← Back to home

Vibe Coding for Senior Engineers

I use Claude Code with plan mode and structured prompts. The key insight: you're not just prompting - you're training Claude to understand your codebase. Over time, the prompts get shorter as the knowledge lives in your repo's markdown files.

ultrathink

Add ultrathink to your prompt to enable Claude's extended thinking mode. This produces more thorough analysis and better results for complex tasks. I use it for most non-trivial work.

The Workflow

Claude Code gets smarter about your codebase over time through three phases:

1. Bootstrap Phase

Use long 3-part prompts to teach Claude your codebase structure, patterns, and conventions. This is front-loaded work that pays off quickly.

2. Learning Capture

After each session, use end prompts to have Claude update claude.md and agents.md files with what it learned.

3. Mature Phase

Once your markdown files are comprehensive, Claude reads them automatically. No more long prompts needed - just describe your task.

Bootstrap: The 3-Part Prompt

Use this structure when starting with a new codebase or when Claude doesn't have good context yet.

Part 1 - Repo Context

Describe your repository structure, tech stack, and high-level architecture. Include your preferences.

Example:

This is a monorepo with a Next.js frontend (apps/web) and an Express API (apps/api). Shared packages live in packages/.

Data hierarchy: Organization → Workspace → Project → Task.

I want minimal working solutions over complex implementations. Avoid over-engineering.

Example (serverless):

This is an AWS serverless backend using CDK. It has Lambda functions for document processing, DynamoDB for storage, and SQS for async workflows.

The document pipeline: Ingestion → Processing → Storage → Search indexing.

Keep functions small and focused. Prefer composition over complexity.

Part 2 - Feature Context

Describe the specific feature area you're working on. Include relevant implementation details Claude should know.

Example:

We have a recurring tasks feature. Regular tasks are stored as single records, but recurring tasks use the RRULE standard (RFC 5545) to spawn occurrences without writing each one to the database.

The recurrence logic lives in packages/scheduling/.

Example:

We're building a third-party integration that syncs documents to ExternalService. The sync is one-way (our system → external). Documents are uploaded via a 3-step API: create session, upload content, create record.

We need to map our metadata fields to their schema - not all fields map 1:1.

Part 3 - Task

Now describe what you want done. Be specific.

Examples:

  • See Linear ticket PROJ-123, create a new branch from main and implement it.
  • Look at the service layer (packages/services) and identify opportunities to improve maintainability and reduce duplication. I want consistent patterns across all entities.
  • This branch implements customer deletion. Do a strict code review and identify what's missing for all customer data to be properly hard deleted.
  • We're migrating from AWS to a cloud-agnostic setup. List what functionality we have in the CDK stack and what needs to be migrated vs deleted.

End of Session: Capture Learnings

Use these prompts after completing a feature to build up Claude's knowledge base.

For complex features:

Write a short, high-level description of the feature and store it in a README file in the feature's directory. If one exists, update it.

Before merging:

Analyze the implementation and consider if anything else needs to be done for it to be production ready. Clean up any test/debug code.

If ready, commit, push, and create a PR.

Knowledge capture:

What did you learn in this session that, if you had known earlier, would have let you complete the task faster?

After Claude answers:

Take the learnings that could help future sessions, condense them, and add them to the claude.md or agents.md files.

Over time, this builds comprehensive context files. Eventually you'll just say "implement PROJ-456" and Claude will know everything it needs.

Code Reviews

Reviewing PRs

Check out the branch first - Claude sometimes gives wrong results if you run /review from main.

Write inline comments for the critical, high, and medium priority issues, then approve.

Write inline comments for the critical and high priority issues, then request changes.

Handling PR Comments

See and fix the issues pointed out in PR comments. Then resolve the comments in GitHub.

Quality Assurance

Use this pattern to verify Claude understands the code before asking it to analyze.

Tell me the intended purpose of this endpoint.

Claude answers. Verify it's correct, then:

Correct. Now analyze the endpoint end-to-end and verify it works as intended.