How Kooltra Builds, Part 2: Our AI-Assisted Engineering Workflow and Its Guardrails

In June, we shared how we reorganized our teams around AI: small Builder PODs, Forward Deployed Engineers, and Context Owners who bring the customer into the loop from day one. This follow-up goes one level deeper, into the engineering workflow itself and the security guardrails around it.

The short version: AI does the drafting, checking, and legwork at every step, and our engineers own the decisions. The AI works inside guardrails we define centrally. It can look but not touch, and a person approves every action that matters.

How does AI fit into Kooltra's engineering workflow?

Every change moves through five steps:

1. Align: Agree the specification

For any change to a business rule, the AI first drafts a specification. It covers a short proposal explaining why the change matters, the requirements written as concrete "given, when, then" scenarios, a design that records the key decisions behind it, and a task list. Our team reviews and agrees on the spec, not just the code that comes later. Once the change is finished, those decisions become architecture decision records, the established patterns our design reviewer checks future changes against.

Business capabilities that span more than one product are captured centrally as "stories," with one linked change for each affected codebase.

Not everything needs a spec. Small technical fixes, such as refactoring, dependency updates, and crash fixes, skip this step on purpose. We have explicit rules for when a spec is required, so it doesn't turn into paperwork.

2. Deliver: Write the code from the agreed spec

The AI implements against the agreed task list. It loads our in-house "skills": packaged knowledge of how Kooltra develops services, covering our SDK, messaging, error handling, observability, architecture boundaries, and testing. The result is code written the Kooltra way, not generic code.

Tests come straight from the spec's scenarios, so what we agreed to and what we test are the same thing.

3. Review: AI first, people last

Before a person looks at a pull request, it passes through several automated reviewers. A general-purpose AI code reviewer does a first pass. Then our own specialist AI reviewers each check one thing:

• Correctness and our coding conventions
• Security, including authentication, tenant isolation between customers, and credentials
• Distributed-systems failure modes, such as what happens if a service stops halfway through a task
• Design decisions, checked against our recorded architecture decisions
• Whether the code actually matches the agreed spec
• API contract changes and breaking changes

The human reviewer then gets a briefing: what changed, what the automated reviewers already covered, and which lines implement which requirement. Their time goes to the decisions behind the change: the ones recorded in the spec's design, and the ones made in the code without being stated. That's where reviewers ask questions and push back, instead of reading line by line.

4. Test & Release: A person at every gate

After a change is merged, the AI generates the development test plan directly from the spec's scenarios. It runs the parts that can be automated, including data queries, API calls, and browser-driven checks of the user interface, and reports the results for an engineer to confirm.

Releases follow a staged runbook with human approval gates. After a production release, the AI monitors errors, latency, and alerts against the pre-release baseline for 30 minutes and drafts the sign-off for an engineer to review and approve.

5. Continuous Improvement: Learn from mistakes every week

When a human reviewer catches something the AI reviewers missed, we turn it into a fix to the relevant skill or reviewer, so the same gap doesn't come back. We batch those improvements weekly. Everything lives in one shared repository, so every engineer works with the same skills and rules.

How does Kooltra keep AI safe around customer data and production systems?

We hold our AI tools to the same principles as the rest of our security program: least-privilege access, human approval for anything that matters, and an audit trail. Six guardrails make that concrete.

1. One shared, version-controlled rulebook

Every engineer's AI setup comes from the same central configuration, and changes to it must be reviewed and approved by our platform team.

2. Ask before writing, and never do anything destructive

Actions that write or change anything need a person's approval, including pushing code, editing our internal documentation and tickets, sending messages, and running scripts. Some actions are blocked outright, even if someone asks: merging pull requests, deleting repositories or releases, and bulk data deletion. Merging code is always a human decision.

3. Secrets never enter the AI's context

The AI is blocked from reading credential files, keys, environment files, and login stores. When it needs to query a system, a vetted script handles the login, so the AI never sees the password or key.

4. Production is protected by default

A guard checks every command for the environment it targets, because the target isn't always obvious from the command itself. Read-only work against test environments goes through. Anything that touches a production environment requires review and sign-off. Writes to production are denied, and the AI's cloud access runs in read-only mode. If the guard can't tell whether an environment is production, it treats it as production.

5. A security review on every change

Every pull request gets a dedicated AI security review covering authentication, tenant isolation between customers, credentials, unsafe input handling, and new public endpoints. It reports only high-confidence findings, so engineers act on them rather than learning to tune them out. Human code review still follows.

6. People stay accountable

The AI drafts, investigates, and reviews. People approve specs, merge code, approve release gates, and sign off on production deployments. That gives us an audit trail of who made each change, and when.

What this means for our customers

• Faster integrations. For certain feature sets, such as payment and trading integrations, we're already seeing implementation time fall by close to 75%. Most of our focus right now is on quality, and we'll share fuller results early next year.
• More engineering time on what matters. The AI handles the legwork, so our engineers spend their time on judgment: design, edge cases, and the problem you need solved.
• Changes you can trace. Every business-rule change starts from an agreed spec, and every merge and production release is approved by a person.
• A clear answer for your risk team. If your vendor-risk or information-security team asks how we use AI, this is the answer, and we're happy to walk them through it.

This is the second look inside how we work. Read Part 1: How Kooltra Builds: AI-Native Product Management & Engineering for the team structure and discovery process behind it.

Have questions about how we develop and secure Kooltra? Visit our Security page or book a call with our team.

Frequently asked questions

Can AI merge code or deploy to production on its own?

No. AI is blocked from merging code entirely, and every production release passes through human approval gates.

Does a person still review every code change?

Yes. Automated reviewers go first so that the human review can focus on judgment. Merging is always a human decision.

Can Kooltra's AI tools see passwords or change production systems?

No. The AI is blocked from credential files and keys, can't write to production, and needs a person's sign-off before any work touches a production environment.

How do you make sure AI-written code is secure?

Every change gets a dedicated AI security review and a human code review. The AI also writes code using our own standards for architecture, error handling, and testing.

Is the process finished?

No. We refine our skills and reviewers every week based on what our engineers catch.