jdubray

You want to see where AI is driving us, fast? look no further than Google...

So a non-technical friend emailed me with some questions about AI and who is leading, now that Grok and Meta are dropping from the race. He asked as a question, "It seems that Anthropic is leading?"

Gmail suggested a full reply, first time. I never saw Gmail writing entire emails for me before... And Google is not holding back. Nobody is going to catch me saying either. I never saw Claude Code perform terribly, au contraire...

This is shameful. How can you trust AI writing entire documents when they can push the company's agenda at any time.

That is a big problem, a problem, if not addressed will kill that industry. Imagine if, say, a government instructs a Coding Agent (or releases a Coding Agent) that introduces backdoors in your code? Can't happen right?

Vibe coding works beautifully until it doesn't. The ceiling shows up somewhere between prototype and production: no audit trail, no review, no way to evolve the system across multiple deployments, no way to know whether yesterday's change broke today's invariants.

Spec-Driven Development is an emerging practice, but for most people it just means a collection of stale organically structured markdown documents, covering more or less the entirety of the system.

This article introduces the concept of a Sekkei (blueprint) and Generative Lifecycle Management (GLM).

Git repo for Sekkei specification and GLM Server.

Follow up article: - Vibe Designing with Claude Code (using GLM CLI) - How to scale GLM to a small team?

Nav has just open-sourced a new low-code project that is using GraphQL as-a-syntax to define message and event payload formats. The extensible framework currently generates json-schemas, protobufs and client libraries in golang, python and ruby for payload validation.

That problem has not really been solved yet with OpenAPI and other approaches. What is novel here is the elegance and simplicity of the GraphQL syntax used in the context of schema definitions.

The Fed

Actually, TLA+ (again the way I understand it), after nearly 20 years of MDSE, convinced me that I would very rarely need to generate code. It's a much better value proposition to write correctly factored code. TLA+ is one of the most amazing element of Computer Science. Everyone who writes code should have at least a basic understanding of it.

I have created the SAM Pattern [1] (State/Action/Model) based on my interpretation of TLA+. The goal is to make the semantics available to developers. Why not writing code as close as possible to the way it would be specified?

SAM can also be used for stateful API/Microservice orchestrations [2]

If you want a slightly more formal introduction to SAM and its relationship to TLA+ (again, based on my own interpretation) I gave this lecture last month [3].

[1] http://sam.js.org

[2] http://www.ebpml.org/blog15/2015/06/designing-a-reliable-api...

[3] http://cloudsentinel.com/sam-state-machines-and-computation....

Marcus Feitoza wrote an example of the SAM pattern with mithril https://jsfiddle.net/mfeitoza/pvdLkny7/

that is correct

I am the author of the SAM pattern. It is based on the semantics of the work of Dr. Leslie Lamport who got a Turing award for it (TLA+ - Temporal Logic of Actions). TLA+ was popularized by Amazon as a tool to help fix complex defects in AWS.

SAM fixes three approximations that we have been using in Software Engineering for Decades:

- actions can manipulate application state

- assignments are equivalent to mutation

- there is no need to define precisely what is a programming step (for instance when you write a = b + c, is that a step or is it 3 steps: read b,c, compute b+c, mutate the value of a)

To a certain degree, Redux and Elm are trying to address these three approximations as well, but they do it from a FP point of view, not from a TLA+ point of view.

Their definition of action aligns with the one of event and their approach to mutation is immutability. The main difference between SAM and Redux/Elm is the way side-effects are treated. SAM embraces side-effects (in particular asynch calls) while Redux/Elm don't know how to deal with them. Redux for instance breaks its principle #1 (single state tree) by introducing Sagas.

SAM is a factoring of your code that fits in one line of code: V = State(Model.present(Action(event))).then(nextAction)

No need for a nebula of libraries or inventing a whole new language.

Can you please re-read the paper, the whole point of the pattern like Cycle.js is to separate logic from effects. Logic != Code

Sorry, but you just don't get the fact that SAM is reactive/functional and what benefits you can drive from it.

This is not true, please visit the SAM room on Gitter https://gitter.im/jdubray/sam

In a nutshell:

in redux the reducer updates the model as: state.counter += 1 ;

All SAM suggests is that this is an unfortunate coupling, you should write it as: // action function increment(value) { return value + 1 ; }

and then present the output of the action to the model:

state.counter = data.counter ;

Redux does not have any next-action-predicate either.

I am happy to walk you through, here are some links that show how I got there: http://www.ebpml.org/blog15/2014/12/tla/ http://www.ebpml.org/blog15/2015/01/tla-the-die-hard-problem... http://www.ebpml.org/blog15/2015/01/state-machines-and-compu... http://www.ebpml.org/blog15/2015/04/star-based-component-mod... http://www.ebpml.org/blog15/2015/06/sam-the-state-action-mod...

https://bitbucket.org/snippets/jdubray/ Can also share more code privately