HanLHo. - Fractional Architect & Software Product Engineer - software-engineering

Harness Engineering

2026-02-27T00:00:00+00:00

Today I heard the term “harness engineering” for the first time:

Harness engineering is the practice of building tooling, tests, and automation that let coding agents execute tasks safely and reliably. </blockquote>
If code is written more and more by LLMs, the focus seems to be shifting to creating guardrails so agents can validate their own work.
Heard in: The Pragmatic Engineer - Mitchell Hashimoto’s new way of writing code</a>

AI’s Opportunity: Pacing Control Loops with Development

2026-02-04T00:00:00+00:00

What caught my attention in the book Vibe Coding by Gene Kim and Steve Yegge is the idea that, as LLMs and coding agents change how we build software, control loops—tests, reviews, and other signals that tell you whether a change behaves as expected—should be faster and more integrated into development feedback loops than before. My intuition says this makes perfect sense.

For example, when there is a dedicated test stage or a QA role that tests after the fact, that role inevitably struggles to keep up with the speed of development. Over time, this makes it increasingly difficult to sustain a 'testing after the fact' organisation of quality.

So how do we solve this?

Some may think that introducing AI by implementing it at the test level after the fact, could be the solution. However, at the rate of development I see and read about, this approach will be hard to keep up with. One either has to accept not fully taking advantage of what AI can help development with, or rethink how testing is integrated into the development process.

Put bluntly: if AI lets you produce a feature in hours but the first meaningful acceptance signal only arrives days later in a separate stage, quality assurance become the bottleneck.

To me, the logical consequence is a stronger shift towards automated quality controls, including acceptance tests and code reviews at the least. I refer to acceptance tests here as writing executable specifications of expected behaviour (in domain language) before or alongside the code. This implies that testing has to move earlier in the development chain because of AI.

AI is an opportunity to start writing acceptance tests if you have not yet. It pushes us to invest time in strategic test design, testing against stable contracts, testing from a behavioural point of view, and isolating test descriptions from the actual implementation.

Put differently, the shift in development practices that LLMs are causing should inspire more adherence to testing best practices, not less. That is, if you want to keep on adding new features, fix and prevent bugs, and keep up the pace of development.

More broadly, to keep benefiting from AI over time, we should shift towards tightly coupled feedback loops embedded in everyday development. This is not limited to testing but also applies to, for example, reviews. In that sense, AI doesn’t remove quality practices; it raises the stakes if you don’t have them.

If testing 'shifts left', team structures must change as well. This evolution points towards smaller, more autonomous teams where testing, development, and feedback are inseparable rather than sequential.

AI presents us with an opportunity: not faster quality control after the fact, but to design systems, processes, and teams that make quality the fastest path forward, so control loops can keep up with the increasing pace of development loops.

On Building Reliable Software with LLMs

2026-01-27T00:00:00+00:00

This post captures my current thinking on how LLMs are impacting software development, particularly around software quality and engineering discipline.
My main observation: most of the best practices we've relied on for years are just as important—maybe even more so—in an LLM-assisted development environment. Working with LLMs requires more discipline and attention to fundamentals, not less.
When using LLMs, there is a heightened risk of losing understanding: of the problem domain, the underlying technology, and the implementation details. Code can become messy quickly without careful attention, review, and guidance. While this is certainly true, we didn't need LLMs for this to happen. Why else have so many projects failed historically? Why is technical debt a topic in most projects?
The critical difference with LLMs is the increased risk and temptation of velocity. We move too fast and skip the practices that help us maintain and change software in the future. Discipline and rigour</a> have become more important than ever.
These practices are becoming MORE crucial in an LLM-assisted workflow:

Codebase quality. This matters for LLM agents too, because they learn from existing code. A clean, well-organised codebase helps agents perform better; inconsistencies lead to poorer results. An LLM will mimic what's already there. </li>

Feedback loops and testing. If an LLM is helping you write code, you need reliable ways to verify it hasn't broken anything. A well-designed, automated test suite that's easy to extend and interpret helps maintain understanding and control of implemented functionality. </li>

Well-designed boundaries and contracts both within and outside your application. These allow you to constrain, shape, isolate, and test the work an LLM produces. </li>

Managing risk and technical debt. Be intentional and explicit about where you rely on LLMs and where you don't. Document these decisions. Maintain a technical debt log with risk assessments and timelines. </li>

Documentation of past decisions. Keep a history of architectural decisions through decision logs and ADRs, and ensure the LLM you're working with is aware of them. I've had LLMs point out inconsistencies in the codebase or flag how new change requests conflict with past decisions. </li> </ul>
Taken together, these practices are what make LLM-assisted development sustainable rather than brittle.
I don't think the skill gap in building and delivering software will ultimately be about prompt cleverness. LLM agents will be genuinely helpful tools, and working effectively with them will be an accelerator. However, as we rely on them more to write code—even when we review that code carefully—the most important work increasingly becomes the disciplined practice of boxing them in with testing, architecture, and contracts.
Avoid painting yourself into a corner. In an LLM-assisted workflow, that means being deliberate about where you let agents move fast, and where you slow them down with guardrails. LLMs make it easier to move fast, and easier to get stuck.

DORA Research: Evidence-Based and Scientifically Grounded Software Engineering

2025-10-09T00:00:00+00:00

Years ago, the book Accelerate</a> changed my view on software development and delivery fundamentally.
Of course, there are its findings (dare I say 'revolutionary'?) on which technical and organisational factors drive high performance software delivery. But that is not what I want to highlight here.
What makes this book so valuable is that it is grounded in scientific research.
The first years of DORA research formed the basis for the book and documented their scientific approach. And every year they keep on publishing their research results. A few weeks ago their latest report came out. This is the best part, as is with science, when the landscape changes, other evidence surfaces and these reports keep on giving valuable insights.
This approach is completely different from other frameworks in the industry that are adopted because of popularity (I have done that) or commercial interests.
Inevitably this year's report is influenced heavily by the impact of AI, so much so that this year they named their report: "The State of AI-assisted Software Development".
Links to the most recent science-based research:

DORA Report 2025 Infographic, if you want to get the high-level overview: https://dora.dev/research/2025/2025-DORA-Report-Infographic.pdf</a> </li>

The full report, +100 pages but if you are into this topic it's an evening's read: https://dora.dev/research/2025/dora-report/</a> </li> </ul>

Slice Work into Smaller, Prioritised Deliverables instead of using Story Points

2024-04-22T00:00:00+00:00

Have you ever wondered if there are better ways to estimate work than using Story Points? Below is a potentially simpler, more effective method to prioritise and estimate your software development tasks that could save your team countless hours of debate and confusion.
This mini-article condenses Story Points: Why is this so hard?</a> which proposes a more reasoned and sensible alternative to using Story Points to estimate software development work. If you find this topic interesting I recommend reading the full article.
Key points:

Slice work in manageable, preferably smaller deliverables. </li>

Put deliverables in a list with the most crucial ones at the top. Work from the top. In essence we choose to work with flexible scope. </li>

Stop using Story Points, they are not reliable for scheduling work. (1) </li>

Working software is the measure of progress. So try to start with end-to-end working software. </li> </ul>
Benefits of slicing in smaller feature/behaviour/task slices:

More accurate to estimate. (2) </li>

More time discussing actual work. </li>

More steady delivery. </li> </ul>
Of course there is not such thing as free lunch: you need to spend time preparing the stories and accept that sizing the stories will not and does not need to be an exact science. Try not get carried away making the slicing the main activity either.
Thank you for reading, Hans
(1) Story Points were introduced to avoid overworking teams, not estimation. One could statistically derive actual estimates from story points but personally I have never seen it done fundamentally. See Story Points: Why is this so hard?</a> for more details.
(2): In general it does make sense to me since smaller stories tend to have lower variability. Again, Story Points: Why is this so hard?</a> goes into more detail.

FizzBuzz fun: Exploring Functional Programming Design Patterns : Monoids

2023-12-04T00:00:00+00:00

In this post, we will continue from where we left off in a previous article in this series, "FizzBuzz Fun in Scala: Combining Functions," and explore where further abstraction leads us in terms of functional programming design patterns. Our goal is to show that, despite their intimidating name, Monoids are a logical, reusable design pattern that emerges when reducing list-like structures to a single value—a task quite common in everyday development. As for Scala 3, we will also utilize contextual abstractions instead of Scala 2 implicits, to combine more complex structures from smaller ones.
Combining values using a single abstraction</h2>
Below is the code we will start with. If you would like to understand this code better please see the FizzBuzz fun in Scala: Combining functions</a> post.
// Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 def combine[A]( f1: A => Option[String], f2: A => Option[String] ): A => Option[String] = a => (f1(a), f2(a)) match case (Some(s1), Some(s2)) => Some(s1 + s2) case (None, Some(s2)) => Some(s2) case (Some(s1), None) => Some(s1) case (None, None) => None val fizzbuzzAt: Int => String = extension (word: String) def every(n: Int): Int => Option[String] = i => if i % n == 0 then Some(word) else None val wordShouts = List( "Fizz".every(3), "Buzz".every(5) ) val combined = wordShouts.fold(_ => None)(combine) val fizzbuzz: Int => String = i => combined(i).getOrElse(i.toString) fizzbuzz end fizzbuzzAt def fizzbuzz(n: Int): List[String] = LazyList .from(1) .map(fizzbuzzAt) .take(n) .toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(20).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre>

💡</div>
Code can be run using Scala CLI</a>. Save a copy of a complete example in e.g. FizzBuzz.scala</code> and run it like: scala-cli run FizzBuzz.scala</code>. In this article, a complete runnable example can be recognised by a //> using scala 3.3.1</code> directive near the top of the file.</div> </div> We will begin by zooming in on how we 'combined' multiple functions with the type signature Int => Option[String]</code> into a single one:
def combine[A]( f1: A => Option[String], f2: A => Option[String] ): A => Option[String] = a => (f1(a), f2(a)) match case (Some(s1), Some(s2)) => Some(s1 + s2) case (None, Some(s2)) => Some(s2) case (Some(s1), None) => Some(s1) case (None, None) => None </code></pre> which is used as:
val combined = wordShouts.fold(_ => None)(combine) </code></pre> In the `fold</code>` we seem to have two related functions so let's define them together:
trait Combiner[B]: def zero: B def combine(b1: B, b2: B): B </code></pre> The zero</code> function enables us to define an element that 'does not count' when combining elements. The combine</code> function allows us to merge elements of the same type into another element of the same type. For example, consider integers: we could combine them using addition, in which case the zero element would be 0; alternatively, we could combine them using multiplication, in which case the zero element would be 1. Looking at the type signature of combine</code>:
def combine[A]( f1: A => Option[String], f2: A => Option[String] ): A => Option[String] </code></pre> We can see that B</code> in Combiner[B]</code> in this case would be of type A => Option[String]</code>, so the instance for our type of Combiner</code> would look like this:
new Combiner[A => Option[String]]: override def zero: A => Option[String] = ??? override def combine( a1: A => Option[String], a2: A => Option[String] ): A => Option[String] = ??? end Combiner </code></pre> Declaring the instance in an object (later we will group more Combiner</code> instances together) we get:
object Combiner: def myCombiner[A] = new Combiner[A => Option[String]]: override def zero: A => Option[String] = ??? override def combine( a1: A => Option[String], a2: A => Option[String] ): A => Option[String] = ??? end Combiner </code></pre> To implement zero</code> we can have a look at the fold</code> usage above. For the combine</code> method we can have a look at our original combine</code> function:
object Combiner: def myCombiner[A] = new Combiner[A => Option[String]]: override def zero: A => Option[String] = _ => None override def combine( a1: A => Option[String], a2: A => Option[String] ): A => Option[String] = a => (a1(a), a2(a)) match case (Some(s1), Some(s2)) => Some(s1 + s2) case (None, Some(s2)) => Some(s2) case (Some(s1), None) => Some(s1) case (None, None) => None end Combiner </code></pre> This Combiner</code> we can then use to implement our original combine</code> function:
import Combiner.* def combine[A]( f1: A => Option[String], f2: A => Option[String] ): A => Option[String] = myCombiner.combine(f1, f2) </code></pre> At this point, our solution works again and we can remove our combine</code> function entirely. Our `fold</code>` then becomes: val combined = wordShouts.fold(_ => None)(myCombiner.combine) </code></pre> Or: val combined = wordShouts.fold(myCombiner.zero)(myCombiner.combine) </code></pre> Since the Combiner</code> type has all the behaviour required for fold</code> ideally we would write: val combined = wordShouts.fold(myCombiner) </code></pre> Which we can do using an extension method: extension[A] (as: List[A]) def foldWith(c: Combiner[A]): A = as.fold(c.zero)(c.combine) val combined = wordShouts.foldWith(myCombiner) </code></pre> Note: using fold</code> as a name for the extension method sadly does not seem to work so I renamed it to foldWith</code>. I did delve deeper into this on why this is. Combine all the things!</h2> At this point, you might be wondering, "Why go through all this trouble?". The answer lies in the fact that the two functions we defined in Combiner</code> are precisely the arguments we provide to a fold</code>. A fold represents the operation of combining elements within a collection while accounting for cases where the collection has no elements. This is something we do frequently. In functional programming, this type is commonly referred to by its mathematical name: a monoid. If we rename our definition of Combiner</code> to Monoid</code>, then this is precisely how a Monoid is defined: trait Monoid[A]: def zero: A def combine(b1: A, b2: A): A </code></pre> Let's stick with Combiner</code> for now and I'll revisit monoids further down in this post. Let's have a closer look at our current instance of Combiner</code>: def myCombiner[A] = new Combiner[A => Option[String]]: override def zero: A => Option[String] = _ => None override def combine( a1: A => Option[String], a2: A => Option[String] ): A => Option[String] = a => (a1(a), a2(a)) match case (Some(s1), Some(s2)) => Some(s1 + s2) case (None, Some(s2)) => Some(s2) case (Some(s1), None) => Some(s1) case (None, None) => None </code></pre> The code accomplishes several tasks: 1. The pattern matching on the Option</code> type essentially combines Options, which is not directly related to combining functions. 2. The addition of String</code>s, s1 + s2, can also be regarded as 'combining'. 3. The Combiner</code> is generic in its argument, but its return type is specific to Option[String]</code>. Currently, our Combiner</code> instance appears to be combining functions, Options, and Strings simultaneously. Let's attempt to separate each of these into its own Combiner: def stringCombiner = new Combiner[String]: override def zero: String = ??? override def combine(a1: String, a2: String): String = ??? def optionCombiner[A] = new Combiner[Option[A]]: override def zero: Option[A] = ??? override def combine(a1: Option[A], a2: Option[A]): Option[A] = ??? def functionCombiner[A, B] = new Combiner[A => B]: override def zero: A => B = ??? override def combine(f1: A => B, f2: A => B): A => B = ??? </code></pre> Since we started with combining functions, let's start with functionCombiner</code>: def functionCombiner[A, B] = new Combiner[A => B]: override def zero: A => B = a => ??? override def combine(f1: A => B, f2: A => B): A => B = a => val b1 = f1(a) val b2 = f2(a) ??? // combine b1 and b2 </code></pre> We need a way to combine B</code>s, otherwise we cannot possibly continu. Do we have a way of combining Bs? Certainly, if pass one: def functionCombiner[A, B](bc: Combiner[B]) = new Combiner[A => B]: override def zero: A => B = a => bc.zero override def combine(f1: A => B, f2: A => B): A => B = a => val b1 = f1(a) val b2 = f2(a) bc.combine(b1, b2) end combine end functionCombiner </code></pre> In our myCombiner</code> B</code> is an Option[String]</code>: def myCombiner[A] = new Combiner[A => Option[String]]: ... </code></pre> To implement our combiner, we need a way of combining Options. Let's start with Option[String]</code> first: def optionStringCombiner = new Combiner[Option[String]]: override def zero: Option[String] = None override def combine( a1: Option[String], a2: Option[String] ): Option[String] = (a1, a2) match case (Some(s1), Some(s2)) => Some(s1 + s2) case (None, Some(s2)) => Some(s2) case (Some(s1), None) => Some(s1) case (None, None) => None </code></pre> Here, similar to what we did for the functionCombiner</code>, we can generalize by passing a Combiner</code> for a generic parameter: def optionCombiner[A](ac: Combiner[A]) = new Combiner[Option[A]]: override def zero: Option[A] = None override def combine( maybeA1: Option[A], maybeA2: Option[A] ): Option[A] = (maybeA1, maybeA2) match case (Some(a1), Some(a2)) => Some(ac.combine(a1, a2)) case (None, Some(a2)) => Some(a2) case (Some(a1), None) => Some(a1) case (None, None) => None </code></pre> The final piece of the puzzle involves combining strings. The stringCombiner</code> is easy compared to the other combiners we have already implemented: def stringCombiner = new Combiner[String]: override def zero: String = "" override def combine(a1: String, a2: String): String = a1 + a2 </code></pre> If we now define the optionsStringCombiner</code> in terms of the optionCombiner</code> and stringCombiner</code> we get: def optionStringCombiner = optionCombiner(stringCombiner) </code></pre> Our original myCombiner</code>, of type Combiner[A => Option[String]]</code> becomes: def myCombiner[A] = functionCombiner[A, Option[String]]( optionCombiner( stringCombiner ) ) </code></pre> To recap what we have done: We defined a trait called Combiner</code> to combine elements. </li> We created an instance of this class that enables us to combine 'word shouts'. We modelled shouting words as functions: Int => Option[String]</code>, meaning that given a number, we may or may not shout a word. </li> We defined this instance using three more atomic instances: one that knows how to combine Strings, one that knows how to combine Options, and one that knows how to combine functions. </li> We also defined an extension method for the List</code> class that takes this Combiner</code> instance and performs the actual combining. </li> </ul> All together: // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 trait Combiner[A]: def zero: A def combine(a1: A, a2: A): A object Combiner: def myCombiner[A] = functionCombiner[A, Option[String]]( optionCombiner( stringCombiner ) ) def stringCombiner = new Combiner[String]: override def zero: String = "" override def combine(a1: String, a2: String): String = a1 + a2 def optionCombiner[A](ac: Combiner[A]) = new Combiner[Option[A]]: override def zero: Option[A] = None override def combine( maybeA1: Option[A], maybeA2: Option[A] ): Option[A] = (maybeA1, maybeA2) match case (Some(a1), Some(a2)) => Some(ac.combine(a1, a2)) case (None, Some(a2)) => Some(a2) case (Some(a1), None) => Some(a1) case (None, None) => None def functionCombiner[A, B](bc: Combiner[B]) = new Combiner[A => B]: override def zero: A => B = a => bc.zero override def combine(f1: A => B, f2: A => B): A => B = a => val b1 = f1(a) val b2 = f2(a) bc.combine(b1, b2) end combine end functionCombiner end Combiner import Combiner.* val fizzbuzzAt: Int => String = extension (word: String) def every(n: Int): Int => Option[String] = i => if i % n == 0 then Some(word) else None extension [A](as: List[A]) def foldWith(c: Combiner[A]): A = as.fold(c.zero)(c.combine) val wordShouts = List( "Fizz".every(3), "Buzz".every(5) ) val combined = wordShouts.foldWith(myCombiner) val fizzbuzz: Int => String = i => combined(i).getOrElse(i.toString) fizzbuzz end fizzbuzzAt def fizzbuzz(n: Int): List[String] = LazyList .from(1) .map(fizzbuzzAt) .take(n) .toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(20).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> Contextual abstraction using given instances and using clauses</h2> Scala 2's implicits enabled removing all the explicit wiring of our Combiner</code>s. In Scala 3 this is now done using given</code> instances and using</code> clauses. All our Combiner instances can be declared with the given</code> keyword, and wherever we need an instance of Combiner</code> to be available we use the using</code> keyword. Here is the complete implementation; afterwards, I will highlight the most important parts. // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 trait Combiner[A]: def zero: A def combine(a1: A, a2: A): A object Combiner: given stringCombiner: Combiner[String] with override def zero: String = "" override def combine(a1: String, a2: String): String = a1 + a2 given optionCombiner[A](using ac: Combiner[A]): Combiner[Option[A]] with override def zero: Option[A] = None override def combine( maybeA1: Option[A], maybeA2: Option[A] ): Option[A] = (maybeA1, maybeA2) match case (Some(a1), Some(a2)) => Some(ac.combine(a1, a2)) case (None, Some(a2)) => Some(a2) case (Some(a1), None) => Some(a1) case (None, None) => None given functionCombiner[A, B] (using cb: Combiner[B] ): Combiner[A => B] with override def zero: A => B = a => cb.zero override def combine(f1: A => B, f2: A => B): A => B = a => val b1 = f1(a) val b2 = f2(a) cb.combine(b1, b2) end combine end functionCombiner end Combiner import Combiner.given val fizzbuzzAt: Int => String = extension (word: String) def every(n: Int): Int => Option[String] = i => if i % n == 0 then Some(word) else None extension [A](as: List[A]) def foldWith(using c: Combiner[A]): A = as.fold(c.zero)(c.combine) val wordShouts = List( "Fizz".every(3), "Buzz".every(5) ) val combined = wordShouts.foldWith val fizzbuzz: Int => String = i => combined(i).getOrElse(i.toString) fizzbuzz end fizzbuzzAt def fizzbuzz(n: Int): List[String] = LazyList .from(1) .map(fizzbuzzAt) .take(n) .toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(20).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> Highlights: The Combiner</code> object contains all given instances of Combiner</code> :</li> </ul> object Combiner: given stringCombiner: Combiner[String] with ... given optionCombiner[A](using ac: Combiner[A]): Combiner[Option[A]] with ... given functionCombiner[A, B] (using cb: Combiner[B]): Combiner[A => B] with ... end Combiner </code></pre> given instances must be explicitly imported ('import Combiner.*</code>' does not import them!):</li> </ul> import Combiner.given </code></pre> All elements can be folded into a single element, if a Combiner</code> instance for A is given:</li> </ul> extension [A](as: List[A]) def foldWith(using c: Combiner[A]): A = as.fold(c.zero)(c.combine) </code></pre> This fold needs a Combiner</code> for Int => Option[String]</code>: functionCombiner</code>'s type matches but needs a Combiner</code> for Option[String]</code> </li> optionCombiner</code>'s type matches but needs a Combiner</code> for String</code> </li> stringCombiner</code>'s type matches and does not need anything more </li> </ul> </li> </ul> As such a 'complete' function combiner instance is given and will be used to fold all shouts into a single function: val combined = wordShouts.foldWith </code></pre> Reuse with cats</h2> in Scala 3 type classes are traits with one or more parameters whose implementations are provided as given</code>instances. So Combiner</code> is now a type class. As I mentioned earlier, the Combiner</code> type class is known in category theory as a Monoid</code> (which does come with some 'laws' which allow these structures to be well suited for parallelization but this is out of the scope of this article and for details I'll refer to the references at the end): trait Monoid[A]: def zero: A def combine(b1: A, b2: A): A </code></pre> The cats library</a> also defines this type class. Let's now try to reuse the Monoid</code> type class from cats. Note the changes below: The cats lib dependency is declared and can be used: //> using lib org.typelevel::cats-core:2.10.0</code> </li> The cats Monoid</code> type class is now used instead of Combiner</code> </li> The zero</code> function is renamed to empty</code> to match cats' names. </li> The Combiner</code> object is renamed to CombinerInstances</code> </li> The foldWith</code> extension method is replaced with the Monoid.combineAll</code> method on (a superclass of) List</code> so. This method looks for a monoid that can combine the elements in the list of type List[Int => Option[String]]</code>. This line is where most of the 'action' happens. </li> </ul> // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 //> using lib org.typelevel::cats-core:2.10.0 import cats.Monoid object CombinerInstances: given stringCombiner: Monoid[String] with override def empty: String = "" override def combine(a1: String, a2: String): String = a1 + a2 given optionCombiner[A](using ac: Monoid[A]): Monoid[Option[A]] with override def empty: Option[A] = None override def combine( maybeA1: Option[A], maybeA2: Option[A] ): Option[A] = (maybeA1, maybeA2) match case (Some(a1), Some(a2)) => Some(ac.combine(a1, a2)) case (None, Some(a2)) => Some(a2) case (Some(a1), None) => Some(a1) case (None, None) => None given functionCombiner[A, B] (using cb: Monoid[B] ): Monoid[A => B] with override def empty: A => B = _ => cb.empty override def combine(f1: A => B, f2: A => B): A => B = a => val b1 = f1(a) val b2 = f2(a) cb.combine(b1, b2) end combine end functionCombiner end CombinerInstances import CombinerInstances.given val fizzbuzzAt: Int => String = extension (word: String) def every(n: Int): Int => Option[String] = i => if i % n == 0 then Some(word) else None val wordShouts = List( "Fizz".every(3), "Buzz".every(5) ) val combined = Monoid.combineAll(wordShouts) val fizzbuzz: Int => String = i => combined(i).getOrElse(i.toString) fizzbuzz end fizzbuzzAt def fizzbuzz(n: Int): List[String] = LazyList .from(1) .map(fizzbuzzAt) .take(n) .toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(20).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> It turns out that the instances we defined ourselves are quite common, and cats also provides these monoid instances. For example, the monoid instance we defined for String</code> can be imported using: import cats.instances.string.given </code></pre> Once this is done we do not need our instance in MonoidInstances</code> anymore. The same can be done for the Option and function instances. So in the end we can delete all of our custom instances including the CombinerInstances</code> object because it has become empty: // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 //> using lib org.typelevel::cats-core:2.10.0 import cats.Monoid import cats.instances.string.given import cats.instances.option.given import cats.instances.function.given val fizzbuzzAt: Int => String = extension (word: String) def every(n: Int): Int => Option[String] = i => if i % n == 0 then Some(word) else None val wordShouts = List( "Fizz".every(3), "Buzz".every(5) ) val combined = Monoid.combineAll(wordShouts) val fizzbuzz: Int => String = i => combined(i).getOrElse(i.toString) fizzbuzz end fizzbuzzAt def fizzbuzz(n: Int): List[String] = LazyList .from(1) .map(fizzbuzzAt) .take(n) .toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(20).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> This is the final version of Fizzbuzz in this article. As a side bar, note how we ended with 10 lines less than what we started with when rolling our own monoids manually. Conclusion</h2> In conclusion, this article demonstrates how monoids emerge as a reusable design pattern when reducing list-like structures to a single value. By building upon the FizzBuzz example, we explored the process of defining and assembling reusable monoid instances, and eventually transitioned to using the Cats library for simplification and reuse. Finally, here are some references if you would like to delve deeper into Monoids or functional programming in Scala: The Scala red book</a> (note there is also a second edition for Scala 3</a>) </li> FP Tower</a> has a very elegant and natural way of introducing Monoids in its course materials. As far as courses go this is one of the most engaging courses I ever took online. (Not free. Scala 2 at the time of writing.) </li> Monoid documentation of the cats library</a> </li> Another explanation of what a Monoid is using FizzBuzz on reddit</a> </li> </ul>