To start, this is more or less an advertising piece for their product. It's pretty clear that they want to sell you Allium. And that's fine! They are allowed! But even if that was written by a human, they were compensated for it. They didn't expend lots of effort and thinking, it's their job.
More importantly, it's an article about using Claude from a company about using Claude. I think on the balance it's very likely that they would use Claude to write their technical blog posts.
Not sure how I feel about the whole "LLMs learned from human texts, so now the people who helped write human texts are suddenly accused of plagiarizing LLMs" thing yet, but seems backwards so far and like a low quality criticism.
> The specification forces this question on every path through the IMU mode-switching code. A reviewer examining BADEND would see correct, complete cleanup for every resource BADEND was designed to handle.
> The specification approaches from the other direction: starting from LGYRO and asking whether any paths fail to clear it.
> *Tests verify the code as written; a behavioural specification asks what the code is for.*
However this is a blog post about using Claude for XYZ, from an AI company whose tagline is
"AI-assisted engineering that unlocks your organization's potential"
Do you really think they spent the time required to actually write a good article by hand? My guess is that they are unlocking their own organizations potential by having Claude writes the posts.
> Do you really think they spent the time required to actually write a good article by hand?
Given I'm familiar with Juxt since before, used plenty of their Clojure libraries in the past and hanged out with people from Juxt even before LLMs were a thing, yes, I do think they could have spent the time required to both research and write articles like these. Again, won't claim for sure I know how they wrote this specific article, but I'm familiar with Juxt enough to feel relatively confident they could write it.
Juxt is more of a consultancy shop than "AI company", not sure where you got that from, guess their landing page isn't 100% clear what they actually does, but they're at least prominent in the Clojure ecosystem and has been for a decade if not more.
Is it possible for a tool to know if something is AI written with high confidence at all? LLMs can be tuned/instructed to write in an infinite number of styles.
The WikiEDU project has some thoughts on this. They found Pangram good enough to detect LLM usage while teaching editors to make their first Wikipedia edits, at least enough to intervene and nudge the student. They didn’t use it punatively or expect authoritative results however. https://wikiedu.org/blog/2026/01/29/generative-ai-and-wikipe...
They found that Pangram suffers from false positives in non-prose contexts like bibliographies, outlines, formatting, etc. The article does not touch on Pangram’s false negatives.
I personally think it’s an intractable problem, but I do feel pangram gives some useful signal, albeit not reliably.
AI providers also claim to have small marginal costs. The costs of token is supposedly based on pricing in model training, so not that different from eg your server costs being low but the content production costs being high. And in many cases AI companies are direct competitors (artists, musicians etc.)
(TBH it's not clear to me that their marginal costs are low. They seem to pick based on narrative.)
Zero trust security which is becoming increasingly common is based on removing the internal / external network dichotomy entirely. Everything should be assumed to be reachable from the open internet (so SSO, OIDC everywhere.)
I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process.
I'm sure Nix is better, I just haven't needed it yet.
> it requires discipline (you have to make sure you never do manual steps basically)
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
Cool? It’s broken on my iPhone, text appears beneath other text for no discernible reason. The result of AI coding ‘cool’ websites instead of learning how to use CSS properly.
More importantly, it's an article about using Claude from a company about using Claude. I think on the balance it's very likely that they would use Claude to write their technical blog posts.
reply