TL;DR / Key Takeaways

Enterprise architecture review boards routinely take 3-5x longer than the implementation they're reviewing, and almost nobody talks about how broken that ratio is.
The RFC process at large companies is often theater: the decision is already made, the document just gives everyone a chance to leave fingerprints.
Solo builders operate on a fundamentally different feedback loop: ship, measure, fix. The feedback is real and immediate.
Predict & Profit's Weather Bot went from 31-member ensemble to 164 members without a single meeting. Built, tested, deployed. That's the contrast.

I spent the better part of a Tuesday writing a six-page RFC for a data pipeline change that I could have finished building by Wednesday afternoon. The actual implementation was two Python files and a config update. The RFC had to go through three rounds of async comments, a 90-minute architecture review call, a follow-up async thread, and finally a sign-off from a VP who admitted on the call that he hadn't read the document.

The feature shipped five weeks after I submitted the RFC. The implementation took two days.

Nobody called that out as a problem. It was just Tuesday.

What Architecture Reviews Are Supposed to Do

I want to be fair here, because I have seen what happens when there are no guardrails at all.

Architecture reviews exist because large systems have large blast radii. A bad schema decision in a shared database can break six downstream consumers. A poorly designed API contract locks you into something painful for years. Someone needs to be asking "have you thought about how this interacts with the billing system" before you deploy, not six months after.

That is legitimate. That is worth some process overhead.

The problem is not the concept. The problem is the ratio.

When the review takes longer than the build, the review has become the product. You are no longer engineering. You are producing documentation artifacts that justify the existence of the review board.

The RFC as Organizational Theater

I have seen a lot of RFCs. I have written a lot of RFCs. Here is what I noticed.

The decisions that actually mattered, the ones that changed system architecture in meaningful ways, were usually decided in a hallway conversation between two principal engineers before the RFC was even written. The RFC was the paperwork that made the decision official. Everyone else was invited to comment so they felt included, not because their input would change anything.

The decisions that were genuinely up for debate in the RFC process were usually the small ones. Which logging format. Whether to use an enum or a string field. Whether the new service needed its own database or could share the existing one. Stuff that had a right answer that any competent engineer could arrive at in twenty minutes of clear thinking.

So what you end up with is a process that rubber-stamps big decisions that were already made, and bikesheds endlessly on small decisions that don't matter much either way.

And the clock is running the whole time.

The Calendar Tax

Here is what five weeks of review actually costs.

You write the RFC. Then you wait for the calendar to open up for the architecture review meeting. The architects are busy people. Three weeks out is a good slot. You sit on it.

Before the meeting, you field async comments. Some are useful. Most are clarifying questions you already answered in the document. You respond to each one because leaving a comment unaddressed signals that you don't value input, and you have to live with these people.

The meeting happens. Forty-five minutes of it is people reading the document in real time. Fifteen minutes is actual discussion. Someone asks you to add a section on rollback procedure. You do not need a rollback procedure for a Python script that reads from an S3 bucket, but you add one.

Another week for the follow-up comments. Sign-off happens. You build the thing in two days.

The five weeks did not make the feature better. I can say that with confidence because the feature was exactly what I described in page one of the RFC. The review process added a rollback section to a document no one will ever read again.

What "Move Fast" Actually Means

When engineers at large companies hear "move fast," they usually interpret it as "skip the review and break things." That framing is wrong, and the companies that tried it literally wrote the book on what goes wrong when you have no process.

Moving fast does not mean no judgment. It means the judgment lives in the builder's head and gets validated by the system's actual behavior rather than a committee's prior beliefs.

When I built the AIGEFS integration for the Weather Bot, the decision tree looked like this. Does NOAA publish AIGEFS data somewhere accessible? Yes, AWS S3 public bucket. Can I pull GRIB2 files with byte-range fetching? Let me try. Does it work? Yes, 868 of 868 downloads succeed. Does the ensemble signal improve my edge? Run it in dry-run mode for two weeks and check.

No RFC. No architecture review. No committee. The system itself was the review board, and it gave me real feedback instead of opinions.

I hit real problems. The xarray truthiness bug crashed coordinate extraction and took me an afternoon to diagnose. The NOMADS rate limiter hit me at 868 parallel requests before I switched to S3. Those were not hypothetical risks that a review board speculated about. They were actual failures that I fixed and moved on from.

That feedback loop is faster, more honest, and more useful than any RFC comment thread I have ever participated in.

The Asymmetry Nobody Talks About

Here is the thing that actually bothers me about enterprise architecture review culture.

The review board takes credit for preventing bad outcomes, but it never has to account for good things that didn't happen because the timeline slipped five weeks. Features that shipped late. Experiments that never started because the RFC process was too expensive to justify. Engineers who stopped proposing new ideas because writing a six-page document for a two-day task felt absurd.

The costs of over-process are invisible because they are counterfactuals. The benefits are visible because occasionally the review catches something real. So the institution looks efficient even when it isn't.

A solo builder sees the other side of this clearly. Every day I spend not shipping is a day the product doesn't improve. There is no one to blame the delay on. The calendar is mine. The decision is mine. The consequences are mine.

That accountability changes how you make decisions. It makes you sharper.

What I Actually Miss About Process

I said I wanted to be fair, so here it is.

The one thing I genuinely miss from enterprise engineering is peer review on code I am less confident about. Not architecture theater. Actual eyes on actual code from someone who knows the codebase.

When I was debugging the Kalshi Econ Bot's get_positions() failure, the bot was returning empty position lists every cycle. The API was returning {'event_positions': [...], 'market_positions': [...]} and my wrapper was reading the wrong key. That bug ran silently for longer than it should have because I had no one to read my kalshi_client.py and say "hey, wrong key here."

A second set of eyes would have caught that in a code review. That kind of review I miss. The architecture review that takes three weeks to tell me my schema looks fine? I do not miss that at all.

The distinction matters. Review as craft improvement is useful. Review as organizational permission structure is usually not.

Building the Weather Bot Without a Committee

The Weather Bot went from a 31-member GFS-only ensemble to a 164-member grand ensemble pulling from GFS, NOAA AIGEFS, ECMWF IFS, and ECMWF AIFS-ENS. Here is roughly what that feature development looked like.

# Simplified grand ensemble weight config
# No RFC required

ENSEMBLE_SOURCES = {
    "gfs": {
        "weight": 0.25,
        "members": 31,
        "provider": "open_meteo",
    },
    "aigefs": {
        "weight": 0.25,
        "members": 31,
        "provider": "aws_s3",
        "bucket": "noaa-nws-graphcastgfs-pds",
    },
    "ecmwf_ifs": {
        "weight": 0.30,
        "members": 51,
        "provider": "open_meteo",
    },
    "ecmwf_aifs": {
        "weight": 0.20,
        "members": 51,
        "provider": "open_meteo",
    },
}

def compute_grand_ensemble_probability(source_probs: dict) -> float:
    total_weight = sum(ENSEMBLE_SOURCES[k]["weight"] for k in source_probs)
    weighted_sum = sum(
        ENSEMBLE_SOURCES[k]["weight"] * v
        for k, v in source_probs.items()
    )
    return weighted_sum / total_weight if total_weight > 0 else 0.0

I decided on the weights by looking at verified accuracy benchmarks for each model, not by consensus. ECMWF IFS gets the highest weight because it has the best track record on global temperature forecasts. ECMWF AIFS gets slightly less because it is newer and I have less data on it. GFS and AIGEFS split the remainder.

Could those weights be wrong? Yes. I will adjust them as I get more trade outcomes. The system tells me when I am wrong. No meeting required.

That is the whole loop. Decide, ship, measure, adjust. It is not reckless. It is just honest about where real feedback comes from.

The Permission Structure vs. The Feedback Structure

Enterprise architecture reviews are a permission structure. Someone with organizational authority has to say yes before you build. The theory is that authority equals judgment, and judgment prevents mistakes.

Solo building is a feedback structure. You build, the market or the system tells you if you were right, and you adjust. The market does not care about your seniority level or your RFC format. It just tells you what happened.

Both structures catch some mistakes and miss others. The permission structure is better at preventing certain classes of systemic risk in large shared codebases. The feedback structure is better at moving fast and course-correcting on wrong assumptions quickly.

The problem in most large companies is not that they chose the permission structure. The problem is that the permission structure expanded to cover decisions where it adds no value and slows everything down, and nobody had the organizational standing to push back on it.

I spent 30 years watching that expansion happen. Now I build things and let the results speak.

It is a better feedback loop. I am not going back.

The architecture review that takes longer than the feature is not a process problem. It is a prioritization problem. Someone decided that the review's existence was more important than the ratio of time it consumes. That decision gets made over and over at large companies, and the engineers who live inside it mostly stop noticing.

Building alone, you notice immediately. There is nothing else to blame.

The Architecture Review That Took Longer Than Building the Feature