DEV Community: Lycore Development

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.