The journey
From making a thing to cultivating what comes next.
At first, you decide each change and an agent helps you make it. Over time, you can delegate longer stretches of work—and broaden what the work is for.
Follow one example through that change. These are connected possibilities, from ordinary coding practice to proposed organisational experiments. You can explore them at your own pace and combine them in different ways.
Our starting point: a better feed
LinkedIn Slop Filter is a browser extension intended to reduce unwanted content while keeping worthwhile posts visible. It works on posts already shown in the feed. It gives us a concrete setting for thinking about mistakes, preferences and useful improvements.
For a first project, use a tiny mock feed with fictional posts. The examples below are possible briefs, not a claim that every feature or experiment has already been delivered.
New to coding agents and Git? Start here.A feature or a small project
Make something useful
“Help me build this.”
You describe what you want. A coding agent can read project files, make changes and run checks. You try the result, explain what feels wrong and ask for another change. This is where many people begin with vibe coding: making software through conversation.
Start with a problem you can recognise and a result you can inspect. You do not need to understand every line of code to notice that a button loses your work or that a page is difficult to use. Ask the agent to explain the changes as you go.
A useful next move: Keep a record of the work so that the next conversation can pick up where this one stopped.
A project that survives the conversation
Give the work a memory
“Take this change through to a checked result.”
Git records versions of your project. GitHub gives that project a shared home, with written tasks called issues and proposals for changes called pull requests. The plan, the changes and the checks can now outlast a chat session.
A branch keeps a proposed change separate until it is ready. A commit is a saved set of changes on that branch. A pull request lets you review those changes before merging them into the main version. A preview lets you try the result before publishing it.
When several agents work at once, a worktree gives each one a separate working folder. Shared instructions in AGENTS.md explain how to run the project and check the work. Separate folders still need clear ownership when changes affect the same thing.
A useful next move: Notice which coordination jobs you keep repeating. Those are candidates for automation.
A repeatable software factory
Let the delivery process run
“Organise the work and deliver this improvement.”
Soon you are repeatedly handing work to agents, checking what is blocked, asking for reviews and recovering interrupted sessions. An orchestrator is software that coordinates those steps. It keeps track of the work when an individual agent stops.
The process can assign independent tasks, wait for dependencies, run checks, request fixes and prepare a release. With permission, deployment can run automatically too. You get a result and a record of what happened, while routine coordination becomes part of the system.
Gas City is one toolkit for building this kind of process. It provides reusable coordination machinery; you configure how work should move through it. A single well-organised agent is also a useful starting point. The right amount of machinery depends on the work.
Where Gas City, GitHub and the other tools fit
GitHub holds the project and its review record. Gas City coordinates execution. A rig is a registered project, a Bead is a persistent work item, a formula describes a reusable workflow, and a Mayor is a coordinating agent role.
The reported local setup uses T3 Code as an interface and Tailscale to reach the computer over a private network. Those are choices for operating the workflow; the ideas apply to other setups too.
Read Gas City's own descriptionA useful next move: Once delivery is repeatable, the bigger question becomes which improvement is worth delivering.
A product and the people it serves
Give it an outcome to investigate
“Find out how to make this feed more useful.”
A product is more than a working piece of software: it serves a continuing need. Instead of prescribing the next feature, describe whose experience should improve. The work now includes understanding the problem, comparing options and finding evidence that could change the decision.
An agent might investigate a better classifier, personal rules or showing a label instead of hiding a post. It might discover that people want help finding worthwhile material in the first place. A short interview or a manual trial may answer the question before anyone writes more code.
This creates a learning loop: observe a need, suggest explanations, test an intervention, examine the result and choose what to do next. Delivery is one part of that loop. Continuing, changing direction and stopping are all possible results.
A useful next move: Make the method of investigation inspectable, so you can improve the team as well as the product.
A team with a purpose, resources and ways of learning
Cultivate the organisation
“Pursue this outcome, and improve how you work towards it.”
Now the thing you are shaping includes the organisation itself: who investigates, who builds, who reviews, how they communicate, what they can spend and how they make decisions. Write down that arrangement so that it can be tried again and changed deliberately.
Compare a capable agent working alone, a team sharing its investigation and teams independently exploring alternatives. Give each arrangement comparable total resources and an evaluator whose judgement the teams cannot rewrite. Include human review time and failed attempts in the cost.
Keep the useful findings from every attempt. A team whose product loses the comparison may have discovered an important unmet need. Change one part of the organisational recipe, try it again and see whether it works on a different problem.
A useful next move: Test whether a successful way of working transfers to another product before expanding its remit.
Many organisations pursuing related purposes
Grow an ecosystem that learns
“Explore different ways to improve this wider situation.”
An ecosystem contains organisations with different approaches and responsibilities. Some investigate needs, some develop products, some provide shared services and some evaluate results. They can cooperate, compare alternatives and build on each other's findings.
Resources move towards promising work, while some remain available for unfamiliar ideas. Teams can form, combine or finish. Their evidence and methods survive. You can also investigate the rules of the ecosystem: when should teams share findings, how should work be funded, and who gets to decide what success means?
The feed filter has now served its purpose as a small example. Improving an information environment could involve reading tools, community moderation, education and new ways to discover sources. Each serves different people and requires its own evidence.
A useful next move: Explore what changes when this work reaches public services, physical infrastructure and much longer timescales.
Your role grows with the work
You begin by checking a change. Later you design the conditions in which work happens: purpose, resources, feedback and relationships. As the scope grows, more people have a stake in those decisions.