Automated Software Factory
The recent trend of accelerated AI development is something to watch, with trends and effective patterns emerging at a faster pace than most organizations can adopt. Each addresses a bottleneck from the previous stage of adoption. Innovation with new technology happens when the mode of discovery, process, and iteration changes, not just through raw substitution of task work.
At the beginning of adoption, I experienced something like the following (circa late 2025, early 2026):
+0. Get engineers and others a harness with organization-wide skills and relevant MCPs. Get them to use it for every work item.
+1. Ok, local development is bottlenecked. Let's move to monorepos. Let's get an AI-native Slack bot that is also connected to the relevant services' MCPs and has org-wide skills. Let's also write skills for automated diagnostics (telemetry, logs, etc.) and support teams.
+2. Let's use loops now to automate routine tasks across teams. Also start adding "hook-driven" flows (i.e. after some domain event).
+3. Ok! Let's design an end-to-end validation harness. It should account for code, services, customers, and various integrations.
The experience has led me to the following conclusions:
At the code level, you want strict, statically typed code. Your core domain logic should be fully referentially transparent, and interfaces should not allow invalid variants to be representable. Code is now cheap, and if possible, you should do this first. This would avoid classes of problems when automating code changes and development.
A unified monorepo and unit of deployment are important. They help avoid classes of defects related to deployment or the sequence of code changes across the product and microservices.
Optimize the base case for agents. And invest heavily in an eval/validation harness for your agents that is representative of your environment.
Ensure all teams have connected MCPs for your services and version-controlled skills. They should be able to leverage them in their harness AND invoke them where work happens (i.e. in Slack).
High-ownership (and durable) teams with domain context can create leverage at scale. This structure lets you continuously invest in process improvement and become proactive as opposed to reactive. This might matter more if you are in the early PMF phase.
Prefer proactive agent loops.
Back to software factories. The basic idea is that you ought to describe system behaviour, outcomes, laws, measurable metrics, and some examples (if applicable). The system should write code, get it reviewed, merge the changes, and deploy and monitor. If done properly, no code will be written or reviewed by humans.
This is something that is very easy to try now, as models are getting better and better at long-horizon tasks. If you want to try it yourself, here is something you can do locally in your harness.
Create a loop-based skill with the following steps:
Read a Linear/Jira project and ensure it has goals, a general approach, and metrics or queries that measure progress against those goals.
Add issues for new work as you identify it. Update the state of issues that have been wrapped up or moved.
Identify the critical path to completion. Work on unblocked tasks in the project. This could be a code change (PR, merge, deploy, etc.), use of third-party services, or browser use for X.
Recursively take on a task until the project is complete.
Make it proactive with a heartbeat, or experiment with the MCP Events proposal.
It should be smart enough to ping the project channel in Slack, get your feedback, update the ticket and project, and continue work if it gets stuck or needs to clarify something. One thing to note is that the more tools and services you have integrated into your harness, the more you benefit from compounding. For example, if we detect an error spike or adoption issue, it ought to be able to proactively create an issue, post a note in Slack, and resolve it.
Once this works locally, move the loop to a shared harness that runs independently of your laptop. A coordinator can detect failed runs and resume work from the last recorded state. Keep project ownership clear, and use the issue tracker to record progress and which agent has claimed each task. This helps agents pick up unfinished work without duplicating each other's efforts.