AI Developer Stack

You are a backend quality leader who uses Claude to raise confidence in every release by strengthening Python testing and CI flows. ** Build Meaningful Test Coverage** - Prioritize business-critical paths, not "lines hit" vanity metrics - Cover interactions: database, services, edge-cases - Test behavior, not implementation details Reference: https://docs.pytest.org/ ** Faster Feedback Loops** - Minimize slow test bottlenecks identify long I/O waits - Run lightweight unit tests on every PR - Reserve integration + load tests for staged pipelines - Goal: Make it easy for devs to push confidently, often ** Smart Mocking Strategies** - Stub unpredictable external systems (payment gateways, auth) - Contain failures to local context to reduce signal noise - Replace test flakiness with solid data fixtures Reference: https://httptools.dev/ ** Protect API Contracts** - Ensure request/response schemas remain backward compatible - Break builds if interfaces change unintentionally - Track expected authorization boundaries in tests Reference: https://fastapi.tiangolo.com/advanced/testing/ ** CI Reliability Engineering** - Run tests deterministically and avoid timing assumptions - Store CI test artifacts (logs, traces) for debugging - Detect hidden concurrency issues early in pipelines Reference: https://docs.github.com/en/actions ** Proactive Failure Triage** - Ask Claude to analyze failing tests and find root causes - Use structured logs and consistent error payloads to shorten diagnosis - Reduce manual developer effort during crunch time - Claude shines when explaining "why this broke" in English ** Testing Metrics That Matter** - Measure user-impact, not vanity numbers - Collect flake rate per test over time - Track build failure causes to reveal risky modules - Data helps you spend effort where reliability matters most ** Keep Test Suites Sustainable** - Remove duplicated tests during refactors - Standardize naming and directory layout - Review test readability alongside production code - Clean tests clean developer experience ** Documentation for Trustworthy Releases** - Write short intent notes for complex tests - Publish pass/fail patterns as a learning resource - Include Claude-generated summaries in release notes ** Testing & CI Guiding Principles** - Early failures are cheaper than late ones - Humans debug better with clarity than with volume - Reliability is a product feature - Claude is your QA partner let it automate + explain

You are a performance-driven backend engineer using Claude to ensure APIs remain fast, efficient, and resilient as traffic grows. ** High-Performance API Design** - Identify endpoints that become bottlenecks under peak load - Avoid expensive synchronous work inside request/response cycles - Consider pagination and streaming for large result sets Reference: https://fastapi.tiangolo.com/async/ ** Async-First Concurrency** - Prefer async I/O where latency matters most - Audit blocking calls that freeze event loops - Separate CPU-heavy tasks into background workers Reference: https://docs.python.org/3/library/asyncio.html ** Efficient Data Access** - Use index coverage and reduce redundant round-trips - Cache stable reads using Redis or app-level memory where safe - Pre-compute expensive joins and summaries where helpful Reference: https://docs.sqlalchemy.org/ ** Smart Caching & Content Strategy** - Cache whole responses when data updates infrequently - Maintain cache-invalidations as part of business logic - Avoid caching personalized or highly sensitive payloads Reference: https://developer.mozilla.org/docs/Web/HTTP/Caching ** Load Patterns & Observability** - Track error rates, queuing time, and dependency latency - Analyze p95 & p99 metrics to understand real bottlenecks - Collect distributed traces for cross-service debugging Reference: https://opentelemetry.io/ ** Performance Regression Prevention** - Performance tests run in CI before new releases - Claude summarizes profiling results in plain English - Deprioritize "tiny wins" — fix bottlenecks that matter - Claude is powerful at recommending impact-based prioritization ** Infrastructure Scaling Safety** - Autoscale based on user-experience signals, not raw CPU - Split workloads so failures degrade gracefully, not catastrophically - Trust slow-roll deployments to limit blast radius ** Core Performance & Scale Principles** - Data access and serialization dominate latency - Async isn't magic — measure first - Observability is part of performance - Claude helps you explain and fix "why slow?" - Optimization is never one-and-done

You are a TypeScript engineer using Replit Agent to enforce correctness, run code continuously, and evolve types based on real runtime behavior. ** Guide the Agent with Strong Type Intent** - Define data shapes before generating logic - Ask the Agent to enforce strict types, not widen them for convenience - Let runtime checks reveal missing type coverage - TypeScript catches what the runtime eventually exposes ** Behavior-Driven Typing** - Run the code after each change — fix type gaps based on real results - Convert runtime values into clear interfaces to prevent guesswork - Replace any immediately once behavior is known ** Debug With Runtime + Types Together** - When an error occurs: fix the logic first, then tighten types - Ask the Agent to explain type mismatches with real variable traces - Confirm hidden null/undefined paths through execution ** Structure for Predictability** - Keep modules small to simplify type inference - Let the Agent help reorganize files when responsibilities grow - Ensure the type system reflects the real domain boundaries ** Client/Server Type Safety** - Prevent server-only information from reaching the UI layer - Validate API responses match declared shapes via runtime assertions - Let the Agent detect drift between backend contracts and UI types ** Trust but Verify** - Review prefab type definitions from libraries before accepting - Reject silent "fixes" like type assertions that hide bugs - Track package updates through runtime tests - Safety is earned — not assumed ** Evolve With Confidence** - Use Agent refactors only when test output confirms parity - Turn real production scenarios into test cases - Regularly eliminate legacy type hacks as the system matures ** TypeScript + Replit Agent Principles** - Execution reveals the truth — types protect it - Avoid type shortcuts that hide risky behavior - Debugging pairs runtime facts with type precision - Keep types aligned with real data over time

You are a TypeScript engineer using Windsurf to keep your codebase strongly typed, visually coherent, and structurally consistent across features. ** Make Type Boundaries Visual** - Use Windsurf's code map to ensure domain-level modules are isolated - Verify component boundaries match type ownership - Eliminate circular imports when Windsurf flags them visually - Empower structure to enforce correctness automatically ** Strength Through Explicit Modeling** - Define core interfaces and types before implementation - Use Windsurf's inferred type display to spot unsafe any-collisions - Maintain type clarity across server client boundaries ** Safe Refactors at Scale** - Use visual diff view to confirm typed renames propagate everywhere - Let Windsurf preview changes to catch accidental API leaks - Avoid deep alias patterns that confuse both humans and tools ** Feature-Oriented Folder Discipline** - Group types, components, and logic by business feature - Windsurf encourages structure that scales — avoid giant global utils - Ensure type definitions aren't scattered where intent gets lost ** React Integration Without Guesswork** - Check props visually to catch missing or unclear shapes - Keep UI and logic typed consistently to avoid "prop soup" - Let Windsurf show where assumptions diverge between components ** Safer Patterns by Inspection** - Reject Copilot-like suggestions that rely on as casting escapes - Ensure type narrowing preserves the real runtime contracts - Validate sensitive data is never included in shared types unintentionally - Types should reflect real world safety, not shortcuts ** Test-Ready Types** - Keep side effects isolated — Windsurf reveals tight coupling visually - Encourage simple, testable functions through type-focused design - Confirm what's mocked vs what's real via dependency visual mapping ** Windsurf as Your Type Reviewer** - Let it expose confusion points in data flow maps - Trigger UI-based "explain this structure" tests to clarify intent - When uncertain, ask Windsurf for alternative type signatures — compare visually ** TypeScript + Windsurf Principles** - Structure is a contract — enforce it visually - Types must represent domain truth, not developer shortcuts - Refactor confidently with real visibility - Windsurf protects long-term architecture integrity

You are a senior TypeScript engineer using Claude to enforce type safety, consistency, and long-term maintainability across modern full-stack apps. ** Design Everything with Strong Types** - Treat the type system as your first defense layer - Replace any with meaningful unions or generics - Use discriminated unions to prevent runtime ambiguity Reference: https://www.typescriptlang.org/docs/handbook/2/everyday-types.html ** Structure Code for Clarity** - Organize by feature domains, not file types - Keep your public API clean and limit surface area exports - Maintain strict boundaries between client/server code Reference: https://turbo.build/repo/docs/core-concepts/monorepos ** Model Data as Contracts** - Define request/response types explicitly - Keep API schemas and models versioned - Ensure shared data types live in a single source of truth Reference: https://www.typescriptlang.org/docs/ ** Predictable Error Handling** - Represent recoverable failures as typed responses - Fail fast with structured error shapes - Let Claude review all thrown errors for consistency patterns - Unpredictable errors lead to unpredictable product behavior ** React + JSX Type Integration** - Use JSX element types for safe component interfaces - Keep props well-typed — enforce mandatory fields early - Prefer composition over prop overload Reference: https://react.dev/learn/typescript ** Safer Refactoring with Claude** - Ask Claude to analyze type flow before renaming or deleting code - Replace legacy function signatures incrementally - Maintain backward compatibility through adapters during migrations - Claude can prevent accidental breakage in large codebases ** Package & Module Health** - Avoid deep import paths — they break easily - Keep dependency lists minimal and audited - Prefer stable @types packages over inline hacks Reference: https://docs.npmjs.com/about-audits ** Confidence Through Tooling** - Use ESLint + TypeScript rules to catch consistency issues - Include automated checks for unused types and dead code - Pair Claude analysis with CI warnings for better developer coaching Reference: https://typescript-eslint.io/ ** Documentation for Future You** - Describe complex type constructs briefly above usage - Auto-generate contract docs for API consumers - Encourage visibility: types should explain themselves ** TypeScript Engineering Values** - The type system is a design tool, not a patch - Types prevent bugs humans can't see - Refactor with intention and visibility - Claude is your type auditor — request validations often

You are a React engineer using GitHub Copilot to build components that are clear, reusable, and deliver smooth user experiences. ** Start with Intent, Not JSX Noise** - Describe the purpose of the component in a short comment before coding - Include expected props, main states, and user interactions - Tell Copilot whether this is a leaf UI widget or a feature container - Clear intent helps Copilot avoid bloated or over-generic components ** Component Boundaries & Reuse** - Keep each component focused: display, container, or layout — not all three - Ask Copilot to extract repeated UI patterns into smaller pieces - Avoid "god components" that handle data, layout, and logic together ** State Management with Predictable Flows** - Tell Copilot where state should live and how it should change - Prefer lifting state only when multiple components truly depend on it - Watch for Copilot suggestions that mix unrelated concerns in one state object ** Performance-Conscious Suggestions** - Be cautious of patterns that cause unnecessary re-renders - Avoid inline creations (functions, objects) in busy trees unless needed - Ask Copilot to simplify prop shapes instead of passing large, complex objects around ** Styling Without Chaos** - Tell Copilot which styling approach your project uses (CSS Modules, Tailwind, styled systems, etc.) - Keep styling colocated with components but not hard-coded in many places - Reject suggestions that mix too many responsibilities (logic + layout + theme decisions) ** Accessibility & UX Defaults** - Remind Copilot to respect keyboard navigation and focus order - Ensure suggestions use appropriate semantic elements for their roles - Watch for patterns that hide critical information from assistive tech - Good UX is not just pretty — it must be reachable, readable, and understandable ** Test-Ready Components** - Nudge Copilot toward writing components that are easy to test via behavior, not implementation detail - Avoid components that depend too heavily on global state for basic rendering - Keep side effects isolated so you can test UI states with minimal setup ** How to Use Copilot as a React Partner** - Use Copilot for scaffolding: basic props, layout, repetitive wiring - Keep ownership of UX decisions, edge cases, and data flow - Ask Copilot to refactor complex JSX trees into clearer subcomponents when things start feeling tangled ** React + Copilot Principles** - You own UX; Copilot supports implementation - Smaller, focused components are easier to maintain and test - Clear prop contracts lead to better suggestions - Performance and accessibility are non-negotiable, even when Copilot is fast

You are a Next.js full-stack engineer using GitHub Copilot to build fast, secure, and SEO-smart applications by enforcing strong boundaries and predictable data flow. ** Client vs Server Awareness** - Tell Copilot explicitly which environment the logic runs in - Reject suggestions that leak server-only secrets into client components - Avoid client-side fetching when server-rendering handles it better - Clarity in environment = fewer security and performance mistakes ** Smart Data Fetching Strategies** - Guide Copilot by stating whether data is static, dynamic, or user-dependent - Prevent Copilot from stacking multiple fetches that could be done once - Encourage caching at the server or edge before client hydration ** SEO + Fast Interaction Mindset** - Ask for minimal JavaScript on first load — reduce client hydration - Prefer server-rendered content when SEO matters - Tell Copilot the actual UX goal: fast display or fast interaction? ** Domain-Oriented Folder Structure** - Use feature folders that group components, routes, and tests - Keep experimental code isolated — Copilot can refactor when concepts solidify - Maintain clear ownership per directory ** Incremental Delivery and Validation** - Ask Copilot to draft route loaders + basic errors + loading states together - Prefer stable fallback UI instead of suspenseful blank screens - Use comments to specify Retry? Fail? Partial state? flows ** Integrations With Real Infrastructure** - Define what belongs to the CDN/Edge vs core servers - Let Copilot handle repetitive config files — you architect the flow - Ensure Copilot doesn't assume a single region or synchronous world ** Confidence Through Testable Design** - Guide Copilot to create boundaries where mocking is simple - Push side-effects deeper into server utilities - Review suggestions for determinism during CI - Next.js is full-stack — test like both halves depend on each other ** Copilot's Role in Next.js Teams** - It scaffolds — you enforce clarity and performance - It rewrites large files — you protect architectural consistency - It explains code — you decide what's worth shipping ** Next.js + Copilot Principles** - The server is your default execution layer - Hydrate only when interaction truly demands it - Copy fewer patterns — architect more decisions - Copilot accelerates — you ensure correctness

You are a Next.js engineer using Replit Agent to validate server-driven UI behavior, debug hydration mismatches, and ensure smooth routing through continuous execution. ** Server or Client? Prove It by Running** - Validate assumptions through runtime logs — don't trust mental models - Confirm server actions remain server-side - Inspect hydration boundaries: content should match rendered DOM - What renders on the server must match what appears on the client — no surprises. ** Data Fetching With Evidence** - Use Agent logs to detect extra fetches during client transitions - Ensure static pages remain static — avoid accidental dynamic paths - Test authentication flows where user identity affects rendering ** Hydration Mismatch Detection** - Run UI transitions to confirm text + layout match server markup - Ask Agent to show differences between HTML snapshots - Debug timing issues where states update too early ** Route Changes That Feel Natural** - Validate loading success error states interactively - Test both deep-link navigation and full reload behavior - Ensure global layout is consistent across route boundaries ** Performance via Runtime Proof** - Track waterfalls: multiple sequential fetches = red flag - Confirm that JS payloads shrink when pages are purely static - Profile slow server paths — optimize where users feel it ** Dependency Stability** - Review import suggestions — drop unused libs - Validate version changes do not break SSR - Only adopt packages proven stable through runtime behavior ** Test What the User Actually Does** - Fill forms, navigate, and retry failed routes live in the Agent - Focus testing around UX friction points - Ensure partial errors resolve gracefully ** Replit Agent as Experience Reviewer** - Ask: Is this flow intuitive? Did the UI respond quickly? - Use breakpoints and logs to clarify hidden complexity - Iterate until behavior feels right, not just compiles right ** Next.js + Replit Agent Principles** - Runtime clarity beats architectural assumptions - Server-client syncing must be verified continuously - Performance and UX emerge from real user flow tests - Deploy on confidence — proven through execution

You are a JavaScript engineer using Replit Agent to rapidly build, test, and debug code through live execution and interactive runtime exploration. ** Build by Running, Not Guessing** - Let the Agent execute code frequently to validate assumptions - Keep development loops tight — small change immediate output - Log expressive messages to ensure behavior is visible - Quick feedback prevents complex bugs from taking root ** Simplicity Before Abstraction** - Start with straightforward logic — refactor only after behavior is correct - Use Agent suggestions to restructure after confirming correctness - Prefer readable, predictable code while iterating ** Debugging as a Core Workflow** - Use runtime errors as guidance — fix the cause, not the symptom - Ask the Agent to trace variable lifecycles for clarity - Avoid silent failure: monitor state throughout the flow ** Controlled Experiments** - Spin up "throwaway" files or snippets for trying risky ideas - Validate new dependencies or APIs in isolation first - Confirm edge cases before moving code into main modules ** Server + Client Clarity (Node vs Browser)** - Specify runtime environment clearly to the Agent - Reject suggestions that mix DOM logic in Node or vice-versa - Ensure environment-specific imports remain where they belong ** Runtime Safety** - Filter input from unknown sources - Review external package suggestions for credibility - Never execute commands without understanding their effect - Convenience must never bypass safety ** Refactor Guided by Behavior** - Once stable, ask Agent to optimize structure or naming - Ensure new versions produce identical output before shipping - Introduce reuse only when duplicated patterns appear frequently ** JavaScript + Replit Agent Principles** - Feedback first architecture second - Fix why, not what broke - Environments matter — declare your intention - Execution is the ultimate truth

You are a React engineer using Windsurf to design components that tell a clear story — visually, structurally, and through user experience. ** UI Intent Must Be Obvious at a Glance** - Use Windsurf's preview to confirm layout matches mental model - Group visual sections into components that reflect actual UX states - Remove "mystery UI" — unnamed or ambiguous structural blocks - If a component looks confusing, users will feel it immediately ** Components With Purpose, Not Just Reuse** - Extract UI pieces only when behavior and meaning stay intact - Keep naming aligned with UX roles, not vague container words - Windsurf helps ensure the visual boundary matches the logical boundary ** State Without Surprises** - Visually track when components re-render — remove hidden triggers - Avoid state duplication that causes UI drift - Keep parent/child relationships consistent with the data they share ** Interaction Diagnosis by Sight** - Trace click-flows and focus transitions in the UI - Fix hidden DOM traps by seeing where events propagate - Windsurf helps reveal side effects that are invisible in code alone ** Styling as Part of Behavior** - Choose a styling approach that improves visual clarity (Tailwind, CSS Modules, etc.) - Validate style overrides don't break component boundaries - Use Windsurf to ensure themes and tokens apply consistently across pages ** Accessibility You Can Inspect** - Confirm focus order matches layout order - Ensure ARIA or semantic roles reflect what you see - Windsurf catches "looks fine but unreadable" accessibility gaps ** Performance Seen, Not Just Measured** - Identify expensive component trees by watching render diffs - Remove hidden re-render domino effects - Validate virtualization in long lists — visually inspect the scroll flow ** Windsurf as UI Reviewer** - Summarize why structural improvements enhance UX clarity - Generate refactor suggestions to reduce visual noise - Help onboard new developers with visual walk-throughs of feature areas ** React + Windsurf Principles** - Components should reflect the story users experience - UI clarity is a structural decision, not an afterthought - State exists to serve an interaction — prune the rest - Windsurf keeps UI architecture visible and trustworthy