Leo Gorodinski @eulerfx

Founder @CohesiveSystems, Prev: Co-Founder / CTO @AlvysTeam, VPE @JetTechnology cohesive.sh Del Mar, CA Joined May 2008

Tweets

4K
Followers

2K
Following

1K
Likes

24K

Leo Gorodinski @eulerfx

8 hours ago

@aidenybai @ChatGPT The silver lining of agentic engineers thinking they can push to prod on Friday is that I can finally take some time off 😂

0 0 0 156 0

View Details

Leo Gorodinski @eulerfx

17 hours ago

@mjovanovictech Worth noting that developers have always spent more time reading code than writing it. I still like the IDE to navigate code, even if not all of it.

0 0 0 41 0

View Details

@qianl_cs @petereliaskraft The internal abstraction was leaky, but it sounds like you fixed it, so from the DBOS user’s perspective, the abstraction isn’t leaky. That’s arguably the job of a good abstraction: absorb the complexity below rather than expose it above.

0 0 1 34 0

View Details

Leo Gorodinski @eulerfx

2 days ago

Verification power is bounded by the representation in which the system is expressed.

Hillel @hillelogram

2 days ago

I'm seeing a lot of euphoria about how Opus 5.5 is good at TLA+, and this means that all software will soon be formally verified. As a person who loves TLA+ so much he wrote a book on it, I want to throw a particular cold shower on people's enthusiasm by talking about the limits

32 97 781 98K 962

0 0 2 131 0

View Details

Leo Gorodinski @eulerfx

2 days ago

The bitter lesson may apply more readily to procedures than to representations. Models can absorb handwritten reasoning machinery. But if an agent uses TLA+ to state and check semantics, it’s still relying on an explicitly engineered language rather than raw inference over parameters learned by gradient descent. Gradient descent may write code better than you. That doesn’t mean better models make language design obsolete.

0 0 1 61 0

View Details

Leo Gorodinski @eulerfx

3 days ago

@avrldotdev Yes. Patterns whose main value was reducing boilerplate or organizing code become less interesting when code is cheap. But runtime architecture becomes even more important.

0 0 0 24 0

View Details

Leo Gorodinski @eulerfx

3 days ago

The SDLC increasingly optimizes for access to human attention. Complexity gut checks are still something humans do better than agents, perhaps because, for now, we haven’t found a good way to express many of those judgments explicitly.

Alex Kotliarskyi 🇺🇦 @alex_frantic

5 days ago

Code reviews today are mostly about gut checking if the complexity is worth the benefits.

11 41 619 32K 330

0 0 2 137 0

View Details

Alex Kotliarskyi 🇺🇦 @alex_frantic

5 days ago

Code reviews today are mostly about gut checking if the complexity is worth the benefits.

11 41 619 32K 330

View Details

Leo Gorodinski @eulerfx

3 days ago

@JoshARosen That's an important primitive...explicit criteria plus a receipt. The question that arises is what makes those criteria durable across workers and time? That’s the boundary between a better invoke() and system meaning that survives the call. Curious where you draw that line.

0 0 1 23 0

View Details

Leo Gorodinski @eulerfx

3 days ago

@mjovanovictech OpenTelemetry is huge for agentic development…it gives agents a feedback loop from production.

0 0 0 18 0

View Details

Leo Gorodinski @eulerfx

3 days ago

Yes, you can implement durable execution with object storage and a library, and that’s very elegant. But some workflows make that expensive quickly: large state, frequent reloads, high duty cycle, etc. This suggests separating workflow semantics from execution strategy. Define the process once, then realize it with S3 durability or a long-running VM, depending on the workload.

Marc Brooker @MarcJBrooker

3 days ago

The right architecture for durable execution depends on the size of the state, the cost of unloading and reloading it, the type of state, the duty cycle, and the mutation rate. The right answer could be long-running VMs, local snapshots, remote snapshots, S3, a DB, etc.

8 31 303 25K 148

0 0 0 127 0

View Details

Leo Gorodinski @eulerfx

3 days ago

I like the direction, but the hard question remaining is the right level of abstraction. Lean can rule out bad programs, and LLMs can help write the proofs. Back in the day, I tried to use Haskell for general purpose SaaS development and ended up wrestling with monad transformer stacks. Semantically, I could state when effects commute, but operationally, I was managing transformer order. The mistake was representation. I wanted domain logic to describe state transitions, invariants, and required effects, not how those effects were composed or executed. Same lesson wrt verification…it helps, but the bigger move is a language where those domain semantics are first class.

0 0 0 43 0

View Details

Leo Gorodinski @eulerfx

4 days ago

@kmett Looks good to me. Btw, but isn’t reader only a comonad when the environment has a monoid structure? I’ll show myself out 😂

1 0 0 101 0

View Details

Leo Gorodinski @eulerfx

4 days ago

This is a common freight tech failure mode: trying to automate before fixing the plumbing. AI needs much of the same context humans do. And if you want people to trust the decision, they usually need to see the evidence behind it. Same with systems of record more broadly. AI can improve the interface and patch some gaps, but it’s still bounded by the quality of the underlying operational truth. AI makes the foundation matter more.

0 0 2 39 0

View Details

Leo Gorodinski @eulerfx

4 days ago

Agree, and this holds even with a sophisticated type system. The problem is the level of abstraction. If we reason about and verify the system at one level while the implementation expresses another, static checks quickly become indirect and expensive. The representation has to move closer to the level at which humans actually understand the system.

0 0 0 172 0

View Details

Leo Gorodinski @eulerfx

4 days ago

@unclebobmartin Nice. Looking at code visually almost always reveals something symbols alone conceal.

0 0 0 34 0

View Details

Leo Gorodinski @eulerfx

5 days ago

Vibe coding runs into the same wall every abstraction eventually does: generated artifacts are not the same as system meaning. The next layer is explicit semantics…something closer to a new language/compiler rather than just piles of generated code.

Anton Osika @antonosika

a week ago

The Sutro team has spent the last five years doing deep engineering to build secure and reliable software. They’re now becoming part of Lovable.

21 7 168 24K 14

0 1 5 454 0

View Details

Leo Gorodinski @eulerfx

5 days ago

Interesting paper: resource-centric control (pods, deployments, services) is the wrong layer for governing agents. They propose an intent-aware control plane: intent, policy, capability, context, decision, execution plan, plus a decision artifact recording why one plan won. That feels directionally right. The next useful abstraction for agentic systems may not be another resource model, but a model of decisions, authority, and effects.

0 0 1 104 0

View Details

Leo Gorodinski @eulerfx

5 days ago

My rough classification would be: Patterns that rigorously separate semantics from implementation become more important. DDD, analysis patterns, state machines, etc. I’d put deep modules here too. Human comprehension remains key and I think we should make it as deterministic as possible rather than relying on “agentic inquiry” alone. Patterns that encode runtime semantics remain largely unchanged in importance. Sagas, messaging patterns, consistency models, durable execution, actors, outbox/inbox, etc. Adapters/seams are interesting because I think the principle survives more strongly than the usual presentation. On the other hand, patterns primarily concerned with syntactic modularity or boilerplate decline in importance. Now a more speculative claim: DSLs. DSLs never quite achieved the prominence people expected, partly because asking humans to learn and maintain another language was expensive. Agents change those economics. The underlying pattern of formalizing a domain into a constrained language may become considerably more important, even if humans rarely write the DSL directly.