# Agentic product development: what changes when agents build the software > Agentic product development explained by a practicing CPTO: cycle time, lower adaptation cost and where human judgment concentrates. - Canonical: https://arkatai.com/en/agentic-product-development/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: en - Published: 2026-07-18 --- For most of my career, engineering hours constrained how much software a company could build. Roadmaps allocated that capacity and every feature competed for it. Agents reduce the cost of implementation and move the constraint toward deciding, specifying and verifying. As a Chief Product & Technology Officer, I work with that shift every day. ## What agentic development includes Treating agents as code generators keeps the existing workflow and changes one step. It also assumes that faster writing produces the same increase in shipped product. Writing code is only part of the job. Understanding the problem, deciding what to build, verifying it in production and maintaining it still require time and ownership. At the same time, a lower implementation cost changes more than output volume. Teams can restructure planning and experimentation around shorter build cycles, just as cheaper compute enabled different software architectures. In an agentic workflow, agents explore a codebase, propose an implementation, write it, run tests and help operate what was deployed by watching logs, flagging anomalies and preparing fixes. People spend less time producing each artifact and more time directing and verifying the work. ## Cycle time changes the decision process The first metric to move is cycle time: the distance between a decision and production. When implementation is no longer the main bottleneck, some ideas that waited a quarter can be tested in a week. Track that interval from an approved decision to a deployed and verified change. Counting code generation alone removes review, testing and release from the metric and overstates the improvement. This increases output and changes the economics of experiments. When a test costs six engineer-weeks, teams reserve it for ideas with high prior confidence. When it costs two days of directed work, more uncertainty can be resolved by testing. The roadmap can include explicit stop conditions instead of treating every item as a commitment. Lower production cost also allows a team to create more features that do not help users. The queue used to reject ideas through lack of capacity. When that filter weakens, teams need explicit criteria for what not to build and when to stop an experiment. ## The cost of adapting and maintaining systems is falling The same cost change affects the choice between buying a tool, building internally and contracting an operated service. For decades, companies usually bought software because company-specific systems were expensive to build and maintain. Each system required people to understand, patch and extend it for years. Adapting an internal process to a package was often cheaper than carrying that responsibility. Agents reduce part of that cost. They can inspect an unfamiliar codebase, retrieve context across the system and prepare a corrective change without all the manual discovery that used to precede it. I built an open-source framework for AI-assisted development around the need to document intent and context so both agents and people can change code under defined checks. As adaptation costs fall, software that encodes a company’s processes, exceptions and pricing logic becomes viable in more cases. The client does not have to own or maintain that platform: an operator can absorb the technical cycle as part of a managed service. That category is the subject of [the operating model as code](/en/operating-model-as-code/), and [the custom phase](/en/the-custom-phase/) explains why the deployment still requires company-specific work. This does not justify building everything. Accounting, payroll and email remain products unless the company has a specific requirement the market cannot meet. The change applies to the layer that encodes how the company operates. ## Where human judgment concentrates As agents produce and operate more software, human work concentrates in four places. People decide what to build and when to stop, define what verification means for each type of change, design permissions and review gates, and own the outcome in production. The agent does not replace the named owner. It increases the amount of work that owner can direct, so the quality of specifications and controls matters more. This changes team composition. More time goes to architecture, review and verification, and less to writing each change manually. Junior engineers can learn by reviewing agent output under supervision as well as by producing changes themselves. The same question applies beyond product development. I describe how a company plans work around people and agents in [what an AI-first organization is](/en/ai-first-organization/). Product is often an early test because software work has automated checks and versioned artifacts. ## Questions boards ask me ### Does this mean we need fewer engineers? The distribution of work changes before headcount necessarily changes. Teams may keep similar staffing and expand what they attempt, or reduce hiring later through attrition. Cutting the team before the new workflow can carry production work removes the people needed to specify and verify it. ### Is agent-written code safe to run in production? Safety depends on the verification applied before deployment, as it does for human-written code. A common failure is skipping review or tests because the change arrived quickly and looks plausible. Define required gates by risk class and apply them regardless of who produced the code. ### Should we wait until the tooling matures? Models and tools will continue to improve. The capability that must be built internally is directing, verifying and owning agent work on the company's systems. Waiting may improve the tools, but it does not create that operating experience. ### Can our existing vendor just do this for us? Vendors will use agents to improve products available to all their customers. A company-specific benefit still requires its process, rules and exceptions to be incorporated. That can be done by an internal team or by a service-as-software operator that maintains the system while delivering the operation.