@Casey would it be hard to make an agent built on the work of Michel Foucault and subscribe it to Moltbook?

#moltbook #ai #hardfork #code #technology #philosophy

[About AI assisted coding] All of this is a statistical sifting – using context mapped to code snippets to filter from the set of all possible programs down to the one we need. There isn’t enough time and energy to do this even for a simple application, so we use pattern matching in the embedding to reduce the search space. That’s all that’s happening, when you take away magical AGI mysticism.

On GenAI and Hitchens’ Razor

(Sorry for the LinkedIn link, I don’t think this is posted elsewhere. And thanks to to @cford@toot.thoughtworks.com for surfacing the article.)

[About AI assisted coding] All of this is a statistical sifting – using context mapped to code snippets to filter from the set of all possible programs down to the one we need. There isn’t enough time and energy to do this even for a simple application, so we use pattern matching in the embedding to reduce the search space. That’s all that’s happening, when you take away magical AGI mysticism.

On GenAI and Hitchens’ Razor

(Sorry for the LinkedIn link, I don’t think this is posted elsewhere. And thanks to to @cford@toot.thoughtworks.com for surfacing the article.)

https://www.jamf.com/blog/threat-actors-expand-abuse-of-visual-studio-code/

#vscode #code #malware #cybersecurity

I dig the new #PHP logo. Didn't know until yesterday.

#SoftwareDevelopment #Software #Coding #Code #Logo #Design #GraphicDesign

Contributing to RubyGems (.org)

A few months ago, I wrote about a move that bypassed the maintainers who had built the RubyGems and Bundler projects for decades. I had some questions about trust, governance, and whether Ruby Central could be a responsible steward of our community’s infrastructure.

So it might seem strange that I recently submitted a pull request to rubygems.org.

This post is about that contribution, but it’s also about a question I had to answer for myself: Why help a project when you have concerns about the organization running it?

The Short Answer: the code doesn’t belong to Ruby Central. It belongs to the community.

When I contribute to rubygems.org, I’m not endorsing Ruby Central’s past governance decisions. I’m improving a piece of infrastructure that every Ruby developer depends on, including me, including my team, including developers who have no idea any controversy exists.

The people reviewing my PR weren’t board members making decisions. They were developers like me, with their time spent making the Ruby ecosystem better. Withholding contributions punishes them, not the people who had made the past governance decisions.

The Problem That Got Me Involved

My team had adopted a shared GitHub Actions workflow for releasing our gems. Instead of duplicating release logic across repositories, we maintain one canonical workflow and call it a shared gem release, It’s similar to this:

# In my-gem/.github/workflows/release.yml
jobs:
release:
uses: our-org/shared-workflows/.github/workflows/ruby-gem-release.yml@main

Clean pattern, common in organizations with multiple gems. One problem: RubyGems.org’s trusted publishing feature didn’t support it.

When you use a reusable workflow, the OIDC token from GitHub points to the shared workflow’s location, not your repository. RubyGems.org expected these to match. Our releases were failing. I needed to revert back the old flow, where we have slight release difference in each repo. Not ideal.

I found https://github.com/rubygems/rubygems.org/issues/4294 from 2023. No one had fixed it, yet.

Choosing to Contribute

I had options. I could work around the limitation. I could complain on social media. I could wait for someone else to fix it.

Instead, I decided to fix it myself.

Here’s my reasoning: Open source is bigger than any single organization. RubyGems existed before Ruby Central, and the codebase will outlast whatever governance structure exists today. Contributing good code, code that helps developers, is worthwhile regardless of organizational politics.

If you are going to contribute, you might as well do it well, so here are some tips doing just that and that I kept in mine with my RubyGems feature.

Structure Your Commits Like a Story

Maintainers review a lot of code. Help them follow your thinking: Clear summaries, explanation of why not just what, security implications called out, and reviewer contributions credited.

Write a PR Description That Respects Their Time

Your description is your pitch. Answer these questions immediately:

1. What problem does this solve?
2. How does it solve it?
3. Are there security implications?
4. How can reviewers verify it works?

Mine looked roughly like: Enables trusted publishing for gems using reusable workflows from external repositories

Short. Scannable. No mystery about what’s happening.

Tests Are Your Credibility

Comprehensive tests tell maintainers you’ve thought through edge cases:

The test names describe scenarios. A reviewer can understand what’s verified without reading implementation details. And the security test verifying that mismatched workflows are rejected, matters a lot for authentication code.

Receive Feedback Graciously

This is where contributing gets genuinely valuable. The reviewers know the codebase. Their feedback makes your code better.

I received two pieces of feedback that improved my implementation:

“The validation is tricky to understand. Could we use declarative Rails validations?”

My original:

def workflow_repository_fields_consistency
owner_present = workflow_repository_owner.present?
name_present = workflow_repository_name.present?
return if owner_present == name_present
errors.add(:base, "…")
end

The suggestion:

validates :workflow_repository_owner, presence: true, if: -> { workflow_repository_name.present? }
validates :workflow_repository_name, presence: true, if: -> { workflow_repository_owner.present? }

Same behavior, more idiomatic.

“This query branch is unreachable given your other validation.”

Dead code I hadn’t noticed. The reviewer spotted that my .or() clause could never match because another validation prevented that data state from existing.

Both changes made the code better. I implemented them, credited the reviewers, and the PR was approved.

The Bigger Picture

After my code contribution was merged, I submitted a documentation PR to https://github.com/rubygems/guides explaining how to configure the new fields. Features don’t help if users don’t know they exist.

Now every Ruby developer using shared release workflows can use trusted publishing. That’s a small improvement for potentially thousands of people.

But here’s what I keep coming back to: the people who reviewed my PR, who gave thoughtful feedback, who approved and merged the changes. They’re developers who care about the Ruby ecosystem. They showed up, they did good work, and they made the project better.

Open source is ultimately about people, not organizations. The code is written by individuals. The reviews are done by individuals. The community is made up of individuals who choose to contribute their time.

Ruby Central’s past governance may have disappointed me. But the Ruby community hasn’t.

If You’re Hesitant to Contribute

Maybe you have concerns about other projects’ leadership. Here’s what I’d say:

Contribute to the code, not the org chart. Your pull request improves software that real people use. The maintainers aren’t the executives. Don’t punish them for decisions they didn’t make.

Find a problem you care about. Fix it. Submit the PR. The Ruby ecosystem, our community, is worth contributing to.

The PR discussed in this post is https://github.com/rubygems/rubygems.org/pull/6184. The documentation update is https://github.com/rubygems/guides/pull/410.

Contributing to RubyGems (.org)

A few months ago, I wrote about a move that bypassed the maintainers who had built the RubyGems and Bundler projects for decades. I had some questions about trust, governance, and whether Ruby Central could be a responsible steward of our community’s infrastructure.

So it might seem strange that I recently submitted a pull request to rubygems.org.

This post is about that contribution, but it’s also about a question I had to answer for myself: Why help a project when you have concerns about the organization running it?

The Short Answer: the code doesn’t belong to Ruby Central. It belongs to the community.

When I contribute to rubygems.org, I’m not endorsing Ruby Central’s past governance decisions. I’m improving a piece of infrastructure that every Ruby developer depends on, including me, including my team, including developers who have no idea any controversy exists.

The people reviewing my PR weren’t board members making decisions. They were developers like me, with their time spent making the Ruby ecosystem better. Withholding contributions punishes them, not the people who had made the past governance decisions.

The Problem That Got Me Involved

My team had adopted a shared GitHub Actions workflow for releasing our gems. Instead of duplicating release logic across repositories, we maintain one canonical workflow and call it a shared gem release, It’s similar to this:

# In my-gem/.github/workflows/release.yml
jobs:
release:
uses: our-org/shared-workflows/.github/workflows/ruby-gem-release.yml@main

Clean pattern, common in organizations with multiple gems. One problem: RubyGems.org’s trusted publishing feature didn’t support it.

When you use a reusable workflow, the OIDC token from GitHub points to the shared workflow’s location, not your repository. RubyGems.org expected these to match. Our releases were failing. I needed to revert back the old flow, where we have slight release difference in each repo. Not ideal.

I found https://github.com/rubygems/rubygems.org/issues/4294 from 2023. No one had fixed it, yet.

Choosing to Contribute

I had options. I could work around the limitation. I could complain on social media. I could wait for someone else to fix it.

Instead, I decided to fix it myself.

Here’s my reasoning: Open source is bigger than any single organization. RubyGems existed before Ruby Central, and the codebase will outlast whatever governance structure exists today. Contributing good code, code that helps developers, is worthwhile regardless of organizational politics.

If you are going to contribute, you might as well do it well, so here are some tips doing just that and that I kept in mine with my RubyGems feature.

Structure Your Commits Like a Story

Maintainers review a lot of code. Help them follow your thinking: Clear summaries, explanation of why not just what, security implications called out, and reviewer contributions credited.

Write a PR Description That Respects Their Time

Your description is your pitch. Answer these questions immediately:

1. What problem does this solve?
2. How does it solve it?
3. Are there security implications?
4. How can reviewers verify it works?

Mine looked roughly like: Enables trusted publishing for gems using reusable workflows from external repositories

Short. Scannable. No mystery about what’s happening.

Tests Are Your Credibility

Comprehensive tests tell maintainers you’ve thought through edge cases:

The test names describe scenarios. A reviewer can understand what’s verified without reading implementation details. And the security test verifying that mismatched workflows are rejected, matters a lot for authentication code.

Receive Feedback Graciously

This is where contributing gets genuinely valuable. The reviewers know the codebase. Their feedback makes your code better.

I received two pieces of feedback that improved my implementation:

“The validation is tricky to understand. Could we use declarative Rails validations?”

My original:

def workflow_repository_fields_consistency
owner_present = workflow_repository_owner.present?
name_present = workflow_repository_name.present?
return if owner_present == name_present
errors.add(:base, "…")
end

The suggestion:

validates :workflow_repository_owner, presence: true, if: -> { workflow_repository_name.present? }
validates :workflow_repository_name, presence: true, if: -> { workflow_repository_owner.present? }

Same behavior, more idiomatic.

“This query branch is unreachable given your other validation.”

Dead code I hadn’t noticed. The reviewer spotted that my .or() clause could never match because another validation prevented that data state from existing.

Both changes made the code better. I implemented them, credited the reviewers, and the PR was approved.

The Bigger Picture

After my code contribution was merged, I submitted a documentation PR to https://github.com/rubygems/guides explaining how to configure the new fields. Features don’t help if users don’t know they exist.

Now every Ruby developer using shared release workflows can use trusted publishing. That’s a small improvement for potentially thousands of people.

But here’s what I keep coming back to: the people who reviewed my PR, who gave thoughtful feedback, who approved and merged the changes. They’re developers who care about the Ruby ecosystem. They showed up, they did good work, and they made the project better.

Open source is ultimately about people, not organizations. The code is written by individuals. The reviews are done by individuals. The community is made up of individuals who choose to contribute their time.

Ruby Central’s past governance may have disappointed me. But the Ruby community hasn’t.

If You’re Hesitant to Contribute

Maybe you have concerns about other projects’ leadership. Here’s what I’d say:

Contribute to the code, not the org chart. Your pull request improves software that real people use. The maintainers aren’t the executives. Don’t punish them for decisions they didn’t make.

Find a problem you care about. Fix it. Submit the PR. The Ruby ecosystem, our community, is worth contributing to.

The PR discussed in this post is https://github.com/rubygems/rubygems.org/pull/6184. The documentation update is https://github.com/rubygems/guides/pull/410.

First Claude Code client for Ollama local models

https://github.com/21st-dev/1code

#HackerNews #Claude #Code #Ollama #local #models #AI #development #GitHub

"Code is a liability (not an asset). Tech bosses don't understand this. They think AI is great because it produces 10,000 times more code than a programmer, but that just means it's producing 10,000 times more liabilities.

#Code is a #liability. Code’s capabilities are #assets. The goal of a tech shop is to have code whose capabilities generate more revenue than the costs associated with keeping that code running.

…that's the thing: any nontrivial code has to interact with the outside world, and the outside world isn't static, it's dynamic. The outside world busts through the assumptions made by software authors all the time and every time it does, the software needs to be fixed." @pluralistic

https://pca.st/episode/ff6c7462-2117-43c9-8b45-8829b0d6e5b2

"Code is a liability (not an asset). Tech bosses don't understand this. They think AI is great because it produces 10,000 times more code than a programmer, but that just means it's producing 10,000 times more liabilities.

#Code is a #liability. Code’s capabilities are #assets. The goal of a tech shop is to have code whose capabilities generate more revenue than the costs associated with keeping that code running.

…that's the thing: any nontrivial code has to interact with the outside world, and the outside world isn't static, it's dynamic. The outside world busts through the assumptions made by software authors all the time and every time it does, the software needs to be fixed." @pluralistic

https://pca.st/episode/ff6c7462-2117-43c9-8b45-8829b0d6e5b2

Running Claude Code dangerously (safely)

https://blog.emilburzo.com/2026/01/running-claude-code-dangerously-safely/

#HackerNews #Running #Claude #Code #dangerously #(safely) #code #safety #AI #technology #software #development

I was a top 0.01% Cursor user, then switched to Claude Code 2.0

https://blog.silennai.com/claude-code

#HackerNews #Cursor #User #Claude #Code #Switch #Coding #Journey

Using proxies to hide secrets from Claude Code

https://www.joinformal.com/blog/using-proxies-to-hide-secrets-from-claude-code/

#HackerNews #Using #proxies #to #hide #secrets #from #Claude #Code

proxies #secrets #ClaudeCode #privacy #security #tech

Reading across books with Claude Code

https://pieterma.es/syntopic-reading-claude/

#HackerNews #Reading #Claude #Code #syntopic #reading #books #technology #innovation #literature

🆕 blog! “Should HTML's code blocks be translated?”

I was recently prompted to test my blog's layout when rendered in right-to-left text. Running a website through an automatic translator into a language like Arabic or Hebrew will show you any weird little layout glitches which might occur.

But mechanical translation is a bit of an unthinking brute. In this example, I had a…

👀 Read more: https://shkspr.mobi/blog/2026/01/should-htmls-blocks-be-translated/
⸻
#code #HTML #languages

🆕 blog! “Should HTML's code blocks be translated?”

I was recently prompted to test my blog's layout when rendered in right-to-left text. Running a website through an automatic translator into a language like Arabic or Hebrew will show you any weird little layout glitches which might occur.

But mechanical translation is a bit of an unthinking brute. In this example, I had a…

👀 Read more: https://shkspr.mobi/blog/2026/01/should-htmls-blocks-be-translated/
⸻
#code #HTML #languages

Go-legacy-winxp: Compile Golang 1.24 code for Windows XP

https://github.com/syncguy/go-legacy-winxp/tree/winxp-compat

#HackerNews #GoLang #WindowsXP #Compile #Legacy #Code #Programming #OpenSource

I Taught Myself to Code on a Cracked Android Phone. Now I Can't Get Hired

https://www.rly0nheart.com/posts/life/i-taught-myself-to-code-on-a-cracked-android-phone-now-i-cant-get-hired/

#HackerNews #I #Taught #Myself #to #Code #on #a #Cracked #Android #Phone #Now #I #Get #Hired #coding #journey #self-taught #tech #struggles #Android

Cowork: Claude Code for the rest of your work

https://claude.com/blog/cowork-research-preview

#HackerNews #Cowork #Claude #Code #work #productivity #technology #innovation

Unauthenticated remote code execution in OpenCode

https://cy.md/opencode-rce/

#HackerNews #Unauthenticated #remote #code #execution #OpenCode #security #vulnerability #cybersecurity #hacking #news