marxism

Something nobody's really calling out: Forgejo is genuinely hackable. I just added a "showcase" mode to my instance: private repos can show their README and root file listing publicly (so I can advertise that a project exists and what it does), but viewing actual code, cloning, issues, PRs are all locked behind group membership.

About an hour of work, small and frankly trivial diff: https://peoplesgrocers.com/code/forks/forgejo/pulls/1

I didn't have to fight the architecture at all, the seams were right where I needed them. Added migration adding a boolean column to the repo config table, a few tweaks in permission middleware, and voila, it just worked. Really excellent decoupling in the Forgejo codebase [1]

You can't do anything like this with GitHub. That's the actual freedom! Separate from the where-do-I-host-my-git question. There is a big difference between software that "sure technically I can change it since I have access to the source" vs software that's been constructed specifically to be customized and changed.

[1] Permission checks live in obvious places, the template system let me modify UI without touching unrelated code. Someone (many someones) clearly cared a lot about keeping this codebase modifiable by outsiders, and it shows. That's hard to do and should be more celebrated.

Run.

I've used it in a product for a couple of thousand repos. The big problem is architectural. Each branch is serialized into a single bundle file. There is no structural sharing of git objects. So each and every branch will download the full history from scratch. So changing branches is as expensive as a fresh clone. If you combine this with a real user's desire for images/diagrams of any kind, then boom, massive slowness.

There are also two concurrency bugs which the maintainer refuses to acknowledge.

Hey! Happy Coder contributor here. Great timing on this post. I hear you on the reliability issues and feature stagnation. The project went through a rough patch, but we've had some new core contributors come on board and things have picked up significantly.

Planning to release this week (clean out about 100 issues and pulls in 20 of the 30 open PRs). Would love for you to give it another shot once the update drops. And if you hit issues, we're actually responding to them now :)

Importantly for you Leeroy has created a single statically linked binary for self-hosting in this release, no more docker-compose with postgres, redis, node, minio.

Here are the minutes from the the contributor meeting today; I think you'll find your problems addressed:

Jan 25, 2026

  - Karl
      - rebase and merge Ryan Newton's happy-devbox e2e tests.
  - Leeroy
      - Secret sharing session
      - Profiles!!!! Improving
      - Allow to define api keys in app
      - Modals / popovers / overlays
      - Auth fixes
      - Opening a session without auth would still show you the screen, but it won’t work
      - Permissions sticky to the session
      - Codex permissions now applied
      - Claude allowlist
      - Not in codex / gemini - unified this
      - Modified message queue - see in the UI that the message is pending
      - Ask user question - fixed / permission related (will resolve #383)
      - CLI installed / not detection
      - Used in resume features - claude / codex / acp resume
      - Capability registry
      - Agent registry
      - Added opencode!! (will resolve #394)
      - Improved daemon reliability - reattach to sessions that were running with it
      - Tmux / profiles - decoupled
      - Resume sessions from the UI
      - Claude streaming / local / remote - not update the session - missing some messages
      - Local / remote switches not working completely - previously messages in the queue were broken
      - Server light - now in the server, different flavour. Postgress schema / sqlite schema auto synced
      - If you are working with multiple sessions - notifications in app for other sessions
      - [denis overlap] reworked the ACP part, codex / opencode had some duplicated parts. Make it easier to add new agents - works / stable. Tools display - unify it. Normalization layer different providers have different formats! Normalize on the CLI
  - Kirill
      - Server is deployed from main on path modification /server in the monorepo
      - Steve fixed certificates - so ready to release
      - #16 on app store

I'm trying to understand where our viewpoints differ, because I suspect we have fundamentally different mental models about where programming difficulty actually lives.

It sounds like you believe the hard part is decomposing problems - breaking them into subproblems, managing the "big picture," keeping the architecture in your head. That this is where experience and skill matter.

My mental model is the opposite: I see problem decomposition as the easy part - that's just reasoning about structure. You just keep peeling the onion until you hit algorithmically irreducible units. The hard part was always at the leaf nodes of that tree.

Why I think decomposition is straightforward:

People switch jobs and industries constantly. You move from one company to another, one domain to another, and you're productive quickly. How is that possible if decomposition requires deep domain expertise?

I think it's because decomposition is just observing how things fit together in reality. The structure reveals itself when you look at the problem.

Where I think the actual skill lived:

The leaf nodes. Not chipping away until you are left with "this is a min-cut problem" - anyone off the street can do that. The hard part was:

- Searching for the right algorithm/approach for your specific constraints

- Translating that solution into your project's specific variables, coordinate system, and bookkeeping

Those two things - search and translation - are precisely what AI excels at.

What I think AI changed:

I could walk into any building on Stanford campus right now, tap a random person (no CS required!) on the shoulder, and they could solve those leaf problems using AI tools. It no longer requires years of experience and learned skills.

I think this explains our different views: If you believe the skill is in decomposition (reasoning about structure), then AI hasn't changed much. But if the skill was always in search and translation at the leaf nodes (my view), then AI has eliminated the core barrier that required job-specific expertise.

Does this capture where we disagree? Am I understanding your position correctly?

I watched a youtube video showing off Orlog https://www.youtube.com/watch?v=3rW3jtbsxZk.

Challenge accepted. If you get back to me I'll livestream this on Saturday.

I want to be crystal clear about what I'm claiming

My Claim: AI assistance has effectively eliminated specialized job skills as a barrier. Anyone can now accomplish what previously required domain expertise, in comparable time to what a pre-AI professional would take.

Specifically:

- I've never written a game. I've never used a browser rigid body physics library. Never written a WebGL scene with Three.js before. Zero experience. So I should fail write.

- I think I could recreate the full 3D scene, hand meshes, rigging, materials, lighting - everything you see in that screenshot - using AI assistance

- I'm not going to do ALL of that in a couple hours, because even a professional game developer couldn't do it all from scratch in a couple hours. They would have assets, physics engine, rendering engine, textures, etc all because they were creating Orlog inside a larger game that provides all these affordances.

- But I could do it in the same timeframe a professional would have taken pre-AI

My interpretation of your challenge:

You're claiming that writing the multiplayer networking and state management for a turn-based dice game is beyond what AI can help a -- what you called me "run of the mill coder camp wanna be programmer" -- accomplish in a reasonable timeframe. That even with a simple 2D UI, I lack the fundamental programming skills to write the multiplayer networking code and manage state transitions properly.

So here's what I'll build:

A multiplayer Orlog game with:

- Full game logic implementing all Orlog rules and mechanics

- two players can connect and play together

- observers can join and watch

- game state properly synced managed across clients.

- Real dice physics simulation (because otherwise the game feels boring and unsatisfying - I'll grant you that point). But I'll have a server pick the dice roll values to avoid cheating. (Easiest trick in the book, just run the physics offscreen first, find the face that lands up, remap the textures, replay on screen this time), but use a library for simple rigid body physics engine because you couldn't write one from scratch in 3 hours either.

- Visual approach: Simple 2D/indie game cartoon style UI, with dice rolling in a separate physics area (just compositing dice roll app at bottom of screen, results animate onto 2D board, reality is they are totally separate systems)

What I need from you:

1. Is this the right interpretation? You're claiming the networking/state management is beyond what AI can help me accomplish?

2. Time predictions:

   - How long would a competent game developer take to build what I've described?

   - How long will it take me?

Are you willing to make concrete, falsifiable predictions about this specific challenge?

I'm curious: could you give me an example of code that AI can't help with?

I ask because I've worked across different domains: V8 bytecode optimizations, HPC at Sandia (differential equations on 50k nodes, adaptive mesh refinement heuristics), resource allocation and admission control for CI systems, custom network UDP network stack for mobile apps https://neumob.com/. In every case in my memory, the AI coding tools of today would have been useful.

You say your work is "very specific" and AI is "too stupid" for it. This just makes me very curious what does that look like concretely? What programming task exists that can't be decomposed into smaller problems?

My experience as an engineer is that I'm already just applying known solutions that researchers figured out. That's the job. Every problem I've encountered in my professional life was solvable - you decompose it, you research up an algorithm (or an approximation), you implement it. Sometimes the textbook says the math is "graduate-level" but you just... read it and it's tractable. You linearize, you approximate, you use penalty barrier methods. Not an theoretically optimal solution, but it gets the job done.

I don't see a structural difference between "turning JSON into pretty HTML" and using OR-tools to schedule workers for a department store. Both are decomposable problems. Both are solvable. The latter just has more domain jargon.

So I'm asking: what's the concrete example? What code would you write that's supposedly beyond this?

I frequently see this kind of comment in AI threads that there is more sophisticated kinds of AI proof programming out there.

Let me try to clarify another way. Are you claiming that say 50% of the total economic activity is beyond AI? or is some sort of niche role that only contributes 3% to GDP? Because its very different if this "difficult" job is everywhere or only in a few small locations.

I actually agree with everything you said, and I see I failed to communicate my idea that's exactly why I'm so upset.

You said "the only exception here is learning" - and that exception was my hobby. Programming simple things wasn't work for me. It was entertainment. It was what I did for fun on weekends.

Reading a blog post about writing a toy database or a parser combinator library and then spending a Saturday afternoon implementing it myself. that was like going to an amusement park. It was a few hours of enjoyable, bounded exploration. I could follow my curiosity, learn something new, and have fun doing it.

And you're right: if an LLM can solve it with the same quality, it's not a problem worthy of human effort. I agree with that logic. I've internalized it from years in the industry, from working with AI, from learning to make decisions about what to spend time on.

But here's what's been lost: that logic has closed the amusement park. All those simple, fun learning projects now feel stupid. When I see those blog posts now, my gut reaction is "why would I waste time on that? That's one prompt away." The feeling that it's "not worthy" has completely drained the joy out of it.

I can't turn off that instinct anymore. I know those 200 lines of code are trivial. I know AI can generate them. And so doing it myself feels like I'm deliberately choosing to be inefficient, like I'm LARPing at being a programmer instead of actually learning something valuable.

The problem isn't that I disagree with you. The problem is that I agree with you so completely that I can no longer have fun. The only "worthy" problems left are the hard ones AI can't do. But those require months of serious investment, not a casual Saturday afternoon.

I think you're misunderstanding my point. I'm not saying I don't know how to use planning modes or iterate on solutions.

Yes, you still decompose problems. But what's the decomposition for? To create sub-problems small enough that the AI can solve them in one shot. That's literally what planning mode does - help you break things down into AI-solvable chunks.

You might say "that's not real thinking, that's just implementation details." Look who came up the the plan in the first place << It's the AI! Plan mode is partial automation of the thinking there too (improving every month)

Claude Code debugs something, it's automating a chain of reasoning: "This error message means execution reached this file. That implies this variable has this value. I can test this theory by sending this HTTP request. The logs show X, so my theory was wrong. Let me try Y instead."

Here's an example of gold plating from a CLI I created this past weekend.

I did not like the terse errors when parsing JSON. "invalid type: boolean `true`, expected a string", line: 3, column: 24

So I asked for Elm style friendly error messages that try to give you all the information to fix things right up front.

https://github.com/PeoplesGrocers/json-archive/blob/master/s... https://github.com/PeoplesGrocers/json-archive/blob/master/s...

And then since I had time, I asked for some documentation to show/explain the various edge case handling decisions I made.

https://github.com/PeoplesGrocers/json-archive/blob/master/d...

It's gold plating because no one wants or needs my little tool. If I spent that same hour iterating on the output format to be more user friendly while at work, I would be taken out behind the woodshed and shot. It's pure wasted effort.

I'm working on Happy Coder, an open source Codex and Claude Code native mobile app (plus a web app).

Happy lets you spawn and control multiple Codex/Claude Code sessions in parallel. Happy Coder runs on your hardware, works from your phone and desktop, costs nothing, End to End encrypted, and permissive MIT License.

https://github.com/slopus/happy

Happy Coder is a unix style "do one thing well" project.

The goal is zero workflow disruption. I want to be able to run CLI coding agents on any internet connected computer, and control them with my phone. Happy has a command line wrapper for Codex and Claude Code that let you start a session in your terminal, and then continue it from your phone with real time sync. So type in your terminal and see it on the phone, type into your phone and see it in your terminal. So you can switch back and forth.

There is an optional voice agent some contributors have been hacking on that lets you talk to the voice agent first, and the voice agent then writes prompts for Codex/Claude Code and answers questions about what the coding agent running on your computer is doing/did. The voice agent feature is pretty neat, but in my opinion needs a bit more iteration, so any ideas or help would be awesome.

I'm working on Happy Coder, an open source Codex and Claude Code native mobile app (plus a web app).

Happy lets you spawn and control multiple Codex/Claude Code sessions in parallel. Happy Coder runs on your hardware, works from your phone and desktop, costs nothing, End to End encrypted, and permissive MIT License.

https://github.com/slopus/happy

Happy Coder is a unix style "do one thing well" project.

The goal is zero workflow disruption. I want to be able to run CLI coding agents on any internet connected computer, and control them with my phone. Happy has a command line wrapper for Codex and Claude Code that let you start a session in your terminal, and then continue it from your phone with real time sync. So type in your terminal and see it on the phone, type into your phone and see it in your terminal. So you can switch back and forth.

There is an optional voice agent some contributors have been hacking on that lets you talk to the voice agent first, and the voice agent then writes prompts for Codex/Claude Code and answers questions about what the coding agent running on your computer is doing/did. The voice agent feature is pretty neat, but in my opinion needs a bit more iteration, so any ideas or help would be awesome.

Let me rephrase this. I am feeling empathy for the Blue founder because I am in a similar position to show voice control to people and the overwhelming response is "cool, I'll use it while driving". And similar to people here, I don't like that conclusion. So I think it feels bad for the Blue founder to have people pile onto the driving detail that he likely already agrees with meanwhile people ignore the hardware accomplishment.

To me the point of voice control is walking. I'm thinking of Einstein, Darwin, Thoreau. They believed that physical activity helped stimulate his mind and spark creative thought.

You walk, you think, and occasionally you say something.

But in practice people have been quick to jump to conclusions that surprise me. Such as "the point is to try to kill people".

So I'm merely working backwards to figure out why people want to jump in a car first thing.

And the charitable explanation is the people are just not thinking to carefully and are just excited by seeing a computer respond to voice with a low enough error rate.

Counterpoint: don't blame the founder for leading with driving use cases. It's audience selection bias, not the founder being reckless. He's showing what gets traction, not necessarily what he thinks people should actually do

I'm contributing to a similar open source coding tool [1] and I see the same skewed reaction: voice control of "whatever" while driving gets 5-10x the clicks of any other demo.

There's a logical reason so many people think of voice control while driving. It's not because they're reckless.

It reflects the hierarchy of needs. People with long commutes (often younger, lower-paid engineers living further out) spend 2+ hours driving daily.

This is their biggest time sink, so of course they think about making it productive. When you're living far out for cheap housing and hear "coding while driving", its easy to think: finally, a way to get ahead without choosing between career growth and seeing my family.

Again, I think its just an off-the-cuff reaction, not actually what people will do. Just like people try your app and tell you its amazing but then never pay. Doing stuff while driving just sounds nice until you know... you think about it for 3 seconds and yeah, its bad idea.

[1] https://github.com/slopus/happy

I really liked the definition of reverse-centaur

A reverse-centaur is a machine that is assisted by a human being, who is expected to work at the machine’s pace.

This exactly describes the attitude of a PM I work with who makes abundant use of ChatGPT to generate PRDs.

We get so much crap for not keeping up with the flood of requirements. "Why don't you just plug my specs into Claude Code, review it, just tell Claude what needs to be fixed?" Its exhausting.

I really do feel like a reverse-centaur. I'm genuinely expected to work at the pace of this rube goldberg bullshit machine this PM has rigged up.

Hey, you mentioned needing a web UI for your agent.

I contribute to Happy Coder, an open source agent client (mobile app, desktop app, and web app). The project is just a UI layer for existing agents. Adding Codex specific UI and plumbing last week was a 2,600 line diff that took a contributor 3 evenings. And it should be even less plumbing for the next agent.

I'm looking for developers to try integrating their agents and tell me what's broken or awkward. I'd appreciate feedback on where the abstractions leak or what's missing. Even with the friction of using someone else's codebase, it could be less work than starting from zero.

I keep seeing these proprietary clients charge $50/month for basically the same plumbing everyone needs. Selfishly I would like open source and free to win this category here.

GitHub: https://github.com/slopus/happy (MIT License)

I want to weigh in here because I see comments focusing on how these products are useless trash. I think that's missing the point.

This wealthy engineer mindset is too literal. The AI-generated photos and fake reviews aren't bugs. They're features. They let the poor American with $100 of disposable income pretend they found a way to get an Apple Watch for $11. Just for a few days, they get to believe it might be real. When it arrives and it's crap, they knew it would be. But they got to play the fantasy.

TEMU's tagline is "Shop like a billionaire." I want you to really think about that. Marketers test hundreds of combinations to find what resonates. TEMU probably has thousands of marketers. They've tested millions of possible hooks. Millions. And this is what won.

"Shop like a billionaire" is the message that brought new people in the door above all others. Now what about churn? That's not the tagline's job. Don't let your knowledge of what exactly TEMU does and how it functions conceal from you this signal of what many (not all!!) people want.

However I believe they're not scamming people. They're delivering exactly what they're selling, which is the experience of feeling like you could have nice things.

Twenty years ago you could go to a matinee movie for a dollar. Two hours of escapism for a dollar. That product doesn't exist anymore. Theaters decided to serve a different customer base. They went upmarket. But people still want cheap escapism. Now it's $1-3 on TEMU to get that same escape. You browse, you dream, you wait for the package. It's entertainment.

TEMU is making things people want.

I contribute to the Happy Coder app https://github.com/slopus/happy (MIT License)

I've gotten a lot of use out of Claude Code in the past few months. The big problem for me is struggling to stay on top of multiple sessions in parallel. I know that all the cool kids on twitter have all these AI employees and agents farms... A lot of its probably bullshit, but directionally its clear that tooling will absorb some fraction of my workload.

I know I need to push myself to have 2 or 3 balls in the air. But without push notifications to know when Claude Code needs permissions or input, I end up "wasting" time a lot.

So having an app that sends discrete push notifications to my watch is pretty nice.

Oh, and before I forget, I'm pretty excited by the Voice Agent feature another contributor is working on https://x.com/giaccoangelo/status/1960550007272300964

You talk to a voice agent, then voice agent talks to Claude Code. The voice agent acts like a buffer for me to ramble and gather my thoughts. Then the voice agent writes the prompt for claude code when I'm ready. So that unlocked walk and code for me. Now as I walk to the train from the office, I can dump some of the brain ideas into Claude Code plan mode, and they'll be waiting for me in the morning.

Plus I've been using plan mode more and more.

Why a relay server? I want an app to just work with no fuss while running an AI agent on arbitrary consumer hardware. Having both the mobile app and agent wrapper process connect outwards through any firewalls and networks to a third computer on the public internet is the most boring and dumb way for it always to work.

Plus I wanted a system that did not require the app and the computer running the AI agent to both be online at the same time. Having a third computer act as a dumb mailbox handles some corner cases I care about.

I've been trying to surreptitiously get claude code and an oven specific MCP server to run on my friend's smart oven for a prank. However this oven enters a low power state when you don't interact with it; killing the network connection. My vision is to queue up commands via the mobile app with fuzzy logic, and then have the oven make weird noises as determined by claude code at some later point when they go to make a pizza or something.

Yes you can self host the relay server (and please do so!). If you are like me and already have Mac Mini in a closet running docker, k3s, or just have a friend group kubernetes cluster, you can get it running in about 3 minutes.

https://happy.engineering/docs/guides/self-hosting/

https://github.com/slopus/happy-server

There is a Dockerfile, plus a docker-compose.yaml, and a complete Kubernetes template as well.

I've been contributing to an open source mobile app [1] that takes two swings at offering something that Roo does not have.

1. Real-time sync of CLI coding agent state to your phone. Granted this doesn't give you any new coding capabilities, you won't be making any different changes from your phone. And I would still chose to make a code change on my computer. But the fact that it's only slightly worse (you just wish you had a bigger screen) is still an innovation. Making Claude Code usable from anywhere changes when you can work, even if it doesn't change what you can do. I wrote a post trying to explain why this matters in practice. https://happy.engineering/docs/features/real-time-sync/

2. Another contributor is experimenting with a separate voice agent in between you and Claude Code. I've found it usable and maybe even nice? The voice agent acts like a buffer to collect and compact half backed think out loud ideas into slightly better commands for Claude Code. Another contributor wrote a blog post about why voice coding on your phone while out of the house is useful. They explained it better than I can. https://happy.engineering/docs/features/voice-coding-with-cl...

[1] https://github.com/slopus/happy

If the "on the go" experience is important to you, i.e. you actually want some care and intention put into the phone experience. There are 4 apps I'm aware of:

- Happy Claude Code Client: open source (MIT) effort for a quality mobile app

- Omnara: closed source mobile app, $9/month

- CodeRemote: closed source mobile app, $49/month

- Kisuke: closed source mobile app, private beta, unknown price

If you know of others, I would appreciate a PR to update the table I put together, or just let me know and I'll add it.

https://happy.engineering/docs/comparisons/alternatives/#qui...

There are more more desktop apps, probably because those are easier to design.

There's a huge difference between documentation and prompts. Let me give you a concrete example.

I get requests to "make your research code available on Hugging Face for inference" with a link to their integration guide. That guide is 80% marketing copy about Git-based repositories, collaboration features, and TensorBoard integration. The actual implementation details are mixed in through out.

A prompt would be much more compact.

The difference: I can read a prompt in 30 seconds and decide "yes, this is reasonable" or "no, I don't want this change." With documentation, I have to reverse-engineer the narrow bucket which applies to my specific scenario from a one size drowns all ocean.

The person making the request has the clearest picture of what they want to happen. They're closest to the problem and most likely to understand the nuances. They should pack that knowledge densely instead of making me extract it from documentation links and back and forth.

Documentation says "here's everything now possible, you can do it all!" A prompt says "here's the specific facts you need."

Prompts are a shared social convention now. We all have a rough feel for what information you need to provide - you have to be matter-of-fact, specific, can't be vague. When I ask someone to "write me a prompt," that puts them in a completely different mindset than just asking me to "support X".

Everyone has experience writing prompts now. I want to leverage that experience to get cooperative dividends. It's division of labor - you write the initial draft, I edit it with special knowledge about my codebase, then apply it. Now we're sharing the work instead of dumping it entirely on the maintainer.

[1] https://peoplesgrocers.com/en/writing/write-prompts-not-guid...

As you pointed out the examples in the blog post are not an LLM failure. The real failure is asking too little.

Engineers think "the LLM can handle the simple code change, but if I ask for too much it'll fall over." Wrong. Modern LLMs can easily handle a 50-line function plus 50 lines of detailed comments explaining assumptions, performance implications, and what changes would invalidate this approach.

But most engineers are either asking for solutions without enough context or failing to ask the LLM to document its assumptions.

Then they're shocked when they have to reverse engineer out that the code assumes 100 users when they have 100k, or why it's doing individual API calls when they needed batch processing.

Most engineers have never seen good comments, so they don't know they can ask LLMs to write them.

The default LLM comment is just English pseudo-code: "this function takes a user ID and sends them a notification." Completely useless. But that's because most engineers have never experienced comments that explain trade-offs, performance implications, or future system evolution.

Writing clear technical explanations is genuinely difficult. Almost no one does it well. So when you ask an LLM for "comments," you get the same terrible pattern you've seen everywhere else.

But you can literally ask for explanations of assumptions, performance characteristics, and scenarios where this approach would break. The LLM handles it perfectly. You just have to know that's even possible. Makes the code review so much easier.

Most engineers don't, because they've never seen it done.

[1] https://peoplesgrocers.com/en/writing/asking-llms-the-right-...

I have to disagree with Carmack here.

The evidence suggests this isn't AR prep at all. I watched Apple's 20-minute design presentation, and their design team makes the same point repeatedly: Liquid Glass has very narrow guidelines and specific constraints.

Here's the actual design problem Apple solved. In content apps, you have a fundamental trade-off: you have a few controls that need to be instantly accessible, but you don't want them visually distracting from the content. Users are there to consume videos, photos, articles - not to stare at your buttons. But the controls still have to be there when needed.

Before Liquid Glass, your least intrusive option was backdrop blur or translucent pastel dimming overlays. Apple asked: can we make controls even less distracting? Liquid Glass lets you thread this needle even better. It's a pretty neat trick for solving this specific constraint.

So you'll feel like you're seeing Liquid Glass "everywhere" not because Apple applied it broadly, but because of selection bias. The narrow use case Apple designed this for just happens to be where you spend 80% of your phone time: videos, photos, reading messages. You're information processing, not authoring.

Apple's actual guidelines are clear: only a few controls visible at once, infrequent access pattern, only on top of rich content. The criticism assumes they're redesigning everything when they explicitly documented the opposite. People are reacting to marketing tone instead of reading what Apple's design team actually built.

[1] https://peoplesgrocers.com/en/writing/liquid-glass-explained

Just to clarify, when I say 5x code changes, I was thinking of "edit" operations.

My intuition is the tail of low value "changes/edits" will skew fairly code size neutral.

A concrete example from this week "adding robust error handling" in TypeScript.

I ask the LLM to look at these files. See how there is a big try catch, and now I have the code working, there are two pretty different failure domains inside. Can you split up the try catch (which means hoisting some variable declarations outside the block scope).

This is a cursor rule for me `@split-failure-domain.mdc` because of how often this comes up (make some RPCs then validate desired state transition)

Then I update the placeholder comment with my prediction of the failure rate.

I "changed" the code, but the diff is +9/-6.

When I'm working on the higher complexity problems I tend to be closer to the edge of my understanding. Once I get a solution, very often I can simplify the code. There are many many ways to write the same exact program. Fewer make the essential complexity obvious. And when you shift things around in exactly the kind of mechanical transformation way that LLMs can speed up... then your diff is not that big. Might be negative.

I think we're talking past each other. There's always been a threshold: above it, code changes are worth the effort; below it, they sit in backlog purgatory. AI tools so far seem to lower implementation costs, moving the threshold down so more backlog items become viable. The "5x productivity" crowd is excited about this expanded scope, while skeptics correctly note the highest value work hasn't fundamentally changed.

I think what's happening is two groups using "productivity" to mean completely different things: "I can implement 5x more code changes" vs "I generate 5x more business value." Both experiences are real, but they're not the same thing.

https://peoplesgrocers.com/en/writing/ai-productivity-parado...

My reading is this isn't for random engineers but experienced performance engineers with optimized toolchains who can tackle this efficiently. For someone with the right setup, this is likely straightforward work.

It's similar to job descriptions written for specific candidates they plan to hire. The question shouldn't be "why is this bounty so low?" but "what toolchain makes $20K reasonable for someone?"

Performance work in my experience has been largely organizational friction: running projects in various conditions, collecting evidence maintainers accept, maximizing that limited slice of attention people give my CLs, getting compiler improvements merged. These coordination tasks have become much easier to automate with LLMs (e.g., analyzing maintainer comments to understand cryptic 1 line feedback, what are they actually looking for, what do they mean).

My guess is there's an engineer who's either optimized their feedback cycle to under an hour through specialized tooling (more arrows) or is much better at finding the right signal the first time (more wood). I'd like to understand what tools enable that efficiency.

As a fellow engineer, I think I've been there myself. What helped me was realizing that I had the wrong mental model of what "launching" means.

Think of product development like farming: we engineer a product (seed), plant it in the field, and then customer attention (water) nourishes it while our customer support (care) nurtures it over time. Eventually, we harvest the results. In this model, it makes sense that we obsess over the quality of our seeds since that largely determines yield when given sufficient water and care.

When you work at a company, you build something, hit a quality bar, and there's a big launch day. But for indie founders, that model doesn't work well. Let me explain why with an expanded version of this farming analogy:

Think of your product as a seed and your marketing as an irrigation system.

Established companies already have deep irrigation channels dug. Water (customer attention) flows naturally to their fields. Thousands of eyeballs naturally see their products every day through existing marketing channels, social media presence, and brand recognition.

The reason your experience at work makes you believe launching is so crucial is because your company has already built these irrigation channels. They've constructed a system that brings fresh eyeballs to look at proposed solutions each and every day. As an engineer there, you're just putting seeds into already-prepared soil. You get everything ready, then turn a valve to divert customer-attention water from another established field to your new ground. Then you watch your product work (or not) for all these customers and grow.

But as a solo founder, you have no irrigation channels yet. There's no natural flow of attention to what you're building. You don't have a marketing channel established. It feels like you have a tiny cup of attention (your personal network), and that's understandably terrifying. If you spend your one cup of attention on your seed and it doesn't grow, you're screwed. You've used up your limited resource with nothing to show for it.

Your fear likely comes from feeling like you have a small, non-renewable supply of attention. Once used up, that's it.

Here's a thought experiment: Imagine I promised to bring two real potential customers to your house every day (let's say I'd pay you $10,000 for each day I failed, so you know I'm serious). Two real human beings, just like the people you validated the idea with. Brand new. Never seen them before, never see them again.

How would you feel about your product then?

If you knew you'd get fresh eyeballs on your product daily - a guaranteed stream of attention from the right people - the pressure of a "perfect launch" would vanish. You'd just explain your solution, get feedback, fix issues, and try again tomorrow with new people.

I personally believe it's impossible for any engineer to fail if they get 100 days of direct feedback from people. Tell me specifically how getting feedback from a different person each day for 100 days won't work.

Concretely, find where your potential customers already hang out online.

Here's what most people here would advise: Finding people ALREADY looking for a solution:

1) Instead of cold DMs, I searched for posts like "anyone know a tool that..." or "frustrated with [competitor]" and offered genuine help.

2) Leading with help, not sales. My first message is usually answering their question thoroughly.

3) Only AFTER providing value did I mention "I actually built a tool that might help..."

My email is in my profile if you want to talk about it further.

Thanks for the questions!

So far everyone is accumulating clip annotations on video files over time.

I'm thinking of clips as essentially write-only/append-only annotations. Labels or metadata attached to sections of videos rather than new files. The system is designed to support overlapping clips and allows you to filter/view all clips for a video.

To clarify, Video Clip Library is purely a search engine - it doesn't composite or edit videos. Although it will let you re-encode to save space. I built it for scenarios like: "I have a catalog of shots from the last five years, and when working on a new project, I might want to reuse B-roll or footage I've already taken." A YouTuber doing a Then and Now will find footage from their first year.

For me personally, the virtual clips feature will improve my learning process. I'm not a professional videographer. Naturally I spend time studying work from more skilled creators, trying to understand what makes it effective. I'm excited to take notes on specific moments - "these are the places across many different videos where I feel afraid" or "interesting rack focus technique here" - with notes and tags scoped to their own clips. I was already taking these notes in Obsidian. But it wasn't great.

I find a beauty in the layering: I can create overlapping clips that represent different aspects of the same footage - one layer for emotional responses, another for technical observations. Note: here I'm creating them manually one hour here, one hour there over months as I find the time or interest waxes. I might only annotate a few thousand clips across a couple hundred films in my lifetime. That's ok. I don't need the computer to understand the videos perfectly frame by frame.

The professional use case that prompted this feature is different - teams collect footage, then editors assemble compilations and marketing materials months later. They will run AI models to annotate videos as they're ingested, or apply new models to existing catalogs. Then someone with a creative concept can quickly search: "Do we already have footage that supports this idea or do we need to shoot something new?"

I like the virtual clips feature because it does a better job of getting out of the way of how many people think. Before, I was just telling people 'here's your entire video file, good luck.' If you had 5 hours of footage from a sports tournament but your kid was only doing something interesting for 10 minutes total, you were stuck with the whole file.

My perspective is all those hours of raw footage are just raw materials waiting to be shaped into stories, highlights, or presentations. The value is concentrated in a few hotspots.

Jellyfin and Plex appear to have been built on fundamentally different technical assumptions than Video Clip Library. They expect media to remain connected and accessible to the server at all times - when drives disconnect, they often purge those entries from their databases, requiring full rescans when reconnected. It appears Jellyfin only fixed this in Oct 2024.

The reality for many isn't sleek network storage - it's often just a plastic container filled with labeled hard drives sitting in a closet.

Video Clip Library is architected specifically for the archival cold storage workflow where most media is physically offline. The database maintains complete metadata even when drives are disconnected. When you search for 'soccer highlights from 2018,' it not only tells you what file contains that footage but precisely where that physical drive is located: 'in the blue SSD in Alice's desk, bottom drawer'. You can upload pictures of each drive, print out barcodes, write detailed notes. Organization stuff.

This workflow doesn't necessarily make sense for full-time professionals with dedicated workstations, but it's ideal for the long-tail use cases that originally drove me to build this software - normal people with occasional video projects. Of course, as is often the case, people bring it to their day job and start pushing for more business-oriented features. But the genesis of this software was for the individual creator, the freelancer, or small teams of auteurs collaborating on creative projects. A tool to accommodate the stop-and-start reality of passion projects. A poor man's editing with Proxies.