Introduction
After 30+ years in hacking, signal intelligence, and cybersecurity, I’ve watched countless “revolutionary” tools come and go. Most were incremental improvements dressed up in marketing speak. AI-assisted development felt different from the first serious implementation. Not because the technology is magic—it’s not—but because it fundamentally changes how we approach complex technical problems.
This isn’t another breathless piece about AI replacing engineers. That narrative misses the point entirely. The engineers who will thrive are those who learn to leverage AI as a genuine collaborator: delegating effectively, maintaining oversight, and amplifying their own expertise rather than outsourcing their judgment.
Over the past year, I’ve been leading a cloud migration from AWS to Google Cloud Platform while simultaneously developing cybersecurity insurance platforms under strict regulatory compliance (SOC 2 Type 2, NYS DFS Part 500, CCPA, GDPR). These projects have become my laboratory for understanding how AI collaboration actually works in production environments. This article shares what I’ve learned—the patterns that work, the pitfalls to avoid, and the mental models that make the difference between AI as a gimmick and AI as a force multiplier.
The Mental Model Shift: From Tool to Teammate
Most engineers approach AI the way they approach Stack Overflow: ask a question, get an answer, move on. This works for simple queries but completely misses the real value proposition. The shift that matters is treating AI as a junior engineer on your team—one with encyclopedic knowledge, infinite patience, and zero ego, but also one that requires clear direction, context, and verification.
Consider how you’d onboard a new team member to a complex codebase. You wouldn’t just say “fix the authentication bug” and walk away. You’d provide context about the system architecture, explain the constraints, point them to relevant documentation, and review their work before it hits production. The same principles apply to AI collaboration, but the mechanics are different.
The Context Window as Working Memory
Claude’s context window is the equivalent of working memory in a pair programming session. Everything your AI teammate needs to understand about the current task should be present in that window. This sounds obvious, but the implications are profound:
What belongs in context:
- The specific problem you’re solving, stated clearly
- Relevant code snippets (not entire codebases)
- Constraints and requirements (regulatory, performance, architectural)
- Examples of similar patterns from your codebase
- Expected output format
What doesn’t belong:
- Vague requests (“make this better”)
- Entire repositories dumped without curation
- Assumptions about what Claude “should” know about your project
During our Aurora to AlloyDB migration, I developed a habit of starting complex sessions with a structured brief:
Context: Migrating from AWS Aurora PostgreSQL to GCP AlloyDB
Constraint: Zero-downtime requirement, data integrity verification essential
Current phase: Setting up logical replication between source and target
Specific problem: Publication/subscription configuration for 47 tables with foreign key dependencies
Environment: Source is Aurora 13.4, Target is AlloyDB 14.1
This brief takes 30 seconds to write and saves hours of misdirection.
Understanding Claude’s Skills Architecture
One of the most underutilized aspects of Claude’s capabilities is the skills system. Skills are essentially specialized knowledge modules that Claude can reference for specific task types. Think of them as domain-specific runbooks that encode best practices.
Core Skills for Infrastructure Work
When I’m creating infrastructure documentation or runbooks, Claude can leverage the docx skill for professional document creation with proper formatting. For presentations to stakeholders, the pptx skill handles slide generation. When building spreadsheets for tracking migration progress or compliance matrices, the xlsx skill provides structured data manipulation.
But the real power emerges when you understand how to invoke these skills appropriately. It’s not about Claude “knowing” how to use them—it’s about you understanding when to ask for specific output formats that leverage these capabilities.
Custom Skills and Workflows
Beyond the built-in skills, the pattern of teaching Claude your specific workflows pays dividends. During our ECR to Artifact Registry migration (7+ years of Docker images, hundreds of repositories with regulated insurance components requiring specific retention policies), I developed a consistent briefing pattern:
Migration workflow for regulated container images:
1. Inventory source images with creation dates and tags
2. Classify by retention requirements (standard/regulated/archive)
3. Generate transfer manifest with compliance metadata
4. Execute transfer with verification checksums
5. Generate audit log for compliance documentation
Once Claude understood this workflow pattern, subsequent migrations followed the same structure automatically. The skill isn’t formally defined—it’s an emergent behavior from consistent context.
Sub-Agents: Decomposing Complex Problems
The sub-agent pattern is where AI collaboration becomes genuinely powerful. Rather than asking Claude to solve a massive problem in one shot, you decompose it into specialized sub-tasks, each handled with focused attention.
The Orchestration Model
Think of yourself as the orchestrator. You understand the overall architecture and objectives. Claude instances operate as specialized workers, each handling a specific domain:
Example: ArgoCD Multi-Cluster Management
When building our ArgoCD multi-cluster management system across GCP projects with GitOps workflows, the problem was too complex for a single prompt. Instead, I decomposed it:
Sub-agent 1: Cluster Configuration Specialist
- Focus: ApplicationSet patterns for multi-cluster deployments
- Context: Our specific cluster topology (dev, staging, prod across regions)
- Output: YAML manifests with environment-specific overlays
Sub-agent 2: RBAC and Security Configuration
- Focus: Project-level access controls, SSO integration
- Context: Our Okta SSO setup, developer permission matrix
- Output: AppProject definitions with proper RBAC boundaries
Sub-agent 3: Sync Policy and Automation
- Focus: Automated sync policies, health checks, rollback procedures
- Context: Our deployment windows, compliance requirements for change documentation
- Output: Sync policies, hooks, and resource customizations
Sub-agent 4: Monitoring and Alerting Integration
- Focus: Notifications, metrics exposure, dashboard creation
- Context: Our existing Prometheus/Grafana stack, PagerDuty integration
- Output: Alert configurations, ServiceMonitor resources, Grafana dashboard JSON
Each sub-agent session received only the context relevant to its specific domain. The outputs were then integrated by me—the orchestrator who understood how the pieces fit together.
Benefits of Sub-Agent Decomposition
Focused Context: Each sub-agent works within a smaller, more relevant context window. This reduces hallucination and increases accuracy.
Verifiable Outputs: Smaller, focused outputs are easier to review and validate. I can verify the RBAC configuration independently of the sync policies.
Parallel Development: In practice, I often ran multiple sub-agent sessions simultaneously (across different Claude windows), dramatically accelerating complex projects.
Clear Boundaries: When something breaks, the fault isolation is cleaner. Issues in the sync policy don’t get tangled with RBAC misconfigurations.
Real-World Pattern: Custom IAM Roles with Zero Trust
Let me walk through a concrete example from recent work: creating custom IAM roles for developers using Pulumi with Zero Trust principles.
The Problem Space
Our GCP environment needed fine-grained IAM roles that:
- Followed least-privilege principles
- Enabled developers to manage their specific workloads
- Maintained audit trails for compliance
- Integrated with our existing Pulumi infrastructure-as-code patterns
The Sub-Agent Approach
Session 1: Permission Analysis
I need to define custom IAM roles for developers in our GCP environment.
Current state: Developers have project-level Editor roles (too broad)
Target state: Custom roles with minimum necessary permissions
Developer personas:
1. Backend engineers: Cloud Run, Cloud SQL, Pub/Sub
2. Data engineers: BigQuery, Dataflow, Cloud Storage
3. Platform engineers: GKE, Artifact Registry, Cloud Build
For each persona, identify:
- Required permissions for daily work
- Permissions that should require approval
- Permissions that should never be granted
Output as a structured matrix.
This session produced a comprehensive permissions matrix that I could review against our actual operational patterns.
Session 2: Pulumi Implementation
Given this permissions matrix [attached], generate Pulumi code in Go for:
1. Custom IAM role definitions for each developer persona
2. Role bindings with conditional expressions (time-based, resource-based)
3. Audit logging configuration
Constraints:
- Must use our existing Pulumi project structure (example attached)
- Roles should be defined at organization level, bound at project level
- Include meaningful descriptions for compliance documentation
Session 3: Testing and Validation
Given these IAM role definitions [attached], generate:
1. Test cases to verify permission boundaries
2. Validation scripts to detect permission drift
3. Documentation for security review
Use Go for test cases, integrate with our existing testing patterns.
The Integration Layer
After each sub-agent session, I reviewed outputs, made adjustments based on organizational knowledge Claude couldn’t have, and integrated the pieces. The final PR included:
- Custom role definitions (from Session 2)
- Permission documentation (refined from Session 1)
- Automated tests (from Session 3)
- My own integration logic connecting the pieces
Total time: approximately 4 hours for what would have been 2-3 days of work. The difference wasn’t just speed—the output was more comprehensive because the sub-agent approach forced systematic thinking about each concern independently.
Patterns for Effective Delegation
The Brief, Execute, Verify Loop
Every AI collaboration follows a core loop:
- Brief: Provide clear context, constraints, and expected output format
- Execute: Let Claude work with focused attention
- Verify: Review output against your expertise and requirements
- Iterate: Refine based on gaps or misunderstandings
The temptation is to skip the briefing phase or accept outputs without verification. Both are mistakes. Insufficient briefing leads to outputs that miss critical constraints. Insufficient verification allows subtle errors to propagate.
Explicit Output Formatting
Always specify the output format you need. This isn’t about being picky—it’s about integration efficiency.
Generate the AlloyDB connection pooler configuration.
Output requirements:
- YAML format compatible with Cloud SQL Auth Proxy
- Include comments explaining each parameter
- Provide both development and production configurations
- Flag any parameters that need environment-specific values with [CONFIGURE]
The [CONFIGURE] flag pattern is particularly useful—it creates obvious markers for values that require my judgment or environment-specific knowledge.
The “Teach First” Pattern
When working on complex domains, invest time teaching Claude about your specific context before asking for implementations:
Before we start implementing, let me explain our AlloyDB architecture:
- Primary instance in us-central1 with 2 read replicas
- Connection pooling via PgBouncer sidecars in GKE
- Authentication using Workload Identity, no static credentials
- Connections must route through Private Service Connect
- All queries must be tagged with application identifiers for cost attribution
Given this context, we'll be working on [specific task].
This front-loaded context pays dividends throughout the session.
When AI Collaboration Fails
Understanding failure modes is as important as understanding success patterns.
Failure Mode: Assumption Cascade
Claude makes reasonable assumptions to fill gaps in your brief. These assumptions cascade through the output. If your context is missing critical constraints, you’ll receive technically correct solutions that don’t work in your environment.
Mitigation: Be explicit about non-obvious constraints. If you’re working in a regulated environment, say so. If you have unusual network topology, explain it.
Failure Mode: Pattern Matching to Wrong Context
Claude’s training includes vast amounts of code and documentation. Sometimes it pattern-matches to solutions that don’t fit your specific context—recommending AWS patterns when you’re on GCP, or suggesting deprecated APIs for current versions.
Mitigation: Specify versions, platforms, and any unusual constraints. Verify recommendations against current documentation.
Failure Mode: Confident Incorrectness
Claude will sometimes provide incorrect information with apparent confidence. This is particularly dangerous for security-critical code or compliance-related implementations.
Mitigation: Never trust security-critical outputs without independent verification. Use Claude as a starting point, not a final authority, for anything where mistakes have significant consequences.
Failure Mode: Context Drift
In long sessions, earlier context can become diluted. Claude may forget constraints established earlier in the conversation.
Mitigation: Restate critical constraints periodically. For very long sessions, consider starting fresh with a summary of decisions made rather than continuing indefinitely.
Building Your AI Collaboration Practice
Start Small, Document Everything
Begin with well-defined, low-risk tasks where you can easily verify outputs. Document what works—the briefing patterns, the decomposition strategies, the output formats that integrate cleanly with your workflows.
Develop Domain-Specific Briefing Templates
Over time, you’ll notice patterns in how you brief Claude for specific task types. Capture these as templates:
# Migration Script Brief Template
## Source System
- Platform:
- Version:
- Authentication method:
- Data volume:
## Target System
- Platform:
- Version:
- Authentication method:
- Compliance requirements:
## Constraints
- Downtime tolerance:
- Data validation requirements:
- Rollback requirements:
## Expected Output
- Script language:
- Logging requirements:
- Error handling approach:
Invest in Review Efficiency
As you delegate more to AI, your bottleneck becomes review. Develop efficient review practices:
- Use diff tools to compare generated code against known-good patterns
- Build automated validation for generated configurations
- Create checklists for common error patterns in AI-generated code
Know When to Do It Yourself
Not every task benefits from AI collaboration. Quick one-off scripts, tasks requiring deep system knowledge that’s hard to articulate, or situations where the briefing would take longer than the implementation—these are often faster done directly.
The judgment of when to engage AI collaboration is itself a skill that develops with practice.
Looking Ahead
In Part 2 of this series, we’ll dive into the security and workflow implementation aspects of AI collaboration:
- Security considerations when using AI for infrastructure code
- Integrating AI-generated code into CI/CD pipelines
- Audit trails and compliance documentation for AI-assisted development
- Building organizational practices around AI collaboration
- Advanced patterns for multi-model orchestration
The goal isn’t to become dependent on AI—it’s to become more effective by leveraging AI for what it does well while maintaining the human judgment and expertise that it can’t replace. The engineers who master this balance will define the next era of infrastructure engineering.
Check out Part 2: Security, Workflows, and Organizational Adoption