DEV Community: Ivan

The actual state of self-hosting on a VPS

Ivan — Fri, 09 Oct 2026 08:33:09 +0000

I recently ran into a claim: Docker Compose is outdated and K3s is the king for my 1GB VPS.

At the same time, docker-compose.py is effectively deprecated, with Compose now shipped as a built-in docker compose command. That alone is not a problem, but it raised a reasonable question: has the role of Docker Compose changed, or is this noise from the Kubernetes church?

This post is about self-hosted setups:

one or a few VPS
price sensitivity
limited ops time, bordering on laziness
preference for boring, anti-hype infra

Within that landscape, I compare:

Docker Compose
K3s
Podman + Quadlet
...
Profit!

Docker Compose

No need to explain, here's the docker-compose.yaml.

Compose baseline: app + Valkey

services:
  redis:
    image: valkey/valkey:latest
    restart: unless-stopped
    command: valkey-server --port 6379
    ports:
      - "127.0.0.1:6379:6379"
    healthcheck:
      test: ["CMD", "valkey-cli", "ping"]
      interval: 5s
      timeout: 3s

  python:
    build:
      context: .
      dockerfile: Dockerfile.python
    restart: always
    environment:
      REDIS_HOST: redis
    ports:
      - "8080:8080"
    healthcheck:
      test:
        - CMD
        - python
        - -c
        - "import http.client,sys;
          c=http.client.HTTPConnection('127.0.0.1',8080,timeout=2);
          c.request('GET','/healthz'); r=c.getresponse(); sys.exit(0 if
          r.status==200 else 1)"
      interval: 5s
      timeout: 3s
    depends_on:
      redis:
        condition: service_healthy

Dockerfile.python

ARG BASE_IMAGE=python:3.14-slim-trixie
ARG UV_VERSION=0.9.18-python3.14-trixie-slim

FROM ghcr.io/astral-sh/uv:$UV_VERSION AS uv_carrier
FROM $BASE_IMAGE AS builder

COPY --from=uv_carrier /usr/local/bin/uv /usr/local/bin/
RUN uv venv /opt/venv
ENV PATH=/opt/venv/bin:$PATH

COPY ./requirements.txt requirements.txt
RUN uv pip install -r requirements.txt

FROM $BASE_IMAGE

WORKDIR /opt/app

ENV PYTHONUNBUFFERED=1 \
    PATH=/opt/venv/bin:$PATH

COPY --from=builder /opt/venv /opt/venv
COPY . ./

CMD ["python", "-m", "python.main"]

python/main.py

import asyncio
import os

from redis.asyncio import Redis

REDIS_HOST = os.getenv("REDIS_HOST", "localhost")
REDIS_PORT = os.getenv("REDIS_PORT", "6379")
SRV_HOST = "0.0.0.0"
SRV_PORT = 8080

def handler(redis: Redis):
    async def fn(_: asyncio.StreamReader, w: asyncio.StreamWriter):
        try:
            await redis.ping()
            response = (
                f"HTTP/1.1 200 OK\r\n"
                f"Content-Type: text/plain\r\n"
                f"Content-Length: 0\r\n"
                f"\r\n"
                f""
            )

            w.write(response.encode())
            await w.drain()
        finally:
            w.close()
            await w.wait_closed()

    return fn

async def main():
    redis = Redis(host=REDIS_HOST, port=int(REDIS_PORT))
    server = await asyncio.start_server(handler(redis), host=SRV_HOST, port=SRV_PORT)

    try:
        async with server:
            await server.serve_forever()
    finally:
        await redis.aclose()

if __name__ == "__main__":
    asyncio.run(main())

docker compose ps

NAME               IMAGE                  COMMAND                  SERVICE   CREATED       STATUS                 PORTS
example-python-1   example-python         "python -m python.ma…"   python    2 hours ago   Up 2 hours (healthy)
example-redis-1    valkey/valkey:latest   "docker-entrypoint.s…"   redis     2 hours ago   Up 2 hours (healthy)   127.0.0.1:6379->6379/tcp

Pros

It works. It's simple, supports health checks, and has restart policies.

Cons

Compose is not part of the system, has poor integration with systemd and journald. Broad permissions, a rootful daemon, and a continuous CPU/RAM tax.

Health checks are mostly informational and don't automatically trigger restarts.

It's a fine baseline for a single VPS.

K3s

A few words from the official sites:

What is K3s? Lightweight Kubernetes.

Easy to install, half the memory, all in a binary of less than 100 MB.

Setup is curl -sfL https://get.k3s.io | sh -. I already like it: run as root, trust me 😈

Cluster overview

root@qemu:/home/user# systemctl status k3s
● k3s.service - Lightweight Kubernetes
     Loaded: loaded (/etc/systemd/system/k3s.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-12-19 14:57:54 UTC; 4min 49s ago
       Docs: https://k3s.io
    Process: 1140 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
    Process: 1141 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
   Main PID: 1143 (k3s-server)
      Tasks: 90
     Memory: 1.4G (peak: 1.5G)
        CPU: 35.823s
     CGroup: /system.slice/k3s.service
             ├─1143 "/usr/local/bin/k3s server"
             ├─1168 "containerd "
             ├─1732 /var/lib/rancher/k3s/data/7b97d417878d140a607ac677a82c2562e863279de825743bbdb137cff0b48877/bin/containerd-shim-runc-v2 -namespace k8s.io -id ba799f11f2b2d99b2a153257380ff9755>
             ├─1766 /var/lib/rancher/k3s/data/7b97d417878d140a607ac677a82c2562e863279de825743bbdb137cff0b48877/bin/containerd-shim-runc-v2 -namespace k8s.io -id ff37d03c651fc8d57defe3d5493195fdd>
             ├─1777 /var/lib/rancher/k3s/data/7b97d417878d140a607ac677a82c2562e863279de825743bbdb137cff0b48877/bin/containerd-shim-runc-v2 -namespace k8s.io -id a2b64c80ff6b0546113338e4426c31ccb>
             ├─2773 /var/lib/rancher/k3s/data/7b97d417878d140a607ac677a82c2562e863279de825743bbdb137cff0b48877/bin/containerd-shim-runc-v2 -namespace k8s.io -id a0538126449c9c4ff76f05aec8f2da487>
             └─2862 /var/lib/rancher/k3s/data/7b97d417878d140a607ac677a82c2562e863279de825743bbdb137cff0b48877/bin/containerd-shim-runc-v2 -namespace k8s.io -id 5be4562c4eb8e79d0f8282ed74eb04b76>

Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845233    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="tlsoptions.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845249    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="apiportalauths.hub.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845267    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="apiportals.hub.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845284    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="middlewaretcps.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845297    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="ingressrouteudps.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845313    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="apiplans.hub.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845329    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="apiratelimits.hub.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845341    1143 resource_quota_monitor.go:227] "QuotaMonitor created object count evaluator" resource="serverstransporttcps.traefik.io"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845489    1143 shared_informer.go:350] "Waiting for caches to sync" controller="resource quota"
Dec 19 14:58:59 qemu k3s[1143]: I1219 14:58:59.845520    1143 shared_informer.go:357] "Caches are synced" controller="resource quota"

root@qemu:/home/user# sudo kubectl get all -n kube-system
NAME                                          READY   STATUS      RESTARTS   AGE
pod/coredns-6d668d687-6lhpl                   1/1     Running     0          4m48s
pod/helm-install-traefik-crd-rsd4s            0/1     Completed   0          4m48s
pod/helm-install-traefik-ttdrr                0/1     Completed   1          4m48s
pod/local-path-provisioner-869c44bfbd-k6ct2   1/1     Running     0          4m48s
pod/metrics-server-7bfffcd44-4xtb7            1/1     Running     0          4m48s
pod/svclb-traefik-091968ea-wb98r              2/2     Running     0          4m17s
pod/traefik-865bd56545-b5qkm                  1/1     Running     0          4m17s

NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
service/kube-dns         ClusterIP      10.43.0.10     <none>        53/UDP,53/TCP,9153/TCP       4m51s
service/metrics-server   ClusterIP      10.43.249.39   <none>        443/TCP                      4m51s
service/traefik          LoadBalancer   10.43.154.80   10.0.2.15     80:30206/TCP,443:31853/TCP   4m17s

NAME                                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/svclb-traefik-091968ea   1         1         1       1            1           <none>          4m17s

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/coredns                  1/1     1            1           4m51s
deployment.apps/local-path-provisioner   1/1     1            1           4m51s
deployment.apps/metrics-server           1/1     1            1           4m51s
deployment.apps/traefik                  1/1     1            1           4m17s

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/coredns-6d668d687                   1         1         1       4m48s
replicaset.apps/local-path-provisioner-869c44bfbd   1         1         1       4m48s
replicaset.apps/metrics-server-7bfffcd44            1         1         1       4m48s
replicaset.apps/traefik-865bd56545                  1         1         1       4m17s

NAME                                 STATUS     COMPLETIONS   DURATION   AGE
job.batch/helm-install-traefik       Complete   1/1           34s        4m51s
job.batch/helm-install-traefik-crd   Complete   1/1           33s        4m51s

K3s deployment manifests

Here's the same Valkey & Python app with the same Dockerfile. Let's deploy it. Helm isn't included by default, so I'll use raw YAML manifests.

namespace.yaml

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: Namespace
metadata:
  name: selfhosted
YAML

deployment-valkey.yaml

kubectl apply -f - <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: selfhosted
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        - name: redis
          image: valkey/valkey:latest
          args: ["valkey-server", "--port", "6379"]
          ports:
            - containerPort: 6379
          readinessProbe:
            exec:
              command: ["sh", "-c", "valkey-cli ping | grep -q PONG"]
            initialDelaySeconds: 2
            periodSeconds: 5
            timeoutSeconds: 3
            failureThreshold: 3
          livenessProbe:
            exec:
              command: ["sh", "-c", "valkey-cli ping | grep -q PONG"]
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 3
            failureThreshold: 5
YAML

service-valkey.yaml

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: selfhosted
spec:
  selector:
    app: redis
  ports:
    - name: redis
      port: 6379
      targetPort: 6379
  type: ClusterIP
YAML

deployment-python.yaml

kubectl apply -f - <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: python
  namespace: selfhosted
spec:
  replicas: 1
  selector:
    matchLabels:
      app: python
  template:
    metadata:
      labels:
        app: python
    spec:
      containers:
        - name: python
          image: localhost/local/python-app:dev
          imagePullPolicy: IfNotPresent
          env:
            - name: REDIS_HOST
              value: redis
            - name: REDIS_PORT
              value: "6379"
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 2
            periodSeconds: 5
            timeoutSeconds: 3
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 3
            failureThreshold: 5
YAML

service-python.yaml

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: Service
metadata:
  name: python
  namespace: selfhosted
spec:
  selector:
    app: python
  ports:
    - name: http
      port: 8080
      targetPort: 8080
  type: ClusterIP
YAML

ingress.yaml

kubectl apply -f - <<'YAML'
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: python
  namespace: selfhosted
spec:
  rules:
    - host: python.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: python
                port:
                  number: 8080
YAML

additional trick to bring docker image into ctr

podman build -f Dockerfile.python -t local/python-app:dev .
podman save --format docker-archive local/python-app:dev | sudo k3s ctr images import -

All of this recreates what Docker Compose already gives me:

kubectl -n selfhosted get pods -o wide
NAME                      READY   STATUS    RESTARTS   AGE     IP           NODE   NOMINATED NODE   READINESS GATES
python-59b66ccf6b-xwng2   1/1     Running   0          3m51s   10.42.0.12   qemu   <none>           <none>
redis-68764c78c5-xjplm    1/1     Running   0          30m     10.42.0.9    qemu   <none>           <none>

On a single VPS.

K3s verdict: full cluster tax

Pros: it provides /usr/local/bin/k3s-uninstall.sh.

Jokes aside: on the one hand it gives me the full Kubernetes experience, even with built-in ingress controller, so I could reuse existing manifests for a full-fledged cluster and scale things up (no, but belief helps, see non-clusterized deployment-valkey.yaml).

On the other hand, I pay high operational costs and high CPU/RAM overhead. Will I ever recoup that investment?

Podman + Quadlet

The dark horse. I'd never heard of it before I started writing this article, but it looks the most promising.

First, Podman is an engine that runs containers without a permanent privileged daemon. It uses OCI runtimes, is rootless by design, and stays Docker-compatible enough for this use.

Second, Quadlet generates systemd units, so containers integrate cleanly with systemd and journald.

Quadlet deployment units

Podman itself already exists in Ubuntu repos (no need to add Docker's signing key and repo).

as root: sudo apt update && sudo apt install podman
as regular user: podman build -f Dockerfile.python -t local/python-app:dev . (without Docker's required manual group/permission management; images differ from one user to another)
mkdir -p ~/.config/containers/systemd
podman network create selfhosted (strange, but the default Podman network has DNS disabled)

Preparation done. Add the units.

~/.config/containers/systemd/redis.container

[Unit]
Description=Valkey (redis)
Wants=network-online.target
After=network-online.target

[Container]
Image=docker.io/valkey/valkey:latest
Network=selfhosted
Exec=valkey-server --port 6379
PublishPort=127.0.0.1:6379:6379

HealthCmd=valkey-cli ping
HealthInterval=5s
HealthTimeout=3s
HealthRetries=5

[Service]
Restart=always
RestartSec=3
# MemoryMax=768M
# MemorySwapMax=768M
# CPUQuota=85%
# TasksMax=128

[Install]
WantedBy=default.target

~/.config/containers/systemd/python.container

[Unit]
Description=Python app
Wants=redis.service
After=redis.service

[Container]
Image=localhost/local/python-app:dev
Network=selfhosted
Environment=REDIS_HOST=systemd-redis
PublishPort=127.0.0.1:8080:8080

HealthCmd=python -c "import http.client,sys; c=http.client.HTTPConnection('127.0.0.1',8080,timeout=2); c.request('GET','/healthz'); r=c.getresponse(); sys.exit(0 if r.status==200 else 1)"
HealthInterval=5s
HealthTimeout=3s
HealthRetries=5

[Service]
Restart=always
RestartSec=3
# MemoryMax=768M
# MemorySwapMax=768M
# CPUQuota=85%
# TasksMax=128

[Install]
WantedBy=default.target

Validate configs by /usr/libexec/podman/quadlet --user --dryrun. If it looks good, run systemctl --user daemon-reload.

systemctl --user status redis python --no-pager

● redis.service - Valkey (redis)
     Loaded: loaded (/home/user/.config/containers/systemd/redis.container; generated)
     Active: active (running) since Sat 2025-12-20 13:32:38 UTC; 8min ago
   Main PID: 85139 (conmon)
      Tasks: 21 (limit: 9370)
     Memory: 8.6M (peak: 20.0M)
        CPU: 2.047s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/redis.service
             ├─libpod-payload-e8c29da1a2f6c4bb032304f7dfbc5a767e026092c4a2fcbc830e58565f972f54
             │ └─85141 "valkey-server *:6379"
             └─runtime
               ├─85124 rootlessport
               ├─85130 rootlessport-child
               └─85139 /usr/bin/conmon --api-version 1 -c e8c29da1a2f6c4bb032304f7dfbc5a767e026092c4a2fcbc830e58565f972f54 -u e8c29da1a2f6c4bb032304f7dfbc5a767e026092c4a2fcbc830e58565f972f54 -r …

Dec 20 13:32:38 qemu podman[85050]: 2025-12-20 13:32:38.398858374 +0000 UTC m=+0.013421623 image pull d422224bf6e2d405c51aa2fa092855478543f21872a9b1a8125d184095f5aa25 docker.io/v…ey/valkey:latest
Dec 20 13:32:38 qemu systemd-redis[85139]: 1:M 20 Dec 2025 13:32:38.497 * oO0OoO0OoO0Oo Valkey is starting oO0OoO0OoO0Oo
Dec 20 13:32:38 qemu systemd-redis[85139]: 1:M 20 Dec 2025 13:32:38.497 * Valkey version=9.0.1, bits=64, commit=00000000, modified=0, pid=1, just started
Dec 20 13:32:38 qemu systemd-redis[85139]: 1:M 20 Dec 2025 13:32:38.497 * Configuration loaded
Dec 20 13:32:38 qemu podman[85050]: 2025-12-20 13:32:38.496286417 +0000 UTC m=+0.110849666 container start e8c29da1a2f6c4bb032304f7dfbc5a767e026092c4a2fcbc830e58565f972f54 (image…T=redis.service)
Dec 20 13:32:38 qemu systemd-redis[85139]: 1:M 20 Dec 2025 13:32:38.497 * monotonic clock: POSIX clock_gettime
Dec 20 13:32:38 qemu systemd-redis[85139]: 1:M 20 Dec 2025 13:32:38.497 * Running mode=standalone, port=6379.
Dec 20 13:32:38 qemu systemd-redis[85139]: 1:M 20 Dec 2025 13:32:38.498 * Server initialized
Dec 20 13:32:38 qemu systemd-redis[85139]: 1:M 20 Dec 2025 13:32:38.498 * Ready to accept connections tcp
Dec 20 13:32:38 qemu redis[85050]: e8c29da1a2f6c4bb032304f7dfbc5a767e026092c4a2fcbc830e58565f972f54

● python.service - Python app
     Loaded: loaded (/home/user/.config/containers/systemd/python.container; generated)
     Active: active (running) since Sat 2025-12-20 13:32:38 UTC; 8min ago
   Main PID: 85244 (conmon)
      Tasks: 16 (limit: 9370)
     Memory: 38.3M (peak: 46.6M)
        CPU: 2.721s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/python.service
             ├─libpod-payload-8a390a010658563033af8b8e7be8c0984e03eb109eee54fdf2e7a7688ee7ca90
             │ └─85246 python -m python.main
             └─runtime
               ├─85218 rootlessport
               ├─85232 rootlessport-child
               └─85244 /usr/bin/conmon --api-version 1 -c 8a390a010658563033af8b8e7be8c0984e03eb109eee54fdf2e7a7688ee7ca90 -u 8a390a010658563033af8b8e7be8c0984e03eb109eee54fdf2e7a7688ee7ca90 -r …

Dec 20 13:32:38 qemu systemd[782]: Starting python.service - Python app container (rootless)...
Dec 20 13:32:38 qemu podman[85146]: 2025-12-20 13:32:38.516813999 +0000 UTC m=+0.021024836 container create 8a390a010658563033af8b8e7be8c0984e03eb109eee54fdf2e7a7688ee7ca90 (imag…=python.service)
Dec 20 13:32:38 qemu podman[85146]: 2025-12-20 13:32:38.568795185 +0000 UTC m=+0.073006064 container init 8a390a010658563033af8b8e7be8c0984e03eb109eee54fdf2e7a7688ee7ca90 (image=….version=1.33.7)
Dec 20 13:32:38 qemu systemd[782]: Started python.service - Python app container (rootless).
Dec 20 13:32:38 qemu podman[85146]: 2025-12-20 13:32:38.583186772 +0000 UTC m=+0.087397609 container start 8a390a010658563033af8b8e7be8c0984e03eb109eee54fdf2e7a7688ee7ca90 (image….version=1.33.7)
Dec 20 13:32:38 qemu python[85146]: 8a390a010658563033af8b8e7be8c0984e03eb109eee54fdf2e7a7688ee7ca90
Dec 20 13:32:38 qemu podman[85146]: 2025-12-20 13:32:38.508078113 +0000 UTC m=+0.012288991 image pull 5ab432c25a0bea88ed2ac7b636a0a44eeff6e5cb44c03f63e275ac736475c4eb localhost/l…l/python-app:dev
Hint: Some lines were ellipsized, use -l to show in full.

The result: container isolation without the overhead and complexity. It runs as a regular user. Updates are predictable via systemctl --user restart python.service. Health checks restart the service, and logs rotate out of the box.

Verdict: Podman + Quadlet wins on a 1GB VPS

Metric	Docker Compose	K3s	Podman + Quadlet
Idle RAM (Engine)	~181MB	~1.4GB	~0MB (daemonless)
Orchestrator	Docker daemon	"Control plane"©	systemd
Permissions	Rootful (default)	Rootful	Rootless (default)
Observability	docker logs	kubectl logs	journalctl
LoC	34	124	34

I started on the Docker Compose side, mostly intending to joke about Kubernetes being dragged into everything. Instead, I ended up replacing Docker with Podman + Quadlet on my VPS in the name of simplicity!

I intentionally omitted persistent volumes, because it would make the comparison (especially K3s vs Quadlet) unfair in terms of operational cost.

The surprise: everything worked fine on arm64 (macOS → qemu-system-aarch64 → ubuntu-24.04.3-live-server-arm64).

Rotten specs

Ivan — Thu, 08 Oct 2026 04:54:12 +0000

Say spec-driven development out loud and someone answers "spec rot". OpenSpec, spec-kit and BMAD earned that answer; every one of them builds a knowledge base I never asked for.

But I run SDD without rotten specs. The fix: stop building a knowledge base on top of it.

SDD is two steps: write the spec, then build from it. Both steps run against a context budget, because the 1M window is still a marketing number.

Two steps don't need a local issue tracker

OpenSpec gave me openspec/specs/, then openspec/changes/<name>/ with proposal.md, design.md, tasks.md and a nested specs/<capability>/spec.md, then openspec/changes/archive/2025-01-23-<name>/.

Matt Pocock's skills sell the opposite. Marketed as "small, easy to adapt, and composable", a shot at GSD, BMAD and Spec-Kit for "owning the process". Then /setup-matt-pocock-skills writes docs/agents/issue-tracker.md and a triage label vocabulary, /domain-modeling maintains a root CONTEXT.md plus docs/adr/0001-*.md, /to-spec publishes .scratch/<feature>/spec.md, /to-tickets fills .scratch/<feature>/issues/01-*.md, and /wayfinder lays a map.md over the pile. Smaller units that build the same knowledge base.

The rest repeat the shape. A constitution, a spec, a plan and a task list per feature, a memlog. Scott Logic ran spec-kit on one feature and counted 2,577 lines of generated markdown against 689 lines of code, plus 3.5 hours of review¹. I read that once. The agent reads it every session, long after the code moved on.

Nobody owns the memory

Before writing this I deleted about 250MB from ~/.claude. Memories, plans, task lists, session leftovers, backups, security logs. Nothing broke. Nothing noticed.

Count the layers that claimed to remember something for me:

the harness: projects/<slug>/memory/MEMORY.md and its per-type files, plans/, sessions/, history.jsonl, backups/
- global and per project
the SDD framework. Constitution, spec, plan, task list, CONTEXT.md, ADRs, archive
rotten AI-written comments in code, describing the shape before the last refactor
mine, and the only ones I edit: AGENTS.md, README.md, my tests, my openapi.yaml
somebody's Jira/Monday/Confluence MCP servers
- plus the default expectation that gh is installed and GitHub Issues is where I track work

A lot of places, a lot of writers. Zero owners. One deleter: me.

Where to put a { is a make fmt question. Nobody needs to search three trackers, two memory stores and an ADR to answer it.

So, just stop mixing the jobs. One tool, one job is old advice and it holds here.

My SDD adds no files to the repo

I run Pi now. Zero bloatware, zero opinions I didn't add myself. My global AGENTS.md is 9 lines: six invariants, two headers and one environment note. Next to it, three skills I wrote².

Research only reads. It splits a question into angles, sends read-only sub-agents at the independent ones, returns cited findings and writes nothing. Transfer writes one owner-only Markdown handoff into the temp directory, secrets redacted, then stops. The handoff carries whatever the session produced: findings, or the spec. Apply takes that handoff, checks its claims against the current repo, makes the smallest change and runs the repo's own checks. Durable guidance goes into the instruction files I already keep. No intermediate artifacts land in the repo.

Past 100+k tokens in a session I do Transfer and restart from the handoff. Same move once the spec is ready: hand off, drop the model a tier (Opus to Sonnet, Sol to Terra), then Apply. The spec crosses one boundary and dies there.

Even sessions I don't want to keep at all: export PI_CODING_AGENT_SESSION_DIR=${TMPDIR%/}/pi-sessions.

Conclusion

Stop arguing with a pointless "grilling" session about marketing strategy while trying to ship a local POC.

While models earn more intelligence, your codebase is still the source of truth. The agent gets a new version every hour. The repo is the one worth investing in.

The software development cycle has been here for decades. LLM marketing tries to bury it. Rotten specs are the punishment for blind faith in the Machine God.

Scott Logic, "Putting Spec Kit through its paces: radical idea or reinvented waterfall?", 2025-11-26. 2,577 lines of markdown, 689 loc, 3.5 hrs review against 1,000 loc, no markdown, 15 min review. https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html ↩
Not ideal. Three files, my taste, my harness. If you can do it better, don't hesitate: open a PR. ↩

Null hypothesis: AI code differs

Ivan — Thu, 08 Oct 2026 04:50:29 +0000

I spot AI code in PRs to repos I know. Usually it means nothing. Sometimes it annoys me. Like recognizing a colleague’s style. But a colleague learns; an agent needs an external gate saying "don't do it this way".

If something exists, I could measure it

I wanted a reproducible signature to work with. Started from the observation I already had: AI code looks overengineered to me. The plan was to compute target metrics over time/commits and watch the curve bend around agent adoption.

I tried cyclomatic complexity, cognitive complexity, max nesting, conditions per entity, and call stack depth.

The first snag was size. Complexity tracked SLOC almost one to one. So I normalized everything on SLOC and kept looking.

Then added methods and functions per entity, entities per API method, entities per package, dependency count, edges in the dependency graph, and error handling density. About 280 metrics in all with their pairwise correlations.

I found no anomalies outside statistical error. Same for public repos and my private ones.

The explanation I couldn't shake

As per my understanding, a model emits roughly the mean of its training distribution, while each human deviates from that mean. The means land on top of each other, and the statistic goes quiet.

If that's what happened, comparing AI with human code hides the signal. I would need to compare it with one specific person instead, but I don't have enough single-author code to run that test.

The public papers

The process did one useful thing: it taught me the proper questions, and those led me to people who had already run the measurements.

These papers do find differences:

raw AI-involved code is "more comment-heavy, less cross-file reused, ..."
- these differences disappear in real-world repos (my guess: AGENTS.md customizations, linters and formatters, plus review)
The stronger signal: AI-involved commits are smaller and more localized.
- which I didn't measure and don't care about

The papers also add an angle I missed: vendors differ from each other. Which literally means there is no common signature.

Open niche: no one tests a single vendor against different AGENTS.md files and related tunings. My bet: another layer of tuning splits the signature again.

Conclusion

No general signature. Curiosity satisfied.

Referring to my original annoyance, looks like there is only one way to handle it automatically: write dedicated static checkers to prevent specific patterns.

Security you can't justify is a vicious cycle

Ivan — Thu, 08 Oct 2026 04:47:02 +0000

I've already written about compliance security. Here is the adversarial round.

Dependabot continuously DDoSes me with a wall of pull requests. npm audit always paints X high-severity vulnerabilities. And a devops engineer, now and then, starts arguing that our microservices, inside one locked-down AWS VPC, should really talk over TLS.

Different mouths, one noise: add more security, now. Not one of them showed me an attacker. Not one showed me the threat.

That's the tell. A vulnerability is worth acting on when you can show the code that exploits it. The red banner, the CVSS score, the "we should really" line: all claims. Mostly marketing. Security you can't justify becomes theater. Then it becomes a vicious cycle.

Talk is cheap. Show me the code.¹

A working proof of concept is proof. A severity score is a claim. A scanner label is a claim. Someone's opinion is a claim. Claims are cheap. You can generate a thousand a day, no code required. The PoC is the tax that separates the real from the loud.

Watch a claim meet the tax. A hyped model scanned curl and reported five confirmed vulnerabilities; after the security team looked, one was real.² The label said confirmed. The code said otherwise.

Never update dependencies unless it breaks for your users.³

Brainlessly following automated-tool guidance is a security risk. Brainlessly adding a dependency to your code or infra is a security risk.

Supply chain: attackers force-pushed malicious commits to 75 of 76 tags of the official Trivy Action and turned it into a credential stealer.⁴ That proof never came from the red banner.

Conclusion

None of this is anti-tooling. I keep the scanner and the model. The failure is treating a claim as a verdict: bad tool UI, plus blind obedience to decade-old compliance checklists.

So I've started to understand the projects that refuse AI contributions.

Linus Torvalds, linux-kernel mailing list, 25 August 2000. http://lkml.org/lkml/2000/8/25/132 ↩
Daniel Stenberg, "Mythos finds a curl vulnerability", daniel.haxx.se, 2026-05-11. https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/ ↩
Mitchell Hashimoto: "Fork your dependencies, trim them to only your use case, never update unless it breaks for your users." https://x.com/mitchellh/status/2057171518027887035. ↩
Stephen Thoemmes, "Trivy GitHub Actions Supply Chain Compromise", Snyk. https://snyk.io/articles/trivy-github-actions-supply-chain-compromise/ ↩

Runtime cost matters to me now

Ivan — Sun, 04 Oct 2026 20:13:15 +0000

AI made me reopen a boring question: why am I still paying Fargate rent for V8?

Bun's Zig-to-Rust AI rewrite got me running the math. 6 days, 960'000 lines, 99.8% of Bun's existing tests passing, 9 days to merge ($10'000 total AI spent?)¹.

What does that look like for 15'844 LOC of my own microservice on Fargate?

My setup

Node.js microservice, talks to MongoDB, calls a few neighbors, responds to others, does its small thing. A typical service sits at 0.5 vCPU / 1 GB RAM: $18/month per task. Three replicas minimum for robustness, so $54/month per service.

Most of that bill is provisioned runtime headroom. Node makes that headroom harder to shrink. V8, dynamic dispatch, garbage collection, startup time, memory spikes. The runtime pays rent on Fargate while I'm paying for it.

One rewrite, run the math

Say $100 in Claude Code tokens to produce a first port to Go or Rust. Not to ship it blindly. Review, tests, and rollout still cost human time. But the first draft is no longer the expensive part.

Fargate bills $0.04048 per vCPU-hour and $0.004445 per GB-hour². Minimum task size: 0.25 vCPU / 0.5 GB, about $9/month. A compiled service with a Mongo driver and a couple of HTTP clients belongs at that floor. No V8. No managed runtime heap sitting around waiting for traffic.

New bill for that service: 3 x $9 = $27/month; 2x savings.

Payback on $100 of AI: under four months; for one service in minimal setup.

That is the toy version. My real setup has dev, prod, workload replicas, autotests, and the usual operational mess. Around ten replicas. Payback lands near one month.

The cluster framing

The language map changes:

Rust / C / C++: smallest runtime footprint. Highest migration friction. Ecosystem question still open for my services.
Go: small runtime tax. Boring deployment, strong backend ecosystem. Looks like the new default from the cost side.³
Node / Python / PHP / Java / C#: still productive defaults, but their runtime footprint is no longer free. Fargate turns it into a line item.

The runtime tax used to hide inside developer productivity. AI lowers the cost of moving code. Cloud exposes the cost of keeping code running. That makes runtime choice visible again.

Plan B

Or move off AWS to Hetzner and cut the bill by ~10x.

https://www.theregister.com/2026/05/14/anthropics_bun_rust_rewrite_merged_at_speed_of_ai/5240381 ↩
https://aws.amazon.com/fargate/pricing/ ↩
I’ve personally never been a Rust fan. Go, though, I’ve used for heavily loaded things. C/C++ lives somewhere in old education. ↩

AI agent architecture: model, harness and intent

Ivan — Sat, 03 Oct 2026 23:31:16 +0000

My VPS runs a "personal AI agent". It forgets its own abilities every morning.

My terminal runs a coding agent. It ships production work.

Same year. Frontier models on both. Same ecosystem.

Both are model + harness, trying to handle the same thing: my intent. Why such a
different experience? Start with the thing everyone mixes up: definitions.

What is an AI agent?

Anthropic: the company. Founded by ex-OpenAI researchers. Usual story.
Claude: the model family. When someone says "ask Claude," they usually mean a single call to whichever model through a chatbot. Competes with GPT (OpenAI) and Gemini (Google).
Opus / Sonnet / Haiku: model tiers. Opus = most capable, Haiku = fastest / cheapest.
Agentic approach / Agentic AI¹: reason → act → observe → repeat, the loop itself; the loop is what makes something agentic.
Agent: model wrapped in a harness, spins in a loop. Reads context, plans, acts, verifies, repeats. Distinct from a chatbot by execution pattern: a chat interface can front an agent; a one-shot call cannot.
- Sub-Agent: execution thread inside an agent. Inherits base settings, extends them.
Agent harness²: everything in an AI agent except the model itself. Tools, memory, workflow (the loop, plan/build sub-agents), guardrails (permissions, sandbox).
MCP server: tool through which the agent interacts with the outer world. Web, DBs, clouds, apps.
Skill: goal-aimed prompt plus optional scripts, packaged capability.
RAG: memory, agent stores custom data and pulls relevant chunks into context.
AGENTS.md / CLAUDE.md / SOUL.md: custom instructions loaded into the context.
Context: text the agent handles at once. User input, custom instructions, tool outputs, RAG-retrieved chunks. Bounded by the model's context length.

Providers are wrapping yesterday's chats in agent loops. Execution pattern
flips, the chat UI stays. Same split still holds: model caps capability, harness
wires integrations and workflow, and intent has to be decomposed into pieces the
agent can handle. Who does the decomposition is the next question.

AI platforms and architectures

First, split common LLM application architectures by workflow: the execution
pattern around model calls.

At tiers 0-3 this is mostly application code. Fixed calls, branching, one-off
tool use. At tiers 4-5 it becomes an agent harness. Loop, state, permissions,
memory, orchestration.

Six tiers, in order of escalating cost/complexity:

Tier	Pattern	When	Cost shape
0	Single prompt	Text in, text out	1 LLM call
1	Prompt chain	Multi-step but predictable pipeline	N LLM calls
2	Routing	Input-type dispatch into one of K branches	Router call + selected branch
3	Tool-use, single round	Need external data, one tool round suffices	Tool schema tokens + tool call + synthesis
4	Agent, ReAct loop	Iterative, unknown depth, state-dependent	Unbounded: loop iterations × model/tool calls
5	Multi-agent / orchestrator	Long-horizon, decomposable, large context	Orchestrator + workers + replans + synthesis

This post is about tiers 4 and 5. Agent loops, orchestrators, and who owns
intent decomposition.

Three families compete for "AI agent" today. Same lens for each: who owns intent
decomposition? The specialized harness, the personal assistant, or me.

Specialized AI agents

AI trading agent
AI legal assistant
Customer service bot
AI for medical diagnosis

Same product shape. Narrow task, fixed workflow, integrations hidden behind the
UI.

Perplexity is the research/search version of that shape.

Research the latest evidence and debate around emergent agency in AI systems
in 2025-2026.

Searching the web

... some sources ...

Searching recent academic and policy sources on emergent agency in AI systems

Retrieving recent reports and policy documents on AI agent behavior and emergent agency

Fine results, at least looks relevant.

what's the model you using?

I'm Perplexity, powered by Grok 4.1. Perplexity's default model is a
custom-optimized version called Sonar, built on Llama 3.1 or later
iterations like Llama 3.3 70B, fine-tuned for fast web search,
summarization, and efficiency. It's available to both free and Pro users for
quick, relevant results. Pro subscribers can switch to advanced options like
GPT-5.2 or Claude models via the model selector.

Fail. It understood the surface intent (answer a product-stack question), but
the product owned routing and context. I had no way to inspect which model
routed the answer, which metadata it saw, or why it mixed Grok, Sonar, and Llama
into one pile.

The outcome: specialized harness frames intent into its fixed shape. When that
frame fits, I get a clean research answer. When the frame itself is wrong, I get
confident product salad and no useful control surface.

Personal assistant

Tried OpenClaw first. It wants 2+ CPUs and 8+ GB RAM; my VPS has 1 and 1. Ran
it anyway. It choked the VPS. Dropped it for Hermes.

Rarely discussed, but experimental software with a lot of external integrations
has too broad an attack surface, see https://days-since-openclaw-cve.com. Keep
it in mind.

Hermes, an agent that grows with you

Strange that Nous Research doesn't mention they have a Docker image,
docker.io/nousresearch/hermes-agent, which I've successfully set up in
podman.

/etc/containers/systemd/hermes-agent.container

[Unit]
Description=Hermes Agent
Wants=network-online.target
After=network-online.target

[Container]
Image=docker.io/nousresearch/hermes-agent:latest
ContainerName=hermes-agent
Network=selfhosted
Volume=/root/hermes:/opt/data
Volume=/root/hermes-root:/root
Volume=/tmp/hermes:/tmp
Ulimit=nofile=1024:1024

Environment=VIRTUAL_ENV=/root/.venv
Environment=PYTHONPATH=/root/.venv/lib/python3.13/site-packages

Exec=gateway run

[Service]
Restart=always
RestartSec=3
MemoryMax=768M
MemorySwapMax=768M
CPUQuota=85%
TasksMax=128

[Install]
WantedBy=multi-user.target

And it runs completely fine on a 1 CPU / 1 GB VPS.

CPU/RAM consumption

I connected it to my GPT subscription, added integrations for X, Google
Calendar, Notion, and this blog's RSS, plus free Mem0 as RAG.

It even worked right after setup, but the next day it forgot about the
integration. I had to persuade it to try again.

OAuth failed in a different way. During Google Calendar integration I issued
credentials only for read/write on the calendar, not broader Google scopes. The
builtin Google skill wants broader access, so the agent re-requests broader
scopes every time it touches the calendar, and eventually the auth flow breaks
again.

One more case: I configured a scheduled job to check, each morning at 9:00, my
Notion calendar, Google Calendar, event listings, and send me a summary for
today and tomorrow. How often does it work right? Almost never. It checks only
one calendar, sends events for the next ~6 months instead of 2 days, sends
events for the current month but from this and previous years, and so on.

Current state: the initial GPT auth token has expired, and the agent can't renew
it automatically. Well... experiment successful.

Each failure is easy to fix manually. Cron, small script, explicit OAuth scopes,
date windows, deterministic calendar queries. But that is exactly the point: the
general assistant is supposed to replace the glue. Here it doesn't. The failure
is not the model. The harness decomposes intent badly, and the UI doesn't expose
decomposition early enough to fix it.³

CLI coding agents

Terminal-native, actively evolving. Everything in my hands. Only vendor ToS can
limit me.

OpenCode, the open source AI coding agent

My favorite one. Open source, standard ~/.config/opencode path, strong
build/plan sub-agent architecture. Also ships opencode web, same engine,
browser UI.

~/.config/opencode/opencode.jsonc

{
  "$schema": "https://opencode.ai/config.json",
  "autoupdate": false,
  "default_agent": "plan",
  "share": "disabled",
  "snapshot": false,
  "instructions": ["/Users/ivan/.config/opencode/AGENTS.md"],
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "{env:CONTEXT7_API_KEY}"
      },
      "enabled": true
    },
    "playwright": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@playwright/mcp@latest",
        "--browser=chromium",
        "--executable-path=/Applications/Chromium.app/Contents/MacOS/Chromium",
        "--caps=vision,devtools"
      ],
      "environment": {
        "PLAYWRIGHT_BROWSERS_PATH": "{env:HOME}/.cache/ms-playwright"
      },
      "enabled": true
    }
  },
  "experimental": {
    "openTelemetry": false
  },
  "server": {
    "mdns": false
  },
  "plugin": []
}

Current AI-bro consensus: "Context is the key". I agree. Context engineering
pwnd prompt engineering.

Even more, after
Gloaguen et al., "Evaluating AGENTS.md" (Feb 2026),
generated agent context files hurt task success and add ~20% inference cost. I
stopped keeping per-repo CLAUDE.md / AGENTS.md files full of paths, framework
summaries, and obvious project descriptions. Current agents can inspect a repo
per case, fast and cheap enough. Put only what they cannot infer from code.
Constraints, preferences, dangerous commands, external contracts.

my global CLAUDE.md / AGENTS.md

# Invariants

Be brief

Truth over comfort

Simple over clever

Contradiction: name both sides, never average

Use subagents to do the work; main thread is orchestrator

grep -> rg; python -> python3

Still, the most reliable way to fix hallucinations is not to argue with the
agent but to drop the session and restart from scratch.

OpenCode's approach helps me clearly follow the principles above:

In plan mode I explain the goal and constraints, pointing to important files or docs as entry points;
The plan sub-agent collects requirements, explores the repo, clarifies intent, produces a plan⁴;
I review the plan; if decomposition is wrong, GOTO 1;
The approved plan is handed to the build sub-agent, which implements it⁵;
GOTO 1.

In plan mode, the harness exposes decomposition before execution. At that point,
the limit is me: how clearly I can split intent into steps.

This resembles the Plan-Then-Execute pattern⁶.

Claude Code

I migrated Claude work to Claude Code after Anthropic restricted third-party
Claude access to API credits⁷; OpenCode still runs my GPT subscription.

Proprietary, vendor-locked, but I can't complain that it misses anything
important.

~/.claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "cleanupPeriodDays": 1,
  "env": {
    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1",
    "CLAUDE_CODE_DISABLE_TERMINAL_TITLE": "1",
    "DISABLE_AUTOUPDATER": "1",
    "DISABLE_BUG_COMMAND": "1",
    "DISABLE_COST_WARNINGS": "1",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_FEEDBACK_COMMAND": "1",
    "DISABLE_TELEMETRY": "1"
  },
  "permissions": {
    "allow": [
      "Bash(git log *)",
      "Bash(git diff *)",
      "Bash(git show *)",
      "Bash(git status)",
      "Bash(grep *)",
      "Bash(echo *)",
      "Bash(ls *)",
      "Bash(rg *)",
      "Bash(npm run *)",
      "Bash(npm test *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(docker push *)",
      "Bash(find * -delete)",
      "Bash(find * -exec rm*)",
      "Bash(git branch -D *)",
      "Bash(git checkout -- *)",
      "Bash(git clean -f*)",
      "Bash(git push *)",
      "Bash(git reset --hard*)",
      "Bash(nc *)",
      "Bash(rm -f *)",
      "Bash(rm -r *)",
      "Bash(rm -rf *)",
      "Bash(rsync *)",
      "Bash(scp *)",
      "Bash(ssh *)",
      "Bash(sudo *)",
      "Bash(wget *)",
      "Edit(./.env*)",
      "Edit(./.git/**)",
      "Edit(./secrets/**)",
      "Edit(~/.aws/**)",
      "Edit(~/.bashrc)",
      "Edit(~/.ssh/**)",
      "Edit(~/.zshrc)",
      "Read(*.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.aws/**)",
      "Read(~/.azure/**)",
      "Read(~/.config/gh/**)",
      "Read(~/.git-credentials)",
      "Read(~/.gnupg/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)",
      "Read(~/.ssh/**)"
    ],
    "defaultMode": "plan"
  },
  "model": "sonnet",
  "disableClaudeAiConnectors": true,
  "disableBundledSkills": true,
  "disableRemoteControl": true,
  "disableWorkflows": true,
  "disableArtifact": true,
  "enableAllProjectMcpServers": false,
  "includeCoAuthoredBy": false,
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["git"]
  },
  "effortLevel": "low",
  "awaySummaryEnabled": false,
  "autoUpdatesChannel": "stable",
  "autoMemoryEnabled": false,
  "disableAutoMode": "disable",
  "theme": "light",
  "editorMode": "normal",
  "preferredNotifChannel": "notifications_disabled",
  "autoCompactEnabled": false,
  "skipAutoPermissionPrompt": false
}

This config reaches the same control goal I like in OpenCode: decomposition
stays visible, writes stay gated, mode switching stays under my control:

"defaultMode": "plan": plan mode by default. Writes blocked, reads allowed, plan exposed as /plan
"disableAutoMode": "disable": no autonomous mode switching
"sandbox.enabled": true plus a permissions.deny list for rm -rf, git push, sudo, ~/.ssh/**, etc.
telemetry off: DISABLE_TELEMETRY=1, DISABLE_FEEDBACK_COMMAND=1, DISABLE_ERROR_REPORTING=1, awaySummaryEnabled: false

Current setup

Context7 MCP: provides actual library docs instead of the model's stale or hallucinated snippets.
Playwright MCP: browser control. Nothing else to add.⁸
~Caveman plugin: its selling point is "Saves tokens, preserve accuracy".~⁹
security-guidance@claude-plugins-official: blame the times

Each of these touches the harness only. Model stays the vendor's, intent stays
mine.

Intent is the failure point

Perplexity frames intent into its fixed shape. Hermes decomposes intent on its
own, without me. CLI plan mode keeps decomposition visible. I'm the bottleneck.

The loop is what makes something agentic, and the harness puts me inside or
outside of it.

Outside the loop: I wait for a solution that fits my intent's shape. When it doesn't, the agent won't say "no". It attempts the task anyway, drifts, and hands something back.
Inside the loop: I keep intent, decompose it and approve execution. The ceiling is whatever I can break into steps.

Same year. Same frontier models. Humans still hold the loop. That is the
autonomy that emerges today.¹⁰

Popularized by ReAct: Yao et al., ICLR 2023
(paper,
Google Research blog). ↩
See Birgitta Böckeler, "Harness engineering for coding agent users":
https://martinfowler.com/articles/harness-engineering.html. ↩
Personal assistants still look worth watching. I'll wait for the next
Hermes iteration. Notion's agent may become the boring alternative. ↩
Yes-yes, I know about openspec.dev, but the plan has to stay observable, not
5+ A4 neuro-generated pages of
raw text. ↩
To save some tokens I use stronger model for plan (Opus) and weaker for
build (Sonnet). ↩
https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns/#the-plan-then-execute-pattern
Caveat: the split is weaker here. Plan sub-agent still reads untrusted repo
while planning, so a malicious file can steer the plan. ↩
Anthropic
tightened terms. Subscription plans (including the corporate one I use) no
longer cover Claude access from third-party apps; third-party access now
requires per-usage API credits. ↩
CLI is more token effective than MCP,
https://github.com/microsoft/playwright-cli#playwright-cli-vs-playwright-mcp. ↩
Caveman vs "be brief",
https://www.maxtaylor.me/articles/i-benchmarked-caveman-against-two-words.
Agent tools move too fast; without a fresh benchmark after model or harness
updates, a third-party skill can quietly make results worse than the
baseline. Benchmark it continuously or keep it off. ↩
Agent autonomy
framed as emergent from model behavior, product design, and user oversight
strategy. ↩

DEV Community: Ivan

The actual state of self-hosting on a VPS

Docker Compose

Pros

Cons

K3s

K3s deployment manifests

K3s verdict: full cluster tax

Podman + Quadlet

Quadlet deployment units

Verdict: Podman + Quadlet wins on a 1GB VPS

Rotten specs

Two steps don't need a local issue tracker

Nobody owns the memory

My SDD adds no files to the repo

Conclusion

Null hypothesis: AI code differs

If something exists, I could measure it

The explanation I couldn't shake

The public papers

Conclusion

Security you can't justify is a vicious cycle

Talk is cheap. Show me the code.1

Never update dependencies unless it breaks for your users.3

Conclusion

Runtime cost matters to me now

My setup

One rewrite, run the math

The cluster framing

Plan B

AI agent architecture: model, harness and intent

What is an AI agent?

AI platforms and architectures

Specialized AI agents

Personal assistant

Hermes, an agent that grows with you

CLI coding agents

OpenCode, the open source AI coding agent

Claude Code

Current setup

Intent is the failure point

Talk is cheap. Show me the code.¹

Never update dependencies unless it breaks for your users.³