We taught AIour engineeringdiscipline
Velocity went up several-fold.
Quality, for the first time, stopped depending on the individual engineer
Without a process, AI doesn't accelerate It amplifies what's already broken
Before AI, a weak process simply shipped legacy slowly. With AI, the same thing, ten times faster. Time to release, reliability, understanding of your own system: none of it rests on tools. It rests on repeatability
From kick-off to stable production: TLS, secrets, monitoring, backups, auth, dashboards. Built from scratch every time, by every new team
Holds the whole system in their head. They leave, the product stalls. Documentation ages faster than it's written
But no one checks whether it follows the team's architecture and security model. Generation speed is not delivery speed
AI works the way our best engineers work — because that's how we taught it
Over years of practice, we crystallized our own way of building production software: architectural principles, code review rituals, incident playbooks, ways to separate stable from draft. We don't keep it in our heads. We digitized it. AI inherits that layer
Every engineering decision we make is recorded as a rule in the repository, not in someone's memory, and not in a Notion page no one opens
Every rule gets a machine-enforced check: hooks, gates, agent role limits. Decisions become a system that runs itself, with no reminders required
AI operates on top of this layer. It inherits process the way a new hire inherits a team's culture. But without onboarding, without forgetting, without drift
4 pillars One factory
Each block owns its zone. The contracts between them are explicit. Any part can be shown to an auditor, forked for a client, or handed to a new team, with no context loss
Our corporate platform. Unified SSO, secrets, image registry, end-to-end observability. Every client project plugs in: no separate setup
Standard infrastructure pack per client: containers, configuration, backups, monitoring, recovery. Spins up with a single command
Backend scaffold with architectural artefacts built for code generation. Security, observability, audit — embedded. AI assembles the domain from the approved document
Production-ready backend components: transactional outbox, audit log, idempotency, brute-force protection, metrics, cache, JWT. The base layer the domain is built on
2 deployment modes
1 methodology · 2 architecturesWe pick the architecture to fit the task. The templates, the artefacts, the quality controls are all the same
Docker Compose, one machine. Fast launch, low operating cost, simple DR. Fits MVPs, mid-load systems, isolated corporate environments
Horizontal scale, multi-region, high load. Event buses, OLAP analytics, long-running process orchestration. For heavily loaded and distributed products
From day one — what teams usually build by month 6
Security, observability, recovery — baked into the template. Not built from scratch on every project. Designed once, documented, proven in production operation
→ total saved·~6 months·of calendar time
First we break the business into atoms Then we write code
Before writing any code, we break down the partner's strategy and business processes using four proven methodologies. Each one shows the domain from a different angle: hypotheses, user experience, MVP slice, event model. The output is a set of artefacts from which the application follows as a consequence, not as guesswork
A tree from business metric down to specific feature. Every branch is a testable hypothesis about user behaviour
"we're building this feature because they asked for it": no link to strategy or metric
The full user journey through company processes, overlaid with backstage systems and pain points
tunnel vision on one feature without seeing what breaks around it
A two-dimensional map: user journey × implementation depth. The MVP and the iterations after it are sliced out of this map
"we need everything at once, perfect": no slice that can be shipped first
Collaborative modelling with the partner's team: domain events, commands, aggregates, policies. Maps directly into our docs/domains/ templates
the gap between "how the business thinks" and "how it's described in the code": shared vocabulary from the first meeting
One artefact — 6 layers of code
Analytics artefacts move into a single markdown format. From the approved document, AI assembles every implementation layer, the same way on every project. Until the document is approved, generation does not run: status: draft — stop
From advice to hard blocks
Five layers of reliability: from "remember and apply" to "this command will not physically execute." Each next layer eliminates a class of errors the previous one couldn't catch
"Instructions are advice. Blocks are a guarantee of execution"
8 layers — each closes its own class of attack
Not "later, when we get to it." Each layer is a known attack vector with a built-in response in the template. All of it is already running on the first deploy
Automatic security updates, precise time for logs, kernel limits. Baseline host hardening — out of the box
Key-based login only. After 5 failed attempts — one-hour ban. Passwords aren't disabled until keys are configured. No one gets locked out
WAF with curated rule sets. Mandatory HTTPS, modern TLS, pre-configured HSTS. Noisy traffic is dropped at the edge
Image versions pinned by hash. Updates only by deliberate action. Read-only filesystems where possible. Databases unreachable from the public network
Rate limits, body size caps, security headers, idempotent retries. Every request is tied to a trace: the full path is visible
Strict algorithm verification on every entry. Strong password hashing. Refresh reuse → instant session kill and an audit event
Centralized vault. Access scoped by project and environment. A foreign project gets a policy-level refusal, not a discipline-level one
Append-only log: nothing can be deleted or altered. Correlated with traces and request IDs
Observability — a finished dashboard, not a separate project
Metrics, logs, and traces are collected automatically, the moment the modules are wired in. Business indicators live on the same panels as infrastructure ones. No separate weeks of observability work
Not just CPU and disk. Conversion drops, error spikes, business indicators drifting off baseline — configured to your metrics and thresholds. Every alert ships with context: what happened, in which service, on which request
Not Slack, not email. Alerts arrive as push notifications on the phone, instantly, with the incident's details. Access is granted to those who actually need it: engineers, operations, business stakeholders. Part of our infrastructure offering
Isolation by cryptography, not by discipline
Each tenant runs in its own logical contour. To impersonate another tenant's identifier, three independent checks would have to be broken simultaneously. This is not a requirement on developers — it's a property of the platform
12 decisions — each closes its own class of bugs
Not marketing — every decision actually exists in the code, verifiable in a minute: open the repo, find the line. Architecture, documentation, templates, quality, release, AI. No vague promises
The inner domain knows nothing about Postgres, HTTP, or queues: only interfaces. Swapping the storage layer means two folders. This isn't "later, on big projects", it's the default on day one
The mapping from markdown sections to Go constructs is fixed in a single document. Property → getter; emitted event → publish to outbox in the same transaction. Teams build code by identical rules
Any change starts with an update to the markdown document: business logic, API, infrastructure service. status:draft blocks the build, a missing section blocks the skill. AI physically cannot step outside the description. The document is its contract. A year after release, the documentation still reflects the current state
audit · outbox · brute-force · http · auth · observability — each kit brings its own migration schema, its own metrics, its own fx-module. These aren't "utilities," they're infrastructure contracts with boundaries
aggregate · entity · event · use-case · policy · value-object · context-readme. Each has strict frontmatter, required sections, and validated cross-document referential integrity
The same service is described in two formats: compose — for the single-VPS start (day one, low cost); Helm chart — for scale, when horizontal fault tolerance is needed. The transition doesn't require rewriting the application
Every line — business logic, infrastructure wrappers, utilities — is written test-first: contract first, implementation after. A PR without tests, or with a coverage drop, won't pass CI. Integration tests run against real Postgres / NATS / Redis in containers, not against mocks
golangci-lint in strict mode with 30+ checkers. depguard declaratively forbids imports across domain boundaries: the inner domain can't pull in an infrastructure package, a repository can't call a handler. Architectural layers can't "accidentally" merge. CI won't let it through
Every stage is a blocking gate. Failed lint: no tests. Failed test: no build. A dependency vulnerability found: no deploy. No stage is "skippable if urgent"
Every environment is a separate compose stack, separate Vault secrets, separate databases, separate domain. Prod is physically unreachable from dev: there's no network path. Test data does not leak into production, directly or indirectly
Rollouts to prod require explicit approval from the designated reviewers in the PR. After deploy, the health check is monitored for N seconds. If it doesn't go green, the previous version is restored automatically, with no human in the loop
/add-domain, /add-endpoint, smartdev: step-by-step procedures with preconditions, not "prompts." The reviewer is given read-only tools. Edit/Write are physically absent from its toolset. The agent isn't a "creator," it's the executor of a reproducible script
The questions they'll ask us first
01objectionAI is unpredictable — something is bound to break+
02objectionA template is reinventing the wheel — our requirements are unique+
03objectionWon't we end up locked into the STIT ecosystem?+
04objectionWhat happens if STIT disappears?+
05objectionAI might just "make things up"+
06objectionWhere's the proof this actually works?+
8 episodes of a live walkthrough
The full walkthrough is 30 minutes with a host. Not slides: real commands against live infrastructure. Under NDA we open the corporate stack and the reference projects
Pipeline in Gitea: lint → test → security scan → build → deploy → health check, all green. The version on /health changes in the time it takes to grab a coffee
"Deploy" isn't an event with five people on their phones — it's a button
We open docs/domains/user/aggregate.md, run /add-domain: entity.go, usecase.go, events.go, policy.go, repository.go, handler.go appear. Everything compiles, tests are in place
AI doesn't "suggest." AI executes a fixed procedure against an approved document
We open a PR, delegate to the reviewer agent. It reads the diff, leaves comments. On a "let me just fix that" attempt, the tool refuses: Edit/Write are physically absent from its set
A reviewer can't "fix" instead of "comment." Review stays review
POST to the API → the trace appears in Tempo. The chain: handler → DB (pgx) → outbox → NATS → consumer → outbound HTTP. One trace_id, no gaps, every step's duration visible
"Where did it fail?" — one click in the dashboard, not half an hour in the logs
We change X-Tenant-ID in a curl request → rejected at the perimeter. Change it in the body: rejected at the storage entrance. Query the DB past the sink: no data in the response
"One bug = all tenants leaked" — physically impossible: three checks have to be broken at once
We use refresh, get a new pair. We use the same refresh again: the session is killed instantly, audit_log gets a refresh_reused entry, the user is logged out on every device
"Our token was stolen" — detected in seconds, not weeks
We start a production deploy on a PR without sign-off from the designated reviewers, and the pipeline halts at the approval gate, notifications go to the responsible parties. After approval, the rollout proceeds automatically
An "accidental release" to production — impossible, technically and organisationally
On staging Postgres we DROP DATABASE → run the recovery procedure → restic restores the latest backup → integrity check → /health green. RPO and RTO measured in real time
DR isn't "a piece of paper with words on it" — it's a measurable operation with a known duration
We become your engineering contour
Not a one-off project. A long-term partnership in which we take on four zones of responsibility and operate inside the logic of your business
No funnel
No account managers
A short note about the task, over Telegram. We reply ourselves. If it's within our expertise, we'll set up a meeting. If it isn't, we'll say so honestly