DEV Community: Vijaya Sai Munduru

Agentic Development: My Invisible Dev Team and Why Our Processes Must Adapt

Vijaya Sai Munduru — Mon, 02 Mar 2026 23:31:09 +0000

I want to be honest with you upfront: I was skeptical.
As a Lead Software Engineer, I have seen enough tools arrive with big promises and leave with modest results. Most of them made certain things faster or easier, but none of them fundamentally changed how I worked. I had learned to stay measured until something actually earned a different reaction.
I had tried GitHub Copilot back when it first came out. It was useful — good for boilerplate, decent at code suggestions — but it was not what I would call a shift in how I worked. It was autocomplete with ambition. I appreciated it, but I was not blown away.
Then I started using Cursor with Claude. And something genuinely clicked.
What I experienced was not just a faster way to write code. It was more like having two or three senior developers working alongside me, a couple of architects I could brainstorm with at any time, and a set of peer reviewers available on demand. That analogy might sound like marketing language. I mean it as a practical description of what the workflow actually feels like day to day.

So What Does Agentic Development Actually Mean?
The definition of 'agentic' remains unsettled; therefore, I will describe it through my practical experience rather than relying solely on its technical meaning.
My workflow starts with planning and not coding. I bring the AI into a brainstorming session, work through the problem together, and see what it comes up with. Then I read that plan carefully. I look for missing scenarios, incorrect assumptions, and flows that it has not accounted for. I push back, add context, and we iterate until the plan reflects what I actually want to build.
Only after this planning phase do I proceed to development. As a result, I typically produce functional code with up to 85% unit test coverage, integrated into the process rather than appended at the end.
This aspect was particularly surprising. The tests are not treated as an afterthought; the AI considers them integral to the deliverable. This shift has fundamentally altered my understanding of what constitutes a completed task.

The Part Nobody Talks About Enough: Hallucination in Planning
AI hallucination is often discussed as the model generating information without basis, such as inventing libraries or fabricating facts. In my experience, the more subtle and potentially hazardous hallucinations are less conspicuous.
Here is a real example. I was implementing a new feature flow to sit alongside an existing legacy flow. The whole point was to run the new flow behind a feature flag — so if anything went wrong in production, we could flip a switch and go back to the old behavior instantly. Simple, clean, safe.
Upon reviewing the AI-generated plan, I noticed it included logic to automatically revert to the legacy flow if a network request failed. This behavior was neither requested nor specified in the requirements. The AI inferred it, likely because such fallbacks are common patterns. However, this approach was inappropriate for the current use case, and had I not reviewed the plan beforehand, this logic would have been implemented unnoticed.
This represents the fundamental shift required by agentic development. The primary contribution is no longer code writing, but rather critically evaluating the plan, discerning the AI's assumptions, and identifying plausible yet incorrect elements. This process demands substantial domain knowledge and judgment, and is, in some respects, more cognitively demanding than manual coding.

The Real Numbers — and Where the Time Actually Goes
When all factors align, agentic development can reduce a task that previously required five days to just one. I emphasize this point because it may appear exaggerated, but it is accurate. With clear requirements, an effective plan, and optimal AI performance, the efficiency gains are substantial.
However, it is important to note that these time savings do not necessarily translate to faster delivery.
Accelerated code readiness simply reveals the next bottleneck: the review-and-merge process. My team mandates at least two reviewers per pull request and prefers to keep pull requests open for 24 hours to accommodate developers in various time zones. This is a sound practice, particularly for globally distributed teams. However, these processes were established when code writing was the primary constraint. Now that development is being expedited, the review phase appears significantly longer.
I intentionally keep my pull requests small and manageable, even though the AI can generate larger changes in a single iteration. I explicitly plan how to partition the work to ensure that no individual pull request overwhelms reviewers. This discipline is essential; without it, one risks producing extensive pull requests that are technically functional but practically unreviewable, thereby defeating the purpose of peer review.

A Question I Genuinely Do Not Have the Answer To
I am curious how many other developers encounter this pattern, where tool adoption accelerates individual productivity but existing processes become the primary obstacle.
I am eager to learn whether this is a widespread frustration. Are some teams managing it more effectively? Have any organizations restructured their review processes to align with the increased pace enabled by these tools?
These questions are posed sincerely. This appears to be a critical conversation for the industry, yet it is not sufficiently addressed.

Necessary Changes and a Potentially Unconventional Proposal
Organizations are currently under significant pressure to adopt agentic tools, as leadership is attracted by the potential productivity gains. However, if delivery processes remain unchanged, accelerating engineering output may simply introduce new frustrations, with tools prepared but workflows not.
Here is the idea I keep coming back to, and I will admit it might be too early: what if agents were part of the process? For example, an agent could analyze pull requests, identify conflicts, validate test coverage, and, under careful human supervision, assist with the merge process. The intention is not to replace human reviewers, but to support them by expediting tasks that do not require human judgment, while ensuring humans remain responsible for critical decisions. For such integration to be safe, a robust foundation is essential: comprehensive unit tests, reliable integration tests, and a trustworthy test suite. With high-quality tests, automated assistance in the review pipeline becomes significantly less risky. Tests serve as the contract, the agent acts as the validator, and humans remain the final arbiters, though not the sole gatekeepers. I do not claim this approach is immediately feasible. However, it represents a logical progression, and organizations should proactively consider it before encountering significant obstacles. They have already hit the wall.

For the Architects and Leaders Reading This
The architect's role does not diminish in this context; rather, it becomes increasingly vital. Skills such as precise problem framing, identifying flawed assumptions, decomposing complex systems into manageable components, and maintaining a clear vision of objectives remain irreplaceable by automation. change concerns time allocation: less time is spent on implementation details and more on thoughtful problem analysis prior to commencing work. In my view, this is a beneficial shift..
However, this approach is effective only if organizations combine the adoption of agentic tools with a readiness to reevaluate surrounding processes. Encouraging teams to use tools like Cursor and Claude addresses only part of the challenge; the remainder involves reconsidering delivery processes to keep pace with engineering's accelerated pace.
This question remains unresolved, yet it is arguably the most pressing issue in contemporary engineering.

I sincerely invite feedback from other engineers and architects. Are you encountering similar bottlenecks? Have you identified effective solutions? Please share your experiences, as broader participation will enrich this discussion.
— Vijay Munduru

Architecting Offline-First iOS Apps With Idle-Aware Background Sync

Vijaya Sai Munduru — Tue, 23 Dec 2025 18:22:19 +0000

Imagine a medical field sales rep walking into a hospital basement early in the morning, where the signal is weak. The app should open checklists immediately, have all reference data available, and let the rep take notes without needing a network connection.

Last night, the phone was charging and connected to Wi-Fi. The app uses this time to complete a full background sync. By morning, it is ready to use, and updates during the day are quick because only changes since the last sync are downloaded.

Offline-first enterprise mobile CRM apps face challenges that rarely appear in demos: intermittent connectivity, large reference datasets, and high user experience standards. On iOS, background execution is best-effort and controlled by the system, so reliable sync is mainly an architectural challenge.

This article describes an idle-aware sync architecture that intentionally separates synchronization into two lanes:

a complete baseline sync scheduled for background idle/charging windows, and
lightweight foreground refreshes that download only delta changes.

By moving the majority of data transfer into idle windows, the interactive experience remains fast and predictable while the system converges toward consistency over time.

The Architectural Problem

In enterprise mobile systems, “sync” is not a single operation. Customers often need large bodies of reference data (products, policies, schedules, catalogs, content) and must also capture local changes while offline. A complete refresh can take minutes, yet interactive flows must remain responsive.

The architectural question is broader than “how do I run in the background?” It is this:
How can a mobile client converge toward consistent data, reliably and safely, without requiring user intervention and without fighting iOS execution constraints?

Real-World Use Case: Offline Field Operations in Regulated Environments

A representative use case is a CRM application used in regulated or security-sensitive environments (hospitals, industrial sites, secure customer locations). Common constraints include:

Hours of offline work per day (records created, notes captured, forms completed).
Large reference data that must be available locally (often tens of thousands of entities).
A full refresh that can take 5-10 minutes on average networks, and longer on poor networks.
Operational constraints that discourage or disallow push-triggered orchestration (compliance, security posture, or infrastructure complexity).
Auditability expectations: it must be explainable when data was last refreshed and what was successfully uploaded/downloaded.

In this environment, forcing a full sync at app launch is a user experience failure. At the same time, deferring everything to background execution without resilience is an operability failure. The architecture must provide a fast, interactive experience while still achieving large-scale consistency.

The Two-Lane Sync Strategy: Baseline in the Background, Delta in the Foreground

A practical way to balance responsiveness and completeness is to split synchronization into two intentional lanes with different service-level expectations:

Background baseline sync (complete refresh during idle windows)

The baseline sync is the “heavy” lane. It is scheduled for OS-approved idle/charging windows and may run for minutes. Its job is to establish or repair the local dataset so the app is usable even when the user is offline.

Runs under background processing scheduling (best-effort).
Downloads the complete baseline or large batches of reference data as needed.
Persists progress frequently (checkpoints) so work can resume after interruption.
Implements single-flight control so overlapping baseline runs do not corrupt state or amplify load.

Foreground delta sync (fast, interactive refresh)

Foreground sync should protect the interactive experience. In this pattern, foreground refreshes download only delta changes since the last successful watermark. They do not attempt a complete refresh and do not “heal” large gaps; if the client is far behind, that is intentionally delegated to the next baseline run.

Triggered on app launch/resume or at high-value interaction points.
Downloads only deltas since the last successful watermark (seconds, not minutes).
Keeps bandwidth and CPU use low to preserve perceived performance and battery life.
If the delta window is too large or invalid, schedules a baseline sync rather than expanding foreground work.

The effect is cumulative: the baseline run moves most of the data while the device is idle, and the subsequent foreground refreshes during the day stay small because they only download deltas. This produces a system that feels responsive without sacrificing completeness.

Why Traditional Sync Approaches Fall Short

Many teams start with straightforward strategies and discover that they fail at scale.

Foreground-driven full sync
Running full synchronization on app launch or during active sessions can block the UI, degrade perceived performance, and undermine user trust. It also breaks down when users force-close the app or when long syncs compete with other interactive workloads.

Background fetch
Background fetch is designed for lightweight refresh and is not suited for multi-minute work. Execution windows are short, and scheduling is adaptive; it cannot be treated as a dependable mechanism for heavy synchronization.

Push Notification-triggered sync
Push-triggered sync can be effective but introduces operational dependencies: server orchestration, notification delivery, and policy constraints. In regulated or security-sensitive environments, it may be restricted or avoided entirely.

Naive periodic timers
Periodic timers are fragile under mobile lifecycle constraints and can drain the battery if they encourage work under unfavorable conditions. They also tend to create concurrency issues when combined with foreground triggers.

Architecturally, these approaches overemphasize timing control. iOS rewards designs that focus on correctness, resumability, and resource responsibility.

iOS as a Cooperative System

A useful mental model for iOS background execution is: you request, the system decides. Background scheduling is influenced by device state (battery, charging, thermal), user activity, and system heuristics.

This has two architectural implications:

Background execution must be treated as best-effort. Tasks may be delayed or may not run for long periods on some devices.
Reliability comes from resilience and observability, not from attempting to force deterministic scheduling.

The goal is not to win a scheduling battle. The goal is to build a synchronization system that makes progress whenever the platform permits it, and remains correct when interrupted.

Idle-Aware Background Sync Model

Idle-aware background sync uses Apple's BackgroundTasks framework to request background processing windows that are more suitable for heavier work. The app communicates intent (for example, requiring network connectivity and preferring external power), and iOS chooses an execution window when conditions are favorable.
A practical model is to treat background sync as a reliability layer:

Foreground sync (if present) is optimized for small, user-initiated operations.
Background sync is optimized for convergence: uploading accumulated local changes and applying larger reference updates when the system allows it.
Both paths use the same sync engine and persistence model, differing only in orchestration.

High-Level Architecture

At an architectural level, the system separates orchestration, sync logic, and durability. This reduces coupling, making it possible to reason about correctness.

Component responsibilities

Lifecycle + task registration: registers background task identifiers and requests execution windows when appropriate.
Sync orchestrator/policy: decides what to sync (full vs incremental), enforces concurrency (single-flight), and applies gating (network, auth, schema readiness).
Sync engine: performs the actual synchronization steps. It must be idempotent and resilient, and must not assume a particular execution context.
Local persistent store: provides durability (checkpoints, progress markers, and conflict/audit artifacts).
Telemetry: captures outcomes (success, partial, expired), durations, retries, and diagnostic context.

Execution Flow

The execution flow emphasizes resumability. A background run is never assumed to finish; it is assumed to make safe progress.

Architectural notes

Checkpointing is not an optimization; it is a correctness requirement for long-running work.
Single-flight control prevents overlapping runs that can corrupt state or amplify load.
Upload and download steps should be independently restartable (idempotent writes and resumable reads).

Operating Model: Observability and Outcomes

Architects are accountable for how the system behaves in production. Background work is inherently non-deterministic, so observability is not optional.

Operational practices

Attach a correlation identifier to each sync run and propagate it through logs and backend calls for end-to-end debugging.
Persist a human-readable last sync summary locally (time, success/partial, counts) to support "why is my data stale" investigations.
Treat background sync as a progressive improvement, not a single point of failure: the app must remain usable if background runs are delayed.

When to Use This Pattern (and When Not To)

Good fit

Offline-first enterprise applications with large reference datasets.
Workloads where eventual consistency is acceptable and user experience stability is critical.
Environments where push notifications are unreliable, restricted, or intentionally avoided.
Systems that benefit from running heavy work in charging/idle windows.

Poor fit

Real-time messaging or collaboration features that require low-latency updates.
Latency-critical alerting where minutes of delay are unacceptable.
Very small datasets where a lightweight foreground refresh is sufficient.

Conclusion
Idle-aware background synchronization is an architectural alignment with iOS rather than a workaround. By delegating execution timing to the system and investing in resumability, idempotency, and observability, an offline-first app can converge toward consistent data without interrupting users or harming battery life.
The outcome is not perfect determinism. The result is dependable progress and a user experience that stays fast even as data scales.