Linkblog

Vibe Engineering a Personal Tool

Tue, 09 Jun 2026 00:00:00 +0000

There are two approaches when it comes to using modern coding agents. On one end of the spectrum is pure vibe coding: you let the agent build and never look at the code. The other end has been dubbed agentic engineering: you treat the agent as a co-developer, and you discuss and review all changes in detail.

At CosmoCode, we usually use the latter approach. We want to own and understand the code we deliver. Coding agents can help us deliver better code, not necessarily more code or code built faster.

But if the approach to coding agents is a spectrum, then there should be a middle ground as well. I like to call it “vibe engineering”. Vibe engineering is a more relaxed approach to coding agents: you still review the code it generates, but you don’t scrutinize every line of it.

I like this approach for personal tools that aren’t purely one-off scripts, but also aren’t production code. These are tools that I want to use for myself, but that I don’t necessarily want to turn into real “projects”.

One of my colleagues asked me if I could describe how I approach vibe engineering for such a personal tool, using a real example. This is easier said than done, but I’ll try anyway. I will give some examples of the kind of interactions I have with the agent without reproducing the entire conversation. I’ll hide the full Claude answers behind a details tag, so you can drill into them if you want to see the full context. I will still omit the tool calls.

Step 1: Brainstorming

We’re running most of our services in a Kubernetes cluster, and sometimes you need to move files to or from a storage volume mounted to a specific pod. This can be done with kubectl cp. However, kubectl cp does not take care of copying last modified dates. The workaround is to use kubectl exec and tar to stream to stdout, then use a second tar to read stdin on the other side: classic Unix tooling. But constructing the right kubectl exec call is non-trivial.

I wanted a simple, Midnight Commander-like, two-panel TUI interface for copying files. One side shows my local computer and the pod’s filesystem is shown on the other side. Files can simply be selected and copied by the press of a button.

To figure out how feasible this is, I actually started in Claude chat. I find that the chat interface is a better way to do initial brainstorming than jumping right into Claude Code - especially when I am not even sure I want to pursue the project in the end. I can ask questions, get suggestions, and iterate on the idea without constantly having to tell Claude not to start coding. But yes, I could also have used Claude Code’s plan mode.

question: how complicated would it be to create a simple TUI tool that uses kubectl and tar to allow for easy file transfer between the local machine and a kubernetes pod using a two panel layout? (tar to preserve timestamps and file permissions)

Claude explains how it could work and offers three approaches
Not very complicated. A working version is a weekend project; a polished one is maybe a week.
Here’s the breakdown:
The core mechanics are easy. kubectl already does the heavy lifting:

List remote files: kubectl exec <pod> -- ls -la --time-style=full-iso /path (parse the output)

Pull a file/dir preserving metadata: kubectl exec <pod> -- tar cf - -C /parent target | tar xf - -C /local/dest

Push: tar cf - -C /local target | kubectl exec -i <pod> -- tar xf - -C /remote/dest

This is essentially what kubectl cp does internally (it’s tar-based), but you get to control flags like --numeric-owner, -p, etc. yourself.
The TUI is the bulk of the work. A two-panel layout (local on left, remote on right, Tab to switch focus, arrows to navigate, Enter to descend, F5/F6 to copy — basically Midnight Commander) is a well-trodden pattern. The real effort goes into directory navigation state, scrolling, selection, and async transfers so the UI doesn’t freeze.
Recommended stack:

Go — bubbletea/bubbles for the TUI, and you can use client-go to talk to the API directly (including the exec/SPDY streaming) instead of shelling out. Natural fit since kubectl is Go.

Python — textual for the TUI is very fast to build in; shell out to kubectl or use the kubernetes client library. Lowest effort to a prototype.

Rust — ratatui if you want a single static binary and don’t mind more work.

The fiddly parts (where the time actually goes):

Pods often lack tar (especially distroless/scratch images) — you need a fallback or a clear error.

Multi-container pods need -c <container>.

Async progress reporting for large transfers without blocking the event loop.

Error handling for permissions, broken pipes, missing paths.

Context/namespace selection.

If you shell out to kubectl and use Textual or Bubbletea, a usable single-pod-context prototype is genuinely a 1–2 day effort. Going to API-direct streaming, progress bars, multi-namespace browsing, and the tar-missing fallbacks is what stretches it toward a week.
Want me to sketch out a starter implementation in one of these stacks?

Hmm I would tend towards go because I like the single binary and I know a bit of go. But you say it’s the most difficult option?

Claude suggests to keep things simple
Not the most difficult — I’d put it in the middle. The ordering I had in mind:

Python/Textual — fastest to a prototype, but you don’t get the single binary you want (you’re shipping a Python env or doing PyInstaller gymnastics).

Go/Bubbletea — slightly more upfront ceremony than Python, but you get the single static binary, and you already know some Go. This is the sweet spot for your constraints.

Rust/ratatui — most work (borrow checker + more manual TUI plumbing), only worth it if you specifically want it.

So Go isn’t the hard option — it’s the right one for what you care about. Python only “wins” on raw speed-to-prototype, and it loses the thing you explicitly said you like.
One more decision inside the Go path that affects difficulty:
Shell out to kubectl (run exec.Command("kubectl", ...)) — much simpler. You let the user’s existing kubeconfig/context do its thing, and you just pipe tar streams around. This keeps you firmly in the “1–2 day prototype” zone.
Use client-go directly — no kubectl dependency, cleaner streaming, but client-go has a real learning curve (the exec/SPDY/remotecommand setup is notoriously fiddly, and kubeconfig loading has its own boilerplate). This is what pushes things toward the week.
My suggestion: start by shelling out to kubectl. You get a working tool fast, and you can swap the transfer layer for client-go later without touching the TUI — if you keep a clean interface like:
type Transfer interface {
List(pod, path string) ([]FileInfo, error)
Pull(pod, remotePath, localPath string) error
Push(pod, localPath, remotePath string) error
}
Then the kubectl-shelling implementation and a future client-go implementation are just two structs satisfying the same interface.
Want me to put together a starter Bubbletea skeleton with the two-panel layout and a kubectl-backed Transfer implementation?

can you create a PLAN file that I can pass to a coding agent?

At that point, Claude created a plan artifact, which I read through and addressed my concerns about certain details.

one question about the numeric UIDs. when the pod container runs rootless, you probably can not change UIDs?

After Claude clarified, I asked it to update the plan, and then I was ready to start coding.

PLAN.md:
PLAN: k8tc — A Two-Panel TUI for Kubernetes Pod File Transfer
Goal
Build a terminal UI tool, written in Go, that lets a user browse the local filesystem and a Kubernetes pod’s filesystem side-by-side in a two-panel (Midnight Commander style) layout, and transfer files/directories between them. Transfers use tar streamed over kubectl exec so that timestamps and file permissions are preserved.
Ship as a single static binary.
Non-Goals (v1)

No client-go integration. v1 shells out to the user’s existing kubectl. (Keep the transfer layer behind an interface so client-go can be added later without touching the TUI.)

No editing of remote files in-place.

No multi-pod parallel transfers.

No Windows-specific polish (target Linux/macOS; it may work on Windows but that is not a v1 requirement).

Tech Stack

Language: Go (1.22+)

TUI framework: Bubble Tea (github.com/charmbracelet/bubbletea) with Bubbles components and Lip Gloss for styling.

External dependency at runtime: kubectl must be on the user’s PATH and configured (valid kubeconfig / current context). The target pod must have tar available in the chosen container.

Architecture
Package layout
cmd/k8tc/main.go        # entrypoint, flag parsing, bubbletea program start
internal/transfer/      # the Transfer interface + kubectl implementation
transfer.go           # interface + shared types (FileInfo)
kubectl.go            # kubectl-backed implementation
internal/local/         # local filesystem browsing (List/Stat helpers)
internal/ui/            # bubbletea model, panels, key handling, rendering
model.go
panel.go
keys.go
styles.go
Core interface
The transfer layer is abstracted so the kubectl implementation can later be swapped for a client-go one:
package transfer

import "time"

type FileInfo struct {
    Name    string
    Size    int64
    Mode    string    // e.g. "drwxr-xr-x"
    IsDir   bool
    ModTime time.Time
}

type Transfer interface {
    // List returns directory contents at path inside the pod.
    List(pod, container, path string) ([]FileInfo, error)
    // Pull copies remotePath (file or dir) from the pod to localPath, preserving metadata.
    Pull(pod, container, remotePath, localPath string, progress func(n int64)) error
    // Push copies localPath (file or dir) into the pod at remotePath, preserving metadata.
    Push(pod, container, localPath, remotePath string, progress func(n int64)) error
}
The local filesystem panel does not go through Transfer; it uses the internal/local helpers directly. Only the remote panel uses Transfer.
Transfer Mechanics (the important bit)
All remote operations shell out to kubectl. Build commands with os/exec.CommandContext and stream stdin/stdout — never buffer whole files in memory.
Listing remote files
kubectl exec <pod> [-c <container>] -- ls -la --full-time <path>
Parse the output into []FileInfo. Notes:

Use --full-time (GNU coreutils) for a parseable ISO timestamp. If that fails (BusyBox), fall back to ls -la and accept coarser/absent mtimes rather than erroring out.

Skip the total N first line.

Always synthesize a .. entry for navigation (unless at /).

Detect directories from the leading d in the mode string.

Pull (pod → local), metadata-preserving
kubectl exec <pod> [-c <container>] -- tar cf - -C <remoteParent> <remoteBase> \
| tar xpf - --no-same-owner -C <localDest>
tar c on the remote side, piped to tar xp locally (-p preserves mode + mtime). --no-same-owner is the default for pulling — see “tar flags & ownership” below for why.

Run the local tar via exec.Command and connect the kubectl stdout to its stdin with an io.Pipe (or cmd.StdoutPipe() → cmd2.Stdin).

Wrap the pipe in a counting io.Reader to drive the progress callback.

Push (local → pod), metadata-preserving
tar cf - -C <localParent> <localBase> \
| kubectl exec -i <pod> [-c <container>] -- tar xpf - --no-same-owner -C <remoteDest>
Note the -i on kubectl exec so stdin is forwarded.

--no-same-owner again by default — in a rootless container the extract cannot chown anyway (see below); this makes the intent explicit and avoids warnings.

Same counting-reader trick for progress.

tar flags & ownership
Mode bits and mtime are reliably preserved without privilege. Owner UID/GID is not — treat it as best-effort.
When tar x runs without CAP_CHOWN (extracting on your local machine as a normal user, or inside a rootless pod), the chown() calls fail with EPERM. GNU tar’s default for a non-root extract is to silently drop ownership restore and create files owned by the extracting user — it does not hard-fail. So a blanket --numeric-owner on extract buys nothing in the common case: it only controls how a UID is chosen (by number vs. name lookup), not whether tar is allowed to apply it.
Defaults, therefore:

Create side: tar --numeric-owner -cf - ... Numeric is harmless here and avoids name-lookup surprises when packing.

Extract side (default): tar -xpf - --no-same-owner ... Preserves mode + mtime, and explicitly tells tar not to attempt chown. This is the right default for both directions:

Pulling to local: you almost never want the pod’s UIDs applied on your machine anyway (UID 1000 in the pod ≠ you).

Pushing to a rootless pod: the chown would no-op regardless, so don’t pretend otherwise.

Opt-in ownership preservation: add a --preserve-ownership flag to k8tc. When set, use tar --same-owner --numeric-owner -xpf - ... on the extract side. This only does anything useful when the extracting end is privileged (root in the container, or root locally); otherwise it degrades to the same best-effort behavior. Document this clearly so users aren’t surprised when UIDs don’t carry across into a rootless target.
What actually hard-fails is unrelated to ownership: writing into a directory you lack write permission for, or a restored directory mode that locks tar out mid-extract. Those surface as EPERM/EACCES on the file ops themselves and should be reported per-transfer (see Error Handling).
TUI Behavior
Layout
Two equal-width panels filling the terminal, a header line, and a footer/status line.
┌─ LOCAL: /home/user/project ──┐┌─ POD nginx-abc:/var/www ──────┐
│ ..                           ││ ..                             │
│ > src/                       ││   index.html                   │
│   README.md                  ││   assets/                      │
│   go.mod                     ││                                │
│                              ││                                │
└──────────────────────────────┘└────────────────────────────────┘
Tab: switch  ↑↓: move  ⏎: open  F5: copy  q: quit      [status...]
The focused panel has a highlighted border; the cursor row is highlighted.

Each panel maintains its own cwd, file list, cursor index, and scroll offset.

Keybindings

Key Action
Tab Switch focus between local and remote panel
↑ / ↓ Move cursor
PgUp/PgDn Page cursor
Enter If dir: descend; if ..: go up; if file: no-op (v1)
F5 / c Copy highlighted entry from focused panel → other panel’s cwd
r Refresh focused panel
q / Ctrl+C Quit
Async transfers
Transfers must not block the event loop. Use the Bubble Tea pattern:

On F5, dispatch a tea.Cmd that runs the Pull/Push in a goroutine and returns a transferDoneMsg{err} (and intermediate transferProgressMsg{n} via a channel + tea.Tick or a custom message pump).

While in flight, show progress/byte-count in the status line and disable further copy actions.

On completion, refresh the destination panel and clear status.

CLI
k8tc --pod <name> [--namespace <ns>] [--container <name>] [--remote-path <path>] [--local-path <path>]
--pod (required for v1)

--namespace / -n → passed through as kubectl -n

--container / -c → passed through as kubectl exec -c; if omitted, let kubectl pick the default container

--remote-path initial remote dir (default /)

--local-path initial local dir (default .)

--preserve-ownership attempt to restore owner UID/GID on extract (--same-owner --numeric-owner). Off by default; only effective when the extracting end is privileged. See “tar flags & ownership.”

(Stretch: a pod picker if --pod is omitted, via kubectl get pods -o json.)
Error Handling & Edge Cases
The agent must handle these explicitly, surfacing errors in the status line rather than crashing:

kubectl not found on PATH → fail fast at startup with a clear message.

tar missing in the pod (distroless/scratch images) → detect the exec failure and show: “pod has no tar; cannot transfer.” Do not hang.

Multi-container pod with no --container → kubectl will error; surface its message and hint to pass -c.

Permission denied on read (local or remote) → show per-transfer error, keep the UI alive.

BusyBox ls lacking --full-time → fall back gracefully (see Listing).

Broken pipe / context cancel mid-transfer → clean up both processes (CommandContext + cmd.Wait() on both ends; kill the partner on failure).

Empty directories and the root / (no ..).

Large files → never read fully into memory; always stream.

Spaces / special chars in paths → pass paths as separate exec.Command args (no shell string interpolation); when piping two exec.Cmds, do it in Go via pipes, not via a sh -c "... | ..." string.

Suggested Build Order (milestones)

Transfer interface + kubectl List. CLI prints a remote ls. Verify parsing against a real pod.

Local List. Mirror the same FileInfo for the local FS.

Static two-panel render (Lip Gloss) with both panels populated, no interaction.

Navigation: focus switching, cursor movement, Enter to descend/ascend, scroll offset, refresh.

Pull (pod → local) synchronous first, then move it onto the async tea.Cmd pattern with a status line.

Push (local → pod) same shape as Pull.

Progress reporting via counting reader → status line.

Edge-case hardening from the list above (tar-missing, busybox ls, cancellation).

Polish: styling, help footer, --namespace/--container plumbing.

Milestones 1–6 are the usable prototype. 7–9 are the path to “done.”
Acceptance Criteria

Launches with k8tc --pod <p> and shows local + remote panels.

Tab switches focus; arrows + Enter navigate both filesystems.

F5 copies the highlighted file or directory in the focused panel into the other panel’s current directory.

Transferred files retain original mtime and permission (mode) bits (verify with stat on both ends). Owner UID/GID is best-effort: preserved only with --preserve-ownership against a privileged extract target.

Directory transfers are recursive and also preserve metadata.

A transfer of a large file does not freeze the UI and shows progress.

Missing tar in the pod produces a clear error, not a hang or panic.

Builds to a single static binary: CGO_ENABLED=0 go build.

Future (post-v1, do not build now)

Swap the kubectl-backed Transfer for a client-go implementation (exec via remotecommand SPDY) to drop the kubectl runtime dependency.

Pod/namespace picker UI.

Multi-select and queued transfers.

File preview / view pane.

Delete / rename / mkdir operations.

Key	Action
`Tab`	Switch focus between local and remote panel
`↑` / `↓`	Move cursor
`PgUp/PgDn`	Page cursor
`Enter`	If dir: descend; if `..`: go up; if file: no-op (v1)
`F5` / `c`	Copy highlighted entry from focused panel → other panel’s cwd
`r`	Refresh focused panel
`q` / `Ctrl+C`	Quit

The main takeaway here is not to start the implementation in the chat. That’s the entirely wrong environment. Get a PLAN artifact and take it to the code environment.

Step 2: Initial Implementation

It was time to move to Claude Code. I run Claude in a custom sandbox using bubblewrap on Linux. This allows me to safely run in auto mode, which means Claude is running mostly autonomously with an LLM classifier as the only safeguard.

In this concrete example, the sandbox prevented Claude from accessing my kubectl config and thus from running kubectl commands against our cluster unchecked.

I added the PLAN.md to a new repository and let Claude one-shot the initial implementation.

read @PLAN.md and implement it

About 20 minutes later, Claude reported that it was done. Time to give the tool a quick test.

It worked just as specified ✨️. I could have stopped here if this were an one-off tool.

Step n: Review

Before I decided to add more features, I wanted to review the code.

Another reason why I decided to use Go is that the code is usually more straightforward and easier to review than Python or Rust. Go tends to have only one way to do things, which makes it easier for the agent to generate code that is correct and idiomatic. And that in turn makes it easier for me to review the code and understand what it does.

When vibe engineering, I mostly look at architectural decisions and code structure. I don’t want to nitpick every line of code, but I want to make sure that the overall design makes sense and that the code is organized in a way that is maintainable.

As an example, here is the review session I had with Claude right after the initial implementation.

Let’s review the current state. I see that we have a FileInfo struct and a Transfer interface. The comment says that this only covers the remote side and that the local side does not use the interface. But then looking at local.go it uses transfer.FileInot and transfer.Sort so it seems the two sides are not that different?

Claude gives an explanation that doesn’t fully satisfy me
I read all four files. Here’s what’s actually going on — the tension you spotted is real but it’s conflating two different things that live in the transf er package.
There are two separate things in transfer.go

A shared data layer — the FileInfo struct (transfer.go:15) and the Sort helper (transfer.go:40). Both panels use these, by design. That’s why FileInfo’s own comment says “on either the local or the remote side.”

The Transfer interface — List/Pull/Push (transfer.go:25). This is what the local side doesn’t use.

The comment at transfer.go:23-24 is talking strictly about #2. And it’s literally accurate: the local panel calls local.List(p) — a plain package functi on (model.go:109) — whereas the remote panel dispatches through the interface, t.List(...) (model.go:111). So when the comment says “does not go through this interface,” it means local doesn’t implement the List/Pull/Push method set, not that local is walled off from the package.
So your instinct is half right: the display side is barely different (shared types + shared sort), but the transfer side is fundamentally asymmetr ic.
Why local isn’t behind the interface
Two reasons, and the second is the deeper one:

Nothing to swap. The package doc says the interface exists “so the kubectl implementation can later be swapped for a client-go one.” The local files ystem has no such alternative — it’s always os.ReadDir. An interface with exactly one possible implementation is just ceremony.

The local side has no Pull/Push of its own. Look at the signatures: Pull(pod, container, remotePath, localPath, ...) and Push(pod, container, localPath, remotePath, ...) — the Kubectl value already straddles both ends; it reads/writes local paths itself (it’s the local tar process in pi pe). So Transfer isn’t really “the remote filesystem” — it’s “the thing that bridges local↔remote.” The only purely-local operation is listing a direc tory, and that’s a one-liner over os.ReadDir. There’s no “local Transfer” concept to even abstract.

That’s the real answer to “are the two sides that different?”: for browsing, no; for transferring, there is no local side — it’s subsumed into Kubectl.
Two minor warts worth noting in the review

FileInfo/Sort live in the package named after the remote side, yet are used by both. It’s pragmatic (local imports transfer, not vice versa), but it’s why the comment has to keep clarifying “this is also used locally.” If you wanted stricter cohesion you’d hoist FileInfo+Sort into a small shared package (e.g. fileinfo) that both transfer and local import — but that’s arguably over-engineering for two callers.

The ../root-synthesis logic is duplicated — local.go:36-38 vs kubectl.go:139-141. The duplication is justified: local uses filepath (OS separators) and remote uses path (always /, inside a Linux pod), so they can’t trivially share it. But it’s worth a one-line comment on each noting the deliberate split, since they’ll need to stay in sync.

If you want, I can tighten the interface comment to say “the List/Pull/Push method set” instead of “this interface” (to kill the ambiguity you hit), or sketch the fileinfo extraction so you can judge whether it’s worth it. Which direction do you want to take?

I feel like if there are two concerns (transfer and file representation) then the two should be separated. It would make it less weird that local reuses the file representation then

Claude refactors and mentions another issue
Decisions I made

Renamed FileInfo → file.Info. file.FileInfo would stutter; file.Info is the idiomatic Go form. Sort keeps its name (file.Sort). If you’d rather preserve the FileInfo name, say so and I’ll rename — it’s a mechanical change.

Reworded the Transfer doc comment to describe it as a local↔remote bridge (List reads the pod; Pull/Push move trees between pod and disk), which is the accurate framing we landed on in the previous discussion — and it no longer needs to awkwardly disclaim the shared type, since the type now visibl y lives in its own package.

Still untouched (deliberately)
The ../root-synthesis duplication between local.List and parseLS is still there — that’s the filepath-vs-path split we discussed, and it’s ortho gonal to this refactor. file would be the natural home for a shared helper if you ever want to collapse it, but I left it alone since it’d need the sepa rator parameterized. Want me to tackle that too?

I don’t remember discussing filepath-vs-path - what’s that about?

Claude explains the issue and recommends to ignore it
Fair — I overstated it as “discussed.” It was a one-line aside in my earlier review, not something we actually worked through. Here’s what I meant.
It’s about two different standard-library packages in Go:

path — manipulates always-slash-separated paths (/). It’s what you use for URLs and anything that is defined to use forward slashes regardless of the host OS.

path/filepath — manipulates paths using the host OS’s rules: / on Linux/macOS, \ on Windows.

In k8tc the two panels live on different sides of that line:
The local panel walks the filesystem of whatever machine k8tc runs on, so it correctly uses filepath:
That last grep is the clearest illustration: kubectl.go uses both packages, deliberately. The remote (pod) side uses path (lines 141, 149–150) and the local side of the very same transfer uses filepath (lines 158–159).
The reason: a pod is a Linux container, so its filesystem paths are always /-separated, no matter what OS k8tc itself is running on. If you used filepath on a pod path while running k8tc on Windows, you’d get backslash semantics applied to a path that is genuinely slash-based — wrong. So pod paths must go through path; host paths must go through filepath.
Now, the ..-synthesis duplication I flagged. The two snippets are:
// local.go:36 — host filesystem
if filepath.Clean(dir) != string(filepath.Separator) {

// kubectl.go:141 — pod filesystem
if path.Clean(dir) != "/" {
They’re structurally identical (“if this isn’t the root, prepend a .. entry”), but they differ in exactly the two spots where the path-flavor matters:

which Clean — OS-aware vs. always-slash

what counts as root — string(filepath.Separator) (the host’s root) vs. the literal "/" (the pod’s root)

So you can’t just lift the snippet into one shared function and call it from both sides — you’d have to parameterize it with “which path semantics,” e.g. pass in the clean-func and the root sentinel. That’s why I called the duplication “justified”: collapsing it would trade two obvious 3-line blocks for one indirection-laden helper, and arguably make it less clear that one side is host-pathed and the other is pod-pathed.
So nothing for you to do here — I just wanted to flag that the duplication is intentional, not an oversight, in case it caught your eye during review. It’s unrelated to the file extraction we just did.

Hmm to me it sound like local and remote should implement at least Transfer.List (don’t implement, discuss)

Claude suggests different ways to address the issue
Good instinct — and it points at a real seam. Let me lay out the case for and against, because there’s a genuine obstacle that’s worth seeing clearly. First let me confirm one thing the argument hinges on:
Confirmed what I needed: pod/container are set once in New (model.go:66–67) and only ever read after that. They’re session-constant, yet they’re threaded as arguments into every single List/Pull/Push call. That detail is the whole crux of your suggestion. Here’s the discussion.
Your instinct is right — for List specifically
The two operations in Transfer have fundamentally different shapes:

List is symmetric and one-sided: (path) → []file.Info. Both panels do exactly this. There’s nothing pod-specific about the operation itself — “read a directory, give me the entries.”

Pull/Push are asymmetric and two-sided: they move a tree across the local↔pod boundary. There is no “local Pull”; the kubectl process is inherently both ends at once. These genuinely belong only to the bridge.

So Transfer today actually bundles two responsibilities — browsing and moving — and you’ve spotted that browsing is the half that’s symmetric. This is the same kind of cut we just made pulling file out: separate the thing that’s shared from the thing that isn’t.
The obstacle: the signature carries pod/container
Why local can’t satisfy Transfer.List as written:
Kubectl: List(pod, container, path string) ([]file.Info, error)   // 3 path-ish args
local:   List(path string)                 ([]file.Info, error)   // 1
The local side has no pod or container, so it can’t match. But — as the grep above shows — pod/container are session-constant. They don’t need to be per-call args; they’re only per-call because the interface made them so. Bind them once and the signatures converge:
type Lister interface {
    List(path string) ([]file.Info, error)
}
local: a zero-field local.FS{} whose List(path) wraps today’s local.List.

remote: a tiny adapter holding pod/container, whose List(path) calls kubectl.List(pod, container, path).

What it buys, concretely
loadPanel loses its which == focusLocal fork (model.go:108–112):
// before
if which == focusLocal {
    files, err = local.List(p)
} else {
    files, err = t.List(pod, container, p)
}
// after — each Panel owns its own lister
files, err = m.panelPtr(which).lister.List(p)
Each Panel becomes self-sufficient: it knows how to load itself, and the Model stops caring whether a panel is local or remote when listing. That’s a real improvement in the model’s coherence, and it makes test fakes trivial — a Lister fake is one method, versus today’s fakeTransfer that must stub Pull/Push even for a listing test.
Where I’d put the interface
The idiomatic Go move: define Lister in the consumer (ui), not the producer. Then local.FS satisfies it structurally without importing anything, and local stays fully decoupled (no transfer import — which we just worked to remove). The remote adapter can live in ui too. transfer.Transfer keeps List as the backend capability (the future client-go backend must still list), and the adapter just curries pod/container onto it.
Two honest caveats

It doesn’t unify everything. Pull/Push stay asymmetric and the push-vs-pull decision stays in the UI (model.go:289/292). The Lister cut only simplifies browsing. That’s fine — but don’t expect it to collapse the transfer logic.

It doesn’t touch the ../filepath-vs-path duplication. Each side’s List still synthesizes .. its own way. Orthogonal to this.

My recommendation
Worth doing, at the lightweight end: introduce a consumer-side Lister, adapt both sides, give each Panel its own. It’s contained, reversible, and improves the conceptual model.
I’d stop short of the maximal version (ripping pod/container out of the Transfer interface entirely and binding them at Kubectl construction). That’s arguably “more correct” — it’d kill the per-call threading on Pull/Push too — but it turns Kubectl from a reusable engine into a session-scoped object, and the blast radius is much larger for a payoff that’s mostly aesthetic.
The deciding question is really: do you want each Panel to “own how it lists itself”? If yes, the Lister is the clean expression of that. If the 6-line branch in loadPanel doesn’t bother you, the status quo is defensible too — the asymmetry it encodes (only the remote side is swappable) is real.

TBH your “maximal version” sounds more correct. I feel like there are distinct responsibilities. A kubernetes package which wraps around kubectl and handling the tar commands. A ls parser (used probably remotely only). A Transfer manager that implements the push/pull mechanism. And remote/local implementations of the same “virtual” file system list. Would you agree?

Claude comes up with a detailed proposal for what I suggested
Yes — broadly I agree. Those are real, separable responsibilities, and the fact that you can name them this cleanly is a good sign the seams are real and not invented. But I’d refine one of your four boundaries, and in doing so I think the decomposition gets sharper than what you sketched. Let me give you the version I’d actually defend.
The dependency graph I’d aim for
file        Info + Sort                                    (done; depends on nothing)
  ▲   ▲
  │   └──────────────┐
parser              local Lister        kube      ← the swap seam
(ls -la → []Info)   (os.ReadDir)         ▲  ▲
  ▲                                      │  │
  └────── remote Lister ─────────────────┘  │
          (ls via kube + parse)             │
                                  transfer (Pull/Push)
                                  (tar streaming over kube)
file — representation. Done.

kube — the exec/stream primitive: “run this command in this pod/container, give me stdin/stdout/stderr.” Holds the bound pod/container (killing the per-call threading you spotted). Knows nothing about tar, ls, or file.Info.

parser — pure []byte → []file.Info. Remote-only, as you said (locally os.ReadDir already hands back structured entries; nothing to parse).

two Listers — local (os.ReadDir) and remote (kube + parser), both satisfying one List(path) → []file.Info.

transfer — the Pull/Push manager: tar create/extract + the streaming pipe, using kube for the remote endpoint and local exec for the local one.

No cycles, clean DAG. Each node has an independent test story — and notably the tests you already have fall out naturally: parse_test.go (pure parser), and fakeKubectl (which makes the “pod” just the local fs) is really a test of the transfer streaming independent of real k8s.
Where I’d push back: tar does not belong in the kube package
You said the kubernetes package wraps kubectl and the tar commands. I’d split those. Put only the exec/stream primitive in kube; keep tar (createArgs/extractArgs/pipe/classify) in the transfer manager.
The reason is your own swappability rationale. The package doc promises “swap the kubectl implementation for a client-go one without touching the TUI.” The thing that differs between kubectl and client-go is how you exec into a pod and get a byte stream — not tar. tar runs identically either way. So the swap seam is the exec primitive, and it must be tar-agnostic, or every transfer detail leaks across the seam. If kube owns tar, you haven’t isolated the swappable part; you’ve just renamed Kubectl.
The non-obvious consequence — and why this is the version that makes the doc true
Here’s the part I think is the real payoff, and it’s hidden in pipe:
func pipe(src, dst *exec.Cmd, progress func(int64)) error
pipe wires together two *exec.Cmd. That’s fine for kubectl (both endpoints are local processes — kubectl exec … is itself a local process). But client-go does not give you an *exec.Cmd — it gives you a remotecommand executor you hand Stdin/Stdout/Stderr io streams. So today’s Transfer interface claims client-go swappability while its internals (two *exec.Cmd) would actively fight it. The swappability is currently aspirational, not real.
The decomposition you’re proposing fixes exactly that — if the kube seam is expressed as streams (Run(cmd, stdin io.Reader, stdout, stderr io.Writer) error) rather than *exec.Cmd, then pipe connects two stream endpoints, the local tar side is one impl, the pod side is another, and kubectl-vs-client-go becomes a true drop-in. So this isn’t just tidying — it’s the refactor that would make the package doc’s promise honest. That’s the strongest argument for going maximal.
Two cautions

Granularity. Four responsibilities ≠ four packages. The parser is ~45 lines of pure code — I’d keep it as parse.go inside the remote-listing package with its existing test, not a package of its own. A package per function is its own smell. The boundaries that earn a package are file, kube, local, transfer, and the remote side; whether remote-List and Pull/Push are one “pod” package or two is a coin-flip I’d decide on cohesion (I lean: one pod/remote package exposing both, since they share the kube client and the “pod-ness” — but your capability-split is defensible).

Cost is front-loaded in pipe. Everything else (extract kube, bind pod/container, add Listers) is mechanical and low-risk. Re-expressing pipe around streams instead of *exec.Cmd is the one genuinely fiddly change, and it only pays off the day someone actually writes the client-go backend. If that day is hypothetical, you can stop short: extract kube as an *exec.Cmd factory (still removes the threading, still separates concerns) and leave pipe alone. You lose nothing you have today and can tighten the seam later.

So, sequencing
If you want to do this, I’d go in dependency order, each step independently shippable and green:

Extract kube (exec primitive, pod/container bound) — removes the per-call threading.

Introduce the Lister interface + local/remote impls — collapses the loadPanel branch.

Move transfer to Pull/Push-only on top of kube; isolate the parser into the remote lister.

Optional, later: re-express pipe/kube around streams when (if) client-go becomes real.

Net: I agree with your four-way split, with the single amendment that tar lives with transfer, not kube — and the headline is that doing this is what would finally make the “swap to client-go” sentence in the package doc actually true rather than aspirational.
Want me to start at step 1?

I like your analysis and corrections. It seems like a sound plan. Implement the changes fully

The final result was a lot cleaner than the original first version. At the same time, I had gotten a rough overview of the codebase.

As you can see, I often try to give Claude open-ended questions to coax it to “think” through the problem and come up with its own analysis, rather than just asking for a specific change. Only when I am confident that I have understood the issue and solution well enough do I come in with specific guidance. A question: prefix or an explicit discuss, don't code can keep it from jumping to code before the design is clear without having to switch back to planning mode.

The example above also shows the importance of pushing back on the agent’s suggestions when they don’t feel right. Claude often tries to take the lazy way out ;-)

Step n+1: Add Features

With a first prototype and a clearer understanding of the codebase, I can now start adding features. I won’t go through all the details here, but the process is similar to what we did before: identify a feature, discuss it with Claude, and then ask it to implement it.

Currently only a single item can be copied. I would like to be able to mark multiple files or directories and then copy them over. Before the copy starts, a confirmation dialog should be shown. While the copy is running a progress dialog (with abort button) should be shown instead of using the status line for progress tracking. Can you come up with a plan first?

Once a feature is planned and implemented, it’s a good time to review the code again and make more architectural improvements if needed. Repeat until you’re happy.

I usually start a new session for each feature and for each review.

Final Result

The final tool is available at its GitHub repository. Following the commits, you can see the sequence of adding new features and refactorings in between.

The final tool has the following features:

selecting multiple files and directories
copying files and directories
deleting files and directories
creating new directories
confirmation dialogs for copy and delete operations
abortable progress dialog for copy and delete operations

I might add a pod/container selector on startup in the future, but for now it’s doing exactly what I wanted it to do, and the whole process took about four hours of work. Incidentally, writing this blog post took nearly the same amount of time ;-)

Stop Using Conventional Commits - Sumner Evans

Sat, 06 Jun 2026 04:53:43 +0000

You’ve almost certainly encountered Conventional Commits before. It may have reared its ugly head in the changelog of an open source project you’ve used. It may have been the enforced commit format for an open source project you contributed to. A lot of people swear by it. I swear at it.

Even though it is used by a large number of popular open source projects, Conventional Commits is an actively bad standard which encourages focus on the wrong things and fails to deliver on its promises.

Focus Failure

Conventional Commits promises to add semantic meaning to commit messages to aid developers and end-users in understanding the changes made in a commit. However, Conventional Commits fails to do this in spectacular fashion. To demonstrate this, let’s look at the anatomy of a conventional commit. According to the Conventional Commit website commit messages should be formatted as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit’s subject line has a <type> (something like fix, feat, chore, docs, or refactor¹) describing the type of change. Following that, there is an optional scope, and then a description.

This format has a major failing: type is prioritised over scope. This is exactly backwards.

Scope > Type

The scope of a change (the subject of the change) is the most important part of a commit. To demonstrate this, let’s consider why each one of the following stakeholders care about the scope of the change more than the type of the change:

Contributors: when you are a contributor to a project, you often need to read the commit log to identify changes in the codebase relevant to a certain area of the code. There are many reasons for this including:
- Wanting to catch up on what has happened since the last time you contributed.
- Trying to understand where the project’s overall inertia is.
- Looking for commits that might conflict with your in-progress work when pulling or rebasing.
As you read the commit log, you’re looking at what areas were touched. You really do not care about the type of change happening, you care about the scope of the change.
Debuggers: when investigating a bug, you often want to look through the commit log to see what changes might have touched areas related to the component where the bug manifested. Once again, the scope is the most important piece of information. The type of change is entirely useless because bugs can be introduced in any change regardless of type. (I’m sure we’ve all experienced writing a bugfix that caused another bug.)
Incident responders: when production is down, scanning the commit log for changes that were made around the time of the outage is an effective way to identify what areas may be causing the problem. Scope is once again the most important piece of information you can have at this point. For example, if you see a commit related to the auth scope at the tip of the spike of inbound API errors, it’s a likely culprit for the problem. And once again, type is irrelevant because bugs could have been added by any change.

So what does Conventional Commits do? It deprioritises scope so much that it’s optional! Why the hell is scope optional? Having a commit without a scope is like having a sentence without a subject! Then, to add insult to injury, Conventional Commits elevates type to the front of the commit message. Conventional Commits gets the priority of scope and type entirely wrong.

Type is Redundant and Restrictive

You might be thinking “so it may be backwards, but commit type is at least still important, right?” and to that I say “no”. A commit’s description should almost always tell you the type of the change! Consider this commit message as an example:

fix(compiler): prevent namespaced SVG <style> elements from being stripped

Even if you only had the description, it’s obvious that it was a bugfix! Space on the subject line of a commit is already at a premium, wasting characters on the type is not helpful! But it’s often even worse than useless; it’s often restrictive. Take this commit message as an example:

refactor(core): Update webmcp support to use document.modelContext

This commit updated the webmcp functionality in the core component to support both document.modelContext and navigator.modelContext, so was that a bugfix, refactor, or new feature? I would argue it’s all of them! But again, the only thing that really matters is that it was a change to the core/webmcp component.

Conventional Commits fundamentally focuses on the wrong thing (the commit type) and devalues the scope (which is what people actually care about).

Broken Promises

So we have determined that the format of Conventional Commits sucks, but it must provide some benefit. Let’s read the Why Use Conventional Commits section to see if any of the reasons make any sense.

Automatically generating CHANGELOGs.
This is the biggest promise of Conventional Commits: you can run a tool like git-cliff or conventional-changelog to generate a changelog from the commits since your last release. Is this even a good idea? No! The audience of a changelog is entirely different than the audience for a commit log!
A changelog is user-facing, and the user cares about understanding the functional differences between versions. They care about what changed from a business/functional perspective.
A commit log is developer-facing, and the developers care about reading a story of how the codebase has changed over time. They care about what changed from a scope perspective.
As you can see, these are two entirely different grains, and any efforts to combine them result in subpar results. The reasons for this are multiple:
- In any moderately complex project, it takes multiple commits to land any notable feature. The process of landing the feature (as documented by the commit log) is valuable for developers and contributors, but it’s useless for the end-user. The end-user only cares about the new feature, not how it was built!
- As Rich pointed out, reverts are problematic for Conventional Commits. Revert commits are important from a commit log story perspective for developers, but to the end user, a change that is reverted is equivalent to a change not made.
Automatically determining a semantic version bump (based on the types of commits landed).
This sounds nice, but the realities of software engineering often interfere significantly with the viability of accurately accomplishing this task. Consider the following situations:
- Reverts: imagine a situation where the breaking change you introduced was actually so breaking that you have to revert it? Your tooling will pick up a breaking change and increment the major version even though the breakage was actually reverted and there is no breaking change.
- Accidental breakages: maybe the breakage is subtle and you don’t realise a change is a breaking change when you make the change. Only in retrospect realise that it’s breaking. You will incorrectly increment a minor/patch version when a major version bump is necessary.
- Retroactive unbreakages: say you later add a commit which, in composition with a previously breaking commit, results in a diff which is not breaking. Similar to the revert situation, tooling would incorrectly identify a breaking change.
In such situations, you could rewrite history with a rebase, but that often breaks or is prevented by workflows. It also presents a revisionist history to the contributors trying to contribute to the project, reducing the reliability of the story the commit log is telling.
Communicating the nature of changes to teammates, the public, and other stakeholders.
As we have established up to this point, teammates and the public have very different needs from a changelog and commit log. Conventional Commits manages to solve neither.
Triggering build and publish processes.
This is just a bad idea. Say you only run automated security checks on commits that touch code and then someone creates a Trojan-horse commit titled docs: fix typos which actually introduces vulnerabilities into the authentication subsystem? Obviously, that sort of malicious activity would hopefully be caught in code review, but the automated tooling is bypassed, putting the onus on a human to identify the problem.
Compute is cheap, just use git diff to identify changed files (scope, once again) and run build/publish processes based on that.
Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
More structured, sure. Making it easier to contribute? Not at all (as we have already demonstrated at length).

Not a single one of the “selling points” for Conventional Commits actually holds water.

Conventional Commits is also extremely difficult to apply to a project. You are supposed to define your own set of “types”, but pretty much everyone just takes the defaults from commitlint which often don’t fit well with the particulars of individual projects. This problem is especially acute in corporate environments where change management and audit requirements often mandate a ticket number in every commit message. The <scope> field is the obvious place to put it, but this ends up replacing the only useful metadata in a Conventional Commit with a completely useless ticket number.

A Better Way

So what should you do instead? Follow the lead of truly successful software projects like Linux, FreeBSD, Git, Go, and NixOS! What do these projects have in common? They all use scope-prefixed commit messages (where “scope” is defined to be relevant to the actual project). Usually, the scope to use on a given project is self-evident. For the Linux kernel, the subsystem is the natural scope. For Go projects, the package path is the natural scope. For a project using a microservice architecture, the microservice name is the natural scope.

Here are some examples of projects and their commit format guidelines.

Project	Format	Example
Linux	`subsystem: description`	`i2c: virtio: mark device ready before registering the adapter`
FreeBSD	`prefix: Description`	`linuxulator: Return EINVAL for invalid inotify flags`
Git	`area: description`	`gitlab-ci: update macOS image`
Go	`package: description`	`net/http/cookiejar: add godoc links`
nixpkgs	`pkg-name: description`	`xwayland: 24.1.11 -> 24.1.12`
Node.js	`subsystem: description`	`stream: fast-path stateless transform flush results`

Unfortunately, despite being used by some of the most successful open source projects ever created, this commit style seems to have lost the branding war. I intend to change that. Introducing scopedcommits.com. The website is dedicated to advocating for a return to commit message sanity, and separating the concern of changelog generation from commit log management.

Conclusion

Conventional Commits’ purported advantages are actually illusory and the industry has seen no tangible benefit from using it as a standard. However, Conventional Commits unfortunately seems to have become fairly popular in open source projects, and due to this it seems like AIs have a habit of defaulting to using it for commit messages. This has caused propagation of anti-pattern-ridden commit messages across projects.

My goal in this article is to fight against Conventional Commits’ dominance, and demonstrate that there better ways to structure commit messages. But if this article has not convinced you to stop using Conventional Commits, I look forward to the flame war in the comment section.

SpaceX Boersengang – Der groesste Bankraub Geschichte

Mon, 01 Jun 2026 06:58:11 +0000

Diesen Monat geht SpaceX an die Boerse und es wird wohl der groesste Boersengang der Geschichte! Aber nicht nur das..., denn wenn alles glatt laeuft, dann wird dadurch Elon Musk zum ersten Billionaer ueberhaupt.

Was aber noch viel gruseliger ist: Millionen Amerikaner werden SpaceX-Aktionaere – ohne eine einzige Aktie aktiv zu kaufen. Klingt nach einer technologischen Erfolgsgeschichte? Ist es nicht. Es ist die mutmasslich groesste (und am offensten orchestrierte) Vermoegensumverteilung von Kleinanlegern hin zu einer Handvoll Tech-Investoren, die wir je gesehen haben. Und sie ist wohl komplett legal!

SpaceX Börsengang Analyse - Der größte Bankraub der Geschichte!? | MeTacheles Tonspur | Episode 209

Hier 👉 https://t.ly/SpaceXIPO geht es zum wichtigen, begleitenden Artikel zu dieser Spezial-Ausgabe!🚨 SpaceX-Börsengang: Der grösste Bankraub der Geschichte? Wie Musk uns alle abzockt!Der SpaceX-IPO wird der grösste Börsengang aller Zeiten – und laut Sascha Pallenberg auch die offenste…

Der größte Bankraub der Geschichte!?

HIER oder auf das Widget klicken, um zum Podcast zu gelangen

Wenn ihr MeTacheles direkt unterstuetzen wollt, dann "chippt" doch einfach den Gegenwert einer Currywurst (gerne auch vegan) in meine Paypal:

oder meine Wero-Kasse:

MeTacheles funktioniert nicht ohne euch und wenn ihr glaubt, dass dieses Format auch in eurem Netzwerk ankommt, dann teilt es doch genau mit diesem.

Ganz wichtig: Den Podcast koennt ihr hier direkt oben im Browser, aber auch auf diversen Plattformen wie u.a.
Apple - Spotify - Youtube - Amazon oder als RSS-Feed
anhoeren und abonnieren. Gerade Apple & Spotify-Abrufe helfen dem Format, denn dort gibt es entsprechende Rankings!

Disclaimer: Die Nummer hier wird ein wenig umfangreicher... ich denke es ist hinlaenglich bekannt, wie kritisch ich Musks Unternehmungen seit gut 15 Jahren kommentiere... aber die Recherche fuer diese Analyse, die hat auch mich immer und immer wieder dem Kopf schuetteln lassen. Setzt euch nen Bookmark, hoert euch den Podcast an und vielleicht denkt ihr ja darueber nach diesen Artikel mit eurem Netzwerk zu teilen? Ich bin mir sicher, dass der ziemlich gut altern wird!

Gehen wir es an!

1,75 Billionen Dollar fuer eine Raketenfirma

Lasst uns direkt in die Glaswolle der Fantasiebewertungen springen und mit einer Zahl anfangen. 1,75 Billionen Dollar. Das ist die Bewertung, die Elon Musk fuer SpaceX in den Raum gestellt hat... Mehr als Walmart! Mehr als die meisten Volkswirtschaften dieses Planeten. Mehr als ich, der mit einem Jeanssparbuch angefangen hat die Finanzwelt zu erkunden, auch nur ansatzweise begreifen kann!

Ist SpaceX ein echtes Unternehmen? Absolut! Sie schiessen Satelliten in den Himmel. Sie betreiben Starlink mit ueber 10 Millionen Abonnenten in 164 Laendern. Sie sind technisch beeindruckend und.... schliesslichen haben sie ja letztes Jahr rund 19 Milliarden Dollar Umsatz gemacht – das meiste davon mit Starlink und Regierungsauftraegen. Bei einem GAAP-Nettoverlust von 4,94 Milliarden Dollar. Merkt euch die Zahl, wir kommen darauf zurueck!

0:00

/0:24

Powered by US-Taxpayers. Knapp $3 Mrd hat die NASA SpaceX ueberwiesen, dass sie Astronauten auf den Mond bringen. Stattdessen explodieren Starships mit schoener Regelmaessigkeiten und beehren die Oekosysteme unserer Ozeane mit Tonnen an Muell. Die SpaceX-MitarbeiterLinnen finden das offensichtlich richtig gut!

Jetzt zur eigentlichen Kuriositaet. Eine Bewertung an der Boerse ist immer auch eine Wette auf zukuenftige Umsaetze. Die Nummer nennt sich Revenue Multiple oder Price-to-Sales. Bei der SpaceX-Zielbewertung kommen wir auf ein P/S-Verhaeltnis von rund 94 – Jeffrey Kluge von der University of Colorado nennt das in einem SSRN-Papier "historically associated with the peak of the dot-com bubble".

Zum Vergleich: Lockheed Martin handelt bei einem P/S von 1,7. Northrop Grumman bei 1,9. RTX bei 2,9. Das sind die etablierten US-Verteidigungskonzerne mit echten Gewinnen, echten Margen, echten Bilanzen! Bei dieser Groessenordnung gibt es im Defense- und Aerospace-Bereich nichts Vergleichbares. Es gab es nie und ich habe das Gefuehl, dass dies auch so schnell nicht noch einmal vorkommen wird!

Das ist nicht ambitioniert. Das ist nicht visionaer. Das ist – um es mit Robin Wigglesworth von der Financial Times zu sagen – absolut "batshit". Selbst Baillie Gifford, einer der groessten institutionellen Pre-IPO-Investoren von SpaceX, markiert seine eigene Beteiligung konservativ bei einer impliziten Gesamtbewertung von 1,25 Billionen Dollar. Eine halbe Billion unter dem IPO-Ask. Wenn dein eigener Long-Term-Investor 500 Milliarden (abermals: MILLIARDEN!) unter deinem Wunschpreis bilanziert, sollte das zu denken geben.

Aber die Bewertung muss halten. Weil dahinter ein sehr spezifischer Mechanismus steckt und der muss durchgezogen werden, greifen... denn am Ende wollen ja alle fruehen Investor:innen gluecklich sein, oder?

Wie wir hier hingekommen sind

Spult kurz zurueck ins Jahr 2022. Elon Musk sammelt 44 Milliarden Dollar ein und kauft Twitter. Seine Mitfinanziers: Andreessen Horowitz, ein saudischer Prinz, der Mitgruender von Palantir, Jack Dorsey!

Musk benennt Twitter in X um. Innerhalb eines Jahres ist X weniger als die Haelfte des Kaufpreises wert und genau das ist ein Problem!

Danke Elon Musk! Twitter ist der wichtigste Honeypot

Der Verkauf Twitters an Elon Musk hat tatsaechlich mein digitales Leben auf den Kopf gestellt und das alles andere als negativ. Und genau dafuer moechte ich mich einmal ausfuehrlich bedanken!

MeTachelesSascha Pallenberg

Aber dann kommt aus heiterem Himmel die Loesung: KI ist der naechste heisse Scheiss und Musk hat hat ja eine KI-Firma, also fusioniert er X mit xAI! Kein Cash wechselt den Besitzer. Die X-Investoren bekommen xAI-Aktien. Problem geloest!

Naechstes Problem: xAI ist eine der groessten Geldverbrennungs-Maschinen der westlichen Hemisphaere und zerballert nach Schaetzungen ueber eine Milliarde pro Monat. xAI-CapEx 2025 allein: 12,7 Milliarden Dollar – mehr als Starlink und das SpaceX Launch-Geschaeft zusammen!

xAI verbrennt $1 Mrd/Monat fuer ueberschaubare Marktanteile von Grok

Loesung Nummer zwei: Musk hat eine Raketenfirma! Also nutzt er nun ganz hurtig SpaceX, um xAI zu kaufen. Wieder kein Cash. Drei Firmen, zwei Fusionen, null Dollar tatsaechlich gezahlt. Alle, die damals geholfen haben, Twitter zu uebernehmen, halten jetzt SpaceX-Aktien.

0:00

/0:29

Ich kann mir nicht helfen aber "All-in SpaceX" hat was von "Alles auf Horst!" aus dem Legenden-Film "Bang Boom Bang"

Und dann kommt im Maerz 2026 der eigentliche Knaller: SpaceX nimmt einen 20-Milliarden-Dollar-Bridge-Loan auf, arrangiert von Goldman Sachs, mit Bank of America, Citi, JPMorgan und Morgan Stanley. Effektivverzinsung 4,58 Prozent. Damit werden fuenf Vorgaenger-Fazilitaeten abgeloest – darunter die toxischen Twitter-Junk-Bonds mit bis zu 12,5 Prozent und die xAI-Senior-Secured-Notes. Bezahlt wird der Kredit zwingend aus den IPO-Erloesen!

Was hier passiert ist, lasst euch das auf der Zunge zergehen: Die ehemaligen Twitter-Glaeubiger – angefuehrt von Morgan Stanley, werden de facto durch SpaceX-IPO-Equity ausbezahlt. Musks toxisches Twitter-Schuldenbuch wird ueber drei Umzuege saniert: Twitter wurde X, X wurde xAI, xAI wurde SpaceX. Und SpaceX wird oeffentlich. Mit eurem Geld!

Und SpaceX ist auf einmal nicht mehr nur eine Raketenfirma, die Internet verkauft. SpaceX ist – laut Musk – die Zukunft. Rechenzentren im Weltraum. "Mehr KI in der Umlaufbahn als auf der gesamten Erde zusammen", sagt er. Sehe ich, vielleicht ein bisschen pessimistisch, ein bisschen anders. Aber dazu kommen wir spaeter... zuvor oeffne ich noch die Asservatenkammer dieses Scams und praesentiere Beweisstuecke A und B!

Beweisstueck A: Die Cybertruck-Connection

Wer wissen will, wie Elon Musk heute schon Geld zwischen seinen Firmen verschiebt, muss sich die Cybertruck-Verkaufszahlen anschauen. Nicht die Zahlen, die Tesla im Quartalsbericht praesentiert. Die Zahlen dahinter.

Per S&P Global Mobility und ueberkreuzgeprueft mit den 10-K/A-Filings von Tesla: SpaceX hat allein im vierten Quartal 2025 ganze 1.279 Cybertrucks gekauft. Zusammen mit anderen Musk-Vehikeln waren es 1.339 von insgesamt 7.071 US-registrierten Cybertrucks in diesem Quartal. Das sind 18 bis 19 Prozent aller Cybertruck-Registrierungen, die in Q4 2025 quasi an Musk selbst gingen.

0:00

/0:21

Von SpaceX gekaufte Tesla Cybertrucks

Ohne diese internen Kaeufe waeren Teslas Cybertruck-Registrierungen im Q4 2025 um 51 Prozent year-over-year eingebrochen. Mit ihnen sehen die Zahlen... ja was soll ich sagen? Nicht ganz so katastrophal aus? Ne... es ist der groesste Flop der Automobil-Geschichte. Auch mit den SpaceX-Kaeufen!

Tesla Cybertruck Analyse - Shuttle der Apokalypse *Update

Erste Eindruecke vom Tesla Cybertruck, einem ueber 3t schweren Pickup-Truck, der gefuehlt auch den offiziellen Shuttle Service fuer saemtliche kommenden Mad Max-Filme stellen koennte

MeTachelesSascha Pallenberg

Aber es kommt noch besser, denn Morningstar-Analyst Seth Goldstein hat herausgearbeitet, dass SpaceX die Cybertrucks zum vollen Listenpreis gekauft hat. "Suggested Retail Price". Konzerngrosskunden bekommen normalerweise Mengenrabatte. Wenn euer Mittelstaendler 100 Firmenwagen bei VW bestellt, bekommt er einen Rabatt. SpaceX kauft 1.279 Cybertrucks – und zahlt den vollen Listenpreis. Hey... why not? Bleibt doch eh in der Familie, oder?

Ich finde da faellt es ja schon fast kaum noch ins Gewicht, dass auch das Pentagon ein wenig tiefer in die Tasche greifen muss:

SpaceX reportedly pressured the Pentagon into paying more for Starlink access - Engadget

SpaceX is reportedly jacking up Starlink prices for the Pentagon.

EngadgetWill Shanklin

Um das mal fuer das Geschaeftsjahr 2025 zusammenzufassen: SpaceX und xAI zusammen kauften Goods und Services bei Tesla im Wert von rund 650 Millionen Dollar. Davon allein $506 Millionen Megapack-Batteriesysteme fuer Colossus umd $131 Millionen Cybertrucks. Das ist eine direkte Vermoegensuebertragung von SpaceX-Aktionaeren an Tesla-Aktionaere – beide Firmen kontrolliert von derselben Person und wenn ihr mich fragt... ich bin mir ziemlich sicher, dass die SpaceX-Aktionaere davon erstmal nichts wussten... und sich die von Tesla nun freuen 🚀

Und jetzt die Frage, die jeder kuenftige SpaceX-Aktionaer sich stellen sollte: Wenn Musk schon vor dem IPO SpaceX nutzt, um Tesla-Quartalszahlen aufzuhuebschen – was glaubt ihr, passiert nach dem IPO mit eurem Geld? Vor allen Dingen der ehemalige Branchen-Primus mal wieder schwaechelt? Wenn ein xAI-Vertrag platzt? Wenn X mal wieder Werbeeinnahmen verliert?

Texas, wo SpaceX inzwischen inkorporiert ist, hat 2024 ein Gesetz erlassen, das Klagen gegen das Management praktisch unmoeglich macht! Mehr dazu spaeter. Aber merkt euch: Die Mechanik des Geld-Hin-und-Her-Schiebens ist nicht hypothetisch. Sie laeuft schon. Sie ist offen in den SEC-Filings dokumentiert. Und nach dem IPO werdet ihr daran beteiligt sein. Ist das alles neu? Nein, so hat Musk bereits vor 10 Jahren Solar City gerettet und den Tesla-Aktionaeren aufgedrueckt... uebrigens, Tesla verkauft inzwischen keine Solardaecher mehr!

Chanos: ‘Brazen’ SolarCity deal is ‘corporate governance at its worst’

High-profile investment manager Jim Chanos blasted Tesla’s proposed acquisition of SolarCity on Wednesday.

CNBCTed Kemp and Scott Wapner

Beweisstueck B: Der Anthropic-Deal und die Maerchenstunde mit den Orbital-Datacentern

Jetzt zum zweiten Beweisstueck. Das ist subtiler, aber meines Erachtens noch entlarvender... also Hyperloop/Neuralink-Level entlarvender!

Im S-1 wird erstmals ein Vertrag offengelegt, von dem die meisten Beobachter bisher nichts wussten: Anthropic zahlt 1,25 Milliarden Dollar pro Monat an SpaceX/xAI fuer den Zugang zu Colossus 1, dem KI-Rechenzentrum in Memphis mit ueber 220.000 Nvidia-GPUs. Der Vertrag laeuft bis Mai 2029, mit einem potenziellen Gesamtvolumen von ueber 40 Milliarden Dollar. Das ist – haltet euch fest – fast so viel wie der gesamte SpaceX-Konzernumsatz aus dem letzten Jahr. Wohlgemerkt pro Jahr und wohlgemerkt durch einen Wettbewerber von xAI!

Anthropic kauft also praktisch die gesamten 300 Megawatt Rechenkapazitaet von Colossus 1 auf. Warum? Weil xAI selbst die eigenen Rechenzentren nicht voll auslastet. Grok hat zwar 64 Millionen monatliche Nutzer, aber nur 1,9 Millionen zahlende Abonnenten. Das Geschaeft ist da, aber es ist nicht gross genug, um die Compute-Kapazitaet zu rechtfertigen, die Musk gebaut hat. Es ist einfach nur absurd und wenn man dann noch bedenkt, dass ja jetzt Colussus 2 gebaut wird... oh well:

Lasst das mal sacken. Musk hat sich jahrelang vor jedes Mikrofon gestellt und erklaert, wie kritisch GPU-Kapazitaet fuer die KI-Zukunft sei. Wie xAI nur dann mit OpenAI und Anthropic mithalten koenne, wenn es ueber genug Compute verfuege. Memphis war das groesste GPU-Cluster der Welt. Und jetzt – Plot Twist – vermietet er es an den Wettbewerber. Weil er es selbst nicht braucht oder vielleicht nicht allein fuer die unvergleichbare Umweltbelastung gelten moechte:

xAI built an illegal power plant to power its data center

This article was updated April, 14, 2026 to reflect new litigation. Just south of the Tennessee-Mississippi state line sits dozens of unpermitted gas turbines that power xAI’s Colossus 2 data center while releasing smog-forming pollution, soot, and hazardous chemicals like formaldehyde. The tech company set up the de facto power plant with no permits, no public input, […]

Southern Environmental Law CenterEric Hilt

Aber zurueck zu Musk und seinem AI-Irrsinn, denn auf der Buehne des World Economic Forum in Davos erklaerte er: KI-Rechenzentren im Weltraum seien ein "no-brainer". Orbital AI Compute. Mehr Rechenleistung in der Umlaufbahn als auf der gesamten Erde. Das sei die Zukunft!

Das Interview in Davos fuehrte Blackrock CEO Larry Fink. Blackrock hat einen Anteil an Tesla von um die 5% (Wert ca. $85 Mrd.) und ist bei SpaceX (Pre IPO) mit 300 Millionen eingestiegen. Mit dem SpaceX IPO plant man weitere $5-10 Mrd. zu investieren!

Wartet kurz. Wenn xAI seine irdischen Rechenzentren schon nicht voll auslasten kann – warum braucht es dann ueberhaupt welche im Orbit?

Die Antwort steht im S-1. Im Risk-Factor-Abschnitt. Im selben Dokument, das die Investoren ueberzeugen soll. Heisst also: Im SEC-Pflichttext, fuer den Musk persoenlich haftet, beschreibt SpaceX dieselbe Orbital-AI-Initiative woertlich als: "in early stages, involve significant technical complexity and unproven technologies, and may not achieve commercial viability".

Auf der WEF-Buehne: "no-brainer". Im SEC-Filing: "may not achieve commercial viability". Es ist eine so unfassbare Clownshow!

Bonus-Rant: Orbitale Rechenzentren (anklicken!)

Den Kern des IPO-Pitches bildet eine Vision, die ich euch nicht vorenthalten moechte: SpaceX will eine Million Satelliten starten, die als orbitale Rechenzentren direkt Solarenergie im All nutzen.

Die Logik: Terrestrische Rechenzentren stossen an Grenzen bei Land, Energie und Kuehlung. Also bauen wir sie im All.

Klingt doch logisch, oder? Jaaaaa... ne, nicht wirklich!

Kuehlung im Vakuum funktioniert nicht wie auf der Erde — kein Luftstrom, keine Konvektion, nur Infrarotstrahlung ueber riesige Radiatoren. Ein Startup hat vor Kurzem einen Satelliten in der Groesse eines kleinen Kuehlschranks mit einem einzigen Nvidia-H100-Chip gestartet. Der Chip konnte ein kleines KI-Modell trainieren — musste aber regelmaessig abschalten, weil er ueberhitzte. Fuer die naechste Version plant das Unternehmen das zweitgroesste Kuehlradiator-Array im All. Das groesste ist uebrigens auf der Internationalen Raumstation. Nur damit die Groesenordnung dieses Bullshitting klar wird!

Fuer die von Musk angesprochene Gigawatt-Kapazitaet wuerden Solar- und Kuehlungsarrays von rund vier Kilometern Laenge benoetigt. Das entspricht etwa 40 Fussballfeldern — fragil, im Weg von Weltraumschrott und extrem teuer im Betrieb.

Und dann ist da noch Starship. Das gesamte Geschaeftsmodell basiert auf einem Startet-im-Stundentakt, mit 200 Tonnen Nutzlast pro Flug. Aktuell ist Starship noch in der Phase, die SpaceX intern als "Rapid Unscheduled Disassembly" bezeichnet. Auf Deutsch: Es explodiert noch gelegentlich.

Als Bonus hat Musk eine Mondfabrik vorgeschlagen, die Satelliten per elektromagnetischem Maschinengewehr ins All schiesst. Die US Navy hat 16 Jahre und 500 Millionen Dollar in genau diese Technologie investiert — ohne Erfolg. Aber vielleicht klappt es ja im Weltraum besser 🤡

Sam Altman, immerhin Chef von OpenAI, hat es auf einer Konferenz in Neu-Delhi unverbluemter formuliert: "I honestly think the idea with the current landscape of putting data centers in space is ridiculous." Orbital-Datacenter wuerden in diesem Jahrzehnt nicht im relevanten Massstab existieren. Selbst Google rechnet damit, dass kommerzielle Orbital-Compute erst Mitte der 2030er Jahre sinnvoll werde – wenn die Launch-Kosten unter 200 Dollar pro Kilogramm fallen.

Uebrigens... da haette ich noch ein Schmankerl:

Musk predicts more AI capacity will be in orbit than on earth in 5 years, with SpaceX becoming a ‘hyper-hyper’ scaler | Fortune

Musk said getting all that AI and solar capacity in space will require about 10,000 launches a year—or a launch in less than an hour every day.

FortuneJason Ma

Musk said getting all that AI and solar capacity in space will require about 10,000 launches a year—or a launch in less than an hour every day. SpaceX is the most prolific rocket company and set a record last year with 165 orbital launches.
SpaceX could pull off a 10,000-per-year launch cadence with 20 to 30 Starship rockets, he added, though the company will make more than that, enabling perhaps 20,000 to 30,000 launches a year.

Alle 60 Minuten einen Start der Starship Rakete ist ziemlich sportlich fuer eine Company, die alle paar Monate mal eine dieser Dinger explodieren laesst!

Ihr merkt es sicherlich schon... die "Orbital-AI"-Story ist keine technische Vision. Sie ist ein Bewertungs-Artefakt. Sie muss da sein, weil sonst die Luecke zwischen 19 Milliarden Umsatz und 1,75 Billionen Bewertung nicht zu fuellen ist. Matt Levine von Bloomberg hat es boese pointiert: SpaceX schreibt im S-1, man habe "the largest actionable total addressable market in human history" identifiziert. Levines Kommentar: "The upper bound on SpaceX's TAM is the gross domestic product of the universe."

Und es kommt noch hirnrissiger. Anthropic ist der direkte Konkurrent von xAI. Im KI-Geschaeft kaempfen beide um dieselben Enterprise-Kunden. Aber Anthropic finanziert mit seinen Compute-Zahlungen jetzt SpaceX! Uuuuuuuund..... die koennen kuendigen und das mit einer nur 90 taegigen Frist.

Heisst also: Falls es zu einem Bruch zwischen Musk und Anthropic kommt – oder ein anderer Konflikt aufpoppt – verliert SpaceX mit drei Monaten Vorwarnung rund 15 Milliarden Dollar Jahresumsatz.

Das ist kein robustes Geschaeftsmodell. Das ist eine spektakulaer hochbewertete Wette darauf, dass Anthropic Compute kauft und niemand ueber das Vertragskleingedruckte spricht.

Das Grundprinzip des Schemas: Indexfonds

Ok, wir atmen mal kurz ein wenig ruhig und sammeln uns wieder... ich weiss, dass das nicht einfach ist und ich muss euch jetzt schon einmal enttaeuschen: es wird nicht besser!

Bis hier hin habt ihr zwei Dinge gesehen: Erstens, wie Musk schon heute Geld zwischen seinen Firmen verschiebt. Zweitens, wie er die Story konstruiert, die die Bewertung tragen muss. Jetzt kommt das eigentliche Geschaeftsmodell des IPOs. Und dafuer muesst ihr verstehen, was Indexfonds sind... halt nicht nur das, vor allen Dingen auch, warum sie so erfolgreich wurden. Also mal kurz und knapp zusammengefasst:

Ein Index ist eine Liste. Jemand entscheidet, welche Firmen draufkommen. Ein Fonds ist ein Korb. Jemand baut den Fonds so, dass er die Liste spiegelt. Wird eine Firma in den Index aufgenommen, muss jeder Fonds, der den Index nachbildet, Aktien dieser Firma kaufen. Nicht, weil sie denken, das sei eine gute Investition. Sondern weil die Regeln das vorschreiben!

Indexfonds sind eine der seltenen Erfindungen der Finanzbranche, die Kleinanlegerinnen und Kleinanleger wirklich reicher gemacht haben. Sie haben aktive Fondsmanager in jedem Markt, in jedem Land, ueber jeden Zeitraum, geschlagen! Fast ein Drittel des amerikanischen Aktienvermoegens ist in Indexfonds gebunden. Die meisten amerikanischen Rentenkonten ebenfalls.

Einer der populaersten Indizes ist der Nasdaq-100. Die 100 groessten nicht-finanziellen Aktien an der Nasdaq. Und nach den bisherigen Regeln war SpaceX dafuer nicht qualifiziert. Neue Firmen mussten bis zu einem Jahr warten. Das nennt sich "Seasoning" – die Aktie muss eine Weile oeffentlich gehandelt werden, damit der Markt versteht, was sie eigentlich wert ist.

Und genau diese Regel hat die Nasdaq in diesem Fruehjahr einfach mal geaendert.

Die Regelaenderung, die alles ermoeglicht

Im Maerz 2026 hat die Nasdaq eine neue "Fast Entry"-Regel eingefuehrt. Wenn ein riesiges Unternehmen an die Boerse geht, kommt es in 15 Handelstagen in den Index. Kein Seasoning. Keine Wartezeit. Zusaetzlich wurde die 10-Prozent-Free-Float-Mindesthuerde abgeschafft und ein 3-fach-Multiplikator fuer kleine Floats eingebaut. Es gab eine oeffentliche Kommentierungsphase. Die Wall Street war dafuer. Die einzigen Gegner waren – Ueberraschung – Kleinanleger.

Jeffrey Kluge nennt die Regelaenderung in seinem SSRN-Papier von April 2026 einen "bespoke red carpet" – einen massgeschneiderten roten Teppich – fuer SpaceX. Aber die Regelaenderung ist nicht das Ziel. Das Ziel ist, was die Regelaenderung ermoeglicht. Und das ist ein vierstufiger Plan.

Stufe 1: Kuenstliche Knappheit. Bei einem normalen IPO werden 15 bis 20 Prozent der Aktien an der Boerse angeboten. SpaceX? Weniger als 5 Prozent.

Stufe 2: Hohe Allokation an Kleinanleger. Bei normalen IPOs bekommen institutionelle Investoren – Pensionsfonds, Banken, Versicherungen – etwa 90 Prozent. Privatleute kriegen 10. SpaceX kehrt das teilweise um: 30 Prozent gehen an Kleinanleger ueber Schwab, Fidelity, Robinhood, SoFi und Morgan Stanleys E*TRADE. "Main Street, not Wall Street" lautet die PR-Story. Die Fanboys jubeln und ich glaube Elon Musk noch ein wenig umfangreicher!

Denn was er denen nicht erzaehlt: Wenn ein IPO eine ungewoehnlich hohe Allokation an Kleinanleger macht, ist das normalerweise ein Zeichen dafuer, dass die Profis nicht zu diesem Preis kaufen wollen. Der Preis ist verrueckt. Und wenn du es den Profis nicht verkaufen kannst, verkaufst du es an Leute, die es nicht besser wissen.

Stufe 3: Fast Entry in den Nasdaq-100. 15 Handelstage nach dem IPO landet SpaceX im Index. Jeder Indexfonds, der den Nasdaq-100 abbildet, MUSS jetzt SpaceX-Aktien kaufen. Chan Ahn, frueher bei Goldman Sachs und JPMorgan, jetzt CEO bei Tessera, hat das Zwangskaufvolumen in einem Benzinga-Interview im Mai 2026 beziffert: zwischen 22 und 27 Milliarden Dollar an erzwungenen ETF-Kaeufen allein von physisch hinterlegten Indexfonds. Ueber das gesamte Nasdaq-100-Oekosystem inklusive aktiver Benchmark-Mandate koennten es mehr als 60 Milliarden werden. Eine Mauer aus Geld, die kaufen muss, egal zu welchem Preis. Das treibt den Kurs ins Absurde.

Stufe 4: Auszahlung der fruehen Investoren. Es gibt Restriktionen – sogenannte Lock-Up-Perioden. Elon selbst muss laut Prospekt ein Jahr warten. Aber die Lock-Up-Struktur fuer andere fruehe Investoren ist ungewoehnlich gestaffelt: 20 Prozent koennen schon nach 70 Tagen verkauft werden, dann 10 Prozent, dann jeweils 7 Prozent in mehreren Tranchen. Wer kauft, waehrend der Preis steigt? Die Rentensparer ueber ihre Indexfonds. Wer verkauft? Die urspruenglichen SpaceX-, Twitter- und xAI-Investoren.

Bag-Holder! Und der Sack heisst Bob, Karen und Mike aus Ohio... ok, ich diversifiziere noch ein wenig: Uschi aus Castrop, Max aus Berlin und Simon aus Taipei sind auch noch mit am Start. Alles selbsternannte Expert:innen, die zwischen Fintech-TikTok und Twitter keine freie Minute mehr finden!

Nasdaq ist hier nicht neutral

Wer glaubt, Nasdaq habe diese Regel einfach so geaendert, weil sich "der Markt weiterentwickelt" – wie es die offizielle Stellungnahme behauptet – der glaubt auch, dass Elon Musk seine Twitter-Investition aus Liebe zur Meinungsfreiheit getaetigt hat.

Der Nasdaq ist zwei Dinge in einer Firma: Er ist ein Indexanbieter UND eine Boerse. Diese beiden Funktionen werden nicht sauber getrennt. Die New York Stock Exchange und Nasdaq konkurrieren um jedes grosse Listing. Und SpaceX war der Preis!

Laut Reuters hat Musk bei der Frage, wo SpaceX gelistet wird, eine Bedingung gestellt: Fast-Track in den Index. Die Nasdaq hat geliefert. Sie verdient an SpaceX nicht nur die Listing-Gebuehren. Das richtig dicke Geld kommt ueber die Daten- und Handelsgebuehren, die sie ueber Jahre an andere Investmentfirmen verkaufen.

Und das Beste: Niemand hat das genehmigt. Die Securities and Exchange Commission, die US-Boersenaufsicht, muss solche Indexaenderungen ueberhaupt nicht absegnen. Mehr als 30 Billionen Dollar Vermoegen werden durch ein System gelenkt, das sich effektiv selbst reguliert. Die einzige Kontrolle ist der interne Kommentierungsprozess des Indexanbieters selbst.

Ja, ihr habt richtig gelesen. Der Indexanbieter prueft seine eigenen Regelaenderungen. Man moechte fast die wilde These in den Ring schmeissen, dass Musk auch noch diesen Laden managed!

Wer das wirklich kontrolliert

Damit kommen wir zur Frage, wer SpaceX nach dem IPO eigentlich gehoert. Spoiler: Im wirtschaftlichen Sinne ein paar Tausend Aktionaere. Im rechtlichen Sinne genau einer Person!

Musk haelt nach Vollzug des IPOs 85,1 Prozent der Stimmrechte – bei einem wirtschaftlichen Anteil von rund 41 bis 42 Prozent. Moeglich macht das eine Dual-Class-Struktur: Class-A-Aktien fuer den Markt mit einer Stimme pro Aktie. Class-B-Aktien fuer Musk mit zehn Stimmen pro Aktie. Im S-1 steht woertlich: "This will limit or preclude your ability to influence corporate matters and the election of our directors." Auf gut Deutsch: Liebe Aktionaere, ihr habt nichts zu melden.

Dazu kommt ein Compensation-Package, das im Januar 2026 beschlossen wurde. Musks Grundgehalt: 54.080 Dollar pro Jahr. Aber er bekommt potenziell eine Milliarde Class-B-Aktien. In 15 Tranchen. Die letzte Tranche wird erst freigegeben, wenn SpaceX eine "permanent human colony on Mars with at least one million inhabitants" etabliert hat. So steht es im SEC-Filing. Eine Million Menschen auf dem Mars. SpaceX' eigene Auditoren stufen das als "improbable" ein – weshalb es bilanziell nicht als Aufwand erfasst wird. Bilanzielle Magie 🦄

Aber der eigentliche Trick: Musk darf bereits vor der Erfuellung dieser Meilensteine mit diesen Aktien abstimmen, sie als Sicherheit fuer Kredite verpfaenden und sie in Trusts mit Super-Voting-Status fuer seine 14-plus Kinder ueberfuehren. Mars-Kolonie oder nicht.

Und falls jemand auf die Idee kommen sollte, Musk dafuer zu verklagen: SpaceX hat sich nach Texas reinkorporiert. Das Texas-Gesetz SB29 erlaubt es boersennotierten Firmen, eine 3-Prozent-Schwelle fuer Derivative Lawsuits zu setzen. Bei 1,75 Billionen Dollar Bewertung entspricht das 52 Milliarden Dollar Aktienbesitz. Praktisch koennen nur Musk, BlackRock und Vanguard ueberhaupt klagen. Anne Lipton von der University of Colorado Law School nennt das "die exotischste Compensation-Konstruktion, die im US-Aktienmarkt je in einer Mega-IPO vorgelegt wurde". Und sie laesst sich praktisch nicht angreifen.

Uebrigens: 2022 entschied der Delaware Court of Chancery im Fall Tornetta v. Musk, dass Musks 56-Milliarden-Dollar-Tesla-Compensation-Package unzulaessig sei. Musks Reaktion: Reinkorporation nach Texas und Wiederholung des Pakets. Die Lektion: Wenn ein Gericht Musk nicht passt, sucht er sich ein anderes Gericht. Das ist die Governance-Realitaet, in die ihr investiert.

0:00

/2:22

Tornetta vs Musk

Und es geht noch weiter: Der S&P macht es nach

Wenn ihr jetzt denkt, das sei ein Einzelfall – nee. Bloomberg berichtet, dass der S&P 500 – der wichtigste Index der Welt – ebenfalls darueber nachdenkt, was Nasdaq gerade durchgezogen hat. Verkuerzte Seasoning-Periode. Aufnahme von Megakonzernen, die noch nie einen Dollar Gewinn gemacht haben.

Warum? Weil OpenAI und Anthropic in den naechsten Monaten an die Boerse gehen koennten. Mit absurden Bewertungen. Keine davon profitabel. Auch hier wird die Kommentierungsphase gerade durchgenudelt. Sie endet Anfang Juni... excuse my French, aber Leckopfanni ist das alles schrill!

Wir reden hier nicht ueber ein technisches Detail im Finanzmarkt-Klein-Klein. Wir reden ueber die Frage, wer in den naechsten Jahren reicher und wer aermer wird. Und die Antwort schreiben sich die grossen Tech-Investoren gerade selbst auf, mit Hilfe der Indexanbieter, die zufaellig auch Boersen sind. Und ohne dass irgendjemand etwas daran genehmigen muss.

Was das mit uns zu tun hat

Ihr fragt euch jetzt vielleicht: Sascha, was geht uns das in Europa an?

Eine ganze Menge. Weil etliche europaeische Anlegerinnen und Anleger – auch wir deutschsprachigen – ueber MSCI World, ueber FTSE All-World, ueber S&P-500-ETFs – in genau diesen Indizes investieren. Wir sind alle drin. Auf die eine oder andere Art. Was hier passiert, das betrifft auch unsere Altersvorsorge und zwar umfangreichst!

Die ETFs, ueber die wir uns Jahre lang die digitalen Patte gerieben haben, weil sie endlich mal nicht die Versicherungs- und Bankprovisionsmuelltonnen waren, werden gerade in eine Goldgrube fuer Silicon-Valley-Investoren umgebaut. Und wir merken es nicht, weil wir – zu Recht – die Idee verinnerlicht haben: Indexfonds sind sicher, passiv, regelbasiert.

Well.... diese Regeln werden gerade umgeschrieben. Vor unseren Augen. Damit Elon Musk Billionaer wird!

Und es kommt noch eine zweite Dimension dazu, die mich als jemanden, der seit ueber 15 Jahren von Taiwan aus auf die digitale Welt schaut, besonders aergert: Starlink und Starshield sind inzwischen kritische westliche Verteidigungsinfrastruktur. Vom ukrainischen Drohnenkrieg bis zur NRO-Spionage. Europa hat mit IRIS2 ein Gegenprojekt – Vollbetrieb fruehestens 2030. Fuenf bis sieben Jahre Rueckstand. Bis dahin sind Bundeswehr, ESA und EU-Sicherheitsarchitektur abhaengig von einer in Texas inkorporierten Privatfirma unter Einzelkontrolle eines Mannes, der 2022 in der Ukraine eigenmaechtig Starlink fuer eine Drohnenoperation abgeschaltet hat!

Und jetzt wird genau diese Firma an die Boerse gebracht – und wir kaufen sie ueber unsere ETFs mit. Das ist nicht nur finanzielle, sondern auch strategische Selbstuntergrabung.

Fazit

Ich bin grundsaetzlich ein Freund davon, dass Menschen sich aktiv an Aktienmaerkten beteiligen. Ich bin grundsaetzlich ein Freund von Indexfonds. Ich rate seit Jahren dazu, weil sie nachweislich besser performen als 99 Prozent der aktiven Fondsmanager.

Aber was hier passiert, ist keine Marktentwicklung. Das ist eine orchestrierte Vermoegensumverteilung. Eric Newcomer und sein Team haben das in ihrer Recherche ausserordentlich gut aufgedroeselt. Ben Schiffrin, 18 Jahre bei der SEC, sagt es selbst: "Ich versuche optimistisch zu bleiben, aber das ist ein Setup fuer ziemlich missbraeuchliche Marktmanipulation. Legal? Wahrscheinlich. Ethisch? Definitiv nicht."

Was ihr tun koennt: Wenn ihr betroffen seid, schaut euch eure ETF-Bestaende an. Lest die Indexregeln. Macht euch klar, dass auch passive Investments politischen Entscheidungen unterworfen sind.

Dieser SpaceX-IPO wird die Boersengeschichte schreiben. Bleibt nur die Frage, auf welcher Seite ihr stehen wollt... und das war hier uebrigens keine Aufforderung dieses Kartenhaus zu shorten!

Dir hat diese Ausgabe gefallen? Dann teile diese doch mit deinem Netzwerk. MeTacheles ist kostenlos, extrem zeitaufwendig & genau deshalb spiele ich jetzt auch ein wenig Staubsaugervertreter 😎

Zum Podcast: Apple - Spotify - Amazon oder RSS-Feed

Bleibt gesund!

Sascha

Disclaimer: Meine Infografiken wurden durch eine KI erstellt, ich frage mich aber wirklich, ob ich dies einzeln angeben muss? Wenn ich was mit Canva mache, dann erklaere ich das ja auch nicht!

Bei der Recherche kam vor allen Dingen Perplexity, aber auch Claude AI zum Einsatz. Der Text wurde jedoch zu 100% von einem in Taiwan lebenden Europaaer mit nem deutschen Pass geschrieben aka mir!

Quellen

Primaerdokument

SpaceX S-1 Filing (SEC, 20.5.2026) – Bewertung, Finanzen, Risikofaktoren, Governance, Related-Party-Transaktionen, Compensation-Package, Mars-Klausel, Orbital-AI-Risk-Disclosure, Anthropic-Compute-Deal, Cybertruck-Kaeufe https://www.sec.gov/Archives/edgar/data/1181412/000162828026036936/spaceexplorationtechnologi.htm

Pressequellen

Reuters – "SpaceX says unproven AI space data centers may not be commercially viable, filing shows" – https://www.reuters.com/world/spacex-says-unproven-ai-space-data-centers-may-not-be-commercially-viable-filing-2026-04-21/
Reuters – "SpaceX posted nearly $5 billion loss in 2025, The Information reports" – Verlustzahlen 2025 https://www.reuters.com/science/spacex-posted-nearly-5-billion-loss-2025-information-reports-2026-04-10/
Fortune – "Rollout complete: SpaceX files IPO prospectus" https://fortune.com/2026/05/21/rollout-complete-spacex-files-ipo-prospectus/
Fortune – "SpaceX IPO targets $28.5 trillion total addressable market" – TAM-Marketing https://fortune.com/2026/05/20/spacex-ipo-filing-s1-total-addressable-market-make-life-multiplanetary/
CNBC – "SpaceX's historic IPO plans: Billions in losses and Musk's massive ownership" – Governance, Voting-Struktur https://www.cnbc.com/2026/05/20/spacex-ipo-live-updates.html
New York Times – "Elon Musk's SpaceX IPO" https://www.nytimes.com/2026/05/20/technology/elon-musk-spacex-ipo.html
TechCrunch – "Anthropic will pay xAI $1.25B per month for compute" (20.5.2026) – Anthropic-Compute-Vertrag https://techcrunch.com/2026/05/20/anthropic-will-pay-xai-1-25-billion-per-month-for-compute/
Axios – "Anthropic is paying SpaceX $15 billion per year" – Annualisiertes Volumen Anthropic-Deal https://www.axios.com/2026/05/20/anthropic-spacex-compute
Tagesschau – "SpaceX Boersengang" – NASDAQ-Index-Regelaenderung aus deutscher Perspektive https://www.tagesschau.de/wirtschaft/unternehmen/spacex-boersengang-100.html
Ars Technica – "As Grok flounders, SpaceX bets future on beating Big Tech at AI" https://arstechnica.com/ai/2026/05/as-grok-flounders-spacex-bets-future-on-beating-big-tech-at-ai/
ComputerBase – "Grok und xAI am Scheideweg: Auf Musks Supercomputer laeuft kuenftig Anthropic Claude" https://www.computerbase.de/news/wirtschaft/grok-und-xai-am-scheideweg-auf-musks-supercomputer-laeuft-kuenftig-anthropic-claude.97240/
Storyboard18 – "Anthropic to pay xAI $1.25 billion a month in massive compute deal" https://www.storyboard18.com/digital/anthropic-to-pay-xai-1-25-billion-a-month-in-massive-compute-deal-ws-l-98757.htm

Ja, es gibt ein Abomodell fuer MeTacheles und ja, 30% der Umsaetze helfen dabei verschieden Baumpflanzprojekte zu unterstuetzen… und verschafft mir mehr Luft, um solche Artikel zu bauen:

Stargate Project Analyse - $500 Mrd fuer die AI-Herrschaft!

Donald Trump, frisch wiedergewaehlter US-Praesident, zieht gleich zu Beginn seiner Amtszeit die ganz grosse Karte: Ein 500-Milliarden-Dollar-Fonds namens „Stargate“. Ziel? Ein landesweites Netzwerk an Rechenzentren fuer kuenstliche Intelligenz aus dem Boden stampfen. Klingt nach Science Fiction, koennte aber die Grundlage fuer Amerikas naechste Tech-Dominanz werden. 💡Aktuelle Ausgaben werden u.a.

MeTachelesSascha Pallenberg

DeepSeek R1 im Faktencheck - AI Hype aus China?!

DeepSeek R1 heisst der neue Hype in der AI-Welt und laesst die Werte der US-Techfirmen an den Boersen abstuerzen. Aber warum eigentlich? Ich erklaere euch in dieser Ausgabe was es damit auf sich hat, warum der Hype und diverse Statements einfach kompletter Quatsch sind, aber auch, warum es sich dabei

MeTachelesSascha Pallenberg

Nachhaltigkeit ist keine Raketenwissenschaft

Weshalb wir die nachhaltige Transformation von Gesellschaft und Industrie nicht verkomplizieren sollten und warum wir bereits alle wichtigen Technologien haben, um uns klimaneutral aufzustellen!

MeTachelesSascha Pallenberg

Bedingungsloses Grundeinkommen - Zukunft oder Utopie?

Warum wir ein bedingungsloses Grundeinkommen brauchen. Ein flammendes Plaedoyer fuer mehr Gerechtigkeit, Sicherheit und Wohlstand fuer alle Gesellschaftsschichten.

MeTachelesSascha Pallenberg

Wenn ihr meint, dass euch dies den Gegenwert eines Kaffees, Kaesekuchens oder ner Currywurst im Monat wert ist, dann koennt ihr entweder » HIER « oder auf den unteren Button klicken und aus den verschiedenen Abo-Modellen waehlen bzw. ihr koenntet ja auch ein Abo verschenken:

Open source was not ready for AI-speed contributions

Sun, 31 May 2026 16:00:42 +0000

If I rent an excavator to dig a hole for a swimming pool, I do not suddenly become a professional.

I become a person with a very powerful tool and a very real chance of making a much bigger mess. I will probably hit something I should not hit. The hole will not be level. The shape will be wrong. And after a few hours of pretending I know what I am doing, someone who actually knows this stuff has to come in and fix my garden. 🙈

That is how I think about AI-assisted software contributions right now.

AI is a tool. A powerful one. In the hands of a good developer, it can amplify output in genuinely useful ways. It can help explore code, write tests, spot patterns, draft boring glue, explain unfamiliar APIs, and remove a lot of friction. I use it that way myself.

But a powerful tool does not replace understanding. It amplifies whatever is already there. If there is judgment, it amplifies judgment. If there is confusion, it amplifies confusion. If there is no ownership, it creates work for someone else.

Open source is now feeling that very hard.

The pull request is not the finish line

I want to be very clear about one thing first: contributions are good. That is the whole point of open source. Someone taking the time to report a bug, improve documentation, fix an integration, or add support for a device is a good thing. A pull request usually means someone cared enough to try.

That part matters. I never want maintainers, including myself, to forget it.

But a contribution is not finished when the pull request is opened. That is where a different kind of work starts. Someone has to understand the change, review the code, check the behavior, think about the edge cases, look at the user impact, verify tests, consider long-term maintenance, and eventually own the result after it is merged.

AI changes the cost of creating the first version. It does not make that second part disappear.

That is the asymmetry we are dealing with. Contributors are being amplified. Maintainers are still the verification bottleneck.

Security is already showing the shape of this

Anthropic published an initial update on Project Glasswing, their effort around AI-assisted vulnerability discovery. The headline number is huge: more than 10,000 high- or critical-severity vulnerabilities found across important software stacks.

That number gets attention, of course. Big numbers always do. But the more interesting line is this one:

“Progress on software security used to be limited by how quickly we could find new vulnerabilities. Now it’s limited by how quickly we can verify, disclose, and patch the large numbers of vulnerabilities found by AI”.

That is the whole problem in one sentence.

Finding work got faster. Verifying work did not become free. Patching did not become instant. Coordinated disclosure did not become easier. Maintainers did not suddenly get more hours in a day.

The open-source part of that update is especially interesting. Anthropic says they scanned more than 1,000 open-source projects and identified thousands of potential high- or critical-severity vulnerabilities. At the time of their update, only a much smaller number had been patched. Some of that is expected because disclosure windows exist, and not every patch is public immediately. Still, the shape is obvious: AI can create a huge amount of legitimate-looking work faster than the ecosystem can absorb it.

And that is with an organized program that includes verification steps. Now imagine the same dynamic spread across normal issue trackers, pull requests, vulnerability reports, and well-meaning contributors who have access to increasingly capable tools.

curl has been living this in public

Daniel Stenberg, a fellow GitHub Star and curl’s long-time maintainer, has written a lot about this from the maintainer side, and I think those posts should be required reading for anyone who thinks this is a simple “AI good” or “AI bad” discussion.

In Death by a thousand slops, he described the flood of low-quality AI-generated security reports hitting curl. The problem was not just that the reports were wrong. The problem was that every report still needed human attention. Security reports cannot simply be ignored because they look annoying. Someone has to check. Someone has to spend the time.

curl eventually ended its bug bounty program. That changed the incentives and reduced the worst of the slop. But then Daniel wrote High-Quality Chaos, which is a much more interesting phase of the story. The obvious junk went down. The quality went up. Almost every report seemed to use AI in some way. The reports were better.

But the volume was still a problem.

That is the part I keep coming back to. Better AI-assisted work is still work. Higher-quality reports are much better than slop, obviously, but they still need triage, discussion, patches, releases, advisories, and judgment.

A few weeks later, Daniel wrote another post with the very direct title The pressure. That one is harder to read because it is not really about tools anymore. It is about people. About work hours, responsibility, health, and a project that is installed almost everywhere trying to keep up with an avalanche of security work. That is the part the “AI found more bugs” headline usually misses. Finding more is only useful if the humans on the other side can still verify, fix, disclose, release, and breathe.

Open source has spent years optimizing for getting more people to contribute. That was the right goal. But now we are entering a phase where “more” is not automatically the answer. We need better paths from contribution to maintainable outcome.

The answer is not banning AI

Some projects have responded by restricting or banning AI-generated contributions. I understand why they get there. When a project is drowning in questionable contributions, the fastest visible lever is to say “no AI”.

NetBSD’s commit guidelines say LLM-generated code is presumed tainted and must not be committed without prior written approval. Gentoo’s AI policy forbids contributions created with the assistance of natural language processing AI tools, citing copyright, ethical, and quality concerns.

Those are not silly concerns. But I do not think trying to detect AI use, police it, and fight contributors over whether a tool touched their work is where open source should spend its limited maintainer energy.

That energy is better spent on the thing we actually need anyway: clear contribution paths, stronger review boundaries, better tests, reproducible reports, smaller changes, and maintainers feeling safe to say “no” when something is not ready.

AI-assisted work is not one thing. A drive-by contributor asking an agent to “fix this issue” and pasting the result is very different from an experienced developer using AI to write tests for code they understand. A security report generated by a model and never verified is very different from a report where the researcher used AI as part of their workflow and then reproduced the issue properly. A maintainer using AI to find repeated review feedback and turn it into a lint rule is different again.

The useful question is not “did AI touch this?”. The useful question is: does the person submitting this understand it, validate it, and take responsibility for it?

That is the professional line. Not whether an excavator was used, but whether the person operating it knows how to dig the hole without destroying the garden.

Home Assistant will likely adopt an AI policy soon as well. Not to ban AI, but to give maintainers the tools and the permission to say “no” when someone shows up after absolutely obliterating their garden with that machinery.

That is the point for me. A policy should not become an AI detector game. It should make the expectations clear: if you submit the work, you own the work.

Still useful machinery. Still capable of making a mess. Photo by Erik Mclean on Unsplash.

Home Assistant is feeling this too

At Home Assistant, we are not watching this from a distance. We are in it.

The number of pull requests is high. The number of merged contributions is high too, and that part is genuinely good news. Every release includes more work from people who cared enough to contribute. New integrations, fixes, cleanups, documentation improvements, tests, translations, small quality-of-life improvements. That is open source working.

But the queue is growing. And that is the hard part.

We are not winning yet.

That does not mean contributions are bad. It means the system around contributions has to evolve. If contributors are amplified, the project needs to amplify the path around them as well: the docs, the checks, the review process, the feedback loops, and yes, the AI instructions that shape what people and agents produce.

This is an important distinction: these improvements do not only help humans. AI uses them too.

When we improve documentation, humans read it, but AI tools also retrieve it, summarize it, and use it as context. When we tune AI instructions because we notice weird repeated patterns, we are not just helping the next person. We are shaping the next generated contribution. When human reviewers keep leaving the same comments, that is a signal. Maybe the documentation is unclear. Maybe a static check should catch it. Maybe a linter rule should exist. Maybe our own tooling needs to become more opinionated.

That is where I think the real adaptation happens.

Not by pretending AI is not part of software development now. Not by accepting every AI-shaped pile of code because “contributions are good”. And not by believing AI review can fully replace human judgment, because verification is the slower, more careful part for a reason.

The path forward is to turn repeated human judgment into better systems.

Maintainers need leverage too

Developers are getting leverage from AI. Maintainers need leverage as well.

Some of that leverage is boring, which usually means it is useful. Better documentation. Clearer contribution guidelines. Stronger tests. More static checks. Linters that encode project-specific expectations. CI that catches common mistakes before a reviewer spends time on them. Templates that ask for the right information. Review tooling that summarizes the risk areas instead of pretending to make the decision.

Some of it can be AI-assisted too. AI can help analyze review history and find repeated patterns. It can help draft documentation for common mistakes. It can suggest where a check might replace a repeated review comment. It can help maintainers navigate a large queue and group similar problems together.

But the goal is not “let AI review AI”. That sounds neat until you remember that review is not only pattern matching. Review is judgment. It is taste. It is understanding the project’s direction. It is knowing why something that works technically may still be wrong for the project.

AI can help prepare the review. It cannot be the maintainer.

That is why I do not think the battle is won by fighting AI. It also will not be won by surrendering to it. Open source has to become more explicit about what good contribution looks like, more automated around the parts that should not require human attention, and more protective of the scarce human judgment that remains.

Open source has to adapt

Open source was not ready for AI-speed contributions. Honestly, I am not sure any of us were.

We built a lot of our workflows around a world where creating a pull request took effort. That effort acted as a filter. Not a perfect one, but a real one. If someone had to understand the code, write the change, run the tests, and explain the result, there was some friction before the maintainer ever saw it.

AI removes a lot of that friction. Sometimes that is wonderful. Sometimes it means a good contributor can do more good work. Sometimes it means a confused contributor can produce a much larger confused contribution. Sometimes it means a maintainer gets a useful report. Sometimes it means they lose an afternoon proving that a confident report is nonsense.

The answer cannot be nostalgia for the old friction. That world is not coming back. The answer is to build better friction in the right places.

Make the easy path the good path. Make the repeated mistakes fail before review. Make the documentation good enough for humans and machines. Make AI instructions part of the project’s contribution surface. Make tooling catch what tooling can catch. Save human attention for the parts that actually need humans.

The best open-source contribution is not the one that arrives fastest. It is the one that can be merged, maintained, and trusted.

AI can help us get there. But only if we stop treating it as magic and start treating it like the excavator it is.

Very useful. Very powerful. Very capable of making a massive hole in the garden.

../Frenck

ripgrep/AI_POLICY.md at master

Thu, 28 May 2026 04:52:21 +0000

AI Policy

Using AI (i.e., LLMs) as tools for coding is welcome. A high bar is held for all contributions to this project. Moreover, the project maintainers remain responsible for any code that is published as part of a release. Contributors are expected to be responsible for any code they publish.

AI should not be used to generate comments when communicating with maintainers. Comments are expected to be written by humans. Comments that are believed to be written by AI may be hidden without notice.

If you are opening an issue, you should be able to describe the problem in your own words.

If you are opening a pull request, you are expected to be able to explain the proposed changes in your own words. This includes the pull request body and responses to questions. Do not copy responses from the AI when replying to questions from maintainers.

This project requires a human in the loop who understands the work produced by AI. Autonomous agents are not allowed to be used for contributing to this project. Pull requests that appear in violation of this will be closed, perhaps without notice.

If you wish to include context from an interaction with AI in your comments, it must be in a quote block (e.g., using >) and disclosed as such. It must be accompanied by human commentary explaining the relevance and implications of the context. Do not share long snippets.

AI is useful when communicating as a non-native English speaker. If you are using AI to edit your comments for this purpose, please take the time to ensure it reflects your own voice and ideas. If using AI for translation, we recommend writing in your native language and including the AI translation in a quote block.

This policy was adapted from uv's AI policy.

Linkblog

Vibe Engineering a Personal Tool

Step 1: Brainstorming

PLAN: k8tc — A Two-Panel TUI for Kubernetes Pod File Transfer

Goal

Non-Goals (v1)

Tech Stack

Architecture

Package layout

Core interface

Transfer Mechanics (the important bit)

Listing remote files

Pull (pod → local), metadata-preserving

Push (local → pod), metadata-preserving

tar flags & ownership

TUI Behavior

Layout

Keybindings

Async transfers

CLI

Error Handling & Edge Cases

Suggested Build Order (milestones)

Acceptance Criteria

Future (post-v1, do not build now)

Step 2: Initial Implementation

Step n: Review

There are two separate things in transfer.go

Why local isn’t behind the interface

Two minor warts worth noting in the review

Decisions I made

Still untouched (deliberately)

Your instinct is right — for List specifically

The obstacle: the signature carries pod/container

What it buys, concretely

Where I’d put the interface

Two honest caveats

My recommendation

The dependency graph I’d aim for

Where I’d push back: tar does not belong in the kube package

The non-obvious consequence — and why this is the version that makes the doc true

Two cautions

So, sequencing

Step n+1: Add Features

Final Result

Stop Using Conventional Commits - Sumner Evans

Focus Failure

Scope > Type

Type is Redundant and Restrictive

Broken Promises

A Better Way

Conclusion

SpaceX Boersengang – Der groesste Bankraub Geschichte

1,75 Billionen Dollar fuer eine Raketenfirma

Wie wir hier hingekommen sind

Beweisstueck A: Die Cybertruck-Connection

Beweisstueck B: Der Anthropic-Deal und die Maerchenstunde mit den Orbital-Datacentern

Bonus-Rant: Orbitale Rechenzentren (anklicken!)

Das Grundprinzip des Schemas: Indexfonds

Die Regelaenderung, die alles ermoeglicht

Nasdaq ist hier nicht neutral

Wer das wirklich kontrolliert

Und es geht noch weiter: Der S&P macht es nach

Was das mit uns zu tun hat

Fazit

Sascha

Quellen

Primaerdokument

Pressequellen

Open source was not ready for AI-speed contributions

The pull request is not the finish line

Security is already showing the shape of this

curl has been living this in public

The answer is not banning AI

Home Assistant is feeling this too

Maintainers need leverage too

Open source has to adapt

ripgrep/AI_POLICY.md at master

AI Policy

PLAN: `k8tc` — A Two-Panel TUI for Kubernetes Pod File Transfer

There are two separate things in `transfer.go`

Your instinct is right — for `List` specifically

The obstacle: the signature carries `pod`/`container`

Where I’d push back: tar does not belong in the `kube` package