stuartaxelowen

Advertising platforms have had this since their inception. They were just motivated because they could be left holding the bag.

Agree on the changing work interface layer going higher to product capabilities, but not on “the code base is no longer important”. It’s easy to dismiss given how easy it is to ask an agent to generate a bunch of code. But the code base encodes the intersection of the orgs learnings and its arc of product growth as well. Good code bases encode the learnings as checks and abstractions that form the foundation for future growth. It would be a mistake to give up this formal language. Personally, I would bet on better abstractions in code bases, and being able to embed your product description in code, for high leverage and verifiability.

This blog post pints to the fact that you need information across scales to make really insightful products and software. You need to understand fundamental mechanisms, strengths, and risks of your software to know where to make bets next. You need to know about the “how” of your optimization system to know which customer asks to deny.

Using layers like the loops described here to abdicate your work is you decoupling from the joint market/engineering value you originally provided.

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.

Why’s that?

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?

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.