DEV Community: Selçuk GÜRAL

I built Kule: AI agents work on a copy of your folder, and you decide what comes back

Selçuk GÜRAL — Wed, 21 Oct 2026 09:10:54 +0000

Hi, I'm Selçuk. I've been building an open-source tool called Kule, and its first preview release is out. I'd like to tell you what it does, why I built it, and what it can't do yet.

The short version: Kule is a control room for AI agents that work on your folders. You point an agent (Claude Code, Codex, Gemini, or any agent that speaks ACP) at a folder. Kule gives it a copy-on-write copy of that folder inside a sandbox, looks at what every command really changed, and lets nothing reach the real folder until a policy, or you, says so. Every commit can be undone.

("Kule" means tower in Turkish. Think control tower.)

The problem I kept running into

Coding agents are good now, good enough that we let them run commands. When an agent runs a command, it runs as you: your files, your ~/.ssh and ~/.aws, your ~/.zshrc, your network, your API keys.

Most agents ask before they run something, but they ask about the command text: "Run npm install?" You can't tell from that text what a postinstall script, a Python one-liner or a build script will actually touch. So after the twentieth prompt you start clicking "yes" without reading, or you switch on the mode that stops asking. And if a file the agent reads contains a prompt injection, the agent is on the attacker's side, and all that's left is what you approve.

I wanted something else: let the agent work freely, somewhere nothing it does is real until I've seen it.

The loop

Kule has one loop, in the CLI and in the desktop app:

make a task → give the agent a prompt → watch → review → commit or roll back.

Here it is without an agent, on a scratch folder:

mkdir -p ~/kule-demo && echo "hello" > ~/kule-demo/notes.md

kule new ~/kule-demo                                    # prints a task id, e.g. 1a2b3c4d
kule exec 1a2b3c4d -- sh -c 'echo "more" >> notes.md'  # runs in the copy, in the sandbox
kule status 1a2b3c4d                                    # what changed, and the policy's verdict
kule commit 1a2b3c4d                                    # apply it, keeping a checkpoint
kule undo 1a2b3c4d                                      # put the folder back

And with an agent:

kule run 1a2b3c4d --agent claude-code "Turn notes.md into a checklist"
kule steps 1a2b3c4d     # every tool call the agent made, and what it changed
kule commit 1a2b3c4d    # or: kule rollback 1a2b3c4d

The desktop app (Tauri) does the same thing with a live stream, an approval inbox, a review screen and a timeline. A small daemon keeps runs going when the window is closed.

What's actually between the agent and your stuff

Your folder. The agent works in a copy-on-write copy: an APFS clone on macOS, a reflink on Btrfs/XFS. Its changes reach the real folder only through a commit, and every commit keeps a checkpoint, so kule undo really puts things back. The history of commits and undos is signed and hash-chained.

Your computer. Every command runs in the OS sandbox: Seatbelt on macOS, Landlock + seccomp + namespaces on Linux. It can write only to the copy and its own temp folders. ~/.ssh, ~/.aws, your Documents and the projects next to the folder are hidden. If the sandbox can't be set up, the command doesn't run. Kule never quietly falls back to "no sandbox".

What gets in. This is the part I care about most. Kule doesn't judge the command; it judges the effects. After a run, it compares the copy with your folder: files created, modified, deleted or moved, git branches moved, hooks added. Then a Cedar policy gives each effect a verdict: pass, ask or deny.

With the default ("balanced") policy:

ordinary edits to source, notes, documents and data pass;
manifests and lockfiles, CI files, editor settings, agent instructions (CLAUDE.md, AGENTS.md, .mcp.json…), git config changes, history rewrites and mass deletes wait for you;
git hooks are denied, because they would run on your next git command, as you.

So a harmless-looking command that rewrites package.json still waits for you, and a scary-looking rm -rf that only touches the copy changes nothing real. When something waits, Kule tells you which rule stopped it:

policy: waits for approval
  package.json · waits for approval (manifests-and-lockfiles)

There's also a "careful" policy where every change waits. You can write your own, and a repository can add refusals of its own, but never loosen yours.

Your network. Every connection goes through the task's proxy. Package registries pass, the agent reaches its own model API while it runs, and anything else waits for your answer. Every connection is logged.

Your secrets. The agent sees a placeholder, never the key. The proxy puts the real value into requests going to the hosts you named, and nowhere else.

Your home. A write to ~/.zshrc, ~/.gitconfig or ~/.config lands in the task's home layer with a diff for you to review. It doesn't touch your real home.

Your wallet and your machine. Cost budgets per task, per group and per day (with a notice at 80%), CPU/memory/disk/time limits per run, and a Stop button.

Not only for code

Kule works on any folder. The review shows what changed inside a file (functions and methods, Markdown sections, JSON/YAML keys), before-and-after pictures, and previews for CSV, Excel and Word. If you let an agent tidy your notes, rename photos or clean up a data folder, the same loop applies.

Two tasks can work on the same folder. A file both of them changed merges method by method, and only the parts that were changed twice conflict.

The honest part: what it can't do (yet)

I'd rather you hear this from me than find out after an hour of setup:

It's a preview (0.2.0-preview.1). Things will change between previews.
macOS 13+ and Linux x86_64 only. Windows is planned, not started.
The macOS app isn't notarized. It's signed ad hoc, so Gatekeeper will complain the first time. Every release file comes with SHA256SUMS, a build provenance attestation and an SBOM, and the install guide shows how to check them and open the app.
Linux has some requirements. On ext4 the copy is a full copy, not a clone. The sandbox needs Landlock (Linux 6.2+, 6.7+ for network rules) and unprivileged user namespaces, which Ubuntu 24.04 restricts by default. Kule tells you what's missing and won't run an agent with weaker isolation unless you choose that knowingly.
The proxy doesn't do HTTP/2 or WebSockets yet. Clients fall back to HTTP/1.1. A few tools on macOS have certificate quirks; the Platforms page lists them all.
Kule doesn't make the agent right. It makes the agent's mistakes cheap and visible. You still review, and Kule's job is to make that review short and honest.
It's built by one person. I take security seriously (every boundary has a test that fails without it, on real processes and the real filesystem, no mocks), but one person can still miss things. That's part of why it's open.

Try it

Download: releases page (universal .dmg, .deb, .rpm, and the CLI alone as .tar.gz)
Or build from source:

  git clone https://github.com/kulehq/kule && cd kule
  cargo build --release -p kule -p kule-desktop

Docs (English and Turkish), with a quick start, a page for every command and a three-minute video tour: kulehq.github.io/kule
Code: github.com/kulehq/kule · Apache-2.0 · written in Rust

What would help me most

Try it on a real folder and tell me where it got in your way. A policy that asks too often, a confusing screen, a tool that breaks inside the sandbox: that's exactly the feedback I'm looking for. Open an issue, or just reply here.

If you find a way through one of the boundaries, please don't post it publicly. Report it privately as SECURITY.md explains. I'll be grateful, and I'll fix it.

And if Kule ends up keeping your folders safe and you'd like to help it keep going, there's GitHub Sponsors. That's completely optional. A star, an issue or a "this worked for me" means a lot too.

Thanks for reading. 🙏

Stop running your whole .NET test suite on every pull request

Selçuk GÜRAL — Fri, 16 Oct 2026 18:30:36 +0000

Every .NET codebase I have worked on hits the same wall sooner or later. The test suite grows, CI goes from three minutes to twenty, and every pull request pays the full price, even a one-line rename deep inside a helper class.

Splitting the suite or buying bigger runners helps for a while. But most of those tests could never have noticed the change in the first place. They run anyway because nothing tells CI which ones matter.

So I built TestDetta: a .NET tool and GitHub Action that reads your diff and runs only the test classes that can observe it. It follows one rule throughout: when it cannot be sure, it runs more tests, never fewer. A missed test is a bug. An extra test only costs CI time.

This post covers how it works, how to try it in a few minutes, and how to check that it holds up on your own code before you trust it.

A real example

Here is a real change to OpenTelemetry .NET: a local variable renamed inside one method. It changes no behaviour, but a normal pipeline still runs all 30 test projects and 274 test classes.

TestDetta works it out like this:

Projects: 2 of 30 test projects are affected. The other 28 are not even built.
Symbols: 1 member changed, WarnIfConfigFileEnvVarDiffers.
Coverage map: 8 test classes ran that method on main.
Result: 8 of 274 classes run, 266 are skipped.

Those 8 classes are exactly the ones that fail when that method is broken. Recorded test time went from 5 m 59 s to 22.4 s.

Try it in two minutes

TestDetta is a .NET tool (it runs on the .NET 10 SDK; your projects can target older frameworks):

dotnet tool install --global TestDetta

Ask what your branch affects, and why:

td affected --base origin/main

See the dotnet test commands it would run, without running anything:

td test --base origin/main --dry-run

And run only the affected tests:

td test --base origin/main

The output looks like this:

$ td test --base origin/main
TestDetta 0.2.2 · 1 changed file · 2 affected test projects
Tests to run
┌──────────────────┬──────────┬─────────┬──────────────────────────────────────────────────────────┐
│ Test project     │ Run      │ Classes │ Why                                                      │
├──────────────────┼──────────┼─────────┼──────────────────────────────────────────────────────────┤
│ tests/Shop.Tests │ filtered │  3 / 41 │ 3 of 41 test class(es) run or reference the changed code │
│ tests/Api.Tests  │ skipped  │  0 / 12 │ no test class runs or references the changed code        │
└──────────────────┴──────────┴─────────┴──────────────────────────────────────────────────────────┘
  tests/Shop.Tests → 3 classes
    Shop.Tests.CartTests
    Shop.Tests.CheckoutTests
    Shop.Tests.OrderTests

Without a coverage map, TestDetta decides by tracing names through your source. For sharper selection, record a map once on your default branch:

td record

This runs every test with coverage and writes one map per test project to .testdetta/coverage (add .testdetta/ to your .gitignore).

Need machine-readable output? td affected --format json gives you the selection for your own scripts, --format paths lists the test projects, and --format commands prints the dotnet test commands.

How it decides

Each step narrows the selection only when it has evidence. Otherwise it falls back to something wider.

Projects. Changed files are mapped to their projects and followed through ProjectReferences. Build-wide files such as Directory.Build.props, global.json or .editorconfig affect every project below them.
Symbols. For C#, Visual Basic and F# files, the old and new syntax trees are compared (Roslyn for C# and VB). Comment and whitespace edits select nothing. Otherwise TestDetta knows exactly which types and members changed.
Coverage. A map of which test class ran which method, recorded at the base commit, gives the test classes for changed methods, properties and constructors directly.
Names. What coverage cannot see, such as new code, fields and constants, is traced through the source by name until it reaches test classes or code the map knows.
Fallbacks. When a change cannot be traced, the whole test project runs. That covers non-code files the build uses (appsettings.json, .csproj, .resx), global usings, assembly attributes, and types a framework discovers through reflection (controllers, message handlers, EF configurations).

There is one more safety net: if a filter matches no test at all, TestDetta treats that as its own bug and runs the project again without the filter.

A few details took a lot of work to get right:

Maps don't have to be fresh. The best map is one recorded at your branch's merge base. A map up to 50 commits older still works: TestDetta also selects the classes that ran anything changed in between that could reach your change.
Source generators are handled. Generated code is read from the PDBs during recording. When a change reaches a generator in your repository, TestDetta builds the test projects that use it and compares what is generated, framework by framework.
#if code is not missed. C# files are parsed with each target framework's real preprocessor symbols, and with every symbol their #ifs name.
Your test configuration is respected. Your own --filter, run settings and runner arguments are combined with TestDetta's class filter, so it only ever narrows your runs.

In GitHub Actions

The usual setup records a map on every push to main and runs only the affected tests on pull requests:

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read
  actions: read # lets pull requests find the newest coverage map in the Actions cache

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7 # pin to a commit SHA
        with:
          fetch-depth: 0 # TestDetta compares with the merge base
          persist-credentials: false

      - uses: actions/setup-dotnet@v6 # pin to a commit SHA
        with:
          global-json-file: global.json

      # Full test run of main, which also records the coverage map
      - if: github.event_name == 'push'
        uses: TestDetta/action@a2f55a8252840a367f2f7a9ebd6733de3ebfb2f5 # v0.2.2
        with:
          mode: record

      # Pull requests run only what the change can affect
      - if: github.event_name == 'pull_request'
        uses: TestDetta/action@a2f55a8252840a367f2f7a9ebd6733de3ebfb2f5 # v0.2.2
        with:
          mode: test
          dotnet-test-args: --logger trx

Maps live in the Actions cache, keyed by commit, and pull requests read the map of their merge base. Every run writes a job summary explaining what ran and why.

Not on GitHub? GitLab CI, Azure DevOps, Jenkins and Bitbucket use the same two commands (td record and td test) with a folder of per-commit maps on a shared disk or object storage (--maps-dir).

Don't trust it, check it

A tool that decides which tests to skip has to earn your trust on your own codebase, not on a marketing page. TestDetta ships two ways to check it, and neither needs a license:

Shadow mode (td test --shadow, or mode: shadow in the action) keeps running your full suite and compares the result with what the selection would have run. When a test fails outside the selection, it reruns that class to tell a real miss from a flaky or pre-existing failure. Run it for a couple of weeks of normal pull requests and you have evidence from your own code.

Audit (td audit, or mode: audit) doesn't wait for real failures. It breaks your code on purpose, one member at a time with IL mutants in a copy of the working tree, runs every test that can see each change, and reports any failing class the selection left out. It also reports the 95% upper bound of the miss rate. Your sources and build output are only read.

How it is tested

I run the same check at scale on 53 open-source .NET repositories, including Polly, Newtonsoft.Json, AutoMapper, Serilog, Markdig, Refit, Autofac, NodaTime, FastEndpoints, FluentValidation and OpenTelemetry. Members are changed one at a time, and every test class that fails must be one TestDetta selected.

From the latest round (2026-10-13 to 2026-10-15):

3,071 changes broke at least one test.
5 misses, each a documented limitation (more on those below). Earlier real misses were fixed, each with a regression test that fails without the fix.
The median repository ran 35% of its test classes per change. In 20 of the 53 repositories it was a quarter or less, and Polly got down to 3%.

To be upfront: some repositories gain much less. Mapperly ran 97% and AutoMapper 86%, because nearly every test there goes through the same central code paths. If most of your tests touch everything, test impact analysis can't save much, and the evaluation shows that honestly.

Limitations

TestDetta is static and coverage-based analysis, not magic. Here is what it can't fully see:

Code that runs once per process (static constructors, lazy singletons, EF model building) is credited to the first test class that triggers it. TestDetta traces changes to such code by name instead, but a cache you wrote by hand (a Dictionary checked with TryGetValue) can still hide its users.
Reflection and dynamic loading are only partly visible. Types a framework discovers this way run their whole test project.
F# signature files (.fsi) are not analysed, so a change to one runs its project's dependents.
Tests skipped while recording have no coverage, for example a missing Docker daemon. Record where your tests actually run.

The full list is on the Limitations page. My recommendation: keep running the full suite on your default branch. Recording does that anyway, so anything a selection could ever hide is still caught before release.

What's supported

Test frameworks: xUnit v2, xUnit v3, NUnit, MSTest and TUnit
Runners: VSTest and Microsoft.Testing.Platform (read from global.json)
Languages: C#, Visual Basic and F#
CI: GitHub Actions, GitLab CI, Azure DevOps, Jenkins, Bitbucket and on-premises setups

Privacy and licensing

None of your code leaves your CI. Analysis, coverage maps and test results stay on your machines. The only network call is an optional license renewal, at most once a day, that sends the license and nothing else.

TestDetta is free for public repositories on GitHub Actions and GitLab CI, with every feature and no sign-up. It detects public repositories from the CI itself. Private repositories need a paid license, with a 30-day free trial that needs no card. A license problem never fails your build: without a valid license, every test simply runs, as it did before TestDetta.

Anka: Designing a Minimal HTTP Server for Native AOT, Its Architecture, and Intentional Constraints

Selçuk GÜRAL — Fri, 01 May 2026 16:48:33 +0000

In modern backend systems, being “fast” alone is no longer enough. How quickly your service responds to the first request, how little memory it consumes at startup, and how predictably it behaves are now just as important as raw throughput. Especially in serverless, short-lived container, edge worker, and bursty internal service scenarios, the real problem is often not steady-state throughput, but cold start performance, startup allocations, and operational simplicity.

Anka approaches this problem from the opposite direction of the traditional ASP.NET Core model: no middleware pipeline, no built-in routing, no TLS, no HTTP/2. Instead, it provides a Native AOT-friendly, HTTP/1.x-focused, allocation-conscious HTTP server core built on .NET 8+. The goal is straightforward: once the process starts, begin listening on the socket within milliseconds and keep the connection/request lifecycle as deterministic as possible.

The Problem

The traditional .NET web stack is extremely powerful, but that power comes with a cost. Middleware chains, reflection-heavy surfaces, dynamic extensibility, broad protocol support, and JIT warmup all introduce significant overhead on the cold-start path. If your actual requirement is simply:

“Open a socket, parse HTTP/1.1, execute a handler, and write the response,”

then the general-purpose framework model can become unnecessarily expensive.

The core question Anka focuses on is:

If we do not need a full-featured web framework, but only a fast-starting, low-memory, Native AOT-compatible HTTP listener, what should the minimum architecture look like?

The answer becomes visible in the performance characteristics as well. In measured environments, Anka reaches a time-to-ready of approximately 2.3 ms, startup allocations around 124.5 KB, and a steady-state RSS of roughly 15 MB. Kestrel, by comparison, offers a much broader feature set, but carries a heavier cold-start and memory profile. Interestingly, throughput differences are not dramatic; Anka’s real advantage is not raw requests-per-second, but startup cost and footprint.

Architecture: Minimal Layers, Maximum Control

Anka’s architecture is intentionally narrow:

Server.StartAsync()
-> parallel accept loops
-> Connection.RunAsync() (one task per TCP connection)
-> SocketReceiver.ReceiveAsync()
-> HttpParser
-> RequestHandler(request, response, ct)
-> HttpResponseWriter.WriteAsync()

The important aspect of this flow is that there is very little abstraction. Request processing starts directly at the socket layer and ends directly at the socket layer.

Server: The Acceptance Layer

The server opens the listening socket, configures the backlog, and runs multiple parallel accept loops instead of a single accept loop. This may sound like a small detail, but under burst traffic it prevents a single accept loop from serializing connection acceptance.

Additionally, the minimum thread pool size is increased to reduce thread injection latency during initial load. This may look like benchmark tuning, but in reality it is an operational decision intended to make cold-path behavior more deterministic.

Connection: The Real Unit of Execution

A Connection task is created for each TCP connection. This object:

rents a pooled receive buffer,
acquires a pooled HttpRequest,
creates a connection-scoped HttpResponseWriter,
reads and parses data from the socket,
invokes the request handler,
and if keep-alive is enabled, continues with the next request using the same resources.

The critical idea here is resource ownership at the connection level rather than the request level. This minimizes repetitive buffer rental and return operations across keep-alive requests.

SocketReceiver: Async I/O with Allocation Discipline

Instead of using the more convenient Socket.ReceiveAsync(Memory) APIs, Anka uses SocketAsyncEventArgs together with IValueTaskSource.

This is not micro-optimization for its own sake. The goal is to avoid state machine overhead and additional allocations when socket reads complete synchronously.

In loopback or LAN scenarios, data is often already available in the kernel buffer. In those cases, the receive operation completes synchronously and the system proceeds with almost direct function-call overhead. If data is not available, the OS I/O completion thread finishes the operation, while continuations are posted back to the thread pool using RunContinuationsAsynchronously = true.

The result: I/O threads are not blocked by request-processing work.

HttpParser: Single-Pass Parsing

The parser’s real value is not merely that it parses HTTP, but that it does so in a single pass using pooled buffers.

It performs:

request line parsing,
path/query separation,
lowercase normalization of header names during ingestion,
inline Content-Length tracking,
request body reading when necessary,
chunked request body decoding and reassembly into req.Body,
keep-alive decision calculation during parsing.

This approach provides two important benefits:

No second header scan is required.
The HttpRequest passed to the handler is already in a usable, near zero-copy state.

HttpResponseWriter: Not a Framework, Just Wire Format

The response layer follows the same philosophy. HttpResponseWriter constructs the HTTP response header block inside a pooled buffer, inlines small bodies into the same buffer whenever possible, and writes directly through Socket.SendAsync().

Another important design choice here is the absence of chunked response encoding. All responses use Content-Length.

This constraint simplifies the response pipeline significantly and narrows the execution path for AOT and low-allocation goals.

Core Design Decisions

A Single RequestHandler Delegate

Anka has no middleware chain. There is only one RequestHandler.

This is a deliberate form of radical simplification.

Benefits

shorter call chains,
fewer abstraction layers,
lower dispatch overhead,
a cleaner surface for Native AOT.

Costs

cross-cutting concerns must be implemented manually,
routing, authentication, logging, and metrics are not framework-managed.

This is not an “incomplete framework”; it is a primitive-oriented design.

No Built-in Routing

Path dispatching is left entirely to user code. A simple switch statement is considered sufficient for many scenarios.

At first glance this may appear primitive, but routing costs are not limited to path matching itself. Routing systems also bring metadata graphs, endpoint conventions, and large API surfaces. Anka rejects that cost upfront.

Lowercasing Header Names During Ingestion

Instead of performing case-insensitive lookups repeatedly, header names are normalized during parsing. This allows lookups to use straightforward SequenceEqual comparisons.

It may seem like a small design detail, but on the hot path it reduces both branching and processing overhead.

Reusing HttpRequest and Buffers Across Connections

The HttpRequest.ResetForReuse() approach avoids discarding request objects after every request. The same object is reused throughout the connection lifetime.

This becomes especially effective under keep-alive workloads, because steady-state allocation reductions often come not from huge optimizations, but from many small, systematic reuse decisions.

Small CAS-Based Request Pool

The HttpRequestPool is lock-free and intentionally small.

The goal is not theoretical “infinite pooling,” but a practical, cache-friendly, low-overhead reuse mechanism. If all slots are occupied, objects are simply discarded.

This is another important engineering decision: trying to pool everything can sometimes become more expensive than not pooling at all.

Trade-offs: What This Architecture Gains — and Intentionally Gives Up

One of Anka’s strengths is that it clearly communicates what it is not.

Decision	Benefit	Cost
No middleware	Shorter hot path, fewer abstractions	Developers handle cross-cutting concerns
No built-in routing	Lower startup cost, simpler model	Reduced ergonomics in large APIs
HTTP/1.x only	Narrower execution path, simpler AOT surface	No modern protocol features
No built-in TLS	Keeps the core minimal	Reverse proxy becomes mandatory
No chunked responses	Simpler response writer	Limited streaming ergonomics
Raw socket approach	Full control over allocations and behavior	Higher maintenance burden

The most important trade-off is this:

Anka does not exist to replace Kestrel. It exists to occupy a different optimization point.

If you need HTTP/2, TLS termination, middleware ecosystems, advanced hosting integrations, or rich observability plugins, then Kestrel is probably still the correct answer.

But if your priority is low footprint, rapid readiness, and a highly controlled request path, Anka becomes compelling.

The Strongest Part of This Design: Predictability, Not Performance

In my opinion, the real value here is not just “0 B allocations” or “2.3 ms startup.”

The real value is how easy it becomes to mentally model the system:

one task per connection,
connection-scoped buffers,
parse → handle → write pipeline,
very few failure states,
limited protocol surface.

Architecturally, systems like this become valuable not because of benchmark presentations, but because of operational clarity. You know exactly what the system does, what it does not do, where behavior changes under load, and where costs are paid.

Example Use Cases

Serverless or Short-Lived Container APIs

If cold start is critical and the endpoint surface is small, Anka’s minimal startup overhead becomes a major advantage.

Sidecar / Internal Control Plane Endpoints

For health checks, readiness probes, metrics gateways, or simple control APIs, a full framework is often unnecessary.

Edge Compute and Appliance Deployments

Low RSS and Native AOT compatibility matter significantly in resource-constrained environments.

Benchmarking and Protocol Research

Anka provides a clean environment for teams that want to observe HTTP pipeline behavior without framework noise.

Narrowly Scoped, High-Control Services

It is well suited for single-purpose webhook receivers, internal callback endpoints, or lightweight ingestion services.

When I Would Not Use It

Personally, I would avoid this architecture for:

large general-purpose product APIs developed by big teams,
applications requiring rich middleware ecosystems,
systems where streaming, TLS, or HTTP/2 are first-class requirements,
organizations where framework integrations matter more than low-level control.

Because what you gain here is not “freedom.”

It is control.

And control always comes with increased engineering responsibility.

Conclusion

The most accurate technical summary of Anka is this:

It is not an HTTP server that gains performance by adding optimizations on top of features; it gains simplicity and predictability by deliberately reducing scope.

Native AOT compatibility, low startup allocations, connection-scoped resource management, single-pass parsing, and direct socket writing all serve the same goal:

a small, fast-starting, understandable request pipeline.

This approach is not for everyone — and it is not trying to be.

From an experienced backend engineering perspective, its most mature characteristic is precisely this: it defines the problem narrowly, optimizes aggressively for that problem, and consciously leaves everything else outside the boundary.

And often, that is a far more valuable engineering decision than building a system that tries to do everything.

Originally published in Turkish on my personal blog:

https://selcukgural.com/2026/04/17/anka-native-aot-icin-minimal-http-sunucusu-tasarlamak-ankanin-mimarisi-ve-bilincli-kisitlari/