Software Engineering on Alfero Chingono

Fixing Deep Nesting in TypeScript: A Real Refactor From CueMarshal

Tue, 10 Feb 2026 09:00:00 +0000

There’s a point in the lifecycle of any project where the “quick fix” logic starts to pile up. For the Gitea MCP server in CueMarshal, that point was the get_pr_diff tool.

What started as a simple API call had grown into a 150-line function with four levels of nested if/else statements. It was classic “Arrow Code”: the logic was pointed so far to the right that it was getting hard to read on a standard monitor.

Here’s how I refactored it and the TypeScript patterns I used to make it maintainable.

The Problem: The “Arrow Code” Trap

The original function had to handle multiple failure modes:

Check if the repository exists.
Check if the pull request exists.
Check if the diff is too large for the LLM’s context.
Handle the Gitea API’s specific error formats.

If any of these failed, I had to return a structured error message. This led to a pattern of:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


if (repoExists) {
 if (prExists) {
 const diff = await getDiff();
 if (diff.length < LIMIT) {
 // Success!
 } else {
 // Error: Too large
 }
 } else {
 // Error: PR missing
 }
} else {
 // Error: Repo missing
}

This is hard to follow because the “Success” case is buried in the middle, and the “Error” cases are disconnected from their triggers.

The Solution: Guard Clauses and “Return Early”

The first step was to flip the logic. Instead of nesting for success, I used Guard Clauses to return early on failure.

1
2
3
4
5
6
7
8


if (!repoExists) return { error: "Repo missing" };
if (!prExists) return { error: "PR missing" };

const diff = await getDiff();
if (diff.length >= LIMIT) return { error: "Diff too large" };

// Success! (Now at the top-level indentation)
return { diff };

This immediately flattened the function and made it much more readable.

Leveling Up with TypeScript’s `Result` Type

To make this even more reliable, I introduced a Result type pattern (inspired by Rust or F#). Instead of returning null or throwing an error, every step of the process returns an object that explicitly states if it succeeded or failed.

1
2
3


type Result<T, E = string> =
 | { ok: true; value: T }
 | { ok: false; error: E };

Using this pattern, I could chain the operations together. If any step returns { ok: false }, the whole chain stops and returns that error.

The “Functional” Refactor

The final version of the get_pr_diff tool now looks like this:

Validate Inputs: A clean, typed function that ensures the repo and PR IDs are valid.
Fetch PR Data: A separate function that handles the Gitea API call and maps the error codes to human-readable messages.
Process Diff: A dedicated function for the logic of truncation and formatting.

By splitting these into small, testable functions, the main execute method for the tool became a simple 10-line orchestrator.

Why This Matters for Agentic AI

Refactoring for “Clean Code” isn’t just for human developers anymore. When you are building Agentic Orchestras, your code is the environment the agent has to reason about.

If your codebase is full of deep nesting and “spaghetti” logic, the AI is more likely to make mistakes when trying to refactor or extend it. Clean, flat, typed code makes your system more “agent-friendly.”

The refactor of the Gitea MCP server didn’t just make my life easier; it made CueMarshal’s agents faster and more reliable.

Related reading:

The Year Agentic AI Got Real: A Developer's Retrospective on 2025

Fri, 12 Dec 2025 09:00:00 +0000

By the end of 2025, software engineering felt materially different from a year earlier.

In 2024, AI in software development was mostly about autocomplete. We had GitHub Copilot, Cursor, and LLMs that were essentially “very fast search engines with a code editor.”

In 2025, that changed. We moved from autocomplete to autonomy. This was the year Agentic AI started to feel real.

The Three Shifts of 2025

Three key technical and cultural shifts happened this year that changed how we build and deliver software.

1. From “Chat” to “Task”

At the beginning of the year, we were still “chatting” with AI. We had to explain the context, provide the files, and then manually copy the code into our editors.

By mid-2025, tools like Copilot Agent Mode and specialized platforms like CueMarshal shifted the interface. Instead of “Write a function for X,” we started saying “Implement the login flow for the new multi-currency engine.” The AI became responsible for the task, not just the output.

2. The Standardization of “Tools” (MCP)

Before 2025, every agent was its own silo. If you wanted an AI to talk to your database or your issue tracker, you had to write a custom integration.

The introduction and rapid adoption of the Model Context Protocol (MCP) changed that. MCP gave us a common language for agents to interact with the world. It turned every API, every database, and every repo into a structured tool that any agent could use. This was the “USB moment” for AI agents.

3. The Rise of the “Agentic Orchestra”

We realized that one “do-it-all” agent was a dead end. Instead, the high-performing teams started building Agentic Orchestras: specialized agents for architecture, development, testing, and review, all working together within a Git-native workflow.

In my own work with CueMarshal, this shift was the difference between an AI that “helped” me and an AI that “worked” with me.

What 2025 Taught Me

The biggest lesson of 2025 for me is that the human role in software engineering is not disappearing. It is being reframed.

More of us are moving into a conductor-architect role. The job is less about writing every line of code and more about designing the system, defining the constraints, and orchestrating the agents doing the implementation. That requires a deeper understanding of Platform Engineering and system architecture than before.

Looking Ahead to 2026

If 2025 was the year of “autonomy,” I expect 2026 to be the year of reliability. We have the tools. We have the protocols. Now we need governance and observability that make agentic workflows as predictable as a standard CI/CD pipeline.

The transition is already underway, and it is moving faster than most people expected. The question for 2026 is no longer “Will you use AI?” It is “How will you orchestrate your agents?”

Related reading:

Why Platform Engineering Is the Most Underrated Career Path in 2025

Fri, 14 Nov 2025 09:00:00 +0000

A few years ago, the common narrative was that “DevOps is dead.” That was mostly clickbait, but it pointed at a real problem: the “You Build It, You Run It” mantra was starting to burn out developers.

Asking a full-stack engineer to also be a Kubernetes expert, a security specialist, and a cloud architect is not realistic. It piles too much cognitive load onto one job.

That is why I think Platform Engineering remains one of the most underrated career paths in 2025.

What Platform Engineering Actually Is

Platform Engineering is the practice of designing and building internal developer platforms (IDPs) that provide clear paved roads. These are self-service workflows that let developers deploy their apps without having to think through the infrastructure from scratch each time.

In a mature Platform Engineering organization, a developer should not have to open a ticket to get a database or a staging environment. They should be able to click a button or run a single command and get what they need in minutes, with security and compliance built in.

Why it matters as a career

If you enjoy systems thinking, automation, and making life easier for other developers, platform engineering is hard to beat. Here is why:

1. You improve output across whole teams

As a product engineer, you ship features for users. As a platform engineer, you improve how other engineers ship. If you save 100 developers one hour a week each, that adds up to roughly two and a half weeks of engineering time for the company every month.

2. You sit at the intersection of tech and strategy

Platform engineers have to understand the entire stack, from the kernel to the cloud to the CI/CD pipeline. But they also have to think like product managers: what do the internal customers, the developers, actually need to do their jobs well?

That puts you in a strong position to influence the technical direction of the company.

3. Demand is ahead of supply

Every company is becoming a software company, and every software company eventually hits the cognitive-load wall. There are thousands of React developers and Go developers, but far fewer people who can design a reliable self-service platform that balances developer freedom with operational control.

The future is agentic platform engineering

In 2025, the platform is no longer just a set of scripts and dashboards. It is starting to become agentic. We are beginning to build platforms where AI agents can identify bottlenecks, suggest architecture improvements, and even fix SonarQube issues before a human sees them.

If you care about delivery infrastructure and AI systems, this is one of the more interesting places to work right now.

How to Get Started

If you are already doing “DevOps” or SRE work, you are halfway there. To move toward Platform Engineering, stop thinking about infrastructure as a pile of resources to manage and start thinking about it as a product to design.

Start by asking your fellow developers, “What is the most frustrating part of your day?” Then go build the platform that removes that friction.

Related reading:

Building a Multi-Currency App: The Edge Cases Nobody Warns You About

Wed, 22 Oct 2025 09:00:00 +0000

When I started building Famorize, I thought multi-currency support would be a weekend feature. “Just store the currency code and multiply by the exchange rate, right?”

Wrong.

Dealing with money in software is a masterclass in edge cases, data integrity, and precision. If you’re building an app that handles more than one currency, especially one designed for families across borders, the complexity stacks up fast.

Here are the four big lessons I learned from building Famorize’s multi-currency engine.

1. Never, Ever Use Floating Point Numbers

This is the “Day 1” rule for financial software, yet I still see it in production. Floating point numbers (like double or float in most languages) are inherently imprecise for decimals. $0.1 + 0.2$ in IEEE 754 floating point is not $0.3$; it’s $0.30000000000000004$.

In Famorize, everything is stored as integers in the smallest unit (e.g., cents for USD, yen for JPY, satoshis for BTC). If a transaction is $10.50, it is stored as 1050. This eliminates rounding errors at the database and application levels.

2. Exchange Rate “Drift” and Historic Validity

Exchange rates are not static. If a user recorded a $50 CAD transaction today, it might be worth $37 USD. If they look at that same transaction next year, it should still be $50 CAD. But what was its USD value at the time?

To handle this, Famorize doesn’t just store the transaction. It stores:

The Base Amount (in the user’s home currency).
The Original Amount (in the transaction currency).
The Exchange Rate Used (at the time of the transaction).

This “Snapshot Pattern” ensures that reports are accurate to the moment the money actually moved, not the current market rate.

3. The “Yen Problem” (Zero-Decimal Currencies)

Most developers assume a currency always has two decimal places. This is a trap.

While USD, CAD, and EUR have two (cents), currencies like JPY (Japanese Yen) have zero, and others like BHD (Bahraini Dinar) have three. If your UI or database assumes integer / 100 is the decimal value, you will break for users in Japan or Bahrain.

Famorize uses a Currency Metadata table that defines the “Scale” (decimal places) for every supported currency. The display layer is responsible for formatting based on this scale.

4. The UX of “Which Currency?”

If a user in Toronto is sending money to a family member in Nairobi, which currency should the input field show?

The UX pattern that worked best for me was to always let the user select the Transaction Currency while showing a real-time “estimated conversion” into their Home Currency. That gives them a clearer sense of how much they are spending in the units they understand.

The Result

Building a multi-currency app taught me that “precision” is not just a technical requirement; it is a trust requirement. If a financial app is off by even one cent, the user’s trust is broken.

Famorize now handles dozens of currencies with an integer-based engine that I can trust with real family finances. It took more than a weekend, but the lessons were worth the effort.

Related reading:

Software Engineering on Alfero Chingono

Fixing Deep Nesting in TypeScript: A Real Refactor From CueMarshal

The Problem: The “Arrow Code” Trap

The Solution: Guard Clauses and “Return Early”

Leveling Up with TypeScript’s Result Type

The “Functional” Refactor

Why This Matters for Agentic AI

The Year Agentic AI Got Real: A Developer's Retrospective on 2025

The Three Shifts of 2025

1. From “Chat” to “Task”

2. The Standardization of “Tools” (MCP)

3. The Rise of the “Agentic Orchestra”

What 2025 Taught Me

Looking Ahead to 2026

Why Platform Engineering Is the Most Underrated Career Path in 2025

What Platform Engineering Actually Is

Why it matters as a career

1. You improve output across whole teams

2. You sit at the intersection of tech and strategy

3. Demand is ahead of supply

The future is agentic platform engineering

How to Get Started

Building a Multi-Currency App: The Edge Cases Nobody Warns You About

1. Never, Ever Use Floating Point Numbers

2. Exchange Rate “Drift” and Historic Validity

3. The “Yen Problem” (Zero-Decimal Currencies)

4. The UX of “Which Currency?”

The Result

Leveling Up with TypeScript’s `Result` Type