Forem: Mario Hayashi

The Factory Must Grow: I Replaced Myself with AI. Now What?

Mario Hayashi — Wed, 15 Apr 2026 14:01:41 +0000

tl;dr -- I made an orchestration system that creates PRDs, writes code, opens PRs and handles review feedback. And then I realised I'd automated myself out of the parts I once called my job.

The PR That Changed Things

My orchestration system opened a PR. Tests passing and commit messages better than any I could write. The code was clean. I left my feedback in the PR but the work was solid. After this first PR, I started feeding the task pipeline with more ideas while it churned out PRDs, implemented them and addressed feedback, without much of my attention.

That was the moment it clicked for me: I am just feeding product ideas to the machine. The system handles everything else. Ideas really are cheap now.

If 2025 was the year of agentic AI, 2026 is the year agents will be operationalised at scale. It's both exciting and scary to see half of what I used to call a job automated away.

Step #1: It starts with just a thought. A note in Github

My Slow Start

Most engineers will have been following the rise of agentic AI very closely in 2025. Not me. I was changing nappies. I have a young son and didn't have the bandwidth to follow what was happening. I leaned on Cursor's tooling, had AI help me generate code, but never graduated beyond one-off agentic work. I was comfortable under my rock.

"Just Try Building One Yourself"

An old friend, a software engineer I worked with several times over the years, changed my mind. He had kept a close watch on AI while I was busy being tired from parenting. His advice was simple: build an agent yourself.

I let it sit at the back of my mind for a few weeks. Then I got curious and decided to build it. The gap between reading about agents and watching one work on your own codebase is the gap between reading a recipe and tasting the food. The understanding only clicks when you see an AI agent produce PRs in your codebase, with your conventions. Cheaply also. I'm on Claude's Max plan, so I pay a flat subscription. Over the last week my orchestrator ran 300 worker runs across four workflows and burned through at least $240 of API-equivalent tokens. I say "at least" because crashed runs (of which there were many) never emit a final cost event, so the real number is higher.

At that pace it would be north of $1,000 a month without the subscription. Instead I pay the flat Max fee and the system keeps going. A full pipeline -- PRD, code, review, fix -- averages around $4 in API-equivalent per shipped PR. I hope subscriptions remain this affordable but I know pricing could change any time. I'll park that thought for now.

From Bash Scripts to an Orchestration System

Before the orchestration system, I built basic agents.

I wrote about that first version in An autonomous dev pipeline for one: bash scripts, cron, tmux and Claude glued together until the behaviour was reliable enough to trust. It picked up tasks, wrote code, opened pull requests and handled review feedback. "Beginner" agentic, held together with glue and hope.

It worked well enough but this time I rebuilt the whole thing in TypeScript. Proper architecture and state management. Where bash was duct tape and slightly chaotic, TypeScript is steel: typed interfaces, phase boundaries and methodical error handling.

Managing Many Agents

One agent was manageable. Then I wanted a specialised one for planning, another one for code review, another for fixing PR review feedback. Managing the agents became tricky. Capability is not the bottleneck, orchestration is. I needed a conductor for my orchestra.

Put another way, the factory must grow.

If you recognise that phrase, you already understand how I felt the need to get this right. What started as "let me just automate this one thing" became a full orchestration system: idea goes in, PRD comes out, issues get created, workers pick them up, code gets written, PRs get opened, reviews get addressed, fixes get pushed. I ideate and check in. The system handles the rest.

Factorio: The Factory Must Grow. Source: https://commons.wikimedia.org/wiki/File:Factorio_Space_Age_Gleba_Screenshot.jpg

The pipeline looks something like this:

idea > PRD > issues > code > tests > PR > review > fixes > merge

I'm still figuring this out, but the pattern is clear. Each step is a phase with defined inputs, outputs and failure modes. The system retries, backs off, stops to ask for help as needed.

Under the Hood

The architecture is simpler than you would expect. GitHub is my system of record, my state machine. Each column in the Project board is a state. The orchestrator polls the board, picks up eligible issues and spawns workers.

Step #2: After your idea/note is processed, agent creates a PRD after clarifying ambiguities with me

Step #3: Agent creates a PR

Step #4: Agent reviews its own code and I review it only thereafter

Step #5: Approve and merge the work

Each worker gets its own fresh workspace directory, where it can read, write and commit without stepping on other agents' toes. The worker is a Claude CLI subprocess streaming JSON events and the orchestrator watches that stream for completion.

The part that took the longest to get right was retries. The interesting failures are the ones that look like success. An agent finishes its work, reports success, the orchestrator changes the issue to Done, and nothing has actually been pushed. A pre-commit hook silently rejected the push and the work is sitting orphaned in the workspace directory. Put another way, the agent gets close to finishing, pauses on a turn limit, resumes, gets close again, pauses again, repeat ad infinitum. Or the agent burns through its cost cap without ever committing. Oops.

There are two kinds of retry. A continuation is the agent pausing mid-task because it's hit its turn limit. It resumes with its full conversation history and picks up where it left off. A failure retry is the agent crashing. It retries with a fresh start, no memory, backoff before trying again. Continuation and failure retries both have per-issue caps now. The orchestrator also checks git status after every reported success and abandons any issue that breaches the (configurable) dollar budget. Most of the retry logic exists because one of these went wrong.

The entire workflow configuration (one each for PRD, dev, review) lives in a single file. States, cost limits and prompt templates live in it. When you change the file, the orchestrator hot-reloads it. I spent a good amount of time adjusting these workflow files but it's starting to work.

                    ┌─────────────────────────────┐
                    │      ORCHESTRATOR TICK      │
                    └──────────────┬──────────────┘
                                   │
                    ┌──────────────▼────────────────┐
                    │  1. RECONCILE running workers │
                    └──────────────┬────────────────┘
                                   │
                    ┌──────────────▼──────────────┐
                    │  2. GATE on rate limits     │
                    └──────────────┬──────────────┘
                                   │
                    ┌──────────────▼──────────────┐
                    │  3. FETCH candidate issues  │
                    └──────────────┬──────────────┘
                                   │
                    ┌──────────────▼──────────────┐
                    │  4. DISPATCH workers        │
                    └──────────────┬──────────────┘
                                   │
                    └───── schedule next tick ──────┘

The Thinking Is Still Mine (For Now)

I've replaced (most of) myself. But I can still decide what to build. And what not to build. I can still judge whether code is correct or there's code smell. I can feed the pipeline with ideas that are worth pursuing and axe the ones that are not. I can judge whether the output matches the intent. Being less in the weeds, I have more time to think about strategy.

The orchestration system handles the execution. The thinking, taste and judgement are still mine, for now.

On the flip-side, every layer of abstraction creates demand for someone who understands the layer below it. The more software we automate, the more we need people who can fix the pipes when they burst.

We've all been replaced in small ways before. I started my career writing vanilla JS and jQuery code that has been replaced by higher level libraries and frameworks powering today's web apps. Abstractions make yesterday's hard problems trivial. Each time, the work shifts slightly. The only difference this time is that the shift is... vast.

I am the product and tech strategy machine now. I will feed the machine with ideas until I am replaced again and then I'll have to carve out another higher level role. The factory must grow.

If you're experimenting with AI in your workflow, I'd love to hear from you! I write more like this at blog.mariohayashi.com, and feel free to follow me on X: @logicalicy.

Trade-offs leading tech at early-stage startups

Mario Hayashi — Tue, 05 Jan 2021 12:06:40 +0000

If you're a first-time tech founder or lead at a startup, you'll find yourself spending an inordinate amount of time making trade-offs. You'll need to pick a tech stack that works for your team; decide how much time to invest in visual design; balance your vision with the most valuable thing you can deliver to your user right now.

This post intentionally confronts this controversial topic head on. I feel it's a topic that's not talked about nearly enough. Tech founders and leads often find out they'd spent countless hours on creating something no-one wants only after the fact (myself included). Having built tech from scratch at multiple startups and talked to other tech founders in the past, I've noticed that some (if not many!) first-time founders and tech leads find out the hard way that they may have taken the wrong turn when they were presented with a trade-off.

Here, I talk about the most common "questionable turns" taken that I've experienced for myself, heard about or seen others experience. These thoughts may be controversial and you might not agree with most of them but I will feel I've contributed something if you might agree with just one!

Tech stack: Some founders spend lots of time thinking about the tech stack, trying to pick the "perfect" technologies. It's good to explore. But don't spend an inordinate amount of time thinking about it. Before I joined my first early-stage startup, I was given helpful advice (from my CTO at the time) to "just build". Your startup might not exist in 18 months. Pick things that work right now.
Hire the right people: I was really lucky when we hired someone who was extremely talented at my first tech lead role. I learned things daily from him. He had opinions (something I've come to value a lot). We iterated fast. I've seen the opposite however too: hires who've struggled to push any code and shown not much engagement despite trying to accommodate. Founders inevitably need to make a decision whether or not to let that person go, so make sure to hire well (or be prepared for it to hurt!).
Trust: Give everyone the benefit of the doubt. At the beginning, everything might be all over the place. That's ok. Introduce or suggest the right processes that you and others can trust. That way, structure will come and you'll be able to make progress. If there's distrust from the get-go, it'll be hard to make it work long-term. Everything will feel "transactional".
Testing: One experienced CTO once told me that testing is overkill at a startup pre-Product-Market Fit (PMF). And I think he's mostly right: at many startups, if you're iterating fast, you'll be throwing away lots of code. Yes, there are some exceptions — code for financial transactions, mission-critical applications, etc. where bugs can be disastrous — but for most pre-PMF startups that are creating a few REST APIs and a React.js front-end, focusing on testing may be overkill. Start testing when your product starts to stabilise. Be comfortable with tech debt. You can address tech debt when you reach Series A and your team is growing (when there's an obvious need for tests). It's ok to do things that don't scale at first.
Documentation: Only document as much as you need to communicate with your team. Creating a big project implementation plan may be a waste of time in a small, nimble team. Instead, make sure to communicate in daily stand-ups, comms tools, etc. Similarly, documenting code is secondary at an early stage. You may throw away lots of code and the API may change a lot. Note: this is not to be confused with good practices, such as good naming conventions and code structure, which are a must. Documenting code will become a productivity multiplier once you have more than a few engineers but not until then.
Goals: Make sure to define goals. You might think building tech counts as progress. It is but only if it's contributing to your company's wider goals. Without goals, you'll have less alignment in the team (yet another risk you can't afford at an early stage) and you're leaving success to chance.
Analytics: Similarly, make sure to install analytics from an early stage, tracking the most important metrics. I've seen founders regret not measuring early enough. That includes me!
Design: Both UX and UI design are fluid, especially at the start. You're still trying to find PMF, so naturally your UX will evolve. UI design and the visual language will change as your branding becomes more clear. Therefore, spending an inordinate amount of time creating the perfect design system is a bit of an overkill. I would suggest sitting down with the designer to work out the most pragmatic path to a product that allows users to accomplish their jobs (if you're using JTBD). Often designers are just trying to paint the "ideal" picture. Designers are very pragmatic and will design around technical limitations if you flag them. Also, some product designers may prefer using existing design systems to iterate faster (such as Material, Bootstrap or Tailwind).
Speak to users: You might be getting siloed in "tech", either because responsibilities are defined in binary or there's so much product development to do that you don't have time for other things. If it's the former: ownership doesn't mean others can't be involved. Speaking to customers can be driven by your co-founder but your team will benefit from your involvement as you'll better understand what product to build. If there's too much on your plate: ask yourself, would you prefer to do things the right way or do the right things? Speaking to users de-risks the possibility that you're building the wrong thing.

Here are some rule-of-thumbs that have helped me, with some of the trade-offs above:

Pick speed and limit scope: The Product Management Triangle: you can only pick two of speed, scope and quality. Obviously pick speed, as iterating is key to developing product at an early stage. Of scope and quality, try to limit scope so as to minimise the sacrifices you make with quality. Also, limiting scope will help you iterate faster.
Over-communicate: Always over-communicate your intentions. You might be a small team but it never hurts to share too much. It's never too early to introduce 1-on-1's. If silence is the norm in your startup, ask yourself if that's ok. If silence is the manifestation of lack of trust or "we have nothing to talk about but work", then it might need addressing. Your opportunity cost is your time, so make sure that whatever you're working towards is communicated!
Be pragmatic: Not everything is black-and-white. So making a rule in the first week and expecting it hold for the next months is unrealistic. Take information as it comes and act on the information. The startup that processes the information most efficiently (the advantage of being a startup!) often makes the most progress.

These are just some of my thoughts around tech founder trade-offs. Some may be controversial but I hope there may be some things that you could relate to, from your current or past experience.

10 things they don't teach you about AWS

Mario Hayashi — Thu, 31 Dec 2020 13:05:05 +0000

Some things that I've picked up over the years that may not be obvious when starting out with a new AWS service.

Create SSL certificates in us-east-1. CloudFront's provisioning infrastructure is based there, so is only compatible with us-east-1 certificates.
IAM. May not be obvious to the newcomer: permissions are granted via statements in Policies, which are assigned to either Identities or Resources.
CloudFormation vs Terraform. CloudFormation features oddly sometimes lag behind Terraform, which uses AWS's API under the hood (not CloudFormation's).
Lambda deployment too big. Consider AWS Lambda Layers when your deployment package size has exceeded Lambda limits.
AWS Lambdas suffer from cold starts. Tackle it by reducing your package size. Also, you get at least the same amount of CPU in the init phase as in the handler. You get the init phase for very close to free, so move as much application code as possible outside of your handler function. Subsequent invocations can also reuse resources outside the handler.
SQS deliverability: Standard queues guarantee at least one delivery, FIFO queues attempt one delivery. Make sure your application code makes the correct assumptions/de-dupe as necessary.
AWS KMS is your friend. Use it to encrypt your keys. Think twice about what goes into environment variables or Parameter Store.
AWS RedShift performance. RedShift queries perform a lot better with Distribution Keys. Set them up early.
AWS Cognito customisation. ~~You can't customise AWS Cognito verification emails.~~ As suggested in the comments, you can now customise verification email with code. (See docs.)
AWS Credits. Most accelerator programmes offer you AWS Credits. Join one and ask for them.

Edit: Helpful resource, in case you haven't come across it — Open Guide to Amazon Web Services (GitHub).

Cover: "AWS - Amazon Web Services Office in Houston, Texas" by Tony Webster is licensed with CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/

Do web/mobile app copy changes get handed over to you in Notion/Sheets?

Mario Hayashi — Mon, 14 Dec 2020 03:53:54 +0000

Hey! 👋

This Q is for devs who work on web/mobile apps and have PMs/marketers/designers who write the copy for these apps in Notion/Google Sheets...!

How frequently do you get asked for copy changes (in Notion/Google Sheets)?
How annoying/easy is it for you to update the copy in your web/mobile app?

I wanted to research your opinions, as I'm the maker of CopyOcean (posted about last week), which turns web/mobile app copy in Notion Tables into GitHub/Gitlab Pull Requests. Your feedback will be very helpful! Thank you 🙏

Write copy in Notion, export to JSON

Mario Hayashi — Wed, 02 Dec 2020 22:20:59 +0000

Hey there! 👋

I made a Low-Code project that I’d welcome feedback on —

Aimed at devs, PMs and copywriters, CopyOcean takes copy from a Notion Table and exports it to JSON, so developers can easily drop it into the app (https://www.copyocean.com). It also makes i18n a breeze!

It was motivated by experience in product development where copy management was often messy and ad-hoc. Unnecessary communication overhead, outdated copy and lost productivity were some of the problems that came with copy changes. CopyOcean attempts to solve this problem by using Notion Tables as a central source for copy and helping you add the copy to your product with a machine-readable export (JSON).

Would love to know from you (a) how your copy process looks like today and (b) whether this is of interest! Of course any other thoughts welcome.

Made a blog on software contracting/freelancing

Mario Hayashi — Wed, 07 Oct 2020 13:40:56 +0000

Hey! 👋 Just wanted to share a blog (contracto.dev) I made to describe my experiences as a software contractor. I usually take on jobs like React.js, Node.js, Serverless and more.

If you're curious about software contracting, its challenges and benefits, I've written a couple of posts on it:

Let me know if you have any Qs!

Where to start with SQL? A few posts to help beginners

Mario Hayashi — Mon, 05 Oct 2020 17:13:24 +0000

There are tonnes of SQL resources out there. This small project I made over the weekend — How do I SQL? — collates them to make it a bit more digestible. Hope it helps!

Why SQL? https://howdoisql.com/why-sql
List of SQL resources: http://howdoisql.com/resources
List of SQL courses https://howdoisql.com/courses