Vibe Engineering Effect Apps — Michael Arnaldi, Effectful

So, welcome everybody. Um, just setting up the context for this workshop: I had a lot of ideas to potentially prepare, but at the end I thought, we are Vibe Engineering, for this to be authentic it has to be from scratch.

So I actually pre- pre- prepared absolutely nothing. That means we can take any path that we want, and let's hope this is real enough. First of all, I'd like to know from the crowd: do you already know Effect?

Do you know Xero? Like, what's your level of familiarity with AI tooling? And some kind of questions like that. Lucky enough, we're not too many, so I hope this can be as interactive as possible. Maybe let's just start.

I know Chris.

Hey, guys.

Hello? Hello? Hi.

I'm Christian. Follow? Nice to meet you.

Familiarity with AI and with Effect?

Recent.

Some? Okay, good.

Running V4 in production.

Running V4 in production. Against advice, by the way.

Hi, I'm Colin. Um, I've never actually used Effect, but I like, you know.

Good.

Computer programs like F# and things like this, but not as much as against Effect.

Good.

I'm starting the write-up on it.

Yeah, I've been familiar with the agent workflows. I think I've been I haven't been, like, writing code by hand since the beginning of this year, like, doing everything with the agents. And the reason I'm particularly interested with Effect is, like, it's, you know, encouraging so much safety, so my agents cannot become smoke cannons.

And the reason I wanted to use Effect was to, like, we had one API client. I transferred that API client from a regular, like, Profic client to Effect, then built a CLI on top of it. And now I'm more interested in how you make the Effect more discoverable by the agents.

Okay.

I saw the idea about having the repo cloned as a subtree. It's, like, not pretty convincing yet, so I'm curious how it.

Good.

Will make it work, yeah.

Good. Well, what about you?

Yeah, I'm quite familiar with, like, clean code and building stuff, but I've not heard much about Effect yet, so this will be my learning.

Sounds good. Sounds good.

Um, hello everyone. I'm Natalie. My name is Mirela, and I help with community and design and effect impact for the company behind Effect.

Good. So, pretty heterogeneous crowd, all interested in some sort of how to use agents effectively with Effect, pun intended. You pointed out a very good thing, which is cloning, giving the repository access to giving the agent access to the repository.

And in reality, this session should just be called "Just clone the fucking repo" and get and be done with it. And really, like, I've also have not been coding by hand since about late this summer, so it's been quite a while.

I started programming when I was 12 years old, so it's quite an odd feeling to get to the point where, you know, you're no longer writing code by hand. And most of what I do is library-level coding. So it's pretty low-level, usually fairly complex type machinery stuff that used to require a very good understanding of the language, of how the user interacts with your software, and so on and so forth.

Not diminishing in any way up-level development, just that the way you treat a language if you have to build a library versus the way you treat the language if you are building an app on top of it is usually very different.

Now, sometimes in app land you have the same requirements as library land, especially when you need to, you know, generalize, abstract over some patterns, make them repeatable, well, remove the verbosity from the repetitions, and so on and so forth.

So there's some crossing there, but I definitely thought that AI would be more useful in app land, and I didn't see much usage at library-level land, and I was dead wrong. Because I'm not writing code by hand. I have not wrote any line of code by hand for a while.

And I've done that in TypeScript, I've done that in Rust, and the funny element is, given I mostly write libraries, I usually interact with codebases that have zero documentation, that have zero best practices available online, and so I couldn't really use the usual "let's just add an MCP server to get access to the documentation" or hoping that the models have been trained on the documentation enough to be directly useful.

And the reality is, with LLMs, like, people treat them like a human brain, but they're very different. We learn continuously. This is a learning experience. Once we get out of this room, hopefully, you're going to know a little bit more

from the starting point on when you come in, and your brain will keep going and will internalize more and more patterns over time. Then you go to sleep, your brain cleans up a little bit of the mess of irrelevant information that you got during the day, and there's this whole process of transforming experience, so the word that we experience every day, into long-term memory.

With LLMs, this does not happen. With LLMs, you get a pre-training phase where LLMs are trained on all the world of existence of existing knowledge. Usually they get trained on the whole internet, then they get specialized in some tasks, and then there's the whole post-training phase where models are fine-tuned to act on specific things.

For example, coding agents are generic models that have been reinforced that have had passes of reinforcement learning to operate on codebases. The whole post-training phase of a of a large language model dedicated to coding is letting the model rip through codebases and having evaluations that tells the training phase how is the model performing.

Is it doing good? Is it doing bad? Does the code compile after this change? Does the code fail to compile after this change? And so on and so forth. But once that is done, it's done. There's no more knowledge that comes into the model every day.

So if you interact with a model today and you tell you tell something to the model and you say, "Hey, I want you to do this in a very specific way," tomorrow it's not going to remember.

So how do you make it remember? That is the that is the big question. And models,

you have to think of them like

you're chatting with them, but the reality is you are basically appending messages onto a fixed-size array, which is called the context window. And the context window is limited. Now there are models with a 1 million tokens context window, and that's not necessarily a good idea, because the context window of the model is what is pushed to the neural network, and the neural network is going to try to predict what's coming next.

So if you push more information, there's a very good chance you're going to confuse the model, which is why a 1 million context window is not necessarily helpful, especially if you're doing multiple things in the same context. That really means

we have to architect around a dump process. We have to architect around some machine that had knowledge of 6 months ago at best, that is not going to remember everything, because even if you have 1 trillion parameters in the model, or even if you have 10 trillion parameters in the model, that's not enough to store all the human knowledge.

So you're always going to get compressed knowledge. And in the best-case scenario, you have some ability of generalization in the model so that the model can say, "Hey, I know A and B, maybe I can do C because it's similar to A and B."

And you have some form

of this emergent behavior and capability of reasoning on new problems. But models have become very good. I've said it by myself, I'm not writing code by hand since at a minimum 6 to 8 months. So that means even if the machine is dumb, it's already at the point where we can leverage it to do good.

But how do we do it? Now, if the assumption is the model has outdated knowledge, we need a way for the model to get new knowledge.

And we said that those models that we use for coding have been reinfor have went through reinforcement learning to be able to understand your own codebase, make changes in your own codebase, and replicate patterns that exist in your own codebase.

They haven't really been trained on reading human documentation. They haven't been trained on using an MCP server that they never seen. They've been trained primarily to consume and produce code.

So 8 months ago I was thinking, "What if I just give the model access to code?" That means if I want to use Effect, I'm going to add the Effect repository in my directory, just masquerading the Effect codebase as my own codebase, and maybe I can trick the model into thinking that it's just one big codebase, and that it would explore it and would progressively use it to build up the required knowledge and to sort of clone the patterns.

And there's various ways of doing that. One could argue the model already has access to library code by having it in NPM in Node modules.

But coding agents have been trained to focus on your own code, not on the code that is on Node modules. So if you have it in Node modules, the model is deoptimized. It's not going to look at it with the same frequency as it looks at your own code.

If you have it in a git ignored directory, the models have been trained not to look at files that are git ignored. For example, Cursor does not index stuff that is git ignored.

So there are all of those sort of random restrictions that we figure out while developing. And the only way I found the models to be good, regardless of the language, regardless of what you use, is if you just clone the fucking repo, which is the point of this workshop.

So this is a completely empty project. I have some ideas of where we could take this. My idea would be to set up

a Bun repository, use Vitest for testing, use build up some kind of HTTP server, ideally providing an OpenAPI documentation for consumption, build kind of type-safe client to interact with the backend. Hopefully, if we have enough time, I'm not sure, tap into the world of workflows and clustering for persistent operations in the backend.

And really, I have nothing set up. So how do I usually start? Well, I would like you to I start nice with the model, but as soon as it derails, you're going to see I'm going to start to insult the model.

And it's fun because it cannot really answer you back. If you don't like the answer, you can just shut it down. It's not like a human that gets offended.

Maybe. So I would like to set up a project using Bun.

The project should also include setup of Vitest and

TypeScript

check

script. I'm using GPT-5.4. When I started this journey, I was using Sonnet 4. There's many differences between Sonnet 4 and GPT-5.4. Namely, Sonnet 4 felt like a kid with a knife running through the house. That's an example that comes from Geoffrey Huntley, the author of the Ralph Loops.

But even as a kid running through the house with a knife, it was still enough to do coding. And GPT now we have models like Opus 4.5, GPT-5.4 that are much, much better.

But a very interesting element to think about is

open weights models are kind of lagging behind by 3 to 6 months compared to frontier models, which means now we already have models in the open that are smarter compared to Sonnet 4, which I already used in library-level development.

How long would it take for those open weight models to become good enough to be used in our daily operations? I don't know. It's just one thought that lately I have more and more, especially because, well, Anthropic is putting arbitrary restrictions on how we use their models, so I don't really want to use Anthropic models.

OpenAI is good for now. Who knows what they're going to do in a year or two. And I like open source, of course. Okay, I don't have a git repo created. Create an empty

git repo. And by the way, if you have questions, if you want to interrupt me, this is supposed to be interactive. I'm here to entertain you for another hour and a half.

Initialize the git repo. Okay, this is done.

It's amazing that using GPT-5.4 with open code would create by default a Claude.md. I think, like, this is from Bun. Yeah, let's trash this.

This absolutely has nothing to do with this recent link.

Perfect marketing strategy. Plus they said it wasn't a real fool, and two days after they announced Mithas as the new model.

Okay, I create a source and test directory.

Let's see what it created.

Okay, it types Bun. Bundle mode no emit.

That's fine.

Strict. Skip lib check. That's fine. And please it override. That's good.

Yes. Also, actually move the

files

in the proper directory.

Moving the entry file. Good. Seems smart enough.

Run some basic smoke test. Okay.

Okay, so that's a good starting point. We verified with Bun run test. Bun run type check. Good. We want to add Effect beta. We're going to use Effect v4. It's not yet released for production usage, except he uses in production already.

So if I have any problem, I'm going to ask you. It's fine.

It's the small repo,right?

Yes. It's Effect small. Small because it used to be small and evolved to become bigger. Still very, very thin in bundle size.

Okay, 1% 14k. There's plenty of context left. I want to add Effect beta, and we want to use Effect Vitest to write the tests.

Just the LSP.

I will. I will. That's next. That's next. And speaking of that, I want to try to use the TSGo version of it. Now, I never used this, so.

I used it. It's totally ready for production.

What I want to use I haven't used it, so I don't know how to use it.

Let's set up

as the compiler for as the

type checker. Check the README and set it up. Not sure if this is going to work or not.

I'm not sure how it works with VS Code, but you might want to install the VS Code TypeScript preview extension.

Oh, the actual base compiler.

Because you can use the package repository, and you can use only the TSGo version of the VS Code as the primary source.

Yes. I don't know if Matia.

It works.

Allowed.

It's TypeScript, but it doesn't really use it anymore.

Yeah, the point is it does not use it, and

we could just do an alias install. So install TypeScript as something else. But I'm not sure if

he did it. Maybe let's follow the normal practice. Let's install TypeScript Go instead of

TypeScript. Would it be able to do this? Who knows.

You should use the TypeScript Go normal one. It's a bit difficulty to use the language service together with

the original TSGo, I think.

Well, we will find out.

We will find out.

Is this the package? No, I don't think this is the package.

No.

No.

I think they just stole my crypto wallet, except I do not have one, so.

Check from here.

Oh, the NPM package name TypeScript Go is only a placeholder security package. So I used the real preview compiler that provides the TSGo binary. Well, that was probably a good idea. Script TSGo no emit.

Let's see.

Bun exec. It's going to not found. Okay.

Okay, type check.

Bun run type check.

Okay, set up VS Code to use TSGo.

The TSGo LSP.

Will it work? Maybe.

That's it. So there's two settings it needs to set. There's to set it to TSGo enabled, and also to the log book. I mean, the log book only if you want to use the language service.

That's what you need. That's the extension.

Yes, that I need.

So we only need to install the new one.

There we go. Native preview. That's it.

Okay, I did install that.

Do I need to reload the window? Most likely.

TSGo.

Okay, maybe it worked. Then let's go here and.

The famous AI, I think you can just tell it to point it to the repo and tell it to set the settings.

Yeah, I should be able to do that.

But also the reason I

will not be loaded if files are specified in command line.

Nor config to skip this error. What?

Feed it to the agent.

I'm going to feed it to the agent in a minute.

It's Bun that gives issues.

Probably. Maybe not. Yes, it is Bun.

Then let me stop this. Select the TS config to configure. This one. This other is a package to JSON. Installing dev dependencies.

Select all.

What is this?

That's VS Code. That's fine.

Okay, this needs a lot of work.

Do we have the Effect pattern installed? Oh gosh.

Where is this coming from? Who knows.

Okay, okay, okay.

Bun

install. Okay, that's installed.

Let's see if it catches anything. Import.

Add from Effect.

Let's see it. 100.

Nope, that's a dangling effect. That should be.

You need to do the post-install hook for the language service to look into it.

I think I've done that.

You mean the prepare one?

Yeah, that one.

Yeah, I did.

Maybe I need to reload.

Yeah.

Reload after that.

Yes, that was easy. The Windows solution just restarted.

Okay, so we have it. And now.

Now we want to

we have some diagnostic severity to suggestion, warning, and so on and so forth. For AI, we would like to turn everything into an error so that the

LLM cannot

pass, cannot accept code that has any remote resemblance of an error. So this is

a project where we will use AI a lot. We want all diagnostics available for to be set to error.

I should switch from TSGo to whatever. Fine. Okay.

What is the model doing? Wow.

So it did update the TS config? It did not.

Oh, I'm updating the TS config. Okay.

Do you want to use the Effect solutions?

No. No. No. And that's another interesting point. The Effect solutions, there is a website called effect.solutions. It's a really nice website. Kit Langton did this. And it's kind of a quick start to use Effect in an AI project.

And it does install the language service and strict policy defaults and so on and so forth. But then it uses a CLI to give the model access to the Effect repo. And

the model needs to know how to use the CLI. So it's kind of a dog beating its tail.

I think the CLI it uses more for the to access, basically, whatever's in this documentation. What's in the website that is exposed through a CLI for Effect solutions, not the repo.

Yes.

So you use this LinkedIn.

Yes, but.

There are some Markdown files.

But it doesn't work as well. And if you actually read at some point, it says you should actually just clone the repository.

Okay, this looks exactly what I had in mind. So we have all the diagnostics set to error, which is good. It's exactly what we want.

Reload window. Okay. I also want to.

Custom save.

Format on save to true.

Just because it's annoying otherwise. Okay, very good point. Commit current. Commit current. Oh.

Now I want to add Effect small as a subtree.

Okay, it's committed. Good. Now create a .repos folder and add as a git subtree without history. Squashed.

In repos effect.

Who knows if it's going to be able to do it.

Repos. At least it did MKD here.

Why is it trying to? Okay.

Okay, we have it. Let's just check git log. Yep, it did add it.

Okay, and now we are at the point where we can start to do our research. For example, we said we want to create an HTTP API. I would clean up this. Open a new session to avoid context pollution.

You have access to the Effect repository at repos. Actually, let's do something else before we want.

Set up the agents.

We want to set up an agents.md. Set up an agents.md listing the commands available, like Bun run type check. And specify

that you have access to the Effect repository at repos effect. And you should use that to extract best practices, look at how things work, etc.

Now, the agents.md, now we're going to get an initial prototype. As you work in the project, you're going to evolve that. You're going to add more commands to it. You're going to add rules when you spot that some bad patterns are created in code.

One thing we haven't set it up yet is a linter. Linter is going to be an essential piece of the backpressure loop that helps the model drive in theright direction. If you want a kind of fully working setup, I have a repository of mine that I use for fun, which is called Accountability.

In this repository, you can find

a lot of things. But for example, I have an ESLint config with a lot of custom rules. And those are arbitrary. For example, I don't want the model to do an explicit type assertion on things. I want the model to use schema to check for the shape.

I have rules prohibiting the usage of x as z. I have rules prohibiting the usage of any, of unknown. Basically, I'm trying to avoid the model to do dumb stuff that I realized it was doing in my code.

Any is easy to disable, but type assertions? I think no,right? You can't tell TypeScript config to.

No.

Bad as.

Yeah. The same for unknown.

Yeah, as unknown is something.

And the funny thing is, initially I banned unknown because I wanted the model to not do as unknown as x. It found that never is a bottom type, so you can do as never as x. I was like, okay, then I'm going to ban as.

And now it's doing better.

Okay, let's see what it created. Okay, this is sure. Use Bun. Okay.

Available project commands. That's fine. Test watch.

This is going to create issues, I already know. Because the model is going to try to run this and get stuck. Same with dev servers.

Effect reference repositories. Good. Look at the for repository specific guidance. Okay, that's enough of a start. Mention in the agents.md that you should never, ever try to run commands

in watch mode. For example, you are not allowed to run

or a dev server. Otherwise, it's going to try to run the dev server as the first thing and get stuck.

Okay, what I like about OpenAI models is that they are way more concise compared to Anthropic models. The same task with Opus would have probably wrote 200 lines of agents.md.

But that's good. It's enough as a start. So we are back to square zero. We said we want to create an HTTP API. I know nothing about Effect. So

I would like to create an HTTP API that should have OpenAPI documentation and type save client generated by default. Explore the Effect repo for patterns on how

to

do this.

Save your research into patterns.httpAPI.md.

Ask me any question you need.

Again, I'm starting from the perspective that I have no idea how to do this in Effect.

Do you tend to use plan mode in open code? Or not really.

No, I find plan mode to be

the issue with plan mode is that the model has crippled access to tools. So it cannot easily do the same things that it does outside of plan mode.

So I don't make heavy usage of it. I usually do what's called Spec-Driven Development, in the sense that the first task I do with the model is I discuss with the model how to create a spec for something.

Then the spec is persisted as a Markdown file, which is effectively my plan. And I tell the model then to implement that. Usually, the second step I do in a Ralph loop. Because you've seen I already restarted open code a few times to clean up the context window.

Doing this manually is boring, and you usually end up reusing the same context window for multiple things. And it's going to just deoptimize the model at some point. Because the context window is limited, you're going to push a lot of information in, and the earlier information is going to confuse the model for the later information.

So I use a very simple Bash script that tells the model, pick up a small task, implement the small task, and then exit. And I run that in a loop.

It's funny how with AI, many times less is more. You can have very complex architectures around context management and so on and so forth. At the end, the dumbest thing ever ends up working better.

And we are doing research

by ourselves, and it looks like there's actually very good margins of improvement by reducing the number of tools that the model has access to. For example, we have been experimenting with a coding agent that has a single tool call, which is called Execute.

And it can execute arbitrary TypeScript code, including calling Bash through TypeScript. And in that scenario, the model doesn't even have access to a patch. It cannot change files directly. It has to write a TypeScript file that changes the code.

And then it ends up doing TypeScript transformers, AST-based transformations. It's fantastic how you reduce the things that the model can do, and it does better. So let's see. Save the research to HTTP API. Good. Main conclusion. For this repo, the strongest default Effect pattern is to define a shared HTTP API.

You're absolutelyright. Derive OpenAPI from it. Mount the docs.

Okay.

OpenAPI generator only when you need generated client artifact. We don't know. We don't need that. One question before I implement anything further. Do you want the primary pattern here to be shared HTTP API with HTTP API client.make?

No.

I am fine with a shared HTTP API.

I don't need a committed client in the repo itself.

Let's see what it did here.

For this workshop repo, the best part, okay. This gives you relevant upstream files. Good. It looked at tests.

Nice.

Okay, this looks like a decent enough. We should probably tell it what we want to do.

But this is just generic patterns that we're going to use as reference. So list the files in patterns in the agents.md so the agent has context of their

existence. Model does not care about grammar.

And I feel like many people raised the point that

a model is not good at something if it doesn't do good by default. I don't think there's anything more wrong with that statement. The model is good when it can operate a large-scale code base using patterns, and it doesn't fail at scale.

The 0 to 1 problem is not really it's a problem for the first 10 days or 10 hours, depending on what you're building. And

as programmers, if our job is not to write code,

our job should be to set up the repositories in ways that the models can act good on it. So what I'm doing now is like most of what I do when I operate a coding agent at scale in a code base, even if the code base has no concept of AI.

If I start in a project that is brownfield, code base existing from 5 to 10 years, no context, set it up. The first thing I do is let the model explore the code. Clone the main libraries that are used.

If you're using a framework like TanStack or so on and so forth, clone the code of TanStack Router. If you're using Svelte, clone the code base of Svelte. Ask the model to generate best practice files and so on and so forth.

Once you have all of it, the model is going to be much more efficient. So now that we have a little bit of context on HTTP APIs, we can start implementing one. I do want to check something quickly.

Because I'm using Bun, and I'm using Vitest.

There's a Vitest run. Does Vitest run actually uses Bun as the runtime, or does it use Node?

Because if I recall, there was a flag that I had to pass to Vitest to let it use Bun. And I don't want our test setup to defer from our

what is it doing? No.

Add to Vitest that it should ignore anything in repos. It was running the Effect tests that it found.

Okay, there was no Vitest config whatsoever. Good.

Add to the test something that uses a Bun API.

I feel like I did it here. So I should have

test Vitest run. No. Okay. Was I using Node? Probably.

No, you should expect it to be defined.

Because now it did one of the classical mistakes. It had to make the test pass. It changed the test to make it pass.

No.

Wow.

Okay.

Okay, it did it.

Let's now begin our HTTP API implementation. So we want to implement an HTTP API following the patterns at

patterns teaching HTTP API. We want the API to

expose a to-do functionality where you can, one, create to-dos.

Description. Title. Description.

Two, update to-dos. Change title, etc. Three, flag to-do as done or not. Four, list to-dos.

I should have done something else.

Discuss the plan with me and create a plans to-do API.md. So here I'm telling the LLM to read the pattern file that we created before, where it's going to gather generic knowledge about the Effect ways of doing things.

It still has access to the original code base of Effect if it wants to. But now I'm creating a specific plan

to implement the API that I would like to that I would like to implement.

Drafting the plan. Okay.

Minimal to-do shape. That's fine.

Initial storage strategy. Okay, let's do something different. For storage, use Effect SQL and SQLite store.

Explore the Effect repo for how to do that and create patterns.

Patterns

SQL.md.

Okay, I realize we need a persistent strategy, and I don't have a persistent strategy.

I know that Effect has some SQL thing. And again, I'm

using the same process where I first generate some patterns for it. And this is also useful because you may want to use something from Effect, but you may not want to use everything from Effect. So if we were to push all the patterns in your repository by default, you would end up using everything from Effect, even if you don't want to.

This is kind of self-select. So you can pick and choose whatever you want to use. Especially in brownfield projects, this is very important because you don't want to refactor everything you already have.

For example, here I could have picked Drizzle to do the persistence just as well.

What are your thoughts on potentially using GitHub to use up something for patterns and other reusable components, even the agents md, maybe, so that you can reuse them to start up a project immediately and then go into.

Most likely, we're going to develop some kind of CLI where you can prefetch some patterns that are already available and still let you pick and choose. And we also want to automate this kind of process of exploring something, create patterns out of it.

Because the patterns that we have as best practices might not exactly fit your needs. So you would still maybe update them as a second step.

Also, the model I use may not be as good as the one that you use, but it also happens. For example, the PRs that are submitted to OpenClaw, you go and you read the code. Some of them are just used the free version or the lowest version of any model.

And the code it generates, also the documentation, everything it generates, is not as good as the one that we use. So I was also going to ask, what if the framework library authors are providing not skill slide or solve-able, but this kind of pattern libraries, like Effect solutions, but officially distributed by the package, collocated?

I feel like generally, it's a good idea, but there are some caveats to that. For example, even the agents.md standard is kind of not a standard because the way you prompt Claude and the way you prompt GPT is different.

For example, you've noticed I never wrote anything in uppercase. If I was using Claude, I would write a lot of stuff in uppercase. The reason is GPT gets scared if you scream at them, at it. I don't even know how to call the model.

And if you scream at it, it's going to deoptimize and then be passive and agree on everything. That is not what you want. With Claude, if you scream at it, it's going to pay attention to that specific sentence.

So that comes also in these shared patterns. I feel like the patterns should be almost generated with the model you use versus being off-the-shelf. Now, we can do that for the top three frontier models. All the GPT family is very similar.

5.3, 5.4, 5.2, there are not so many differences. Opus, Sonnet, and Haiku are also very similar. So ideally, we can have the CLI where it says, which model do you use? Okay, I'm going to optimize the context for this versus the context for that.

And it's annoying because you would obviously like to have a standard.

I would want to maintain it as well.

Yes. Yes. It's very painful to maintain this stuff.

Maybe you can treat it as a derivative so that you have theoretic patterns for certain things in a non-specific way, and then by each model, you turn them into useful patterns.

Our approach is to make the code as good and self-explanatory with examples and everything that any model you use can generate those. And then the CLI would generate them on the spot for the model you use. That's one approach.

It may fail, and in six months, we provide patterns for everything and just tell you, please use either one or two. Another very interesting argument is fine-tune an open-source model to use Effect patterns by default. We thought of that.

It's like a sub-agent to audit and make your code base ready for Effect.

Kinda.

Okay, let's see.

Update the HTTP. No. If you want the next step for me to update, yes, do that. This is the annoying part of GPT models. They're going to ask constantly for input from you to continue. Opus would have just done it.

But sometimes it does it wrong, and you have to do it three times, and then your session limit.

That's why I use GPT-5.4. But I'd like some sort of fusion and inbred fusion of Anthropic models and OpenAI models so that it doesn't ask me all the time. Because GPT usually, especially in complex tasks, takes its time, but at the end, the output is good.

With Opus isright. Sometimes it likes to take these shortcuts. And the funny thing is, if you let one slip, it's going to repeat. If you let one any slip in your code base, and if you have Opus, it's going to do as any all the time.

It's like, oh, I can do this. Let me do that for everything. I need this to compile. Let's remove the code.

So you can ban it in the limiter?

Yes. That's why in this project and in accountability, I was using Opus, and I have a lint file of thousands of lines of code to prohibit any shortcut. I can start implementing this next? Yes, please.

I feel like we've spent enough time.

And let's see what it does.

See, it's correctly looking up

in the Effect repo,

in the AI docs for ideas.

This most likely is going to take a little bit, which is positive.

Do you use anything for schemas to support a bit schema generation when you use AI

to model your domain?

Kind of.

Or?

In some projects, it was using schema by default, and I didn't need a lot of back pressure for it. Sometimes,

yes, one example is the rule in

accountability. I have this yes lint rule, SQL.

Custom yes lint rule to ban SQL type because it would write an SQL query. It would write an interface, and it would just this is the exact same thing as casting.

And I had to ban this pattern fully. And it's using type parameters with SQL template leader that provides no runtime validation. Use SQL schema. Find one. And you see that the rule

ends up suggesting to use SQL schema.

So I'm more or less just watching what the model produces. And if there's something I don't like,

I end up writing lint rules to prohibit that specific pattern. For example, in schema,

many times it would, for example, have a user ID as a string, and then it would have another ID as a string, and you would, of course, have no type safety whatsoever, and the code would try to pass one into the other.

So I would force all identifiers to be banned at types. And I would then prohibit the usage of type casting because otherwise, it would do like, this requires a user ID. Let me do as user ID. And it's like, yeah, that's pointless.

You should validate the data. So I would ban the usage of as and force them to use constructors. So instead of doing 100 as user ID, user ID dot make. Or prohibit usage of constructors in places where you should do validation.

For example, one case that I found was it would do the API layer as plain strings and then use constructors inside the handler to create the objects, defeating the purpose. Then I would write rules for the model to write validation directly in the schemas so that I was basically saying, if you use a constructor inside the handler, most likely you're wrong.

You should improve the starting schema to provide the validation at the edge. It's kind of babysitting a junior developer

with a knife running through the kitchen instead of a kid running through the kitchen with the knife. This is still going.

You said that you usually use both

Codex and Claude. How do you decide when I should use Codex and when I should use Claude?

Both models are exceptional. Sometimes one model drives you nuts, and you try the other. There's not much of a rule. Lately, I tend to use more OpenAI models because I don't really like to be restricted on the harness that I can use.

What do you mean by harness?

The CLI itself. I want to use OpenCode. I want to use my own TypeScript files that interact with the AI SDK natively, and I'm prohibited from doing that from Anthropic. So up until a few months ago, when this was allowed, I would use mostly Opus.

When they enforced their policies against OpenCode, I switched to OpenAI models, and now I'm most of the time just using OpenAI models. There are some small edge cases. For example, when you do UI, Opus is much better than Codex.

So

there are some specific things where one is clearly better than the other, but for most of the tasks, they are the same. I just had some experience, for example, where GPT

thought for half a day on a bug that I had and went nowhere, and Opus one-shotted the solution. But I had the opposite experience too. So it's very hard to know which one is which.

You can fall back. Start it one, and if it fails or takes too much time, then kill it.

You could.

Dramatically.

You could. You could. You definitely could. Okay, let's see what is this creating. Okay, it created an SQL client. The layer looks

correct.

Has migrations.

It decided to inline

the migrations. Okay, that's a valid choice.

Okay.

It correctly provided the SQL live layer to the migration layers.

This feels like duplicated.

There is clear duplication between those two.

I used a clip for this stuff. It creates multiple things that are doing the same thing, and it's not importing it to another. It's also a way to fight with the slope hammers. Sometimes you refactor, and it leaves one code in place.

And it's like never exported, never used in the same file. NIP catches them quite well.

Okay, good to know.

We are, in our experimentation, another thing we're doing is we're using semantic code search. Because we've noticed that a lot of times, the model re-implements the same features because it doesn't find it. And with semantic code search, it finds it.

But okay, there's a duplication here. I'll probably tell it that there is a duplication at some point. I want to check the API.

Exactly. You see it's using plain strings for identifiers. So one of the future things that we might want to do is to tell it to use branded stuff.

Okay, to do not found, it added a schema annotation to flag that to do not found should be a 404.

This looks decent. I don't understand why it sometimes creates structs instead of classes. I personally prefer to use classes.

So I would, in the future, either create a best practice to prefer classes, or depending on how strict I want, create a lint rule to prohibit usage of schema.struct in specific files and stuff like that. For now, it's obviously it's fine.

It doesn't need to.

Is it not something already part of the RSP to prefer classes for schema?

Not sure. There might be, but it's not flagging anything here. And the LSP is on.

Lint all the files.

Lint with what? We don't have a linter in place.

Lint.

Good point. We also do not have formatter in place.

Let's ignore for now. Let's see.

Okay.

Client with a base URL.

That's good. We have the live handler.

Server. Index is just exporting everything.

The index.ts should probably

run the server instead of exporting everything. Do that

condition checking that the file is main so it doesn't

run when you import the file.

It also created some tests.

Do you have some global agents and the file?

No. No.

What is it doing here?

It created an arbitrary with HTTP

to run an effect. Make test HTTP live. Yeah, it's one way.

Do the test actually pass? One run test. I'd be surprised. Wow.

Is there a start command? Add a start command to start the API server and tell me where to find

the OpenAPI

docs.

Okay, it really likes this pattern. As a future thing, I would probably just tell it to use it.layer instead of using the with repository and with

thing. But let's see if at least it works. Bun, run, start.

Good. Way of listing to-dos.

Let's check the OpenAPI. Good. There is an OpenAPI spec created.

This looks decent as a first.

It shows the schemas properly. Good. Okay, then let's maybe

it did create a database here.

Let me maybe git ignore the full DB.

DB to-dos.db.all.

Todos dot db.

To-do like as with.

To-do. You'reright.

I want to say do the dash.

Yeah.

No longer able to write anything by hand.

30 minutes.

Yes. Okay, let's actually clean up the tests a little bit.

So,

clean. You see, I'm fooling myself in wanting to use the same session over and over again. That's when Ralph loops are really useful.

We created a lot of mess.

You.

You created a lot of mess in tests. Clean up everything. This should be the cleanest code you've ever seen. Not like the crappy Python code you've been trained on. Do not use patterns like

simply use it.layer with layer.

And put utilities in their own folder. No offense to Python developers, of course.

Probably a better approach is to create the patterns for it.

Probably. Now I'm winging it. I'm going to see if it's able to do it. If it does, once it's done, I'm going to create a pattern from it. But yes, that would have been a good idea.

Which is why automating the process is very important, because we are lazy. Like now, I was so lazy that I didn't want to create a pattern for it.

Maybe I'll use test utils layers. Maybe. Maybe.

Can you explain what it's about? It's a bad pattern there. I'm not very familiar with the.

Oh, the bad pattern.

Yeah.

It basically created a function to provide a layer

to an effect. It built the layer manually. It wrapped everything in an effect dot scoped, which is going to close the layer once this is done.

And my guess is that it did this because this pattern is actually used to test some layered internals in the codebase, but it's completely unnecessary here.

But if you look at the file, even without knowing details of effect, it stinks.

Something's notright. Now it cleaned it up. So

when you see something that doesn't lookright, usually just ask the model why you did that. Is there any alternative? And in this case, I knew that to provide a layer in test, we should just use it.layer. So I kind of skipped that.

But in reality, I would have if I didn't notice, I would have discussed with the model that I didn't like to see that repeated thing all over. And sometimes it's necessary. Sometimes you're wrong and the model isright. That's the way to do it.

In this case, it was completely unnecessary.

Do we have describe dot layer as well? Or not really?

No, I think we have it.describe. So you would do it.layer as a top thing, pass the layer, like whatever.

Then

in the closure, do it.describe.

Could probably also add an it.describe as a short. Models don't care about verbose code. Why should we make it less verbose?

But does it do any cleanups between tests?

Yes.

So if we do it in the top level, it will poison the other tests.

Yes. Yes. But you can do it per test still.

Now, it does poison the other tests.

And the other alternative is that you just.

The other alternative is you provide it.layer at every test.

The reality is whenever you're using a database, in this case it's SQLite, so the argument is kind of moot. But if I were to use a Postgres in a project where you have hundreds of tests, spinning up a Postgres instance per test is going to make your test runtime two days.

Two days, maybe. So usually what I end up doing is I end up making tests that can run that do self-cleanup. Like, for example, I run a test within a transaction and I roll back the transaction as soon as the test finishes so that they are kind of atomic by the fact that they don't leak that.

It would be another pattern that we can tell the model to do. It would be a matter of creating the transaction and the rollback. But there's alternatives.

How does the model know about the effect library? I mean, related to instituting the text 7 or something like this? Or are you just relying on the model's knowledge about the library?

No, we added the effect codebase in a repository folder. We created an agents.md that references

the effect repo. And then for the features we wanted to use, we asked the model to create patterns by looking at the repo, investigating how things are done in the repo as kind of general knowledge. In this case, we did one for SQL.

We did one for API. Now, the good point is in this session we have best practices about testing. So let's create patterns/testing.md. It should include all the best practices of testing effect-based code, including usage of it.layer,

year, etc.

And also update. I'm going to queue that agents.md to reference all the patterns in

dot patterns. And the next thing that you would do to automate the flow is, for example, OpenCode allows you to create slash commands. Claude Code allows you to do the same. You optimize for slash, new pattern, whatever you want.

Are we going to skill, for example, within Discover it or anything like that?

You can create skills and tag the skills. Skills are very useful for these kind of things.

I'm kind of against skills in general. For these things, they are ideal, but many people think that just by adding a skill, you're going to make the model good at React. You're going to make the model good at Next.js.

The reality is if you put a skill for every single Next.js internal, you're going to pollute the context and not get anywhere. So skills have a very good use case, which is this kind of use case. And I guess they are more general than slash commands.

So I tend to do slash commands because I tend to use a single coding agent. But definitely, if you are, for example, in a team where everybody is free to use their own agent, maybe some people use Cursor, some people use OpenCode, some people use Claude Code, skills are a good baseline.

Let's see. Patterns testing.

Use effect b test for all effect-based tests. Use it.all effect. Use it.layer. Avoid custom wrappers. That call layer.build. This is a very specific rule. Now, a friend of mine told me whenever you read a rulebook, a legal rulebook, you find those specific rules that are just like when you enter a pub and it's like, don't do skateboarding on top of and you ask yourself, why does this rule exist?

Because somebody did that. Why does this rule exist? Because the model did that.

Why this pattern? Okay. You see relevant files. They're all linked.

Yeah, they need to be maintained. That's the file references that is the.

Yes. And

there's a friend of mine who's writing a linter plugin that checks for existing references. So when you add

when you change code, it runs in the CI and says, hey, this reference is broken.

Also, sometimes instead of relative path, they give the absolute path.

Yes.

And you see your name.

Yes. The full slash home slash whatever. Yeah. Yeah.

I guess another approach you can use is that you actually write tests for your patterns.

If you treat them as their own artifacts, then you can keep evaluating them.

How would you write a test for a pattern?

In the programming code. Like you have the pattern and then a test.

You mean actually write a file.

You use the pattern in the test and then evaluate the results on what you expect to be and work and compile and.

I feel like that could be a way. Sometimes the code that is inside the patterns is not really executable.

I guess it has pros and cons. It's definitely an interesting idea. For example, maybe with an additional tag like ts execute this to flag which of the patterns you actually want executed. Or like references, which files you want to be referenced.

Because sometimes it mentions files as examples. For example, if you write this feature, you use a file called abc and that's not a concrete reference. So you don't want your program to fail because it read that.

Maybe you can use it even just by triggering have a command using your pattern, then to actually write code as part of the test and then you evaluate the output that it is entirely what you expect. And if the models evolve or change, it can also.

That's more in the direction of evaluation. So evolves.

So you're kind of testing for patterns and skills and that sort of thing.

Yes. That's at scale. That's very good. I found doing it on a per-project basis ends up.

Yeah. Not on per-project. If it's more like your domain, because you spend more time curating these things than actually writing code or eventually reviewing code. So maybe saying quality controls as you would do for code is useful to do.

What we are thinking of doing in the effect repo is, for example, to have evals running once per day and generating reports. So anytime we do library changes or we add more docs, we add more examples, we see exactly if the outputs are better or worst.

Sometimes in evals it's very hard. Like even Anthropic a while ago wrote a blog post where the summary of the blog post is, we don't really know when code is good or bad because

is more terrace code better? Depends. Is more verbose code better? Depends.

There are some properties where you can say this is definitely better than not. Like code that type check is better than code that doesn't. Probably true. But when it comes to style, when it comes to is this file structure better than another file structure and they both convey meaning, you kind of need a human at the end to say, yeah, I prefer this.

And if you take 100 humans, you're going to have an 80/20 split. So we have the same problem now with defining effect patterns because we are running evals and evals are kind of our opinion of what's good. And it's not really

an absolute truth. Let's put it this way.

So do you have an LLM track that checks for certain patterns? How do you run these evals?

We have humanly written best practice code. We have generated code and then we have an LLM that matches and says, is this too different or not? Give us a score. And that's pretty much how you run the eval.

Not a very nice way to run. But we're trying to figure this out because we are thinking of fine-tuning a model on top of effect. And for the reinforcement learning part, we are going to need to have good evals.

So it's part of what we are researchingright now. There's noright or wrong answer. If there was, all the models would perform the same because everybody would have the same evals. Everybody would have the same thing. But now we have all the patterns for what we want.

So I feel like we are at the point of saying commit this.

I'm going to create a repository and push it so that at least you have access to it.

Gosh, I'm too big.

New repository.

Is it public? Please choose an owner. Sure.

Add or agent.

And push.

Pushing the final repository. So hopefully.

So we haven't got to the point of doing clustering and workflows.

Just sharing a few words about why you would want those aspects in your code. This is a very dumb to-do API. One thing I wanted to add would be authentication and registration. For example, when you have a registration, your process is usually write something in the database and then send an email.

Or send an email code and wait for confirmation. Anytime you do two unrelated operations, there is no transaction between them, no database transaction between them, and your server may fail at any random point within your code. So it's very hard to guarantee that the email has actually been sent, which is why many times in a registration procedure you see the sentence, if the email did not arrive in 30 minutes, please retry.

You retry for me. Why should I retry if I haven't received the email? That's a symptom of a badly designed system that cannot guarantee that two operations happened. To do that, you have various ways. One way is to implement queues and so on and so forth.

The other way is to use something like workflows. You have solutions like Temporal, Ingest. There's many workflow solutions. Effect has one

implemented on top of what is called effect cluster, where basically you run a cluster of Bun, Node, whatever instances, and the system itself guarantees that once a procedure starts, it's going to finish. Even if the server crashes, it's going to move to a different location.

How I would go about it? Same way as I did now. Ask the model to explore the repository, extract the patterns around how to use effect cluster, how to use effect workflows, and just

gone from there. It's very interesting. It's still in the unstable part of effect, but it's going to be stable very soon. And we think especially with if you

integrate AI in your app, it's going to be even more important because with AI, every process becomes more long-running. Like LLMs take minutes to answer. There's a lot of things that can go wrong in a minute. If the average response time is 10 milliseconds, server is pretty much never going to fail in that 10 millisecond.

If that 10 millisecond becomes a minute, yes, you're pretty sure the server is going to fail in that minute at some point. And usually

before the companies that would use workflows were larger scale companies because at scale every edge case happens twice per day.

With longer response time, even if you have 10 users, you're pretty much going to have disruption if your average process takes a minute and you're going to have failure all over the place. Which is why, for example, Temporal became much more interesting in the past 12 months because everybody's now implementing AI in their own products.

They have chatbots. They have any kind of AI-driven process. And with effect, you get workflows, you get clustering, you have AI integrations, you have Discord, Slack integrations, and so on and so forth. So the system is really composable and the models are pretty decent at it.

We have a working API. I've been speaking for about an hour and a half and I started with zero effect knowledge. It was an empty repository and this is why I wanted to call this workshop, just clone the fucking repo.

That's pretty much it. If you have any question or anything else, I'm happy to discuss with you at a later point. And let's get the next speaker set up. Thank you so much.