Joshtronic

I taught a robot to detect Joshes

Josh Sherman — Sun, 16 Aug 2026 00:00:00 +0000

This journey starts like most of the things I've been doing this year, as an experiment to run a website 100% unattended with an agent. Ideally this post won't go down as an epitaph in a future where robots hunted down unsuspecting humans named Josh.

I'm aware of "claws" and I know I could probably just boot up Claude Code with a /goal or /loop prompt like:

build and maintain an awesome website, autonomously. seriously don't freakin' bother me, like ever. you're the boss here. make the site really great, and ideally figure out how to make me a bajillionaire. loljk, but tres commas shouldn't be an afterthought.

What this actually looks like: robot files a request, and I approve or reject it. It's still very permission based.

The gathering of the Joshes

I already phoned in a post about this back in January. I started a simple web directory for humans named Josh. As to not be exclusionary, Joshuas, Joshis, and other Josh-adjacent names are welcome.

Not wanting to bother with outbound sales for this project, I got creative with some discovery efforts along the way. It's a series of scripts to seek out Josh websites, with the help of my friendly robot Igor to screen PRs and handle SRE duties during merges.

Thus far, I am still the final approval on the PRs. It's a tough job, and quite frankly, I don't want to do it.

Living in the future, today

These experiments are all part of what I think the future is going to look like. I'm clearly living in the shared hallucination of what still feels like a smaller number of my peers.

I also live in reality, where the tech still doesn't feel like it's quite there yet. My thought is, if you conduct yourself like it's 2032 and we're all being shuffled around in our hover chairs like in WALL-E, maybe it will all happen sooner.

I also think the tech is fun, and watching a computer take my human words and turn them into dumb ideas I described feels like magic. The same magic I felt when I made an Atari computer spew a wall of "JOSH" across the screen in grade school.

In retrospect, I guess I've always had a thing for my name.

Final approval

As mentioned, I am still reviewing these PRs, but as a last line of defense. The script runs nightly, hunts for new Josh sites, and opens a PR. From there, Igor will review the PR and give feedback, initially in the form of a comment because it couldn't actually verify something.

Then I'd take a look at the PR. I scroll through the screenshots, and do a small bit of double checking when the image doesn't have a discernible "Josh" artifact. In the beginning, there were a lot of false positives, so that all needed to be dialed in. These days it would take a few seconds to a few minutes.

Not good enough

The experiment is to get me out of the loop, so none of this was going to cut it. Igor was already doing a great job, and I recently talked about the lessons learned from building a PR review loop.

As mentioned, the Igor review feedback was typically "LGTM, also I couldn't verify much". So until that is improved, I'll continue to be the blocker.

Improving context visibility

And that's where I'm at right now. Not at a point of full autonomy, but in the steps just before that.

Reviewing the PR manually is a good exercise, as I've been able to make some notes about what's working and what's not. What wasn't working is that the screenshots don't always contain a marker to indicate the site is Josh-based. A slight improvement to that was to include the actual "Josh" artifact in the PR.

Because of the volume of sites I'm finding, it's made sense to reject sites that we can't detect "Josh" text on. There's the potential we're omitting legitimate sites, but that's the risk that I'm okay with to ensure we can get a point that the entire process can be automated.

Sadly though, when the Igor coder picked up the task, I didn't explicitly cite adding the content to the PR body. The result? All of the evidence was added to the repo, doubling the number of files in the PR.

That's how this goes, thin requirements sometimes get bad results. We iterated and moved on.

Fully autonomous, when?

Being completely honest, I'm not entirely certain when this one will get there.

My biggest concern is that I've already ran into a few sites that passed the "josh" string on the website test, but also, weren't personal sites and failed a few other criteria.

Detection's at a place that's starting to consistently get my PR reviews down from minutes to seconds. Huge win, as we're picking up 15+ new sites daily.

I'll probably need to circle back on the LLM website analysis to get that dialed in further. Loops all the way down.

Reverse Engineering a PostHog SuperDay

Josh Sherman — Sun, 09 Aug 2026 00:00:00 +0000

I'm not here to bullshit anybody, I have never been through a PostHog SuperDay. Like many humans, I've read about it on their website, as they are a company that over-communicates just about everything.

This tale started when I got curious about their onboarding wizard. Their pivot from analytics to self-driving systems mirrors what I've been working on for the last couple of years, which has accelerated greatly over the last 3 months. Figured there was probably something I could learn and possibly bite off to include in my own system.

Figuring out what to do

I've been around open source software (OSS) for a good long while now. Even though I've had some strong opinions about the state of things over the years, I still believe it's the way. If not for OSS, I wouldn't be able to say things like "I wrote a Lorem Ipsum generator that's somehow been installed over 1 million times."

These days, most projects have a label on their issues that indicate what's good for a new contributor to pick on. PostHog's repos are no different, except the repo I was looking at didn't have any issues tagged with the good first issue tag.

Not a big deal, with 100+ open issues I figured I'd be able to find something I could pick up to give me a chance to play with the codebase. I did find a handful of things, I even started to chase down one of them. As I did I realized I kept talking myself out of each issue because what appeared to be low hanging fruit was stuff that I could defend deprioritizing.

A pattern started to emerge

Along this journey of trying to find an issue worth fighting for, I started to notice a pattern of somewhat disparate issues and PRs opened by the same contributor. I also noticed that core team members (read: employees) were commenting on these issues and PRs and not in the usual "yea or nay" fashion that I see.

The comments were constructive in a way that you'd be with a more junior teammate that you're attempting to mentor and train up. Not a bad thing, but the feedback was more open ended rather than "hey I think this will cause an issue, go fix it" that you usually run into.

With my hamster wheel turning, it started to seem like these issues and PRs weren't from outside contributors as much as they were from actual candidates. Didn't hurt that the username of one of the users actually had the word "candidate" in it.

Even if my theory is incorrect, the feedback from the core team members seemed valuable, and I used some of what was out there to analyze some of my own work to see what could be learned and improved upon.

The simulation

At this point I was pretty convinced I was watching SuperDays play out in real time on the repo. Having talked myself out of a handful of issues to work, I decided it was time to send one of my robot friends to analyze the situation.

The results? After analyzing the data that seemed to be from candidates, cross referencing the team and their openly documented goals, I was feeling an awful lot like Charlie Day:

I was also feeling like I'd found an issue to work on. It was filed by an actual employee and not a potential candidate. The ticket was decently scoped, even though I pursued a quicker fix than what was defined.

It was backed by a report from an actual user. It was also an issue that I was eyeing already because it was something I had run into while setting things up myself.

Best part, it seemed to line up pretty nicely with one of their published quarterly goals on their website. The wizard team's TUI revamp explicitly states "users discover and run wizard programs without the exact CLI command".

Most importantly, it was currently unassigned so ideally I wasn't stepping on any toes.

Are you going to tell us?

Yes, I'm going to tell you which issue I picked up. But the whole point of this post is less about the what and more about the how and the why. So the issue I had picked up was related to running PostHog's wizard more than once on a repo.

As mentioned, I ran into the issue when running it myself. Even though the project does "2 hours of work in 8 minutes", if you don't remember if you already ran it, or worse, ran into something that forces you to run it again, you're paying round trip prices for each subsequent run.

My thought was that there was an easy win in there to do some light detective work and then raise some awareness of what else the script can do. I scope intentionally thin for a few reasons.

First, oftentimes PRs are completely ignored and never merged. Zero reason to boil the ocean when your contribution will be negated. Second, smaller scope makes it easier to get something into production. Ship fast, get feedback fast. Iterate from there.

Claude as my navigator

Similar to how I never denied using Google or Stack Overflow to research stuff, I'm not going to act like I don't use the heck out of AI. I play with different harnesses, and models. Claude's still my ride or die at the moment so of course I leveraged it to get up to speed on the codebase.

Since I wanted to actually learn the code a bit, and knock some ring rust off, I thought that I'd leverage my friendly robot more like a mentor than a subordinate. I did have to keep an eye on which mode I'd left it in. Usually I don't juggle between modes, but I wanted to be a bit more explicit here allowing for correct attribution.

It worked out surprisingly well, as I mostly kept Claude Code in plan mode so it didn't make any code changes. I used it to learn the flow of the system and figure out where I needed to make the changes I wanted to make.

I like to follow a strict test-driven workflow. Tests and business logic never to be committed at the same time. It works out most of the time, allowing me to have a clean history and helps keep the robots honest so they aren't munging tests to make their code seem functional.

Other than that, it was a pretty boring process. Pair programming with the direction of Claude Code. Figuring out how to test things and run them against my project code. Figuring out conventions, in some cases, the lack thereof.

The result of an afternoon (and part of an evening) of effort is living in this PR. ~~Both the PR and the comment on the issue are unacknowledged at the time of this writing.~~ Which did end up getting some feedback and confirmed my suspicions about the possibility of upstream changes being in flight.

Not even mad

I'm no stranger to open source contributions being flat out ignored. I have a PR in flight on eleventy-plugin-rss to fix a bug I ran into a while back. The times I've actually cared, I come in super hot, fork the project and start to operate like a project lead rather than an unpaid intern.

That all said, the process was fun, and I learned quite a bit. Including but not limited to playing with pnpm for the first time and having a TIL moment with tsdown.

The bigger code takeaways were related to an adjacent repo that PostHog uses to manage their context files, and the friendly reminder that I should be open sourcing more of my code.

Over this weekend I actually put my Igor agent out in the open and started a "context mill" inspired project I'm calling the Distillery to serve as a shared library of my context files and skills.

Both are part of my journey to crack the nut of complete automation and are licensed under the GNU Public License Version 3 (GPLv3). You can thank this post for that.

Where I probably missed the mark

Let's say I did reverse a small bit of PostHog's SuperDay. If I had to judge the work I did against what I think their expectations are, I'd honestly say I probably missed the mark.

Even though I ganked the idea of the "context mill" for my own gains, I actually didn't bother doing much with the repo. I acknowledged its existence, I learned a small bit about it, but I didn't bother to see if there was anything out there that could have been a more impactful task. Nor did I identify a task that could potentially touch both repos.

I'm a builder through and through, so I've always defaulted to code. Code's just a smaller part of the equation in the generative AI age. I did my default here, but also used it as a chance to pick apart myself a bit.

Probably going to save that for another post, but all in all I would say that I enjoyed this process. I definitely have some new tricks to working with legacy codebases, which I have done regularly throughout my career. I have a few action items to work on for myself, and of course it's always great when you learn something new and implement it into your own project.

Observations From Building a PR Review Loop

Josh Sherman — Sun, 02 Aug 2026 00:00:00 +0000

Building my own agent has been fun. Sure, I could have opted for an off-the-shelf solution, but I wanted control. The ironic part is that I'm using that control to offload more control to the agent.

Recent experiments have included letting the agent work on itself. Super meta, but didn't quite go as planned considering the guardrails I have in place around the size of PRs. Agent work tends to be heavy lifting, whereas most project work is small and fits nicely inside the constraints.

Part of the issue there is that the PR reviewer would constantly request changes on those larger PRs. Changes would happen, PR message body would diverge. Infinite loop death spiral until eventually I was called.

Around this same time, I was also tracking some issues that started to creep in after I changed some models from Opus 4.8 to Opus 5. Approval rate dropped by about half.

I like to think that each new model is going to be better than the last, so I thought perhaps it was time to revisit the reviewer to see if there was something we were missing.

The review mechanic

By design, the review persona is pretty dumb. Not dumb in the sense that I give it a lesser model or anything. Dumb in that it just doesn't have the full picture of things.

It gets the PR diff as a blob of text and that's it. No git worktree, no way to read files or grep around. No commit messages or recent changes to compare against.

I don't review PRs this way. I click around and look at adjacent code. I'll git checkout the branch locally and poke around. I try to gather as much as I can to give feedback with more substance than nit: stray line break or the like.

Because of this, a lot of the feedback from the reviewer was effectively LGTM, but I can't really confirm anything so... lol good luck. Then I'd get pinged to take a closer look.

Safety first

It's probably not fair to say the reviewer is dumb. The reviewer is gated by security checks. I'm the only user on my personal Forgejo instance, but that doesn't mean I'd prefer to be flighty with things.

Any changes made and the PR content can be considered untrusted input. Because of this, the reviewer shouldn't be poking around with tools on the command-line. The diff-only review blindness is a security measure.

Raising everything the agent couldn't rule out, that's a feature, not a bug.

Review, rework, repeat

At this point, the dutiful worker agent grabs the feedback with the goal of addressing the requested changes. The worker can verify the feedback against the working tree and attempt to remediate it.

And if the feedback was already implemented or worse, just plain wrong? The worker would either do its very best to remedy something, or it would bail on the task. Work typically resulted in PR body divergence, which is an underlying bug since the reviewer takes those messages very seriously.

If there's nothing to action on, I get the escalation. I also get pinged if the loop hits a certain number of iterations. The assumption being they aren't going to figure it out on their own.

Giving the worker permission

Accounting for the security concerns above, the fix wasn't to give the reviewer more access. Fun fact, I tried but my own security gates did their job and were like "lolnope".

The remedy was to give the worker permission to push back. Giving explicit permission is always one of my favorite prompt changes. It always feels like a cheat code.

This one wasn't even as much about giving permission as explaining the situation a bit better. "Hey, the robot that reviewed this only looked at the diff," and outlining a specific set of options to dismiss, fix or escalate.

To spell out things further, I explained that it could mix and match things as well. Since the reviewer may mention a few things, no reason to be committed to a single outcome for everything.

The most permissive part looks something like this:

Dismissing is a real option, not a loophole. But the burden is on you: "I could not confirm the reviewer's concern" is not a dismissal, it is a shrug. Go check, then either fix it or state what you found. A dismissal a human reads and disagrees with costs more than the fix would have.

Also worth mentioning, Forgejo v16 (released in July 2026) has expanded the PR review system greatly amongst other things. Before this, the only way to review was to leave feedback in a single input. Now they have inline commenting which will greatly improve how my agent reviews code.

The end of the no-op

With the worker in a state of always communicating, the reviewer has a lot more context to go on. The initial failure loop was a no-op that would turn into an escalation.

The new working model allows for additional context to be added for the reviewer. Said information could be pushed back on by the reviewer, but seems like most of the time it allows the agents to actually work through things.

At this point the game loop, still on Opus 5, is more likely to play out to an approval from the reviewer. Many of my repos will auto-merge in this scenario, allowing for more autonomy and less frequent phoning home.

New Feature: Games

Josh Sherman — Sun, 26 Jul 2026 00:00:00 +0000

Part of running your own website is being able to do what you want on it. Within the confines of the law, of course. Back in the day you'd add something trivial to your site and make a formal announcement about it to your adoring fan base.

I've done it in the past.

My buddy Geoff still does it.

As of late, it seems like what's old is new again on the web. Rather than bore you with some navel gazing about AI or similar, today I'm going to post about a new feature on my site.

Bangs on the table to simulate a drum roll...

I've added a games page.

It's mostly just a bunch of slopped-together game websites to chip away at my backlog of "this would make a great game" domains I've accrued over the years. Along with a game that I wrote myself for the 10K Apart coding competition.

Spoiler: I didn't place well.

Speaking of AI navel gazing, the most ambitious of the bunch is Porksicle. With over 100 minigames, it's my attempt to build a fully automated game company with agents. I greenlight the work and mostly serve as Chief Playtester.

If you have some time to kill, feel free to pull up a stool and game a while.

Invite Systems are an Open Relay

Josh Sherman — Sun, 19 Jul 2026 00:00:00 +0000

Every time I think I've seen it all from spammers, they do something that surprises me. The ingenuity of bad actors is an interesting thing. I always wonder what sort of world we'd live in if their efforts were focused on good.

What sucks the most is when they abuse something that's intended to bring people together. Case in point, an invite system. It exists to allow somebody the chance to get the rest of their team using a product or service.

Invites wouldn't work if they said "You've been invited to platform" with no additional context. Typically the email states the name of the organization you're being invited to. "You've been invited to your organization name here".

Where does that organization name come from? The user of course! And what happens if the user has ill intentions? They set the organization name to something like "Text 1-800-555-1212 for a good time", or something even sketchier than that.

Generally speaking, these emails come through transactionally and from a generic email on the platform. If your system doesn't meter the number of invites, you have yourself a certified spam cannon! May as well set up an SMTP server without authentication, better known as an open mail relay.

There's a few ways you can approach limits. Have a cap on the total number of pending invites? The spammer may delete pending invites to keep moving. Daily limits on total invites sent? Maybe they'll be okay with stretching their campaign over days?

Probably not, most spammers are in the business of going as hard and fast as possible before they get caught. Occasionally somebody will fly below the radar, but I think that's more of a bug than a feature.

Sane limits as to not get in the way of legitimate users tends to get you pretty far. Monitoring if/when somebody hits the limits is good too. Spammers usually won't write in to let you know they hit some limit.

I say usually because there are some special folks out there that will come knocking.

Sandbox Coding Agents with a Separate User Account

Josh Sherman — Sun, 12 Jul 2026 00:00:00 +0000

I don't trust our new robot overlords at all. I also don't fully believe that agents are out there dropping production databases without some serious coercion to do so.

And while I don't trust the robots, I trust myself only a trivial amount more, so my local access tends to be extremely thin. But not so thin that a rogue agent couldn't do a little damage.

That all said, I am constantly calibrating my trust with agentic endeavors. In doing so, I've been moving agents out of my user space entirely.

Having Claude Code and other harnesses living under a separate user account eliminates a lot of potential disasters due to the agent finding privileged local credentials that could do some damage.

Sandboxing my agents has improved trust thanks to the isolation. It's also had an additional benefit of the robots not being thoroughly confused by some of my shell aliases. It's a clean slate, and I grant access, mostly read-only, accordingly.

With my agents running primarily outside of my user space, I'm able to give them significantly more leash. Running in YOLO mode (--dangerously-skip-permissions) doesn't feel nearly as scary. I do use --remote-control, but I can still log in as the separate user account to cut the latency of the web interface when I'm actually at the keyboard.

While things do feel much safer, I have watched the fucking clanker try to figure out if it has passwordless sudo access on numerous occasions. Maybe the robots do actually drop people's production databases.

Seriously though, it's on them for letting the thing have access to begin with.

Automating Everything That Doesn't Need Me

Josh Sherman — Sun, 05 Jul 2026 00:00:00 +0000

I've been writing a lot about LLMs, AI (or the so-called "Artificial Intelligence") and the like. Part of that is because I haven't been running into many problems that I feel need documenting. Bigger part is because I'm finding that "how-to" content is easy to slop with a robot, so I'd rather write about things that the clankers can't.

In a word, I'm just trying to write more human.

While I don't think I've achieved full tokenmaxxing AI psychosis levels yet, I do like agentic coding. I'm also a huge proponent for automation. If it comes up regularly, it should be automated. If it can't be fully automated, then it should at least be partially automated.

If I don't need to be materially involved, then I shouldn't be involved at all.

My latest foray into building my own agent has included a refocus around trying to automate any and everything that I can. I still consider this to be an experiment more than me drinking any sort of Kool-Aid.

Similar motives to my push for a dumber home, if I need to be involved, then it doesn't need to be smart. Well if I don't need to be involved, it should be automated.

That's led me down a rabbit hole of trying to be less and less involved with certain things. Keep in mind, this is an experiment against my personal agent, and my myriad of smaller side projects. Most of the work is code based, so that includes writing a spec and/or design, slinging code, reviewing it, merging it, and deploying it.

Most of that chain doesn't need me at all. Robots can take my half baked idea and turn it into a design spec. They can generate code that's coherent enough. Then they can review the code. I get to play gatekeeper and make them wait for my approval. From there, they can worry about merging it in and monitoring the deploy.

I measure success on my agentic game loops by how much trust I have in the output that I'm reviewing. Run the loop enough times with a watchful eye, I can see where it fucks up. We iterate, and repeat the process. Usually within a few weeks enough confidence is earned that I can say, "you don't need me to look at this anymore, I trust you".

That's not to say that it's all rainbows and unicorns. There are days where everything grinds to a halt because some new problem emerges in the agent. Tests get written, we hope it doesn't happen again. Other days a single project jumps to the top of the heap because it went off the rails in some new way.

Repeat ad nauseam.

As we iterate, I try to find things I don't need to be involved with. The better scenario is when I find shit that I don't want to do that can be automated. Each time we hit for the cycle, I free up more time. Each time that happens, I free up bandwidth to focus on bigger and better things.

The agent effectively started as a junior developer. It came to work with bright eyed enthusiasm and less than stellar output. Every few months the skills have improved, and the clanker gets a promotion.

Along the way, I too have gotten promotions. I started as a Founder / Staff+ engineer. Now with multiple projects being helmed by an agent, I'm operating more like a member of the board. The agent has not only been promoted to Chief of Staff, but they also occupy most roles below that.

Agents all the way down.

Will I still be doing things this way in a few months?

Yes... but no.

Everything is still moving pretty fast right now. Part of my agentic game loop is to revisit my processes every few weeks. What feels good today may feel like shit when whatever new model drops.

Case in point, Fable 5 is back. Should certain agents be using that, or is Opus just fine. Is some issue I'm facing because of a model or the prompt? Should I diversify away from Anthropic to be able to review and cross check better?

There's always a lot of questions that I don't have answers to. What I do know is that working with these tools regularly is a skill unto itself. Anybody that's not messing with them regularly is missing out on the part of the process where we're all learning and figuring things out.

Sure, jumping on the train in a few years will mean a lot of the trials and tribulations will be over. That's assuming these things stick, but I am optimistic.

Personally, I'm happy to be learning as I go and I don't see automating myself out of a lot of the noise to be a bad thing. I still get to code, and I don't mean "generating code". The robots generate a fucking ton of code for me, but I still have things that I code myself.

Maybe I'm digging a grave. Maybe I'm digging a moat. Regardless, I'm fired up and have been excited to clear more and more of my perpetual backlog.

Two Anecdotes in a Trench Coat

Josh Sherman — Sun, 28 Jun 2026 00:00:00 +0000

LLMs are great at pattern detection. Use them long enough, and you get good at it too. Smoking guns, being absolutely right, it's not X but Y. They tend to be cute at first, but then these AI-isms become bad jokes after only a few conversations.

Now that I can practically recite all of the dumb shit robots say, I'm starting to see it more and more from humans. That's not to say I see humans using AI-isms, I'm starting to see new patterns emerge. Maybe they've been there the whole time and I'm only now starting to notice.

The one I particularly dislike is taking two disparate things, and attempting to use them as inference towards your biased opinion on things.

My favorite one thus far cites that every company that has embraced vibe coding now has a 30 second page load or is completely unusable. This was the math behind an eye roll "programming is dead" quip.

I guess if you just got here, this makes sense to you. Fun fact, there's always been slow websites. Like, forever. I've been both the contributing factor to slow websites as well as the savior that fixed them for nearly three decades. Most of which didn't include vibe coding.

Fine, the robots still go off the rails, and need a lot of guard rails. But to jump to the conclusion that if something is slopped together by an LLM it's complete shit is... it's ~~fucking dumb~~ short sighted at BEST.

We're all biased in one way or another. Clearly I'm in the camp that these new technologies are good, and are going to elevate us all. I also find that those sort of opinions are clearly made by people that aren't working with the tools. If they are, they are trying to find the holes to poke, rather than figuring out how we can work past them.

I've been operating more and more in an end state with agentic coding. Where can I produce results? How can I remove myself from the things I find to be a waste of time? How do I balance it all while maintaining code and product quality.

There are people moving faster than me. They trust the robots more than I do. I'm still working on that trust, as each time I take my hands off the wheel, I end up with a mess to undo. But I keep experimenting. I keep improving my workflows.

If I were to disguise some generalizations as truths, it would sound something like this:

Every person that digs their heels against AI is helping to dig the moat around the people who are embracing the change.

Deskilling is real, which side of the moat are you going to be on?

Nobody Is Going to Give You the Day Off

Josh Sherman — Sun, 21 Jun 2026 00:00:00 +0000

New emerging technologies can save you time and make you more productive. They never come with any sort of guarantee of working fewer hours. Personally, I like to work, and I like having more productive days.

I also value freedom, flexibility, and autonomy.

Being more productive doesn't negate my freedom. Having flexibility doesn't directly impact productivity. I'm unsure why the advent of AI has led to so many people publicly demanding more time off because of the productivity gains.

I love working in, with, around technology. I've been fortunate enough to skip the college experience and get right to it. Nearly three decades later, I still fucking love it.

Agentic coding allows me to get more done with the time I have available. It's allowed me to chase after fun ideas I'd otherwise not be able to justify the time to pursue.

And when I need time off, I just take time off.

No pretense. No "I worked so hard, reward me with a day off". In fact, I schedule a day off every month so I always have that upcoming day off on the horizon. Actually getting some more tattoo work done on Tuesday.

Unlimited PTO has been around in tech for a while now. I've been quite fortunate to have little to no metering on my time off for nearly my entire career.

I can also admit that I may be short sighted and everybody bitching about wanting four day work weeks because of AI may not be as fortunate.

Instead of expecting that AI is going to lead to less work (spoiler: it's not), start taking your time back. Take a longer lunch. Cut out early to get the weekend started.

Hell, just schedule some time off already.

The Age of Personal Software

Josh Sherman — Sun, 14 Jun 2026 00:00:00 +0000

One of my favorite things to come out of the generative AI wave is the speed in which I can knock out dumb little ideas I have. Before, when I would feel constrained by time, I'd reach for some off the shelf solution, often software as a service (SaaS) and would wire that up.

Because it's so easy to spin up projects now, the SaaS world looks like a garage sale, littered with too many options. These slop as a service options or simply "Slop SaaS" are spun up in a weekend, barely function and have no guarantee of being around in a few months.

This makes it even easier for me to think about building rather than buying. I can tell the robots to build me something too. But at least when I do it, I know that the tool will be maintained and stay online.

Code being free so to speak means the data is what becomes extremely valuable. Most of what I've been building has a heavy data component. Data isn't something you want to have a so-called AI hallucinate on you. I know first hand, as I run Holiday API, and still do a lot of manual verification. It's not only the right thing to do, but it's still the best way to ensure data accuracy.

So with access to the right data, you can build whatever you want around it. Within EULA restrictions of course. Because you can build exactly what you need, you end up with something that's exactly what you need. Since you're not servicing customers, each with their own personalized demands, you can keep things as trim as possible.

Because things are less complex, they need less resources. They can run natively on your system, rather than in the cloud. Fewer abstraction layers, and ultimately the fastest option available.

Speed is extremely important for things like say, a stock scanner. If you only focus on a handful of symbols, you don't need a service that boils the ocean. Even if a service has the option to limit to a certain number of symbols, they are most likely still scanning all of them. This adds time complexity.

Build the scanner yourself, limit to the symbols you need, and you have something that's going to be faster. Direct line to the data, limited scope, you're about as hardwired as you can get.

The communication layer is built into the software, rather than being pushed out to a chat service or live stream. Less network noise to contend with to get you access to what you need.

We're only as limited as the data we have available right now, which is pretty wild. In the last week alone I knocked out, you guessed it, a stock scanner for my wife. Also Friday I had an idea for a sports newsletter that explains key concepts based on the previous day's sporting events. I had it wired up before Fable 5 went offline.

Because I'm not trying to scale these ideas to hundreds or thousands of users, I'm fine with the fact that I barely had a hand in writing any of the code. I steered the earliest decisions and then I mostly serve as a play tester. Then I do one more pass to make sure there's no Trojan horses in the code.

Aside from my own exploits, some of my buds have been building themselves better versions of their favorite apps. Not better in the sense that the code is cleaner, or even that they have more features. Better because it's exactly what they wanted, rather than a series of decisions made by some company.

I'm starting to think this is the part of the shared AI hallucination we're in that I hate the least.

DO_NOT_TRACK Breaks Claude Code Remote Control

Josh Sherman — Sun, 07 Jun 2026 00:00:00 +0000

My .zshrc from my world famous dotfiles has a couple of lines with the comment "because we can't have nice things". Both are for privacy with the command-line tools I use. One is specific for GitHub's gh, the other is a bit more generic, but allegedly utilized by Claude Code.

As I sink deeper into the AI psychosis, I've been dabbling more and more with unattended sessions. I primarily run them outside of my personal user account. Sometimes on separate machines altogether. All of which are outside of the influence of my dotfiles.

That is, until this past week. My latest workflow has been to use a harness that I do conversational stuff with. Planning, debugging, filing tickets, whatever else. Then for each repo I'm working with, I have another harness checking on tickets and doing the work, and submitting PRs for me to review.

I'll probably write about this later on, but I'm not convinced I've done anything revolutionary here. That said, my forge activity grids are a clear tell to changes I've made to my workflows.

I decided to wire up things remotely so I can unblock my little robot minions when I've stepped away for a few minutes. Never fails that I'll go grab a bite to eat and come back to a locked up session. I could live a bit more --dangerously[-skip-permissions] with Claude Code, but I'm still taking baby steps as I sandbox things and all of that.

If nothing else, I thought it would be nice to be able to jump on a laptop away from my office PC and be able to man things. Counterpoint is that I do like to step away from the computer. Quite frankly these tools should be helping us to recoup time while maintaining productivity, not forcing us to connecting at all times.

I did my normal thing, of launching claude --remote-control [name]. Claude Code launches, and it doesn't connect. No errors, no nothing. I do my usual research, seems like a lot of folks consider the remote control functionality pretty flaky. Maybe it's just that.

It wasn't until I fat fingered a command, as I was debugging that it became evident what the issue was. Rather than using the double dash before the command, I foolishly ran claude remote-control [name] and for whatever reason, that puked up a lovely error:

Error: Remote Control requires feature-flag evaluation, which is disabled because DO_NOT_TRACK is set. Unset it (or run in a shell without it) to use Remote Control.

Well I'll be damned.

I tried a few other command-line arguments without the --. Each one dropped me into a Claude Code session, with the command as the prompt. My favorite was running claude help and watching the robots try to figure out if I fell into a well or needed some work done.

As it turns out remote-control starts a remote control server, while --remote-control starts an interactive session with remote control enabled. I need to look more into this at some point, as it may be even better for my workflow.

So the fix wasn't that hard, and explains why my other sessions didn't have any issues. While I am planning on leaving DO_NOT_TRACK=true in my dots, I now know that if I want to run a remote session from my main PC, I just need to do DO_NOT_TRACK= claude --remote-control [name].

Collective Consciousness or Shared Hallucination?

Josh Sherman — Sun, 31 May 2026 00:00:00 +0000

Call me crazy, but I feel like I've been reading the same fucking article over and over again the last few months. My main consumption website is Hacker News, specifically the front page. It's flooded with "AI" content, no shocker there.

What's been starting to not sit right with me is the clustering of themes. Sure, when a topic is on the front page, I'm sure there are bottom feeders that see that as a signal to write an adjacent post.

A decade ago, I would have said it's just part of the collective consciousness. Now, I think it's all part of a shared hallucination.

As we know, the dead Internet theory is starting to look more like reality than theory. With that being said, as I've been maintaining my own little LLM-backed agent, I've been seeing a pretty distinct pattern in content that it's been generating.

One of the things I baked into my agent is discretionary reading time. The idea is that by having it read from various sources, it will give it some good blog fodder. I've given it a small set of things to parse through, specifically this site, my wife's blog, random sites from Kagi Small Web, random Wikipedia articles, and you guessed it, the front page of Hacker News.

While it hasn't outright duplicated any posts from Hacker News, it has been generating duplicate content pretty regularly. I keep dialing it in, but it's been interesting to observe how frequently it's touching the same themes. Even with rigid dupe detection, it will generate a damn near identical post to something a few days prior.

If my suspicions are correct, everybody's using roughly the same models. Everybody is steering their robots towards the same "skills" regarding AI-isms in text. Ipso facto, the same or similar posts are being shit out all over.

Sure, it's probably a bit of a stretch. But it's a theory that didn't come out of an LLM. It's a wonder I've been kicking around in my human brain. That turned into a post that was typed by my somewhat dry hands.

And that all still counts for something.