<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Mohammed Umair — Writing</title>
    <link>https://mohammedumair.com</link>
    <description>Mohammed Umair is a business builder and operator working across growth, operations, smart infrastructure and enterprise technology.</description>
    <language>en</language>
    <lastBuildDate>Sun, 12 Jul 2026 22:14:18 GMT</lastBuildDate>
    <atom:link href="https://mohammedumair.com/feed.xml" rel="self" type="application/rss+xml"/>
    
      <item>
        <title><![CDATA[The Decision That Disappeared]]></title>
        <link>https://mohammedumair.com/writing/the-decision-that-disappeared</link>
        <guid isPermaLink="true">https://mohammedumair.com/writing/the-decision-that-disappeared</guid>
        <pubDate>Sun, 12 Jul 2026 00:00:00 GMT</pubDate>
        <description><![CDATA[AI tools helped our team move faster. They also made it easier to lose the reason behind a decision. What we changed, and what it taught me about working with AI.]]></description>
        <content:encoded><![CDATA[
While working on the NxSync ERP, I noticed a recurring problem. AI tools helped the team move faster, but they also made it easier to lose the reason behind a decision. A change that made sense on Monday could look arbitrary two weeks later, because the conversation that produced it had disappeared.

This was not carelessness. Everyone was working the way the tools invite you to work. You describe a problem in a chat window, the assistant proposes a solution, you refine it together, and the code changes. The output survives. The reasoning does not.

In a small project that hardly matters. In an enterprise system it matters a great deal. When something breaks, the first question is always *why is it like this?* — and increasingly the honest answer was that nobody could remember, because the "why" had lived in a session that no longer existed.

## The pattern, once you see it

I have spent most of my career in physical projects — buildings, automation, interiors — where the space between disciplines is where things go wrong. The electrician and the AV integrator each do competent work and the system still fails, because nobody owned the joint between them.

AI-assisted software has the same weakness in a new place. The joint is not between two trades; it is between sessions. Each conversation with an AI assistant is competent in isolation. The failure accumulates in the gaps: a requirement quietly reinterpreted, an architectural boundary moved without record, a dependency assumed that was never checked.

The speed was real. The confidence in what we had built was declining even as the output grew.

## What we changed

We stopped starting with the tool and started with the problem. Before any AI-assisted work began, the business problem was written down, along with what "finished" would mean for that piece of work. Work was cut into bounded pieces small enough to review properly. Decisions that changed requirements or architecture were recorded outside the chat, where the next person — or the next session — could find them. And nothing shipped without a human looking at it against the original intent.

None of this is novel as project discipline. What surprised me was how much of it the industry quietly dropped the moment the tools became conversational.

That set of habits eventually became a product, Spine, because I wanted the discipline to be a system rather than a resolution. But the habits matter more than the software. You could keep most of them with a text file and some patience.

## What I am still unsure about

I do not yet know how large a piece of autonomous AI work can safely be before it needs a human checkpoint. The honest answer is that the limit keeps moving, and anyone who claims a fixed rule is guessing.

What I am confident about is smaller and more durable: if you cannot explain why a system is the way it is, you do not fully control it. That was true of buildings before it was true of software, and it will stay true whatever the tools become.
]]></content:encoded>
      </item>
    
      <item>
        <title><![CDATA[What Buildings Taught Me About Software]]></title>
        <link>https://mohammedumair.com/writing/what-buildings-taught-me-about-software</link>
        <guid isPermaLink="true">https://mohammedumair.com/writing/what-buildings-taught-me-about-software</guid>
        <pubDate>Fri, 10 Jul 2026 00:00:00 GMT</pubDate>
        <description><![CDATA[Fifteen years of physical projects — automation, AV, interiors — turned out to be surprisingly good preparation for leading enterprise software work. A field note on why.]]></description>
        <content:encoded><![CDATA[
There is a common assumption that leading physical projects and leading software projects require entirely different muscles. I believed a version of it myself. Then I started directing enterprise software work and kept having the same feeling: I have seen this failure before, on a job site.

Over fifteen years running Synchronos we delivered thousands of projects, most of them multidisciplinary — automation, AV, security, lighting and networking that all had to work together in one building. The technology itself was rarely the problem. The failures lived in the space between disciplines. The electrician didn't talk to the AV integrator. The automation vendor didn't understand the networking constraints. Each trade did competent work, and the building still didn't work.

When I moved into enterprise software, the pattern was waiting for me. The backend engineers didn't understand the business constraint. The interface designers didn't understand the data model. The AI assistants wrote code without understanding the production environment. Different trades, same gaps.

## What transferred

In physical projects, our answer had been to own the whole cycle — discovery, design, procurement, delivery, commissioning, support — so that there was one team answerable when systems met each other. Clients didn't buy automation from us. They bought the absence of finger-pointing.

In software, the same instinct translated into two habits.

The first is writing down what "finished" means before work starts. On a job site this is a commissioning checklist; nobody argues with it. In software it is strangely controversial, and its absence is why so many projects are permanently eighty percent done.

The second is keeping a single point of accountability for every joint between disciplines. Committees do not ship buildings, and they do not ship products. Someone has to own the seam.

## The part that surprised me

I expected the physical world's discipline to feel heavy in software. It didn't. If anything, software teams were relieved when the ambiguity was taken away — when the requirement was written down, the boundary was explicit and someone would actually check the result against the intent.

If you are struggling to deliver a complex system of any kind, my field note is this: look for the gaps between disciplines, because that is where the project is failing; give the seams an owner; and define what finished looks like before you start. The medium changes. The discipline doesn't.
]]></content:encoded>
      </item>
    
  </channel>
</rss>