The Great AI Paradox: Why a Development Team Chose React for Learning, Only to Abandon It Four Months Later

BRUSSELS — In the modern software engineering landscape, artificial intelligence is frequently marketed as the great accelerator. It writes boilerplate code in seconds, debugs complex loops before human eyes can scan them, and promises to bridge skill gaps overnight. But what happens when an AI-driven development workflow succeeds too well?

For ThinkR, a specialized R development consultancy, the answer was unexpected: it completely sabotaged their primary project objective.

In a revealing architectural case study titled “We chose React to learn it. The AI wrote it for us,” the firm documented a four-month experiment that began with a deliberate commitment to step outside their comfort zone and ended with a humbling, yet pragmatic, U-turn back to their native ecosystem.

Main Facts: The Anatomy of a Tech Pivot

The project in question centered on StaffPuzzle, an internal resource-allocation tool tracking who works on what down to the half-day. Version 1 of the tool was a read-only R Shiny application comprising approximately 1,200 lines of code that had operated reliably for years.

By February 2026, the team aimed to build Version 2, designed to introduce Google Calendar integration, a simulation mode, and historical performance indicators.

Instead of extending their existing Shiny architecture, the six-person team made a radical choice: they decided to rebuild the application from scratch using React, a JavaScript library with which they had only "junior" familiarity.

• The Core Trade-off: The team knew full well that building in React would take roughly twice as long as doing it in R (estimated at 19–24 half-days versus 12 half-days).
• The Strategic Goal: They were not buying a faster application; they were consciously "buying skills" to modernize their frontend capabilities.
• The Reality Check: By June 2026—just halfway through the project timeline, with two development milestones successfully delivered—the team pulled the emergency brake, scrapped the React implementation, and pivoted back to R.

Only one of their justifications for returning to R was an admission of being "wrong." The factor that truly sealed the decision was far more uncomfortable: the learning process they had paid a steep premium for had never actually taken place. Because of AI assistance, the code had arrived faster than the developers could read it.

Chronology: Four Months of Architectural Whiplash

To understand how a seasoned development team could completely reverse a foundational architectural decision in less than 150 days, one must examine the timeline through their formal Architecture Decision Records (ADRs).

February 19: The Strategic Gamble

The team evaluated three distinct architectural paths: an all-JavaScript stack (React paired with Supabase), a native R stack utilizing raw HTMX on raw Plumber2, and a hybrid approach. Notably, "staying on Shiny" was absent from the options, having been quietly eliminated months earlier by a brief that demanded an "exit Shiny" mandate.

According to their initial Architecture Decision Record, the team acknowledged their junior comfort level with React, framing it as a "deliberate investment." They accepted a timeline penalty because they believed React skills offered high transferability to future web projects.

February to May: The AI Acceleration Trap

As development commenced, the team leveraged AI coding assistants to bridge their lack of React expertise. The AI functioned precisely as advertised: it generated functional components, wired up state management, and cleared milestones on schedule.

However, a silent failure mode was taking root. Because the AI was outputting production-ready code at a blistering pace, the human developers shifted from learning a new framework to merely reviewing and accepting machine-generated output. The cognitive friction required to deeply understand React’s rendering lifecycle, hooks, and state architecture was bypassed by automated generation.

June 3: The U-Turn and ADR-003

By early June, the team reopened the project file to evaluate their progress. Three distinct variables had shifted, prompting the creation of a second ADR that formally canceled the first:

1. The R Ecosystem Evolved: In February, the R-based HTMX option required writing raw HTML and attributes by hand. By June, mature R packages such as htmxr and alpiner had matured, providing high-level abstractions that bridged the gap without abandoning the R language.
2. Ghost Complexities Dissipated: The original decision matrix penalized R for "difficult rich interactivity," citing drag-and-drop mechanics as a roadblock. Upon inspecting the actual React code written thus far, the team realized they hadn’t implemented drag-and-drop at all; they had used a lasso selection mechanism, which alpiner handles natively.
3. The Learning Deficit Exposed: The central pillar of the February decision—acquiring React fluency—had completely collapsed.

Supporting Data and Comparative Metrics

The financial and operational metrics gathered by ThinkR provide a clear quantitative backing for their journey.

Furthermore, the post-pivot return to R yielded immediate architectural dividends:

• Test-to-Code Ratio: Skyrocketed from 0.26 to 0.77, resulting in 544 automated tests running entirely without a browser.
• Performance: A proof-of-concept written immediately after the pivot successfully reproduced the main application screen in pure R, executing requests in just 70 milliseconds.
• Ecosystem Synergy: The rewritten internal tool became the premier production stress-test for ThinkR’s proprietary packages within the broader "hyperverse" ecosystem—a benefit no generic React application could ever offer.

Official Responses and Strategic Reflections

Rather than attempting to sweep the pivot under the rug, the leadership team at ThinkR published an open, transparent post-mortem detailing how modern workflows interact with human learning curves.

The core takeaway, according to the team’s documentation, is that a technical decision justified by learning must actively schedule its own verification.

"Learning React, the central motivation for February’s decision, is not happening in practice: the developer does not have time to read the code generated by the AI, so the skills objective is not being met."
— ADR-003, June 3, 2026

The team emphasized that writing down architectural decisions in structured ADRs is what ultimately saved them from pride-driven inertia. Without explicit, dated criteria, the June meeting would have devolved into an emotional debate over "who was right." Instead, it became an objective audit of whether underlying hypotheses held true.

Moreover, the team separated the concepts of environmental change versus human error. Only one part of their initial choice—the overstated difficulty of R-based interactivity—was a genuine misjudgment. The other shifts were external: the maturation of the R web ecosystem and the realization of how generative AI alters the human cognitive absorption of new codebases.

Broader Implications for the Software Industry

The ThinkR case study serves as a canary in the coal mine for software engineering teams worldwide. As AI code assistants become ubiquitous, organizations must confront the "AI Learning Paradox."

1. The Death of Accidental Up-skilling

Historically, taking on a tech stack outside a team’s comfort zone was a legitimate strategy for organic professional development. Developers learned new paradigms by wrestling with compiler errors, reading documentation line by line, and painfully debugging state management issues.

When an AI assistant abstracts away the struggle, it also abstracts away the education. Companies that mandate a tech stack change primarily for "team growth" must now actively audit whether that growth is actually occurring, or if they are simply paying a productivity tax to act as glorified code reviewers for an LLM.

2. The Fallacy of "Transferable Skills"

The team’s mid-project revelation regarding skill transferability strikes at the heart of corporate strategy. While React skills look impressive on an individual developer’s CV, a company whose core business model revolves around R gains little long-term leverage by maintaining surface-level proficiency in JavaScript frameworks. Doubling down on domain-specific expertise—such as authoring CRAN-bound packages and refining native web-R abstractions—amplifies a company’s market visibility far more effectively than adopting generic web standards.

3. The Power of Rigorous Documentation

Ultimately, the story of StaffPuzzle is a testament to disciplined engineering governance. By maintaining formal Architecture Decision Records, ThinkR transformed what could have been a demoralizing failed project into a textbook study in agility. They proved that a U-turn is not a sign of institutional failure, but rather the exact intended outcome of a well-instrumented decision-making framework meeting empirical reality.

As engineering teams race to integrate AI into every corner of the software development lifecycle, ThinkR’s experience offers a sobering reminder: Just because an AI can write the code doesn’t mean your team is learning how to build the product.