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

spot on! that's exactly who I am and what I do.

thank you for digging, I believe that one was a few months later (MSPDC) but still!

thank you, this is really helpful

Thanks guys, I was expecting this kind of answers. The part that bothers me is: why there is no "standard" wrapper functions (sliders, contact form,...) that you can "theme" with various snippets of HTML/CSS. I would expect it would be a lot more practical to deliver a template as a set of wrapper functions, rather than the raw HTML/CSS as it is always the case.

Is there a product in history that has been more hyped than Google Glass?

This is a B2C device (on the spot customer service, hospitals, ...), nobody wants to look like a freak in front of his friends, nobody is going to talk to this stupid device in public.

Can we just move on with our lives and stop talking a product that is not for sale, pretty much useless, will cost a bundle?

I added some comments to the post to explain that the structure of a User Story has already a foot in the solution space. I view this somewhat as an issue.

The relationship between a problem and its solution (one of many) is a graph of states, transitions (decomposition of the problem) and actions (the solution of each transition).

The problem I see with User Stories is that not only we encourage a solution centric thinking but the articulation between the problem and the solution is convoluted (not cleanly expressed as a graph) and often forced fit into a hierarchical tree in tools like Rally.

I have been part of teams who struggle to relate user stories together and I think this is a core problem, there is no clean decomposition possible, like you could achieve with problem statements.

Hope this helps, thank you for your comment.

LoL

Christian,

I wrote this post a month ago to discuss that subjet.

http://www.b-mc2.com/2012/12/06/cooperation-essential-for-in...

I would tend to say that we can express ourselves today in so many ways, but we can't communicate anymore. In that sense we can't share our insight.

Communication by itself does not allow you to elaborate insight. Communication enables cooperation which can sometimes lead to insight, but in the end the words says it all "in-sight".

Actually, not a penny. I am big Apple fan boy and don't like Android that much ... That being said, I have tried to analyze the space as objectively as I could.

Chuck,

did you actually read the post or your position is to say that Social Networks like Facebook and Google+ have reached a point of evolution beyond which not much can happen? In particular that world can't be disrupted?

It's not because you are making money today that you'll be making money in 12 months.

Amazon has a 90 day exclusivity contract for books. But to be frank the gain in revenue would probably be never enough to make it viable.

The best way for Apple to achieve the outcome of attracting the best apps is to deliver the best Platform, which is increasingly questionable.

Don't you think that Social is about to move from reporting events that just happened to organizing your (near) future activities?

Don't you think that Social is about "friends" not "followers"?

Is a Social Utility, a la App.net, the right architecture for that? I don't think so, Google can change the game and own that space, if they choose to.

What's arrogant about that? Maybe you need to re-read the post.

I have developed a similar framework also built on Xtext, but not Applause. The tool is cross-platform and generates back-end data services using PHP/MySQL and HTML forms for the mobile application companion web site. It can also connect to existing HTTP or SOAP based services.

http://www.moppr.com