My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually unify these into some kernel of app state. Honestly, Postgres already has a lot of these capabilities, but I don’t see an obvious story on the app or product level, providing provably correct sets of states that apps can transition between, and which they can automatically expose to clients in informative ways (this user can like this post, but not edit). It looks colored Petri net shaped to me, but I don’t yet see a simple app state paradigm in the same way that the database has obvious successful boundaries.
Version control might not be a big deal if you are all-in on the database.
Stored procedures are easiest to version by simply defining multiple variants and then incrementally moving the callers in the direction you want. The durability comes from (hopefully) your backups. Point-in-time-recovery is often easier for the business to reason about than a git repository.
Having worked for a business that made a serious go of running everything out of stored procedures, I have to say that lack of version control was a huge problem and effectively limited all development to a single person who held all the rules in their head.
This is essentially what we do. All of our stored procedures, views, etc are kept in *_api schemas. Those schemas just get fully dropped and reinstalled whenever we migrate. It works really well, and has basically zero cognitive load overhead for developers.
In pg19 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... will land, which significantly improves NOTIFY performance. Right now LISTEN/NOTIFY doesn't scale to very busy instances because a `NOTIFY` within a transaction takes a global lock.
Well another POV is, AWS sells RDS instances capable of global lock NOTIFY. Clearly people have been using it despite it being really slow.
It's a terrible architecture but does it matter? This article should really say "AWS is a useful but expensive way to run your apps," which isn't say much of anything at all.
In Taiwan the standard way to drink beer is to get it in large bottles, but shared with a small glass per person. Easy to not drink much that way, and promotes the social “let me fill your glass” behavior. (making it harder to not drink much)
Given the atomization and layering of work, this has become much harder to truly judge. Ten years ago I was excited to join a customer feedback platform - what could be better than helping companies understand their customers and provide better services and products? You can probably see where this is going, but inevitably the tools were just used to better tweak product profitability and eliminate end customer surplus, to the customer company’s benefit. And they were used by the likes of draft kings et al along with the Starbucks and Nikes of the world. I hear people claim that, in capitalism, no one hands are clean, and I am inclined to agree.
It seems that we have forgotten how to distinguish between value and profit, and now celebrate the latter instead of the former. Currency enables ever broader and more niche markets, but the financialization of everything is the Faustian bargain; we gained niche hobbies but lost our souls?
Not only value and profit, but also assets, cash flow and debt.
Altogether in terms of currency, very hard to distinguish in the most meaningful way.
It's too easy for the real non-dollar value element to slip through the cracks, and even end up completely gone, in a system where true value itself is not prominent enough to be recognized as the source of highest growth, like it often happens so many times but has been forgotten.
Success can spoil you too.
Once you've got so much more cash than value at any one time because you've been leveraging a productive opportunity well, and taking profits aside regularly, if you're not careful the currency amount alone can seem like enough on its own.
I too am still investigating the space, but what's attractive to me about CPNs is that they can be both the specification and the implementation. How you describe the CPN in code matters, but I'm toying with a rust + SQL-macros version that makes describing invariants etc natural. My understanding is that for TLA+ you'd need to write the spec, and then write an implementation for it. This might be another path for "describe formally verifiable shape then agentic code it", but it smells to me a little like it wouldn't be doing as much work as it could. I think in this there's an opportunity to create a "state store" where the network topology and invariants ensure the consistency of the "marking" (e.g. state of the database here) and that its in a valid state based on the current network definition. You could say "well SQL databases already have check constraints", and we'd probably use those under the hood, but I am betting on the ergonomics of putting the constraints right next to the things/actions relevant to them.
It is tempting to think that we can delegate describing the mental model to AI, but it seems like all of this boils down to humans making bets, and it also seems like the fundamental bets engineers are making are about the formalisms that encode the product and make it valuable.
Notes are options. Sometimes options for taking action later, sometimes as reference for related action. The bet when writing a note is that its risk adjusted return for those avenues is higher than the opportunity cost.
I also have similar thoughts on turning writing into action and re-entrance, would be interested to hear your thoughts:
This has proven to work well for me, but I’m chafing with git and agentic coding abstractions and looking for a unifying concept. Agent of empires doesn’t feel quite right, but is in the right direction.
I read your post — the `thread` file structure (Bet / Context / Next steps / DoD / Log) is a really clean “re-entrance artifact” for both humans and agents.
One thought: it also gives you a natural closed-loop signal — Log + DoD changes are the feedback, not vague “AI memory”. A tool could surface notes as *options* only when a thread is active, then write back only via diffs to `Next steps` / `Log` (human-approved), keeping it deterministic.
For the git/agentic abstraction itch: what do you want as the single source of truth — the thread file, issues, or git events?
I’m curious why you don’t target an HDL, which seems like it should match very well to llm capabilities, and rely on existing layout solvers for describing the last physical layout step?
reply