DEV Community: Lycore Development

React Native's New Architecture in Production: What JSI, Fabric, and TurboModules Actually Change

Lycore Development — Mon, 04 May 2026 05:40:31 +0000

React Native's New Architecture — JSI, Fabric, and TurboModules — has been "coming soon" for long enough that some teams wrote it off as vaporware. It shipped. It is now default in new React Native projects. And it meaningfully changes how the framework works at the performance-critical boundaries between JavaScript and native code.

This post is not a getting-started guide. It is an honest account of what the New Architecture actually changes in production applications — which performance improvements are real, which problems it does not fix, what the migration involves, and what you need to know before enabling it on an existing app.

What the Old Architecture Got Wrong

To understand what the New Architecture changes, you need to understand what it replaces.

The Old Architecture communicated between JavaScript and native code through a bridge — an asynchronous, serialisation-based message-passing system. JavaScript could not call native code directly. It sent a serialised message (JSON) to the bridge, the bridge deserialised it, passed it to the native thread, native code executed, serialised a response, and sent it back.

This created three fundamental problems.

Asynchronous communication for synchronous needs. Some interactions require synchronous communication between JS and native — reading a layout value to position an animation, for example. With the bridge, this required workarounds that were either slow (async round-trips) or brittle (cached values that could be stale).

Serialisation overhead. Every interaction between JS and native went through JSON serialisation and deserialisation. For high-frequency interactions — scroll events, gesture callbacks, animation frames — this overhead was measurable.

Eager initialisation of all native modules. The Old Architecture initialised every registered native module at startup, regardless of whether it was used. In large applications with many native modules, this contributed significantly to startup time.

What JSI Actually Does

JSI — the JavaScript Interface — replaces the bridge with direct JavaScript bindings to C++. JavaScript can hold references to native objects and call native methods directly, synchronously, without serialisation.

The practical effect is that JavaScript can interact with native code with the same directness as calling a JavaScript function. No queuing, no serialisation, no round-trip to the bridge.

// JSI binding example — what JSI enables at the C++ layer
// This is simplified from how TurboModules work internally

class NativeStorageModule : public jsi::HostObject {
public:
    jsi::Value get(jsi::Runtime& runtime, const jsi::PropNameID& name) override {
        // JavaScript calls this directly via JSI
        // No bridge, no serialisation
        if (name.utf8(runtime) == "getItem") {
            return jsi::Function::createFromHostFunction(
                runtime,
                name,
                1, // number of arguments
                [this](jsi::Runtime& rt, const jsi::Value&, const jsi::Value* args, size_t) {
                    auto key = args[0].getString(rt).utf8(rt);
                    return jsi::Value(rt, jsi::String::createFromUtf8(rt, storage_[key]));
                }
            );
        }
        return jsi::Value::undefined();
    }
private:
    std::unordered_map<std::string, std::string> storage_;
};

From JavaScript's perspective, calling a JSI-backed function feels identical to calling a regular JavaScript function — because it effectively is. The native implementation runs synchronously on the JavaScript thread via the JSI host object protocol.

TurboModules: What Changes for Native Module Development

TurboModules use JSI to provide direct, type-safe access to native code from JavaScript. They replace the old NativeModules system with two significant improvements: lazy loading and type safety.

Lazy loading. TurboModules are only initialised when first accessed, not at startup. An app that has 30 native modules but uses only 5 of them in any given session initialises only 5. Startup time reflects actual usage rather than the total module count.

Type safety via Codegen. TurboModules are defined in a TypeScript or Flow spec that Codegen uses to generate native interface code automatically. This eliminates the type mismatch bugs that were common in the old system — where you could pass the wrong type from JavaScript to native with no compile-time error, only a runtime crash.

Here is what a TurboModule spec looks like:

// NativeDocumentProcessor.ts — the spec file
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
    processDocument(documentId: string, options: ProcessingOptions): Promise<ProcessingResult>;
    cancelProcessing(jobId: string): void;
    readonly getVersion: () => string;
}

interface ProcessingOptions {
    extractTables: boolean;
    extractImages: boolean;
    language: string;
}

interface ProcessingResult {
    jobId: string;
    status: 'success' | 'error' | 'partial';
    extractedData: Record<string, unknown>;
    processingTimeMs: number;
}

export default TurboModuleRegistry.getEnforcing<Spec>('DocumentProcessor');

Codegen generates the iOS (Objective-C/Swift) and Android (Java/Kotlin) interface code from this spec. The native implementation provides the actual logic; Codegen provides the glue.

Fabric: The New Renderer

Fabric is the New Architecture's UI renderer. It replaces the old shadow tree — a background-thread representation of the UI — with a C++ implementation that can run synchronously on the JavaScript thread when needed.

The most significant practical change for application developers is Concurrent Mode. Fabric enables React's concurrent rendering features in React Native:

Suspense for data fetching — components can suspend while data loads, with a fallback rendered in their place
useTransition — expensive updates can be deferred without blocking the UI
Automatic batching — state updates in asynchronous code are batched automatically, reducing re-renders

// Concurrent features now work in React Native with New Architecture
import { useState, useTransition, Suspense } from 'react';

function DocumentList() {
    const [query, setQuery] = useState('');
    const [isPending, startTransition] = useTransition();

    const handleSearch = (text: string) => {
        // Mark the search result update as a transition
        // UI stays responsive while results load
        startTransition(() => {
            setQuery(text);
        });
    };

    return (
        <View>
            <SearchInput onChangeText={handleSearch} />
            {isPending && <ActivityIndicator />}
            <Suspense fallback={<DocumentListSkeleton />}>
                <DocumentResults query={query} />
            </Suspense>
        </View>
    );
}

What the Performance Numbers Actually Look Like

The New Architecture performance improvements are real but context-dependent. Here is what we have measured across our own applications:

Startup time. Improvement is most visible in apps with many native modules. Apps with 20+ native modules see 25–40% startup time reduction from lazy TurboModule initialisation. Apps with few native modules see minimal improvement on this metric.

Scroll and animation performance. Frame drop reduction during complex scroll operations is measurable — we have seen drops from ~2% to ~0.3% in list-heavy views. The improvement comes from Fabric's ability to run layout calculations synchronously and its better integration with the native animation system.

Native module call latency. The JSI-based direct call is faster than the bridge for synchronous calls — sub-millisecond versus 5–10ms for bridge serialisation. For async native operations (network calls, disk I/O), the improvement is not visible because the async operation dominates.

Memory usage. Modest improvement from lazy module initialisation. We have seen 10–15% reduction in idle memory in apps with large native module counts.

The headline: the New Architecture delivers real improvements, but the degree of improvement depends heavily on your specific application. Memory-bound apps or apps with complex gesture handling see more dramatic gains than simple content apps.

The Migration Reality

Enabling the New Architecture in an existing app is a multi-step process. The biggest variable is third-party library compatibility.

Checking Library Compatibility

Before doing anything else, audit your dependencies:

npx react-native-community/upgrade-support
# Or check the React Native directory for compatibility info

The React Native directory now shows New Architecture compatibility for listed packages. Libraries that use the old NativeModules system need to be updated to TurboModules before they work correctly with the New Architecture enabled.

Enabling New Architecture

Android:

// android/gradle.properties
newArchEnabled=true

iOS:

# In ios directory
RCT_NEW_ARCH_ENABLED=1 bundle exec pod install

The Bridge-Compatible Pattern for Mixed Migration

If you have custom native modules that are not yet migrated to TurboModules, the Bridge compatibility layer allows old and new modules to coexist:

// Accessing a not-yet-migrated module via the compatibility bridge
import { NativeModules } from 'react-native';

// Old style — still works via compatibility bridge
const { LegacyDocumentModule } = NativeModules;

// New style — direct JSI binding
import NativeDocumentProcessor from './NativeDocumentProcessor';

The bridge compatibility layer is a migration tool, not a permanent solution. Native modules should be migrated to TurboModules progressively.

Problems the New Architecture Does Not Fix

It is worth being specific about what the New Architecture does not change, because the marketing around it can create inflated expectations.

JavaScript thread performance. JSI removes the bridge overhead, but the JavaScript thread is still single-threaded. Expensive JavaScript computations still block the UI. The New Architecture does not fundamentally change this — it reduces the cost of JS-to-native communication, not the cost of JavaScript execution itself.

Third-party library ecosystem gaps. Many popular libraries have been slow to add New Architecture support. As of mid-2026, most major libraries support it, but you will still encounter edge cases. Always test your specific dependency tree.

Complex gesture handling. Gesture Responder System limitations are not primarily a bridge problem. The Gesture Handler library (now a recommended standard) addresses these, but it requires its own integration separate from New Architecture migration.

Network performance. Network calls go through the native networking stack regardless of architecture. The New Architecture does not make network calls faster.

What to Do Right Now

If you are starting a new React Native project: New Architecture is enabled by default in React Native 0.74+. Leave it on. Start with TurboModules for any custom native code you write.

If you have an existing app on React Native 0.71+: audit your third-party dependencies for compatibility, enable New Architecture in a feature branch, and test comprehensively against your specific hardware targets. Start with your most performance-critical screens.

If you are on React Native below 0.71: upgrade first. The New Architecture on old React Native versions is a different, worse experience than on current versions.

For a broader comparison of React Native and Flutter including how AI-assisted development changes the decision, read Lycore's Flutter vs React Native comparison for 2026.

Lycore builds production React Native and Flutter applications for businesses building cross-platform mobile products. We architect, develop, and deliver mobile applications that perform reliably on real hardware. Get in touch.

What a Real Digital Transformation Actually Looks Like for a Mid-Sized Business

Lycore Development — Sat, 25 Apr 2026 12:29:49 +0000

Digital transformation is one of the most overused phrases in business. Consultants use it to sell strategy engagements. Software vendors use it to sell platforms. Conference speakers use it to describe any change involving technology. After enough repetition, it loses meaning entirely.
This is unfortunate, because the underlying idea — using technology to fundamentally change how a business operates, not just automate what it already does — is genuinely valuable. The problem is not the concept. It is the way it gets packaged and sold.
This article is about what a real digital transformation looks like for a mid-sized business: what actually happens, what typically goes wrong, what success looks like, and how to tell the difference between meaningful change and expensive redecorating.

The Difference Between Digitisation and Transformation
Before anything else, it is worth being clear about what transformation is not.
Replacing paper forms with PDF forms is not transformation. Moving from a filing cabinet to a shared drive is not transformation. Building a website for a business that previously had no web presence is not transformation in the meaningful sense.
These are digitisation — making existing processes electronic. They are often worth doing. They are not transformation.
Transformation happens when technology enables a fundamentally different way of doing business — different processes, different capabilities, different competitive positioning — not just a faster or cheaper version of the existing approach.

A manufacturer that replaces paper-based production tracking with a digital system is digitising. A manufacturer that uses real-time production data to dynamically adjust scheduling, predict maintenance needs, and optimise material ordering is transforming — because the technology has enabled something the business could not do before, not just faster execution of what it was already doing.
The distinction matters because the investment, the timeline, and the organisational change required are fundamentally different. Digitisation projects are relatively predictable. Transformation is harder, takes longer, and fails more often — but produces results that cannot be achieved any other way.

What Transformation Actually Requires
The technology is usually the easiest part. This surprises most businesses when they hear it, but it is consistently true.
Building a custom platform, integrating with existing systems, and migrating data is a tractable engineering problem. It has a known solution space, can be planned and estimated with reasonable accuracy, and follows predictable patterns. The hard parts of transformation are consistently the same across businesses and industries.
Process redesign, not process automation. The instinct when digitalising a business process is to replicate the existing process in software. This instinct is almost always wrong. Existing processes were designed around the constraints of their medium — paper, phone calls, manual data entry — and they accumulate workarounds over years of operation. Digitalising a broken or inefficient process produces a faster broken or inefficient process.
Real transformation starts with understanding what the process is trying to achieve, not how it currently works. From that understanding, you redesign — sometimes radically — and then build the technology that supports the redesigned process.

Data readiness. Transformation initiatives that depend on data — which is most of them — fail far more often because of data quality problems than because of technology problems. A business that has been operating on spreadsheets for ten years has ten years of inconsistently formatted, partially duplicated, variably accurate data. Migrating this into a new system without a serious data cleaning exercise produces a new system full of bad data.
Data readiness work is unglamorous, slow, and frequently underestimated in transformation projects. It is also non-negotiable. The businesses that do it properly before building technology produce better outcomes. The businesses that skip it spend months dealing with data quality issues after launch.
Change management. The new system being technically complete and the organisation actually using it are different things. People who have been doing their jobs a particular way for years — sometimes decades — do not automatically adopt new approaches because the technology now supports them. Resistance, workarounds, and reversion to old habits are the default, not the exception.
The businesses that succeed with transformation invest in change management as a first-class activity alongside technology development: clear communication about why the change is happening, involvement of the people affected in the design process, training that is role-specific and practical rather than generic, and visible leadership support that signals the new approach is not optional.

What Success Looks Like, Measured
Transformation that cannot be measured is indistinguishable from expensive change. Every transformation initiative should have a set of specific, measurable outcomes defined before the work starts — not "improved efficiency" but "reduced order processing time from 4 hours to 30 minutes" and "reduced error rate in invoicing from 8% to under 1%."
These measurements serve two purposes. They tell you whether the transformation worked. And they create accountability for the initiative that prevents it from drifting into a technology project that runs forever without delivering business value.
The most common transformation success metrics we see are: reduction in manual processing time (measurable in staff hours per week), reduction in error rates (measurable by type and frequency), improvement in customer-facing metrics (response time, satisfaction scores, churn), reduction in cost of a specific process (measurable per unit), and improvement in decision quality (measured by the quality of the information available to decision-makers).
Choose three to five metrics before you start. Establish baselines. Measure at 30, 60, and 90 days after go-live. Adjust the approach based on what you find.

The Specific Failure Modes Worth Knowing
Transformation initiatives fail in predictable ways. Knowing them in advance does not prevent them entirely, but it does make them easier to catch and correct.
Scope expansion without timeline or budget adjustment. Transformation projects attract scope additions — stakeholders see the opportunity and want their needs included. Every addition that is not matched with timeline and budget adjustment increases risk. The discipline of maintaining a clear boundary around the MVP and managing additions through a structured change process is as important as any technical decision.
Technology selection before process design. The vendor has a compelling platform. The demo looks good. The contract gets signed. Then the business discovers that the platform's assumptions about how the process should work do not match how the business actually needs to work. The sequence should always be: understand the process, design the new approach, then find the technology that fits.
Going live without a parallel run period. Cutting over from an old system to a new one without any period of parallel operation is a high-risk approach. A parallel period — running both systems simultaneously for a defined period — is slower and more expensive but surfaces issues that only become apparent with real data and real users before the consequences are serious.
Underestimating the training requirement. A two-hour training session for a system that people will use eight hours a day is not adequate preparation. Role-specific, practical training that covers not just how the system works but how to handle the edge cases specific to each role is the minimum. Ongoing support in the first weeks after go-live is essential.

Where to Start
For a mid-sized business beginning to think seriously about digital transformation, the most useful starting point is an honest audit of where your current operations are most constrained by technology limitations.
Not where technology is absent — where it is actively constraining what the business can do. The process that everyone knows is broken but nobody has the capacity to fix. The data that exists but cannot be used because it is in the wrong system. The customer experience that is suffering because the internal tools cannot keep up with demand.
That constraint is the right starting point. Not the most ambitious vision of what the business could be, not the most impressive technology available — the specific operational constraint that, if removed, would have the most measurable impact on the business.
For businesses in the marketplace, e-commerce, or platform economy space, read Lycore's guide to maximising business potential with custom-built platforms — the principles of building technology that fits your specific model, rather than conforming to what a generic platform allows, apply across every transformation initiative.

Lycore is a custom software and AI development company with 20 years of engineering experience. We work with mid-sized businesses on digital transformation initiatives — from strategy through to delivery of custom platforms, AI integrations, mobile apps, and web applications. Get in touch.

The Quiet Crisis in Residential Care: How Technology Is Helping Providers Get Ahead of Compliance Risk

Lycore Development — Sat, 25 Apr 2026 12:08:33 +0000

In residential care, a compliance failure is not a minor administrative inconvenience. It is a CQC inspection finding. It is a safeguarding investigation. In the worst cases, it is harm to a resident that might have been prevented if the right information had been visible at the right time.
The stakes are high and the administrative burden is significant. Residential care providers are required to maintain detailed records of incidents, medication administration, care plan reviews, and staff competencies — all while delivering care to residents with complex and changing needs, managing staff rotas, and operating within increasingly tight funding constraints.
Most providers are doing this with a combination of legacy software, paper records, and spreadsheets that were never designed for the purpose. The result is a compliance environment that is reactive rather than proactive — problems are discovered at inspection rather than before it, incidents are logged after the fact rather than tracked as patterns, and the evidence of good care practice is fragmented across systems rather than readily accessible.
Technology does not solve all of these problems. But the right technology, properly implemented, changes the compliance posture of a residential care provider from reactive to proactive — and that difference is significant both for residents and for the business.

The Incident Management Problem Specifically
Incident management is the clearest illustration of how the right technology changes compliance posture.
In a reactive model, an incident occurs, a paper form is completed (often hours or days later, from memory), the form is filed, and unless there is an immediate regulatory notification requirement, that is the end of the process. The information exists but it is not systematically reviewed for patterns, not connected to care plan reviews, and not visible to the right people without manual effort.
In a proactive model, incidents are logged digitally at the point of occurrence — on a mobile device, by the staff member involved, while the details are fresh. The log captures structured information: incident type, time, location, individuals involved, immediate actions taken, and a free-text description. The system automatically flags whether regulatory notification is required based on the incident type. Managers receive an alert. The incident is visible in the resident's care record immediately.

But the real value comes in the pattern recognition that becomes possible over time. When incidents are logged consistently in a structured format, you can ask questions that paper records cannot answer. Are falls happening more frequently on a particular shift? Is a specific resident's incident rate increasing in a way that should trigger a care plan review? Is there a correlation between staffing levels and incident rates on particular days?
These patterns exist in paper records too — but finding them requires someone to manually review hundreds of forms. In a digital system, they are surfaced automatically.

Care Records and the CQC Evidence Question
The Care Quality Commission's inspection framework requires providers to demonstrate not just that care is being delivered, but that it is person-centred, regularly reviewed, and responsive to changing needs. This is fundamentally an evidence question: what proof do you have that care planning is happening as it should?
The challenge with paper-based care records is not that the care is not happening — in most providers, it is. The challenge is that the evidence is fragmented, inconsistent in quality, and difficult to retrieve during an inspection. A care plan review that happened six months ago is in a filing cabinet. The medication record from last Tuesday is in a different folder. The handover notes from last night's shift are in a book that might or might not be findable.
A digital care management system solves the evidence problem by creating a single, searchable, timestamped record of care activity. Every care plan review is logged with who conducted it and what was changed. Every medication administration is recorded at the point of administration. Every handover note is captured digitally and visible to the incoming shift. When an inspector asks to see evidence that a resident's care plan was reviewed following a recent incident, the answer is a search rather than a manual hunt through filing cabinets.

Staff Competency and the Training Compliance Challenge
Residential care providers are required to ensure that staff are trained and competent for the care they are delivering. This is straightforward in principle and genuinely challenging in practice, because training requirements are extensive, qualifications expire, mandatory updates recur annually, and rotas mean that not all staff can attend training on the same day.
The manual version of managing this — spreadsheets tracking who has completed what by when, email reminders for upcoming renewals, paper certificates filed in staff records — is time-consuming, error-prone, and creates compliance gaps that are discovered at inspection rather than before it.
A digital system that holds staff competency records, generates automatic alerts for approaching expiry dates, and produces evidence reports for inspection purposes removes most of the administrative burden and eliminates the most common compliance gaps. The system knows that a particular staff member's Safeguarding Level 2 renewal is due in 60 days and generates an alert — rather than the provider discovering it has lapsed when an inspector asks to see the certificate.

The Integration Between Systems That Matters Most
In residential care, the most important integration is between the incident management system and the care planning system — and it is the one that generic tools most often fail to deliver.
When an incident occurs involving a specific resident, it should automatically prompt a review question: does this incident suggest that the current care plan is no longer appropriate? In paper-based systems, this connection depends entirely on a human remembering to make it. In a well-designed digital system, it happens automatically: an incident triggers a task for the named nurse or care coordinator to review the relevant sections of the care plan within a defined timeframe.
This sounds like a small operational detail. Over time, it is one of the most significant drivers of care quality — because it means that the care plan remains a living document that reflects the resident's actual needs rather than a static record that was accurate six months ago.

For a detailed look at how technology can transform compliance and incident management in residential care settings, read Lycore's guide to peace of mind, compliance, and incident management for residential care.

What to Look for in a Residential Care Technology Partner
Not all software built for residential care is built by people who understand residential care. The difference is visible in the details: whether the incident categories match CQC's framework, whether the medication recording workflow reflects actual administration practice, whether the care plan structure supports person-centred documentation rather than generic templates.
The right technology partner for a residential care provider is one that has worked with providers directly, understands the regulatory environment, and builds software that reflects how care is actually delivered — not how an outside developer imagined it might be delivered.
The outcome of getting this right is not just reduced administrative burden — though that is real and significant. It is a compliance posture that means inspections are opportunities to demonstrate good practice rather than anxious searches for missing documentation.

Lycore is a custom software and AI development company with 20 years of engineering experience. We build care management platforms, compliance systems, AI integrations, and mobile applications for healthcare and social care providers. Get in touch.

The APIs Quietly Powering the Products You Use Every Day

Lycore Development — Sat, 25 Apr 2026 11:40:10 +0000

When users interact with a product, they see the surface: the interface, the animations, the data that appears in front of them. What they do not see is the layer underneath — the network of APIs that make the product work. The payment processor that handles the transaction. The mapping service that plots the route. The AI model that generates the response. The identity provider that authenticates the user.
Modern software products are not monolithic systems. They are compositions — carefully assembled networks of capabilities, most of which are delivered by APIs built and maintained by someone else. The quality of those API choices shapes the product's capabilities, its reliability, and its cost structure as fundamentally as any internal engineering decision.
For developers building products today, understanding which APIs are genuinely worth integrating — and which ones represent technical debt in disguise — is an increasingly important skill.

Why API Choices Matter More Than They Used To
Ten years ago, most software products were built by teams that owned most of their stack. If you needed payments, you built a payment integration from the ground up. If you needed mapping, you licensed mapping data and built the rendering yourself. If you needed identity management, you built an authentication system.
This approach was expensive, slow, and produced inconsistent quality. The infrastructure that underpins most modern products — payments, communications, mapping, AI, identity — is genuinely hard to build well. Stripe's payment infrastructure has had decades of investment and handles edge cases that most in-house payment teams would never encounter.
The shift to API-first infrastructure means that a two-person startup can offer payment experiences that match large enterprises, because they are both using the same underlying payment API. It means a team of ten can build a product with mapping capabilities that would have required a GIS team of twenty in 2010.
But this shift also means that API selection has become a genuine product and engineering discipline. The wrong API choice can mean vendor lock-in that costs you years to unwind, pricing that destroys unit economics at scale, reliability that caps your SLA, or capabilities that cannot grow with your product.

The APIs That Have Genuinely Changed What Is Possible
Large language model APIs. The most significant shift in software capabilities in the last five years has come from LLM APIs — OpenAI, Anthropic, Google Gemini — making capabilities available via API that would previously have required a research team to build. Document understanding, semantic search, structured data extraction, conversational interfaces, code generation — all available at reasonable per-token costs through a standard API call.
The products being built on LLM APIs right now are not theoretical demonstrations. They are automating document-heavy workflows in legal, financial, and healthcare businesses. They are powering customer service interfaces that handle tier-one queries without human intervention. They are enabling search experiences that understand intent rather than matching keywords.
Real-time communication APIs. Twilio and its competitors made programmable SMS, voice, and WhatsApp available to any developer with a credit card. The business impact has been significant: appointment reminders that actually get seen (SMS open rates run at 90%+ versus email's 20%), transactional notifications that reach customers on the channel they prefer, two-way messaging flows that replace phone calls for routine communications.
More recently, video API providers have made embedded video calling accessible at the API level — enabling telemedicine platforms, remote consultation tools, and virtual classroom products that deliver the experience natively within the product rather than redirecting users to third-party tools.

Geolocation and mapping APIs. Google Maps and its alternatives — Mapbox, HERE, Apple Maps — have become infrastructure for any product where location is relevant. But the more interesting development is the layer above basic mapping: routing APIs that handle real-time traffic, geocoding APIs that resolve addresses to coordinates at scale, and distance matrix APIs that power logistics optimisation. For delivery platforms, field service management tools, and any product that coordinates physical assets across geography, these APIs are not a feature; they are the core operational layer.
Payment infrastructure APIs. Stripe has been the reference implementation for developer-friendly payment APIs for over a decade, and its capabilities have expanded well beyond simple card processing. Stripe Connect powers marketplace payment flows — splitting payments between platforms and vendors, managing payouts, handling compliance across jurisdictions. Stripe Billing handles subscription management with all its edge cases: prorations, trials, upgrades, downgrades, metered billing. The availability of these capabilities via API has lowered the barrier to building marketplace and subscription businesses significantly.
Identity and authentication APIs. Auth0, Clerk, and similar providers have turned authentication from an engineering problem into an API call. The value is not just the implementation time saved — it is the security capabilities that come bundled: MFA, social login, device management, anomaly detection, and compliance tooling that would take months to build to an equivalent standard.

How to Evaluate an API Before You Build on It
The excitement of a capable API can lead teams to integrate first and evaluate later. The consequences — lock-in, pricing surprises, reliability issues — show up months or years after the decision.
The evaluation questions worth asking before integrating any significant API are: What is the pricing model at 10x and 100x your current volume, and is it sustainable? What is the documented SLA, and what compensation exists if it is breached? How active is the development and what is the deprecation policy for older API versions? What data does the API provider retain, and under what terms? And critically: if this API went away or became unaffordable, how would you replace it, and how long would that take?

The APIs that have become genuinely foundational — Stripe, Twilio, the major LLM providers — have earned that status through years of reliability, clear documentation, and pricing that remained reasonable as customers scaled. That track record is worth factoring into your evaluation alongside the technical capabilities.
For a detailed look at the specific APIs shaping software development right now and how to evaluate which ones belong in your stack, read Lycore's guide to the six game-changing APIs shaping the future of software development.

Lycore is a custom software and AI development company with 20 years of engineering experience. We build AI integrations, API-connected applications, mobile apps, and web platforms for businesses that want practical results. Get in touch.

Why We Stopped Writing Boilerplate and What Our Code Reviews Look Like Now

Lycore Development — Thu, 16 Apr 2026 07:27:50 +0000

A year and a half ago we started integrating AI tools into our development workflow across Python, Django, React, Flutter, and .NET projects. This is an honest account of what changed — specifically around boilerplate and code review, which are the two areas where the impact has been most concrete.
Not a productivity manifesto. Just what actually happened.

The boilerplate problem
Before AI tools, setting up a new Django app involved a lot of typing that every senior engineer on our team had done hundreds of times. Serializers, viewsets, URL routing, permission classes, filter backends, initial migrations — none of it is hard, but it takes 30–45 minutes of focused work that adds zero intellectual value.
We now generate that scaffolding in under two minutes. Here is roughly what a typical prompt looks like:
Create a Django REST Framework setup for a Project model with the
following fields: name (CharField), owner (ForeignKey to User),
status (choices: draft/active/archived), created_at, updated_at.

Include:

ModelSerializer with read-only id, created_at, updated_at
ViewSet with list, retrieve, create, update, partial_update
IsAuthenticated permission
Filter by status and owner
URL routing The output is accurate, follows our patterns, and is ready for a senior engineer to review structurally before anything is built on top of it. That last part — "ready for a senior engineer to review structurally" — is the rule we follow. AI writes the skeleton. A human checks the architecture before it becomes load-bearing. This stops structural mistakes from propagating through the codebase.

What changed in code review
This is the more interesting shift.
Before AI tools, our code reviews caught a mix of things:

Obvious mechanical issues: missing null checks, inefficient queries, typos in variable names
Structural concerns: wrong abstraction level, coupling that shouldn't exist
Business logic errors: misunderstood requirements, missing edge cases
Security issues: missing validation, exposed data in serializers

AI handles the first category well. We now run Claude over every PR before it goes to human review, with a prompt along these lines:
Review this Django code for:

N+1 query problems
Missing null/empty checks
Serializer fields that expose sensitive data unintentionally
Missing error handling in API views
Any obvious security concerns

Code:
[paste diff]
It catches N+1 queries reliably. It spots missing select_related and prefetch_related calls. It flags serializer fields that probably shouldn't be writable. It notices when an exception is swallowed silently.
This means our human reviewers spend almost no time on mechanical issues. They spend their time on the things AI is not good at: whether the abstraction is right, whether the business logic matches the actual requirement, whether this code will be maintainable in 18 months.

The rule about tests
One thing we learned the hard way: never let AI write both the implementation and the tests for the same code.
If you do this, the tests pass — but they test what the code does, not what it should do. You end up with 100% coverage on the wrong behaviour.
Our rule: tests are written against the specification, not against the implementation. We write test cases from requirements first (even just as comments describing what each test should verify), then use AI to fill in the test code. The human wrote the spec for the test. The AI wrote the boilerplate of the test function.
This produces test suites that actually catch regressions rather than just confirming that the code runs.

What the numbers look like
We are careful about overstating productivity claims — the research on this is genuinely mixed and highly context-dependent. But across our team over the past year:

New module setup time is down significantly. What took 45 minutes now takes under 10, including review.
Code review cycles are shorter. Pre-review AI checks eliminate a full round of comments on mechanical issues in most PRs.
Documentation coverage is higher. We generate initial API docs and changelog entries with AI after each sprint. This used to get skipped under time pressure.

The gains are real. They are also concentrated in specific task types. Complex architectural decisions, novel integrations, debugging subtle race conditions — AI adds overhead on these, not speed. Knowing which is which is the actual skill.

What we still do entirely by hand
Security-critical code. Authentication systems, payment processing, access control logic, data encryption — we write these carefully, review them carefully, and do not rely on AI-generated implementations. Research shows a measurable increase in security vulnerabilities in AI-assisted code. We take that seriously.
Novel architecture. When a project requires something that isn't a well-worn pattern — a custom multi-tenant data model, a real-time system with unusual constraints — AI suggestions tend toward generic solutions. These decisions need human judgment and experience.
Anything that requires understanding the client's actual business. AI does not know why a field is named the way it is, what the edge case in the legacy data means, or why a particular design decision was made three years ago. That context lives in engineers' heads and in Slack history.

The honest summary
AI tools made our team faster on the tasks where they work well. They did not change what good engineering looks like — they just removed some of the friction in getting there.
If you are adopting AI tools on your team: spend the time figuring out exactly where in your workflow they add value and where they add overhead. The teams seeing real gains are the ones who made that distinction deliberately, not the ones who turned on Copilot and hoped for the best.

Lycore is a custom software development company. We build with Django, React, Flutter, and .NET — and we have been integrating AI tools into our workflow since they became production-ready. Questions or thoughts? Drop them in the comments.

Building AI Agents That Actually Work in Production: Lessons from Real Projects

Lycore Development — Thu, 16 Apr 2026 07:21:13 +0000

Everyone is building AI agents right now. Most of them work fine in a demo and fall apart in production. This post is about the gap between the two — what causes it, and what we have learned from shipping agents that run reliably in real business environments.

What "agent" actually means here

For this post, an agent is a system that takes a goal, plans a sequence of steps to achieve it, executes those steps using tools or APIs, and adapts based on what it finds along the way — without a human approving each action.

That is meaningfully different from a chatbot that answers questions, or a RAG pipeline that retrieves and summarises documents. An agent takes action in systems. That is what makes it powerful, and what makes it hard to get right in production.

The four failure modes we see repeatedly

1. Unbounded loops

An agent is given a task. It takes a step, evaluates the result, decides the task is not complete, takes another step — and loops. Without explicit loop limits, a poorly designed agent will happily consume API credits and time indefinitely.

Every agent we build has a hard step limit. Not a soft suggestion — a hard ceiling that raises an exception and routes to human review if hit.

class AgentExecutor:
    MAX_STEPS = 15

    def __init__(self, tools, llm):
        self.tools = tools
        self.llm = llm
        self.steps_taken = 0

    def run(self, goal: str) -> dict:
        context = {"goal": goal, "history": []}

        while self.steps_taken < self.MAX_STEPS:
            action = self._decide_next_action(context)

            if action["type"] == "complete":
                return {"status": "success", "result": action["result"]}

            result = self._execute_action(action)
            context["history"].append({"action": action, "result": result})
            self.steps_taken += 1

        # Exceeded step limit — escalate to human
        raise AgentStepLimitExceeded(
            f"Agent exceeded {self.MAX_STEPS} steps. Last context: {context}"
        )

2. Silent failures that look like success

An agent calls an external API. The API returns a 200 with an error message in the body. The agent reads the response, interprets it as success, and reports the task complete.

This is more common than it sounds. Many internal APIs have inconsistent error handling. Agents need to be taught to verify outcomes, not just record that an action was taken.

def verify_action_result(action_type: str, result: dict) -> bool:
    """
    Verify the actual outcome of an action, not just that it returned.
    """
    verifiers = {
        "send_email": lambda r: r.get("message_id") is not None,
        "create_record": lambda r: r.get("id") is not None and r.get("error") is None,
        "update_status": lambda r: r.get("updated") is True,
    }

    verifier = verifiers.get(action_type)
    if not verifier:
        # Unknown action type — log and flag for review
        logger.warning(f"No verifier for action type: {action_type}")
        return False

    return verifier(result)

3. Prompt drift under load

This one is subtle. Your agent works correctly on your test cases. In production, it sees inputs it has never encountered — slightly unusual phrasing, edge case data, requests that are adjacent to but not exactly what it was designed for. Over time, the average quality of outputs drifts.

Mitigation requires ongoing monitoring of output quality, not just uptime. We log every agent decision alongside a confidence indicator and review anything below threshold. We also run a fixed set of regression test cases against the live agent weekly.

4. Tool call hallucinations

The agent decides to call a tool that does not exist, or calls a real tool with parameters that do not match the schema. This fails with an error that confuses the agent, which then tries to recover and often makes things worse.

The fix is strict tool schema enforcement with clear error messages that the agent can actually use to correct itself:

def call_tool(tool_name: str, params: dict) -> dict:
    if tool_name not in AVAILABLE_TOOLS:
        return {
            "error": f"Tool '{tool_name}' does not exist.",
            "available_tools": list(AVAILABLE_TOOLS.keys()),
            "suggestion": "Check the tool name and try again."
        }

    tool = AVAILABLE_TOOLS[tool_name]
    validation_errors = tool.validate_params(params)

    if validation_errors:
        return {
            "error": "Invalid parameters.",
            "details": validation_errors,
            "expected_schema": tool.param_schema()
        }

    return tool.execute(params)

Returning structured, actionable error messages — rather than raising exceptions — gives the LLM something to work with when it makes a mistake.

The architecture pattern we keep coming back to

After building agents across fintech, healthcare, e-commerce, and SaaS projects, we have settled on a pattern that handles the above failure modes consistently:
The key design decisions:

Separate planning from execution. The LLM proposes a plan. A separate step validates that plan against constraints (allowed tools, scope limits, business rules) before any action is taken. This stops the agent from taking actions it is not authorised to take.

Maintain explicit state. The agent's understanding of what has happened and what still needs to happen is stored explicitly, not inferred from conversation history. This makes the state inspectable, debuggable, and resumable after failures.

Human review queue is first-class. It is not a fallback — it is a designed-in path. Any time the agent is uncertain, hits a limit, or encounters a situation outside its defined scope, it routes to the queue rather than guessing. This is what makes agents safe to run in production on real business data.

What a minimal Django integration looks like

# models.py
from django.db import models

class AgentTask(models.Model):
    STATUS_CHOICES = [
        ('pending', 'Pending'),
        ('running', 'Running'),
        ('complete', 'Complete'),
        ('failed', 'Failed'),
        ('needs_review', 'Needs Human Review'),
    ]

    goal = models.TextField()
    status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='pending')
    steps_taken = models.IntegerField(default=0)
    state = models.JSONField(default=dict)
    result = models.TextField(blank=True)
    error = models.TextField(blank=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)


# tasks.py (Celery task)
from celery import shared_task
from .models import AgentTask
from .agent import AgentExecutor, AgentStepLimitExceeded

@shared_task
def run_agent_task(task_id: int):
    task = AgentTask.objects.get(id=task_id)
    task.status = 'running'
    task.save(update_fields=['status'])

    try:
        executor = AgentExecutor(tools=TOOLS, llm=LLM)
        result = executor.run(task.goal)
        task.status = 'complete'
        task.result = result['result']

    except AgentStepLimitExceeded as e:
        task.status = 'needs_review'
        task.error = str(e)

    except Exception as e:
        task.status = 'failed'
        task.error = str(e)

    finally:
        task.steps_taken = executor.steps_taken
        task.state = executor.get_state()
        task.save()

This gives you a persistent, inspectable record of every agent run — what it was trying to do, how far it got, what state it left things in, and whether it needs a human to look at it.

Observability is not optional

In production, you need to know:

How many agent tasks complete successfully vs. hit the step limit vs. fail?
What is the distribution of steps taken per task?
Which tool calls fail most often, and with what errors?
What does a typical agent trajectory look like for your most common task types?

Without this data, you are flying blind. We instrument every tool call, every LLM decision, and every state transition, and pipe it to whatever monitoring stack the client is already using (Datadog, Sentry, CloudWatch — it does not matter as long as it's there).

The honest summary

Agents are genuinely useful. They can automate multi-step work that would otherwise require a human, and do it at a scale that changes what is possible for a business. But they require more careful engineering than a simple LLM API call.

If you are building your first agent: start with a narrow, well-defined task. Add hard limits everywhere. Build the human review path first, not last. Instrument everything from day one. Expand scope only once the narrow case is working reliably in production.

The teams that get agents into production successfully are not the ones who built the most ambitious agent — they are the ones who built the most observable one.

Lycore builds production AI systems for businesses — agents, RAG pipelines, LLM integrations, and custom AI applications on Django, React, Flutter, and .NET. Get in touch if you want to talk through your use case.

LangChain vs LlamaIndex in 2026: What We Actually Use and Why

Lycore Development — Thu, 16 Apr 2026 07:02:42 +0000

Every time we start a new AI project, someone on the team asks whether to use LangChain or LlamaIndex. We have shipped production systems with both. Here is an honest comparison based on that experience — not a feature matrix copied from the docs.

Quick context
Both libraries have matured significantly since their early versions. LangChain went through a messy period of API churn around v0.1/v0.2 that burned a lot of teams. LlamaIndex (formerly GPT Index) went deep on the retrieval and indexing use case. Both are now stable enough for production use, but they still have different strengths.

What LangChain is actually good at
Chains and agents with complex logic. LangChain's expression language (LCEL) is well-suited for building multi-step pipelines where you need explicit control over how data flows between components. If you are building an agent that needs to decide between multiple tools, maintain conversation state, and handle branching logic — LangChain's abstractions are a reasonable fit.
Broad ecosystem of integrations. LangChain has integrations with almost everything: every major LLM, every vector store, most common APIs. If you need to wire together a lot of different services quickly, the breadth of LangChain's integration library saves time.
Streaming support. LangChain's streaming support is solid and straightforward to implement, which matters for user-facing applications where you want tokens to appear as they are generated.
A typical LangChain chain for a simple RAG setup:

from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import PGVector
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

llm = ChatOpenAI(model="gpt-4o", temperature=0.2)
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

vectorstore = PGVector(
    connection_string="postgresql://user:pass@localhost/db",
    embedding_function=embeddings,
    collection_name="documents"
)

prompt = PromptTemplate(
    template="""Answer based only on the context below.
If the answer isn't in the context, say so.

Context: {context}
Question: {question}
Answer:""",
    input_variables=["context", "question"]
)

chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    chain_type_kwargs={"prompt": prompt},
    return_source_documents=True
)

result = chain.invoke({"query": "What is the refund policy?"})
print(result["result"])

What LlamaIndex is actually good at
Document ingestion and indexing. LlamaIndex's abstractions around loading, chunking, and indexing documents are more thought-through than LangChain's. If your primary use case involves ingesting varied document types — PDFs, Word docs, Notion pages, web pages, database rows — and querying across them, LlamaIndex handles this more cleanly.
Query engines and advanced retrieval. LlamaIndex has better out-of-the-box support for more sophisticated retrieval patterns: hybrid search, recursive retrieval, query decomposition, and sub-question generation. If retrieval quality is your main concern, LlamaIndex gives you more levers to pull.
Structured outputs from documents. Extracting structured data from unstructured documents is a use case where LlamaIndex's PropertyGraphIndex and structured extraction tools outperform what you'd put together yourself with LangChain.

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.core.retrievers import VectorIndexRetriever
from llama_index.core.query_engine import RetrieverQueryEngine
from llama_index.core.postprocessor import SimilarityPostprocessor
from llama_index.llms.openai import OpenAI
from llama_index.embeddings.openai import OpenAIEmbedding

# Load and index documents
documents = SimpleDirectoryReader("./docs").load_data()
index = VectorStoreIndex.from_documents(
    documents,
    embed_model=OpenAIEmbedding(model="text-embedding-3-small")
)

# Build query engine with similarity threshold
retriever = VectorIndexRetriever(index=index, similarity_top_k=4)
postprocessor = SimilarityPostprocessor(similarity_cutoff=0.7)

query_engine = RetrieverQueryEngine(
    retriever=retriever,
    node_postprocessors=[postprocessor],
    llm=OpenAI(model="gpt-4o", temperature=0.2)
)

response = query_engine.query("What is the refund policy?")
print(response.response)
print([node.metadata for node in response.source_nodes])

Where each falls short
LangChain:
The abstraction layers can work against you. When something breaks in a LangChain chain, the stack traces are deep and the error messages are not always helpful. Debugging a complex agent that is misbehaving takes longer than it should because you are reasoning through multiple layers of abstraction rather than your own code.
API stability has improved but LangChain still moves fast. Pinning your versions carefully and reading changelogs before upgrading is not optional.
The breadth of integrations is also a maintenance burden — many community integrations are not well-maintained and break quietly when upstream services change.
LlamaIndex:
Steeper initial learning curve. LlamaIndex's concepts (nodes, indices, query engines, postprocessors) take longer to internalise than LangChain's chain/agent model.
Less suited for complex agentic workflows. If you need an agent that takes sequential actions across multiple external tools — not just retrieval — LangChain or building directly on the OpenAI/Anthropic function calling API is usually cleaner.
The documentation has improved a lot but some of the advanced features are still better understood by reading source code than docs.

What we actually reach for
For RAG on existing Django/Python apps: We often skip both and build directly with the OpenAI API and pgvector, as described in our RAG guide. For straightforward retrieval use cases the framework overhead is not worth it.
For document-heavy use cases with varied inputs: LlamaIndex. The document loaders and chunking pipeline alone justify it.
For multi-step agents or complex chains: LangChain, specifically LCEL. The composability is genuinely useful for orchestrating multi-step logic.
For anything client-facing where we need fine control: Neither. We build directly on the provider APIs (OpenAI, Anthropic) with our own thin wrappers. This gives us complete control over prompts, error handling, costs, and debugging.

The honest take
Both are tools, not commitments. The mistake most teams make is picking one and trying to use it for everything. LangChain and LlamaIndex have different strengths; the right one depends on your specific use case.
If you are building your first AI feature: start without a framework. Call the API directly. Add a framework when the complexity justifies it, not before.

Lycore builds production AI systems for businesses — RAG pipelines, agents, LLM integrations, and custom AI applications. We work with both LangChain and LlamaIndex depending on the project requirements. Get in touch if you want to talk through your use case.

Building a RAG Pipeline on Your Existing Django App: A Practical Guide

Lycore Development — Wed, 15 Apr 2026 15:03:26 +0000

You have a Django app. You want to add AI-powered search or a chatbot that actually knows about your data — not just a generic LLM that hallucinates answers. The solution is RAG: Retrieval-Augmented Generation.

This guide walks through exactly how we add RAG to existing Django projects. No rebuilding from scratch. No switching stacks. Just a clean integration on top of what you already have.

What RAG actually does

A plain LLM call like GPT-4 or Claude knows only what it was trained on. Ask it about your product catalogue, your customers, or your internal docs — and it will either make something up or tell you it doesn't know.

RAG fixes this by retrieving relevant chunks of your actual data and injecting them into the prompt as context. The model then answers based on that context, not just training data.

The flow looks like this:

User asks a question
Your app converts the question to a vector embedding
You search your vector store for the most similar chunks of your data
Those chunks get injected into the LLM prompt as context
The LLM answers based on your data

What you need

A Django app with a PostgreSQL database (we'll use pgvector)
An OpenAI API key (for embeddings and completions)
pgvector Postgres extension installed
Python packages: openai, pgvector, django

We use pgvector here because it runs inside your existing Postgres instance — no separate vector database to manage or pay for. For larger scale, Pinecone or Chroma are worth evaluating, but for most Django projects pgvector is the right call.

Step 1: Install pgvector

pip install pgvector openai

Enable the extension in Postgres:

CREATE EXTENSION IF NOT EXISTS vector;

Step 2: Add a vector field to your model

# models.py
from django.db import models
from pgvector.django import VectorField

class Document(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    embedding = VectorField(dimensions=1536, null=True, blank=True)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

Run your migration:

python manage.py makemigrations
python manage.py migrate

Step 3: Generate and store embeddings

# utils/embeddings.py
from openai import OpenAI

client = OpenAI()

def get_embedding(text: str) -> list[float]:
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=text
    )
    return response.data[0].embedding

Hook this into a Django signal:

# signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import Document
from .utils.embeddings import get_embedding

@receiver(post_save, sender=Document)
def generate_embedding(sender, instance, created, **kwargs):
    if created or not instance.embedding:
        embedding = get_embedding(instance.content)
        Document.objects.filter(pk=instance.pk).update(embedding=embedding)

Step 4: Semantic search with pgvector

# utils/search.py
from pgvector.django import CosineDistance
from .models import Document
from .utils.embeddings import get_embedding

def semantic_search(query: str, top_k: int = 5) -> list[Document]:
    query_embedding = get_embedding(query)
    results = (
        Document.objects
        .annotate(distance=CosineDistance('embedding', query_embedding))
        .order_by('distance')[:top_k]
    )
    return list(results)

Step 5: Build the RAG response

# utils/rag.py
from openai import OpenAI
from .search import semantic_search

client = OpenAI()

def rag_response(user_query: str) -> dict:
    relevant_docs = semantic_search(user_query, top_k=4)
    context = "\n\n---\n\n".join([
        f"Title: {doc.title}\n{doc.content}"
        for doc in relevant_docs
    ])
    system_prompt = """You are a helpful assistant. Answer the user's question
using ONLY the context provided below. If the answer is not in the context,
say so clearly — do not make up information.

Context:
{context}""".format(context=context)

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_query}
        ],
        temperature=0.2
    )
    return {
        "answer": response.choices[0].message.content,
        "sources": [{"id": doc.id, "title": doc.title} for doc in relevant_docs]
    }

Step 6: Wire it up as a Django view

# views.py
import json
from django.http import JsonResponse
from django.views.decorators.http import require_POST
from django.views.decorators.csrf import csrf_exempt
from .utils.rag import rag_response

@require_POST
@csrf_exempt
def ask(request):
    data = json.loads(request.body)
    query = data.get("query", "").strip()
    if not query:
        return JsonResponse({"error": "query is required"}, status=400)
    result = rag_response(query)
    return JsonResponse(result)

Test it:

curl -X POST http://localhost:8000/api/ask/ \
  -H "Content-Type: application/json" \
  -d '{"query": "What is your refund policy?"}'

Things to watch in production

Chunking strategy matters. Split long documents into 300–500 token chunks with 50–100 token overlap before embedding. Add a DocumentChunk model alongside Document for this.

Cache embeddings aggressively. Never regenerate an embedding for content that hasn't changed.

Monitor retrieval quality. Log cosine distance scores. If the top result has a distance above ~0.4, handle this gracefully rather than feeding irrelevant context to the LLM.

Rate limit your LLM calls. Use the tenacity library for retry logic with exponential backoff.

What this gets you

A working RAG pipeline on your existing Django app, using your existing Postgres database, with no new infrastructure. The whole integration is around 100 lines of code.

At Lycore we build AI integrations on top of existing Django, React, and .NET applications. If you're looking to add RAG, agents, or other AI capabilities to your stack, get in touch.