# anttka4.dev — Anton Tkachenko

Last updated: 2026-10-05

> Precise AI engineering. We audit AI-written code, make it work inside large systems, and automate operations — built to stay visible to ChatGPT, Gemini, Grok and Claude. Improve · Scale · Automate.

This file holds the full English text of every page on www.anttka4.dev. Ukrainian and Czech versions live under /ua/ and /cs/.

<page>
Title: Anton Tkachenko — AI code audit, scaling & automation · anttka4.dev
URL: https://www.anttka4.dev/
Summary: We audit AI-written code, make it work inside large systems, and automate operations — built to stay visible to ChatGPT, Gemini, Grok and Claude.

AI development|Code audit|CI/CD pipelines

# Precise AI engineering.

Improve · Scale · Automate
See what we can do for you →

Built to stay visible to ChatGPT, Gemini, Grok and Claude.

## What a buyer sees when they ask AI

C ChatGPT a buyer, right now

What's the best CRM for a 10-person agency? Not too complicated.

For a small agency I'd look at these:

**1. Your product**yourproduct.com ↗

Simple setup, fixed price per team, works with Gmail.

2. Competitor A — powerful, but heavy for small teams.

3. Competitor B — cheaper, fewer integrations.

**New client** · came from ChatGPT Pro plan

Solutions

## What do you need?

### Audit my AI-written code

AI wrote half your codebase. Nobody knows what breaks next.

We audit it and make it hold up inside a large system.

Audit report in 1 week
Book a call about this → (https://www.anttka4.dev/contact.html?need=audit)

- Full audit of AI-generated code: security, architecture, performance

- Fixes and refactors that fit your existing system

- Automatic checks so the next AI edit can't break production

- We sign an NDA — your code stays private and only yours

### Automate my operations

Your team copies data between tools by hand every day.

We connect your systems and let the routine run itself.

First automation live in 1–2 weeks
Book a call about this → (https://www.anttka4.dev/contact.html?need=automate)

- CRM, email, sheets and payments connected

- AI agents with spending limits and your sign-off

- One clear view of what ran and what it saved

### Stay found by AI

ChatGPT, Gemini, Grok and Claude recommend your competitors — not you.

Every system we touch stays readable, quotable and usable by AI.

Built into every project
Book a call about this → (https://www.anttka4.dev/contact.html?need=ai-visibility)

- Check of real buyer questions across 5 AI chats

- Structured data, llms.txt and pages AI can trust

- Monthly report: mentions and clients from AI

Tech stack

## Built with 50+ tools.

- **AI visibility** llms.txt · schema.org · OpenAPI · SSR / static rendering · Bing & Google indexing · AI referral analytics

- **CI/CD pipelines** GitHub Actions · GitLab CI · Docker · automated tests · preview & staging deploys · one-click rollback · Vercel · Cloudflare

- **Dev control** GitHub Actions · Playwright · visual regression · Lighthouse CI · agent PR policies · preview deploys

- **Web** React · React DOM · Next.js · Astro · Vanilla JS · HTML · CSS · Tailwind CSS · Bootstrap · TypeScript

- **AI infrastructure** Model Context Protocol · TypeScript · SSE transports · agentic workflows · open-source tooling

- **Mobile** Flutter · Dart · React Native · Swift · Objective-C · Kotlin · Xcode pipelines · REST · GraphQL · WebSockets

- **Game development** Godot · Unity · C# · Swift (SpriteKit, SceneKit)

- **Backend & storage** Node.js · Express · Python · Java · PostgreSQL · Prisma · Redis · Firebase · Vercel · Cloudflare edge · GitHub · Stripe

React · Next.js · Flutter · Swift · Kotlin · Node.js · Python · Godot · MCP — and 40 more.

About

## Precision over promises.

Led by **Anton Tkachenko** — fifteen years of building production software across web, mobile and interactive systems.

Every project we take follows the same order: measure, specify, build, test, document. Nothing ships untested. Nothing is handed over undocumented.

Our method comes from game engineering, where a system must behave identically every time. We apply it to AI search, AI-built software and business automation.

A senior lead on every project, from audit to production. A limited number of clients per quarter.

Written scope before work startsTested & documentedNDA on request

Only a few spots open — they fill fast

## Tell me what you need.

One message is enough: your link and one sentence. I reply within a day.

Book a free AI audit call → (https://www.anttka4.dev/contact.html?need=audit)
</page>

<page>
Title: Blog: AI agent harnesses & CI/CD guides · anttka4.dev
URL: https://www.anttka4.dev/blog.html
Summary: Guides on AI agent harnesses: CI/CD with fastlane, Android builds on a private Linux VPS, and running multiple AI coding agents in Docker.

Blog

# Notes from the work.

Practical guides: AI agent harnesses, CI/CD with fastlane, Android builds on a private Linux VPS, and running multiple AI agents in Docker.

Articles are in English.

CI/CD8 min

## How to build an AI agent harness around CI/CD with fastlane (https://www.anttka4.dev/blog/ai-agent-harness-ci-cd-fastlane.html)

AI coding agents can write a feature in minutes. The hard part is everything after that: tests, signing, builds and the moment code reaches real users. Here is how I wrap a mobile CI/CD pipeline around agents with fastlane, so they move fast and still can't ship anything on their own.

Read the article → (https://www.anttka4.dev/blog/ai-agent-harness-ci-cd-fastlane.html)

Infrastructure8 min

## Remote AI agent development over a private VPN: Android builds on a Linux VPS (https://www.anttka4.dev/blog/remote-ai-agent-development-vpn.html)

Long-running AI agents work best on a dedicated machine, not on the laptop you close at night. For Android that machine can be a plain Linux VPS: cheap, always on, and fast enough for Gradle. The catch is reaching it safely. Here is the setup I use: a private WireGuard VPN, where nothing else listens on the public internet.

Read the article → (https://www.anttka4.dev/blog/remote-ai-agent-development-vpn.html)

AI engineering6 min

## What is an AI agent harness? A practical definition for engineering teams (https://www.anttka4.dev/blog/what-is-an-ai-agent-harness.html)

“Use AI agents” is easy advice. Getting AI-written code to hold up inside a large system is not. The difference is the harness — and most teams don't have one yet.

Read the article → (https://www.anttka4.dev/blog/what-is-an-ai-agent-harness.html)

Infrastructure9 min

## How to run multiple AI coding agents in Docker on a remote machine (https://www.anttka4.dev/blog/multiple-ai-agents-docker-remote-machine.html)

One AI agent on one task is useful. Four agents on four tasks — while you review the first pull request — is where a remote machine pays off. The trick is keeping them out of each other's way and out of anything they shouldn't touch. Here is how I run several agents side by side with Docker.

Read the article → (https://www.anttka4.dev/blog/multiple-ai-agents-docker-remote-machine.html)
</page>

<page>
Title: AI agent harness for CI/CD with fastlane · anttka4.dev
URL: https://www.anttka4.dev/blog/ai-agent-harness-ci-cd-fastlane.html
Summary: Let AI coding agents work on mobile apps safely: fastlane lanes as one entry point, signing out of their reach and a human-approved release gate in CI.

## What “harness” means here

An **AI agent harness** is everything around the model that decides what it may touch, how its work is checked and who lets it out. For a mobile app the harness has a simple rule: **the agent proposes, the pipeline verifies, a human releases.** fastlane is a good backbone for this, because it turns every build, test and upload step into a named command that behaves the same on a laptop, on an agent box and in CI.

## Layer 1 — one entry point for humans and agents

Agents get confused by ten ways of doing the same thing. Give them one. Every check lives in a fastlane lane, and the agent's instructions (an `AGENTS.md` or similar file in the repo) say exactly which lanes it may run.

```
default_platform(:ios)

platform :ios do
before_all { setup_ci if ENV["CI"] }

# Safe for agents: no secrets needed
lane :check do
run_tests(scheme: "App", devices: ["iPhone 16"])
end

# CI only: needs signing + App Store Connect access
lane :beta do
api_key = app_store_connect_api_key(
key_id: ENV["ASC_KEY_ID"],
issuer_id: ENV["ASC_ISSUER_ID"],
key_content: ENV["ASC_KEY_P8"],
is_key_content_base64: true
)
match(type: "appstore", readonly: true, api_key: api_key)
increment_build_number(
build_number: latest_testflight_build_number(api_key: api_key) + 1
)
build_app(scheme: "App", export_method: "app-store")
upload_to_testflight(api_key: api_key, skip_waiting_for_build_processing: true)
end
end
```

The `check` lane needs nothing secret, so an agent can run it as often as it likes. The `beta` lane can only succeed where release secrets exist — and they only exist in CI.

## Layer 2 — keep signing out of the agent's reach

Code signing is the real “ship” button, so it is the first thing to fence off:

- **Certificates and profiles** live in an encrypted `match` repository. CI reads them with `readonly: true`; nothing in the pipeline can create or revoke them.

- **App Store Connect access** uses an API key stored as a CI secret, never a personal Apple ID and never a file in the repo.

- **The agent's environment has none of these.** No `MATCH_PASSWORD`, no `.p8` key. If an agent tries to run `beta`, it fails loudly — exactly what you want.

## Layer 3 — CI that verifies, and a human who releases

Pull requests (including the ones agents open) run the safe lane. Merges to `main` run the release lane inside a **protected environment** that waits for a human reviewer before any secret is exposed.

```
name: ios
on:
pull_request:
push:
branches: [main]

jobs:
check:
runs-on: macos-15
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
bundler-cache: true
- run: bundle exec fastlane ios check

beta:
if: github.ref == 'refs/heads/main'
needs: check
runs-on: macos-15
environment: release   # required reviewers = the human gate
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
bundler-cache: true
- run: bundle exec fastlane ios beta
env:
MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
MATCH_GIT_BASIC_AUTHORIZATION: ${{ secrets.MATCH_GIT_BASIC_AUTHORIZATION }}
ASC_KEY_ID: ${{ secrets.ASC_KEY_ID }}
ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }}
ASC_KEY_P8: ${{ secrets.ASC_KEY_P8 }}
```

Store the release secrets as environment secrets on `release`, not repository-wide, so a job outside that environment cannot read them.

## Layer 4 — protect the harness itself

An agent that can edit the pipeline can edit its own rules. Close that loop:

- Branch protection on `main`: pull requests only, required status checks, at least one human approval.

- A `CODEOWNERS` entry for `fastlane/` and `.github/workflows/`, so any change to the harness needs an explicit human review.

- The agent's git token can push branches and open pull requests — never push to `main` or change repository settings.

## Android uses the same pattern

The Android side mirrors iOS: a `check` lane with `gradle(task: "test")`, and a CI-only lane that builds a release bundle and calls `upload_to_play_store(track: "internal")` with a Play service-account key stored as an environment secret. Start on the internal track; promotion to production stays a human decision.

## Checklist

- Every build, test and upload step is a fastlane lane.

- Agents may run only lanes that need no secrets.

- Signing via `match` in read-only mode; App Store Connect via an API key.

- Release jobs run in a protected environment with a required reviewer.

- `CODEOWNERS` guards `fastlane/` and the CI workflows.

With this in place, agents can iterate as fast as they like inside the fence, and every build that reaches TestFlight or Play has passed the same tests and the same human gate. Building Android on a remote Linux machine? The next step is keeping that VPS on a private VPN (https://www.anttka4.dev/blog/remote-ai-agent-development-vpn.html).

Tell me what you need.

One message is enough: your link and one sentence. I reply within a day.
Book a free AI audit call → (https://www.anttka4.dev/contact.html?need=audit)
</page>

<page>
Title: Run multiple AI coding agents in Docker remotely
URL: https://www.anttka4.dev/blog/multiple-ai-agents-docker-remote-machine.html
Summary: Run several AI coding agents in parallel on one remote Linux machine: a Docker container and git clone per agent, resource limits, no secrets, CI as the gate.

## The idea in one picture

One remote Linux machine, reachable only over a private VPN (see Android builds on a Linux VPS over WireGuard (https://www.anttka4.dev/blog/remote-ai-agent-development-vpn.html)). On it, every agent gets:

- **its own container** — its own processes, limits and filesystem;

- **its own git clone** on its own branch — no two agents edit the same working copy;

- **its own caches** — no lock fights over Gradle or npm caches;

- **one task** — written down before it starts.

Everything they produce comes back as pull requests, and CI decides what is good enough to merge.

## Step 1 — one image for all agents

Build one image with your toolchain and a non-root user whose ID matches the owner of the clones on the host, so files stay writable on both sides:

```
FROM eclipse-temurin:17-jdk

RUN apt-get update \
&& apt-get install -y --no-install-recommends git curl unzip ruby-full build-essential tmux \
&& rm -rf /var/lib/apt/lists/*

ARG UID=1000
RUN userdel -r ubuntu 2>/dev/null || true \
&& useradd -m -u $UID agent

USER agent
WORKDIR /work
```

Install your agent CLI of choice in the same image (the steps differ per tool). The Ubuntu-based base image ships a default `ubuntu` user with ID 1000, which is why it is removed first.

## Step 2 — one clone per agent

```
mkdir -p ~/agents/work
for n in 1 2 3; do
git clone git@github.com:acme/app.git ~/agents/work/agent-$n
git -C ~/agents/work/agent-$n switch -c agent-$n/task
done
```

Why not `git worktree`? A worktree's `.git` file points to the main repository by its absolute path on the host. Mount only the worktree into a container and git inside it can't find that path. Separate clones cost a little disk and avoid the problem entirely.

## Step 3 — Docker Compose with a shared agent template

```
x-agent: &agent
build:
context: .
args:
UID: "1000"
image: agent-box
init: true
stdin_open: true
tty: true
command: sleep infinity
cap_drop: [ALL]
security_opt: ["no-new-privileges:true"]
mem_limit: 6g
cpus: 2
pids_limit: 512
env_file: agent.env   # model API key + scoped git token, nothing else

services:
agent-1:
<<: *agent
volumes:
- ./work/agent-1:/work
- gradle-1:/home/agent/.gradle
agent-2:
<<: *agent
volumes:
- ./work/agent-2:/work
- gradle-2:/home/agent/.gradle
agent-3:
<<: *agent
volumes:
- ./work/agent-3:/work
- gradle-3:/home/agent/.gradle

volumes:
gradle-1: {}
gradle-2: {}
gradle-3: {}
```

```
docker compose up -d --build
```

Limits matter more than they look: without `mem_limit`, one agent's runaway Gradle build can push the whole machine into swap and slow every other agent to a crawl.

## Step 4 — what the containers must never get

- **The Docker socket.** Mounting `/var/run/docker.sock` into a container gives it control of the host — effectively root. Agents never get it.

- **Release secrets.** No signing keys, store credentials or production database URLs. The env file holds a model API key and a git token that can push branches and open pull requests — nothing else. Releases stay in CI, behind a human-approved environment (https://www.anttka4.dev/blog/ai-agent-harness-ci-cd-fastlane.html).

- **Your SSH keys and shell history.** Only the agent's own clone is mounted.

## Step 5 — work with the agents

Start each agent in a tmux session on the host, so sessions survive when you disconnect from the VPN:

```
tmux new -d -s agent-1 'docker compose exec agent-1 bash'
tmux attach -t agent-1
```

Check how hard the machine is working at any time:

```
docker stats --no-stream
```

To preview an agent's dev server, publish its port on the VPN address only — never on all interfaces:

```
agent-1:
<<: *agent
ports:
- "10.8.0.1:3001:3000"
```

Agent 1's app is then at `http://10.8.0.1:3001` for devices on the VPN, and invisible from the internet.

## Step 6 — coordinate the work

- **Split tasks by module, not by step.** “Agent 1: login screen. Agent 2: crash in sync. Agent 3: tests for billing” — not three agents on one feature.

- **Write each task down** in the agent's branch (a short `TASK.md` works) together with the repository's agent instructions file, so every agent starts from the same rules.

- **One branch, one pull request per agent.** CI runs the same checks for every PR; conflicts are solved at review time, not by agents overwriting each other.

More about those rules in what an AI agent harness is (https://www.anttka4.dev/blog/what-is-an-ai-agent-harness.html).

## Step 7 — reset an agent

When a task is merged — or goes wrong — throw the state away instead of repairing it:

```
docker compose rm -sf agent-2
git -C ~/agents/work/agent-2 fetch origin
git -C ~/agents/work/agent-2 switch -C agent-2/next-task origin/main
docker compose up -d agent-2
```

The container starts clean, the clone is back on the latest `main`, and the agent's build cache volume keeps builds fast.

## Checklist

- Machine reachable only over the VPN; dev servers bound to the VPN address.

- One container, one clone, one branch and one task per agent.

- Non-root user, capabilities dropped, memory, CPU and process limits set.

- No Docker socket, no release secrets, no personal keys in containers.

- Separate cache volumes per agent.

- Agents deliver pull requests; CI and a human decide what merges.

Tell me what you need.

One message is enough: your link and one sentence. I reply within a day.
Book a free AI audit call → (https://www.anttka4.dev/contact.html?need=audit)
</page>

<page>
Title: Remote AI agents: Android builds on a Linux VPS via VPN
URL: https://www.anttka4.dev/blog/remote-ai-agent-development-vpn.html
Summary: Run AI agents and Android builds on a Linux VPS with nothing exposed: WireGuard VPN, per-peer firewall rules, private APK sharing and CI that joins per job.

## Why put agents and Android builds on a Linux VPS

- **Agents run for hours.** Tests, builds and refactors keep going when your laptop sleeps.

- **Android builds don't need a Mac.** The Android SDK command-line tools, a JDK and Gradle run on any Linux server. Pick a VPS with enough RAM and CPU cores for Gradle — memory is usually the first bottleneck.

- **Emulators are optional.** Unit tests and builds need no emulator. If you want instrumented tests on the VPS, choose a host that exposes KVM, otherwise the emulator is too slow to be useful.

- **Isolation.** The agent gets its own user, its own tokens and its own disk — not your personal accounts and SSH keys.

The risk is the opposite of isolation: an SSH port or a dev server open to the whole internet. A WireGuard VPN removes that risk.

## The layout

The VPS runs a WireGuard interface, `wg0`, on the private range `10.8.0.0/24`. Each device gets its own key and a fixed address: the VPS is `10.8.0.1`, your laptop `10.8.0.2`, your Android phone `10.8.0.3`, the CI runner `10.8.0.10`. The only port open to the internet is WireGuard's UDP port — and WireGuard does not answer packets from unknown keys, so to a scanner the VPS looks silent.

## Step 1 — install WireGuard and create keys

```
sudo apt install wireguard
wg genkey | tee vps.key | wg pubkey > vps.pub
```

Repeat `wg genkey` for every device. Private keys stay on the device they belong to; only public keys are copied around.

## Step 2 — configure the VPS

`/etc/wireguard/wg0.conf` lists every allowed device by its public key. A device that is not listed cannot connect.

```
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <vps-private-key>

# laptop
[Peer]
PublicKey = <laptop-public-key>
AllowedIPs = 10.8.0.2/32

# Android phone
[Peer]
PublicKey = <phone-public-key>
AllowedIPs = 10.8.0.3/32

# CI runner
[Peer]
PublicKey = <ci-public-key>
AllowedIPs = 10.8.0.10/32
```

```
sudo systemctl enable --now wg-quick@wg0
```

## Step 3 — connect your laptop and phone

Each device gets a small config that points at the VPS:

```
[Interface]
Address = 10.8.0.2/32
PrivateKey = <laptop-private-key>

[Peer]
PublicKey = <vps-public-key>
Endpoint = vps.example.net:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25
```

For the phone, write the same kind of file with address `10.8.0.3` and show it as a QR code for the official WireGuard app:

```
qrencode -t ansiutf8 < phone.conf
```

`AllowedIPs = 10.8.0.0/24` means only VPN traffic goes through the tunnel; everything else on the device uses its normal connection.

## Step 4 — firewall: default deny, then allow per peer

WireGuard decides who may join; the firewall decides what each peer may reach. Set it up **while connected over the VPN** (`ssh agent@10.8.0.1`), so enabling it cannot lock you out:

```
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 51820/udp
sudo ufw allow in on wg0 from 10.8.0.2 to any port 22,8080 proto tcp
sudo ufw allow in on wg0 from 10.8.0.3 to any port 8080 proto tcp
sudo ufw allow in on wg0 from 10.8.0.10 to any port 22 proto tcp
sudo ufw enable
```

Now SSH is reachable only from your laptop and the CI runner, the APK share only from your laptop and phone, and nothing at all from the public internet. Also set `PasswordAuthentication no` in `sshd_config` — keys only.

## Step 5 — build Android on the VPS

Install a JDK and the Android SDK command-line tools for the `agent` user, then give agents one command to run. A fastlane lane keeps it identical to CI:

```
platform :android do
# Safe for agents: no signing keys needed
lane :check do
gradle(task: "testDebugUnitTest")
gradle(task: "assembleDebug")
end
end
```

The agent runs `bundle exec fastlane android check` (or `./gradlew testDebugUnitTest assembleDebug` directly) after every change. Release signing never happens here — the upload keystore and the Play service-account key live only in CI, behind a human-approved release environment, as described in the fastlane harness post (https://www.anttka4.dev/blog/ai-agent-harness-ci-cd-fastlane.html).

## Step 6 — get the APK onto your phone, privately

Serve the build output folder on the VPN address only:

```
python3 -m http.server 8080 --bind 10.8.0.1 --directory ~/app/app/build/outputs/apk/debug
```

With WireGuard on, open `http://10.8.0.1:8080` on your phone, download the debug APK and install it. The server is bound to the VPN address and allowed only for your devices by the firewall — no public download links, no files sent through chat apps. A dev server started by an agent can be shared the same way.

## Step 7 — let CI in, temporarily

If a pipeline needs to reach the VPS — say, to collect artifacts — store the CI peer's config as a secret and bring the tunnel up only for the job:

```
- name: Join VPN
run: |
sudo apt-get update && sudo apt-get install -y wireguard-tools
echo "${{ secrets.WG_CI_CONF }}" | sudo tee /etc/wireguard/wg0.conf > /dev/null
sudo wg-quick up wg0

# ... steps that use ssh agent@10.8.0.1 ...

- name: Leave VPN
if: always()
run: sudo wg-quick down wg0
```

The firewall rules above limit the CI peer to SSH on the VPS. If the secret ever leaks, delete that one `[Peer]` block on the VPS and the key is useless.

## Step 8 — keep secrets off the VPS

- The agent runs as an unprivileged `agent` user, not as root.

- Its git token is scoped to the repositories it works on: push branches, open pull requests, nothing more.

- No upload keystore, no Play Console key and no production credentials on the VPS. Debug builds are all it ever signs.

## Checklist

- Only WireGuard's UDP port is open to the internet.

- One key and one fixed address per device; remove a `[Peer]` to revoke it.

- Firewall default-deny, with rules per peer on `wg0`.

- SSH with keys only, reachable only over the VPN.

- Agents build and test with one fastlane lane; debug builds only.

- APKs and previews bound to the VPN address.

- CI joins for the job and disconnects at the end.

- No release keystore or Play key on the VPS.

Tell me what you need.

One message is enough: your link and one sentence. I reply within a day.
Book a free AI audit call → (https://www.anttka4.dev/contact.html?need=audit)
</page>

<page>
Title: What is an AI agent harness? A practical definition
URL: https://www.anttka4.dev/blog/what-is-an-ai-agent-harness.html
Summary: An AI agent harness is the instructions, tools, sandbox, checks and human gates around a coding agent. What each part does and how to build one in a week.

## A definition

An **AI agent harness** is everything around a coding agent that decides what it knows, what it can touch, how its work is checked and who lets the result out. The model is the engine; the harness is the chassis, brakes and dashboard.

## The six parts of a harness

- **Instructions and context.** A file in the repository (often `AGENTS.md`) that tells agents how the project is built, which commands to run, which folders are off-limits and what “done” means.

- **Tools.** The commands and services an agent may call — your CLI scripts, a test runner, or **Model Context Protocol (MCP)** servers that expose systems such as issue trackers or databases in a controlled way.

- **A sandbox.** Where the agent runs: its own machine or container, its own user, scoped tokens and no production secrets. For a remote setup, see running agents and Android builds on a Linux VPS over a private VPN (https://www.anttka4.dev/blog/remote-ai-agent-development-vpn.html).

- **Verification.** Tests, type checks, linters and CI that run on every change — the same checks for agent and human code.

- **Gates.** Points where a human must approve: merging to the main branch, touching the pipeline, releasing to users. In mobile, that means a protected release environment — here is how to build it with fastlane (https://www.anttka4.dev/blog/ai-agent-harness-ci-cd-fastlane.html).

- **Observability.** A record of what ran, what changed and what it cost, so you can review agent work after the fact.

## Why AI-written code needs it

Agents are fast and confident, and they write code that looks right locally. Inside a large system, the failures are rarely in the line the agent wrote — they are in what it didn't know: a convention three folders away, a migration that other services depend on, a secret that should never have been in reach. A harness turns those unknowns into explicit rules and automatic checks, so speed doesn't come at the cost of production.

## A first version in a week

- **Day 1** — write the instructions file: build, test and lint commands; folders agents must not edit.

- **Day 2** — make every check runnable with one command each, and make CI run exactly those commands.

- **Day 3** — branch protection with required checks and a human review; a `CODEOWNERS` rule for the CI configuration.

- **Day 4** — move agents to their own sandbox user or machine with scoped tokens.

- **Day 5** — put releases behind a protected environment; release secrets live only there.

After that, improve it the way you improve any system: measure where agent changes fail review, then add the rule or check that would have caught it.

## The harness also makes you visible to AI

The same habits — clear written specs, structured documentation, files such as `llms.txt` — make your product easier for ChatGPT, Gemini, Grok and Claude to read, quote and recommend. Engineering for agents and engineering for AI search turn out to be the same discipline.

Tell me what you need.

One message is enough: your link and one sentence. I reply within a day.
Book a free AI audit call → (https://www.anttka4.dev/contact.html?need=audit)
</page>

<page>
Title: Contact — book a free AI audit call · anttka4.dev
URL: https://www.anttka4.dev/contact.html
Summary: Book a free AI audit call. One message is enough: your link and one sentence. AI code audit, automation and AI visibility — reply within a day.

Only a few spots open — they fill fast

# Tell me what you need.

One message is enough: your link and one sentence. I reply within a day.
</page>

<page>
Title: Terms & conditions · anttka4.dev
URL: https://www.anttka4.dev/terms.html
Summary: Terms of anttka4.dev — Anton Tkachenko, Czech sole trader, IČO 17587557: scope, pricing and VAT, NDA and confidentiality, IP and liability.

# Terms & conditions.

Effective from 5 October 2026

## 1. Provider

- **Name** Anton Tkachenko

- **Legal form** Sole trader (OSVČ) registered in the Czech Trade Register (živnostenský rejstřík)

- **Business ID (IČO)** 17587557

- **Tax ID (DIČ)** CZ686087109 — not a VAT payer (neplátce DPH)

- **Registered office** Malešická 2855/2b, 130 00 Praha 3 – Žižkov, Czech Republic

- **Contact** hello@anttka4.dev (mailto:hello@anttka4.dev) · www.anttka4.dev (https://www.anttka4.dev)

## 2. Scope

These terms apply to the services offered on anttka4.dev — AI code development and audit, scaling AI-built software inside existing systems, operations automation and AI search visibility — provided to business clients. A written scope or order agreed with the client takes precedence over these terms.

## 3. Orders and scope

Work starts only after the client accepts a written scope that states the deliverables, timeline and price. Changes to the scope are agreed in writing (email is enough) before they are carried out. The free AI audit call is a non-binding consultation.

## 4. Prices, invoicing and VAT

Prices are those stated in the accepted scope. Work is invoiced as agreed in the scope, with the payment terms stated on the invoice. The provider is not a VAT payer; for services supplied to VAT-registered businesses in other EU member states, VAT is accounted for by the client under the reverse-charge mechanism.

## 5. Confidentiality and NDA

Your code, data and business information stay private and only yours. They are used solely to deliver the agreed work and are never shared with third parties or used to train AI models. We sign a non-disclosure agreement (NDA) on request before any code is shared.

## 6. Intellectual property

Once the related invoice is paid in full, the client owns the results created specifically for them (code, documentation, configurations). The provider keeps the right to its pre-existing tools, libraries and know-how and grants the client a perpetual licence to use any of them that are included in the deliverables.

## 7. Client cooperation

The client provides the access, information and feedback needed for the work in good time. Delays caused by missing access or information extend the timeline accordingly.

## 8. Liability

Every deliverable is tested and documented before hand-over. To the extent permitted by law, the provider's total liability for any scope is limited to the price paid for that scope, and the provider is not liable for indirect damage or lost profit. This does not limit liability that cannot be excluded by law.

## 9. Governing law

These terms and all contracts under them are governed by the laws of the Czech Republic, in particular the Civil Code (Act No. 89/2012 Coll.). Disputes are decided by the competent courts of the Czech Republic.

## 10. Changes

The provider may update these terms. The version in force when a scope is accepted applies to that scope. The current version always lives at anttka4.dev/terms.html.
</page>

<page>
Title: Privacy & cookies · anttka4.dev
URL: https://www.anttka4.dev/privacy_policy.html
Summary: Privacy at anttka4.dev: the contact form is delivered via Web3Forms and never stored, analytics run only with consent, no ads and no data resale.

# Privacy & cookies.

Last updated: 5 October 2026

## What this site collects

- **Contact form** — what you send (need, message, link, name, email, reply preference) is delivered to us by email through Web3Forms. It is not stored on this site.

- **Analytics** — Google Analytics (Firebase) and Microsoft Clarity measure aggregate visits. Visitors from the EEA, UK and Switzerland are asked first; nothing loads until you allow it. You can change your choice any time via “Cookie settings” in the footer.

- **Your browser** — your language and cookie choice are saved locally. The language is picked from your browser's time zone and language settings, without contacting any location service.

No ads. Your data is never sold or rented.

## How long we keep it

Contact emails — as long as needed to reply and, if we work together, as accounting requires. Analytics — up to 12 months, aggregated.

## Your rights

Ask for access, correction or deletion of your data any time: hello@anttka4.dev (mailto:hello@anttka4.dev).

## Controller

Anton Tkachenko, anttka4.dev — hello@anttka4.dev (mailto:hello@anttka4.dev).
</page>