DEV Community: Nenad Mićić

I Built compartment to Sandbox AI Agents on Linux

Nenad Mićić — Thu, 02 Apr 2026 12:06:30 +0000

AI coding agents are useful, but in a corporate environment they are often too privileged by default.

They can read files, edit code, run commands, inherit environment variables, and talk to the network. I wanted a smaller trust boundary for tools like Claude Code and Codex CLI.

So I built compartment, a small Linux process isolation toolkit with:

compartment-user — rootless confinement using Landlock, seccomp, and no_new_privs
compartment-root — stronger namespace-based isolation when needed
one shared profile format
zero external dependencies

This is also a rebuild of an old idea. Back in 2003, I wrote shell-guard, a wrapper that intercepted shell execution and applied policy early. Modern Linux finally has the kernel primitives to do that idea properly.

I built compartment primarily for AI-agent sandboxing, but the same logic also applies to other semi-trusted local tools, including SSH.

Small tool. Explicit policy. Lower blast radius.

GitHub: github.com/nmicic/compartment
README: github.com/nmicic/compartment#readme

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

Nenad Mićić — Wed, 11 Mar 2026 09:42:27 +0000

**Update (March 17, 2026): Since publishing this post, the campaign found two first-kind CC18s with roots 106103983461039119546815109 (87 bits) and 214325014495971624590189129 (88 bits). A later prior-art review showed that first-kind CC18 had already been documented in John Armitage’s 2021 Oxford thesis via the smallest known example, so these are not the first known CC18s. They do, however, remain the largest listed first-kind CC18 entries on the current public Cunningham tables. The campaign has now finished because my available GPU compute time ran out. The original post below is left mostly unchanged as the March 11 baseline.

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

Nenad Mićić · LinkedIn · March 2026

What This Is

A visualization hobby project that turned into a high-throughput Cunningham chain search engine. More about HPC optimization and AI-assisted iteration than the math itself.

It started with mapping integers in a 2-adic geometry, noticing structured prime paths, recognizing Cunningham-chain recurrences, and then building a GPU/CPU pipeline to search for long chains.

Results

This project ultimately did reach its CC18 target, but not the more ambitious CC19 goal. It remained a compute-limited campaign.

As of March 2026, the public Cunningham chain tables at pzktupel.de list results under my name, Nenad Mićić, including:

new CC16 and CC17 entries
the largest listed first-kind CC16, CC17, and CC18 on the current public tables

The published data snapshot contains 929,574 roots in total, including 44 CC16 roots and 1 CC17. The main campaign was centered on the 89–91 bit range, and the release includes both the search code and derived analysis:

gap statistics and spacing distributions
immunization / residue summaries and immune-fingerprint distributions
p+1 breaker analysis
ghost chains — roots where prime links continue beyond the official chain break, tested to depth 20
closest CC-twins and CC-clusters (triplets, quadruplets, quintuplets)

I think this dataset is useful in its own right and deserves deeper study.

How It Works

Visual learning led to search design.

The 2-adic coordinate system made chain structure visible. The p+1 factorization view showed which small-factor patterns kill candidates early. That became the sieve.

For a first-kind chain, a root p generates: p, 2p+1, 4p+3, 8p+7, ...

The key optimization is depth filtering:

generate candidates on the CRT-and-wheel search lattice
test cheap modular conditions across the first d projected chain positions
reject any root whose chain is already doomed modulo a tracked small prime
send only the tiny survivor set to the CPU for probable-prime testing and full chain confirmation

Pipeline:

GPU (CUDA): 57–65 billion candidates/sec modular filtering (RTX 4090 / RTX 5090)
CPU (GMP): probable-prime testing, true-root recovery for non-roots, and chain-length confirmation

The GPU sieve rejects about 99.9988% of candidates before expensive primality work is needed. Only about 0.0012% survive to the CPU path.

Interactive Visualizations

Each tool shaped the search design.

Cunningham Chain Mesh: 2-adic square-perimeter map with CC1/CC2 edges and chain paths
2-Adic Tree Explorer: inspectable tree with local chain structure
3D Fold: shell structure across levels; top view becomes the p+1 analysis grid
p+1 Analysis: factor coloring for primes, mod-p view for composites
Chain Analyzer: single-chain analysis, breaker autopsy, residue immunity
Campaign Dashboard: live campaign tracking across bit ranges and chain lengths
Immunization Dashboard: residue immunity analysis

Project Stack

Search: CUDA filtering, GMP proving, prefix sharding, checkpointing
Visualization: standalone HTML/JS tools
Analysis: Python plus HTML tools for autopsy and fingerprinting
AI-assisted: LLMs used for coding iteration; math direction and search decisions are human-driven
Extra: a PARI/GP library and a small MCP server wrapper for interactive Cunningham-chain analysis

Part of the project was also an experiment in AI-assisted iteration: not one-shot prompting, but many rounds of visual exploration, code generation, rejection, correction, and performance tuning. The transferable lesson for me was not number theory itself, but the workflow: isolate the hot path, turn it into something benchmarkable, iterate quickly with AI assistance, and only bring back changes that survive measurement.

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Nenad Mićić — Mon, 15 Sep 2025 08:42:38 +0000

I'm sharing this with the team as a summary of my personal workflow when working with AI on code. It's not an official framework, but rather a set of learnings from experience (polished with a little help from AI, of course). My main goal is to start a conversation. If you have a better or similar workflow, I'd genuinely love to hear about it.

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

AI can accelerate coding, but it can also drift, hallucinate requirements, or produce complex solutions without a clear rationale.
This framework provides the guardrails to keep AI-assisted development focused, deliberate, and well-documented.

Sailing Analogy (High-Level Intro)

Working with AI on code is like sailing:

Compass → Keeps you oriented to true north (goals, requirements, assumptions).
Steering Wheel → Lets you pivot, tack, or hold steady (decide continue vs. change).
Destination Map → Ensures the journey is recorded (reusable, reproducible outcomes).

This framework grew out of real-world experience. It’s not brand new theory, but a way to formalize a shared language for teams working with AI.

Step 1: Compass (Revalidation)

Purpose: keep alignment with goals and assumptions.

Template (copy/paste):

What’s the primary goal?
What’s the secondary/nice-to-have goal?
Which requirements are mandatory vs optional?
What are the current assumptions? Which may be invalid?
Has anything in the context changed (constraints, environment, stakeholders)?
Are human and AI/system understanding still in sync?
Any signs of drift (scope creep, contradictions, wrong optimization target)?

Step 2: Steering Wheel (Course Correction)

Purpose: evaluate if we should continue, pivot, or stop.

Template (copy/paste):

For each assumption: what if it’s false?
Does an existing tool/library cover ≥80%?
Does this map to an existing framework/pattern (ADR, RFC, design template)?

Alternatives:

Different algorithm/data structure?
Different architecture (batch vs streaming, CPU vs GPU, local vs distributed)?
Different representation (sketches, ML, summaries)?
Different layer (infra vs app, control vs data plane)?

Trade-offs:

Fit with requirements.
Complexity (build & maintain).
Time-to-value.
Risks & failure modes.

Other checks:

Overhead vs value: is the process slowing iteration?
Niche & opportunity: is this idea niche or broadly useful? Where does it fit in the landscape?

Kill/Go criteria:

Kill if effort > value, assumptions broken.
Go if results justify effort or uniqueness adds value.

Next step options:

Continue current path.
Pivot to alternative.
Stop and adopt existing solution.
Run a 1-day spike to test a risky assumption.

Step 3: Destination (Reverse Prompt)

Purpose: capture the outcome in reusable, reproducible form.

Template (copy/paste):

Instructions

Restate my request so it can be reused to regenerate the exact same code and documentation.
Include a clear summary of the key idea(s), algorithm(s), and reasoning that shaped the solution.
Preserve wording, structure, and order exactly — no “helpful rewrites” or “improvements.”

Reverse Prompt (regeneration anchor)

Problem restatement (1–2 sentences).
Key algorithm(s) in plain language.
Invariants & assumptions (what must always hold true).
Interfaces & I/O contract (inputs, outputs, error cases).
Config surface (flags, environment variables, options).
Acceptance tests / minimal examples (clear input → output pairs).

High-Level Design (HLD)

Purpose: what the system solves and why.
Key algorithm(s): step-by-step flow, core logic, choice of data structures.
Trade-offs: why this approach was chosen, why others were rejected.
Evolution path: how the design changed from earlier attempts.
Complexity and bottlenecks: where it might fail or slow down.

Low-Level Design (LLD)

Structure: files, functions, modules, data layouts.
Control flow: inputs → processing → outputs.
Error handling and edge cases.
Configuration and options, with examples.
Security and reliability notes.
Performance considerations and optimizations.

Functional Spec / How-To

Practical usage with examples (input/output).
Config examples (simple and advanced).
Troubleshooting (common errors, fixes).
Benchmarks (baseline numbers, reproducible).
Limits and gotchas.
Roadmap / extensions.

Critical Requirements

Always present HLD first, then LLD.
Emphasize algorithms and reasoning over just the raw code.
Clearly mark discarded alternatives with reasons.
Keep the response self-contained — it should stand alone as documentation even without the code.
Preserve the code exactly as it was produced originally. No silent changes, no creative rewrites.

When & Why to Use Each

Compass (Revalidation):
- Use at the start or whenever misalignment is suspected (context drift, new requirements).
Steering Wheel (Course Correction):
- Use at milestones or retrospectives to decide continue, pivot, or stop.
Destination (Reverse Prompt):
- Use at the end of a cycle/project to capture reproducible documentation & handover artifacts.

References & Correlations

This framework is simple, but it builds on proven practices:

Systems Engineering: Verification & Validation (build the right thing).
Agile: Sprint reviews (revalidation), retrospectives (course correction).
Lean Startup: Pivot vs. persevere decisions.
Architecture Practices: ADRs (decision rationale, alternatives).
AI Prompt Engineering: Reusable prompt templates & libraries.
Human-in-the-Loop Design: Oversight to prevent drift in AI systems.

By combining them under a sailing metaphor, the framework becomes:

Easy to remember.
Easy to communicate inside teams.
Easy to apply in AI-assisted coding where drift, misalignment, and reusability are everyday challenges.

Closing Note

Think of this as a playbook, not theory. Next time in a session, just say:

“Compass check” → Revalidate assumptions/goals.
“Steering wheel” → Consider pivot/alternatives.
“Destination” → Capture reproducible docs.

DEV Community: Nenad Mićić

I Built compartment to Sandbox AI Agents on Linux

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

What This Is

Results

How It Works

Interactive Visualizations

Project Stack

Links

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Sailing Analogy (High-Level Intro)

Step 1: Compass (Revalidation)

Step 2: Steering Wheel (Course Correction)

Step 3: Destination (Reverse Prompt)

When & Why to Use Each

References & Correlations

Closing Note