Finding the Fun in Building Your Own Software Factory

Many developers are still uncertain about coding agents. The “engineers are cooked” refrain does little to help. Fast demos are exciting, but they leave an important question open: how do you use these tools to build production software well and still enjoy your craft?

Vibe coding makes experimentation fun. It has its place. I also want that enjoyment while building software people depend on, with quality, understanding, and responsibility for what ships.

Coding agents have made me more ambitious about both the software I build and how I build it. This series explores that change through three ideas: raise expectations, make human attention the priority, and build a system that keeps improving.

1. Raise your expectations

We have spent years making trade-offs around the cost of implementation. In a previous planning cycle, a Platform Team had to choose what to take into a sprint:

• Break a design-system module containing 50 components into smaller modules.
• Build a telemetry tool for the iOS team.
• Add automatic memory-leak tracing to the app.

Choosing one meant postponing the others. With coding agents, you can now tackle all three in parallel and get them done in a single day. That changes what is worth attempting.

Old estimates become habits. We keep ruling out improvements because we learned to expect each one to consume the available time. Recognizing when that constraint has changed lets us take on useful work that used to remain postponed.

I expect higher throughput, better quality, and greater impact from the effort I put in. Easier implementation gives experience and judgment more possibilities: finding a poor architectural boundary becomes more valuable when I can improve it today.

Raising Expectations When Working With Coding Agents

A comparison of 200 contributors with their own earlier commit counts, followed by practical ways to find meaningful work and assess throughput, quality, and impact.

2. Make human attention the priority

For me, efficiency means how much human time a useful result requires. Explaining, steering, reviewing, correcting, and verifying all count.

An agent saying “done” illustrates the problem. If I then spend half an hour discovering what changed and whether it works, that handoff needs improvement. One person’s faster implementation can also become another person’s growing review queue.

I want to observe where the effort goes: repeated explanations, awkward handoffs, interruptions, and slow feedback. Ten minutes of unattended execution and ten minutes of rescuing an agent have different costs. Timings and feedback collected during the work help me choose what to improve.

Then follow the bottleneck as it moves. Faster implementation may expose slow review; better review may expose slow integration. Improving that whole path leaves more attention for understanding problems and making decisions.

Making Human Attention the Priority

My iOS code-review workflow: where the attention goes, what I can measure, and how feedback captured during the work guides improvements.

3. Build a system that keeps improving

The foundation: prepare the project for fast iteration. Spend time thinking through the architecture: where responsibilities belong, what each part exposes, and how a change will be built and verified. Make it easy to change one part without having to understand or rebuild everything around it. Modular architecture gives me that foundation: clear responsibilities and narrow contracts keep changes understandable, while focused builds and tests shorten feedback. The aim is a project you can keep reshaping quickly as you learn.

Modular iOS Architecture for Agentic Coding

Design principles and practical iOS rules for module boundaries, ergonomic wiring, cache reuse, focused workspaces, and selective testing.

The toolset: measure the work and improve it. Build or buy tools that show where time and attention go, then help remove the bottlenecks. Measure build and test times, capture review feedback, and notice where people repeatedly have to intervene. Use that evidence to choose the next improvement: a repeated correction can become a lint rule, a confusing handoff can become a better review view, and a slow check can become a focused build or test run. Compilers, lint rules, and behavior tests provide repeatable checks as agents iterate. Measure again after each improvement to see whether it actually helped.

I keep several reusable tools in Pitcrew on GitHub: local review, Swift repository checks, dedicated worktree simulators, and shared development sessions. They are examples of improvements made for my own workflow, available to use or adapt independently.

Vibe Coding Your Productivity Tools Is Fine

Thirteen rules for building useful tools with clear inputs and results, short feedback loops, and enough hygiene to keep them under control.

Further iOS examples cover tooling feedback time, worktree simulators and shared authentication, and Tuist module-cache workflows.

Start with a real task, notice one recurring obstacle, and improve it. The result should be useful software at a quality you can stand behind, and a better way to build the next thing.