Cause & Effect

Get support from the Effect community

John A. De Goes joins Johannes Schickling and Michael Arnaldi to discuss how AI is reshaping software engineering, what developers should still learn, and why Effect’s primitives are especially valuable for coding agents.

John is the creator of ZIO, as well as CEO of Ziverge and Golem Cloud.

Learn more about and follow John:
X // Linkedin

Mentioned in the episode:
Ziverge x Effectful Partership
Effect TS Workshop
The Primitive is the product blog post.

Effect is an ecosystem of tools to build production-grade software in TypeScript.

#Effect #TypeScript #Ziverge #ZIO #softwareDevelopment

Song: Dosi & Aisake - Cruising [NCS Release]
Music provided by NoCopyrightSounds
Free Download/Stream: http://ncs.io/Cruising
Watch: http://ncs.lnk.to/CruisingAT/youtube

(00:00) - Intro, From ZIO to Effect
(06:54) - Software engineering in the age of AI
(12:34) - More developers, but a wider skill gap
(23:03) - What is still worth learning?
(29:40) - Closing the loop around coding agents
(39:10) - Preventing engineering skills from atrophying
(47:20) - Effect through the eyes of ZIO’s creator
(52:42) - Why Effect’s primitives matter more with AI
(58:05) - Teaching coding agents to write good Effect code
(01:01:25) - Rethinking tests, DRY, and boilerplate
(01:08:45) - The Effect Companion
(01:18:16) - A role-playing game for learning Effect
(01:25:05) - Turning knowledge into a product

What is Cause & Effect?

Explore how software engineers use Effect to build reliable, production-ready software in TypeScript.

In an age in which like you can make code

for free by pushing buttons.

What matters is the shape of the

primitives and how they snap together

to solve problems and Effect

TS has that it's those primitives that

can be used to efficiently solve

a huge range of problems in building

reliable cloud software.

You know, not only do the primitives

matter, still matter.

The primitive is the product as Amplify

would say, but also even if there's

a ramp up curve to learning the

primitives, it doesn't

really matter anymore.

And that is to say we can choose better

primitives in the era of agentic

coding than we could before, because

before you had to convince a bunch

of humans to learn stuff and you don't

have to convince agents to learn stuff.

Snap your fingers

and they already know it.

And that's what's Effect TS: better

primitives for

building reliable software.

And you can make your coding agent use

it, even if it's never seen them before.

Welcome, John and Mike. Very, very

excited to have you

both on the show today.

John is the absolute foundation that

has led to Effect as it is today.

So is Mike. I think we'll revisit later

the way how John put it

best at the Effect Days 2024,

I believe it was, with like a little fish

of like Haskell, ZIO and Effect.

But we will come back to that later. But

John is the creator of ZIO,

which was the intellectual

foundation for what became Effect later

due to Mike's work. And so

today I'm very delighted to

have you both on the show to talk about

where Effect is coming

from, where it's going, and

which weird time we're in today with AI.

So welcome to the two of

you. And John, if you want

to briefly introduce yourself, that would

be great. Thank you so

much. And also thank you for the

invitation to be here on the podcast.

It's a pleasure. So

currently I am CEO of Ziverge.

And Ziverge used to be a Scala

development shop doing Scala

consulting and training and team

extension. But now we're increasingly

getting into the Effect TS

ecosystem, and trying to help

build stuff there as well as training

developers on Effect TS, do a lot more in

TypeScript. And we're

also doing more in Rust these days. And

then I'm also CEO of a company called

Golem Cloud, which is

a tiny little startup incubated from

Ziverge, which is building

a durable runtime for agents

and their tools. And then at nights and

weekends, I spend coding

some open source pretty much,

and I'll do some Scala development in

the ZIO ecosystem, and then miscellaneous

stuff here and there.

That's awesome. And Mike, everyone knows

presumably who you are in the Effect

ecosystem. But for those

two who don't know, would you mind

briefly introducing yourself?

Sure. I'm Mike. I'm the original author

of Effect. I've been a

software developer for

the good part of the past 20 years. I

always worked in startups,

always kind of at the edge

of what's possible within a language. And

it just so happens that

about six years ago, I found

ZIO in Scala. That point in time I was

dipping my toes into other languages.

I mean, extra TypeScript to see if I

could bring something to

TypeScript that would make it

possible to build production grade

systems at scale. And I found the ideas

of ZIO, which I later

found that it was the project that John

was authoring at that

point in time. And I took a lot

of inspiration that became the version

zero of what Effect later

evolved in. And my personal

relationship with John dates back to

about six years ago, and we've been in

touch since. And now,

as we've announced a few weeks ago, we've

partnered officially for John

to have to date the position

as the official trainer for Effect. I

think he's a great

teacher. I've enjoyed his

workshops in the past. And I'm so excited

that he's now joining

the TypeScript evil side.

Yes. Happy to be here. Thank you.

And yeah, I just want to reflect on that

little time travel. Six years ago is also

when I started my journey on like,

rediscovering the joys

of functional programming,

where I've done a lot of like Haskell in

the past, but it always you

always kind of felt stuck in

between like, okay, here the right ideas,

but like, no one is using it. This is

like, like, all like

academia, like esoteric land, or like

you're using a programming language,

everyone is using like,

the industry is here.

But there was like, not no

overlap. And like, in 2020, I started

looking for that overlap. I found it in

ZIO and Scala. I didn't

want to have anything to do anymore with

the JVM. So I looked around for like,

where are those ideas

in TypeScript? And sure enough, a crazy

scientist named Michael Arnaldi was

already exploring that.

This is where we then teamed up to work

on Effect. And very

shortly after, we actually came to

to see you in person in Malaga, where we

went to the the ZIO conference. Yes.

Exactly. And this is where like the early

Effect team was like coming

together, we met the first

in person. And we sat in the the ZIO

talks, like been like simultaneously

hacking on TypeScript,

talking to other like Scala developers

like, hey, have you like, are you also

using this TypeScript

thing? And everyone was just like

laughing about it. Yes.

And we were absolutely outsiders

well, we should have had a real time

TypeScript translator,

you know, for you guys.

But, well, so the tables have turned a

little bit. And now we're sitting at the

same

tables. And I couldn't be more excited

because like, we're we're

caring about the same, the same

intellectual things have like,

tickled our neurons before. And now we're

now we're working on

the exact same thing, which is so

awesome. But before

getting lost in nostalgia land,

I actually want to bring back the

conversation into today. And like, six

years ago, we could have

never imagined which of a weird situation

we're all in today. Like for

basically, as long as I can

remember my experience as an engineer,

just kind of like compounded over time

and added up. And like

my relevance as a senior

engineer has kind of been

like, as time progressed has just

become more valuable. And with

coding agents, etc. I would argue the

that is still equally

value, if not more valuable, my

experience, but also 99% of my experience

can now be replicated

by someone with no experience through

coding agents. So it's such

a weird time, I think it's

everyone, me included is trying to like

figure out like wrap their

head around like, what is like,

what is it worth learning? Which sort of

things just don't matter

anymore. And so I'd be very

curious to frame this conversation with,

like, what the two of you think

programming or software

engineering as such would look like in a

year or two years from now?

Yeah, I think that's a great question.

And one we're all trying to

figure out. I think we know

what it's not going to look like. It's

not going to look like

people typing into IDEs anymore. I

think we're already past that for the

most part, at least the

people who have gotten AI, which is

still a small fraction, I think of the

overall space developers,

you know, it's not that we're

on typing code into an ADI. Are we still

prompting? Are we like Elon

Musk's vision is almost prompt

enter in a prompt and you get assembly. I

don't think it looks like

that. I think he's totally

wrong on that. I think we're still going

to be using programming

languages. I think we're still

going to be directing steering agents. I

think we still have to be

involved in these kinds of

decisions. The type of technology that we

have in AI is, I think best

understood is mining training

data for intelligence rather than sort of

de novo intelligence. And I think

implications for that,

for our career, mean that our job as high

level thinker, systems

thinker, is still so critically

important. We have to be there and we

have to find ways, I think,

and invent ways to understand,

deeply understand the structure and

quality of code, even in a

world where every poll request

has 20,000 lines of code. And I think

that's a very interesting

question. What are we going to be

doing a year from now? Or we're going to

have ways, I hope, of

understanding our software systems

without having to review every single

line of code, macroscopic

structure of our program and

quality, quality metrics. How is this

thing actually running?

And probably a feedback loop

is going to be tightened between the

moment when a defect

happens and the fix is introduced.

We're going to have to narrow that down

as we attempt to try to

get a handle on the quality

issues with today's models, which of

course have gotten a lot better. We have

a lot more work to do.

Michael, what do you think? I couldn't

agree more. I feel like

the role of programming languages is

changing over time. They

used to be the way we express

concepts. Now they might be an

intermediate

representation of those ideas.

But I don't see a future where we become

irrelevant. Of

course, we are very close to

the software engineering aspects of it.

So it might be that we are

too internal to see it from

the outsider perspective. And I usually

like to look at other

fields that I'm close, closely

attached to, but I'm not so deeply

entrenched in. Mathematics has been a

great passion of mine for

the good part of my life. And I'm a

mathematician by training

even though I never finished the university.

I know, John, you share the evil aspects

of being a mathematician by training. And

recently there has been a huge influx of

conjectures that have

been proven with AI.

And first of all, I never expected that

to be the case. Even if you asked me a

year ago, I would say

completely crazy. The AI cannot prove

something like, you know,

I think recently the Jacobian conjecture

had a counter example

found the area does you need

distance conjecture, but I think that

there are probably other three or four

conjectures that have

been either proven or disproven with AI

assistance. But I

went deep on that on that

rabbit hole and I tried to replicate the

findings by myself and do it

by myself. Of course, I'm not

I'm not an expert in algebra. I'm not an

expert in differential

geometry. I could go nowhere.

I would stumble. I could never

find the counter example. And then

Terence Tao, which is like a God in

mathematics terms have

published his own chat with chat

GPT his own chat history discussing the

conjecture. I was like,

okay, the model is insanely

powerful, but only only that level of a

human can can make the model

do that type that kind of stuff.

So I feel like the relationship between

the driver and the model

is is a is an essential part

of the equation here. And I think you've

probably seen as well as I have that

AI is like it's almost in a sense the

world's greatest tool and

tools exist as amplifiers of

human potential. And so like the

difference between mediums

sort of skill, but you know,

not exceptional engineer using AI and an

exceptional engineer

using AI is night and day

and exceptional like I have one person in

my Golem team, for example,

who is is just like coding

probably like a full team, right with

with quality and code ownership and good

architecture and all

of that. And it's astounding to see that

because AI is the only way

that that person could have

gotten to that level of productivity. But

I've also given AI to other

people and they do see some

improvement, but it's like,

okay, you know, 20% better.

So to lean into that a little bit more,

how do you think the like

quantity of software engineers

like professional software engineers,

people who make a living

through software engineering,

how do you project that to evolve over

time? So, Mike, your

reference in regards to mathematics,

there's only so many people who can like

even still understand what

all of that means. And the

floor of like how good a coding model is

constantly keeps rising.

So that said mean like if

one interpretation what we've been just

talking about is basically

only humans that are both

that floor can actually still

successfully wield coding models and

coding agents. And that's

like fragment of the software engineer

population basically

keeps like narrowing.

Like how do you think about that? It's

almost to me, it's almost

like a paradox where you could

in theory have a lot more people that

could now do successful software

engineering just because

there are no more to have more

capabilities through those

more powerful tools. And yet,

at the same time, the pool of engineers

who are like above that

floor, kind of keeps shrinking.

So, do you share that perspective? How do

you make sense of this?

So, I've been thinking about this just

I talk to people all the time from

all sorts of different

industries. And for example, this very

small marketing agency

had started to go into the

business of website design. Why? Because

they can now with coding

agents. So, they had the ability to

create a beautiful design and brand

colors and all that before in the old

world and the new world,

they can actually build out a full

website. And so, they're

doing that. And they're doing that

at cost points that like old fashioned

shops, website development

firms would not be able to

attain. So, they are legitimately they

have moved into

software engineering. In a way,

there's more software engineers, right?

Through all of not

just marketing agencies,

but I see this everywhere. More people

are building more

things. So, I think the number

of software engineers is increasing, but

also those software

engineers, the new ones who are

vibe coding, they're not making the same

amount that I'm making or

that you're making or any of us

are making. And also like in Silicon

Valley, right? You have these software

engineers who are making

$2 million a year in annual salary.

Ridiculous. How can you do that? Well,

you can only do that

at a very few companies and only if you

have the right background

and demonstrate the right level

of productivity. And I'm sure these

people do. I'm sure they're worth it

because otherwise they

would be replaced by someone else. But

that spread, I think, is

probably a trend line for

the future is that there's going to be

more software

developers, at least in some sense,

of being able to actually use a coding

agent to build things that previously

only like the computer

science guys could build. But the spread

of the salaries is going

to be greater than ever.

And the people who are old school and you

train on old school

methods, you know, I think,

have deep expertise and successfully

migrated to the new world can actually

make a great living.

And then lots of other people will be

doing software engineering

at rates so that we never

would have gone into the profession for

right, because we could

just do something else that

maybe we wanted to do just as much. So I

think more software

engineers, but also more spread

and salary, that would be my guess.

Well, I definitely share

the perspective and the gap is widening

massively. I see

old people in a sense

that stopped coding years ago, that are

now back full speed coding because they

enjoy welcome back uncle Bob.

Thinking of other other people that but

the the point stands and the fact that

software engineering is becoming more fun

and more accessible is

gonna inherently attract

more of the curious people. And I've also

seen like juniors who

joined the field a year or two ago

that are making exceptional progress at a

rate that would have

been completely unfeasible.

I think it is a new tool. The new tool

allows you to maximize for the for the

direction you want to

maximize on. I feel though there I've

made a chart that went viral

on x.com a few weeks ago,

where basically my statement was the the

top developers are

becoming even more top and the

bottom developers are becoming even more

bottom. Because if you don't

have the mindset of wanting

to improve your risk is you're gonna

saturate your you feel like

you're productive you feel

like you know what you're doing and

you're gonna do a lot.

But you're never gonna cross

any boundary of understanding or go deep

in any sense. And that's

not the fault of the model.

That's the fault of you as a developer.

But as a junior is very hard

not to fall for these traps.

I remember when I was a junior one of the

traps was I felt the need to

watch every single conference

talk at every single conference in the

world and I've lost hundreds

and hundreds and hundreds of

hours consuming content that was

completely irrelevant to me. And I

started thinking, oh,

I should use this database because Google

engineers are using this database. When,

it makes no sense for my use case. It

took me years to realize

what I was supposed to do as

an engineer to become better. I feel like

AI gives you a boost. But

if the boost is used wrongly,

you can boost yourself to your death

spiral. I really like that

perspective. And I think that

also helps reconcile something that a lot

of people are worried

about, which is like that with

that raising floor of like how good

coding agents are, that

it could be almost like a

perspective where only if you have so

many like years or decades

worth of experience already,

then you're good with AI and people

before that are going to struggle. But I

think it's much more

about like, what is your learning

velocity? And coding agents also

help you learn things

faster. I think it's not just a great

time to build, but it's an even better

time to learn right now.

It's almost like in the Olympics or

like any sort of like field, typically,

the level of like what great looks like

also steadily climbs

over time. And I think there

we're also in terms of like how fast you

can make progress with

like what accident looks like.

That ceiling is like growing at an

exponential rate as well. So

I think the field of like for professional

software engineers, I think the new

normal has to be that you're

like growing in a similar rate.

And I think that kind of helps

reconcile that. So the

current level of experience, yes,

that's a great starting point. But I

think to stay competitive, I think you

just need to like be

as fast as a learner as like the best

current learners are. I

think that's all that's going to matter.

And that's how we make new people,

new really good software engineers.

I also want to share the perspective that

was recently shared by

two pioneering in our industry that

Salvatore Sanfilippo being

the author of Redis,

who is now old, who's now

antirez, of course, he's an icon

in our field. Yes. And

he's been recently sharing his

takes about AI. He has an interesting

project about local AI

running model locally. And the

perspective I wanted to share goes along

the lines of the average

engineer cannot feel the difference

between Fable, Kimi K3 or GLM 5.2. Yeah.

The expert engineer feels

a world of difference. Yes.

So when we think in terms of model

capabilities, they're

biased from our own experience,

we might feel a model is way better than

another model. But it's

actually because we can

leverage that model. That's right. The

average engineer is not that

capable in a sense. And I'm

not saying they cannot become that

capable. I'm just saying that

it requires a lot of skills to

use those new generation models at scale.

And even us, we're like,

with Johannes we've

been having conversations over the past

year or two. And they were like, we

change patterns every

few months. Now I treat the agents this

way. Now I treat it the

other way. How do I get it

the most out of it? And it's a very

evolving ecosystem. So

yeah, I just wanted to share his

and curious perspective on this because I

think it's very true.

So maybe to slightly shift the

perspective, the two of you are among the

greatest minds that can

think of new abstractions that give

engineers and now by

extension also coding agents

more leverage. The abstractions that come

to mind here is clearly

what ZIO has given us,

what the effect type is, layers, streams,

all of that. And those

are, based on years worth

of pain and suffering, of having to deal

with a lot of Scala,

having to deal with a lot of

JavaScript and TypeScript. And this

emerges out of a lot of

complexity and through osmosis,

spending a lot of time with that and

thinking, "Ah, this can be better

expressed in a more elegant way

also based on actual academical

research," etc. And so this

was made for the materials

of that given time, like programming

languages, systems, trade-offs,

affordances. And now we have

this fundamentally new gravitational

field of things that matter

and things that don't matter anymore

one lens I like to use when looking at a

new technology, a new

framework, a new practice,

it's like it's half-life time in the age

and acceleration of

AI. Should I even bother

learning that? Will this be like learning

a Webpack config thing

that doesn't matter anymore,

like in a year from now? Now learning a

thing might not matter

in a week or two from now.

So this is a whole range of questions I

want to ask from here.

One of it is which things

do matter, which things are worth it,

really investing into,

getting better at, which

category of things might no longer be the

best field to invest your

time into. And then maybe

at a later point of the conversation, do

you have a hunch of an

abstraction of or something

that gives us even more leverage for how

we construct and define

software? But maybe starting

with the first one first, what are your

rubrics on thinking about

categories of things where it's

worthwhile to spend your time and

attention and energy on

versus categories of things to

avoid because the half-life times are so

short? Yeah, I think

that's a great question. And I

think that there's a huge number of

things in our education as software

engineers that even if they

don't apply literally to the new world,

still they train us in ways

of thinking about information.

And algorithms and architecture that is

so incredibly useful when

you're building software

through coding agents. Example is just

like the better debugger you

are, right, if and I'm talking

low-level debugging skills, firing up

debugger, loglines, all

this stuff, distributed system,

you know, complicated, only reproduces an

AWS, the East one or

whatever, that sort of level of like

insane ability to find a problem. Even

though you're not going

to do that now, your coding

agent is going to do that now, right?

Probably, but still having the

ability to think in terms of,

okay, I need a hypothesis and I need to

either validate or reject

that and I need to iterate on

this cycle and I need information, right?

That's one of the things

about debugging that debugging

teaches you is that in order to make a

hypothesis about malfunctioning software,

you need information

and the more information is better. I

mean, you need to be able to

sift through that and maybe

the wrong type of information is bad, but

you need feedback from

the system. And so this

knowledge that you gain from becoming a

good debugger is useful

when you go into coding

agents and your coding agent produced the

wrong thing. And now you

have a hundred more things

like that one thing that it produced and

you wanted to have it produce

it, but the prompt you're using

or the workflow or the plan, whatever

your system of agentic software

engineering is, it didn't work.

Okay, you're debugging something. You're

not using the same print

lines anymore, but like, you know,

you need information from the system. So

you have the conversation

history, you have all this stuff

and then you're like, okay, well, I need

a hypothesis and you form

the hypothesis and you test it.

So I think like ways to think better are

always in vogue and you

know, math and computer science

and abstract hours or all this stuff

here, it teaches you how to

think. And so these thinking

skills and reasoning about systems are

never going to go out of

style, at least, you know,

not in the next few years for sure, maybe

in the far future, but for now,

we have to know how to think. And I think

learning how to think is

useful. And also like an analogy

that my mind keeps coming back to his

matrix where like you plug

in and you download Kung Fu.

Okay, that's the new era we're entering,

right? Is our agent needs

to learn Kung Fu. So we just

push the button and now our agent knows

Kung Fu. But like, how do

you know how to choose Kung Fu?

You might not want your

agent to learn Kung Fu.

They can only learn like 20

things, right? Before it runs out of

context. So like you have to

become an expert, you know,

in Kung Fu per se, but in knowing when to

choose boxing over Kung Fu.

Okay, so I think that I love those two,

like analogies or like

perspectives how to think

about it, I actually want to push back

against the first one and

like widely underscore the

second one. So like the first one you've

mentioned, I think is like

really, really broadly applicable

to the I would say the majority of like

what software engineering

budgets are currently spent

on. And I would make the case that maybe

here's actually not the

best use of our time to like

trying to absorb the entire problem

ourselves. Like this is pre coding

agents, you could basically

just observe maybe like maybe you're

building Uber and like

you're getting those sort of like

reports. And then like you can kind of

like track over time, okay,

we're getting all of those

reports there were being triaged. And

then you say, okay, this is worthwhile

looking into like a team,

starts looking into that. It's not

obvious. So you start like

looking for logs, maybe you

realize you don't have enough logs, you

like add more logs, you see,

like you try to reproduce it

somehow load in your head. So I think you

now have like two paths

with coding agents, how you can

pursue that. One approach is basically

just collaboratively with

the coding agent, trying to make sense

of the entire thing and

always like having it, even like

still trying to attempt

to load the entire problem in your head.

I think that's one approach.

The other approach, I think

is much more of like what I would call

like closing the loop. Basically, what

prevents a coding agent

to like address the entire thing just

with high confidence just

by itself. And I think the

addressing it just by itself with high

confidence is very similar

to what Mike described before,

with like the now solved math problem.

Like this is where like

the verification loops etc.

is already closed. So it's just a

matter of like, a very

inefficient way would be like to

brute force to go to the solution. So

like clearly here intelligence

pays off. So with that second

approach, I'm kind of posing the approach

to say, actually, we don't even try to

attempt to understand

the problem. All we care about is like

working through checklists

of like, do we have maximum

observability here? Are we following like

those distributed systems

best practices? Do we have

proper test coverage for that and

basically just like building, enhancing

the machine that looks

into it. And so I think that part is

going to be widely automated and like

also through systems

like effect is almost like automating the

bulk of this. I think

where it matters more is like

knowing like, okay, here I need control

here. I need like

whatever I need to be a diver.

Yeah, and that's what I was saying in the

first part was really that ultimately,

whether you're working with agents or

you're doing work

yourself, you need to understand

system thinking, and information flow and

all these other things

that like, once you understand

that, they translate from doing it

yourself to applying that

like closing the loop in AI.

Why do you do that? Well, you need a

feedback mechanism. Why do

you need a feedback mechanism?

It goes back to the scientific

hypothesis, right? You need to be able to

create a hypothesis that

can be falsified. And then once you have

that, you're in business

and the agentic and analog

of that is some mechanism, whether that's

running the TypeScript

compiler or whether that's, you

know, it depends on the domain, but you

create that mechanism and

feedback and then suddenly

you can get an agent to fix its problem.

And I do think that like on a

day to day basis, that's what

our job looks like right now is getting

the agent to fix its own problem by

engineering the system

in which the agent runs. Exactly. And I

think this is what it's

going to be all about. Like,

how can you think of like what you're

building as a closed loop? Like what is

like the most elegant,

like we're still like going for like

elegance and like we're

trying to build the entire thing as

efficiently and as simply as possible.

But I think it's more of

like how do you express and

compose the entire thing so that it can

be self verified. And

this could be through like

invariants through like a clever

architecture. And this is

like the, this is where like,

knowing Kung Fu, this could hear me

like you want to use an event source

architecture or like,

an actor style system. This is like

what it means to know Kung

Fu. I would even make the point

that like, if you have more tokens to

spend, you can

basically just like try it all.

And see like, what works best. Yes. But I

think this is also

sort of like the window

ahead of us, the time window ahead of us

where us knowing when to

choose Kung Fu versus something

else is like that, that gives us the

right to be software engineers.

Yeah. I think If I were to challenge a

little bit the

perspective, I think that works

because both of your minds are already

trained in this specific way. Going

through years of debugging yourself, understanding

systems yourself and so on and so forth.

I'm not sure it can work equally as well

for a non-trained mind is I can make a

very recent and concrete example.

I'm trying to stretch the, to find the

boundaries of the

capabilities of the models,

of new generation models like Kimi K3.

And recently as a

weekend project, I was like,

I have effect in TypeScript. I like it

more than Python, of course. But the

whole AI stack is in

Python. Trainers, Tensor mathematics, and

so on and so forth. I say, okay, let's

build the equivalent

of a PyTorch in TypeScript. It's not

something I would have ever

done before, because obviously

it would have taken me months and months

of work to even architect

that. And in a weekend

I'm already at a point where
I can specify a model, I

can specify a trainer, I

can specify an evaluator,

its performance comparable to the PyTorch

implementation. It's fantastic. But this

morning, I run a very small training job.

I see that it slows down over time. Okay,

what why does it slow down? And like, I

tell my agent, hey

let's make a benchmark.

So let's close the feedback loop. Let's

prove that it is slowing

down. And then you investigate why

it is slowing down. And the agent

crunches numbers for two hours in a row

and makes 100 different

hypotheses. Disproves the 100

hypotheses and was in

a loop, in a concert.

At some point, my engineering mind was

like, let's stop the

agent, let's tell the agent,

check the memory allocator, because I

have a back end in Rust,

and I have a basically an

interface in TypeScript, which is a

garbage collected

language, that the memory layout

of how JavaScript allocates and

deallocates objects doesn't quite map the

Rust infrastructure.

And two minutes later, it found a bug in

the library that I was

using on the Rust side,

which is candle from from Hugging Face,

fix that bug, my program now runs

correctly with the right

input, it took the agent two minutes.

Yeah, by itself, it crunched

number for like an hour and

a half, absolutely going nowhere. And may

never have solved it. It

may never have had solved it I'm

not sure. Yeah, maybe I try on on an

experiment, let it run for 24 hours, see

if it can get to the

same. But I think this is where like the

the engineering mindset

and the ability of like

choosing kung fu is essential. And I'm

not sure how I would have

done it without my level of

knowledge. I'm not sure that's just

enough. What closing loop I

feel like you still have to be in

the loop you close? I think that's that's

a great example. And I

think still just trying to think

through what would it mean to close the

loop here is probably

still like a very interesting

thought exercise since for this

particular scenario now, you could

basically build yourself

like a higher level harness that has like

that goal. And then maybe

you have a separate supervisor

agent who just constantly looks for like

a bag of evidence like

what are we looking at here,

formulates hypothesis of like, what

could be the problem, spawns off like

swarms of agents that

like look for that, maybe one of them

strikes gold says like,

aha, like stops that one like,

and so if you have enough tokens to

spend, I think you can get further

there's probably like

new problems you're now running into.

Well, that's what I did though. I did

exactly that and ended

up spending $1,000 in in in tokens on

Kimi k3. So I was doing

exactly that. I'm sure like if I

if I had $100,000 in tokens, maybe that

would have been the

solution. But we even the middle.

Yeah, yeah, at the very least having that

knowledge of all these different systems,

knowing software hardware sort of end to

end enabled you to take a

shortcut that dramatically

completion of this feature. But I think

that there's still

something in here where,

before coding agents, it would be

unthinkable, like we would be the only

way how those solutions could be

attempted. And I think now

there's like a very credible path,

how those solutions can be worked out is

just a matter of like

something being economically

like not useful to even attempt and or to

even attempt yet. So like

coding agents are getting

more capable at like a comparable price

point. So there might be

like very real problems that

might be not feasible or economically

useful to attempt today that

you could attempt in a year

from now and get a different outcome. But

I think just like

coming to terms with that,

that's like also another form of like the

bar is raising in in terms

of like what is feasible and

in relation to that, like what is our

role, but maybe bringing

back the conversation to

what are like timeless skills to invest

into or like timeless

things. So like

general system thinking, like I

definitely, definitely

agree. I mean, even like one

hypothetical way to think about this is

in the same way as like how

we automated like a lot of

physical labor to an extent that anything

that's like we have

excavators or like we have

things that are no longer only depending

on our muscle power,

but like we have machines

that help with that. And to offset for

that, a lot of people now

go to the gyms. So you could

basically say like, okay, we're getting

good as like some system

level thinking as an equivalent

for like the gym for the mind just to

like not like, like,

ostrafy too much. But yeah,

I'm curious, like, how

are you thinking about that?

Yeah, I think gyms for the mind, I think

I've heard a lot of people

talk about this, which is

like I'm, I've been using coding agents

for months, and I feel like my

skills are atrophying. And if

someone stuck me in front of a computer

and asked me to do anything,

I would get stuck and not be

in progress because I don't have my

coding agent with me. So I

think we are in a way becoming

addicted to our coding agents. What is a

gym for the mind look like? And what

sorts of things might

we do there? I don't know exactly. But I

do think that like, there

are skills that are independent

and independent of the tools that you're

using. And the example is

like, debugging is just an

example of like the scientific

hypothesis. How do you learn? How do you

learn information in an

uncertain environment? And that is

fundamental, like rational, logical

thinking. The notion of

experiments parallelism, right? That's

another example of

something that's not going to change

and knowledge of parallelism is going to

be useful. Hardware

hasn't changed that much. And

learning a lot about hardware can help

inform you when you're directing coding

agents to solve some

problem that might involve trade offs

between several different

dimensions. And it can't pick

you up. It can't be used for you.

Otherwise you're going to get

something that's not useful.

So I feel like there is a number of

topics that are probably not

going to go out of style and

that is still going to benefit you from

understanding. And

probably there's going to be

things that we can do to keep those

skills up to date. An example is

actually, I'm not even sure

how long or how much longer this will be

relevant. But I went to, I

wanted to do an async version of

streams for a new library in ZIO blocks.

And I wanted this to be

as close as your allocation

as possible because allocation has such a

high cost in the JVM. And I had a

specific idea in mind.

I told my coding agent do this. And you

know, it spins around

and looks all the files and

figures up, comes back to me and says,

sorry, it can't be done. I'm

like, yeah, okay. And I argue

with it back and forth. And it's like,

okay, I'll go off and do it.

It goes off and tries to do it.

And it comes back later, an hour or two

later, it's like, sorry, it can't be

done. Yes, it can be

done fine. And I type out the Scala code

inside the chat and I'm

like, do it exactly this way.

Don't vary. And then it goes off and does

it and it succeeds. And

then, you know, I've got the

benchmark in place. So of course, I use

that to just iterate for

some number of iterations until

things stop improving. And then I'm

goal, right? Something

that's super fast, but that never

would have happened. Probably never. I

mean, like you say, maybe

spinning off a hundred, but like

that type of knowledge is not going to be

known by software engineers

in the future. They're not

going to know that. So what's going to

happen? Well, I guess the

models have to get better,

right? Because the junior software

developers who are learning by coding

agents are never going to

be able to do what I did in that case.

And that's probably

Michael, your experience that you

mentioned before is like, there's some

things that the new way of

programming is not going to teach

you. And we can hope and cross our

fingers that the agents will eventually

get there or parallelism,

spend more tokens solves these problems.

But we don't know that for certain.

And that there's a very nice parallelism

to something that I

think Mitchell Hashimoto said

recently where he was. Maybe it wasn't

him. I don't want to necessarily

attribute a quote to

the wrong person, but someone of the

level of Mitchell was

working on a, on a problem and

told the agent to optimize it as much as

possible. And it was like the agent

actually found a 5x.

Which is quite impressive, except that I

already know how to make

it 20x and the way that the

agent started. There's no way it could

have ended. There's no

path from here to there.

Local optimum.

Local optimum. And I feel like all these

levels of skills, let's not be completely

doomers and say that maybe some junior

engineers will reach that

level. But I, if I were to do so,

I would not know how cause that that

literally comes from years of fighting

with coding and coding

paradigms and so on and so forth. I think

like some interesting

takeaways from this though,

is that the, even the five X improvement

is already great. And

for like most systems,

that's probably just going to be totally

fine. Let's say

Mitchell has given that statement

and let's put that in the context of like

ghosty or like any sort of

things that he's working on.

This is for having software feel that

premium. Yes, you don't want

to be stuck at a local maximum.

You want to be at a global maximum. You

also want to like, since

complexity kind of compounds over

time, typically in an exponential way,

you also want to

simplify the system as much as

possible. So as much as matters that is

like at the global

maximum in terms of performance,

maybe it matters even more that in the

process, you don't 10 or

100 X the complexity of your

system. So I think kind of figuring out

what is like

a measurement for

complexity. I think that is something

that I'm very curious

whether we'll find more credible

answers for that. So this could be almost

like a different definition

of like what it means to be

a software engineer is kind of like you

fight accidental

complexity. This is like you're trying

to put the system as simply as possible.

And yes, that something works

the way

You want it to work. That's already

great. But if you do that a lot of times

in the context of a team,

you're going to have so much more

complexity at your hand if you had a

little bit more resistance

while you're working on this and like you

fight maybe harder. So I

think this is like another

kind of quality. And I think a worthwhile

like framing of what, why

it still matters to gain

that experience that you can basically

push back and say like, yes, it can be

simpler. John, like you

said, like when the coding agent says

like, this is not possible. And you say

like, yes, it is possible.

Even just like, like maybe not

everyone has the exact solution in their

heads, but maybe they

hunch that it can be more simplified.

Like I think this is where

it really matters to

go with that and keep overall systems as

simple as possible. And I

think this is also a nice way

to bring it back to ZIO and Effect. So

it's like, this is the

material that allows us to define

and build and compose a system out of

that overall, I think gets us

much closer to a global maximum

in terms of how simple a system can be

expressed compared to other kind of

material. So maybe this

is, well, I'm sure we have like plenty of

other areas that we could

indulge in in AI land. But

maybe let's use that as like as a segue

back in into the realms

of like Effect and ZIO.

I'm very curious to hear your thoughts,

John, as the author of

ZIO who've like you've

very, you've sweated each detail about

ZIO, about each abstraction,

etc. And now you're entering

the House of Effect and like trying out,

trying on clothes that are

kind of like similar to the ones

designed, but they might feel different.

So I'm very curious, what

does that feel like? Where do

you feel like, oh, like those shoes are

actually nicer, but like man, those

pants, they're not like

the ones I've made. Yeah, well, honestly,

I think that the real

breakthrough of, or at least one of

the real breakthroughs of Effect TS is

taking some of the ideas in ZIO and

making them accessible

in a way that's idiomatic in TypeScript.

Because, before I started

digging into Effect TS

and looking at how it's made, how its

pieces fit together, the type

signatures, what programs in it

look like, I would have thought that it

would be different than it

is. And then in every single

case where like, oh, why didn't they do

it that way? I'm like, oh, that's why

it's that the usability,

the DX would have been horrible. And

probably for the final finished polished

product that I'm seeing,

Michael you, or you know, another

contributor explored like five or 10

different iterations,

and you found all the dead ends. And I

can't see all those dead

ends, I just see the finished

product. But in most cases, I've been

able to release in the most in

the cases where I've actually

pursued my idea for, oh, why isn't it

like this way? I found out, oh, actually,

there really is a good,

there's a good reason for that. And this

is why Effect TS has the

adoption it does is because

it's not just a one to one port, it is

its own way of doing things. And some of

those design decisions,

you know, I like like, for example,

schema went in a different

direction than ZIO schema,

I mean, not radically different, but

different enough to be noticeable. And

actually, it's quite

nice. And comparing that to ZIO schema,

like, okay, well, ZIO schema gives us

this, but this is like

out of the box thinking here, this is

someone who took the goal of

ZIO schema, but not the details

and arrived at a totally different design

that actually is quite

interesting. And you know,

you can imagine that existing in Scala,

maybe it would be great.

And yeah, probably even 100 different

iterations, not just 10.

A lot.

Of mistakes.

It's obvious that there was like, and I

love it, because you can't

find a global optimum until you

find a lot of local optimums and throw

them away. And you've, I

think, come very close to that in

Effect TS maybe even gotten there.

And I think look, to me, the reason I

like ZIO and I took

inspiration from ZIO is not really

the language element or how I read the

code. It's rather what that paradigm

gives me. At that point

in time, I was running a FinTech as a CTO

and we had a very small

team. It was very challenging

because in FinTech, you are highly

regulated. You need to build solutions

that are proven to work.

You're just not, you cannot just hope

that they work. Like, it

works on my machine there,

doesn't really work. You have to prove

that it works in the

deployment in US East One,

in AWS, in all the regions and so on and

so forth. And what the

ideas of ZIO gave me,

like this high level representation of

code very close to human

that could be transformed and

refined, made dealing with errors

exceptionally easy, dealing with

testability exceptionally easy,

dealing with telemetry completely

different story compared to the other

forms of code that I ever

wrote in my life. If we go back to like

today in the age of AI and

looking maybe even into the future a year or two

in advance of like, what are we looking

at when we look at software?

For sure

we should read code. And I know this is a

controversial take,

but it's not enough to

just look at code when you're about to

merge a 2000 line or a

20,000 lines of code PR,

like John, you mentioned before, what are

we looking at? And I

think things like telemetry,

things like system diagrams and so on and

so forth are essential

to the future of software

development and heading a high level

representation of code such as ZIO in

Scala or Effect in TypeScript

gives you those things for free.

The code that your agents

produce is automatically observable

is automatically testable

you don't have to infuse your own

experience as an engineer to make them

testable at this level.

I feel like this is what I really like

about this way of programming.

It gives you the right primitives. And

once you use these

primitives, a whole host of problems

are solved for you. And that reminds me

of that post by Amplify Partners,

The primitive is the product

by Lenny Pruss, which sounds like

an ad for Effect TS. I

mean, among other things,

did you put them up to that, Michael? I

think it was a different

ad for a different company,

while it applies very well to Effect too.

It does. And it's like

in an age in which like,

you can make code for free by pushing

buttons, what matters, it's

the shape of the primitives

and how they snap together to solve

problems. And Effect TS has

that. It's those primitives

that can be used to efficiently solve a

huge range of problems in building

reliable cloud software.

Not only do the

primitives still matter,

the primitive is the product, as Amplify

would say. But also,

even if there's some ramp up

curve to learning the primitives, it

doesn't really matter

anymore. And that is to say,

we can choose better primitives in the

era of agentic coding

than we could before, because

before you had to convince a bunch of

humans to learn stuff. And

you don't have to convince

agents to learn stuff. I can snap your

fingers and they already know

it. So you can choose better

primitives. And that's what's Effect TS,

better primitives for

building reliable software. And you can

make your coding agent use it, even if it's

never seen them before. And

I think that is like it's,

even though functional programming often

has said to have failed,

even though the way it succeeded

was Effect TS, right? And other similar

things like that, the way that it

succeeded. It's like,

this principled approach to building

things with primitives is

actually more feasible now,

because you don't have to convince

developers to do it.

I think it's almost like a way of like,

if you study the emergent

behavior of those systems,

like when you build with Effect, do you

as an emergent property, do

you end up with a giant mess?

Or do you end up with something that's

like, I like to look at

this kind of like through the

lens of like a fractal. Like when you

look at a fractal, no

matter which like zoom level

like that, like you can still sort of

like into it the shape and

the complexity of the overall

system like what you can currently look

into. And then you zoom

in like a given situation.

And then you can still like make sense of

this. And I think Effect

has like that sort of property

to it, that no matter which level of the

system you're currently

like exposed to, you can make

sense of it. And like it doesn't give you

like a false story of the

like oversimplification,

you basically something looks like a

pure function, it definitely isn't.

And so I think that matters even more.

Because like in the same way,

it helps you to kind of like

trust what you have here. It matters

equally, if not more for a coding agent,

because now they can

work on their stuff with like their

assumptions, kind of like playing out.

And I think that's like

one of the most beautiful like properties

of Effect that go

hand in hand with like how

compositional it is. Yeah, exact

composition. That's the keyword

compositional, right, which

leads to that fractal structure, and

snapping together solutions

from building blocks. And that

was my old argument for selling

functional programming is learn

functional programming,

because it's compositional. And the fact

that it's compositional

will help you understand the

software you write better. And people

were like, why would I

ever want to understand it?

And that's why FP failed. But actually,

agents, they do a much better job of

maintaining code that

they quote unquote understand. So it's,

it's a killer argument for

an agent, whereas for humans,

you know, humans are lazy. So I want to

see whether you have

maybe pointers or advice

for engineers that now have this new

power of effect. Maybe I

think there's like a wide set

of engineers that squarely fit into that

bucket, where they were

aware of effect before they

maybe like intellectually liked it. But

they were just like they couldn't be

bothered to spend the

well, sizable amount of time it

takes to get really good at it. Now they

have the magic ones,

the catalyst is like, they don't need to

get good at it. They just need to tell

the agent like, hey,

we're doing this. And the same goes for

colleagues, maybe someone is like really

excited about effect,

the rest of their team isn't. And so

effect adoption doesn't

happen. I think now we're

basically with coding agents, we get like

that catalyst for

everything. And I think there's still

need to somehow fight the like

cancerous pattern of like,

coding agents, like adding more and more

and more stuff, and

doing it the right way. So I'm

wondering whether you have thoughts on

that. Things like good linter

tooling, etc, comes to mind.

But also other practices that I found to

work really well, such

as property based testing.

And so I'm just curious whether you have

any sort of advice or any

sort of patterns that

maybe you've always practiced

those, but you knew that it

would be too much for other

practitioners. But now it's actually you

can have the cake and eat it too. So

curious what you have

in mind. Yeah, well, for I think we're in

a situation where I

think a lot of people are

new to Effect TS, right? And they don't

necessarily have a background in FP, or

should they have to in

order to use it. But they might not be

in a position where they

can look at Effect TS code

and say that's idiomatic. And that's not

this needs some work, this

needs some simplification,

or it doesn't. So I think, you know, some

of my learnings from using coding agents,

are that first off, we need better big

picture metrics. And an

example is, like you can do

cyclo matter complexity, and you can do

all this other stuff. And that helps

somewhat. But we need

like bigger picture, it should be

possible for an agent to see without

looking at tokens, I mean,

like average length of a method, or a

function. And like all this

other stuff that we can see by

looking at it, but it's harder for an

agent, it's harder to make

that tangible for an agent, you

can't just sell an agent go out there and

write best practice

idiomatic Effect TS, and have it do

that, because it doesn't know what that

means. And so inserting that in your

agents.md and expecting

anything useful to come out of that is,

you know, it's a joke. So

what we need is we need to codify

what it what it is we mean, when we say,

best practice Effect TS,

and turn that into metrics

that can be analyzed, most likely not at

the level of tokens, but

at the level of the abstract

syntax tree, right, this might be

compiler plugin, I don't know if you've

done anything like this,

Michael, but like compiler plugin to like

capture all this stuff,

expose that in a compact form to an

agent and say, well, this is what good

Effect TS software looks like. And and

that tangible feedback

can be used to iterate and improve. But

one of the things that I've done is

obviously turn on linting

to the max turn on all the linters, take

advantage of very powerful

type system that TypeScript has

in trying to model things precisely make

illegal states

unrepresentable, all these sort of FP stuff

that now you can do for free more or

less. And then also letting you turn on

all this stuff. And so

the agent will find problems and fix

problems. But that's not enough.

Ultimately, you cannot make the

agent write good quality software. So you

have to have skills to

fix up bad quality software.

And fortunately, like in any given

domain, like Effect TS, for example, an

agent will make certain

kinds of mistakes that it keeps on making

again and again, as it solves new

problems. And so you go

and you have skill files, multiple skill

files or one depending on

what domain you're working in.

And you say, okay, you think you're done

now go back and execute

these, you know, commands,

right or scales, whatever, same thing.

And it goes back and it will

find all these anti patterns

that you know that it produces and it

will fix them up. And then

another thing, another technique

you can do is part of your sort of post

production and review process, your

automated review process

to have it go through the diff and say,

what had to change versus

what did change and go back and

delete all the stuff that changed, even

though it shouldn't. And that will help

maintain more stable

architecture by discarding all the stuff

that's not actually necessary. And

there's lots of like code

review commands out there you can use

that work reasonably well. But

if you're working with effect

TS, you're going to probably want to

customize them or like any

given stack, right? You want to

customize to your stack. And all of these

techniques, let the

agent write slop, clean it

up afterwards, give it big picture

feedback, make sure it's not making more

changes than necessary

and do spot checks for reviews. Test is

another big thing. I think

the way that we have of writing

tests has changed. And in the old days,

you would say write tests

so that they're maintainable.

And these days you would say write tests

so that it's very obviously

the case that they're correct,

even if you see no context and don't look

up any functions. So make

the test to be duplicated,

no helpers like minimal helpers, if any,

and be verbose and

impossible to get wrong. If you look

at it and spot check that test, and you

know, it's right, even if it's

horrible, and you would never

maintain this yourself, that's actually a

good test in the age of

agents. So just to like underscore

the last point, since I think it's

somewhat non obvious and

flies a little bit in the phase of

the traditional like dry methodology. And

I think this is really

something that has now been

flipped with with coding agents, and

maybe also just to

look at that lens of like,

which advice or practices have been

flipped with coding agents,

which sort of trade offs are

changing. Here, the dry principled has

really, like we can

renegotiate it, I think it's still

it's not like squarely, like now always

bad, like you should still

in a lot of cases still keep

things dry. But for a lot of places, for

example, in tests, where like the the

test itself has sort

of like a different kind of lifecycle and

maintainability horizon

as like the the source code

itself, we can now renegotiate that like

us like a lot of like the

best practices we came up with

was like

the human

suffering of like having to write lines

of code. Now that

doesn't matter anymore. Now it's much

More episodes

Chapters

What is Cause & Effect?