DEV Community: Y.K. Goon

AutoGen, Eliza, Aider

Y.K. Goon — Thu, 23 Jan 2025 02:28:33 +0000

I got around to building what they call AI agents. This is a report on the explorations of the toolsets.

Half my intention here is to make use of code assistants to do the bulk of the work here. Aider has been living on my machine more than half a year; it's time to make it earn its place.

Aider has been steadily improving, updates are pushed frequently. It's an undiscovered gem obscured by hypes like Cursor.

But putting it to use is like learning to a new musical instruments, all while having access to the instrument you're good at (handcrafting code).

Telling Aider what to do is just not as natural as writing code by hand; every so often in the process I revert to writing code myself. I have to actively fight this urge.

At this point, Aider has this feature that monitor for comments in files and make changes in real-time. On top of that Aider reads documentations when given URLs. Both of these make it game-changing.

Onto making agents. The instinct is to pick a framework that makes everything easy.

But I've been around the block. If you intend for what you build to have a decent lifespan, frameworks should be approached with heavy dose of caution.

Framework-less development means not having your fate handed to other people's hands. But it also means repeating mistakes that has been made by others.

A healthy use of frameworks is to have them be responsible for the right layers of abstractions; things that you have no interests in tweaking in the future. Problem is you probably have no idea what those things will be when you get started.

I was aware of CrewAI a year ago. I was waiting for cool ideas to hit for me to put it use. That did not come. Not that there was no cool idea, but none that warrant the use of a framework to coordinate multiple agents for one single task.

@truth_terminal came along, that gave me inspiration. I absolutely don't have to build anything useful. In fact, trying to be useful is recipe for mindblocks.

What I now want is simple: three unpredictable off-the-wall LLM agents talking to each other. I want to see if they are capable of reaching upon insights that are new to me. This feels promising.

Now, creating one single agent is trivial. I write arbitrary ones that run from within Emacs all the time.

The Eliza framework is newly popular, the results look promising. I built two agents/characters running on it. The process of creating an agent with lores and specific knowledge was rather involved. It's like a five-page form that you have to fill in the format of a JSON file.

I randomly generated most of these details, even that took me half an hour to craft a character. The upside is it's an entirely creative process of character creation, void of any engineering concern.

The inner workings of how these character details eventually got sent to LLMs are abstracted away by Eliza. The end result is impressive, the characters do speak in personalities consistent with what's configured. If you intend for it to sound quirky, given enough sample texts and background stories, it does come out sounding quirky.

In fact that's Eliza's bread and butter: create personalities. You know, as opposed to getting things done (being useful). Nothing wrong with that.

Until I want to have two characters talking to each other. There's just no way to it unless I'm willing to have the conversations take place publicly on Twitter. At least in this iteration, Eliza is simply built to run one single awesome Twitter chatbot.

It feels like the fact that Eliza being written in Typescript is the draw by itself. If this is true, I find this suspicious. The quality of the framework should stand on its own, not its choice of ecosystem. Many products in the Javascript world has this quality.

That said, the amount of plugins being made for Eliza is impressive as a social phenomenon. Plugins are responsible for giving agents abilities beyond just talking. If Eliza were to have a long shelf-life, these plugins will be the factor.

However, how lindy is Eliza remains to be seen. From what I've digged around in its innards, Eliza feels overrated.

That's an ironic statement. In the interest of giving you an idiot-proof method for creating an autonomous-KOL, it does a lot on your behalf. It does too much, I may say. If your use case goes just a little off their course, there's no easy way but to hack the framework.

Subsequent research brought me to AutoGen. It does not try to do too much; not being opinionated is part of its deal.

Most of all, it's trivial in AutoGen to have multiple agents talk to each other. They've got the whole team-infrastructure figured out.

Once I've tried it, it's not as intuitive to create characters that speak as coherently as Eliza-made characters. Tweaking characters' behaviors took repeated prompt-engineering. But I am better off tweaking prompts in English than wrangling a framework to get what I want.

AutoGen was created to get things done. It came with agents that browse the web, handle files and run code. All the things an autonomous being is expected to do.

As far as I can tell, it does not come with RAG built in. The ready-made browser-agent is also giving me a hard time with Playwright, where it's somehow not installed perfectly on Arch Linux.

AutoGen does not have the social validation of Eliza, but it does have the pocket of Microsoft. I'm more optimistic about AutoGen's lindy-ness.

It's a matter of time before I get my agents to write and run their own code. For now they would have to settle for making trippy conversations among themselves.

Before I get there though, I have this inkling that code written by machines should not be subjected to the same criteria as code written for humans. Though like it or not, LLMs still end up writing code like humans.

But fundamentally, if these are code written autonomously by machines themselves for themselves, there's no reason why code should be arranged in ways that are human-friendly.

It's conceivable to me that machines prefer writing assembly code because it makes more sense to them.

It can be argued that we still want code-legibility as a safeguard for humans to peek at, but ultimately that's a losing battle. That amounts to demanding a new life form to conform to human standards, which itself is tenuous at best.

Deep dive into Mentat coding assistant

Y.K. Goon — Wed, 24 Jul 2024 09:52:16 +0000

Following up from playing with Aider coding assistant, I've been using Mentat to code for the past few weeks.

Comparing with Aider

The way it works is similar. It runs on the terminal with a textual UI. It even lets you set light and dark mode color scheme. Coding sessions involve adding relevant files for context. In the chatbox, you make your wishes and it comes back with an action plan involving code changes. Approve them and changes are made.

The experience as a whole is close to Aider, except Aider makes a git-commit for every change (which you can opt out). Mentat leaves the version management to you.

The quality of how you phrase your wishes determines the quality of the work. You have to be pretty verbose about it. What comes back is a function of your choice of LLM. I won't attribute smartness to the coding assistants, but I would credit superior development experience to them if any. No matter which one you use, you still have to talk to them like a clueless intern.

Context limit

Out of the box, Mentat supports is a meager list of LLMs compared to Aider (that might or might not change). I didn't let that be a problem, I hooked it up to use a coding LLM in Together.ai.

But it didn't matter; I ran into context window limit right off the bat. Granted some of my files are production-length, but I didn't include that many of them. I didn't even get the chance to make it do something clever yet. I was determined to make this work, only context-limit is getting in the way.

The solution isn't to just use an LLM with larger context limit. There's always an upper limit, you'd just end up hitting that constantly.

Built my own RAG

I heard RAG is the answer. So I built a middleware that sits between Mentat and the LLM.

This is an OpenAI-compatible REST API (http://localhost:<port>/chat/completions) running locally, all housed in one Python file. I call it Broken Sword for easy reference.

As far as Mentat is concerned, Broken Sword is an actual LLM service. Within Broken Sword I capture Mentat's requests, massage the inputs, send to any LLM I want, and return the response in an OpenAI-compatible way. When doing this, I get to see the elaborate directives given by Mentat, that is what prompt-engineering looks like.

Just by doing this I've enabled Mentat to use any LLM available to mankind. I proceeded use Google Gemini 1.5 to power Broken Sword, mostly because it has the right balance of quality and cost.

This alone does not solve context window limit though. This is no more than a glorified pipe.

Rather than sending inputs from Mentat verbatim, the huge amount of context can be stored in a vector database and sent over as embeddings instead. If I understand it right, large chunks for texts get turned into multidimensional matrices of numbers. This is much smaller for LLMs to use rather than original texts.

I made all that work using LangChain (it has the series of processes abstracted away), with a dash for Flask for simple API. It felt like cheating when I don't yet know how this magic works, but I wanted to hack things fast. I know they say you don't really need LangChain and I believe them, but some day man, some day.

It works

When I'm done, Mentat ended up working like it's supposed to. I made it write unit tests, it got written in the style that's consistent with existing ones. I made it write a GitHub Actions workflow, the result was sensible.

It was gratifying, when it works. Knowing I've made it work with Broken Sword is doubly satisfying.

Which got me wondering, why does Mentat not use RAG or vector database like I just did? It felt almost trivial to do so. I took a browse in Mentat codebase, indeed Chroma DB is used (the same vector db I use). So maybe they are doing RAG somehow but not in ways that matter to me.

But it's clunky

As I put Mentat to work more and more, the clunkiness becomes apparent. It would crash from time to time. Sometimes because the LLM didn't come back with something it likes, but most of the time for reason unknown to me. Graceful failure isn't its strength.

There would be times when Mentat would crash after I made a request. Upon relaunching and re-including the relevant files, I repeated the same request (good thing they have chat history to make this easy) and everything works out.

Mixture of hand-coding

One question I was hoping to answer in this adventure is the right mixture of using coding assistant this way and directly editing files when solving one problem. In that if possible, should all coding be done from just the coding assistant? Or are we expected to have a code editor ready in the next screen?

In my case half of my screen is for Mentat, the other half for emacs. I expected Mentat to grant me most what I want but not perfect, and I would make minor adjustments by hand to the same files in emacs.

If Mentat-style coding assistant has a future, I wonder if that's the way it should be.

The Future of Programming: Classical vs. Assisted Coding with Mentat and Aider

Y.K. Goon — Wed, 19 Jun 2024 02:29:27 +0000

I was trying to catch a glimpse of the future of programming alongside LLMs. I think I ended up discovering a whole new art.

When you bring up AI and coding assistants, most people think of GitHub Copilot and similar alternatives. By now I can confidently say this: code completion is not the future. At best, it's just cute.

The discussion around this among seasoned coders is complicated. It's not that we're unwilling to use Copilot. But when we know our turf well, having a code-completion as assistant gets in the way half of the time. So much of it requires learning a different workflow to complement our existing one. By the time I've explained enough to the machine, I could've coded the solution myself. It's unclear if adopting a different workflow is worthwhile.

On the other hand, there's a sense that a lot of the reluctance comes from the ignorance of what these tools can achieve. Similar to learning vim-keybindings. I hesitated for many years. But once I've suffered through the learning curve, I swear by it.

So I put in some time to explore something entirely different. Instead of code-completion tools, I looked at coding assistants that live up to its true meaning. I narrowed the field down to two: Mentat and Aider.

Mentat

I tried Mentat first, a seemingly smaller project of the two. The demo looks promising, you should take a look first.

It's a terminal-based application. Installation via pip is easy. It's made with Textual TUI so that's a nice touch.

The UX had me at hello. It doesn't try to code with me in Emacs. Instead, I tell it what I want and it will try to deliver in the right places across the project.

To get it to work, I hooked up Mentat to use a coding LLM by Phind hosted by Together AI.

Next I have to pick a problem domain. This is my first mistake: I tried using it to solve a bug in my day job. It's made to work on a code base that is 9 year-old by now.

That broke any available context window limit from the get-go.

See, when working with Mentat we get to specify the relevant files to work on. Code changes by the machine would happen on those files. These files get submitted to the LLM as context (possibly on top of git logs too).

A single Python test file of mine run up to 3,000 lines, easy. No LLM would want to entertain that.

This obstacle got me thinking about fine-tuning a model with my entire code base; or some solution involving RAGs. This can get quite involved; it feels premature. But before I get there, I might as well try Aider first. I shall circle back to Mentat in the future.

Aider

Watch the demo first.

The UX and concepts involved here are similar to Mentat. The difference though is Aider supports Google's Gemini, which has the largest context window out there. If it can't handle my code base, nobody can.

And indeed it could not. I did the setup (similarly with pip), worked on the same files from my large code base and Gemini refused to return anything at all.

By now I think I'm making it do things it's not designed to. Most demos like this start idealistically, without the burden of a 9-year-old code base. So I pulled something out of my idea bank (things I wanted to code but never got to it) and made Aider code it from scratch. Now Aider worked as advertised.

This project is a web browser extension that's meant render web pages from within a 3D scene, made to be used within a VR device. The details of this application are immaterial. What matters is it make use of Three.js and various pieces of Javascript stack, something I'm not invested in and therefore out of my depth.

From the get-go Aider created the entire set of boilerplate files, enough for it to work as an empty browser extension. I subsequently spent the whole day working with Aider to get the project to a point where it successfully integrated Three.js.

Now I can start reflecting on the experience.

How it's really like

Without Aider, a substantial amount of my time would've been spent shaving yak. That include setting manifest files by hand, configuring, doing it wrong and Googling back and forth. All these are low value work, make sense to be done by machines. I wouldn't have taken the project this far in one day coding it myself.

Real action takes place after the first hour. I made a point of telling it what I want like I would to a junior coder, sparing it from making assumptions. That worked out well.

When it gets things wrong, it needs help correcting its own mistakes. Chances are it's because I was not specific about what I was asking for.

When Aider did something unknowingly wrong, I didn't know enough to correct it and assumed it's correct. Further work is built on top of that mistake and cascade into larger mistakes.

There are two facets to mistakes. When Aider makes mistakes on its own, it needs human's help in pointing them out. Doing so involves being specific about the solution. Just saying the outcome is wrong is not helpful.

Secondly, the reason I was not specific enough about my request was because I didn't know enough about the intended solution to ask for it. Therefore Aider does not free you from knowing your stack and technical intricacies.

About testing. This is highly domain specific. Had I been doing backend work, I would've had Aider code my test cases for me. However mine is a VR project, so it's still down to me to test by clicking on browser. I think it most projects, Aider will end up encouraging a test-driven approach by making test cases easy to create.

With coding assistants, it's not the case where you ask for the result and it will deliver the solution. For any non-trivial problem, you would have to iterate with it to come to the right solution. So before machines can reason on their own, human is the reasoning component in this loop.

Like most new skills, learning to get good at working with coding assistants will make you slower before it makes you faster.

Which leads me to declare this: AI-assisted coding is an entirely different art. It's not better than classical coding (I have to coin that here); it's not worse either. It's different like Judo and Muay Thai; comparison is unfair without context.

Classical vs Assisted

Now that I've established two different approaches to coding, I can now engage in some speculation.

Here's an easy one: assisted coding works well on popular programming languages (simply because LLMs are well-trained on them). Projects in artisanal languages (let me introduce you to Hoon) have no choice but to be handcrafted the classical way.

Classical coders are about how; assisted-coders are about what. Consequently, assisted projects achieve objective faster but classical projects maintain better.

Should any given software project in the future be done with a mixture of assisted approach and classical? I suspect no. In that if a code base is assisted code to begin with, there should be minimal classical intervention.

Conversely a classical code base should not be tainted by assisted code commits. Even if this has no quality implication, I think it will be socially demanded by team members.

I can't qualify this point beyond falling back to my intuition, but this aspect will be interesting to observe.

I wonder how collaboration works differently for an assistedly-coded project. Would problems in a typical FOSS project still exist? If not, is the same pull request workflow of a classical project still relevant?

The final point is how physical limits of LLMs affect engineering approaches. Let's assume there will always be a limit to context windows in LLMs no matter how much fine-tuning and RAGs are pulled.

I think assisted projects are likely to discourage monoliths. Because LLMs couldn't fit a big monolith its figurative head, humans go around it by breaking it into pieces. The result end up looking like microservices, whether the problem domain demands for it or not.

Some may argue that's universally a good thing. That remains to be seen.

Going forward

This will be an ongoing research. I'm hopeful to see my toy project to the end.

I may try Mentat again on a new project at some point.

Dirty code

Y.K. Goon — Tue, 06 Feb 2024 10:09:44 +0000

This is one of those posts that should've been a tweet. That is if I'm successful in distilling the essence.

Technical debt has a special place in the hearts of software engineers. The privileged ones get to build a business on it, surviving long enough to accrue a lot of them and not fall apart.

Big Tech tend not to talk about it, preferring to act as if they have none. The real deal talk about it with very slight hint of pride, like daredevils performing death-defying feats.

There's a special breed of technical debt I want to highlight. For lack of a better term, I shall call them dirty code.

The juxtaposition to Uncle Bob's clean code is interesting. Clean code is made out of a well-defined set of qualities. The lack of these attributes however does not make a code dirty; they are simply not-clean.

Dirty code belongs in the realm of chaos. It is not compelled to confine itself to any arbitrary definition. However, they are exceedingly easy to spot.

Think of dirty code as low-class technical debt. Wrong placement of files; camel case instead of snake case; bad styling; poor indentation, etc.

What makes code dirty is their overtness. Other kinds of technical debt/coding malpractice are about unintended consequences from illegible design choices.

Not dirty code. They stare at your face; the only condition for you to not spot it is incompetence.

They are low hanging fruits kind of coding malpractice. They are easy to fix, but not easy enough to be automated. Linters sometimes exists to enforce this but not every ecosystem has them; and for those who do I'm sure someone would find it too constraining.

Mostly they don't get fixed early because they appear harmless, and we're too cool to bother with it.

When would dirty code becomes a debt so intense that you reach the development equivalent of Minsky moment? How much is too much?

Here's a suggestion: when it leaks into culture.

Given the condition that new members join the team, not all of them are confident or assertive enough to challenge the old ways. When they have to write something new on top of dirty code (broken windows), they have two choices: subvert it, or conform to it and leave it alone.

The safe and probable choice is to stay consistent. Monkey see monkey do. Now one dirty code leads to two. The cycle repeats, two dirty code leads to four.

Dirty code has now become ingrained in the culture.

Even more significant design trade-offs don't have this kind of broken windows effect.

Feature flags piloting & how to ruin it

Y.K. Goon — Tue, 04 Jan 2022 06:15:51 +0000

There is a semi-sophisticated thing we do in managing SaaS in production environment that's not given an proper name yet. For the lack of better word I'll resort to calling it feature flag piloting. I reserve the right rename it in the future.

It's a great solution to a very specific set of problems. I'm here to explore what happens when you take it too far.

What is feature flag piloting

Say you have a spanking new feature, it's going to impact everyone when deployed. This is potentially risky and dangerously irreversible.

What you can do instead is to have the feature turned on selectively. This is done by implementing feature flags within your code logic. When the flag is on, the new feature executes. Feature flag can be global or user-specific; a global one affects everyone and is not selective.

Advantages

With this mechanism you can adopt a handful of beta users to test out this feature. If mistakes happen, damage is contained and fixes can take place before a wider roll out. Existing non-beta users are happily cruising in your SaaS without feeling any impact.

This is effectively changing the aircraft engine in mid air. Whatever you can do to cut down your risk, you should do it and feature-flagging is a great way forward.

Doing this is more than safety too. It allows feature-development to be agile, giving you the room develop quickly, release for beta-testing, get feedback, make corrections and repeat the loop in a rapid manner without the downside of receiving widespread complaints.

But what if you take it too far?

In what ways can this be taken too far? Here's a few:

Beta-testing keeps running and never finishes
Features flags are never removed
Too many feature flags are running concurrently
Inter-dependent feature flags (god no don't do that!)

While you're reaping the benefits of this approach, debt accrue. Over time the price comes in these forms:

Involving many humans in operations

Sometimes feature flags are self-managed, a simple checkbox for user to turn on. Sometimes that's too dangerous to even expose. As such turning on feature flags for pilot users involves getting in touch with support staff, backend engineers, maybe even product managers.

In the chain of operations multiple emails get passed, unnecessary human mistakes get to be made. Multiply that by the amount of beta users across time, this cost of manhour adds up.

Software is about taking out humans from the loop in the first place. This is a complete failure in that regard.

The UI is no longer the source of truth

Very often feature-flags are used for presenting different user interfaces to beta users.

Beta user sees something different from other users. Over time there are two sets of realities (or more) for different sets of people. They may all be looking at the user-profile page (for instance) but are experiencing something entirely different.

Now you can no longer count on the UI alone to tell us what is supposed to happen. There needs to be another parameter (the feature flag) to tell us the expected behavior. This becomes a problem that needs additional product-management manpower to managed.

Imagine a sole pilot user who is the only one getting this new feature. He's been left alone using this, six months later he contacts support for help. Support looks at his screenshot and got shocked, the user-profile (example) page is nothing like what he has seen before.

Difficult to debug

Effectively you have expanded the products surface area. Double the area, double the potential for bugs.

When old version and new versions (via feature flag) are running at the same time, you have doubled the maintenance cost while serving the same amount of users.

The default bug report is no longer enough to tell you if this new feature is generating the problem.

Cost spent are wasted

When a new features is only as impactful as its exposure. By limiting it to only beta users, you may never make back the cost of development.

Secret internal knowledge

This whole approach is like ordering off-menu in a high class restaurant. It's cool for the few people involved, but it benefits only them.

Most internal staff don't know about features that are long hidden in beta phase. When some users request for it, some staff won't know to ask to turn it on.

How to manage it better

Here's a few suggestions on what can you do if you have to have feature flags:

Limited beta time window

Don't let it run forever. Set a time limit, maybe three months, maybe two weeks.

When the time is up, evaluate, release it widely and deprecate accordingly.

Set conditions to exit pilot phase

Perhaps a fixed time window isn't good enough. Define your own condition on what constitute satisfactory conditions before you feels safe releasing the feature to everyone.

Maybe it's a collection of pilot users of diverse profiles. Define their characteristics, let them beta-test for a set amount of time (just not forever) then evaluate.

Maybe you want to define it statistically. Above 85% success rate where no bugs are reported within a period of a week, then exit the pilot phase.

Wider release but partial

To further hedge the bet, you may opt to exit pilot phase by releasing only to half the population of users (who didn't opt in as beta users).

The engineering cost of this is highly subjective, just know that it's an option.

But same point, eventually this has to end and complete release ought to happen.

Conclusion

There may be better ways to manage a pilot phase while being in the middle of it, that's outside the scope of my concern here. In the long run it's better to not stay in it than having two versions of the same product running at the same time (A/B test doesn't count).

As far as management tactic goes, it's a simple matter of setting an alarm to go off at a certain date telling you to re-evaluate a specific feature.

Any good thing can be taken too far. It doesn't invalidate the approach, just be mindful of the limits.

Flirting with Nyxt browser

Y.K. Goon — Fri, 24 Sep 2021 03:26:16 +0000

The browser is an OS

The web browser is the most important operating system inside your operating system. If it's not the most important software you use, it's probably a close second.

When a tool is that important, you better served having a deep level of control over it. It should behave exactly the way you want it, and the way you tell to behave should come in the form of code that's shareable.

That's what Nyxt is about. I've been fascinated by it since last year.

It's been progressing well, version 2 right now is a vast improvement over version 1.

To understand what Nyxt is trying to do, you have to first understand what emacs really is.

To understand what emacs really is you have to use it. And not just open it and take a look (there's nothing to look at), you have to dive in and use it. Give it four months and you may get the idea. Hearing people describe emacs is like reading the descriptions of a feeling. You really only get it when you feel it yourself.

Few people will get it but those who do will be die-hard about it.

Trying it as a secondary browser

Switching browsers are typically a low cost move. Bring over bookmarks, install a handful of extensions and you're mostly done.

But Nyxt isn't like that and I know it. So I considered adopting it as a secondary browser. But I'm not sure what secondary even mean. At best I arrive at doing non-mission critical thing on Nyxt, like Twitter.

So I did that.

Nyxt so is not ready for prime time. It may get there eventually but probably by version 4 or so.

It sells itself as keyboard driven, but even on that aspect is clunkier than Firefox with Vim Vixen installed.

The built in dark mode is serviceable but nothing like Dark Reader can do.

Support for Chrome extensions are work in progress apparently.

And it doesn't even come with reader-mode yet. Now that's a deal breaker.

I know with enough custom code I can take care of all the above but the cost would be prohibitively high.

If it ain't broken

I can't yet build a strong case on why I invested time on Nyxt other than wanting to play with new toys. Firefox is working very well, for now it's in no danger of being dethroned.

I don't mind that Nyxt falls short for now, the project has gotten enough traction that it will likely go on.

But I care about my tools. I want them to be powerful, and the less of them the better.

There's nothing out there like emacs, but Nyxt comes very close. It has the right intention, something completely unique in the browser space.

Wabi Sabi Limit

Y.K. Goon — Wed, 15 Sep 2021 07:19:31 +0000

Wabi sabi carries the sprit of embracing inherint brokenness.

The wabi sabi limit is the point where cost of maintenance exceed the risk of re-building your software from ground up. A point where technical debt has gotten so high, bankcruptcy is the only choice.

This is an exploration of the nature of wabi sabi limit.

The law of program evolution dictates that we're gonna run into wabi sabi limit if our software survive long enough.

For most teams, re-writing a production software from scratching is to be avoided. The reasons are best summarized by "remember Netscape 5", and better elaborated by many other people before.

But re-writes are not avoided at all cost. They do happen, decisions to do so do get reached by reasonably smart people, presumably some of them with really good reasons, even taking into account of what we know today. Clearly some of them think the cost and risk is worth paying for.

What are the costs? Too many to count, but one interesting pre-requisite for engaging in a re-write is 100% automated test coverage.

No it's not true, that would be ridiculous. That would rule of 99% of software in production.

Which sounds right. I'm willing to bet the true pre-requisite is probably close to 100% coverage.

Facebook Messenger proudly re-wrote their iOS app with acceptable results (I assume, I'm not a user). I also wanna guess they have the luxury of freezing features for the new build to catch up. Most software that matters can't afford feature-freeze. It'll be interesting to see how FB came to make this bet.

How did FB know they've hit the wabi sabi limit? How conscious were they about this limit? How much of the decision was quantified? Of the quantification, how much of them are full of shit?

How are we supposed to find our wabi sabi limit? It's tempting question, but I highly suspect it's the wrong thing to ask.

It's tempting for the fact that we wanna imagine a two-dimensional graph where cost of maintenance squares off against risks of re-writes. Soon as we get hold of a model, we can point at it to the suits, and they'll have to take it as data.

Nope, I'm more interested in the truth. But you go ahead anyway, the suits will love it.

Cost of maintenance can be calculated if we squint hard enough, but I can't take a model seriously if risks are quantified.

There's amount of value-at-risk equations you can throw at it to get close to modelling reality. Every risk variable we have would be made out of layers of assumptions, it's assumption-turtles all the way down.

If we can't quantify the wabi sabi limit, sounds like it isn't much good helping us make decisions. But maybe that's not the point.

The wabi sabi limit has more power being an mythical figure, The point is for it to be creature behind the curtain, a cautionary tale.

It's not meant to be figured out, but to actively avoid running into. Because by the time you do, it's too late.

One approach is to treat wabi sabi limit as an inevitability. If we see impermenance in everything, all pieces are susceptible to be thrown away and replaced.

Then it helps to decouple, micro service, isolate code rot, minimize surface area of re-writes. Basically everything they've been telling you is a good idea.

The wabi sabi limit is not static. Even if you hold the re-write risk constant, the cost of maintenance stands a chance of going down given the will.

Wabi sabi limit is not solely an engineering concern. The suits arguably care more about the risk equation. In fact engineers enjoy re-writes regardless of the business consequences.

Acknowledging this limit allows both camps to point to a bogeyman. Not in such a way that measuring it ends up invalidating a gamed metric, but allows the team to develop a negative capability in dodging the risky bullets of re-writes.