Atlassian Says AI Use Rose 65% but Developer Velocity Only 15%: What AI Consulting Firms Get Wrong About Workflow Automation

Atlassian’s finding suggests that increasing AI activity does not automatically accelerate delivery.

For Sydney and NSW organisations, the practical risk is paying consultants to automate isolated tasks while approvals, data gaps, handovers and rework continue to control the end-to-end result.

Effective workflow automation starts with the operating system around the task, then measures completed outcomes, cycle time, exceptions and quality—not prompts, licences or generated output.

The most revealing figure in Atlassian’s latest discussion of AI-native software development is not the increase in AI adoption. It is the much smaller change in completed delivery.

In a longitudinal study conducted with developer intelligence platform DX, Atlassian reported that AI use increased by 65 per cent , while developer velocity topped out at a 15 per cent improvement. Many organisations were reportedly closer to 10 per cent.

That difference matters well beyond software engineering. It captures a problem appearing across Sydney professional services, property operations, construction administration, finance teams and growing service businesses.

AI can produce a document, summary, estimate, response or block of code faster, but the business may still be waiting for somebody to verify the information, approve the next step, resolve an exception or coordinate the physical work.

The productivity ceiling is often not inside the AI model. It is inside the workflow surrounding it.

Faster Production Is Not the Same as Faster Delivery Many AI consulting proposals focus on the visible task. The consultant identifies a repetitive activity, connects an AI model and demonstrates that the activity can be completed in seconds rather than minutes.

The demonstration may be technically successful while leaving the operating result almost unchanged.

A drafting assistant, for example, may reduce the time required to prepare a quotation from 25 minutes to three minutes. That does not mean the quotation reaches the customer 22 minutes earlier.

It may still wait for site measurements, pricing confirmation, project-manager review, product availability, strata conditions or scheduling approval.

The distinction is between task efficiency and flow efficiency .

Task efficiency: Measures how quickly one activity is performed. Flow efficiency: Measures how quickly work moves from request to completed business outcome. Operational value: Depends primarily on flow efficiency. A task that takes five minutes but then waits two days for approval is not a five-minute workflow. It is a two-day workflow with five minutes of productive work inside it.

The Automation Metrics That Create a False Sense of Progress AI adoption statistics can be useful, but they become misleading when treated as evidence of operational improvement.

Logins, generated documents, automated actions and token consumption show activity. They do not prove that customers, projects or transactions moved faster.

Number of employees using AI What it actually shows: Adoption and access. What the business should also measure: Completed work per person and end-to-end cycle time. Number of AI-generated outputs What it actually shows: Production volume. What the business should also measure: Acceptance rate, rework and downstream completion. Minutes saved on one task What it actually shows: Local task efficiency. What the business should also measure: Total elapsed time from request to outcome. Automated steps executed What it actually shows: System activity. What the business should also measure: Exception rate and human intervention required. Software licences activated What it actually shows: Procurement and deployment. What the business should also measure: Commercial return, service quality and customer impact. AI usage cost What it actually shows: Technology consumption. What the business should also measure: Cost per approved, completed and commercially useful outcome. An organisation can therefore report strong AI adoption while carrying the same backlog, the same approval delays and the same customer response times.

This is why an AI programme should not be judged by how frequently the technology is used. It should be judged by what stopped waiting.

Four Constraints That Usually Determine the Real Result 1. Context Debt AI systems work from the context they can access. In many organisations, the information required to complete a task is scattered across emails, cloud folders, CRM records, accounting software, project boards, text messages and individual staff knowledge.

The model may generate an answer quickly, but somebody must still locate the missing site condition, client decision, previous approval or pricing rule.

Producing more output against incomplete context simply moves the delay into checking and correction.

Atlassian’s earlier developer research found that employees were saving time with AI while continuing to lose substantial time to information retrieval, fragmented tools and organisational friction. The pattern is highly relevant to non-technical operations.

2. Approval Capacity Automation increases the amount of work arriving at the next stage. When the next stage remains manual, the organisation can create a larger queue rather than a faster process.

Consider an AI system that prepares twice as many project scopes each day. If one senior estimator must review every scope, that estimator becomes the new constraint.

The organisation has increased work in progress without increasing completed work.

Approval design therefore matters as much as generation speed. Teams should determine:

Which outputs genuinely require human approval. Which low-risk outputs can proceed under defined rules. Who owns each approval category. How long an approval may remain pending. What happens when the assigned reviewer is unavailable. Which exceptions must be escalated. 3. Exception Handling Most demonstrations show the normal path. Production workflows are shaped by the exceptions.

A customer may submit an incomplete address. A property manager may request additional insurance evidence. A strata building may restrict lift access. A supplier may substitute a product. An invoice may not match the purchase order. A contract document may contain an unusual condition.

When the automation cannot identify, classify and route these cases, staff begin working around it. They create spreadsheets, send private messages and manually repair records.

The formal system then shows a clean process while the real process moves elsewhere.

4. Acceptance Quality An output is not valuable merely because it exists. It must be accurate enough, complete enough and appropriately structured for the next person or system to use without unnecessary repair.

AI-generated work should therefore be assessed through:

First-pass acceptance rate. Average correction time. Material error rate. Number of review cycles. Downstream rejection rate. Customer or operational outcome. A system that drafts 100 items but requires extensive rewriting may produce less value than a controlled system that drafts 40 items with a high first-pass acceptance rate.

What the Productivity Gap Looks Like in Sydney Project Operations The same 65-to-15 problem can appear in a property or renovation workflow even when no software development is involved.

A Sydney flooring or renovation business might use AI to classify an enquiry, summarise photographs, prepare a preliminary scope and draft a customer response.

Those activities may be completed almost instantly. The project still cannot proceed until the organisation confirms:

The correct property and access details. Whether the building is subject to strata requirements. The existing floor build-up and likely removal method. Power, lift, parking and waste-movement arrangements. Whether hazardous or restricted materials require further investigation. Labour, equipment and material availability. The person authorised to approve scope changes. The sequence between demolition, preparation, levelling and installation. If those dependencies remain outside the automation, the business may respond faster without being able to book, price or deliver the work faster.

The better approach is to connect the enquiry to a controlled operational pathway.

Elyment’s workflow automation for Sydney operations teams focuses on routing, approvals, reporting and system handovers rather than treating the first generated response as the finished outcome.

The Workflow Should Be Measured at Five Levels Organisations assessing an automation proposal should require measurement across the complete operating chain.

Activity Core question: Is the system being used? Example measures: Active users, executions and generated outputs. Task Core question: Did the individual activity become faster? Example measures: Handling time, labour minutes and completion volume. Workflow Core question: Did work move through the complete process faster? Example measures: Cycle time, queue time, handoff delay and backlog. Quality Core question: Was the output accepted and usable? Example measures: Error rate, rework, approval cycles and exceptions. Business outcome Core question: Did the organisation obtain a better result? Example measures: Bookings, revenue, margin, customer response and project completion. Most weak AI business cases stop at activity or task measurement. Strong programmes continue through workflow, quality and commercial impact.

This also changes how return on investment should be calculated.

Elyment’s analysis of the cost of a successfully completed automated task examines why retries and failures must be included.

The Atlassian finding adds another layer: even a successfully completed task may deliver limited value when the wider process remains constrained.

A Better Method for Designing Workflow Automation A credible AI consulting engagement should begin with operating evidence rather than a predetermined product.

Define the unit of business value. Identify the completed outcome that matters, such as a qualified booking, approved quotation, resolved service request, completed review or reconciled payment. Map the current workflow. Record every handoff, system, approval, waiting period, exception and manual workaround from the initial request to completion. Establish the baseline. Measure current cycle time, work in progress, error rate, rework, labour effort and completion volume before introducing AI. Identify the controlling constraint. Determine which queue, approval, missing information or capacity limit governs overall throughput. Redesign the process before automating it. Remove unnecessary approvals, clarify decision rights, standardise inputs and define exception routes. Build the smallest complete loop. Automate an end-to-end segment that produces a usable outcome, rather than deploying disconnected assistants across multiple tools. Measure accepted outcomes in production. Compare the new cycle time, backlog, exception rate, quality and commercial result with the original baseline. This approach is closer to end-to-end business process automation than installing an AI feature inside one existing application.

It requires process design, technical integration, operational ownership and measured handover.

Governance Cannot Be Added After the Workflow Accelerates Faster production can increase operational and compliance exposure when controls are not redesigned at the same time.

The Australian Government’s Guidance for AI Adoption encourages organisations to establish accountable governance, risk management and lifecycle oversight.

The Office of the Australian Information Commissioner also advises organisations to assess privacy obligations when commercially available AI products process personal information.

For private Sydney businesses, the NSW AI Assessment Framework is not generally a mandatory private-sector framework. It can nevertheless provide a useful reference point for structured risk assessment, transparency, accountability and human oversight.

NSW Government agencies have separate mandatory requirements for registering and assessing relevant AI use cases.

Where AI agents can take actions across email, documents, finance platforms, customer records or operational systems, the Australian Signals Directorate’s guidance on the careful adoption of agentic AI services reinforces the need for controlled permissions, monitoring and risk assessment.

Practical controls should include:

Role-based access to source systems and customer information. Approved data categories for each AI function. Human review for material, financial, legal or safety-critical actions. Logs showing what the system accessed and changed. Fallback procedures when an integration or model is unavailable. Version control for prompts, rules and knowledge sources. Regular quality testing against real production cases. A named operational owner after the consultant leaves. Governance should not merely slow the workflow with another approval. It should define which work can move automatically and which work genuinely requires judgement.

What Buyers Should Require From an AI Consulting Firm The strongest protection against an underperforming automation project is a scope tied to operational evidence.

Before appointing a consultant, the organisation should expect written answers to the following questions:

What complete business outcome will improve? What is the current baseline for that outcome? Where does work currently wait? Which approvals will remain and why? How will exceptions be identified and assigned? What percentage of outputs must pass without rework? Which systems and knowledge sources will provide context? What happens when the AI is uncertain or unavailable? Who will own monitoring, corrections and future changes? How will commercial value be reported after launch? Warning signs include proposals dominated by model names, agent counts, licences or demonstrations without a current-state process map.

Another warning sign is a promise to automate an entire department without identifying the specific unit of work, approval structure or exception profile.

A proper Sydney AI consulting and implementation review should reveal where AI belongs, where deterministic rules are more reliable and where the process must be repaired before either technology is introduced.

The Commercial Lesson From Atlassian’s 65-to-15 Gap Atlassian’s figures do not show that AI has failed. They show that technology adoption and organisational throughput are different variables.

AI can accelerate drafting, coding, classification, research and administration.

The resulting gain will remain limited when work is constrained by unclear requirements, scattered context, review queues, unmanaged exceptions or weak coordination.

For Sydney organisations, the more useful question is therefore not how much AI staff are using. It is whether enquiries are being resolved, quotations approved, projects booked, risks controlled and customer commitments completed with less delay and less rework.

The best workflow automation does not simply make one worker faster. It changes how the complete organisation moves.

Measure the Completed Outcome, Not the Automated Activity Review process constraints, approval capacity, exception handling, system integration, governance and commercial measurement before expanding your organisation’s AI investment.

Request an Operational Project Review

Sources and References Atlassian: AI use increased by 65 per cent while developer velocity improved by no more than 15 per cent Australian Government: Guidance for AI Adoption Digital NSW: NSW AI Assessment Framework Australian Signals Directorate: Careful adoption of agentic AI services Elyment: Workflow automation for Sydney operations teams Elyment: Cost of a successfully completed automated task Elyment: End-to-end business process automation Elyment: Sydney AI consulting and implementation review Elyment: Operational Project Review