Around 8 years ago I built https://www.taggit.io/ and concluded that the market just wasn't there... Turns out it just wasn't there yet. I know the frustration you're talking about, pitching to PMs. Maybe the iron is hot again, and SotA perf/problem has definitely changed. Would love to chat and commiserate, hit me up if you're interested.
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.
It is self-serving to say "the code base is no longer important" for companies that want to sell you LLM tokens for swarms of agents to have to constantly burn away at a pile of increasingly messy and broken code.
If they can convince people to never look at the code, the people will have no choice but to keep throwing more and more piles of their product at mysterious blobs of codebases that become increasingly difficult and expensive to manage.
Yeah, a bit of hyperbole there. I do think the codebase is still super important. Just less informative maybe, and becomes hard to reconcile with as the amount of changes in a codebase increases by an order of magnitude.
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.
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.
