Afa' Afa' Afa'

Building a Complete AI Engineering Team with DSH Agent Presets

Build a multi-agent AI engineering workflow with DSH agent presets.

12 min read Updated

Software engineering is increasingly moving toward AI-assisted development, but there is a difference between having an AI that can write code and having an AI engineering team.

A good engineering workflow is not just:

"Build this feature."

It is also:

  • Is the architecture sound?
  • Is the API well designed?
  • Is the database efficient?
  • Is the code maintainable?
  • Is the project secure?
  • Is it performant?
  • Are failures handled correctly?
  • Is it observable?
  • Is it properly tested?
  • Can it be deployed reproducibly?
  • Can it be released safely?

That is the idea behind my new collection of DSH Agent Presets: a set of specialized engineering agents that can be used independently, or as a complete engineering workflow.

One AI agent is useful. A team of specialized agents is better.

The collection is built around a simple principle:

Each agent should have a clearly defined engineering responsibility.

Instead of creating one enormous prompt containing every possible software engineering rule, each preset specializes in a particular discipline.

The result is a collection of agents such as:

text 
Project Architect & Generator
Architecture Engineer
Backend Engineer
Frontend Engineer
API Engineer
Database Engineer
Code Review Engineer
Refactoring Engineer
Testing Engineer
Security Engineer
Performance Engineer
Reliability Engineer
Observability Engineer
Dependency Engineer
DevOps Engineer
Migration Engineer
Documentation Engineer
Release Engineer

Each one can be used independently depending on the task.

Project Architect & Generator

The central preset of the collection is the Project Architect & Generator.

It started as a simple fullstack project generator, but quickly became clear that "fullstack" was too restrictive.

A real project can contain:

text 
0..N frontends
0..N backends
0..N shared packages
0..N generated clients

So instead of assuming:

text 
frontend + backend

the agent builds a project manifest and a component graph.

For example:

text 
Project
│
├── apps/
│   ├── web/
│   └── admin/
│
├── services/
│   ├── api/
│   └── auth/
│
└── packages/
    └── contracts/

The topology is then used to derive the rest of the repository.

This is important because Docker, CI/CD and the Makefile should not be copied blindly from a template.

They depend on the actual project structure.

For example:

text 
2 frontends
+
2 backends
        ↓
4 application build targets
4 container definitions
appropriate CI jobs
appropriate test jobs
appropriate documentation

rather than generating infrastructure for applications that don't exist.

Python and TypeScript backends

The generator supports both Python and Node.js/TypeScript backends.

For Node.js/TypeScript services, the convention is:

text 
services/
├── api/
├── auth/
└── worker/

while frontend applications can live under:

text 
apps/
├── web/
└── admin/

The project generator also treats full type safety as an architectural requirement.

For Python, that means strict static typing and typed boundaries.

For TypeScript, that means strict compiler settings and avoiding any as an escape hatch.

The same principle applies across API contracts, configuration, external data, generated clients and shared packages.

Architecture Engineer

The Architecture Engineer is designed to answer a different question:

"Is this system structured correctly?"

It analyzes:

  • module boundaries;
  • service boundaries;
  • dependency direction;
  • coupling;
  • cohesion;
  • data ownership;
  • API boundaries;
  • shared packages;
  • infrastructure boundaries;
  • circular dependencies;
  • technical debt;
  • scalability constraints.

It can also work before implementation.

For example:

text 
We need two APIs,
three frontends,
a shared authentication service
and several external integrations.

The agent can turn that requirement into an architectural model before implementation begins.

The objective isn't to introduce architecture for architecture's sake.

The rule is simple:

Prefer explicit, understandable boundaries over unnecessary abstractions.

Backend Engineer

The Backend Engineer focuses on backend implementation and architecture.

For Python projects, it is particularly suited to stacks such as:

text 
Python
FastAPI
Pydantic
uv
Ruff
mypy
pytest

It focuses on:

  • API design;
  • configuration;
  • dependency boundaries;
  • domain logic;
  • async I/O;
  • persistence;
  • external integrations;
  • background work;
  • error handling;
  • observability;
  • typing;
  • testing.

A key principle is avoiding unnecessary layers.

A project shouldn't automatically receive:

text 
repository
service
manager
factory
provider
adapter

just because those patterns exist.

The architecture should follow the actual domain.

Frontend Engineer

The Frontend Engineer specializes in modern React/Next.js applications.

It focuses on:

  • Next.js architecture;
  • server/client boundaries;
  • React composition;
  • state ownership;
  • hooks;
  • data fetching;
  • caching;
  • forms;
  • validation;
  • accessibility;
  • loading and error states;
  • API clients;
  • frontend testing.

It also pays attention to the boundary between browser code and server-side code.

The goal is not to turn every component into a generic abstraction.

The goal is to keep the frontend understandable as it grows.

API Engineer

APIs are contracts, not just HTTP endpoints.

The API Engineer focuses on:

  • resource modeling;
  • HTTP semantics;
  • validation;
  • error schemas;
  • pagination;
  • filtering;
  • idempotency;
  • authentication;
  • authorization;
  • versioning;
  • backwards compatibility;
  • WebSockets;
  • OpenAPI;
  • generated clients.

One important principle is that generated API clients should have a clear source of truth.

For example:

text 
Backend
   │
   ▼
OpenAPI
   │
   ▼
Generated TypeScript client
   │
   ├── Web
   └── Admin

The generated client is not manually edited.

Database Engineer

The Database Engineer focuses on the part of applications that often becomes a bottleneck or reliability problem as systems grow.

It analyzes:

  • schema design;
  • constraints;
  • indexes;
  • query plans;
  • N+1 queries;
  • joins;
  • pagination;
  • transactions;
  • locks;
  • connection pools;
  • migrations;
  • data integrity;
  • caching.

A particularly important rule is:

Don't add an index simply because a column is frequently queried.

The agent should look at the actual workload and query plan when possible.

Code Review Engineer

The Code Review Engineer is designed for pull requests, diffs and changes.

It focuses on:

  • correctness;
  • regressions;
  • edge cases;
  • error handling;
  • backwards compatibility;
  • maintainability;
  • repository conventions;
  • missing tests.

It deliberately avoids turning code review into a style contest.

A review should identify a real engineering problem, not simply:

"I would personally write this differently."

Findings should contain concrete locations, evidence and remediation.

Refactoring Engineer

Refactoring deserves its own specialist because refactoring and feature development are different activities.

The Refactoring Engineer follows:

text 
Existing behavior
      ↓
Characterization tests
      ↓
Small structural change
      ↓
Tests
      ↓
Next change

Its job is to improve:

  • coupling;
  • duplication;
  • complexity;
  • responsibilities;
  • dead code;
  • boundaries.

without silently changing application behavior.

It also avoids mixing unrelated feature development into refactoring work.

Testing Engineer

The Testing Engineer focuses on an important question:

What actually needs to be tested?

Rather than blindly pursuing 100% coverage, it identifies:

text 
Business logic
Critical paths
Failure modes
Security boundaries
API contracts
Integration points
Regression risks

It can work across:

  • unit tests;
  • integration tests;
  • API tests;
  • contract tests;
  • E2E tests;
  • security regression tests;
  • performance regression tests.

The principle is:

Coverage is a measurement, not the objective.

The objective is confidence in important behavior.

Security Engineer

The Security Engineer is dedicated to security auditing and hardening.

It covers:

text 
Authentication
Authorization
IDOR / BOLA
Input validation
Injection
SSRF
XSS
CSRF
CORS
Secrets
Docker
CI/CD
Dependencies
Supply chain
Logging

It can operate in several modes:

text 
audit
review
threat-model
harden
pentest

An audit starts by understanding the architecture and trust boundaries rather than blindly running a checklist.

For example:

text 
Internet
   │
   ▼
Reverse Proxy
   │
   ├── Frontend
   │
   └── API
        │
        ├── Database
        ├── Redis
        └── External APIs

From there, the agent can reason about actual attack surfaces.

Security findings also distinguish:

text 
severity
exploitability
confidence

rather than collapsing everything into a single arbitrary score.

And secrets discovered during an audit are always treated as sensitive data and redacted.

Performance Engineer

The Performance Engineer follows one particularly important rule:

Measure first. Optimize second.

Its workflow is:

text 
Discover
   ↓
Define workload
   ↓
Baseline
   ↓
Profile
   ↓
Identify bottleneck
   ↓
Optimize
   ↓
Benchmark
   ↓
Regression test

It covers:

  • latency;
  • throughput;
  • CPU;
  • memory;
  • I/O;
  • databases;
  • async behavior;
  • concurrency;
  • algorithms;
  • frontend rendering;
  • bundle size;
  • startup time;
  • Docker;
  • infrastructure.

Instead of saying:

"This code could be faster."

the agent should ideally be able to explain:

text 
Baseline:
p95 = 420 ms

Dominant cost:
database query

Change:
add appropriate index and eliminate N+1 access

Result:
p95 = 190 ms

The workload and measurement methodology matter just as much as the number.

Reliability Engineer

Performance isn't reliability.

A system can be extremely fast and still fail badly when a dependency becomes unavailable.

The Reliability Engineer focuses on:

text 
timeouts
retries
backoff
jitter
idempotency
circuit breakers
partial failures
graceful degradation
startup/shutdown
health checks
queue failures
race conditions
concurrency limits

For example:

What happens if PostgreSQL becomes unavailable for 30 seconds?

Or:

What happens if an external API takes 20 seconds to respond?

These are reliability questions rather than performance questions.

One important invariant:

Never add retries to a non-idempotent operation without an explicit idempotency strategy.

Observability Engineer

The Observability Engineer deals with what happens after the application is deployed.

It focuses on:

  • structured logging;
  • metrics;
  • traces;
  • request IDs;
  • correlation;
  • health checks;
  • readiness;
  • latency/error/saturation metrics;
  • dashboards;
  • alerts;
  • sampling;
  • cardinality.

It also treats logging as a security boundary.

Credentials, cookies, authorization headers, tokens and private keys should never accidentally appear in logs.

The goal isn't simply:

"Add more logs."

It is:

Make important system behavior measurable and diagnosable.

Dependency Engineer

Modern applications are built on thousands of direct and transitive dependencies.

The Dependency Engineer handles:

  • dependency discovery;
  • upgrades;
  • lockfiles;
  • transitive dependencies;
  • compatibility;
  • deprecated packages;
  • package-manager configuration;
  • reproducibility;
  • supply-chain risks.

It also avoids the classic:

text 
dependency problem
        ↓
delete lockfile
        ↓
run install
        ↓
hope

Instead, dependency changes are treated as controlled engineering changes.

DevOps Engineer

The DevOps Engineer focuses on the path from source code to deployable software.

It handles:

text 
Docker
Compose
CI/CD
builds
artifacts
releases
environments
secrets
health checks
multi-architecture images
rollback

An important principle is that local development and CI should use the same authoritative commands whenever practical.

If:

text 
make test

is the canonical local test command, CI shouldn't quietly implement a completely different test process.

Migration Engineer

Migrations are one of the easiest places to accidentally create large amounts of technical debt.

The Migration Engineer handles migrations between:

  • framework versions;
  • runtimes;
  • dependencies;
  • architectures;
  • infrastructure;
  • project structures.

Its workflow is incremental:

text 
Current state
     ↓
Compatibility analysis
     ↓
Target state
     ↓
Incremental migration
     ↓
Validation
     ↓
Next step

It separates mechanical migration work from behavioral changes wherever possible.

Documentation Engineer

Documentation should describe the software that actually exists.

The Documentation Engineer therefore inspects:

  • source code;
  • configuration;
  • scripts;
  • CI;
  • Docker;
  • APIs;
  • deployment.

before writing documentation.

It can maintain:

text 
README.md
ARCHITECTURE.md
DOCUMENTATION.md
CONTRIBUTING.md
SECURITY.md
AGENTS.md

The important rule is:

Never document planned behavior as implemented behavior.

Release Engineer

Finally, the Release Engineer handles the last step:

text 
version
   ↓
changelog
   ↓
build
   ↓
artifacts
   ↓
container images
   ↓
validation
   ↓
release

It focuses on:

  • versioning;
  • changelogs;
  • release notes;
  • artifacts;
  • container tags;
  • provenance;
  • CI release jobs;
  • migrations;
  • smoke tests;
  • rollback.

The objective is reproducible and traceable releases rather than a collection of manual commands.

The interesting part: they form an engineering system

The presets aren't intended to be just a random collection of prompts.

They can form a larger engineering workflow:

text 
                    Project Architect
                           │
                           ▼
                    Architecture
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
         Backend                     Frontend
             │                           │
             └─────────────┬─────────────┘
                           ▼
                          API
                           │
                           ▼
                       Database
                           │
                           ▼
                         Tests
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
          Security     Performance    Reliability
             │             │             │
             └─────────────┼─────────────┘
                           ▼
                     Observability
                           │
                           ▼
                        DevOps
                           │
                           ▼
                        Release

And the Code Review, Dependency, Refactoring, Migration and Documentation agents can be used throughout the lifecycle.

The presets are deliberately independent

One of the design decisions I made was not to turn everything into one gigantic agent.

You might only need:

text 
Security Engineer

for an existing project.

Or:

text 
Performance Engineer

for a specific performance investigation.

Or:

text 
Database Engineer

for a migration.

You don't need to involve the entire engineering suite.

At the same time, the Project Architect & Generator can serve as the starting point for a new project.

A different way to use AI for software engineering

The larger idea behind these presets is that AI-assisted development doesn't have to mean:

text 
Human
  ↓
"Write code"
  ↓
AI

It can look more like:

text 
Human requirements
       ↓
Architecture
       ↓
Implementation
       ↓
Testing
       ↓
Security
       ↓
Performance
       ↓
Reliability
       ↓
Observability
       ↓
Deployment
       ↓
Release

with specialized AI agents responsible for different engineering concerns.

The goal isn't to replace engineering judgment.

It's to give the developer a collection of specialized tools that can apply consistent engineering practices repeatedly.

What's next?

The most interesting next step is orchestration.

Instead of manually switching between:

text 
Architecture Engineer
Security Engineer
Performance Engineer
Testing Engineer
...

a future DSH Engineering Orchestrator could coordinate a complete project lifecycle:

text 
                    Requirement
                         │
                         ▼
              Project Architect
                         │
                         ▼
                   Implementation
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
          Code Review            Testing
              │                     │
              └──────────┬──────────┘
                         ▼
              ┌──────────┼──────────┐
              ▼          ▼          ▼
          Security   Performance Reliability
              │          │          │
              └──────────┼──────────┘
                         ▼
                   Observability
                         │
                         ▼
                       DevOps
                         │
                         ▼
                      Release

That would turn the collection from a set of individual presets into a genuine AI-assisted engineering workflow.

The collection

The complete collection currently includes:

  • Project Architect & Generator
  • Architecture Engineer
  • Backend Engineer
  • Frontend Engineer
  • API Engineer
  • Database Engineer
  • Code Review Engineer
  • Refactoring Engineer
  • Testing Engineer
  • Security Engineer
  • Performance Engineer
  • Reliability Engineer
  • Observability Engineer
  • Dependency Engineer
  • DevOps Engineer
  • Migration Engineer
  • Documentation Engineer
  • Release Engineer

All presets use the DSH naming convention, as in:

text 
DSH Project Architect & Generator
DSH Security Engineer
DSH Performance Engineer
DSH Database Engineer
DSH Architecture Engineer
...

The idea is simple: one preset, one engineering responsibility, one clear purpose.

And together, they provide the foundation for a complete AI-powered software engineering team inside DSH.

Download the presets

Every preset is available as an individual archive. Download the ones you need and import them into DSH:

Related articles

Search articles

Type to filter articles. Use the arrow keys to move through results and Enter to open one. Press Escape to close.