Happens. Had an idea (simple and stupid one), built it (with LLMs) went to register the domain. Found out somebody had the same idea and already put it there :)
Location: Denver, CO
Remote: Open to remote, would prefer at least some in person time
Willing to Relocation: No
Technologies: Rust, Scala + JVM ecosystem, python, rails, c++, (basically anything with AI now)
Resume/CV: Available upon request
Email: Jordan@parker.sh
15 years of experience developing software at many scales from the frameworks that ran all of twitters services to nimble startups, to large scale data collection pipelines. Most recently, I was the head of engineering for a ~25 person engineering org, and have done consulting in the areas of providing technical due diligence. I'm currently working on projects that make self-hosted computing more accessible to anyone.
(Asking sincerely in good faith - I read this note along with skimming a few of the linked ones, and I'm familiar with gastown)
Can someone explain the value calculation to me? This seems like someone has truly let AI VASTLY expand the codebase of what seems to be a medium sized hobby game to ~10-100x the amount of engineering required. Especially with statements about how wheelhouse, his software factory, has grown to nearly the size of the actual software he's writing. He also mentions several times that wheelhouse is specific to developing the game. Then, he discusses "pulling in beads" which itself seems on my read to be enormously engineered. (note that he also says that you burn a lot of tokens with agents "keeping your beads in sync" and I didn't have the time to figure out what that meant, but it looks like as complicated as it is, beads can't reconcile itself without burning $$$).
It seems like if you answer "yes" at every time you have the question of "can I make AI do this", you end up burning $120k/month in tokens on your side project.
Again, I am not disparaging this- but I feel like I am genuinely missing something and would welcome help understanding it.
I guess this is a question of what you believe code and software engineering writ large is for.
If you believe that good engineering practice matters (in the sense that your software is maintainable, efficient, etc.), then this is horrific because the human has no idea what’s going on and any attempt to fix something by hand would probably uncover enough complications to make you consider rewriting from scratch.
But if your only qualifier is “does it do what I want it to do?” then this is perfectly fine. If you throw out the assumption that a human will ever maintain the code or need to understand it, then who cares if your main branch is full of unused code and it’s outrageously complex.
In a way, I guess this is a similar moment to abstract painting in the early 20th century.
If your assumption was that the point of a painting is to accurately capture a landscape or person, then abstract paintings are an abomination.
If you believe paintings should evoke a feeling and depicting people or landscapes are only one way to get there, you can throw out all the sketching and composing and painting technique.
> If your assumption was that the point of a painting is to accurately capture a landscape or person
I know this is way off-topic, but this oft-repeated disinformation should be quashed wherever it appears. "Accuracy" was never the goal. Look at Hokusai [1], at John Bauer [2], at Jeffrey Catherine Jones [3]. Even at so "realistic" painters as Beksiński [4], or Caspar David Friedrich [5] - even if you were at the site of such a ruined abbey, and it was late evening, and you had the camera of your choice, the resulting photo would look nothing like that - painted in 1810. Look at The Swing by Fragonard [6], from 1768. Trees don't actually grow like that. Light doesn't work like that! You could visit every tree in the world with a camera, and you couldn't even approximate the feeling of that painting.
These were not accidents, it was not that they tried to be photorealistic, and came up short. They were deliberate stylizations. And modern artists, and abstract artists, well educated in the history of art, know this well, but they deliberately spread the lie that accuracy was the goal, that photography made beautiful art redundant, to justify their abominations. Because the sketching and composing and painting techniques were only half about capturing life, while the other half, the more important half (or in the case of composing, the whole), was about evoking a feeling. Something at which they were infinitely better than their modern art successors.
Steve is not making a game, he is _playing_ the game of making games.
It's like playing Factorio but instead building a rocket to escape, you are building a game. Instead of messing around with mining drills and train tracks, he is deploying agents and thinking about how to interface with them.
I think it sounds like a super fun game.
update: with the added benefit that he might see a return on his investment as well!
Want to be the head of a game studio? "Hire" a bunch of game dev agents, put them to work in the software factory, get pretty progress updates and an actual game of sorts along the way.
Want to be the CEO of a startup? Hire a bunch of biz ops agents, and fire them when they make mistakes. Ship an actual website and MVP and make some numbers go up along the way.
If you know you're playing a game its fun and weird. But I worry for the people that don't know they're LARPing...
I haven’t kept up to date on Gastown, but I’m familiar with the mindset.
A lot of people who want to go all-in on AI start with how they currently produce software and they try to add AI everywhere they can until things start going wrong. At this point they’ve found the threshold for “we can automate as much as possible without compromising on quality” and they can expand their AI use when models improve.
A minority of people like Yegge start by automating absolutely everything possible but still trying to get everything to work, even if it’s low quality. At this point they’ve found the threshold for “as automated as possible while still basically working” and they can improve their quality when models improve.
Both sets of people are trying to do the same thing – automate software development as much as possible – but they are approaching it from starting points on the opposite ends of the spectrum. One starts with quality and increases automation; the other starts with automation and increases quality. The latter approach is insane if you have to ship and maintain production quality software, but it’s also where some of the ideas that will be eventually used by the people taking the former approach come from.
Disclaimer: I work at an AI lab [edit: but speak for myself :-)]
The value proposition is an average of 270 commits a day, for $4000/month, and the dramatic improvements to the game Yegge described. Even supposing 2/3 of them are burned on the scaffolding, 90 commits/day (assuming they’re of mostly good quality) would cost multiple engineers, one of which would cost much more than $48k/year.
As another comment said, the ultimate proof will be in the pudding. But I don’t think the value proposition claimed is complicated.
I wouldn't say complicated, and I agree with you that the proof is in the pudding. I looked at the gameplay and if it was something akin to.. let's say "minecraft before minecraft existed", I'd be amazed and see the value right away.
Looking at the game, it doesn't seem like a game that would require as much money to build as he's claiming he uses in credits (although via a loophole that allows him cheaper access). It doesn't look BAD, it just doesn't seem to warrant that much spend.
> would cost multiple engineers, one of which would cost much more than $48k/year.
Have you played the game?
There's no way all this wasted money is comparable to the work of multiple engineers. This is using AI for entertainment, the result isn't an engaging game.
> I am of course using sanctioned cheating: I get all those tokens because I'm an individual, with the Claude Max discount. So it "only" costs me about $5k/month out of pocket, for a 50-agent cluster running on a 512GB M3 Ultra Mac Studio I bought off eBay for $25k.
> So it's not $120k/month of real money, but it's still crazy spend.
I just took a look a both (thanks for the pointer to seastar! cool project). I'd say "sort of but not exactly". It seems like two approaches to solving the same problem.
Silk seems like mostly a scheduler that uses C++'s native coroutines. Seastar is a future-based framework. Both contain a scheduler and enable async coding patterns.
Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?
There's not a word in the English language that really expresses how absolutely stupid the npm ecosystem is and the developers that perpetuate it by importing a package rather than writing 5 lines of code.
I'm far from an expert, but this feels like an oversimplification.
Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control.
Native Ruby Gems execute arbitrary code via extconf.rb.
Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorporated into your build (and so can run code at build time).
PHP Composer packages can ship install scripts or configure themselves as Composer plugins.
The venerable .tar.gz approach to packaging, covering decades of C and C++ code, is all about executing code during installation.
There are measures that can help (e.g., PHP Composer doesn't run install scripts of _transitive_ dependencies) but the JS space is adopting measures that can help too (like pnpm's approve-builds).
But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages.
> PHP Composer packages can ship install scripts
Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "composer -n config allow-plugins.foo/bar true && composer -n require foo/bar"
> The venerable .tar.gz approach to packaging
Which most people don't install directly, but have already had built for them by their distro.
As more and more languages get "package managers", there's an expectation that installing what should just be inert package/library code should not run commands. Sometimes generated files are needed, and the direction seems to be that these package managers should be like distro package managers, where they take the risk of running the build instructions and generate those files for you, serving up os/architecture-specific builds.
This is the direction npm ought to take, and furthermore shouldn't allow things like electron being a small bundle of javascript code that fetches large lumps of binary code from somewhere else on the internet to install. It should all be uploaded to, and sourced from, NPM.
> But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages.
Yes, and these are positive changes. But they aren't security boundaries, and they don't mean that pip won't execute arbitrary code: a malicious update could ship an update with sdist instead of wheels, a malicious pyproject.toml could provide an arbitrary-code `build-backend`, etc., and pip would still function as designed.
I appreciate the clarifications/corrections on PHP.
> Which most people don't install directly, but have already had built for them by their distro.
Yes, but the original claim was that npm is "particularly susceptible to these attacks" because "npm can execute code after install and most package managers don't do that." I don't think that's accurate: we've seen hundreds of NPM packages compromised in multiple high-profile attacks over the last several months, while .tar.gz was used for decades with nowhere near the same number of compromises.
Rather, I suspect it's a combination of factors: Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects. And the extreme popularity of JS, the centralization of NPM + GitHub, and increased usage of automation makes attacks more practical and more lucrative.
Taking a step back from that particular debate, I'm very much in favor of changes like what you describe.
Taking still another step back, I'm not sure that even those will be enough. If I download a package, it's because I intend to run its code at some point: if it's malicious, I may be less automatically hosed than if its postinstall script runs, but I'm still hosed at execution time. I trust my distro packages, not because they don't execute arbitrary code on installation (RPMs and .debs both do), but because I _trust my distro_. NPM et al. simply cannot vouch for every package they host.
> Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects.
This always seems like a very convenient excuse. C also have a very small standard library. And unless you're doing system programming, you often have to find utility library. It's just that those libraries tries to solve their domain instead of splitting themselves into molecules. Before npm, we had good js libraries too like jQuery as a fundamental one, backbone.js, dropzone.js,... where you import a few files (and vendor them in your project) and be done with it.
The issue with NPM is that it led to the creation of weird ecosystem like babel, webpack, eslint,... where instead of having a good enough solution, it was plugins ad infinitum. And other maintainers started doing the same thing, splitting their libraries, and writing libraries where a gist or a blog post would be enough[0]. Cargo is suffering the same[1]
Couldn't you accomplish the same thing by adding a malicious [build-system] to a pyproject.toml file? You can pull in arbitrary code by providing exact URLs for requirements:
That's a very visible Ken Thompson style attack. The modern expectation is that PyPI would be evaluating this build-system section and would only accept build-systems that they trust to turn package distributions into wheels, and the end users only need the wheels. If you need a specific version of hatchling that they know of, that's fine. If you need something they haven't heard of, they should say no.
> most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages
Technically true, but wheels can include a `.pth` which will run arbitrary code as soon as Python is started, which is only marginally less dangerous. Recently exploited in the LiteLLM attack.
That appears to be an exploitable feature of the language, not the package manager per se.
We could then add the philosophical question of asking what's the difference between:
1. Adding malicious code to a package's .pth file that's evaluated automatically on every python invocation
2. Adding malicious code to the package itself that's evaluated automatically on every python invocation _that uses that package_
Packaging systems that don't run arbitrary code when you install a package are more trustworthy than ones that do, but there's still the essential trust you have to place in all code you're installing, directly and indirectly.
/me looks at the `build.rs` file in my Rust's project's `Cargo.toml` and laughs nervously...
(For non Rustaceans: "Placing a file named build.rs in the root of a package will cause Cargo to compile that script and execute it just before building the package.")
aaand many Cargo packages do use it, right now. It became an inseparable part of Rust ecosystem. You cannot build any embedded program or something slightly complex (omg Protobufs!) without build.rs. Not just your own program but all of your dependencies' build.rs is also executed.
I get the need for simple ways to make ecosystem inviting to the new developers. However, I think Cargo was completely mis-designed for simplicity only, where a system language like Rust should shine in its ability to control complexity. With the bad initial design, they invented hacky solutions like build.rs which speaks a string-based language to talk with Cargo!
On top of that crates.io is completely ripe for typosquatting and package overtakes. I think the ecosystem should be completely revamped to a Maven-style namespaced repos and it should require strong GPG signatures.
You're installing code from npm anyway, presumably to execute it at some point on some machine. If it's will be executed from an install script or later during app execution should not really make much of a difference for most devs.
2. Then five more packages appear so you don't have to write that one terrifying line of JavaScript yourself.
3. Then someone writes a wrapper around those five packages.
4. Then someone writes a "modern, lightweight, zero-config" wrapper around the wrapper.
5. Then a framework adopts it, a build tool requires it, and suddenly your todo app has a dependency graph that looks like international diplomacy.
6. Out of 100 devs building the same product, there are now 300 different dependency combinations, all somehow involving 'left-pad' spiritually if not literally.
7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues.
8. The other half were abandoned three years ago but still have 40 million weekly downloads because removing them would break civilization.
9. Pinning dependencies sounds nice until the ecosystem tells you, "sorry, this package only works with Node 22, this plugin needs Node 18, and this transitive dependency has discovered ESM enlightenment."
10. So everyone lives on the bleeding edge, except nobody agrees where the edge is, and the bleeding part is very real.
So yeah, npm is not uniquely cursed because JavaScript devs are worse. It's cursed because it turned code reuse into a lifestyle, dependency trees into rainforests, and 'npm install' into an act of faith.
It was.. but not in the way people generally think. Im not a native english speaker. Therefore, I use chatgpt to fix my comment sometimes. This was done the same way.
I get it and I'm not trying to get down on you, but I've seen people around say this and it bugs me.
I don't know Japanese at all. Sometimes I use LLMs to translate discord messages into Japanese so I can communicate with Japanese people. Then as verification I translate the messages back (with different LLMs) and they usually come out as a near-verbatim version of what I wanted to say. In other words, they don't come out in the chatgpt style of writing.
If I'm able to do that, then chatgpt should be able to fix your English without chatgpt-ifying the whole comment.
Well, I too, don't have anything against a company selling a "good but not open printer", and I don't care if my fridge is open.
However, I hope you see that the behavior reported by Jeff here is just bad. They are either not understanding open source licenses or are acting in bad faith.
reply