Do you not end up breaking half the value of referential integrity doing it that way (e.g. you had to update all the queries but now you have a sharp edge in that all future queries need to remember to be soft delete aware. Not a blocker for sure, just a sharp edge).
You know your system better than me for sure, a random commenter on a website :-D your comment just shocked me out of my daze enough for my brain to say "but I always move the record to another table rather than soft delete" and i felt compelled to give unsolicited and likely wrong opinion.
Yeah, I did consider moving records to shadow tables, but - because of the nature of our data - it requires moving a lot of child records as well, so it's quite a lot of additional churn in WAL, and the same for restore. And this approach has its own challenges with referential integrity.
More than that, though: lots of queries for reporting, and the like, suddenly need to use JOINs. Same for admin use cases where we want them to be able to see archived and live data in a unified view. The conclusion I came to is it doesn't really eliminate complexity for us: just moves it elsehwere.
Totally valid approach though. I'd also considered different views for live versus archived (or live+archived) data. Again, it solves some issues, but moves complexity elsewhere.
The other key point: it's a Ruby on Rails system so the moment you start doing funky stuff with separate tables or views, whilst it is doable, you lose a lot of the benefits of Active Record and end up having to do a lot more manual lifting. So, again, this sort of played against the alternatives.
As I say, not to diss other approaches: in a different situation I might have chosen one of them.
My conclusion - not for the first time - is that soft delete obviously adds some level of irreducible complexity to an application or system versus hard delete no matter how you do it. Whether or not that extra complexity is worth it very much depends on the application and your user/customer base.
For some people, just the ability to restore deleted rows from backup would be enough - and in other cases it's been enough for me - but that is always a bit of a faff so not a great fit if you're optimising for minimal support overhead and rapid turnaround of any issues that do arise.
Thanks for taking the time to write such a high quality reply; this is something I've wondered about for a long time and I appreciate the thought and detail you've shared here. :)
This, make sure the 'active' flag (or deleted_at timestamp) is part of most indexes and you're probably going to see very small impacts on reads.
It then turns into a slowly-growing problem if you never ever clean up the soft-deleted records, but just being able to gain auditability nearly immediately is usually well worth kicking the can down the road.
Articles entire thesis looks like it can be completely de-railed if one activity happened: ai infrastructure firms cease to be able to secure more capital.
Is that likely? History says it's inevitable, but timeframe is an open question.
> ai infrastructure firms cease to be able to secure more capital
If this does occur, unfortunately it isn’t like any of the production capacity is going to immediately shift or be repurposed. A lot of the hardware isn’t usable outside of datacenter deployments. I would guess a more realistic recalibration is 2-3 years of immense pain followed by gradual availability of components again.
yeah 3 years sounds reasonable to me, less than one asset depreciation cycle in business. Pain for you and me, but just a bump in the road for the accounts dept.
My computer, and I think all threadripper systems, has registered ECC DDR5 RAM which I think is the same type used in AI datacenters. Well one half of it, the other half being HBM memory used on video cards, which is soldered to them and non-upgradeable. But the main system memory from a used AI server can become your main system memory.
So that becomes the next question -- will we see an ecosystem of modifications and adapters, to desolder surplus and decommissioned datacenter HBM and put it on some sort of daughterboard with a translator so it can be used in a consumer machine?
Stuff like that already exists for flash memory; I can harvest eMMC chips from ewaste and solder them to cheaply-available boards to make USB flash drives. But there the protocols are the same, there's no firmware work needed...
The thesis wouldn't be "completely derailed", just slightly delayed. The reasons why the powers above are pushing for that dystopian model aren't contingent on AI. If it all went away, we'd have a surge of hardware availability and a drop in prices, followed by the same trends - a slow transition to 'cheaper' remote computing wearing down the more expensive custom PC market, higher prices further reducing demand and creating a spiral until people who want personal computing are a niche market segment that becomes almost extinct. The result is still the same. Everyone will be using thin clients or computers that are more like smartphones or Chromebooks than modern PCs, with most services provided through the tightly-regulated internet via subscription services. It just would take us more time to get there.
The AI bubble feels like it's already starting to burst. Sooner or later the market will see that AI has improved productivity by 20% (or whatever figure) and realise it's much less than the 1000% improvement they've been pricing in.
>> Tesla is the same pattern applied to consumer vehicles
No i'd push back on this because the entire workshop manual is available for free without even registration required. You can literally google and land in the relevant sections and it is of a far higher quality than ford, VAG or bmw as three examples i'm pretty familiar with. I haven't seen the John Deere stuff.
Tesla does have "special tools" for some repair procedures, a practice as old as the auto industry but they don't rely on them to the same extent as BMW for example. Anecdotally, the special tools i'm aware of are genuinely useful - for example, the tool for disconnecting seatbelt anchors saves time vs the traditional bolt - where special tools on other marques are often clearly to workaround a failure of packaging or engineering resulting in tight access for a regular tool.
Their online API access is a little bit annoying, or at least unfriendly to casual home user, specifically the workflow to register an OIDC client, but not insurmountable.
> No i'd push back on this because the entire workshop manual is available for free without even registration required
That's because they were forced by Massachusetts expansion of Right to Repair laws. Before that in 2021, service manuals were withheld and required $3,187 a year or $371.88 a month to see them. Before that in 2018, it was $100/day to view them. Before that, you had to pay and book an appointment and go in person to view them.
yeah this is kind of the point. the manuals being free now is genuinely good, but it happened because Massachusetts forced it, not because Tesla decided openness was good for customers. that pricing history is pretty telling -- $100/day to look at a repair manual for a car you already paid for isn't exactly "we support independent repair."
Craig's point about the special tools being well-designed is fair, I don't think Tesla is uniquely bad on the mechanical side. but the software lockdown is a separate thing from workshop manuals. you still can't get root on the infotainment system or run your own diagnostics without going through their API, which is the part that's more like John Deere than a traditional automaker.
If Tesla making the service manuals free is due to the Massachusetts right-to-repair law, then how do other manufacturers (eg: Ford) still get away with not doing so?
I don't think there's a requirement that they give access for free but they are alone i think in doing so.
Here in the UK (where i also have free tesla repair manual access) i have to pay a daily rate (there are annual subscriptions available) for other marques and i would say it's not cheap.
For example, ford charges me £20/hour or £75/day for access to manuals, wiring diagrams, online connected diagnostics (which sounds more impressive than it is, the UI will show vehicle status like fuel tank level or error codes reported by the various ECUs, without physically connecting to the vehicle, i.e. it's done over the vehicle telemetry link), and the ability to connect via a data link connector device for diagnostics and some reflashing activities. Security activities like key coding require a further (chargeable) registration).
The same setup is available by at least VAG, BMW and Fiat Chrysler (the latter has an annoying extra device registration step the others don't). All chargeable.
I used ghostty for the shell in my agent-manager tool (think something like https://air.dev/ but in SwiftUI. One architectural detail i'm still going back and forth on is: who should own the PTY?
If embedded Ghostty owns it, now i have to have some kind of workaround to instrument what's happening inside the terminal - signals, stdout/stderr events, return code etc.
If my parent agent-manager app owns it, now i don't have the nice clean small interface to ghostty (i'm a fan of John Ousterhout style narrow but deep interfaces, pulling complexity down rather than pushing up to parent).
Not sure if any other ghostty embedders might have advice. It's on my todo list to task a an agent to "gh repo clone" a few ghostty using shells and report on their arch.
>> Misconception 1: specification documents are simpler than the corresponding code
I used to be on that side of the argument - clearly code is more precise so it MUST be simpler than wrangling with the uncertainty of prose. But precision isn't the only factor in play.
The argument here is that essential complexity lives on and you can only convert between expressions of it - that is certainly true but it's is overlooking both accidental complexity and germane complexity.
Specs in prose give you an opportunity to simplify by right-sizing germane complexity in a way that code can't.
You might say "well i could create a library or a framework and teach everyone how to use it" and so when we're implementing the code to address the essential complexity, we benefit from the germane complexity of the library. True, but now consider the infinite abstraction possible in prose. Which has more power to simplify by replacing essential complexity with germane complexity?
Build me a minecraft clone - there's almost zero precision here, if it weren't for the fact that word minecraft is incredibly load bearing in this sentence, then you'd have no chance of building the right thing. One sentence. Contrast with the code you'd have to write and read to express the same.
I've had good success with something along these lines but perhaps a bit more raw:
- claude takes a -p option
- i have a bunch of tiny scripts, each script is an agent but it only does one tiny task
- scripts can be composed in a unix pipeline
#!/usr/bin/env bash
# ai-commit-msg: stdin=git diff, stdout=conventional commit message
# Usage: git diff --staged | ai-commit-msg
set -euo pipefail
source "${AGENTS_DIR:-$HOME/.agents}/lib/agent-lib.sh"
SYSTEM=$(load_skills \
core/unix-output.md \
core/be-concise.md \
domain/git.md \
output/plain-text.md)
SYSTEM+=$'\n\nTask: Given a git diff on stdin, output a single conventional commit message. One line only.'
run_agent "$SYSTEM"
And you can see to keep the agents themselves tiny, they rely on a little lib to load the various skills and optionally apply some guard / post-exec validator. Those validators are usually simple grep or whatever to make sure there were no writes outside a given dir but sometimes they can be to enforce output correctness (always jq in my examples so far...). In theory the guard could be another claude -p call if i needed a semantic instruction.
Do you have examples of these commit messages? I have yet to see an AI write a good commit message. At least when compared to good commit messages -- if it just does better than "wip" or "fix stuff" that's not a high bar.
Context: You are working with Git repositories.
- Commit messages follow Conventional Commits: type(scope): description
- Types: feat, fix, docs, refactor, test, chore, ci, perf
- Subject line max 72 chars, imperative mood, no trailing period
- Reference issue numbers when relevant
So it produces messages like:
$ git diff HEAD~1 | bin/ai-commit-msg
fix(guards): pass input to claude and tighten verdict handling
My issue with this kind of message is that it doesn't convey intent well enough. This kind of commit message will always be like "remove check from handleUser" instead of "fix authorization in xyz case". But I assume these are different schools of commits -- I prefer commits which convey WHY, not WHAT, much like source code comments.
# Build a system prompt by concatenating skill files
# Usage: load_skills core/unix-output.md domain/git.md output/plain-text.md
load_skills() {
local combined=""
for skill in "$@"; do
local path="$SKILLS_DIR/$skill"
if [[ -f "$path" ]]; then
combined+=$'\n\n'"$(cat "$path")"
else
echo "[agent-lib] WARNING: skill not found: $skill" >&2
fi
done
echo "$combined"
}
# Core invocation: reads stdin, prepends system prompt, calls claude -p
# Usage: run_agent <system_prompt> [extra claude opts...]
run_agent() {
local system_prompt="$1"
shift
local stdin_content
stdin_content=$(cat) # buffer stdin
if [[ -z "$stdin_content" ]]; then
echo "[agent] ERROR: no input on stdin" >&2
exit 1
fi
# Combine system prompt with stdin as user message
printf '%s' "$stdin_content" \
| claude -p \
--system-prompt "$system_prompt" \
--output-format text \
$CLAUDE_OPTS \
"$@"
}
# Run agent then pipe through a guard
# Usage: run_agent_guarded <guard_name> <system_prompt>
run_agent_guarded() {
local guard="$1"
shift
local system_prompt="$1"
shift
local output
output=$(run_agent "$system_prompt" "$@")
local agent_exit=$?
if [[ $agent_exit -ne 0 ]]; then
echo "$output"
exit $agent_exit
fi
# Pass through guard
echo "$output" | "$AGENTS_DIR/guards/$guard"
exit $?
}
# For structured output: run agent then validate with jq
run_json_agent() {
local system_prompt="$1"
shift
run_agent "$system_prompt" --output-format text "$@" | guard-json-valid
}
Yep. I am doing all my CAD work with build123d. I think it is much more capable than OpenSCAD due to BREP and Python. A shame that it is still relatively unknown.
There's an extended thinking mode for GPT 5.2 i forget the name of it right at this minute. It's super slow - a 3 minute opus 4.5 prompt is circa 12 minutes to complete in 5.2 on that super extended thinking mode but it is not a close race in terms of results - GPT 5.2 wins by a handy margin in that mode. It's just too slow to be useable interactively though.
That description is NOT coding, coding is a subset of that.
Coding comes once you know what you need to build, coding is the process of you expressing that in a programming language and as you do so you apply all your knowledge, experience and crucially your taste, to arrive at an implementation which does what's required (functionally and non-functionally) AND is open to the possibility of change in future.
Someone else here wrote a great comment about this the other day and it was along the lines of if you take that week of work described in the GP's comment, and on the friday afternoon you delete all the code checked in. Coding is the part to recreate the check in, which would take a lot less than a week!
All the other time was spent turning you into the developer who could understand why to write that code in the first place.
These tools do not allow you to skip the process of creation. They allow you to skip aspects of coding - if you choose to, they can also elide your tastes but that's not a requirement of using them, they do respond well to examples of code and other directions to guide them in your tastes. The functional and non-functional parts they're pretty good at without much steering now but i always steer for my tastes because, e.g. opus 4.5 defaults to a more verbose style than i care for.
It's all individual. That's like saying writing only happens when you know exactly the story to tell. I love open a blank project with a vague idea of what I want to do, and then just start exploring while I'm coding.
There are cases where you need more than htmx / datastar, but i like the explicit calling out of when these boundaries occur (e.g. you've exceeded what "islands" can give you), and i like the gravitational pull to lower levels.
The limitations of HTMX are not the same as the limitations of Datastar. Datastar is a whole other beast with only a few at most vestigial similarities to HTMX.
You can't do virtual scroll over a billion checkboxes in HTMX (I've yet to see anyone manage in react for that matter either), yet you can do it easily in Datastar. [1]
Thanks Carson. Although honestly it's pretty mid compared to what's actually possible in hypermedia.
The only reason I wheel it out is when people say you can't do X (often meaning react like things) with hypermedia.
Honestly, you could probably do it in HTMX if you are prepared to only use out of bounds swaps, morph and SSE. But, that approach has always felt second class, unfinished and against the grain. So stuff like that isn't done.
Always made me sad that you wrote idiomorph (thanks for sharing it with the world) but didn't make it part of HTMX. I guess HTMX 4 will change that?
You know your system better than me for sure, a random commenter on a website :-D your comment just shocked me out of my daze enough for my brain to say "but I always move the record to another table rather than soft delete" and i felt compelled to give unsolicited and likely wrong opinion.
reply