Microsoft pro­vided the FBI with the re­cov­ery keys to un­lock en­crypted data on the hard dri­ves of three lap­tops as part of a fed­eral in­ves­ti­ga­tion, Forbes re­ported on Friday.

Many mod­ern Windows com­put­ers rely on full-disk en­cryp­tion, called BitLocker, which is en­abled by de­fault. This type of tech­nol­ogy should pre­vent any­one ex­cept the de­vice owner from ac­cess­ing the data if the com­puter is locked and pow­ered off.

But, by de­fault, BitLocker re­cov­ery keys are up­loaded to Microsoft’s cloud, al­low­ing the tech gi­ant — and by ex­ten­sion law en­force­ment — to ac­cess them and use them to de­crypt dri­ves en­crypted with BitLocker, as with the case re­ported by Forbes.

The case in­volved sev­eral peo­ple sus­pected of fraud re­lated to the Pandemic Unemployment Assistance pro­gram in Guam, a U. S. is­land in the Pacific. Local news out­let Pacific Daily News cov­ered the case last year, re­port­ing that a war­rant had been served to Microsoft in re­la­tion to the sus­pects’ hard dri­ves. Kandit News, an­other lo­cal Guam news out­let, also re­ported in October that the FBI re­quested the war­rant six months af­ter seiz­ing the three lap­tops en­crypted with BitLocker.

A spokesper­son for Microsoft did not im­me­di­ately re­spond to a re­quest for com­ment by TechCrunch. Microsoft told Forbes that the com­pany some­times pro­vides BitLocker re­cov­ery keys to au­thor­i­ties, hav­ing re­ceived an av­er­age of 20 such re­quests per year.

Apart from the pri­vacy risks of hand­ing re­cov­ery keys to a com­pany, Johns Hopkins pro­fes­sor and cryp­tog­ra­phy ex­pert Matthew Green raised the po­ten­tial sce­nario where ma­li­cious hack­ers com­pro­mise Microsoft’s cloud in­fra­struc­ture — some­thing that has hap­pened sev­eral times in re­cent years — and get ac­cess to these re­cov­ery keys. The hack­ers would still need phys­i­cal ac­cess to the hard dri­ves to use the stolen re­cov­ery keys.

“It’s 2026 and these con­cerns have been known for years,” Green wrote in a post on Bluesky. “Microsoft’s in­abil­ity to se­cure crit­i­cal cus­tomer keys is start­ing to make it an out­lier from the rest of the in­dus­try.”

The shift is largely due to the rapid ex­pan­sion of so­lar en­ergy, which is grow­ing faster than any other source of elec­tric­ity. Together, wind and so­lar gen­er­ated 30 per­cent of E. U. power last year, while fos­sil fu­els pro­vided 29 per­cent, ac­cord­ing to the analy­sis from Ember, a think tank based in London. Including hy­dro, re­new­ables pro­vided nearly half of all E.U. power in 2025.

Last year, for the first time, wind and so­lar sup­plied more power than fos­sil fu­els to the E. U., ac­cord­ing to a new analy­sis.

The shift is largely due to the rapid ex­pan­sion of so­lar en­ergy, which is grow­ing faster than any other source of elec­tric­ity. Together, wind and so­lar gen­er­ated 30 per­cent of E. U. power last year, while fos­sil fu­els pro­vided 29 per­cent, ac­cord­ing to the analy­sis from Ember, a think tank based in London. Including hy­dro, re­new­ables pro­vided nearly half of all E.U. power in 2025.

Last year, for the first time, wind and so­lar sup­plied more power than fos­sil fu­els to the E. U., ac­cord­ing to a new analy­sis.

The analy­sis finds that so­lar is mak­ing gains in every E. U. coun­try, while coal is broadly in re­treat. Last year, so­lar alone sup­plied more than 20 per­cent of power in Hungary, Cyprus, Greece, Spain, and the Netherlands. Meanwhile, in 19 European coun­tries, coal ac­counted for less than 5 per­cent of power. In 2025, both Ireland and Finland joined the ranks of European coun­tries that have shut­tered their last re­main­ing coal plants.

Warming, how­ever, con­tin­ues to chal­lenge the shift to clean en­ergy as drought saps hy­dropower. Last year, hy­dro out­put dropped slightly in the E. U., and nat­ural gas power rose to com­pen­sate.

“The next pri­or­ity for the E. U. should be to put a se­ri­ous dent in re­liance on ex­pen­sive, im­ported gas,” said Ember an­a­lyst Beatrice Petrovich. “Gas not only makes the E.U. more vul­ner­a­ble to en­ergy black­mail, it’s also dri­ving up prices.”

In parts of Europe, there are signs that in­creas­ingly cheap bat­ter­ies are be­gin­ning to dis­place nat­ural gas in the early evening, when power de­mand is high, but so­lar out­put is wan­ing. Said Petrovich, “As this trend ac­cel­er­ates it could limit how much gas is needed in evening hours, there­fore sta­bi­liz­ing prices.”

An E. U. Plan to Slash Micropollutants in Wastewater Is Under Attack

On January 21, 2026, @fredwilson chal­lenged @seth: AI can write code, but it can’t af­fect the phys­i­cal world. This is our re­sponse. Real corn, grown from seed to har­vest, with every de­ci­sion made by Claude Code.

AI does­n’t need to drive a trac­tor. It needs to or­ches­trate the sys­tems and peo­ple who do. A farm man­ager does­n’t per­son­ally plant every seed. They ag­gre­gate data, make de­ci­sions, co­or­di­nate con­trac­tors. Claude Code be­comes that farm man­ager— 24/7, data-dri­ven, fully doc­u­mented.

The Process — How this was built

Fred processes emails as part of his daily check rou­tine. Priority given to farm­ers and op­er­a­tors.

A pro­ject by @seth, in­spired by @fredwilson, or­ches­trated by Claude Code (Opus 4.5)Want to help? Iowa land leads, ag ex­per­tise, vibe coders wel­come: [email protected]

1. Design and plan­ning be­comes the bot­tle­neck when agents write all the code 2. Buried in the chaos are sketches of fu­ture agent or­ches­tra­tion pat­terns 3. The price is ex­tremely high, but so is the (potential) value 4. Yegge never looks at code. When should we stop look­ing too? Access to feed­back loops and de­f­i­n­i­tions of suc­ces

1. Design and plan­ning be­comes the bot­tle­neck when agents write all the code 2. Buried in the chaos are sketches of fu­ture agent or­ches­tra­tion pat­terns 3. The price is ex­tremely high, but so is the (potential) value 4. Yegge never looks at code. When should we stop look­ing too? Access to feed­back loops and de­f­i­n­i­tions of suc­ces

A few weeks ago Steve Yegge pub­lished an elab­o­rate man­i­festo and guide to Gas Town, his Mad-Max-Slow-Horses-Waterworld-etc-themed agent or­ches­tra­tor that runs dozens of cod­ing agents si­mul­ta­ne­ously in a metaphor­i­cal town of au­to­mated ac­tiv­ity. Gas Town is en­tirely vibecoded, hastily de­signed with off-the-cuff so­lu­tions, and in­ef­fi­ciently burn­ing through thou­sands of dol­lars a month in API costs.

This does­n’t sound promis­ing, but it’s lit di­vi­sive de­bates and sparks of change across the soft­ware en­gi­neer­ing com­mu­nity. A small hype ma­chine has formed around it. It’s made the rounds through every en­gi­neer­ing team’s Slack, prob­a­bly twice. There’s some­how al­ready a $GAS meme coin do­ing over $400k in earn­ings. And the hype is jus­ti­fied. First, be­cause it’s ut­terly un­hinged, and sec­ond be­cause it’s a se­ri­ous in­di­ca­tion of how agents will change the na­ture of soft­ware de­vel­op­ment from this point on.

You should at least skim through Yegge’s orig­i­nal ar­ti­cle be­fore con­tin­u­ing to read my re­flec­tions. First, be­cause I’m not go­ing to com­pre­hen­sively sum­marise it. And sec­ond, be­cause a even a one minute glance over Yegge’s style of writ­ing will make the vibes clear.

We should take Yegge’s cre­ation se­ri­ously not be­cause it’s a se­ri­ous, work­ing tool for to­day’s de­vel­op­ers (it is­n’t). But be­cause it’s a good piece of spec­u­la­tive de­sign fic­tion that asks provoca­tive ques­tions and re­veals the shape of con­straints we’ll face as agen­tic cod­ing sys­tems ma­ture and grow.

“Design fic­tion” or “speculative de­sign” is a branch of de­sign where you cre­at­ing things (objects, pro­to­types, sketches) from a plau­si­ble near fu­ture. Not to pre­dict what’s go­ing to hap­pen, but to pro­voke ques­tions and start con­ver­sa­tions about what could hap­pen. Not in a bright-and-glo­ri­ous-fly­ing-cars way that fu­tur­ism can some­times fall into. But, most help­fully, in a way that thinks about ba­nal de­tails, over­looked every­day in­ter­ac­tions, low sta­tus ob­jects, im­per­fect im­ple­men­ta­tions, knock-on ef­fects, and in­con­ve­niences. See the Near Future Lab’s short ex­plainer video and their Manual of Design Fiction if you want to learn more.

I also think Yegge de­serves praise for ex­er­cis­ing agency and tak­ing a swing at a sys­tem like this, de­spite the in­ef­fi­cien­cies and chaos of this it­er­a­tion. And then run­ning a pub­lic tour of his shitty, quar­ter-built plane while it’s mid-flight.

When I was taken to the Tate Modern as a child I’d point at Mark Rothko pieces and say to my mother “I could do that”, and she would say “yes, but you did­n’t.” Many peo­ple have talked about what large-scale, au­to­mated agent or­ches­tra­tion sys­tems could look like in a few years, and no one else at­tempted to sin­cerely build it.

I should be trans­par­ent and say that I have not used Gas Town in earnest on any se­ri­ous work. I have only lightly poked at it, be­cause I do not qual­ify as a se­ri­ous user when I’m still hov­er­ing around stages 4-6 in Yegge’s 8 lev­els of au­toma­tion:

I cur­rently jug­gle a hand­ful of con­sec­u­tive Claude Code and OpenCode agents, but pay close at­ten­tion to the diffs and reg­u­larly check code in an IDE. Which I guess puts me in the agen­ti­cally con­ser­v­a­tive camp in this dis­tress­ingly break­neck mo­ment in his­tory.

Gas Town is a full-on stage 8 piece of tool­ing: us­ing an or­ches­tra­tor that man­ages dozens+ of other cod­ing agents for you. Yegge also warned me not to se­ri­ously use Gas Town mul­ti­ple times, in in­creas­ingly threat­en­ing ty­pog­ra­phy. I trust his guid­ance on his own slush pile.

But I have grokked the ba­sic con­cepts and spent more time with this man­i­festo than is war­ranted. And here is what stood out to me from the parts I could com­pre­hend:

When you have a fat stack of agents churn­ing through code tasks, de­vel­op­ment time is no longer the bot­tle­neck. Yegge says “Gas Town churns through im­ple­men­ta­tion plans so quickly that you have to do a LOT of de­sign and plan­ning to keep the en­gine fed.” Design be­comes the lim­it­ing fac­tor: imag­in­ing what you want to cre­ate and then fig­ur­ing out all the gnarly lit­tle de­tails re­quired to make your imag­i­na­tion into re­al­ity.

I cer­tainly feel this fric­tion in both my own pro­fes­sional work and per­sonal pro­jects. My de­vel­op­ment ve­loc­ity is far slower than Yegge since I only wran­gle a few agents at a time and keep my eyes and hands on the code. But the build time is rarely what holds me up. It is al­ways the de­sign; how should we ar­chi­tect this? What should this feel like? How should this look? Is that tran­si­tion sub­tle enough? How com­pos­able should this be? Is this the right metaphor?

When it’s not the de­sign, it’s the prod­uct strat­egy and plan­ning; What are the high­est pri­or­ity fea­tures to tackle? Which piece of this should we build first? When do we need to make that de­ci­sion? What’s the next log­i­cal, in­cre­men­tal step we need to make progress here?

These are the kind of de­ci­sions that agents can­not make for you. They re­quire your hu­man con­text, taste, pref­er­ences, and vi­sion.

With agents to hand, it’s easy to get ahead of your­self, stum­bling for­ward into stacks of gen­er­ated func­tions that should never have been prompted into ex­is­tence, be­cause they do not cor­rectly ren­der your in­ten­tions or achieve your goals.

Gas Town seems to be halfway into this pit­fall. The biggest flaw in Yegge’s cre­ation is that it is poorly de­signed. I mean this in the sense that he ab­solutely did not de­sign the shape of this sys­tem ahead of time, thought­fully con­sid­er­ing which metaphors and prim­i­tives would make this ef­fec­tive, ef­fi­cient, easy to use, and com­pre­hen­si­ble.

He just made stuff up as he went. He says as much him­self: “Gas Town is com­pli­cated. Not be­cause I wanted it to be, but be­cause I had to keep adding com­po­nents un­til it was a self-sus­tain­ing ma­chine.” Gas Town is com­posed of “especially dif­fi­cult [theories] be­cause it’s a bunch of bull­shit I pulled out of my arse over the past 3 weeks, and I named it af­ter bad­gers and stuff.” It was slap­dashed to­gether over “17 days, 75k lines of code, 2000 com­mits. It fi­nally got off the ground (GUPP started work­ing) just 2 days ago.”

This Hacker News com­ment from qc­n­guy de­scribes the prob­lem well, and points out that Yegge’s pre­vi­ous Beads pro­ject, of which Gas Town is an ex­ten­sion, suf­fers the same is­sue:

“Beads is a good idea with a bad im­ple­men­ta­tion. It’s not a de­signed prod­uct in the sense we are used to, it’s more like a stream of con­scious­ness con­verted di­rectly into code. It’s a pro­gram that is­n’t only vibe coded, it was vibe de­signed too.”

“Gas Town is clearly the same thing mul­ti­plied by ten thou­sand. The num­ber of over­lap­ping and ad hoc con­cepts in this de­sign is over­whelm­ing. Steve is ahead of his time but we aren’t go­ing to end up us­ing this stuff. Instead a few of the core in­sights will get in­cor­po­rated into other agents in a sim­pler but no less ef­fec­tive way.”

Or this re­view from as­trra.space on Bluesky:

“gas town [is] such a night­mare to use i love it… the mayor is dumb as rocks the wit­ness reg­u­larly for­gets to look at stuff the dea­con makes his own rules the crew have the ob­ject per­ma­nence of a tank full of gold­fish and the pole­cats seem in­tent on wreak­ing as much chaos on the pro­ject as they can. this is peak en­ter­tain­ment i swear”

Friends and col­leagues of mine who have been brave enough to try out Gas Town in more depth re­port the same thing; this thing fits the shape of Yegge’s brain and no one else’s. I’d cat­e­gorise that as a mod­er­ate de­sign fail, given this is a pub­lic prod­uct that I as­sume Yegge wants at least some peo­ple to try out. The on­board­ing is bap­tism by fire.

This feels like one of the most crit­i­cal, emerg­ing foot­guns of lib­er­ally hands-off agen­tic de­vel­op­ment. You can move so fast you never stop to think. It is so easy to prompt, you don’t fully con­sider what you’re build­ing at each step of the process. It is only once you are hip-deep in poor ar­chi­tec­tural de­ci­sions, in­scrutable bugs, and a fuzzy mem­ory of what you set out to do, do you re­alise you have burned a bil­lion to­kens in ex­change for a pile of hot trash.

Now that I’ve just cri­tiqued the de­sign of Gas Town, I will turn around and say that while the cur­rent amal­ga­ma­tion of pole­cats, con­voys, dea­cons, mol­e­cules, pro­to­mol­e­cules, may­ors, seances, hooks, beads, wit­nesses, wisps, rigs, re­finer­ies, and dogs is a bunch of un­der cooked spaghetti, Yegge’s pat­terns roughly sketch out some use­ful con­cep­tual shapes for fu­ture agen­tic sys­tems.

If you step back and squint, this mish­mash of con­cepts re­veals a few un­der­ly­ing pat­terns that fu­ture agen­tic sys­tems will likely fol­low:

Every agent in Gas Town has a per­ma­nent, spe­cialised role. When an agent spins up a new ses­sion, it knows who it is and what job it needs to do. Some ex­am­ples:

* The Mayor is the hu­man concierge: it’s the main agent you talk to. It talks to all the other agents for you, kick­ing off work, re­ceiv­ing no­ti­fi­ca­tions when things fin­ish, and man­ag­ing the flow of pro­duc­tion.

* Polecats are tem­po­rary grunt work­ers. They com­plete sin­gle, iso­lated tasks, then dis­ap­pear af­ter sub­mit­ting their work to be merged.

* The Witness su­per­vises the Polecats and helps them get un­stuck. Its job is to solve prob­lems and nudge the pro­le­tariat work­ers along.

* The Refinery man­ages the merge queue into the main branch. It eval­u­ates each piece of work wait­ing to be merged, re­solv­ing con­flicts in the process. It can cre­atively “re-imagine” im­ple­men­ta­tions if merge con­flicts get too hairy, while try­ing to keep the in­tent of the orig­i­nal work.

There are many more char­ac­ters in this town, but these give you a flavour of the sys­tem. Giving each agent a sin­gle job means you can prompt them more pre­cisely, limit what they’re al­lowed to touch, and run lots of them at once with­out them step­ping on each oth­er’s toes.

There’s also a clear chain of com­mand be­tween these agents. You talk to the Mayor, who co­or­di­nates work across the sys­tem. The Mayor in Gas Town never writes code. It talks to you, then cre­ates work tasks and as­signs them to work­ers. A set of sys­tem su­per­vi­sors called the Witness, the Deacon, and “Boot the Dog” in­ter­mit­tently nudge the grunt work­ers and each other to check every­one is do­ing their work. Oh and there’s also a crew of “dogs” who do main­te­nance and clean­ing.

It’s eas­ier if I try and show you. Here’s the ba­sic re­la­tion­ship struc­ture of Gas Town, as best I can make out:

Since I’m mak­ing my own vi­su­als here, I should jus­tify it by point­ing out that while Yegge made lots of his own or­nate, zoop­mor­phic di­a­grams of Gas Town’s ar­chi­tec­ture and work­flows, they are un­help­ful. Primarily be­cause they were made en­tirely by Gemini’s Nano Banana  . And while Nano Banana is state-of-the-art at mak­ing di­a­grams, gen­er­a­tive AI sys­tems are still re­ally shit at mak­ing il­lus­tra­tive di­a­grams. They are very hard to de­ci­pher, filled with clut­tered de­tails, have ar­rows point­ing the wrong di­rec­tion, and are of­ten miss­ing key in­for­ma­tion. Case in point:

Does this help you un­der­stand how the sys­tem works? No? No.

Gas Town’s hi­er­ar­chi­cal ap­proach solves both a co­or­di­na­tion and at­ten­tion prob­lem. Without it, you are the one as­sign­ing tasks to dozens in­di­vid­ual agents, check­ing who’s stuck, who’s idle, and who’s wait­ing on work from some­one else. With the Mayor as your sin­gle in­ter­face, that over­head dis­ap­pears. You can con­tin­u­ously talk to the Mayor with­out in­ter­rupt­ing any agents or get­ting in the way, or hav­ing to think much about which one is do­ing what. This is less cog­ni­tive over­head than con­stantly switch­ing tabs be­tween Claudes.

I think there’s a lot of op­por­tu­nity to di­ver­sify the cast of char­ac­ters here and make more use of spe­cial­ist sub­agents  . The agents in Gas Town are all gen­er­al­ist work­ers in the soft­ware de­vel­op­ment pipeline. But we could add in any kind of spe­cial­ist we want: a dev ops ex­pert, a prod­uct man­ager, a front-end de­bug­ger, an ac­ces­si­bil­ity checker, a doc­u­men­ta­tion writer. These would be called in on-de­mand to ap­ply their spe­cial skills and tools.

One of the ma­jor lim­i­ta­tions of cur­rent cod­ing agents is run­ning out of con­text. Before you even hit the lim­its of a con­text win­dow, con­text rot de­grades the out­put enough that it’s not worth keep­ing. We con­stantly have to com­pact or start fresh ses­sions.

Gas Town’s so­lu­tion to this is make each agent ses­sion dis­pos­able by de­sign. It stores the im­por­tant in­for­ma­tion — agent iden­ti­ties and tasks — in Git, then lib­er­ally kills off ses­sions and spins up fresh ones when needed. New ses­sions are told their iden­tity and cur­rently as­signed work, and con­tinue on where the last one left off. Gas Town also lets new ses­sions ask their pre­de­ces­sors what hap­pened through “seancing”: re­sum­ing the last ses­sion as a sep­a­rate in­stance in or­der to let the new agent ask ques­tions about un­fin­ished work.

This sav­ing and re­call­ing is all done through Gas Town’s “Beads” sys­tem. Beads are tiny, track­able units of work — like is­sues in an is­sue tracker — stored as JSON in Git along­side your code. Each bead has an ID, de­scrip­tion, sta­tus, and as­signee. Agent iden­ti­ties are also stored as beads, giv­ing each worker a per­sis­tent ad­dress that sur­vives ses­sion crashes.

Yegge did­n’t in­vent this pat­tern of track­ing atomic tasks out­side agent mem­ory in some­thing struc­tured like JSON. Anthropic de­scribed the same ap­proach in their re­search on ef­fec­tive har­nesses for long-run­ning agents  , just pub­lished in November 2025. I give it a hot minute be­fore this type of task track­ing lands in Claude Code.

The whole promise of an or­ches­tra­tion sys­tem like Gas Town is it’s a per­pet­ual mo­tion ma­chine. You give high-level or­ders to the mayor, and then a zoo of agents kicks off to break it down into tasks, as­sign them, ex­e­cute them, check for bugs, fix the bugs, re­view the code, and merge it in.

Each worker agent in Gas Town has its own queue of as­signed work and a “hook” point­ing to the cur­rent thing they should be do­ing. The minute they fin­ish a task, the next one jumps to the front of the queue. The mayor is the one fill­ing up these queues — it’s in charge of break­ing down large fea­tures into atomic tasks and as­sign­ing them to avail­able work­ers. In the­ory, the work­ers are never idle or lack­ing tasks, so long as you keep feed­ing the mayor your grand plans.

This prin­ci­ple of “workers al­ways do their work” is bet­ter in the­ory than prac­tice. It turns out to be slightly dif­fi­cult to make hap­pen be­cause of the way cur­rent mod­els are trained. They’re de­signed as help­ful as­sis­tants who wait po­litely for hu­man in­struc­tions. They’re not used to check­ing a task queue and in­de­pen­dently get­ting on with things.

Gas Town’s patch­work so­lu­tion to this is ag­gres­sive prompt­ing and con­stant nudg­ing. Supervisor agents spend their time pok­ing work­ers to see if any­one’s stalled out or run dry on work. When one goes quiet, they send it a ping which jolts the agent into check­ing its queue and get­ting back to work. These pe­ri­odic nudges move through the agent hi­er­ar­chy like a heart­beat keep­ing every­thing mov­ing. This is a de­cent band-aid for the first ver­sion, but more se­ri­ous ef­forts at agent or­ches­tra­tion sys­tems will need re­li­able ways to keep agents on task.

When you have a bunch of agents all work­ing in par­al­lel, you’re of course go­ing to run into merge con­flicts. Each agent is off on its own branch, and by the time it fin­ishes its task, the main branch might look com­pletely dif­fer­ent — other changes have landed, the code has moved on. The later an agent fin­ishes, the worse this gets. Normally you, the hu­man, takes on the bur­den of sort­ing out the mess and de­cid­ing which changes to keep. But if agents are run­ning on their own, some­thing has to do that job for them.

So Gas Town has a ded­i­cated merge agent — the Refinery — that works through the merge queue one change at a time. It looks at each merge re­quest, re­solves any con­flicts, and gets it into main. When things get re­ally tan­gled — when so much has changed that the orig­i­nal work does­n’t even make sense any­more — it can cre­atively “re-imagine” the changes: re-do­ing the work to fit the new code­base. Or es­ca­late to a hu­man if needed.

But there’s an­other way to side­step merge con­flict night­mares that Gas Town does­n’t have built in: ditch PRs for stacked diffs  . The tra­di­tional git work­flow puts each fea­ture on its own branch for days or weeks, ac­cu­mu­lat­ing com­mits, then get­ting merged back as one chunky PR.

Stacked diffs avoid this con­flict-prone ap­proach by break­ing work into small, atomic changes that each get re­viewed and merged on their own, build­ing on top of each other. Every change gets its own branch, forked off the pre­vi­ous change, form­ing a “stack” of changes de­pen­dent on one an­other. When a change ear­lier in the stack gets up­dated, all the changes be­low it au­to­mat­i­cally re­base on top of the new ver­sion.

This fits how agents nat­u­rally work. They’re al­ready pro­duc­ing tiny, fo­cused changes rather than sprawl­ing multi-day branches. When con­flicts do pop up, they’re eas­ier to un­tan­gle be­cause each diff touches less code. Cursor ’s re­cent ac­qui­si­tion of Graphite  , a tool built specif­i­cally for stacked diff work­flows, sug­gests I am not the only one who sees this op­por­tu­nity. When you’ve got dozens of agents land­ing changes con­tin­u­ously, you need tools and in­ter­faces specif­i­cally de­signed for these fre­quent, in­cre­men­tal merges.

Yegge de­scribes Gas Town as “expensive as hell… you won’t like Gas Town if you ever have to think, even for a mo­ment, about where money comes from.” He’s on his sec­ond Claude ac­count to get around Anthropic’s spend­ing lim­its.

I can’t find any men­tion on­line of the per-ac­count lim­its, but let’s con­ser­v­a­tively as­sume he’s spend­ing at least $2,000 USD per month, and lib­er­ally $5,000.

The cur­rent cost is al­most cer­tainly ar­ti­fi­cially in­flated by sys­tem in­ef­fi­ciency. Work gets lost, bugs get fixed nu­mer­ous times, de­signs go miss­ing and need re­do­ing. As mod­els im­prove and or­ches­tra­tion pat­terns ma­ture, the cost of or­ches­tra­tors like this should drop while out­put qual­ity rises.

I ex­pect com­pa­nies would hap­pily pay around the $1-3k/month mark for a sane, un­der­stand­able, higher qual­ity, and lower waste ver­sion of Gas Town. Maybe that sounds ab­surd to you, given we’ve all be­come an­chored to the ar­ti­fi­cially low rate of $100-200/month for un­lim­ited us­age by the ma­jor providers. But once the AI bub­ble pops, the VC funds dry up, and providers have to charge the true cost of in­fer­ence at scale, we should ex­pect that “unlimited” tier to look a lot pricier.

Even when that comes to pass, a few thou­sand is pretty rea­son­able when you com­pare it to an av­er­age US se­nior de­vel­oper salary: $120,000 USD. If Gas Town could gen­uinely speed up the work of a se­nior de­vel­oper by 2-3x or more, it would eas­ily be worth 10-30% of their salary. The cost per unit of valu­able work starts to look com­pet­i­tive with hu­man la­bor.

The maths on pay­ing for some­thing like this is al­ready de­fen­si­ble in wealth­ier places like the US and parts of Western Europe. In spots where de­vel­oper salaries are lower, we would ex­pect the bud­get for AI as­sisted tools ad­justs ac­cord­ingly. They’ll get less crazy scaled au­toma­tion and more con­ver­sa­tive use­age with hu­mans fill­ing in the cog­ni­tive gaps.

Yegge is lean­ing into the true de­f­i­n­i­tion of vibecod­ing with this pro­ject: “It is 100% vibecoded. I’ve never seen the code, and I never care to.” Not look­ing at code at all is a very bold propo­si­tion, to­day, in January 2026.

Given the cur­rent state of mod­els and the mea­gre safe­guards we have in place around them, the vast ma­jor­ity of us would con­sider this blind cod­ing ap­proach ir­re­spon­si­ble and daft to do on any­thing that is­n’t a throw­away side pro­ject. Which, given the amount of ef­fort and Claude to­kens Yegge has sunk into build­ing it, writ­ing doc­u­men­ta­tion, and pub­licly pro­mot­ing it, Gas Town is not.

“Should de­vel­op­ers still look at code?” will be­come one of the most di­vi­sive and heated de­bates over the com­ing years. You might be of­fended by the ques­tion, and find it ab­surd any­one is ask­ing. But it’s a sin­cere ques­tion and the an­swer will change faster than you think.

I’m al­ready see­ing peo­ple di­vide along moral­is­tic, per­sonal iden­tity lines as they try to an­swer it. Some de­clare them­selves purist, AI skep­tic, Real Developers who check every diff and hand-ad­just spe­cific lines, sneer­ing at any­one reck­less enough to let agents run free. While oth­ers lean into agen­tic max­i­mal­ism, di­rect­ing fleets from on high and pity­ing the mass of lud­dites still faffing about with man­ual ed­its like it’s 2019. Both camps mis­take a con­tex­tual judge­ment for a per­son­al­ity trait and firm moral po­si­tion.

A more con­ser­v­a­tive, eas­ier to con­sider, de­bate is: how close should the code be in agen­tic soft­ware de­vel­op­ment tools? How easy should it be to ac­cess? How of­ten do we ex­pect de­vel­op­ers to edit it by hand?

Interfaces like Claude Code  , Cursor  , and Conductor do not put code front and cen­tre in the ex­pe­ri­ence. The agent is your first and pri­mary in­ter­face. You might be able to see diffs rolls by or dis­play code files in­line, but you can’t touch them. Trying to edit code your­self is a round­about jour­ney of open­ing your IDE and nav­i­gat­ing to the cor­rect files and lines.

This de­sign choice as­sumes it is eas­ier to ask an agent to make the change for you, than it is to type it out the syn­tax your­self. They clearly say “we don’t be­lieve users need to touch code.”

Framing this de­bate as an ei­ther/​or — ei­ther you look at code or don’t, ei­ther you edit code by hand or you ex­clu­sively di­rect agents, ei­ther you’re the anti-AI-purist or the agen­tic-maxxer — is un­help­ful. Because noth­ing is a strict bi­nary.

The right dis­tance is­n’t about what kind of per­son you are or what you be­lieve about AI ca­pa­bil­i­ties in the cur­rent mo­ment. How far away you step from the syn­tax shifts based on what you’re build­ing, who you’re build­ing with, and what hap­pens when things go wrong. The de­gree of free­dom you hand over to agents de­pends on:

Front-end ver­sus back­end makes a huge dif­fer­ence. Language is a poor medium for de­sign­ing eas­ing curves and de­scrib­ing aes­thetic feel­ings — I al­ways need to touch the CSS, and it’s of­ten faster to just tweak di­rectly than try to ex­plain what I want. Yegge’s CLI tool­ing is much eas­ier to val­i­date with pass/​fail tests than eval­u­at­ing whether a no­ti­fi­ca­tion sys­tem “feels calm enough”. Model com­pe­tence also varies wildly by lan­guage; prompt­ing React and Tailwind gives you much bet­ter re­sults than Rust or Haskell, where the mod­els still reg­u­larly choke on bor­row check­ers and type sys­tems.

The more agents can val­i­date their own work, the bet­ter the re­sults. If you let agents run tests and see the out­put, they quickly learn what’s bro­ken and how to fix it. If you let them open browsers, take screen­shots, and click around, they can spot their mis­takes. Tools like the Ralph Wiggum plu­gin lean into this — it loops un­til tests pass or some spe­cific con­di­tion is val­i­dated. This does­n’t work for less de­fined, clear cut work though. If you try to make an agent de­sign a vi­sual di­a­gram for you, it’s go­ing to strug­gle. It does­n’t know your aes­thetic pref­er­ences and can’t re­ally “see” what it’s mak­ing.

Stakes mat­ter. If an agent breaks some im­ages on your per­sonal blog, you’ll re­cover. But if you’re run­ning a health­care sys­tem where a bug could mis­cal­cu­late drug dosages, or a bank­ing app mov­ing ac­tual money around, you can’t just wave an agent at it and hope. Consequences scale up fast. Corporate soft­ware has peo­ple whose en­tire job is com­pli­ance and reg­u­la­tory sign-off — they need to see the code, un­der­stand it, ver­ify it meets re­quire­ments. Those peo­ple aren’t go­ing to let you widly run Gas Town over pro­jects with­out se­ri­ous guardrails in place.

“Gas Town sounds fun if you are ac­count­able to no­body: not for code qual­ity, de­sign co­her­ence or in­fer­enc­ing costs. The rest of us are ac­count­able for at least the first two and even in cor­po­rate sce­nar­ios where there is a blank check for to­kens, that can’t last. So the bot­tle­neck is go­ing to be how fast hu­mans can re­view code and agree to take re­spon­si­bil­ity for it.”

Starting fresh (greenfield), means you can let agents make ar­chi­tec­tural de­ci­sions and es­tab­lish pat­terns — if you don’t like them, you can eas­ily throw it out and restart. The cost of mis­takes is low. But in an ex­ist­ing code­base (brownfield) with years of ac­cu­mu­lated con­ven­tions, im­plicit pat­terns, and code that ex­ists for rea­sons no­body re­mem­bers any­more, agents need much tighter su­per­vi­sion. They’ll hap­pily in­tro­duce a new pat­tern that con­tra­dicts the three other ways this code­base al­ready solves the same prob­lem.

If you’re solo of course you can YOLO. If you’re work­ing with more than a hand­ful of peo­ple, you’ll have to agree on cod­ing stan­dards and agent rules. This cre­ates its own over­head: up­dat­ing the AGENTS.md file, pick­ing MCPs, writ­ing com­mands and skills and rules and what­ever else we in­vent to con­strain these things. The pace of change when you’re all us­ing agents can be over­whelm­ing and you need to fig­ure out a sen­si­ble re­view­ing pipeline to man­age it. Team co­or­di­na­tion can fall apart when every­one’s agents start mov­ing too fast. You might show up in the morn­ing and dis­cover some­one’s agent re­named the data­base schema while an­other agent refac­tored the whole API layer, and nei­ther of which jive with your gi­ant, un­merged fea­ture.

More se­nior de­vel­op­ers can prompt bet­ter, de­bug bet­ter, and setup more strin­gent pref­er­ences earned through decades of see­ing what can go wrong in scaled, pro­duc­tion en­vi­ron­ments. They can rec­og­nize pat­terns: “oh, that’s a mem­ory leak” or “that’s go­ing to dead­lock un­der load.” Newer de­vel­op­ers don’t have that cat­a­log of fail­ures yet and are much more likely to prompt their own per­sonal house of cards. The tests might pass and every­thing looks fine un­til you hit pro­duc­tion traf­fic or some­one en­ters a weird char­ac­ter. It is hard to de­fend against un­known un­knowns.

Given all these “it de­pends” con­sid­er­a­tions, I’m cur­rently in the code-must-be-close camp for most se­ri­ous work done by pro­fes­sional de­vel­op­ers. But I ex­pect I’ll shift to the code-at-a-dis­tance camp over the next year or two as the har­nesses and tools we wrap around these agents ma­ture. If we can ship them with es­sen­tial safe guards and qual­ity gates, the risks drop. Sure, the mod­els will also im­prove, but the in­fra­struc­ture mat­ters far more: val­i­da­tion loops, tests, and spe­cialised sub­agents who fo­cus on se­cu­rity, de­bug­ging, and code qual­ity are what will make code-at-a-dis­tance fea­si­ble.

We have many, con­tin­u­ous ver­sions of the code dis­tance de­bate in­ter­ally at Github Next  . One of the pro­jects within the team dri­ving this is Agentic Workflows  — au­tonomous agents run through GitHub Actions in re­sponse to events: new PRs, new is­sues, or spe­cific times of day. Every com­mit can trig­ger a se­cu­rity re­view agent, an ac­ces­si­bil­ity au­dit, and a doc­u­men­ta­tion up­dater, all run­ning in par­al­lel along­side tra­di­tional CI/CD tests be­fore any­thing lands in main. The team build­ing it rarely touches code and do most of their work by di­rect­ing agents from their phones. It’s these kinds of guardrails that makes a hands-off Sim-City-esque or­ches­tra­tor sys­tem feel less ter­ri­fy­ing to me.

I don’t be­lieve Gas Town it­self is “it”. It’s not go­ing to evolve into the thing we all use, day in and day out, in 2027. As I said, it’s a provoca­tive piece of spec­u­la­tive de­sign, not a sys­tem many peo­ple will use in earnest. In the same way any poorly de­signed ob­ject or sys­tem gets aban­doned, this manic cre­ation is too poorly thought through to per­sist. But the prob­lems it’s wrestling with and the pat­terns it has sketched out will un­ques­tion­ably show up in the next gen­er­a­tion of de­vel­op­ment tools.

As the pace of soft­ware de­vel­op­ment speeds up, we’ll feel the pres­sure in­ten­sify in other parts of the pipeline: thought­ful de­sign, crit­i­cal think­ing, user re­search, plan­ning and co­or­di­na­tion within teams, de­cid­ing what to build, and whether it’s been built well. The most valu­able tools in this new world won’t be the ones that gen­er­ate the most code fastest. They’ll be the ones that help us think more clearly, plan more care­fully, and keep the qual­ity bar high while every­thing ac­cel­er­ates around us.

Most PCs tend to boot from a pri­mary me­dia stor­age, be it a hard disk drive, or a solid-state drive, per­haps from a net­work, or — if all else fails — the USB stick or the boot DVD comes to the res­cue… Fun, eh? Boring! Why don’t we try to boot from a record player for a change?

Update February 2022: Click here to ob­serve the very same vinyl ramdisk booted on an IBM PCjr!

So this nutty lit­tle ex­per­i­ment con­nects a PC, or an IBM PC to be ex­act, di­rectly onto a record player through an am­pli­fier. I made a small ROM on-chip boot loader that op­er­ates the built-in “cassette in­ter­face” of the PC (that was hardly ever used), which will now be in­voked by the BIOS if all the other boot op­tions fail, i.e. floppy disk and the hard drive. The turntable spins an ana­log record­ing of a small bootable read-only RAM drive, which is 64K in size. This con­tains a FreeDOS ker­nel, mod­i­fied by me to cram it into the mem­ory con­straint, a mi­cro vari­ant of COMMAND. COM and a patched ver­sion of INTERLNK, that al­lows file trans­fer through a printer ca­ble, mod­i­fied to be runnable on FreeDOS. The boot­loader reads the disk im­age from the au­dio record­ing through the cas­sette mo­dem, loads it to mem­ory and boots the sys­tem on it. Simple huh?

The vinyl loader code, in a ROM

(It can also re­side on a hard drive or a floppy, but that’d be cheat­ing)

And now to get more tech­ni­cal: this is ba­si­cally a merge be­tween BootLPT/86 and 5150CAXX, mi­nus the printer port sup­port. It also re­sides in a ROM, in the BIOS ex­pan­sion socket, but it does not have to. The con­nect­ing ca­ble be­tween the PC and the record player am­pli­fier is the same as with 5150CAXX, just with­out the line-in (PC data out) jack.

The “cassette in­ter­face” it­self is just PC speaker timer chan­nel 2 for the out­put, and 8255A-5 PPI port C chan­nel 4 (PC4, I/O port 62h bit 4) for the in­put. BIOS INT 15h rou­tines are used for soft­ware (de)modulation.

The boot im­age is the same 64K BOOTDISK. IMG “example” RAM drive that can be down­loaded at the bot­tom of the BootLPT ar­ti­cle. This has been turned into an “IBM cas­sette tape”-pro­to­col com­pli­ant au­dio sig­nal us­ing 5150CAXX, and sent straight to a record cut­ting lathe.

Vinyls are cut with an RIAA equal­iza­tion curve that a pre­amp usu­ally re­verses dur­ing play­back, but not per­fectly. So some sig­nal cor­rec­tion had to be ap­plied from the am­pli­fier, as I could­n’t make it work right with the line out­put straight from the phono pre­amp. In my case, in­volv­ing a vin­tage Harman&Kardon 6300 am­pli­fier with an in­te­grated MM phono pre­amp, I had to fade the tre­ble all the way down to -10dB/10kHz, in­crease bass equal­iza­tion to ap­prox. +6dB/50Hz and re­duce the vol­ume level to ap­prox­i­mately 0.7 volts peak, so it does­n’t dis­tort. All this, nat­u­rally, with any phase and loud­ness cor­rec­tion turned off.

Of course, the cas­sette mo­dem does not give a hoot in hell about where the sig­nal is com­ing from. Notwithstanding, the record­ing needs to be pris­tine and con­tain no pops or loud crack­les (vinyl) or mod­u­la­tion/​fre­quency drop-outs (tape) that will break the data stream from con­tin­u­ing. However, some wow is tol­er­ated, and the speed can be 2 or 3 per­cent higher or lower too.

Bootloader in a ROM; be­ing an EPROM for a good mea­sure

And that’s it! For those in­ter­ested, the boot­loader bi­nary de­signed for a 2364 chip (2764s can be used, through an adap­tor), can be ob­tained here. It as­sumes an IBM 5150 with a mono­chrome screen and at least 512K of RAM, which kind of re­minds me of my setup (what a co­in­ci­dence). The boot disk im­age can be ob­tained at the bot­tom of the BootLPT/86 ar­ti­cle, and here’s its ana­log vari­ant, straight from the grooves 🙂

Tesla was told that if it could­n’t re­solve the de­cep­tive mar­ket­ing within those 60 days, the sales sus­pen­sion would take ef­fect. That would be bad for the au­tomaker, as California is far and away its largest mar­ket in the US, al­beit one that is shrink­ing each quar­ter. Having to sus­pend sales en­tirely in the state would be dis­as­trous. Some had spec­u­lated that Tesla could change Autopilot’s name to some­thing less mis­lead­ing, but the com­pany chose a more dras­tic ap­proach.

Now, if you buy a new Tesla and  want it to steer it­self—while you pay at­ten­tion to the road—you will have to pay for FSD. Until the mid­dle of February, that can be done for a one-time fee of $8,000. But start­ing on February 14, that op­tion goes away, too, and the sole choice will be a $99/month FSD sub­scrip­tion.

But prob­a­bly not for very long. Last night, Musk re­vealed on his so­cial me­dia plat­form that “the $99/month for su­per­vised FSD will rise as FSD’s ca­pa­bil­i­ties im­prove. The mas­sive value jump is when you can be on your phone or sleep­ing for the en­tire ride (unsupervised FSD).”

The quest for re­cur­ring rev­enue streams is be­com­ing some­thing of a holy grail in the au­to­mo­tive in­dus­try as OEMs that pre­vi­ously treated their cus­tomers as a sin­gle sale now hope to make them­selves more at­trac­tive to in­vestors by en­cour­ag­ing cus­tomers to give them reg­u­lar pay­outs.

This may have con­tributed to General Motors’ de­ci­sion to drop Apple CarPlay and Android Automotive. BMW has also ex­per­i­mented with sub­scrip­tion ser­vices. Tesla’s stock price re­mains so high that such games are prob­a­bly un­nec­es­sary here, but with falling profit mar­gins, de­clin­ing sales, and the loss of emis­sions cred­its to bol­ster the bot­tom line, one can see why reg­u­lar cash in­fu­sions from Tesla dri­vers would be de­sir­able.

It’s weird to see Docker Inc (the com­pany) strug­gle to find its place in 2026. What started as the com­pany that rev­o­lu­tion­ized how we de­ploy ap­pli­ca­tions has been through mul­ti­ple iden­tity crises, piv­ot­ing from one strat­egy to an­other in search of sus­tain­able rev­enue and mar­ket rel­e­vance.

Docker’s jour­ney reads like a startup try­ing to find prod­uct-mar­ket fit, ex­cept Docker al­ready had prod­uct-mar­ket fit - they cre­ated the con­tainer­iza­tion stan­dard that every­one uses. The prob­lem is that Docker the tech­nol­ogy be­came so suc­cess­ful that Docker the com­pany strug­gled to mon­e­tize it. When your core prod­uct be­comes com­modi­tized and open source, you need to find new ways to add value.

Docker Swarm was Docker’s at­tempt to com­pete with Kubernetes in the or­ches­tra­tion space. But Kubernetes won that bat­tle de­ci­sively, and Docker even­tu­ally sold Swarm. This was a clear sig­nal that Docker was step­ping back from try­ing to be the full-stack con­tainer plat­form and in­stead fo­cus­ing on what they could uniquely pro­vide.

For a while, Docker seemed to fo­cus on de­vel­oper ex­pe­ri­ence. This made sense - de­vel­op­ers are Docker’s core users, and im­prov­ing their work­flow could be a dif­fer­en­tia­tor. Docker Scout emerged from the ac­qui­si­tion of Atomist in June 2022, bring­ing “software sup­ply chain” ca­pa­bil­i­ties. Scout al­lows Docker to see not just what’s in a con­tainer, but how it was built and where vul­ner­a­bil­i­ties are. This was a smart move to­ward se­cu­rity and ob­serv­abil­ity, ar­eas where Docker could add real value.

Docker also ac­quired AtomicJar, the com­pany be­hind Testcontainers, adding shift-left test­ing ca­pa­bil­i­ties. Testcontainers lets de­vel­op­ers run real de­pen­den­cies (databases, mes­sage queues, etc.) in con­tain­ers dur­ing test­ing, mak­ing in­te­gra­tion tests more re­li­able and closer to pro­duc­tion en­vi­ron­ments.

Then came the AI pivot. Docker Model Runner en­tered the scene, po­si­tion­ing Docker as a plat­form for run­ning AI mod­els. Docker Compose ex­panded to sup­port AI agents and mod­els. Docker Offload was in­tro­duced for cloud-scale GPU ex­e­cu­tion of AI tasks. Partnerships with Google Cloud, Microsoft Azure, and AI SDKs (CrewAI, LangGraph, Vercel AI SDK) fol­lowed.

The ac­qui­si­tion of MCP Defender in September 2025 fur­ther ce­mented Docker’s move into AI se­cu­rity, fo­cus­ing on se­cur­ing agen­tic AI in­fra­struc­ture and run­time threat de­tec­tion. This was a sig­nif­i­cant shift - from de­vel­oper tools to AI in­fra­struc­ture.

Suddenly, Docker moved into the hard­ened im­ages space. In December 2025, Docker made over 1,000 Docker Hardened Images free and open source un­der Apache 2.0, re­duc­ing vul­ner­a­bil­i­ties by up to 95% com­pared to tra­di­tional im­ages. This move was likely trig­gered by Chainguard’s suc­cess in the se­cure con­tainer im­age space. Chainguard had been build­ing a busi­ness around min­i­mal, se­cure con­tainer im­ages, and Docker needed to re­spond.

Making hard­ened im­ages free was a bold move - it’s hard to com­pete with free, es­pe­cially when it’s open source. But it also raises ques­tions about Docker’s busi­ness model. If you’re giv­ing away your se­cu­rity fea­tures for free, what are you sell­ing?

In February 2025, Docker re­placed CEO Scott Johnston (who led the com­pany since 2019) with Don Johnson, a for­mer Oracle Cloud Infrastructure founder and ex­ec­u­tive vice pres­i­dent. This lead­er­ship tran­si­tion has prompted tech an­a­lysts to an­tic­i­pate a po­ten­tial ac­qui­si­tion by a ma­jor cloud provider. The CEO swap, com­bined with the strate­gic piv­ots, sug­gests Docker may be po­si­tion­ing it­self for sale rather than build­ing a stand­alone busi­ness.

Docker’s strate­gic shifts tell a story of a com­pany search­ing for its place in a mar­ket it helped cre­ate. The con­tainer­iza­tion tech­nol­ogy Docker pi­o­neered be­came so suc­cess­ful that it be­came in­fra­struc­ture - some­thing every­one uses but no one wants to pay for di­rectly.

The piv­ots from or­ches­tra­tion (Swarm) to de­vel­oper tools (Scout, Testcontainers) to AI (Model Runner, MCP Defender) to se­cu­rity (Hardened Images) show a com­pany try­ing dif­fer­ent ap­proaches to find sus­tain­able rev­enue. Each pivot makes sense in iso­la­tion, but to­gether they paint a pic­ture of a com­pany with­out a clear long-term vi­sion.

The hard­ened im­ages move is par­tic­u­larly in­ter­est­ing be­cause it’s de­fen­sive - re­spond­ing to Chainguard’s suc­cess rather than lead­ing with in­no­va­tion. Making it free and open source is a strong com­pet­i­tive move, but it does­n’t solve the fun­da­men­tal busi­ness model ques­tion.

Docker the tech­nol­ogy is­n’t go­ing any­where. It’s too em­bed­ded in the in­fra­struc­ture of mod­ern soft­ware de­vel­op­ment. But Docker the com­pany? That’s less clear. The lead­er­ship change, ac­qui­si­tion spec­u­la­tion, and rapid strate­gic piv­ots sug­gest Docker Inc may be po­si­tion­ing it­self for an exit rather than build­ing a long-term in­de­pen­dent busi­ness.

For de­vel­op­ers, this does­n’t change much. Docker con­tain­ers will con­tinue to work, and the open source na­ture of Docker means the tech­nol­ogy will per­sist re­gard­less of what hap­pens to the com­pany. But it’s worth watch­ing how Docker Inc’s search for iden­tity plays out - it could af­fect the ecosys­tem of tools and ser­vices built around con­tain­ers.

The irony is that Docker cre­ated a stan­dard so suc­cess­ful that it be­came in­fra­struc­ture, and in­fra­struc­ture is hard to mon­e­tize. Docker Inc’s strug­gle to find its place is a cau­tion­ary tale about the chal­lenges of build­ing a busi­ness around open source tech­nol­ogy that be­comes too suc­cess­ful.

Local Area Network dis­cov­ery tool with a mod­ern Terminal User Interface (TUI) writ­ten in Go. Discover, ex­plore, and un­der­stand your LAN in an in­tu­itive way.

Whosthere per­forms un­priv­i­leged, con­cur­rent scans us­ing mDNS

and SSDP scan­ners. Additionally, it sweeps the lo­cal sub­net by at­tempt­ing TCP/UDP con­nec­tions to trig­ger ARP res­o­lu­tion, then reads the

ARP cache to iden­tify de­vices on your Local Area Network. This tech­nique pop­u­lates the ARP cache with­out re­quir­ing el­e­vated priv­i­leges. All dis­cov­ered de­vices are en­hanced with

OUI lookups to dis­play man­u­fac­tur­ers when avail­able.

Whosthere pro­vides a friendly, in­tu­itive way to an­swer the ques­tion every net­work ad­min­is­tra­tor asks: “Who’s there on my net­work?”

* No Elevated Privileges Required: Runs en­tirely in user-space.

* Integrated Port Scanner: Optional ser­vice dis­cov­ery on found hosts (only scan de­vices with per­mis­sion!).

* Daemon Mode with HTTP API: Run in the back­ground and in­te­grate with other tools.

* Theming & Configuration: Personalize the look and be­hav­ior via YAML con­fig­u­ra­tion.

brew tap ra­mon­ver­meulen/​whos­there

brew in­stall whos­there

Or with Go:

go in­stall github.com/​ra­mon­ver­meulen/​whos­there@lat­est

git clone https://​github.com/​ra­mon­ver­meulen/​whos­there.git

cd whos­there

make build

whos­there

whos­there dae­mon –port 8080

Additional com­mand line op­tions can be found by run­ning:

whos­there –help

Whosthere is sup­ported on the fol­low­ing plat­forms:

* Windows (maybe in the fu­ture, con­tri­bu­tions wel­come!)

Whosthere can be con­fig­ured via a YAML con­fig­u­ra­tion file. By de­fault, it looks for the con­fig­u­ra­tion file in the fol­low­ing or­der:

* Path spec­i­fied in the WHOSTHERE_CONFIG en­vi­ron­ment vari­able (if set)

When not run­ning in TUI mode, logs are also writ­ten to the con­sole out­put.

Example of the de­fault con­fig­u­ra­tion file:

# How of­ten to run dis­cov­ery scans

scan_in­ter­val: 20s

# Maximum du­ra­tion for each scan

# If you set this too low some scan­ners or the sweeper might not com­plete in time

scan_­du­ra­tion: 10s

# Splash screen con­fig­u­ra­tion

splash:

en­abled: true

de­lay: 1s

# Theme con­fig­u­ra­tion

theme:

# Configure the theme to use for the TUI, com­plete list of avail­able themes at:

# https://​github.com/​ra­mon­ver­meulen/​whos­there/​tree/​main/​in­ter­nal/​ui/​theme/​theme.go

# Set name to “custom” to use the cus­tom col­ors be­low

# For any color that is not con­fig­ured it will take the de­fault theme value as fall­back

name: de­fault

# Custom theme col­ors (uncomment and set name: cus­tom to use)

# prim­i­tive_back­ground_­color: “#000a1a”

# con­trast_back­ground_­color: “#001a33”

# more_­con­trast_back­ground_­color: “#003366”

# bor­der_­color: “#0088ff”

# ti­tle_­color: “#00ffff”

# graph­ic­s_­color: “#00ffaa”

# pri­ma­ry_­tex­t_­color: “#cceeff”

# sec­ondary_­tex­t_­color: “#6699ff”

# ter­tiary_­tex­t_­color: “#ffaa00”

# in­verse_­tex­t_­color: “#000a1a”

# con­trast_sec­ondary_­tex­t_­color: “#88ddff”

# Scanner con­fig­u­ra­tion

scan­ners:

mdns:

en­abled: true

ssdp:

en­abled: true

arp:

en­abled: true

# Port scan­ner con­fig­u­ra­tion

port_s­can­ner:

time­out: 5s

# List of TCP ports to scan on dis­cov­ered de­vices

tcp: [21, 22, 23, 25, 80, 110, 135, 139, 143, 389, 443, 445, 993, 995, 1433, 1521, 3306, 3389, 5432, 5900, 8080, 8443, 9000, 9090, 9200, 9300, 10000, 27017]

# Uncomment the next line to con­fig­ure a spe­cific net­work in­ter­face - uses OS de­fault if not set

# net­work_in­ter­face: lo0

When run­ning Whosthere in dae­mon mode, it ex­poses an very sim­plis­tic HTTP API with the fol­low­ing end­points:

Theme can be con­fig­ured via the con­fig­u­ra­tion file, or at run­time via the CTRL+t key bind­ing. A com­plete list of avail­able themes can be found here, feel free to open a PR to add your own theme!

theme:

name: cy­ber­punk

When the name is set to cus­tom, the other color op­tions can be used to cre­ate your own cus­tom theme.

Logs are writ­ten to the ap­pli­ca­tion’s state di­rec­tory:

When not run­ning in TUI mode, logs are also out­put to the con­sole.

For clip­board func­tion­al­ity to work, a fork of go-clip­board is used. Ensure you have the ap­pro­pri­ate copy tool in­stalled for your OS:

Whosthere is in­tended for use on net­works where you have per­mis­sion to per­form net­work dis­cov­ery and scan­ning, such as your own home net­work. Unauthorized scan­ning of net­works may be il­le­gal and un­eth­i­cal. Always ob­tain proper au­tho­riza­tion be­fore us­ing this tool on any net­work.

Contributions and sug­ges­tions such as fea­ture re­quests, bug re­ports, or im­prove­ments are wel­come! Feel free to open is­sues or sub­mit pull re­quests on the GitHub repos­i­tory. Please make sure to dis­cuss any ma­jor changes on a Github is­sue be­fore im­ple­ment­ing them.