RPG character miniatures with different equipment, in two rows on a table.
Editorial illustration.

One person calls their agent a reviewer. Another calls theirs a warrior. A third assembles an entire party: the wizard explores possibilities, the cleric looks after continuity, the ranger looks for clues.

The work is software development. The way they think about it is their own.

Why would it be necessary to swap the wizard for an office job title for the tool to agree to collaborate?

Each person builds their own party

Some people think in lists. Some think in maps, conversations, characters, or stories. An analogy can help you remember responsibilities, organize ideas, and give meaning to the work.

Choosing that repertoire is part of using the software. The tool should make room for it. If a company blocks a task only because the chosen organization doesn't fit its philosophy, a vendor preference has become a rule about someone else's work.

This is the critique: each person should be able to develop in their own way and choose how to use the tool in their own work.

Adaptation is part of use

In human-computer interaction research, Paul Dourish describes appropriation: people adopt and adapt technologies to their practices, including using them for purposes beyond those initially imagined. System design can support or hinder that process. Customizing how you work is part of the relationship between person and tool. Read Dourish's study.

Another foundation comes from self-determination theory. Ryan and Deci discuss how environments that support autonomy and competence foster motivation, while controlling conditions can undermine it. The study does not evaluate AI agents, nor does it establish an unrestricted legal right of use; it offers a basis for asking how much control a product imposes on the person working with it. Read Ryan and Deci’s article.

These works support valuing autonomy and adaptation. Our editorial position is that an unusual way of organizing development does not, by itself, justify a block. A restriction needs a concrete, explainable reason that can be questioned.

The vendor may present one path. The person using it may choose another.

The wizard remains a wizard. The task remains a task. And the one doing the work remains the person.

If you have ever had to abandon a way of thinking in order to use a tool, share that experience through the post’s private story form. What did you want to do — and what did you have to change in order to do it?

Sources and further reading