How I Set Up My Environment for AI-Assisted Development

Most of my day-to-day work now runs through an AI-assisted workflow. Here is how I have my environment wired up so the tooling actually accelerates real engineering instead of getting in the way.

The shape of the setup

I treat AI tooling like any other part of my toolchain: it lives next to the editor, the terminal and the container runtime, and it has access to exactly the context it needs — no more.

• Editor + agent in the loop. I keep an agentic coding assistant attached to the repo so it can read the actual source, run commands, and propose diffs I review before they land.
• Project memory. A CLAUDE.md at the repo root documents the architecture, the commands, and the conventions. This is the single biggest quality lever.
• Everything containerized. Postgres, the API and the frontend all come up with one docker compose up, so the agent (and I) can verify changes end-to-end.

CLAUDE.md is the contract

When the commands and the architecture are written down, the assistant follows them instead of inventing its own.

# CLAUDE.md
## Development Commands
- `docker compose up --build -d` — start the full stack
- `npm run dev` — frontend with hot reload
## Architecture
- Layered .NET API (Http.Api → Core.Application → Infrastructure)
- Next.js App Router frontend talking to PocketBase

Guardrails that matter

1. Review every diff. The agent proposes; I decide.
2. Let it run the verification. Tests, type checks and a quick smoke test catch most regressions.
3. Keep secrets out. Env files are git-ignored and mounted read-only.

That combination — real repository access, written-down conventions, and one-command verification — turns the assistant into something that can carry a feature from idea to a reviewable, tested diff.