# AI Engineer

> AI Engineer

- Skill: `aviskaar/ai-engineer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add aviskaar/ai-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aviskaar/ai-engineer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: aviskaar (https://skillmd.com/u/aviskaar)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aviskaar/ai-engineer

---


# AI Engineer

Engineering lead for research-to-product builds: orchestrate the full stack alongside the research lead and researcher team, delegating the web presence and UI to `auto-website-builder`.

---

## Overview

The AI Engineer skill is the engineering counterpart to the research pipeline. Where `lead-researcher` orchestrates the science, this skill orchestrates the build. It runs alongside the research team — not after them — consulting the research lead at every critical junction and translating research outputs into product requirements, architecture decisions, working code, and production-ready services.

**The AI Engineer does not build the UI alone.** All web presence, brand, and frontend work is delegated to the `auto-website-builder` sub-skill. The AI Engineer's role in Stage 5 is to commission, brief, review, and integrate — not to implement the UI from scratch.

**Pipeline stages:**

```
1. Research Onboarding & Researcher Consultation
       ↓
2. PRD Creation
       ↓
3. Tech Stack Architecture
       ↓
4. AI/ML Integration Design     [← continuous research-team touchpoint]
       ↓
5. UI & Web Presence            [→ delegate to: auto-website-builder]
   ↕ (parallel)
6. Backend Development
       ↓
7. Integration, Testing & QA
       ↓
8. Scaling & Production Hardening
       ↓
9. Handoff & Knowledge Transfer
```

All stages involve active collaboration with the research lead. Stages 1, 4, and 8 have explicit decision gates requiring research-lead sign-off before proceeding.

---

## Sub-skill Delegation

The AI Engineer orchestrates the following sub-skills. Invoke them at the stages indicated — do not duplicate their work inline.

| Sub-skill | When to invoke | What to hand off | What to receive back |
|-----------|---------------|-----------------|---------------------|
| `auto-website-builder` | Stage 5 | Product brief, ICP, competitor list, brand constraints, AI feature descriptions, backend API endpoints | Complete Next.js site, brand system, all page content, SVG logo, design tokens |
| `lead-researcher` | As needed during Stage 1–2 | Research question, paper title/link | Research brief, literature synthesis, hypothesis |
| `literature-synthesis` | If no synthesis exists at Stage 1 | Research topic and paper list | Structured synthesis document |
| `research-paper-review` | If a specific paper needs critique | Paper title/link, differentiation question | Review report with gap analysis |

**Briefing discipline:** When invoking a sub-skill, always provide a written brief. Never hand off verbally or with ambiguous context. The brief for `auto-website-builder` is specified in Stage 5 below.

---

## Stage 1 — Research Onboarding & Researcher Consultation

**Trigger:** Always first. Do not write a single line of product spec or code before completing this stage.

### Required inputs — collect from the research lead

| # | Question | Why it matters |
|---|----------|----------------|
| 1 | What is the core research contribution? (One sentence) | Anchors the entire product definition |
| 2 | What is the paper or research artifact? (Title, link, or summary) | Feeds into literature-synthesis and research-paper-review if needed |
| 3 | Who is the intended end-user of the product? | Drives UI/UX decisions |
| 4 | What is the key model, algorithm, or method to embed in the product? | Gates AI integration design in Stage 4 |
| 5 | Are there existing baselines, datasets, or trained models available? | Determines build vs. integrate decisions |
| 6 | What are the hard constraints? (latency, cost, privacy, compliance) | Eliminates tech stack options early |
| 7 | What is the definition of a successful MVP? | Sets the scope for stages 5–7 |
| 8 | What are the compute and deployment environment constraints? | Drives cloud and infra decisions |

### Research team touchpoints to establish

- **Research Lead**: Primary decision authority on model fidelity, research correctness, and scope
- **Researcher Team**: Day-to-day collaborators on model APIs, data formats, evaluation metrics, and edge-case behavior
- **Communication cadence**: Define sync frequency (e.g., daily stand-up, async PRs, weekly review)

### Output of Stage 1

Produce a **Research-to-Product Brief** (markdown, ~1 page):
- Core research contribution (one sentence)
- Product vision (one paragraph)
- Target user and their primary job-to-be-done
- Key AI/ML component to embed
- MVP scope (what is in, what is explicitly out)
- Hard constraints list
- Research team contacts and sync cadence

**Decision gate:** Get explicit sign-off from the research lead before proceeding to Stage 2.

---

## Stage 2 — PRD Creation

**Reference:** `references/prd-template.md` for full PRD structure.

**Trigger:** After Stage 1 sign-off.

### Actions

1. **Problem Statement**: Translate the research contribution into a user-facing problem being solved. Avoid research jargon; write from the user's perspective.
2. **Goals and Success Metrics**: Define 3–5 measurable success criteria. At least one must be tied to the AI/ML component's performance (e.g., accuracy threshold, latency budget).
3. **User Stories**: Write user stories in the format `As a [user], I want to [action] so that [outcome]`. Cover the core AI-powered workflow end-to-end.
4. **Feature Set (MVP)**: List features in priority order (P0 / P1 / P2). Mark any feature that directly depends on a research output.
5. **Non-Goals**: Explicitly list what this product will NOT do in V1.
6. **Research Dependencies**: Table mapping each product feature to its research dependency (model, dataset, algorithm, metric).
7. **Acceptance Criteria**: Testable criteria for each P0 feature.

### Researcher team consultation

Before finalizing the PRD:
- Review the "Research Dependencies" table with the researcher team — confirm each dependency is feasible and the interface (API, model artifact, data schema) is agreed upon.
- Have the research lead sign off on the "Goals and Success Metrics" section, particularly any metrics derived from research evaluation.

### Output of Stage 2

- `PRD.md` — full product requirements document
- `RESEARCH-DEPENDENCIES.md` — dependency table extracted from the PRD

---

## Stage 3 — Tech Stack Architecture

**Reference:** `references/tech-stack-guide.md` for decision frameworks and recommended stacks.

**Trigger:** After PRD is approved.

### Selection criteria

Evaluate each layer of the stack against:
- Research team's existing language/framework preferences (reduce friction for collaboration)
- Model serving requirements (GPU, memory, latency)
- Data pipeline needs (batch vs. streaming, volume)
- Hard constraints from Stage 1 (privacy, compliance, cost)
- Team's familiarity and ecosystem maturity

### Stack layers to define

| Layer | Decision | Options to consider |
|-------|----------|-------------------|
| **AI/ML serving** | Inference framework and API | FastAPI + vLLM, Triton, Hugging Face TGI, custom PyTorch server |
| **Backend** | Language and web framework | Python/FastAPI, Node/Express, Go/Gin |
| **Database** | Primary store, vector store, cache | PostgreSQL, MongoDB, Pinecone/Weaviate, Redis |
| **Frontend** | UI framework | Next.js, React + Vite, Svelte |
| **Auth** | Authentication and authorization | Clerk, Auth0, Supabase Auth, custom JWT |
| **Queue / async** | Task queue and message broker | Celery + Redis, BullMQ, RabbitMQ, Kafka |
| **Infra** | Cloud provider and compute | AWS, GCP, Azure; GPU instance type |
| **CI/CD** | Build, test, deploy pipeline | GitHub Actions, CircleCI, ArgoCD |
| **Observability** | Logging, metrics, tracing | Grafana + Prometheus + Loki, Datadog, OpenTelemetry |

### Output of Stage 3

- `ARCHITECTURE.md` — full stack diagram (text-based) + per-layer decisions with rationale
- `ADRs/` (Architecture Decision Records) — one markdown file per significant decision, especially for AI/ML serving and data storage

---

## Stage 4 — AI/ML Integration Design

**Trigger:** After architecture is confirmed. This is the highest-collaboration stage with the research team.

### Research team interface agreement

Before writing integration code, agree in writing with the researcher team on:

| Contract | Detail |
|----------|--------|
| **Model API** | Input format, output format, schema, versioning |
| **Inference endpoint** | gRPC vs. REST, authentication, rate limits |
| **Model artifact** | Location, format (ONNX, PyTorch, HF), versioning |
| **Fallback behavior** | What happens when the model returns low-confidence or errors |
| **Evaluation metrics** | How model quality is monitored in production |
| **Retraining triggers** | When and how the model is updated |

### Integration patterns — choose based on requirements

- **Synchronous inference**: User request → backend → model API → response. Use for low-latency (<500ms) single predictions.
- **Asynchronous inference**: Request queued → worker calls model → result fetched or pushed. Use for heavy inference (>1s) or batch.
- **Batch inference**: Scheduled job processes data in bulk. Use for analytics, pre-computation, or offline scoring.
- **Streaming inference**: Model outputs tokens or results incrementally. Use for LLMs, generative models, real-time dashboards.

### Implementation checklist

- [ ] Model client library or API wrapper written and unit-tested
- [ ] Input validation layer (schema enforcement before model call)
- [ ] Output parsing and normalization (research output → product data model)
- [ ] Error handling: timeout, model unavailable, malformed output
- [ ] Confidence threshold handling (reject, fallback, or flag for review)
- [ ] End-to-end integration test with mock and live model
- [ ] Latency and throughput benchmarks recorded

**Decision gate:** Present integration design to research lead. Confirm model interface contract is signed off before building dependent UI/backend layers.

### Output of Stage 4

- `AI-INTEGRATION.md` — interface contract, integration pattern, data flow diagram
- Model client module (code) with unit tests
- Integration test suite

---

## Stage 5 — UI & Web Presence

**Sub-skill:** `auto-website-builder`

**Trigger:** After AI integration design is confirmed (parallel with Stage 6 where feasible).

**The AI Engineer does not build the UI directly.** This stage has three responsibilities: write a precise brief for `auto-website-builder`, review its output against research and product requirements, and integrate the generated frontend with the backend and AI layers.

### 5a — Write the auto-website-builder Brief

Compose a written brief covering every input `auto-website-builder` needs. Do not invoke it before the brief is complete.

| Brief field | Source | Notes |
|-------------|--------|-------|
| What does the product do? (1–3 sentences) | PRD problem statement | Translate from research jargon to user language |
| Primary buyer and end user | PRD Stage 1 ICP | |
| Biggest pain eliminated | PRD user stories | Lead with benefit, not feature |
| 3 direct or indirect competitors | Research brief / PRD | |
| Industry vertical | PRD | |
| B2B, B2C, or developer-facing? | PRD | |
| Product stage | PRD | MVP / Early access / GA |
| Existing name, logo, or brand assets | Stage 1 intake | Provide if researcher team has brand constraints |
| Primary goal of the site | PRD goals section | Leads / signups / downloads / docs traffic |
| AI feature descriptions (for product page) | Stage 4 AI-INTEGRATION.md | Plain-language descriptions of what the AI does; avoid model internals |
| Backend API endpoints (for docs / implementation page) | Stage 6 OpenAPI spec | Share endpoint list so auto-website-builder can generate accurate implementation steps |
| Hard constraints | PRD constraints section | Privacy policy requirements, compliance badges, on-prem availability |
| Research paper or publication link (if public) | Stage 1 | For credibility / "Built on research" section |

### 5b — Invoke auto-website-builder

Hand off the completed brief and let `auto-website-builder` run its full pipeline (Phases 1–7). Do not interrupt or override its brand, messaging, or code generation decisions unless they conflict with a constraint in the brief.

**Mandatory review checkpoints** — after `auto-website-builder` delivers its output, the AI Engineer must verify:

| Checkpoint | What to check | Action if failed |
|------------|--------------|-----------------|
| AI feature accuracy | Does the product page accurately describe the AI/ML component? No overclaiming, no underclaiming. | Provide corrected copy to `auto-website-builder` for revision |
| Research fidelity | Are any research-derived claims (accuracy numbers, benchmarks, paper citations) correct? | Escalate to research lead for approval before launch |
| API documentation accuracy | Do implementation steps and docs match the actual backend API endpoints and auth model? | Update with correct endpoint details |
| Compliance section | Does the privacy policy cover the actual data the product collects? | Flag gaps; advise user to have legal review |
| Brand alignment | Do brand constraints from Stage 1 (e.g., researcher team's existing color scheme) conflict with generated brand? | Surface conflict; defer to research lead |

### 5c — AI-specific UI integration

After `auto-website-builder` delivers the Next.js codebase, the AI Engineer extends it with AI-specific components that require engineering knowledge to implement:

| Component | Purpose | Implementation notes |
|-----------|---------|---------------------|
| **Streaming output display** | Render incremental model responses | Use SSE or WebSocket; add incremental `<TextStream>` component |
| **Confidence / uncertainty indicator** | Surface model confidence scores | Validate display thresholds with research lead before shipping |
| **Async job status poller** | Track long-running inference jobs | Poll `GET /jobs/{id}` or use WebSocket push |
| **Model error states** | Distinguish model errors from system errors | Separate error copy: "Our AI couldn't process this" vs "Service unavailable" |
| **Feedback capture** | Thumbs up/down or correction input | Only add if research team needs production feedback for model improvement |
| **API key / auth flow** | Connect frontend auth to backend | Wire Clerk/Auth0 tokens to backend API authorization header |

### Integration checklist

- [ ] Brief delivered to `auto-website-builder` with all required fields
- [ ] `auto-website-builder` output reviewed against all 5 checkpoints above
- [ ] AI-specific components added to the generated codebase
- [ ] Frontend environment variables set for backend API base URL and auth provider
- [ ] All API calls from frontend point to correct backend endpoints (from Stage 6 OpenAPI spec)
- [ ] End-to-end smoke test: user can complete the core AI-powered journey from homepage to result

### Output of Stage 5

- Generated Next.js site from `auto-website-builder` (brand, all pages, copy, design tokens, SVG logo)
- AI-specific component extensions (streaming, confidence, feedback)
- Completed integration of frontend ↔ backend ↔ AI layer
- Review report: checkpoint results, any corrected content, research-lead approvals for public claims

---

## Stage 6 — Backend Development

**Trigger:** After PRD and architecture confirmed (parallel with Stage 5 where feasible).

### API design

1. Define REST or GraphQL endpoints for each PRD feature.
2. Document each endpoint: method, path, request schema, response schema, error codes.
3. Write an OpenAPI / Swagger spec before implementation.

### Core backend modules

| Module | Responsibility |
|--------|----------------|
| **Auth** | User identity, session management, role-based access |
| **Model gateway** | Wraps the AI integration client; handles routing, retries, rate limits |
| **Data layer** | CRUD operations, ORM/query builder, migrations |
| **Job queue** | Async task management for heavy inference or batch jobs |
| **Webhooks / events** | Notify frontend or external systems of async results |
| **Admin API** | Internal endpoints for monitoring, model management, feature flags |

### Implementation checklist

- [ ] OpenAPI spec written and reviewed
- [ ] Auth endpoints implemented and tested
- [ ] Model gateway module wraps AI integration client
- [ ] CRUD endpoints for core data entities
- [ ] Async job queue wired up (if applicable)
- [ ] Unit tests for all business logic
- [ ] Integration tests for API endpoints
- [ ] Environment-based config (no hardcoded secrets)
- [ ] Database migrations versioned

### Output of Stage 6

- Backend service (repository or module)
- OpenAPI spec
- Database schema with migration scripts
- Test suite (unit + integration)

---

## Stage 7 — Integration, Testing & QA

**Trigger:** After Stages 5 and 6 are functionally complete.

### Test levels

| Level | Scope | Tools |
|-------|-------|-------|
| **Unit** | Individual functions and modules | pytest, Jest, Vitest |
| **Integration** | Service-to-service, DB, model API | pytest, Supertest |
| **End-to-end** | Full user journey through UI | Playwright, Cypress |
| **AI/ML quality** | Model output correctness in product context | Custom eval suite (consult research team) |
| **Load** | Throughput and latency under expected peak load | k6, Locust |
| **Security** | OWASP Top 10 basics, auth boundary checks | Manual + automated scan |

### Research team QA collaboration

- **AI output correctness review**: Have the researcher team review a sample of real inference outputs from the integrated system. Surface discrepancies between paper-reported behavior and production behavior.
- **Edge case inventory**: Ask the researcher team for known edge cases, out-of-distribution inputs, and failure modes the model exhibits. Write test cases for each.

### Definition of done for Stage 7

- [ ] All P0 features pass acceptance criteria from PRD
- [ ] AI/ML output quality validated by research team on production-like data
- [ ] No critical or high security issues outstanding
- [ ] Load test shows system meets latency and throughput targets under peak load
- [ ] End-to-end test suite covers all core user journeys

### Output of Stage 7

- QA report (test results, coverage, open issues)
- Edge case test suite (co-authored with research team)
- Load test results and identified bottlenecks

---

## Stage 8 — Scaling & Production Hardening

**Reference:** `references/scaling-playbook.md` for patterns and runbooks.

**Trigger:** After Stage 7 QA pass.

### Scaling dimensions to address

| Dimension | Target | Approach |
|-----------|--------|----------|
| **Inference throughput** | Requests/sec under peak | Model batching, GPU auto-scaling, request queuing |
| **Backend throughput** | API requests/sec | Horizontal pod autoscaling, connection pooling |
| **Data volume** | Storage growth rate | Partitioning, archival strategy, index optimization |
| **Latency** | P95 and P99 targets from PRD | CDN for static assets, caching layer, async offload |
| **Availability** | Uptime SLA | Multi-AZ or multi-region deployment, health checks, circuit breakers |
| **Cost** | Cost per inference / cost per user | Spot instances, request batching, model quantization |

### Production hardening checklist

- [ ] Model serving: GPU auto-scaling configured, warm pool set
- [ ] Backend: horizontal autoscaling with CPU/memory thresholds
- [ ] Database: read replicas, connection pooling, slow query monitoring
- [ ] Caching: Redis or CDN layer for expensive or repeated computations
- [ ] Rate limiting: per-user and per-API-key limits enforced
- [ ] Secrets management: all secrets in vault (AWS Secrets Manager, GCP Secret Manager, Vault)
- [ ] Observability: logging, metrics, distributed tracing in place; dashboards and alerts configured
- [ ] Incident runbook: on-call rotation, escalation path, model rollback procedure
- [ ] Disaster recovery: backup and restore tested for database and model artifacts

**Decision gate:** Present scaling plan and hardening checklist to research lead. Confirm model rollback and retraining integration points before going live.

### Output of Stage 8

- `RUNBOOK.md` — operational runbook (deploy, scale, roll back, incident response)
- Infrastructure-as-code (Terraform, Pulumi, or Helm charts)
- Observability dashboards and alert definitions
- Cost model (estimated cost at target traffic volumes)

---

## Stage 9 — Handoff & Knowledge Transfer

**Trigger:** After Stage 8 production readiness is confirmed.

### Deliverables

1. **Engineering handoff document**: System overview, repository structure, local dev setup, deployment guide, key architectural decisions and their rationale.
2. **Research integration guide**: How the AI/ML component is integrated, interface contracts, how to update or swap the model, evaluation pipeline.
3. **Operations guide**: How to monitor, scale, and debug the system in production.
4. **Open items register**: All known technical debt, deferred features, and future scaling concerns, with owners and priority.
5. **Demo and walkthrough**: Record or conduct a live walkthrough covering the full user journey, AI integration, and ops dashboard.

---

## Cross-Stage Principles

### Research lead consultation protocol

At every stage, any decision that affects:
- Model fidelity or correctness
- Evaluation metrics or thresholds
- The research paper's core claims as expressed in the product

…must be surfaced to the research lead before being implemented. Do not silently override research constraints with engineering pragmatism.

### Living Engineering Log

Maintain an `ENGINEERING-LOG.md` alongside the Research Log. After each stage:
```
## Stage N — [Name] — [Date]
Status: complete / in-progress / blocked
Key decisions: [list with rationale]
Research team touchpoints: [summary of what was discussed and agreed]
Open items: [list]
```

### Escalation protocol

Escalate to the research lead immediately when:
- The model's production behavior diverges significantly from the paper's reported results.
- A scaling constraint (latency, cost, memory) forces a compromise on model quality.
- A user privacy or compliance constraint conflicts with the research team's data requirements.
- A research dependency is not deliverable in time for the engineering milestone.

### No shortcuts on AI correctness

Engineering velocity does not justify silently degrading the AI/ML component's fidelity. If a deadline forces a trade-off, surface it explicitly to the research lead and document the decision.

---

## Quick-Start Paths

| User intent | Entry point | Notes |
|-------------|-------------|-------|
| "We have a paper, build the product" | Stage 1 → full pipeline | Run `research-paper-review` in parallel with Stage 1; `auto-website-builder` runs at Stage 5 |
| "PRD exists, build it" | Stage 3 → full pipeline | Confirm research dependencies table exists; brief `auto-website-builder` at Stage 5 |
| "Stack is chosen, build AI integration + app" | Stage 4 → 5 → 6 → 7 → 8 | Verify interface contract with research team before Stage 4; run `auto-website-builder` at Stage 5 in parallel with Stage 6 |
| "Just build the website/marketing site" | Stage 5 only | Write the brief from PRD and invoke `auto-website-builder` directly |
| "MVP built, make it production-ready" | Stage 7 → 8 → 9 | Run QA first to identify gaps before hardening |
| "Scale an existing deployment" | Stage 8 directly | Use scaling-playbook reference |

---

## Output Summary

| Stage | Artifact | Owner |
|-------|----------|-------|
| 1 | Research-to-Product Brief (approved by research lead) | AI Engineer |
| 2 | PRD.md, RESEARCH-DEPENDENCIES.md | AI Engineer |
| 3 | ARCHITECTURE.md, ADRs/ | AI Engineer |
| 4 | AI-INTEGRATION.md, model client module, integration tests | AI Engineer |
| 5 | Next.js site (all pages, brand, copy) from `auto-website-builder`; AI-specific component extensions; integration review report | `auto-website-builder` → AI Engineer integrates |
| 6 | Backend service, OpenAPI spec, DB migrations, test suite | AI Engineer |
| 7 | QA report, edge case test suite, load test results | AI Engineer + researcher team |
| 8 | RUNBOOK.md, IaC, observability config, cost model | AI Engineer |
| 9 | Engineering handoff doc, research integration guide, open items register | AI Engineer |
| All | ENGINEERING-LOG.md with stage-by-stage entries | AI Engineer |