2026-09-25 · 7 min read

How I engineer with AI

AI made code generation fast. The engineering challenge moved upstream and downstream: define the right problem, engineer the right context, make sound decisions, and verify what reaches production.

I use AI throughout the development lifecycle — from specification and implementation to agents embedded in products — with an engineering process around it. This essay describes that process as it actually runs today, with the numbers it produced.

01 — Spec-driven development

Define before generating.

Features start with requirements, architecture decisions, constraints, acceptance criteria and implementation tasks. Agents work against explicit specifications instead of inferring intent from scattered prompts.

Requirements → Design → Tasks → Implementation → Validation

On Riavor ERP, this approach produced nearly 4,000 lines of specification across 15 documents — architecture, access control, inventory, purchasing, sales, fiscal, finance — before implementation began. When the agent starts writing code, the contract already exists; disagreement surfaces in review of the spec, which is cheap, instead of review of the system, which is not.

02 — Context engineering

The right context beats a clever prompt.

Architecture decisions, domain rules, code conventions and operational knowledge become structured context that agents can load when a task needs it. In my setup this takes the form of reusable skills: each one packages a slice of project knowledge — the server topology, the sanitization checklist, the deploy procedure — and the agent pulls the right one at the right moment instead of reconstructing context every session.

Sources → Skills → Retrieval → Context → LLM

The goal is not giving the model more information — it is giving it the right information at the right moment, with traceable sources.

For larger knowledge bases, the next step is RAG — retrieval over embeddings instead of hand-curated context. That is applied study on my side today, not something I run in production yet; it enters this list the day it ships, with its own numbers.

03 — Guardrails

Generated output is untrusted until verified.

Everything AI produces — code or agent actions — goes through the same engineering controls: code review, automated tests, type checking, security scanning and schema validation on structured outputs. Agent workflows add tool permissions and tracing on top. For higher-risk operations — anything touching production data or money — execution stays behind explicit human approval.

Review → Tests → Security → Schema → Approval

The rule is boring on purpose. Trust is a property of the pipeline, not of the model.

04 — AI inside the product

AI is also part of the architecture.

I integrate LLM capabilities where they solve real user or operational problems: support automation, task-oriented agents, structured extraction, workflows that talk to existing systems. In production, support automation has created 2,500+ tickets for a federal agency operation — triage, classification and ticket creation, running as part of the service desk.

I treat the LLM as another distributed-system dependency:

LLM APIs → Tool calling → Structured outputs → Retries → Observability → Guardrails

The model handles reasoning and language. The surrounding system controls context, permissions, state, validation and execution.

The principle

AI accelerates execution. Engineering determines direction and quality.

I understand and take responsibility for the systems I ship. The leverage comes from combining AI with fundamentals: architecture, system design, debugging, security, domain knowledge and production ownership.

The profile

T-shaped — end-to-end engineer with depth in backend, system integration, automation and resilient architecture.

Ownership — I understand the business problem, evaluate trade-offs, design the solution and remain responsible for its behavior in production.

AI-native — specs, context engineering, skills and agent harnesses are part of the daily engineering workflow, not isolated AI experiments.

Global-ready — technical communication in English across specifications, documentation, code reviews and asynchronous collaboration, while conversational fluency keeps developing.