AI-aided software development needs Time orientation. Not yet another framework

AI makes developers faster. But organizations can’t keep up as shoddy structures and processes stifle quality and flow

AI coding tools are fundamentally changing how software gets written. The AI revolution has arrived, and it is here to stay. But research around AI in software development clearly indicates that the results are disappointing: More code, but barely more delivered software. So what is happening, and how can we reap the full benefits of AI?

A pattern is showing up across research studies: AI accelerates individual code production, as it helps to generate more code fast, but left unchecked, it is also less thoughtful code. Copy-paste instead of modularity. Technical debt is growing faster than ever before. While individual productivity rises, team-level delivery speed and quality stay flat.

The bottleneck in product development and software engineering just shifts elsewhere, a study concludes. Research consistently shows that to improve system-level delivery with AI-aided development, structural change to how work is conceptualized, bounded, and reviewed is also required. Time-Oriented Software Development, TOSD, provides exactly that structure: In this article, we will discuss how TOSD’s OK Point becomes the essential quality gate in an AI-accelerated world, and how the 1 to 3-day time-box provides the natural boundary that keeps AI outputs small, reviewable, and deployable.

With AI, the bottleneck in software development shifted from typing to thinking

AI assistants like Copilot, Cursor, or Claude Code make writing code dramatically faster. But research consistently shows this speed rarely translates into faster delivery at the team or organizational level. The bottleneck has simply moved: the problem is no longer typing, it’s knowing precisely what to build before you start.

A landmark 2025 study by Faros AI, analyzing telemetry from over 10,000 developers across 1,255 teams, found that while AI-augmented developers write significantly more code, organizations see no measurable improvement in delivery velocity or business outcomes. The bottleneck transfers downstream — into code review, QA, and integration.

TOSD offers several game-changing features for advocates of AI. Here are five ways in which TOSD will save your day in this new age of software engineering.

1) The OK Point: antidote to AI-induced chaos

This is exactly where TOSD’s OK Point becomes critical. It enforces that a clean, written concept exists before anyone starts coding — whether with AI assistance or without. No vague user stories. No endless backlogs. No assumptions baked into a prompt. Just a precise description of the What, clear enough to determine whether the realization takes 1, 2, or 3 days.

Conceptualization done well also produces better AI outputs. Clearly scoped, well-described tasks result in more reliable AI-generated code with fewer hallucinations and less rework. The OK Point ensures that the speed of AI coding is channeled into the right work — not just any work, faster. Opt for a structure in time that’s governed by an OK Point_, or you are, in effect, opting for shoddy process.

2) Small items are AI’s sweet spot. TOSD enforces them

AI tools perform best on small, self-contained, well-described tasks. TOSD’s 1–3 day time-boxes structurally enforce exactly that. Larger items must be broken down before reaching the OK Point — which also means less AI-generated code sprawl, less duplication, and more manageable reviews.

Breaking the work down into small items is always possible, argues Ron Jeffries, and there is hardly an argument to be made about 1-day items, especially considering the power of today’s AI development tools.

3) Flow state: the productivity multiplier AI can’t replace

Research by Gloria Mark at UC Irvine found it takes an average of 23 minutes to fully regain deep focus after an interruption. Sprint ceremonies, stand-ups, and planning rituals destroy this repeatedly throughout the day. TOSD’s structure — time-fixed, concept-first, TTEO when needed — protects the conditions for personal flow: clear goals, bounded scope, minimal ceremony.​​

4) Self-organization instead of AI-induced bureaucracy

​​Many organizations respond to AI adoption with tighter control and more oversight layers. TOSD offers the opposite: structure through time, not hierarchy. The result is more flow, more autonomy, more ownership, and more joy — alongside the speed that AI can genuinely contribute.

In TOSD, disciplined self-organization emerges from the combination of three different kinds of restrictions. It’s a combination that’s unique among approaches to software development:

1. At any point of time, work is handled by individuals or pairs. Not development teams or “roles” that are detached from the work. Responsibility is clearly and transparently attached to one or two people who perform the work.

2. Work is consistently time-boxed to 1, 2 or 3 days. This ensures short learning circles and fast feedback, provides the highest level of transparency, combined, somewhat counter-intuitively, with liberty: In TOSD, the work days of developers are not controlled, detailed allocation of work hours is discouraged. Estimation, forecasting and scheduling become entirely dispensable, which is good for developers and good for overhead reduction.

3. The scope of work is always clear: For Conceptualizers, it is The List that sets the scope, for Realizers, the concept taken over at the OK Point creates boundaries to scope. In addition, the TTEO principle ensures that consultation happens when needed - not some time later, or during some sort of scheduled ritual.

5) TOSD’s nuanced structure favors nuanced use of AI

Lastly, TOSD acknowledges that List curation, Conceptualization and Realization require different types of AI support. They constitute rather different AI use cases, which will often favor use of different types of AI, and different styles of working.

• List curation and Conceptualization are geared towards deliberate discovery: wide-ranging research, information gathering, architectural considerations and, of course, concept-writing. Which isn’t everybody’s cup of tea - with or without AI.

• Realization is more about disciplined creation, requiring a focus on code generation, reviewing and testing code.

To be sure: In TOSD, Conceptualization and Realization both require creativity, but of a different nature. Both should be time-boxed, and Realization must be time-boxed.

The challenge: Overcome popular, yet outdated beliefs

The AI-induced renaissance of software development requires turning away from a bunch of beliefs that are cherished in Project Management and Agile circles alike. It is the need for new paradigms that makes the current development upheaval so challenging, beyond the need of developers to develop mastery in the use of AI. “From the perspective of the Old, the New is always wrong”, said the great Ernst Weichselbaum. Turning your mental models around, collectively, requires chosen agency, and also suitable learning method (“didactics”). As I have outlined in several earlier articles on this web mag, Time orientation in product engineering means that we have to overcome a bunch of strongly ingrained, but profoundly flawed beliefs:

1. Belief in Sprints, cadences or iterations – which constitute impediments to flow.

2. Belief in the utility of roles that are compartmentalizing and bureaucracy-inducing. Which includes, but isn’t restricted to roles like Scrum Master, PO, Agile Coach, Product Manager and Head of Product.

3. Belief in capacity/volume/scale/utilization orientation. In complex contexts, this philosophy of work organizing, also known as batch processing is bound to fail: Plus: it creates walls between developers, inhibiting self-organization, self-actualization and effectiveness.

4. Belief in the supposed choice between organizing developers into either departments or ‘integrated‘ development teams. Development teams are hardly better than silos, as they create yet another set of impediments to flow and performance.

In 2010, Daniel Terhorst North introduced the notion that ignorance-reduction or thinking is the ultimate constraint in software development: Learning is the constraint, ignorance the biggest impediment to throughput. This isn’t changing with the intense use of AI in development. Overall, it is safe to say that AI-aided development will make critical thinking and generating ideas more, not less important. And as stunning as AI tools have become, machines don’t have ideas.

The solution lies not in making AI better and better: AI assistants and tools are quite fabulous already. The Economist argues that there is “a deeper flaw in the argument that AI is powering a productivity boom. Such improvements are usually made not just when workers use a new tool more often, but when firms reorganize production around it. Early factories became only a little more efficient when steam engines were replaced with electric motors; the real revolution came decades later after floor plans were redesigned to make the most of electric power.” The solution to derive higher productivity from AI agents lies in surrounding AI-aided developers with socio-technical systems that match the nature of software development, and the complexity at work in tech.

The organizational rewiring of software development has barely begun.
AI breakthrough without Time orientation? Isn’t likely.

---

---

More stuff on Time orientation and TOSD

Visit the TOSD web page, read my other articles about Time orientation on this Substack and download the TOSD research paper

Watch videos about Time orientation and TOSD

Participate in an upcoming TOSD conference – events in Germany, Argentina, Colombia, Costa Rica, Mexico are coming up! Or organize a TOSD conference yourself – supported by the TOSD Team.