Advanced AI Coding Patterns for Senior Devs

The Senior Developer's AI Advantage

Beginner AI coding: prompt by prompt, function by function. The developer: writes one prompt, gets one function, reviews, moves on. Senior AI coding: orchestrating the AI across multiple files, guiding architectural decisions through rules, and using the AI as a force multiplier for senior-level tasks (complex refactoring, system design implementation, cross-cutting concern enforcement). The difference: not in the tool but in how it is used. The senior developer: leverages their deep technical knowledge to direct the AI more effectively, producing better output with fewer iterations.

The senior advantage: understanding the system. A junior developer: prompts for a function. A senior developer: prompts for a feature that spans 5 files, specifying how the files should interact, which patterns to use at each layer, and which edge cases to handle. The senior's prompt: contains the architectural knowledge that the AI lacks. The AI: executes the senior's architecture at the speed of code generation. The combination: senior-level design at junior-level speed.

Advanced patterns: multi-file orchestration (building features that span files with one prompt), architecture-aware prompting (embedding architectural decisions in prompts), constraint-based generation (defining what the code must NOT do as strongly as what it must do), rule meta-programming (using AI rules to guide not just code generation but the AI's reasoning process), and iterative refinement at scale (refining not one function but an entire feature across multiple files).

Pattern 1: Multi-File Orchestration

The technique: a single prompt that produces a complete feature across multiple files. Instead of: 'Create the database schema' → 'Now create the service' → 'Now create the route' → 'Now create the test' (4 separate prompts, 4 separate reviews). The senior approach: 'Create a complete user registration feature: Drizzle schema (src/db/schema/users.ts), service function with Result pattern (src/services/user-service.ts), tRPC route with Zod validation (src/routes/users.ts), and Vitest test covering success, duplicate email, and validation error cases (src/services/user-service.test.ts).'

The advantage: the AI generates all 4 files in one pass, with consistent types flowing from schema to service to route to test. The types: match across files (the schema defines the User type, the service uses it, the route validates against it, the test asserts on it). With separate prompts: the types might drift between files (the service defines a slightly different User shape than the schema). With one multi-file prompt: the AI maintains consistency across all files because it generates them together.

When to use multi-file: for features that span the typical application layers (schema → service → route → test), for refactoring that touches multiple related files, and for creating new modules with all necessary files. When NOT to use: for isolated changes to a single file (over-orchestrating simple tasks). AI rule: 'Multi-file prompts: for features. Single-file prompts: for functions. Match the prompt scope to the task scope. A 4-file feature: one multi-file prompt. A utility function: one single-file prompt.'

Pattern 2: Architecture-Aware Prompting

The technique: embedding architectural decisions in the prompt itself, beyond what the rules file covers. The rules: encode general conventions (naming, error handling, testing). The prompt: encodes architecture-specific decisions for this particular feature. Example: 'Create an event-driven notification system. The publisher: emits events to a message queue (use the existing EventBus from src/lib/event-bus.ts). The consumers: process events asynchronously. Design for: eventual consistency (the notification may be delivered slightly after the event). Avoid: synchronous coupling between the publisher and consumers.'

The architecture in the prompt: tells the AI the design philosophy (event-driven, eventually consistent, decoupled). The AI: makes implementation decisions that align with this philosophy (uses async event handlers, does not block the publisher, handles retry for failed deliveries). Without the architectural guidance: the AI might generate a synchronous, tightly coupled implementation (the publisher calls the notification service directly). The architecture: in the prompt because it is feature-specific, not a general rule.

Combining rules and prompts: the rules handle: the constant conventions (naming, error handling, testing, security). The prompt handles: the variable architecture (this specific feature's design, this specific integration's approach). The AI: reads both. The rules: consistent across all prompts. The prompt: specific to this task. AI rule: 'Rules for conventions (constant). Prompts for architecture (variable). The rules: do not change per prompt. The prompt: changes per task. Together: conventions + architecture = complete guidance.'

Pattern 3: Constraint-Based Generation

The technique: defining what the code must NOT do as strongly as what it must do. Senior developers know: what to avoid is as important as what to use. The prompt: includes negative constraints alongside positive requirements. Example: 'Create a payment processing function. MUST: use idempotency keys, log all operations to the audit trail, use decimal for all amounts. MUST NOT: store card numbers (use tokens), process without authentication, retry failed charges automatically (require manual intervention for failed payments).'

Why constraints matter for AI: the AI's training data includes: millions of examples of code that stores card numbers, retries failed operations, and uses floating-point for money. Without constraints: the AI may generate these patterns because they are common. With constraints: the AI explicitly avoids them. The constraints: override the AI's default behavior for patterns that are common in public code but wrong for your project. This: is the advanced version of negative rules (the 'don't' rules from the tutorials).

The constraint hierarchy: MUST rules (the code is wrong without these — security, correctness, compliance). SHOULD rules (the code is suboptimal without these — patterns, conventions, best practices). MUST NOT rules (the code is dangerous with these — security anti-patterns, known bug sources, compliance violations). The hierarchy: tells the AI which constraints are absolute (MUST/MUST NOT) and which are preferences (SHOULD). AI rule: 'MUST and MUST NOT: the strongest guidance. SHOULD: a preference. The hierarchy: guides the AI when constraints conflict (MUST wins over SHOULD).'

Advanced Patterns Quick Reference

Quick reference for advanced AI coding patterns.

• Senior advantage: architectural knowledge + AI execution speed = senior-level design at generation speed
• Multi-file: one prompt for a complete feature (schema + service + route + test). Consistent types across files
• Architecture prompting: embed design philosophy in the prompt (event-driven, eventual consistency, decoupled)
• Rules for constants: conventions. Prompts for variables: architecture. Both: complete guidance
• Constraint-based: MUST (required), SHOULD (preferred), MUST NOT (prohibited). The hierarchy guides conflicts
• Negative constraints: override AI defaults for common-but-wrong patterns (storing card numbers, float for money)
• When: multi-file for features. Architecture prompts for complex systems. Constraints for sensitive code
• The expert workflow: rules handle conventions. Prompts handle architecture. Constraints handle safety