dooopPillar page · 14 min

AI in Software Development: Process and Learning

AI should accelerate the right cycle: clear hypotheses, controlled delivery, measurement, and decisions that turn real use into learning.

Published on September 6, 2026

CENTRAL THESIS

AI accelerates the cycle but also accelerates bad questions. The gain appears when delivery becomes learning.

Connect engineering, product, and decision. Use AI to shorten cycles without outsourcing judgment.

Artificial intelligence in software development should not be treated merely as a faster way to produce code. The relevant decision is to redesign the cycle so that each delivery also generates product learning: clear hypothesis, construction, controlled exposure, measurement, decision, and review. When this connection does not exist, AI can accelerate exactly what the company still does not know if it should be building.

Why delivering more software does not mean learning more

Every software company knows the scene. The sprint ends, the demo works, the team shows new screens and completed integrations. In the next meeting, however, the question returns almost intact: did the product become more suitable to the real customer behavior or did it just receive more functionality?

This difference seems simple but changes management. Development capacity is the ability to transform decisions into operating software. Learning capacity is the ability to transform usage, friction, adoption, and feedback into better decisions. An organization can improve the first and remain weak in the second.

Artificial intelligence makes this tension more visible. If it helps generate alternatives, summarize requirements, review code, create tests, or analyze signals, the production queue can move faster. But speed without product questioning only shortens the path to a poorly formulated decision.

The presentation of the DORA 2025 report describes AI as an amplifier of existing organizational strengths and weaknesses and highlights the relevance of the organizational system for return on investment. This reading is useful precisely because it takes the conversation away from enchantment with the tool. The problem is not asking only what AI does. The problem is not asking which system it is amplifying.

If the backlog is a collection of requests without hypotheses, AI can accelerate requests. If quality depends on late review, AI can increase the volume to review. If product metrics do not influence the roadmap, better analyses can become better reports, not better decisions.

For software leadership, the practical question is this: which parts of the cycle need to gain speed, which need to gain decision quality, and which need to preserve human judgment before scaling automation?

Where AI fits in the cycle: idea, code, test, operation, and decision

AI in software development is often discussed from engineering’s perspective. This is understandable because code is a visible area of application. But the complete cycle starts before code and continues after deployment.

In the idea phase, AI can support interview synthesis, grouping pains, comparing recurring requests, and generating solution alternatives. The risk is confusing a well-written synthesis with sufficient evidence. A good approach is to require that each synthesis generates a testable hypothesis, not just a list of features.

In the definition phase, AI can transform a hypothesis into acceptance criteria, use scenarios, product questions, and implementation risks. Still, the decision about priority needs to consider strategy, positioning, team capacity, and opportunity cost. To organize this type of choice, it is worth connecting the topic to a business-connected artificial intelligence strategy, not just a list of tools.

In the construction phase, AI can assist programmers in code generation, refactoring, documentation, and explanation of existing snippets. Here, the rule should not be to romanticize or demonize. The point is to define where AI suggestions can enter, which patterns they need to respect, and what type of review remains mandatory.

In the testing phase, AI can suggest scenarios, expand coverage, review error messages, and help find inconsistencies between requirements and implementation. This does not eliminate engineering’s responsibility for quality. In some contexts, it may even require more explicit criteria because producing variations becomes cheaper.

In the operation phase, AI can help classify tickets, summarize incidents, identify friction patterns, and organize usage signals. The risk is turning superficial correlation into product decision. A group of users complaining about a flow can reveal an interface problem, misaligned commercial expectation, onboarding failure, or inappropriate audience.

In the decision phase, AI can recommend paths, compare evidence, and make tradeoffs explicit. But recommendation is not authorization. Decisions affecting price, access, data, critical experience, or customer commitment need a clear owner.

The question before the tool: what learning does the product need to generate

Before deciding where to use AI, the team needs to write what it expects to learn. This discipline seems slow but reduces rework in code, analysis, and prioritization. The minimal formulation of a product hypothesis should say: if we change something for a certain user profile, we expect to observe a certain behavior because we believe a certain obstacle will be reduced.

It is not necessary to turn everything into a sophisticated experiment. Nor is it necessary to have a proprietary AI model to have maturity. Mature products can integrate third-party models, simple automations, analysis tools, and human review. Maturity lies less in the type of model and more in the quality of the decision cycle.

A useful hypothesis has four components:

a recognizable audience or segment;
an observable behavior;
a specific change in the product or process;
a pre-agreed decision before measurement.

The most neglected part is the last. If the team does not know what it will do when the signal improves, worsens, or is inconclusive, measurement becomes decoration. It informs but does not govern.

This care also avoids a common mistake: asking AI to resolve ambiguity that leadership has not faced. When priority is undefined, when the ideal customer is unclear, or when the metric has no owner, AI can organize the conversation but should not pretend it decided.

AI maturity appears at this point. Not as an abstract certification, but as the ability to choose the appropriate level of use, measure consequences, and adjust the process. In some steps, assistance is enough. In others, a bounded automation is safe. In decisions with high risk or low reversibility, the best design may be to keep AI as support for human judgment.

Criteria to choose between assistance, automation, and human judgment

The question is not whether AI should enter development. The question is what role it should assume in each decision.

Assistance is when AI helps a person produce, review, compare, or think. The human remains responsible for the decision and the outcome. This level is appropriate when there is ambiguity, relevant business context, frequent exceptions, or impact difficult to reverse.

Bounded automation is when AI executes a task with relatively clear input, output, and acceptance rules. It can classify, summarize, suggest test cases, fill documentation, or trigger simple flows. This level requires monitoring, error criteria, and rollback paths.

Decision recommendation is when AI organizes evidence and proposes a path, but authorization remains with a defined person or forum. This use can be valuable when there are many dispersed signals but the decision requires weighing strategy, customer trust, and operational risk.

Some criteria help choose:

Risk: what damage occurs if AI errs?
Reversibility: can the change be undone without affecting many users?
Rule clarity: is there an objective criterion to accept or reject the output?
Error cost: does the error generate internal rework or direct customer impact?
Context need: does the decision depend on tacit, commercial, or strategic information?
Available evidence: are there sufficient data, examples, and history to guide the task?

The distinction between workflows and agents also helps avoid confusion. Anthropic differentiates workflows, where models and tools follow predefined paths, from agents, where the model dynamically decides its process and tool use. The same article recommends starting with the simplest solution and adding complexity when necessary.

This matters for product. A workflow may be suitable for a predictable process, such as reviewing acceptance criteria against an internal policy. An agent may make sense when the task requires decomposing unforeseen paths, consulting tools, and adapting the plan. Neither alone replaces the organizational learning cycle.

There is also no automatic virtue in using more autonomy. Autonomy increases the need for limits, traceability, and interruption criteria. If the organization cannot explain when AI should stop, ask for help, or escalate a decision, it has not yet designed the process.

How to connect experimentation to development with AI

Experimenting is not launching variations at random. It is organizing a decision under uncertainty. In development with AI, this definition becomes even more relevant because the cost of generating options may fall, but the cost of misinterpreting signals remains.

Microsoft Research describes ExP as a platform to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products. The takeaway here is simple: when experimentation enters the development cycle, learning no longer depends only on a later presentation.

In a digital product, a change can be treated as delivery or as a question. As delivery, it is complete when it passes technical criteria. As a question, it only ends when the team decides what it learned and what changes in the roadmap, onboarding, support, documentation, or next version.

AI can support this connection on several fronts. It can help transform a hypothesis into measurement events. It can suggest segments to observe. It can summarize qualitative feedback. It can compare expected and observed behavior. It can point out contradictions between the feature promise and real use.

But there is a limit: user feedback does not automatically retrain a model nor automatically improve the product. Someone needs to decide what will be incorporated, discarded, investigated, or kept under observation. Learning is not accumulating signals. Learning is changing a decision because of evaluated signals.

This reasoning connects to an AI roadmap because it avoids loose initiatives. Instead of choosing use cases just by enthusiasm, leadership can map where AI reduces wait, where it improves analysis quality, and where it creates new governance risks.

The central point is to design smaller and more readable cycles. A limited change, with a clear hypothesis, acceptance criteria, controlled exposure, and planned decision, teaches more than a large delivery without a learning mechanism.

Fictional example: a feature that delivers code and learning

Imagine a fictional B2B software company selling a project management platform for service teams. The team notices abandonment during onboarding, especially at the step where the user needs to create their first project and invite colleagues.

The initial demand could become a generic feature: create an AI onboarding assistant. It seems attractive but is still too broad. Leadership reframes it as a hypothesis: new users abandon this step because they do not know which initial project structure to choose. If the product suggests project templates based on a few answers, some of these users may advance with less friction.

The AI application is limited. Instead of allowing the model to freely alter the experience, the team uses AI to generate template alternatives, summarize patterns in previous feedback, and suggest micro-guidance texts. Engineering implements a controlled variation of the flow. Product defines acceptance criteria. Design reviews clarity. Support validates that promises do not create expectations the platform does not yet fulfill.

Observable signals are defined before launch. The team monitors if eligible users reach the first project creation, if they invite colleagues, if they edit the suggested template, and if they contact support due to confusion in the flow. These signals are not treated as automatic proof of success. They serve to guide a decision.

There is also a stop rule. If recurring confusion appears in tickets, if users create incomplete projects by following inadequate suggestions, or if the template suggestion hides choices relevant to the customer, the change must be reviewed before wider exposure.

The human role is explicit. AI suggests templates and texts. Product decides which hypotheses will be tested. Engineering decides architecture and technical limits. Design decides experience clarity. Support brings qualitative signals. Leadership decides if learning justifies adjusting the roadmap, simplifying onboarding without AI, or keeping the feature only for specific segments.

Nothing in this example presumes the outcome. The value is in designing the question. The company is not just delivering an assistant. It is testing if contextual guidance reduces friction in a specific product step.

Checklist for coupling development and learning

This checklist serves to review an initiative before requesting more code, more automation, or more autonomy for AI.

Explicit hypothesis: does the initiative state what the team expects to learn? If the hypothesis cannot fit into a verifiable sentence, AI tends to accelerate a poorly formulated bet.
Observable signal: is there a behavior, event, or result indicating if the hypothesis gained or lost strength? If the signal depends only on internal opinion, the cycle has not connected development to product learning.
Pre-agreed decision: does the team know what it will do if the signal improves, worsens, or is inconclusive? Without a decision rule, measurement becomes a report.
Risk and reversibility: can the change be limited, reversed, or reviewed before affecting many users? The lower the reversibility, the greater the presence of human review should be.
Appropriate AI role: does it accelerate a clear task, expand alternatives, review quality, or recommend a decision? If the role is unclear, the team cannot assess cost, error, responsibility, or value.
Return to process: does learning alter backlog, acceptance criteria, documentation, support, or product design? If nothing returns to the process, delivery occurred but the organization did not learn.

This checklist does not replace judgment. It creates a better conversation between product, engineering, data, support, and leadership. Maturity appears when the team blocks automation without a verifiable hypothesis or uses AI simply because the task is well defined.

What leadership must decide before scaling AI in development

Scaling AI in development without redesigning governance is replacing a slow queue with a faster queue. Leadership needs to decide where AI enters, who is responsible for the outcome, and how learning returns to the system.

The first decision is to choose workflows. Not every step needs AI at the same time. A good start is mapping bottlenecks: waiting for refinement, rework due to ambiguous requirements, low test coverage, repeated incidents, difficulty interpreting feedback, or delay converting signals into decisions.

The second decision is to choose metrics. Engineering metrics, such as cycle time and delivery quality, need to coexist with product metrics, such as adoption of a step, usage recurrence, friction reduction, or perceived quality. No single metric tells the whole story.

The third decision is to define authorization. Who approves an AI-generated suggestion? Who can change a product flow? Who stops an automation? Who answers if the recommendation seems technically correct but strategically inadequate?

The fourth decision is to preserve limits. Some tasks should remain assisted, not automated. Situations with high customer impact, low reversibility, ambiguous rules, or sensitive commercial context require human review from the design stage, not as a late correction.

The fifth decision is to organize memory. What was learned needs to return to the roadmap, documentation, support, acceptance criteria, and product design. Without this return, the organization only accumulates disconnected experiences.

AI adoption changes responsibilities, decision pace, and question quality. Therefore, the discussion is not only technical. It connects to how the company understands leadership and augmented human: people supported by better systems, with responsibility preserved in decisions that still require context.

The next meeting does not need to end with a longer list of tools. It needs to choose an initiative and record, on one page, the hypothesis, AI’s role, observable signal, decision rule, reversal limit, and authorization owner. If these items are not clear, it is not yet time to scale. If they are, development is better positioned to deliver software and learning in the same cycle.

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

Explore the six cores of development and product

Sources

NEXT DECISION

Discussing application in your company

Conversation about your software company’s context

Content by dooop. Registration allows linking this topic to the reader’s journey and tracking interest in the theme.