dooopPillar page · 18 min

How to Prepare a Software Company to Use AI

Before scaling AI in software, assess competencies, decisions, and evidence to build capacity without hiding risks.

Published on September 6, 2026

CENTRAL THESIS

AI amplifies the system it finds. Readiness depends on decisions, boundaries, and evidence, not just access to tools.

Map competencies, classify uses, and record signs of capacity before scaling AI in software.

In many software companies, AI has already entered through the daily use of the team before there was a clear readiness design. AI adoption in software teams needs to organize which competencies are distributed, which decisions can be assisted, and which evidence shows real capacity increase. Without this, the company may gain speed in specific tasks while losing clarity about risk, quality, and responsibility.

Why AI adoption needs to start with the company’s capacity

The scene is already common in software companies: part of the team uses AI to write tests, summarize tickets, explain code snippets, compare technical alternatives, or speed up documentation drafts. Some people seem more productive. Others use it little. Leadership notices movement but cannot answer three simple questions: which decisions improved, which risks increased, and what evidence shows the team’s capacity became stronger.

From there, leadership needs to evaluate the work system, not just the tool.

AI does not operate in a vacuum. It depends on the quality of the problem formulated, the context provided, human review, available documentation, clarity of responsibility, and the maturity with which the organization learns from errors and successes. The DORA 2025 report describes AI as an amplifier of existing organizational strengths and weaknesses and highlights the importance of the organizational system for return on investment. This does not mean AI guarantees productivity. It means leadership must look at the environment where the technology will be used.

A company with confused decisions, fragile documentation, and low learning discipline tends to use AI to accelerate ambiguities. A company with good engineering, product, and operation practices is better positioned to use AI to investigate, compare options, and support lower-judgment tasks, provided human responsibility is preserved where necessary.

Preparing the company, therefore, is not about choosing the vendor first. It is about organizing three layers before scaling use:

Minimum competencies distributed across the system, not concentrated in enthusiasts.
Decisions classified by risk, impact, reversibility, and responsibility.
Observable evidence of capacity, not just reports of speed.

This reading complements broader discussions on business-connected artificial intelligence strategy and AI maturity. Here, the focus is more specific: how software leadership decides if the organization is ready to scale AI use in engineering, product, and operation.

Before choosing the tool, leadership needs to answer: “what capacity needs to exist so that tool use improves decisions without hiding risks?”

Which competencies need to exist before scaling AI use

Organizational readiness for AI begins when the company stops treating competence as an isolated individual skill. Having some people very good at prompts can help, but it is not enough. In software, capacity needs to appear in the team’s shared practices: how problems are formulated, how responses are reviewed, how decisions are documented, and how errors become learning.

The first competency is formulating good problems. AI responds better when given objectives, context, constraints, and evaluation criteria. In a software team, this means turning vague requests into operable questions. “Improve this flow” is weak. “Compare three alternatives to reduce friction in this registration, considering impact on recurring users, engineering effort, and support risks” already guides a more useful investigation.

The second competency is reviewing outputs. Reviewing is not just looking for obvious errors. It is comparing the response with product context, existing architecture, user experience, safety limits, and team standards. The more sensitive the decision, the greater the weight of human judgment.

The third competency is protecting sensitive context. Software teams deal with code, incidents, customer data, product strategies, and internal information. The company needs to define what can be shared, in which environment, with what level of anonymization, and under which authorization. The absence of rules often becomes informal permission.

The fourth competency is documenting decisions. If AI helped compare alternatives, generate hypotheses, or produce a technical draft, the final decision needs a human record: which option was chosen, why, with what assumptions, and which risks were accepted. Without this record, the organization does not learn. It only accumulates interactions.

The fifth competency is testing hypotheses. AI can suggest paths, but suggestion is not evidence. A product improvement, an architecture change, or a new operational flow needs to be treated as a hypothesis when its effect is still uncertain. Leadership must demand clarity about what will be observed before scaling a practice.

The sixth competency is recognizing when not to automate. This may be the most underestimated. Not all repetitive work should be automated. Some tasks carry judgment, responsibility, political context, or user impact that do not appear in the technical statement. In others, the cost of reviewing a bad automation may be greater than executing manually with judgment.

These competencies do not need to be equally deep in all people. But they need to exist in a distributed way. Product, engineering, data, quality, and operation must be able to discuss AI use without depending on a person who “understands the tool.” Otherwise, the company does not have organizational capacity in software. It has islands of skill.

A good sign of readiness is when the team can explain not only how AI was used but why it was used, which alternative was discarded, who reviewed it, and what evidence supported the next decision.

Which decisions can be supported by AI and which should remain human

Responsible AI use in software depends on a simple distinction: supporting a decision is not making the decision. AI can investigate, summarize, compare, simulate arguments, generate drafts, and point out inconsistencies. But the organization needs to define who authorizes relevant changes, especially when there is impact on users, architecture, security, operation, or reputation.

A practical criterion is to classify decisions by four dimensions.

The first is reversibility. An easily reversible decision, such as suggesting alternative names for an internal function or drafting a release message, can accept broader AI use, provided there is proportional review. A difficult-to-reverse decision, such as changing a core architecture component, requires more context, debate, and explicit responsibility.

The second is user impact. The greater the chance of affecting experience, access, trust, privacy, or support, the less autonomy should be granted to AI. It can help map scenarios and anticipate effects, but the decision must remain assigned to a person or defined forum.

The third is context dependency. Some decisions seem technical but depend on product history, previous incidents, client agreements, commercial constraints, or architecture decisions that are not well documented. In these cases, a plausible AI response can be dangerous precisely because it seems complete.

The fourth is the need for explicit responsibility. If a decision requires someone to be accountable afterward, AI cannot occupy that place. It does not attend post-incident meetings, does not sustain trade-offs before users, and does not assume organizational consequences.

This classification helps separate common uses:

Appropriate support: investigating possible causes of a bug, summarizing non-sensitive logs, comparing implementation alternatives, suggesting test cases, drafting documentation, reviewing specification clarity.
Support with caution: recommending backlog prioritization, suggesting user experience changes, interpreting incident patterns, proposing relevant refactorings.
Blocked or restricted use: approving critical changes without review, deciding product priority without human criteria, executing relevant changes without record, replacing incident analysis when documentation is incomplete.

AI governance in engineering does not need to start heavy. It needs to start visible. The team must know where AI can help freely, where review is needed, and where it should not be used as a decision-maker.

This point is especially relevant for companies that already have an AI roadmap. A roadmap with many initiatives and few defined decision rights tends to produce friction. People use AI but do not know when to ask for authorization, when to record assumptions, and when to stop automation.

A good decision design does not reduce team autonomy. It reduces ambiguity. And ambiguity is costly when a technology starts influencing code, product, and operation.

What evidence shows the team gained capacity, not just speed

Speed is incomplete evidence. A person can write more code, generate more tests, or respond to tickets faster without the organization improving its capacity to deliver reliable software. The question is: is the team deciding better, learning faster, and reducing dependence on tacit knowledge?

Weak signals are easy to find. Enthusiasm with the tool. Increased use. Convincing demonstrations. Reports of time savings. None of this should be discarded, but it should not be treated as sufficient proof. In AI adoption, positive perception may indicate opportunity, not consolidated capacity.

Stronger evidence appears in recorded work.

A first evidence is decision quality. Can the company find why an alternative was chosen? Can it see which options were considered? Can it understand which risks were accepted and which assumptions need revisiting? If AI participated in the analysis, this should increase traceability, not replace it with an informal prompt history.

A second evidence is findable documentation. When a new person joins the team, when someone needs to review an old decision, or when AI is used to support investigation, is the basic information clear and locatable? DORA, on its page about documentation quality, evaluates documentation by attributes such as clarity, ease of location, and reliability, and recommends active creation and maintenance. This is a practical basis for thinking about AI readiness without turning documentation into a promise of automatic return.

A third evidence is the existence of tested hypotheses. If the team uses AI to propose a product improvement, was the change treated as a verifiable bet? Was there an expected impact? Was there a condition to maintain, adjust, or stop? Without this, the company confuses idea generation with learning.

A fourth evidence is output review. Can leadership observe if AI responses were reviewed by people with sufficient context? Can it see where the team accepted, adapted, or rejected a suggestion? Review is part of capacity, not a bureaucratic step.

A fifth evidence is incident and rework analysis. When something goes wrong, does the organization identify if AI use contributed, if documentation was missing, if the decision criteria were flawed, or if the review was inadequate? Capacity increases when error improves the system, not when it becomes individual blame.

A sixth evidence is updating the criteria for use. Mature companies do not write an AI rule once and abandon it. They revise boundaries as they learn, change tools, alter products, and find new risks.

The difference between speed and capacity appears in one sentence: speed is doing more in less time; capacity is repeating good decisions in different contexts, with less dependence on improvisation.

How to use documentation as trust infrastructure for AI

Documentation is often treated as a post-work obligation. With AI, this view becomes even more fragile. If the team wants to use AI to support analysis, comparison, and drafting, it needs to feed the process with reliable context. Otherwise, the tool tends to operate on fragments, assumptions, or informal memory.

Documentation, in this sense, is trust infrastructure. Not because it eliminates error, but because it allows people and systems to find context, review decisions, and reduce ambiguity.

In a software company, documentation relevant to AI is not limited to manuals. It includes architecture decisions, product criteria, incident history, quality standards, code conventions, operation agreements, business glossary, and reasons for previous choices. AI can help summarize, reorganize, or find gaps but should not be used to mask contradictory or outdated documentation.

There are three concrete questions to evaluate this layer:

Is the information guiding decisions in a place the team actually uses?
Is the content clear enough for someone outside the immediate context to understand?
Is there someone responsible for maintaining documentation when product, architecture, or process changes?

If the answer is no, scaling AI may increase trust in fragile answers. The tool can produce convincing text from poor assumptions. The appearance of clarity does not replace context reliability.

This point connects to the discussion about leadership and augmented human. Human judgment does not enter only at the end to correct the machine. It needs to appear in the environment design: what information will be considered a reliable source, who can change it, when it should be reviewed, and how conflicts will be resolved.

A simple practice is to separate three documentation levels:

Current reference: content the team recognizes as a basis for decision.
Historical record: old decisions, incidents, and discarded alternatives that help understand context.
Assisted draft: material generated or reorganized with AI support, still dependent on human review.

This separation avoids a common mistake: treating all well-written text as operational truth. In software companies, trust does not arise from format. It arises from responsibility for content.

How to govern the evolution of AI uses

The evolution of AI uses becomes more controllable when the company distinguishes discovery, hypothesis, and experiment.

Discovery is exploration. The team investigates possible uses, observes repetitive tasks, identifies bottlenecks, and talks about real pains. At this stage, it is acceptable to open possibilities. The question is: where could AI help?

Hypothesis is a formulated bet. The team chooses a specific use and declares the effect it expects to observe. For example: “using AI to suggest test cases may improve the review of forgotten scenarios in stories with complex business rules.” This sentence does not prove anything yet. It only makes the bet discussable.

Experiment is the hypothesis subjected to planned observation. The team defines how it will compare before and after, who will review outputs, which risks will be monitored, and under what condition the practice will be adjusted or stopped. Microsoft describes its ExP experimentation platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. The applicable lesson here is experimental reasoning, not the idea that any feedback automatically retrains a model.

DORA also relates learning culture to software delivery performance and proposes treating learning as an organizational investment. For AI adoption, this suggests a posture shift: the company should not only ask who is using the tool but what the use taught about the work system.

A simple cycle can work like this:

Choose a specific task or decision, not “use AI in engineering” generically.
Formulate a testable hypothesis about quality, risk, effort, or learning.
Define who reviews the output and who authorizes the decision.
Record observable evidence, including rejections and failures.
Review the practice before scaling to other teams or critical stages.

The caution here is not to turn all adoption into a permanent lab. Software teams need to deliver. The learning cycle must fit into the workflow, not become a parallel layer that paralyzes decisions. Discipline is in choosing few relevant uses, measuring honestly, and adjusting criteria.

When the company governs the evolution of uses this way, AI ceases to be just an individual tool and begins to reveal where the process is clear, where documentation fails, where decisions depend on few people, and where leadership needs to design better boundaries.

Readiness checklist for AI adoption in software teams

The checklist below is a practical tool to decide whether the company should scale, limit, or redesign AI use in software. It does not replace technical, legal, security, or product analysis when those dimensions are relevant. Its function is to organize a leadership conversation about organizational capacity.

Minimum distributed competencies

Approved: the team knows how to formulate problems, review outputs, test hypotheses, document decisions, and identify inappropriate AI uses.

Attention: some people master use, but knowledge depends on individual initiative and does not appear in team practices.

Blocked: the company measures adoption only by tool access or usage quantity.

The criterion here is distribution. If competence disappears when a person changes teams, the organization has not yet incorporated the capacity.

Decisions classified by risk

Approved: there is a clear distinction between reversible decisions, moderate-impact decisions, and critical decisions requiring a named human responsible.

Attention: the team reviews important decisions, but the criterion depends on informal judgment of each leader.

Blocked: AI is used to recommend or execute relevant changes without record of responsible party, context, or criteria.

The point is not to prevent use. It is to prevent sensitive decisions from being ownerless.

Reliable and findable documentation

Approved: information used by the team is clear, locatable, updated, and recognized as a work reference.

Attention: there is sufficient documentation for experienced humans, but gaps hinder review, onboarding, or AI-assisted use.

Blocked: AI is used to compensate for outdated, contradictory, or nonexistent documentation.

When documentation is weak, AI can accelerate plausible answer production. Plausibility is not reliability.

Evidence of capacity

Approved: leadership monitors evidence such as decision quality, reduced rework through recorded learning, output review, and tested hypotheses.

Attention: there are positive reports but little comparable evidence between teams or delivery cycles.

Blocked: success is declared by perceived speed, without quality, risk, or learning criteria.

The question is simple: if someone asks for proof the team improved, what will be shown beyond testimonials?

Experimentation cycle

Approved: each use expansion starts from a testable hypothesis, defines expected impact, observes results, and reviews practice.

Attention: the company tests AI uses but mixes exploration, pilot, and experiment without separating objective and evidence.

Blocked: the company scales use because the demonstration was convincing, without hypothesis, metric, or stop condition.

Demonstration opens conversation. Experiment guides decision.

Explicit automation boundaries

Approved: the organization defined situations where AI can support, should not decide, or should not be used.

Attention: boundaries exist in leaders’ conversations but are not visible to those executing the work.

Blocked: absence of rules is treated as permission to automate.

Clear boundaries are not fear of technology. They are responsibility design.

Fictitious example: AI in bugs, tests, and prioritization

Imagine a software company that wants to use AI to support bug analysis, test writing, and improvement prioritization. The example is fictitious, but applying the checklist shows how the decision can be more concrete.

In test writing, use can advance as assistance if there is human review, useful coverage criteria, and record of accepted or rejected cases. The hypothesis to measure could be that AI helps recall scenarios the team tends to forget. The effect should not be presumed. It must be observed in the real review flow.

In improvement prioritization, use remains under attention if the company has not yet defined impact criteria on users, effort, risk, and responsible for the final decision. AI can summarize feedback, group themes, and raise questions. But prioritization involves product choices, commercial context, and responsibility. The decision should not be delegated to an automatic recommendation without explicit criteria.

In bug analysis, full automation is blocked if incident documentation is incomplete or hard to locate. AI can support investigation, suggest probable causes, and organize evidence. But if history is fragile, the tool may reinforce assumptions. Before automating, the company needs to improve incident records and define who validates conclusions.

This example shows the checklist’s value: the same company can approve one use, keep another under attention, and block a third. The decision ceases to be “adopt or not adopt AI” and becomes “where do we have sufficient capacity to advance, where do we need adjustment, and where is risk still poorly designed.”

Preparing a software company to work with AI is deciding what needs to be ready before scaling: distributed competencies, classified decisions, reliable documentation, evidence of capacity, experimentation cycle, and automation boundaries. The practical step is to choose a specific use, apply the checklist, and decide if it should advance, remain under attention, or be blocked for now.

If you want to discuss this decision in your company’s context, talk to dooop.