Lasantha Kularatne

Future of Software Engineering — Thoughtworks

2026-02-18T00:00:00Z

Future of Software Engineering — Retreat Key Takeaways

Martin Fowler shared today on his blog page about the Thoughtworks Future of Software Development Retreat held in February 2026. As I read the details, one document captured my attention:

tw_future_of_software_development_retreat_key_takeaways.pdf

I felt like, this is a good state-of-the-union for the current AI driven software development. I thought sharing a summerized view would be benefitial for everyone.

1. Rigor Isn't Gone — It Moved

Engineering discipline hasn't disappeared; it migrated upstream to specs, into test suites, type systems, risk mapping, and continuous comprehension. TDD is now the strongest form of prompt engineering — tests written before code prevent agents from cheating by validating broken behavior. Spec quality is now the highest-leverage artifact.

2. There's a New "Middle Loop" Nobody Has Named Yet

We now operate in three loops — inner (coding), outer (CI/CD), and a newly forming middle loop: directing, evaluating, and correcting AI agent output. The engineers thriving here think in delegation and orchestration, have strong architectural mental models, and can assess output quality without reading every line. Career ladders don't recognize this yet — and that's a problem.

3. Conway's Law Now Applies to Agents Too

Agent topology mirrors team topology. Agents can be cloned across teams instantly, but they drift over time, accumulating different patterns per context. Speed mismatches are real — agents clear backlogs in days but then hit human-speed bottlenecks (architecture reviews, approvals). Decision fatigue is the new delivery constraint.

4. Security Is Dangerously Underdeveloped

This received the lowest session attendance — which is itself the warning sign. Giving an agent email access alone is enough for full account takeover. Platform engineering must enforce secure defaults by design, not rely on developers making safe choices individually. AI-speed attacks demand AI-speed defenses.

5. Self-Healing Systems Are Still Far Off

The vision of agents autonomously resolving incidents is real — but the prerequisites aren't met. Most orgs lack: a full change ledger, agent identity/permission controls, and well-defined fitness functions. The hardest problem is latent knowledge — senior engineers carry decades of pattern-matching in their heads that's almost never documented. Building an "agent subconscious" from years of post-mortems is the path forward.

6. Developer Productivity and Developer Experience Are Decoupling

Organizations can get more output from AI tools even when developers report lower satisfaction and higher cognitive load. This weakens the business case for investing in developer experience — unless we reframe it as "agent experience." (Conveniently, the conditions that help agents perform well largely overlap with those that help humans perform well.)

7. Junior Devs Are More Valuable, Not Less

AI gets juniors past the initial net-negative phase faster. They're better at adopting AI tools than seniors. The real risk is mid-level engineers who may lack the fundamentals to thrive — no one has solved retraining this cohort yet. Staff engineers, meanwhile, are most impactful as friction killers, not just deep technical contributors.

8. PM and Developer Roles Are Converging

Nobody can clearly define what PMs will do in an AI-first world. Some orgs are training PMs in Markdown and developer tooling. Others see roles diverging further. What's clear: AI is exposing pre-existing dysfunctions in the PM-developer relationship, not creating new ones.

9. Knowledge Graphs & Semantic Layers Are Having a Moment

Decades-old technologies are suddenly critical as the grounding layer for domain-aware agents. One example: a large telecom captured its entire domain ontology in ~286 concepts. LLMs can auto-generate event storming artifacts from legacy code, compressing weeks of discovery into days.

10. Agile Is Evolving, Not Dying

Sprint cadences are compressing. XP practices (pair programming, ensemble development) are being rediscovered. The real threat is governance — faster teams just hit the same approval walls sooner. Also flagged as a regression: AI is enabling large batch releases again, reversing a decade of DORA research on deployment stability.

Open Questions Left Unanswered

How do engineers find meaning when code-writing is no longer the job?
Does faster agent output mean we need fewer (or differently-skilled) middle managers?
Can test suites + constraints ever fully replace human code review?
Are we accumulating cognitive debt faster than we realize?
How do we govern systems where agents move faster than humans can decide?

Fun with Shell Emojis

2026-02-06T00:00:00Z

This article is nothing technical. I want to show the fun side of shell development.

Your shell environment doesn't need to be boring. We can decorate the shell's user messages with fun emojis that are random each time. It's a small touch that helps break the monotony of everyday terminal work.

Let me walk you through how to set this up on Linux, macOS, and Windows.

Linux (Debian/Ubuntu)

Shell environment: Bash

Add the following function to your ~/.bashrc:

rand_emoji() {
  local imgs=("😊" "👻" "😽" "😺" "😌" "🙃" "😃" "🎂" "😎" "🤗" "😈" "🤡" "😻" "💩" "🤓" "🥳" "🤩" "🤑" "🙀" "😱" "🙈" "🧙" "🦄" "🧚" "🤖" "🐶" "🥂" "🍭" "🍿" "🎉" "🎊" "🕺" "🏮" "🎏" "🪔" "🔮" "🏆")

  # Bash arrays are 0-based by default.
  # $RANDOM % length returns a number from 0 to length-1.
  local img_id=$(( RANDOM % ${#imgs[@]} ))

  echo "${imgs[$img_id]:-🙂}"
}

How it works

local imgs=(...) — Declares a local array of emoji strings. Using local keeps the variable scoped to the function so it doesn't leak into your shell session.
${#imgs[@]} — Returns the total number of elements in the array.
$RANDOM — A built-in Bash variable that produces a random integer between 0 and 32767 each time it's referenced.
$(( RANDOM % ${#imgs[@]} )) — The modulo (%) operation constrains the random number to a valid array index (0 to length-1), since Bash arrays are zero-based.
${imgs[$img_id]:-🙂} — Looks up the emoji at the random index. The :- syntax is a fallback — if the value is empty or unset for any reason, it defaults to 🙂.

macOS

Shell environment: Zsh

Add the following function to your ~/.zshrc:

rand_emoji() {
  local imgs=("😊" "👻" "😽" "😺" "😌" "🙃" "😃" "🎂" "😎" "🤗" "😈" "🤡" "😻" "💩" "🤓" "🥳" "🤩" "🤑" "🙀" "😱" "🙈" "🧙" "🦄" "🧚" "🤖" "🐶" "🥂" "🍭" "🍿" "🎉" "🎊" "🕺" "🏮" "🎏" "🪔" "🔮" "🏆")

  # Zsh arrays are 1-based.
  # We add +1 so the range becomes 1 to Length (instead of 0 to Length-1)
  local img_id=$(( ($RANDOM % ${#imgs[@]}) + 1 ))

  echo "${imgs[$img_id]:-🙂}"
}

How it works

local imgs=(...) — Same as Bash, declares a local array of emojis.
${#imgs[@]} — Returns the array length, just like in Bash.
$RANDOM — Works the same way as in Bash, producing a random integer.
$(( ($RANDOM % ${#imgs[@]}) + 1 )) — This is where Zsh differs. Zsh arrays are 1-based (the first element is at index 1, not 0). The modulo gives us 0 to length-1, so we add 1 to shift the range to 1 through length — matching Zsh's indexing.
${imgs[$img_id]:-🙂} — Looks up the emoji at the random index. The :- syntax is a fallback — if the value is empty or unset for any reason, it defaults to 🙂.

Windows

Shell environment: PowerShell

Add the following function to your PowerShell profile ($PROFILE):

function rand_emoji {
	$emojis = @('😊', '👻', '😽', '😺', '😌', '🙃', '😃', '🎂', '😎', '🤗', '😈', '🤡', '😻', '💩', '🤓', '🥳', '🤩', '🤑', '🙀', '😱', '🙈', '🧙', '🦄', '🧚', '🤖', '🐶', '🥂', '🍭', '🍿', '🎉', '🎊', '🕺', '🏮', '🎏', '🪔', '🔮', '🏆')
	return $emojis[(Get-Random -Minimum 0 -Maximum $emojis.Count)]
}

How it works

$emojis = @(...) — Creates a PowerShell array of emoji strings. The @() syntax explicitly defines an array. Unlike Bash/Zsh, PowerShell variables declared inside a function are local by default — no local keyword needed.
$emojis.Count — Returns the number of elements in the array. PowerShell arrays are zero-based, like Bash.
Get-Random -Minimum 0 -Maximum $emojis.Count — PowerShell's built-in cmdlet for generating random numbers. The -Minimum is inclusive and -Maximum is exclusive, so this produces a value from 0 to length-1 — exactly what we need for a zero-based index.
$emojis[...] — Standard array indexing to retrieve the emoji at the random position.

Try it out

Once you've added the function to your shell config, reload it (or open a new terminal) and run:

echo "Hi $(rand_emoji)"

Each time you run it, you'll get a different greeting — Hi 🦄, Hi 💩, Hi 🙃, and so on.

What can you do with this?

Here are a few ways to put rand_emoji to use:

Customize your shell prompt — Prepend a random emoji to your prompt string (PS1 in Bash/Zsh, prompt function in PowerShell) so every new command line feels a little different.
Liven up script output — Sprinkle rand_emoji into your build scripts, deployment tools, or CI logs to make status messages more glanceable and less wall-of-text.
Git commit hooks — Add an emoji to your pre-commit or post-commit messages for a quick visual cue in your log history.

Why bother?

It reduces monotony — Staring at a plain terminal all day gets old. A small, random visual change keeps things just interesting enough to stay engaged.
It's a low-effort morale boost — It takes two minutes to set up and costs nothing. A tiny 💩 or 🦄 popping up in your prompt can genuinely make you smile mid-debugging-session.
It's a gateway to shell customization — Once you start tweaking your shell config for fun, you'll naturally learn more about how your environment works — arrays, variables, random numbers, profile scripts — all useful knowledge.

Make your shell environment more fun -- Try it!

Cost-Effective Multi-Agent AI: Separating Reasoning from Execution

2026-01-31T00:00:00Z

Building AI agents that actually work in production is expensive. Every API call to GPT-4 or Claude costs money, and when you're running agentic loops with multiple tool calls, those costs add up fast. But what if you could use expensive models only where they truly matter, and run everything else locally for free?

That's exactly what I built. A multi-agent system that uses powerful cloud LLMs for planning and tiny local models for execution.

View Code on GitHub

The Problem with Current Approaches

Most AI agent frameworks treat all tasks equally. Need to plan a complex workflow? Call GPT-4. Need to fetch weather data? Call GPT-4. Need to format a response? Call GPT-4 again.

This is wasteful. Planning and decomposition require genuine intelligence. But once you have a clear, small task like "Call this API and extract the temperature", a 2B parameter model running on your laptop can handle it just fine.

There's also a privacy angle. Your reasoning agent only needs to understand the problem structure. It doesn't need to see customer PII, payment data, or internal API responses. By splitting reasoning from execution, sensitive data never leaves your infrastructure.

The Architecture

flowchart TB
    subgraph Cloud["☁️ Cloud / Powerful Model"]
        RA["🧠 Reasoning Agent<br/>(external LLM)<br/>───────────<br/>• Decomposes problems<br/>• No tool access<br/>• No sensitive data"]
    end
    
    User["👤 User Query"] --> RA
    
    RA -->|"Task 1"| EA1
    RA -->|"Task 2"| EA2
    RA -->|"Task 3"| EA3
    
    subgraph Local["🏠 Local Infrastructure"]
        EA1["⚡ Execution Agent 1<br/>(local LLM)"]
        EA2["⚡ Execution Agent 2<br/>(local LLM)"]
        EA3["⚡ Execution Agent 3<br/>(local LLM)"]
        
        EA1 --> Tools1["🔧 Weather API"]
        EA2 --> Tools2["🔧 City Database"]
        EA3 --> Tools3["🔧 Internal APIs"]
    end
    
    EA1 -->|"Result 1"| Synth
    EA2 -->|"Result 2"| Synth
    EA3 -->|"Result 3"| Synth
    
    Synth["📋 Synthesize Results"] --> Response["✅ Final Response"]
    
    style Cloud fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style Local fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style RA fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style EA1 fill:#f3e5f5,stroke:#7b1fa2
    style EA2 fill:#f3e5f5,stroke:#7b1fa2
    style EA3 fill:#f3e5f5,stroke:#7b1fa2

The system has two types of agents:

🧠 Reasoning Agent - Uses a capable model (like cloud-based GPT-4o or local gemma3:12b) to decompose complex problems into independent, atomic tasks. This agent never touches sensitive data or makes tool calls. It just plans.

⚡ Execution Agents - Use lightweight local models (like local granite4:tiny-h with tool-call support) to execute individual tasks. These agents have access to tools and APIs, handle sensitive data, and run entirely on your hardware.

from strands import Agent
from strands.models.openai import OpenAIModel
from strands.models.ollama import OllamaModel

# Reasoning agent - smarter model, no tools, no sensitive data
reasoning_model = OpenAIModel(
        model_name="gpt-4o",
        temperature=0.5
    )
reasoning_agent = Agent(
        model=reasoning_model,
        system_prompt="""You are a planning agent. Break down complex 
        problems into small, independent tasks. Output a JSON list of 
        tasks. Do NOT execute anything yourself."""
    )

# Execution agent - tiny model, full tool access
execution_model = OllamaModel(
        host="http://localhost:11434", 
        model_id="granite4:tiny-h",
        temperature=0.3
    )
execution_agent = Agent(
        model=execution_model,
        tools=[get_city_info, get_weather, search_books]
    )

How It Works

Take a query like "Find cities similar to Austin, TX based on climate and population."

The reasoning agent breaks this into atomic tasks:

Get Austin's weather data
Get Austin's population
Search for cities with similar climate
Search for cities with similar population
Find the intersection

Each task is then dispatched to an execution agent. These can run in parallel since the tasks are independent.

def orchestrate(user_query: str):
    # Step 1: Plan with the smart model
    plan = reasoning_agent(f"Break this into tasks: {user_query}")
    tasks = json.loads(plan.message)
    
    # Step 2: Execute with cheap local models
    results = []
    for task in tasks:
        result = execution_agent(task["instruction"])
        results.append(result)
    
    # Step 3: Synthesize (can use reasoning or execution agent)
    return execution_agent(f"Combine these results: {results}")

Real Examples

Example 1: Similar Cities Finder (output)

I used gemma3:12b for reasoning and granite4:tiny-h for execution. The reasoning agent decomposed "find similar cities to Austin, TX" into weather lookups, population queries, and comparison tasks. Execution agents made the actual API calls.

Example 2: Book Recommendations with Geopolitical Context (output)

For another complex task combining book data with current events, I used granite4:tiny-h for both reasoning and execution. The key insight: even a tiny model can plan effectively when the problem domain is well-defined and the output format is constrained.

The Trade-offs

Pros:

Significant cost reduction. Cloud API calls drop by 80-90% in typical workflows
Privacy by design. Sensitive data stays on your infrastructure
Parallelization. Independent tasks can run concurrently
Fault isolation. One failed execution doesn't break the whole workflow
Model flexibility. Swap reasoning or execution models without changing architecture

Cons:

Latency overhead. The planning step adds one round-trip before execution starts
Task decomposition quality matters. Bad plans lead to bad results (garbage in, garbage out)
Local model limitations. Some tasks genuinely need stronger models

Where This Applies

This pattern works well for:

Enterprise workflows with strict data residency requirements
High-volume applications where API costs are a real concern
Hybrid cloud setups where you want cloud intelligence with local execution
Regulated industries (healthcare, finance) where data exposure is a compliance issue
Edge deployments where bandwidth to cloud APIs is limited

It's less suitable for tasks that require tight reasoning-execution coupling, or when the problem can't be cleanly decomposed.

Technical Notes

I built this using the Strands Agents SDK, which handles the agentic loop, tool calling, and model abstraction cleanly. Strands supports Ollama, LM Studio, llama.cpp, and cloud providers through a unified interface, making it easy to mix and match models.

The key to making this work is good task decomposition prompts. The reasoning agent needs clear instructions on output format and what constitutes an "atomic" task. I found structured output (JSON or XML-like tagging) for explicit task breakdown works better than free-form text.

Conclusion

Not every AI task needs a frontier model. By separating reasoning from execution, you can build agents that are cheaper, faster, more private, and often just as effective. The cloud LLM handles the hard part—understanding what to do. Local models handle the easy part—actually doing it.

The infrastructure is ready. Ollama makes running local models trivial. Strands makes building agents straightforward. The missing piece was the architecture to combine them effectively.

Think big, execute small.

Understanding the Monad Design Pattern in Kotlin

2026-01-10T00:00:00Z

Monads have a reputation for being difficult to understand, often explained with abstract mathematical concepts that leave developers more confused than enlightened. In this post, I'll take a practical approach - implementing monads in Kotlin to show how they solve real problems.

What Problem Do Monads Solve?

Consider this common scenario: you have a chain of operations, each of which might fail or return null. Traditional approaches lead to nested null checks or try-catch blocks:

fun getUserEmail(userId: String): String? {
    val user = findUser(userId) ?: return null
    val profile = user.profile ?: return null
    val email = profile.email ?: return null
    return email
}

Monads provide a cleaner way to chain these operations while handling the "failure" case automatically.

Starting with Functors

Before understanding monads, we need to understand functors. A functor is simply a container that supports a map operation - it lets you transform the value inside without unwrapping it manually.

interface Functor<out A> {
    fun <B> map(f: (A) -> B): Functor<B>
}

From category theory, functors must satisfy two laws:

Identity: functor.map { it } should equal functor
Composition: functor.map(f).map(g) should equal functor.map { g(f(it)) }

The Monad Interface

A monad extends functor by adding flatMap (also known as bind). This is the key operation that enables chaining:

interface Monad<out A> : Functor<A> {
    override fun <B> map(f: (A) -> B): Monad<B>
    fun <B> flatMap(f: (A) -> Monad<B>): Monad<B>
}

The difference between map and flatMap:

map transforms A -> B inside the container
flatMap transforms A -> Monad<B>, then flattens the result

Implementing MayBe: A Practical Monad

Let's implement a MayBe monad (inspired by Haskell's Maybe) for handling optional values:

sealed interface MayBe<out A> {
    fun <B> map(f: (A) -> B): MayBe<B>
    fun <B> flatMap(f: (A) -> MayBe<B>): MayBe<B>
    val isJust: Boolean

    fun getOrNull() = when (this) {
        is Just -> value
        is None -> null
    }

    data class Just<out A>(val value: A) : MayBe<A> {
        override fun <B> map(f: (A) -> B) = Just(f(value))
        override fun <B> flatMap(f: (A) -> MayBe<B>) = f(value)
        override val isJust = true
    }

    data object None : MayBe<Nothing> {
        override fun <B> map(f: (Nothing) -> B) = None
        override fun <B> flatMap(f: (Nothing) -> MayBe<B>) = None
        override val isJust = false
    }
}

The beauty here is in how None handles operations - it simply returns None, short-circuiting the entire chain without explicit null checks.

An Alternative: Optional Monad

Here's another implementation with a factory method for easy construction:

sealed interface Optional<out A> {
    fun <B> map(f: (A) -> B): Optional<B>
    fun <B> flatMap(f: (A) -> Optional<B>): Optional<B>

    fun getOrNull() = when (this) {
        is Some -> value
        is None -> null
    }

    companion object {
        fun <B> of(value: B?): Optional<B> =
            if (value == null) None else Some(value)
    }

    data class Some<out A>(val value: A) : Optional<A> {
        override fun <B> map(f: (A) -> B) = of(f(value))
        override fun <B> flatMap(f: (A) -> Optional<B>) = f(value)
    }

    data object None : Optional<Nothing> {
        override fun <B> map(f: (Nothing) -> B) = None
        override fun <B> flatMap(f: (Nothing) -> Optional<B>) = None
    }
}

Using Monads in Practice

Now our earlier example becomes elegant:

fun getUserEmail(userId: String): Optional<String> {
    return Optional.of(findUser(userId))
        .map { it.profile }
        .map { it.email }
}

Notice how clean this is - just chained map calls! This works because our Optional.map implementation uses of() internally:

override fun <B> map(f: (A) -> B) = of(f(value))

If any step returns null, of() converts it to None, and subsequent operations short-circuit automatically.

So when do you need flatMap? When your function already returns an Optional:

fun findUserProfile(userId: String): Optional<Profile> { ... }

fun getUserEmail(userId: String): Optional<String> {
    return Optional.of(findUser(userId))
        .flatMap { findUserProfile(it.id) }  // returns Optional<Profile>
        .map { it.email }
}

The rule:

map - when your function returns a plain value (A -> B)
flatMap - when your function already returns an Optional<B>

No null checks, no early returns - just a clean pipeline of transformations.

Why Not Just Use Kotlin's Nullable Types?

Kotlin's ?. safe call operator is excellent, but monads offer additional benefits:

Composability - Monads can be combined and chained in powerful ways
Abstraction - The same pattern works for error handling, async operations, and more
Explicit semantics - Optional.None vs null makes intent clearer
Railway-oriented programming - Easy to build pipelines with automatic error propagation

Beyond Optional: Other Monads

The monad pattern applies to many scenarios:

Result/Either - For operations that can fail with an error
IO - For encapsulating side effects
Future/Promise - For async operations
List - Yes, lists are monads too!

Source Code

The full implementation is available on GitHub: kotlin-demo

The repository includes additional functional programming examples like ProducerFunctor and TripletFunctor.

Conclusion

Monads aren't magic - they're a design pattern for composing operations on wrapped values. Once you understand map and flatMap, you've understood the core concept. The rest is just applying it to different scenarios.

The key insight is that monads let you focus on the "happy path" while the container handles the edge cases (null, errors, async completion) automatically.

References

Monad (functional programming) - Wikipedia - Comprehensive overview of monads in functional programming
Functors, Applicatives, And Monads In Pictures - Excellent visual guide to understanding these concepts
Monads, Part One - Eric Lippert - In-depth series on monads from a C# perspective

Happy functional programming!

Generating Mandelbrot Set Images with Kotlin

2025-09-15T00:00:00Z

There's something deeply satisfying about generating fractal images through code. The Mandelbrot set, in particular, has fascinated mathematicians and programmers alike since Benoit Mandelbrot first visualized it in 1980. I built a Kotlin library to explore this mathematical wonder, and I'd like to share both the results and the approach.

What is the Mandelbrot Set?

The Mandelbrot set is defined by a deceptively simple formula: for each point c in the complex plane, iterate z = z² + c starting from z = 0. If the sequence stays bounded (doesn't escape to infinity), that point is in the Mandelbrot set.

The magic happens at the boundary - points that take longer to escape produce the intricate, infinitely detailed patterns that make fractals so mesmerizing.

Why Kotlin?

I chose Kotlin for this project for several reasons:

Coroutines - Mandelbrot generation is embarrassingly parallel. Each pixel can be computed independently, making it perfect for concurrent processing. Kotlin's coroutines provide an elegant way to parallelize the computation.
Clean syntax - Complex number operations and iteration logic read naturally in Kotlin.
JVM performance - The heavy numerical computation benefits from JVM optimizations.

Sample Renders

Here are some images generated by the library at various zoom levels and color mappings:

The classic Mandelbrot set view - the iconic "bug" shape with infinite complexity at its edges.

A Julia set render - a close relative of the Mandelbrot set, also supported by the library.

Different color mappings highlight various aspects of the escape-time algorithm.

The deeper you zoom, the more intricate structures emerge.

How It Works

The core algorithm is straightforward:

fun isInMandelbrotSet(c: Complex, maxIterations: Int): Int {
    var z = Complex(0.0, 0.0)
    for (i in 0 until maxIterations) {
        z = z * z + c
        if (z.magnitudeSquared() > 4.0) {
            return i  // Escaped - return iteration count for coloring
        }
    }
    return maxIterations  // Didn't escape - in the set
}

The iteration count for escaped points determines the color, creating those beautiful gradient bands around the set.

Using Kotlin coroutines, the image is divided into chunks that are processed concurrently:

coroutineScope {
    for (chunk in imageChunks) {
        launch {
            computeChunk(chunk)
        }
    }
}

This approach scales well across CPU cores, significantly reducing render times for high-resolution images.

Anti-Aliasing with Super Sampling

One challenge with fractal rendering is aliasing - the jagged edges and moiré patterns that appear when infinite detail meets finite pixels. This is especially noticeable at the boundary of the Mandelbrot set where detail exists at every scale.

To address this, I implemented super sampling anti-aliasing (SSAA). Instead of computing a single point per pixel, we sample multiple points within each pixel and take the median value:

fun computePixelWithSuperSampling(x: Int, y: Int, samples: Int): Double {
    val values = mutableListOf<Double>()

    for (sy in 0 until samples) {
        for (sx in 0 until samples) {
            // Sub-pixel offset
            val offsetX = (sx + 0.5) / samples
            val offsetY = (sy + 0.5) / samples

            val c = pixelToComplex(x + offsetX, y + offsetY)
            values.add(calculatePoint(c))
        }
    }

    values.sort()
    val mid = values.size / 2
    return if (values.size % 2 == 0) {
        (values[mid - 1] + values[mid]) / 2.0
    } else {
        values[mid]
    }
}

With a 2x2 or 4x4 sample grid, edges become smooth and the fine details render more accurately. The trade-off is computation time - 4x4 super sampling means 16 times more calculations per pixel. But combined with coroutines for parallelization, the results are worth it for high-quality renders.

Try It Yourself

The full source code is available on GitHub: Mandelbrot-Kotlin

The project is licensed under Apache 2.0, so feel free to use it, modify it, or learn from it. The library is designed to be extensible - you can experiment with different fractal formulas, color schemes, and rendering parameters.

Interactive Features

The library includes an interactive viewer built with Java Swing that supports:

Real-time zooming and panning - explore the infinite detail of these fractals
Multiple color palettes - right-click to cycle through different color mappings with instant re-rendering

What's Next?

Ideas I'm considering for future enhancements:

GPU acceleration - using Kotlin/Native or compute shaders for even faster rendering
Arbitrary precision support - replacing Double with BigDecimal or similar to enable deep zooming. Currently, Double precision limits how far you can zoom before pixelation artifacts appear due to floating-point precision loss

Fractals remind us that simple rules can produce infinite complexity - a lesson that applies well beyond mathematics.

Happy coding, and happy exploring!

Building This Website with Eleventy and Bulma

2025-08-12T00:00:00Z

After years of writing on Medium and creating internal documentation at work, I decided it was time to build my own personal website. As someone who values simplicity and maintainability in system design, I wanted the same principles to apply here.

Why Build a Personal Site?

Throughout my career, I've benefited enormously from engineers who shared their knowledge publicly. From blog posts that helped me understand distributed systems to open-source tools that accelerated my work, the community has given me a lot. This site is my way of contributing back.

Plus, having a central place to share my thoughts on AI/ML, reliability engineering practices, and software architecture felt overdue.

The Tech Stack

Eleventy (11ty)

For the static site generator, I chose Eleventy. Here's why:

Zero client-side JavaScript by default - Fast, accessible pages
Flexible templating - Supports Nunjucks, Markdown, and more
Simple data cascade - Easy to manage global and page-specific data
Great developer experience - Fast builds and hot reloading

Having worked with complex build systems at scale, I appreciate Eleventy's simplicity. The configuration is minimal yet powerful:

module.exports = function(eleventyConfig) {
  eleventyConfig.addPassthroughCopy("src/assets");

  eleventyConfig.addCollection("posts", function(collectionApi) {
    return collectionApi.getFilteredByGlob("src/blog/posts/*.md")
      .sort((a, b) => b.date - a.date);
  });

  return {
    dir: { input: "src", output: "_site" }
  };
};

Bulma CSS

For styling, I went with Bulma - a modern CSS framework that's:

Pure CSS - No JavaScript dependencies
Modular - Use only what you need
Responsive - Mobile-first design out of the box
Beautiful defaults - Looks great with minimal customization

Loading it via CDN keeps things simple:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bulma@0.9.4/css/bulma.min.css">

Alpine.js

For the bits of interactivity I needed (mobile menu, image lightbox), Alpine.js is perfect:

Lightweight - Just 15KB minified
Declarative - Behavior lives in your HTML
No build step - Works directly in the browser

Project Structure

I organized the project to be intuitive and maintainable:

src/
├── _data/          # Global site data
├── _includes/      # Layouts and partials
├── assets/         # CSS, images, etc.
├── blog/           # Blog posts in Markdown
├── photography/    # Photo gallery
├── resume/         # Resume page
├── about.njk       # About page
└── index.njk       # Home page

Built with AI Assistance

I used Claude Code to help scaffold and iterate on this site. It's a great example of how AI tools can accelerate development - from generating boilerplate to debugging CSS issues. As someone who's led AI adoption initiatives, I practice what I preach.

Lessons Learned

Start simple - You can always add complexity later
Content first - The tech should serve the content, not the other way around
Progressive enhancement - The site works without JavaScript enabled
Force simplicity - A principle I follow at work applies here too

What's Next?

Some features I'm considering:

Dark mode toggle
Blog search functionality
RSS feed
More content on AI/ML and reliability engineering topics

But for now, I'm happy with this foundation. It's fast, accessible, and easy to maintain - exactly what a personal site should be.

Feel free to reach out on LinkedIn if you want to chat about the tech stack or anything else!

Welcome to My Blog

2025-06-01T00:00:00Z

Welcome to my corner of the internet! After 22+ years in software engineering, I've finally decided to create a dedicated space to share my thoughts on technology, leadership, and the lessons learned along the way.

What to Expect

This blog will cover topics I'm passionate about and have hands-on experience with:

AI/ML & Developer Productivity

Having led AI adoption initiatives across global engineering teams, I'll share insights on:

Practical applications of LLMs and AI tools in software development
Prompt engineering techniques that actually work
Building developer tools with Model Context Protocol (MCP)
Lessons from driving cultural shifts toward AI-powered engineering

Reliability Engineering

With years of experience in reliability engineering, expect posts on:

Achieving high availability in distributed systems
Incident management and blameless postmortems
SLOs, error budgets, and reliability practices
Operational readiness and capacity planning

Software Architecture & Leadership

From my journey through individual contributor to Principal Engineer roles:

Designing scalable microservices architectures
Technical leadership and mentorship
Building high-performing engineering teams
Career growth in software engineering

Photography

When I'm not coding, I explore the world through my camera lens. Occasional posts about photography adventures and perspectives.

Why Start a Blog?

I've always believed in sharing knowledge. Some of my biggest breakthroughs came from reading others' experiences. I've previously written on Medium about topics like application couplings, data science, and error budget policies - this blog extends that journey.

Writing also forces clarity of thought. When you explain something for others, you discover gaps in your own understanding.

Stay Connected

Feel free to reach out if you have questions, want to collaborate, or just want to say hi. You can find me on LinkedIn and GitHub.

Thanks for stopping by!

Happy coding!