weitendorf

I think I know why Go ended up without good enum support.

(Disclaimer, formerly worked at Google and used proto/grpc/go there and now in my own startup in github.com/accretional/collector which tries to address this problem with a type registry and fully reflective API. Not privy to the full history, just reasoning.)

Proto is designed so that messages can be deserialized into older/previous proto definitions by clients even if the server is responding with messages of a more recent version. Field numbers Re what let you to start serializing new fields (add a new field with an unused/the next number) or safely stop setting fields in proto responses (reserve a field) without risking older clients misinterpreting the data as belonging to some existing field they know about. This requires you to encode the field numbers alongside the field data in the proto wire format.

Two major problems: nothing in proto itself enforces that field numbers are assigned sequentially, because there is no single source of truth for the proto schema (you can still have one of your own, but it’s not a “thing” in proto). Also, the whole point of field numbers is that they can be selectively missing/reserved/ignored and allow you to deserialize messages without special handling for version changes in your code at runtime.

So, field numbers aren’t a dense, easily enumerable range of numbers, they’re basically tags that can be any number between 1 and 536,870,911 except for the reserved 19,000-19,999. This smells like serious tech debt/ a design flaw that completely closes the door for even fixing this at Google or anywhere else, because it’s arbitrarily in the middle of the range of field numbers and a leaked implementation detail from the internals. You couldn’t build your own dense field number management/sequential enforcement system on top of proto without ripping that part out, but your existing proto usage relies on that part and changing it would break existing clients because you’re removing field numbers, which is the whole fucking point of proto, and makes it difficult to roll out even if you did fix it yourself.

So, representing union/enumerable types in proto is impossible. For proto enums to have forward compatibility, they have to handle adding new enum values over time, or need to remove and reserve old ones. So, proto enums end up being basically just field numbers. That’s exactly what you see in Golang enums and I don’t think it’s a coincidence: Google has no good way to serialize/deserialize/operate on enumerable enums or union types anywhere they use proto/grpc. Golang inherits this “enums” implementation from protobuf because it’s the context in which it was created.

I'm a big agent proponent myself but I don't think these kinds of companies actually exist yet. It's gotta either be some CTO who learned the word "orchestration" or "agent harness" and decided to play around with that stuff, or pure fantasy from the usual suspects of VC-twitter trying to build FOMO/signal themselves as part of the "in crowd"/drive engagement with hyperbole.

These exist. Just now I triedfinding such a video for a medium-sized contemporary AI devtools product (Mastra) and it took me only a few seconds to arrive at https://www.youtube.com/watch?v=fWmSWSg848Q

There could be a million of these videos and it wouldn't matter, the problem is incuriosity/resistance/change-aversion. It's why so many people write comments complaining about these videos not existing without spending even a single minute looking for them: they wouldn't watch these videos even if they existed. In fact, they assume/assert they don't exist without even looking for them because they don't want them to exist: it's their excuse for not doing something they don't want to do.

> Even if there is a "fully vibe-coded" product that has real customers, the fact that it's vibe-coded means that others can do the same.

I think you are strawmanning what "vibe coders" do when they build stuff. It's not simple one-shot generation of eg twitter clones, it's really just iterative product development through an inconsistently capable/spotty LLM developer. It's not really that different from a product manager hiring some cheap developer and feeding them tasks/feature requests. By the way, competitors can hire those and chip away at your moat too!

> Unless you have a secret LLM or some magical prompts that make the code better/more efficient than your competitions, your vibe coded product has no advantage over competition and no moat

This is just not true, and you kind of make my point in the next sentence: many companies competitive advantages come from distribution, trust, integration, regulatory, marketing/sales, network effects. But also, vibe coding is not really about prompts so much as it is product iteration. Anybody product can be copied already, yet people still make way more new products than direct product clones anyway, because it's usually more valuable to go to market with stronger, more focused, or more specialized/differentiated software than a copy.

Anecdotally I think you're right that the more skilled you are at something, the less utility there is for something that quickly but incompletely takes you from 0 to 90%

But I would generally be skeptical of anybody who claims that all their work is better off starting from 0, the same way I'd be skeptical of someone who claims to not use or need to make google searches about docs/terms/issues as they work.

I'll give you an example of something I understand decently well but get a lot of use out of AI for: bash scripts and unit testing. These are not my core work but they are a large chunk of my work. Without LLMs I would just not write a lot of bash scripts because I found myself constantly looking things up and spending more time than expected getting the script to work across environments / ironing out bugs - I would only write absolutely essential scripts, and generally they'd not be polished enough to check in and share with the team, and just live on my computer in some random location. Now with LLMs I can essentially script in english and get very good bash scripts, so I write a lot more of them and it's easier for me to get them into an acceptable state worth sharing with my team.

Similarly, I really like Golang table tests but hate writing all the cases out and dealing with all the symbols/formatting. Now I can just describe all the different permutations I want and get something that I can lightly edit into being good enough.

I've also found that with domains I am knowledgable enough about, that can translate into being better at going from ~70% to 95% with AI too. In those cases I am not necessarily using AI the same way as someone trying to go from 0->90%: usually they're describing the outcome/goals/features they want relatively informally without knowledge of the known-unknowns and gotchas involved in implementing that. With more knowledge you can prompt LLMs with more implementation/design details and requirements, and course correct away from bad approaches much faster than someone who doesn't know the shape of what they're trying to do. That still comes in handy a lot of the time.

Think about how much time you can save by feeding an API spec/docs into an LLM, telling it create a Go struct for JSON (de)serialization of some monstrous interface like https://docs.cloud.google.com/compute/docs/reference/rest/v1...? Or how much easier it is to upgrade across breaking versions of a language/library when you can just bump the version, note all the places where the old code broke, and have an LLM with an upgrade guide/changelog do all the drudgery of fixing each of the 200 callsites you need to migrate to the next version.

How many 1+ hour videos of someone building with AI tools have you sought out and watched? Those definitely exist, it sounds like you didn't go seeking them out or watch them because even with 7 less hours you'd better understand where they add value enough to believe they can help with challenging projects.

So why should anybody produce an 8 hour video for you when you wouldn't watch it? Let's be real. You would not watch that video.

In my opinion most of the people who refuse to believe AI can help them while work with software are just incurious/archetypical late adopters.

If you've ever interacted with these kinds of users, even though they might ask for specs/more resources/more demos and case studies or maturity or whatever, you know that really they are just change-resistant and will probably continue to be as as long as they can get away with it being framed as skepticism rather than simply being out of touch.

I don't mean that in a moralizing sense btw - I think it is a natural part of aging and gaining experience, shifting priorities, being burned too many times. A lot of business owners 30 years ago probably truly didn't need to "learn that email thing", because learning it would have required more of a time investment than it would yield, due to being later in their career with less time for it to payoff, and having already built skills/habits/processes around physical mail that would become obsolete with virtual mail. But a lot of them did end up learning that email thing 5, 10, whatever years later when the benefits were more obvious and the rest of the world had already reoriented itself around email. Even if they still didn't want to, they'd risk looking like a fossil/"too old" to adapt to changes in the workplace if they didn't just do it.

That's why you're seeing so many directors/middle managers doing all these though leader posts about AI recently. Lots of these guys 1-2 years ago were either saying AI is spicy autocomplete or "our OKR this quarter is to Do AI Things". Now they can't get away with phoning it in anymore and need to prove to their boss that they are capable of understanding and using AI, the same way they had to prove that they understood cloud by writing about kubernetes or microservices or whatever 5-10 years ago.

Generally if something is fast enough/efficient enough that a paying customer can use it without having to worry or actively think about performance and un-bloatedness, that's enough for them. The only people who might complain still are developers who are bothered by the inefficiency and are technically literate enough to notice it, and maybe the users with less powerful/capable devices than the ones the big paying customers use. Generally these groups of people are not the actual customers of these products.

The people who actually pay for slack and discord (eg enterprises that need workplace chat app and decided to go with the "gold standard", consumers with discord servers and such) need the features/tradeoffs choosing featuers over efficiency causing that bloat. They just don't all need the exact same set of those features as the other customers. So because customers are willing to pay for all these features the product tries to ship all of them and becomes bloated.

> Every person I talked to that uses Excel hate how slow it is

But do they make the purchasing decisions behind using Excel?

To be clear I am not really arguing that bloat/overly enterprisey products are good. What I mean that you don't see the world exploding with more elegant products now with agents for the same reason you didn't see the world exploding with them before agents either: the people who pay for those products and build them for a living are not incentivized or necessarily even rewarded for choosing to make them more efficient or elegant when there are other things that customers are asking for with more $$$ behind them.

Back in the day when you found a solution to your problem on Stackoverflow, you typically had to make some minor changes and perhaps engage in some critical thinking to integrate it into your code base. It was still worth looking for those answers, though, because it was much easier to complete the fix starting from something 90% working than 0%.

The first few times in your career you found answers that solved your problem but needed non-trivial changes to apply it to your code, you might remember that it was a real struggle to complete the fix even starting from 90%. Maybe you thought that ultimately, that stackoverflow fix really was more trouble than it was worth. And then the next few times you went looking for answers on stackoverflow you were better at determining what answers were relevant to your problem/worth using, and better at going from 90% to 100% by applying their answers.

Still, nobody really uses stackoverflow anymore: https://blog.pragmaticengineer.com/stack-overflow-is-almost-...

You and most of the rest of us are all actively learning how to use their replacement

Except for maybe an "Excel killer", all those things you listed are not things people are willing to pay for. Also agents are bad at that kind of work (most devs are bad at that stuff, it's why it was something people whined about even before agents).

And funnily enough there are products and tools that are essentially less bloated slack/discord. Have you heard of https://stoat.chat/ (aka revolt) or https://pumble.com/ or https://meet.jit.si/? If not I would guess it's for one of two reasons: not caring enough about these problems to even go looking for them yourself, or their lack of "bloatedness" resulting in them not being a mature/fully featured enough product to be worth marketing or adopting.

If you'd like to see a product mostly made with agents/for agents you can check out mine at https://statue.dev/ - we're making a static site generator with a templating and component system paired with user-story driven "agentic workflows" (~blueprints/playbooks for common user actions like "I need to add a new page and list it on the navbar" or "create a site from the developer portfolio template personalized for my github").

I would guess most other projects are probably in a similar situation as we are: agentic developer tools have only really been good enough to heavily use/build products around for a few months, so it's a typical few-month-old project. But agents definitely made it easier to build.

Consumer AI product posted on a weekend during prime European hours. Brace yourselves!

Actually I would consider this setup to not be very user friendly. This makes a lot of assumptions about the data/format you have available already. Personally I would assume that anything operating on my bank transactions would be through some more turnkey/handsoff integration rather than a direct import.

Puzzle basically does this by hooking directly into my bank and gives me other tools where I can easily use the categorizations

Only a very, very small fraction of open source projects get to the point where they legitimately need committees and working groups and maintainer politics/drama.

> quite a few people would consider "benevolent dictator for life" an outdated model for open source communities.

I think what most people dislike are rugpulls and when commercial interests override what contributors/users/maintainers are trying to get out of a project.

For example, we use forgejo at my company because it was not clear to us to what extent gitea would play nicely with us if we externalized a hosted version/deployment their open source software (which they somewhat recently formed a company around, and led to forgejo forking it under the GPL). I'm also not a fan of what minio did recently to that effect, and am skeptical but hopeful that seaweedfs is not going to do something similar.

We ourselves are building out a community around our static site generator https://github.com/accretional/statue as FOSS with commercial backing. The difference is that we're open and transparent about it from the beginning, and static site generators/component libraries are probably some of the least painful to fork or take issue with their direction, vs critical infrastructure like distributed systems' storage layer.

Bottom line is, BDFL works when 1. you aren't asking people to bet their business on you staying benevolent 2. you remain benevolent.

> fine tune a general purpose LLMs (somehow, as it is much cheaper than starting from scratch, idk?) to behave this way rather than instructing it all the way in

I'd love to do that too but there are basically three ways to teach LLMs how to use it afaik: with data created "in the wild" and a degree of curation or augmentation, or with full-on reinforcement learning/goal-oriented training, or some kind of hybrid based on eg conformance testing and validating LLM output at a less sophisticated level (eg if it tries to call an api that's not in the set that it just saw during discovery, the LLM is being dumb, train it out of doing that).

The thing is they are not really mutually exclusive, and LLM companies will do it anyway to make their models useful if enough people are using this or want to use it. This is what's happened already with eg MCP and skills and many programming languages. Anyway, if prompting works to get it to use it properly it validates that the model can be trained to follow that process too, the same way it knows how to work with React

It does matter because the code needs to still be legible and discoverable and semantic enough for other AI to find it and use it without it being so confusing or painful that they prefer to just write it themselves.

The reason software is so valuable is that it's capital/up-front investment in figuring something out that can continuously deliver value with low or no marginal cost. Rewriting/maintenance/difficulty/figuring out software is marginal cost.

No you're not making it up, this is exactly what some people are working on. Agent frameworks are starting to move towards "dynamic" service discovery/runtime introspection and composition-with-guardrails. Some keywords are "agent mesh", and the general marketing from AI companies about AI "inventors", and agent-driven interfaces like Google's a2ui (which is just a spec)

We recently started working on https://github.com/accretional/collector to serve as a dynamic proto ORM+CRUD server with search and discovery, and features for operating as a node in an "agent/service mesh". The idea is that you can create a uniform interface for data retrieval/search/APIs that lets agents dynamically register, invoke, or discover any data type or service, or write it themselves, then register it locally or share it.

It is feasible to do this stuff now actually, just a bit tricky because most LLMs aren't trained to operate this way without very explicit instructions for how to do so, and for collector specifically the API surface is probably too big. But I am pretty sure neither would take long to fix if enough people were adopting this kind of pattern.

You do learn how to control claude code and architect/orient things around getting it to deliver what you want. That's a skill that is both new and possibly going to be part of how we work for a long time (but also overlaps with the work tech leads and managers do).

My proto+sqlite+mesh project recently hit the point where it's too big for Claude to maintain a consistent "mental model" of how eg search and the db schemas are supposed to be structured, kept taking hacky workarounds by going directly to a db at the storage layer instead of the API layer, etc. so I hit an insane amount of churn trying to get it to implement some of the features needed to get it production ready.

Here's the whackamole/insanity documented in git commit history: https://github.com/accretional/collector/compare/main...feat...

But now I know some new tricks and intuition for avoiding this situation going forward. Because I do understand the mental model behind what this is supposed to look like at its core, and I need to maintain some kind of human-friendly guard rails, I'm adding integration tests in a different repo and a README/project "constitution" that claude can't change but is accountable for maintaining, and configuring it to keep them in context while working on my project.

Kind of a microcosm of startups' reluctance to institute employee handbook/kpis/PRDs followed by resignation that they might truly be useful coordination tools.

Generally I agree with your takes and find them very reasonable but in this case I think your deep experience might be coloring your views a bit.

LLMs can hurt less experienced engineers by keeping them from building an intuition for why things work a certain way, or why an alternative won't work (or conversely, why an unconventional approach might not only be possible, but very useful and valuable!).

I think problem solving is optimization in the face of constraints. Generally using LLMs IME, the more you're able to articulate and understand your constraints, and prescriptively guide the LLM towards something it's capable of doing, the more effective they are and the more maintainable their output is for you. So it really helps to know when to break the rules or to create/do something unconventional.

Another way to put it is that LLMs have commodified conventional software so learning when to break or challenge convention is going to be where most of the valuable work is going forward. And I think it's hard to actually do that unless you get into the weeds and battle/try things because you don't understand why they won't work. Sometimes they do

That's kind of similar to my project collector: https://github.com/accretional/collector

It's protobuf/grpc based but uses json for serialization to make use of sqlite's json filtering functionality. However, it cannot be said to be zero-copy. It serializes binary protos into json and stores the binary protos directly for fast access, which allows you to skip deserialization when pulling out query results

announcing md2ai spec

I completely agree. I don’t think it’s bad for code to be complex if it’s essential complexity that has to go somewhere. To me it’s a red flag when someone cares more about making the code look simple than solving the problem.

I guess what I mean is that you can’t just assume that you can get clever to work if it doesn’t capture some inherent quality of the problem or relies on unrealistic assumptions. In other words, you often can’t just define the abstraction and requirements and iterate/vibes your way from there. Things like the CAP theorem of the discrete number cells in a small blood sample make certain abstractions literally impossible to deliver.

I think this is what software’s value truly is. But the challenge is delivering “clever” without “complex” or leaking out of the abstraction.

Legibility and domain modeling get mixed up with business models and incentives, so good-simple just isn’t the same thing to the people paying for simple and the ones fascinated by simple,

What mongo solved was user adoption and being legible to a specific type of person making a business decision with very high LTV (a web developer handling JSON and needing a scalable database for it they could dump it into). It’s aligned with the purchaser’s needs and incentives and honestly isn’t awful even if it does end up becoming enormously expensive later, because you might just really need a database your team understands and can use asap.

Mongo churns because what’s legible to a purchaser and what captures the essential qualities of some kind of application domain or abstraction are different things. Once immediate growth is covered and you can afford someone who knows a lot about databases to work on yours they’re like “what the hell” because it turns out that it didn’t do what you’d typically consider the bare minimum of a database: https://news.ycombinator.com/item?id=40901573

But what is consistency, and how nitpicky are you about it if your problems seem to be solved well enough that something’s no longer a problem? I like software because there is a certain mystique behind understanding things like “public key cryptography would be useful in any universe with numbers” or “you really couldn’t improve on TCP for what it does”, because these tie in to real world problems but are also universally applicable, so distilling them to their essential form reveals a kind of API of the universe. But you don’t need that to get value from software and computers, you just need to solve your problem, that being, you need a database now or you lose a sale. What’s “simple” or even what counts as a database isn’t legible between the two.

Tech has a lot of money wrapped up in it so there’s a lot of attempts at capturing mindshare and defining things because the payoff is enormous. It just doesn’t sound fun to me to build up a house of cards selling a database that isn’t actually a database and deciding to figure out that whole database thing later when churn, CAC, LTV, and market adoption metrics tell me to. But also, customers really did need to shove json into databases and weren’t too picky about the particulars. So fuck it, this is a database.

This is why I started working on an open source, generic protobuf sqlite ORM + CRUD server (with search/filtering) + type/service registry + grpc mesh, recently: https://github.com/accretional/collector Note: collector's docs are mostly from LLMs, partially because it's more of a framework for tool-calling LLMs than humans

Then this project lets you generate static sites from svelte components (matches protobuf structures) and markdown (documentation) and global template variables: https://github.com/accretional/statue

A lot of the SaaS ecosystem actually has rather simple domain logic and oftentimes doesn't even model data very well, or at least not in a way that matches their clients/users mental models or application logic. A lot of the value is in integrations, or the data/scaling, or the marketing and developer experience, or some kind of expertise in actually properly providing a simple interface to a complex solution.

So why not just create a compact universal representation of that? Because it's not so big a leap to go beyond eating SaaS to eating integrations, migration costs/bad moats, and the marketing/documentation/wrapper.

A huge number of those people only interact with computers as a consumer. Beyond that, maybe schools assignments, texting and other social media, light email, and video games (eg through steam or a console). There is a big gap between that and someone comfortable using git.

Don’t be an asshole to them about that, think about how many developers would do anything it takes to avoid calling someone on the phone. Obviously they can learn it, but they know they’re going to be bad at it for a while (true for both git and phone calls) and they don’t know how long it’s going to take, or the extent of what they don’t know.

The thing about software companies is that they know how to automate and build stuff so why invest the time in learning a CMS if it’s something they could quickly solve for their own use case? Well, the same applies to people who just want to point and click and write, wondering whether it’s worth it to learn what a rebase does.

Open sourcing the TUI is pretty big news actually. Unless I missed something, I had to dig a bit to find it, but I think this is it: https://github.com/mistralai/mistral-vibe

Going to start hacking on this ASAP

This is something that I feel rather conflicted about, because while I greatly dislike the LLM-slop-style writing that so many people are trying to abuse our attention with, I’ve started noticing that there are a large number of people (varying across “audiences”/communities/platforms”) who don’t really notice it, or at least that whoever is behind the slop is making the “right kind” of slop so that they don’t.

For example, I recently was perusing the /r/SaaS subreddit and could tell that most of the submissions were obviously LLM-generated, but often by telling a story that was meant to spark outrage, resonate with the “audience” (eg being doubted and later proven right), and ultimately conclude by validating them by making the kind of decision they typically would.

I also would never pass this off as anything else, but I’ve been finding it effective to have LLMs write certain kinds of documentation or benchmarks in my repos, just so that they/I/someone else have access to metrics and code snippets that I would otherwise not have time to write myself. I’ve seen non-native English speakers write pretty technically useful/interesting docs and tech articles by translating through LLMs too, though a lot more bad attempts than good (and you might not be able to tell if you can’t speak the language)…

Honestly the lines are starting to blur ever so slightly for me, I’d still not want someone using an LLM to chat with me directly, but if someone who could have an LLM build a simple WASM/interesting game and then write an interesting/informative/useful article about it, or steer it into doing so… I might actually enjoy it. And not because the prompt was good: instructions telling an LLM to go make a game and do a write up don’t help me as much or in the same way as being able to quickly see how well it went and any useful takeaways/tricks/gotchas it uncovered. It would genuinely be giving me valuable information and probably wouldn’t be something I’d speculatively try or run myself.

Cool UI! Sorry if it's a dumb question, but do the rotating arcs represent anything in particular?

Might incorporate this into one of my projects (or borrow the idea of implementing a UI on top of LibreHardwareMonitor), thanks for making this!

Kind of a weird hyper-literal interpretation of "servant leadership" IMO. Upskilling and empowering your team, not making yourself a SPOF, treating your adult colleagues like adults, all sounds like servant leadership to me...

Their license does not allow you to modify it and then offer it as a service to others: https://github.com/hashicorp/nomad/blob/main/LICENSE

You can't really do anything with it except work for Hashicorp for free, or create a fork that nobody is allowed to use unless they self-host it.

I'm working on a similar project (here's the v0 of its state management and the libraries its "local control plane" will use to implement a mesh https://github.com/accretional/collector) and worked on the data plane for Google Cloud Run/Functions:

IMO kubernetes is great if your job is to fiddle with Kubernetes. But damn, the overhead is insane. There is this broad swathe of middle-sized tech companies and non-tech Internet application providers (eg ecommerce, governments, logistics, etc.) that spend a lot of their employees' time operating Kubernetes clusters, and a lot of money on the compute for those clusters, which they probably overprovision and also overpay for through some kind of managed Kubernetes/hyperscaler platform + a bunch of SaaS for things like metrics and logging, container security products, alerting. A lot of these guys are spending 10-40% of their budget on compute, payroll, and SaaS to host CRUD applications that could probably run on a small number of servers without a "platform" team behind it, just a couple of developers who know what they're doing.

Unless they're paying $$$ each of these deployments is running their own control plane and dealing with all the operational and cognitive overhead that entails. Most of those are running in a small number of datacenters alongside a bunch of other people running/managing/operating kubernetes clusters of their own. It's insanely wasteful because if there were a proper multitenant service mesh implementation (what I'm working on) that was easy to use, everybody could share the same control plane ~per datacenter and literally just consume the Kubernetes APIs they actually need, the ones that let them run and orchestrate/provision their application, and forget about all the fucking configuration of their cluster. BTW, that is how Borg works, which Kubernetes was hastily cobbled-together to mimic in order to capitalize on Containers Being So Hot Right Now.

The vast majority of these Kubernetes users just want to run their applications, their customers don't know or care that Kubernetes is in the picture at all, and the people writing the checks would LOVE to not be spending so much and money on the same platform engineering problems as every other midsize company on the Internet.

> what is the use case or benefit of not having a control plane?

All that is to say, it's not having to pay for a bunch of control plane nodes and SaaS and a Kubernetes guy/platform team. At small and medium scales, it's running a bunch of container instances as long as possible without embarking on a 6-24mo, $100k-$10m+ expedition to Do Kubernetes. It's not having to secure some fricking VPC with a million internal components and plugins/SaaS, it's not letting some cloud provider own your soul, and not locking you in to something so expensive you have to hire an entire internal team of Kubernetes-guys to set it up.

All the value in the software industry comes from the actual applications people are paying for. So the better you can let people do that without infrastructure getting in the way, the better. Making developers deal with this bullshit (or deciding to have 10-30% of your developers deal with it fulltime) is what gets in the way: https://kubernetes.io/docs/concepts/overview/components/

This is exactly what we're trying to build with https://github.com/accretional/statue - you can email me or hit me up on Linkedin to get early access to our free static site hosting (which our new site for the project at https://statue.dev runs on, and which will Soon™ have a public-facing product doing exactly what you just asked for)

Basically you'll be able to edit the markdown for your site in a souped up version of our lightly reskinned vscode IDE at https://brilliant.mplode.dev and instantly publish/preview the changes in the same browser tab in a pane. Brilliant comes with a full Linux environment running in a container on our cloud platform, and building a Statue static site is already a one-command operation. The little UI we're working on let's nontechnical people skip that and just edit files and click buttons to make changes and publish it, though.

Here's a one-liner that will get you an entire static site with content (not the landing page yet, though) you can edit via markdown:

yes | npx sv create . --template minimal --types ts --no-add-ons --install npm && npm install statue-ssg && npx statue init && npm install && npm run dev