I am 32.6% of Tangled
and you can too
joined GitHub in 2010, just a few years post-launch: in the first 0.5% of users. I've used the platform at almost every job since, as well as for all of my personal projects. I've run a fairly large GitHub Actions cluster, have interviewed with the company, even found a bug bounty. Code I wrote on GitHub has been to space:
GitHub always had some issues around poorly thought out APIs, scalability challenges, and more: but they also released a lot of cool features. But Microsoft's acquisition has caused a talent exodus and a crisis of direction and governance. I don't want to get into the specific details, but they've managed to tank the reputation of the world's most significant software developer platform in just a few short years.
I'm pretty resolved that I won't ever use the GitHub platform for anything significant again. Indeed, myself and many of my peers are considering corporate migrations off of GitHub. Never would've considered saying that even a few years ago!
All tangled up
There are a lot of alternative git forges out there: GitLab, Forgejo, I'm sure they're all largely fine. But I'm trying to dogfood and go atproto-native, so for the past few months I've been using @tangled.org for my personal atproto projects.
Tangled
The next-generation social coding platform.
Tangled as a platform has been a delight to develop against. It largely just works, and when something breaks, I can usually fix it myself (don't sleep on having your agents read the open source Tangled implementation code). The team is helpful! The Discord is fun!
I will caution that Tangled is designed around atproto at its core, and that means it's currently best suited for early adopters and other "adventurous" souls, because it has some interesting and unexpected consequences:
- Data is split between your local git repo, your remote PDS, the remote PDSes of other contributors, the remote git server (knot), and the remote indexer and API (which integrates all of these remote sources). A lot is happening under the hood, and you may get more "distributed systems issues" than you'd usually expect from a site.
- Some records are filed against your PDS, even when they relate to someone else's repo. As an example, anyone can open an issue against your repo because they're writing a report about it into their server. ("Deleting" an unwanted issue as a repo owner would necessarily have to be "hiding it".)
- You can self-host most components of the system. Indeed, you can still write many record types even when the Tangled website is down: if the path only uses your PDS, it will still work.
Using atproto to work on atproto
The projects I've been building on Tangled are all atproto-related, and generally lean towards Rust (with a bit of TypeScript), though they're all quite different from each other:
- did.bot, a novel PDS implementation for agentic identities on atproto
- vibescrobble, streaming live agent activity to a clustered view in both browser and MCP
- atgc, a CLI for interacting with Tangled, especially from a large number of concurrent git worktrees + agents
- lance.blue, a way to play BattleTech in a web browser and integrated with atproto
- SDS, a bot for playing BattleTech implemented as a hierarchical decision-making system with an interpretable linear utility model, written in Rust
- substandard: a browser extension for reading more standard.site blogs
You can follow these projects on Tangled, but I've also made Bluesky accounts for them:
@permadeath.com projects
Join the conversation
Impact factor
I'd initially written off coding agents several years ago after they weren't very helpful for my daily workflows. I've kept a close eye on the coding agent space though, in part because I'm responsible for their rollout at my day job:
Article
I heard a lot of noise about step changes in functionality late last year. I started to integrate coding agents into my own personal workflows at the start of this year, but the last few months are where I've really scaled up my approach and dedicated more time to agentic coding projects.
I'd say I've been quite productive:
Actually, as it turns out, my projects represent the majority of current development activity on Tangled and make up about one-third of all commits on Tangled, ever.
The Tangled team has done an amazing job with their platform. I haven't been asked to stop, meaningfully rate limited, accidentally taken down the whole site, or anything like that. They've also been very supportive of my random Discord questions about odd atproto projects. I really look forward to my next projects launching, since they integrate quite closely with the site!
Inside the sausage factory
Now, it's not really the main point of this post, but given that level of activity I think my development environment might surprise some people:
- $20/mo: all AWS resources for these projects
- $200/mo: A Claude Code Max 20x subscription
- $free: VSCode with the Claude Code extension and a couple of other basic linting/highlighting extensions
- $649.99: refurbished ThinkPad T14s Gen 3
- Ubuntu 26.04
- Intel Core i7-1270P + integrated graphics
- 32 GB of RAM
- 512 GB SSD
- It's all propped up on some pillows on my bed. I don't even have a desk or anything. Please donate.
You'll notice that I'm not using any custom harnesses, agentic editors, local models, custom agents, a Mac Mini, remote dev boxes, or anything else like that. I barely even use loops or skills or the Claude CLI.
That's not to say that I'm just using agents like chatbots, though:
- My workflow is heavily multi-repo (lance.blue has 6)
- Each repo has a few coordinator agents, assigned to git worktrees, taking on a couple of related epics.
- Each coordinator agent can launch new subagents+worktrees for specific feature branches.
- I don't let agents commit to main. Instead, they open PR stacks (and Claude Artifacts) that I review and merge.
With this amount of parallelism, plus keeping my laptop running overnight, I can reliably use up my weekly token allowance. My current pace is about 5000 contexts per month:
The Omnijob
While that is a lot of agent-hours, I would not describe any of my projects as "vibecoded", in the sense that I'm not just describing what I want and having the agent do whatever. Almost all code is agent-written, and almost none of the architectural choices are agent-decided. I maintain a lot of control over language, implementation strategy and order, architecture, design goals, and approach to the project.
I may no longer write appreciable amounts of code, but I'm still a very active collaborator with my agents. That looks like:
- Reading architecture proposals before the agent dispatches subagents to work on it
- Correcting agents when they jump to conclusions, don't search deeply enough, or miss "obvious" connections between work
- Cutting off in-flight work to point out missed system invariants and design goals
- Telling agents what prior work to read up on
- Testing out agentic spikes to provide early feedback
- Applying production infra changes on behalf of agents, when I don't trust them with those creds
- Working on blog posts, writing marketing copy, and organizing alpha testers
- Looking at website screenshots and providing design feedback
- Reviewing simulation results to make sure they seem reasonable
- Providing game rules insights that aren't in the agent's training data or easily learnable from black-box testing
- Discussing trade-offs like statistical models, upstream crates, how to handle key material, etc.
This means I'm acting as product manager, project manager, lead architect, security principal, devops engineer, design lead, and marketing department all at the same time. Essentially, I'm a solo founder.
But faster. These job duties are all things I do from time to time, but now there's almost no waiting between crucial decision points.
Frankly, I don't think that most people have the constitution for this working style. It's an enormous amount of thinking. You need to read fast, have a lot of background experience in fairly unrelated domains, keep a lot of control over many moving pieces, and be able to switch contexts quickly. It's harder work than any of my other software projects have been for years.
Recursive self-improvement
I recently dug up one of my old Bluesky posts about LLMs from ~3 years ago:
A lot has changed since then. I now estimate that on a greenfield project where I'm the solo developer, I'm currently at least 100x faster at implementing functionality using agentic development techniques than I would be by hand. (At work, where I'm not quite as parallelized and have to interact with existing codebases and other people more often, it's more like 5x to 10x faster.)
That doesn't necessarily mean I ship 100x as often, or 100x as many apps. A lot of that increase in velocity is directed into quality, polish, and optional features: real value that would've normally been cut for scope. Essentially everything I'm putting out has a ton of integration testing, tooling, and security features. I firmly believe that well-designed agentic codebases are actually better codebases than human-authored ones.
People - usually the kind trying to sell you something - love to say that "code review is the new bottleneck". Based on my experience, I don't believe that at all for a single-person greenfield project.
I've looked at essentially every PR merged over the past month: yes, thousands of them. But these are PRs about features that I asked for, often a single commit of under 100 lines, written in a safe language. They only need a cursory review that often takes less than a minute. So the "bottleneck" we're really talking about is... an hour or two a day.
I don't think that my primary bottleneck to going past 100x is code review, or even cognitive at all. Mainly I think I'd just need to do this full-time with a better setup: more tokens, more compute, a multi-monitor setup, a keyboard and mouse and a chair. I think that would be sufficient to hit about 500x my previous productivity before maintaining direct understanding and oversight of my projects really broke down.
And right now? I can't afford any of that.
There's always a tradeoff
My current workflow is a balance:
Inputs: my free time and attention, my available compute, and my token budget.
Outputs: lines of code produced, product quality
Right now I'm maxing out my hobby-level compute and token budgets, and also spending a lot of attention to ensure that spend leads to high product quality. Focusing on loop engineering would give me back my attention, but at the cost of inefficiency: I would produce both less code and less quality given the same amount of compute and tokens.
Currently I do have the attention to spend, but I'm maxed out on infrastructure. This means that loop-centric development would be a horrible trade-off. It's only when I'm out of attention and have leftover compute/tokens that it would become appealing.
So, if you want to see Part 2 to this blog post where I fuck around with loops? Buy me a new GPU, or a desk, or something. Until then, it's not a fruitful direction to explore.
Until then I'll be continuing development on all of these projects, in parallel. Several are gearing up for their initial releases! I'm especially excited about did.bot and expect to do another blog post about that soon.
Disclaimer
This post was entirely human-written. However, all data collection and graph rendering was performed by Claude Opus 5. Notably, Tangled is essentially a massive distributed system; the best approach was to crawl and then integrate multiple data sources to try and piece together all reachable pull requests, knots, Tangled users, etc. But a consequence is that if you use a different approach you may get quite different answers on network activity!
Did you enjoy this article?
Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.