Claude and Code and Craft

May 31 2026

This blog post won't come with a catchy title written by AI. Or an exasperated claim about how society is losing its marbles as it leaps into using AI-based tools.

Instead, this will be a brief discussion of how AI influences a topic that I care a lot about: Open Source Software. I’ll make some predictions and, as usual, you can follow-up with me when I inevitably get most of them wrong. ;)

The Context

A few weeks ago, as I walked past four software developers in my office, I noticed something that I never had before: All four had some version of Anthropic's Claude open in some form (Claude Web site, Claude Code in terminal, Claude Code VS Code integration).

It was a first, but not necessarily a cause for alarm. What was more of a cause for alarm was thinking about what this meant for my teams outside of work.

As you might be able to tell from my blog posts, I do a bit of work on open source projects outside of work [MatProGo] [Brom]. These are often small tools that can make your workflow in a robotics project or research project go faster by simplifying a few steps.

These small solutions, I realized, were in danger due to the rise of coding agents. I suspect that coding agents will create a sea change in open source software, and I spent a lot of time worrying about the potential changes.

Rather than worry about all of these things internally, I’d rather put my thoughts down onto paper (or into a computer) to better understand if they are realistic or ridiculous.

What follows is a description SOME of the potential futures that my mind was worrying about and what trends are encouraging them.

Less Contributors (Per Project)

My first concern was that the rise of coding agents might lead to less contributors to open source projects.

This thought comes from my (not-special-at-all) story of getting involved in open source software. It was mainly my interest in fixing a brand new feature in a tool that I used during my PhD (in this case, the optimization toolbox YALMIP).

The story is similar to how a lot of people that I know got involved in the open source community; they fixed some small part of a piece of code that their community used. (I won’t repeat my story here to avoid boring you about bilinear programming problems.) I predict that this entry point to open source will become a door that is hardly ever used in the next few years.

The first reason that I can see is: Developers are often asking for complete rewrites or drop-in replacements of projects rather than building onto community projects.

Now, I’m not talking about using Claude to rewrite a numpy or matplotlib replacement from scratch. Rather, I’m seeing that instead of someone using a popular helper library like trajax to help with trajectory optimization, they ask Claude to build a narrowly scoped tool for just the specific type of trajectory optimization that they want, using the libraries that they already have.

Some people have attached this practice to the new idea of "single use software" or "disposable software"(see these blog posts: "The Disposable Software Paradox", "Single-Use Disposable Applications" for a discussion of that).

The idea, roughly, goes that coding agents make software easy and cheap*, so why not just make your own specialized and (usually) targeted tool and just throw it away whenever it’s not needed anymore.

This gives rise to my second, maybe unexpected prediction.

More Contributions (aka more open source projects)

My second prediction is that we will see more individual open source projects being created than normal.

The number of open source projects always grows as new developers join the community and then their new ideas come into the world. Alongside this natural growth, there were always barriers to entry that slowed down the rate at which they could create new projects. Those barriers were everything from:

• Understanding the technical concepts of their field (e.g., concurrency rules),
• Reading through documentation to understand how low-level shell commands work,
• Learning about the “cultural rules/mores” of the community that they were contributing to (e.g., “what is an acceptable contribution to project X vs. what should be a standalone project”), etc.

Now that the “deep knowledge” of software development tools is embedded in the coding agent and the programmer no longer needs to know it, those barriers to entry are largely gone.

If you’re in certain parts of LinkedIn, then you can already see this wave growing. There are many humble-brag posts about “I took the weekend to build X, find it on GitHub at Y.” or “I spent the last month building A with the coding agent B; Here’s how you can use it to upgrade your workflows in ….”.

And these are just the open source projects that people have the time/confidence to post about on LinkedIn! I’m sure that there are many more that I don’t know about.

On the one hand, this is great.

More open source projects means that it is more likely that: If you have a software problem, then there exists a solution somewhere in the open source ecosystem.

On the other hand, it’s unclear why a programmer should use any of the contributions created with a coding agent. The question I regularly have in the back of my mind is: if the programmer who made tool X just used a coding agent (and if I have my own coding agent), then why not just ask my agent to build a version of X that fits my exact use case?

The question of whether or not to use a given open source project in your own work is not new. So, I suspect that the tools we use to easily “sift through” the options will also be impacted by coding agents.

More Curation!

The simplest form of curation that you can imagine is the “list of best projects for X” that you might’ve run into online.

Most “big topics” from Machine Learning to Solving Differential Equations have such lists. They often are biased by the authors, but they allow readers to cut through the sometimes enormous pile of similar sounding libraries and features that you can find when searching open source.

I predict that much more of this type of curation will be done in the months moving forward.

What would be interesting (but perhaps is not necessary right now) would be if curation tools were extended to help coding agents “choose the right project for the job.” I suspect that, in the same way that most coding agents now have “tools” that help them easily parse files, or generate simple test scripts, they might also need tools that help them pick which one of several similar libraries to use for a given project.

Maybe the community will rally around a benchmarking or other set of tools to make it easier to know when to use which tool.

Conclusion

While these three predictions for the future are neither good nor bad by themselves, I can already see how they may reshape the open source community.

What do you think? Feel free to send me a message with your own predictions or thoughts on the points raised here (or elsewhere!).

Acknowledgements

I want to thank my friend Leo Medrano for proofreading and giving feedback on a version of this post.

Extra Questions

"Is software really easy and cheap?"

I think there are a number of ways to answer this question, but I will say that in this post I mean to only say that software is cheaper to produce than it has traditionally been.

"Why should I use an open source contribution from a coding agent?"

There are a couple of nuances to answering this question that I didn't want to put in the text above.

First, the answer to this question depends on whether or not you have a coding agent. If you do not, then any contribution that helps you is valuable. This is very clear. I assume throughout the post that the reader has a coding agent, but it is very reasonable to consider the perspective of someone who does not.

The second nuance is that this answer depends on whether or not the potential user thinks the contribution is "worth the effort to rewrite". The decision in many developers head is "How long would it take for me to rewrite this contribution with my own agent?" (which mirrored the old question of "How long would it take for me, by myself, to rewrite this contribution?").

I once thought that the barrier to recreating "big" open source projects would keep them safe, but I'm not so sure how "big" is "big enough" anymore. I once thought that these agents would be useful for fixing up single files. Then they started creating complete Python modules. Then, I thought that they might remain limited to single modules and now I'm seeing entire websites/web apps be created by them in less than a day.

While the complexity of replacing a project was once a barrier to replacement, I'm not sure if that's the case anymore.