Ai

Working with Software Factories: A Transition Proposal

Why This Proposal

Getting an org or a team to adopt a Software Factory is yet another Management of Change. This proposal aims only to set guiding principles and expectations to help with the transition.

I’ve been using software factories since the beginning of the year. Initially out of curiosity, then out of necessity as I was onboarding multiple engineers at once and I needed to ship changes. Now I want them badly at a company level. Over the past few months, I’ve seen teams, individuals and myself included taking different perspectives on software factories, from AI-pilled approaches to various degrees of skepticism.

The skeptics raise good points, forged by years of experience: how is cross-team collaboration handled, who a reviewer interacts with in a PR, who is accountable, etc. They should be answered and integrated into a transition framework.

Guiding Principles

  • The author of the spec is accountable: The human who launched the work is the manager of the agents executing it. They must make the spec public. They also own the cross-team collaboration, the final design decisions and the outcome.
  • Agents are teammates in the PR: Reviewers can and should interact with agents as they would with a human engineer implementing a spec. The limit is what the agent can reasonably act on.
  • Coordination is automated, not just the code: The factory must be able to detect and execute a human handoff, for example when a comment cannot be addressed, or a reviewing team was not visibly looped in on the spec. A doc with a list of approvers is now a critical input to the factory, no longer just of a cover-my-ass artifact ;)

Upfront Notice to Impacted Teams

The factory needs to detect which team will be impacted, check whether the team has been informed already and notify the author as needed. The last opportunity to do so is before a PR’s transition from draft to ready-to-review.

Notes:

  • This is for the transition to software factories. Once factories are adopted, further automation can pick up the work: pre-reviews by the other team’s factory or by engineers’ agents.
  • The spec and the PRs must name the author.

Explicit Review Comments

Agents read comments more literally (and so do I). The common “I think you should consider xyz, imho” or “Do we need this?” comments rely on shared human, national and company culture to make sense.

Clear intent in PR comments will help both agents and humans alike:

  • Question: The reviewer wants context, no change is expected.
  • Suggestion:The agent decides to apply the recommendation or checks with the authors.
  • Issue (blocking): Something must change (ideally with the request-change review).
  • Nit: Do what you want with that.

In return the factory must be able to:

  • Provide context (e.g. this is PR 3 of 5, or what the spec says).
  • Make adjustments.
  • Escalate to the author when needed.

Basically, take the fears and shift them left.