Expert Se Bot

Delivers expert software engineering guidance covering architecture, code quality, design patterns, and engineering best practices.

When to Use This Agent

Choose this agent when you need to:

• Evaluate architectural decisions with trade-off analysis across scalability, maintainability, and performance dimensions
• Review code quality patterns and receive recommendations grounded in SOLID principles and clean architecture
• Navigate complex engineering problems such as system decomposition, API design, or technical debt prioritization

Consider alternatives when:

• You need hands-on implementation or code generation rather than engineering guidance and pattern analysis
• Your question is specific to a single framework or language and would benefit from a dedicated technology-specific agent

Quick Start

Configuration

Copy
name: expert-se-bot
type: agent
category: security

Example Invocation

Copy
claude agent:invoke expert-se-bot "Evaluate the trade-offs between event-driven and request-response architectures for our order processing system"

Example Output

Architecture Trade-Off Analysis: Order Processing System

Criterion              | Event-Driven         | Request-Response
-----------------------|----------------------|--------------------
Coupling               | Loose (pub/sub)      | Tight (synchronous)
Latency                | Higher (eventual)    | Lower (immediate)
Scalability            | Horizontal scaling   | Vertical bottleneck
Failure Isolation      | Independent services | Cascading failures
Debugging Complexity   | Higher (distributed) | Lower (linear flow)
Data Consistency       | Eventual             | Strong (ACID)

Recommendation: Event-driven architecture with saga pattern
for order workflows. Use synchronous calls only for the
payment confirmation step where strong consistency is required.

Risk Mitigations:
  - Dead letter queues for failed event processing
  - Correlation IDs for distributed tracing
  - Compensating transactions for rollback scenarios

Core Concepts

Engineering Disciplines Overview

Aspect	Details
Architecture Patterns	Microservices, monoliths, modular monoliths, event-driven, CQRS, hexagonal architecture
Design Principles	SOLID, DRY, YAGNI, separation of concerns, dependency inversion, interface segregation
Code Quality Metrics	Cyclomatic complexity, coupling/cohesion ratios, test coverage, code churn velocity
Technical Debt Management	Debt classification (reckless/prudent, deliberate/inadvertent), payoff prioritization frameworks
API Design Standards	RESTful maturity model, contract-first design, versioning strategies, backward compatibility

System Design Architecture

┌─────────────────────────────────────────────────┐
│                  System Design                   │
├────────────┬────────────┬────────────────────────┤
│ Structure  │  Behavior  │     Cross-Cutting      │
│            │            │                        │
│ Modules    │ Workflows  │ Observability          │
│ Layers     │ Protocols  │ Security               │
│ Boundaries │ Contracts  │ Performance            │
│ Interfaces │ Events     │ Reliability            │
├────────────┴────────────┴────────────────────────┤
│              Quality Attributes                   │
│  Scalability │ Maintainability │ Testability      │
│  Resilience  │ Deployability   │ Operability      │
└─────────────────────────────────────────────────┘

Configuration

Parameter	Type	Default	Description
analysisDepth	string	"detailed"	Level of analysis: summary, detailed, or comprehensive with code examples
domainFocus	string	"general"	Engineering domain emphasis: backend, frontend, distributed, embedded, or general
principleSet	string	"solid"	Core principle framework to apply: solid, clean-architecture, domain-driven, or pragmatic
tradeOffFormat	string	"table"	Output format for trade-off analysis: table, prose, or decision-matrix
techDebtThreshold	string	"medium"	Sensitivity level for flagging technical debt: low, medium, or high

Best Practices

1. Favor Composition Over Inheritance Hierarchies - Deep inheritance chains create rigid coupling where changes to base classes ripple unpredictably through descendants. Composition through interfaces and dependency injection produces flexible components that can be assembled, tested, and replaced independently without disturbing the broader system structure.

2. Design Boundaries Around Business Capabilities - Service and module boundaries should align with business domains rather than technical layers. A boundary drawn around "Order Fulfillment" produces higher cohesion and lower coupling than splitting "controllers," "services," and "repositories" across organizational lines, because changes to business rules stay contained within a single boundary.

3. Make Implicit Decisions Explicit in ADRs - Architecture Decision Records capture the context, constraints, and consequences of design choices at the moment they are made. Without ADRs, teams rediscover the same trade-offs repeatedly or unknowingly reverse decisions that had critical rationale behind them, introducing subtle architectural drift over time.

4. Apply the Strangler Fig Pattern for Legacy Migration - Rather than rewriting legacy systems wholesale, incrementally route traffic from old components to new implementations behind a facade. This reduces risk by maintaining the working system throughout migration and provides natural rollback points if new components exhibit unexpected behavior under production load.

5. Establish Contract Tests at Integration Boundaries - Unit tests verify internal logic, but integration failures occur at boundaries between services, modules, or teams. Contract tests validate that producers and consumers agree on message formats, API schemas, and behavioral expectations, catching breaking changes before they reach production environments.

Common Issues

1. Over-Engineering Simple Problems - Applying microservices, event sourcing, or CQRS to straightforward CRUD applications introduces operational complexity that outweighs architectural benefits. Start with the simplest architecture that meets current requirements, then extract complexity only when concrete scaling or organizational pressures demand it.

2. Ignoring Non-Functional Requirements Until Late - Performance, security, and reliability constraints shape architectural decisions fundamentally. Discovering a 50ms latency requirement after building a multi-hop microservice chain forces expensive redesigns. Capture non-functional requirements alongside functional ones during initial system analysis.

3. Coupling Deployment Units to Code Modules - Conflating the concept of a deployable artifact with a code module leads to either monolithic deployments or an explosion of independently deployed services with excessive coordination overhead. Design code modules for logical separation and choose deployment boundaries based on operational scaling and team ownership needs.