DEV Community: Unni T A

I Use AI to Build Software. I Still Don't Trust the Code.

Unni T A — Wed, 30 Sep 2026 11:45:33 +0000

I use AI to build software.

I also don't trust it.

That might sound strange considering most of my recent projects involve AI, LLMs, agents, RAG systems, and AI-assisted development.

But after building several projects this way, I have learned something simple:

Getting AI to generate code is easy. Knowing whether that code is actually good is the difficult part.

AI can make you feel much more productive

One of the biggest changes for me has been how quickly I can move from an idea to a working prototype.

I can describe a feature, give the AI some context, review what it produces, run it, find a problem, and continue the process.

This is incredibly useful.

It is also dangerous if you stop thinking.

A few hundred lines of generated code can appear convincing even when you don't fully understand what is happening underneath.

The application may run.

The UI may look good.

The API may return the expected response.

And you can still have a bad system.

That is the part that took me time to understand.

The first mistake is trusting code because it works

When I started using AI-assisted development more seriously, it was tempting to use a simple rule:

If it works, keep it.

I don't think that rule is good enough anymore.

Something working in one situation doesn't mean the implementation is correct.

AI-generated code can contain:

unnecessary dependencies
duplicated logic
incorrect assumptions
weak error handling
inconsistent patterns
security problems
unnecessary complexity
code that works only for the example used in the prompt

The problem is that these issues are not always visible from the interface.

A nice-looking application can hide a messy backend.

A successful API request can hide poor validation.

A working AI response can hide a broken retrieval process.

That is why I started treating generated code differently.

I stopped asking only "Does it work?"

Now I try to ask better questions.

What exactly did the AI change?

I want to know which files changed and why.

What assumptions did it make?

AI doesn't actually know my intentions unless I provide enough context.

If the requirements are incomplete, it will fill the gaps.

Sometimes those guesses are reasonable.

Sometimes they are completely wrong.

What happens when something fails?

The happy path is easy.

Real applications have:

invalid input
missing data
API failures
timeouts
authentication problems
unexpected model responses
database errors
external service failures

The system needs to handle those situations too.

Can I explain the code?

This has become one of my personal tests.

If I cannot explain what an important piece of generated code is doing, I shouldn't blindly accept it.

I don't need to memorize every line.

But I should understand the important decisions.

This changed how I use AI coding tools

I don't think the useful question is:

"Can AI code for me?"

It obviously can.

The more interesting question is:

"What should I let AI do, and what should I still understand myself?"

For me, AI is extremely useful for things like:

exploring implementation approaches
generating boilerplate
explaining unfamiliar code
creating initial versions of features
refactoring
writing tests
finding possible bugs
debugging with additional context
generating documentation
trying different approaches quickly

But I don't want AI making important architectural decisions without understanding the consequences.

The more important the decision, the more carefully I review it.

This matters even more with AI applications

Building an AI application adds another layer of uncertainty.

A normal software bug can sometimes be reproduced consistently.

AI systems can have problems at several different levels.

For example:


text
User
  ↓
Application
  ↓
Agent / LLM
  ↓
Tools
  ↓
Database / APIs
  ↓
Retrieved information
  ↓
Final response                                                                         Something can go wrong anywhere in that chain.

The model might misunderstand the request.

The retrieval system might return poor information.

A tool might return unexpected data.

The application might pass the wrong context.

The final response might sound convincing even though the underlying information is incomplete.

That means building AI systems requires more than just writing a good prompt.

This is why my projects became more complicated

When I look at the AI projects I have built, there is a noticeable pattern.

I started with the obvious question:

"How do I make the AI do this?"

Then the questions became:

"How does it get the information?"

"What tools should it use?"

"What should it remember?"

"How do I know the answer is reliable?"

"What happens when the tool fails?"

"How do I control what the agent can do?"

"How do I test the whole workflow?"

That shift changed how I think about AI development.

The model is only one part of the application.

The surrounding system matters just as much.

AI didn't remove the need to think

This is probably the biggest lesson I have taken from AI-assisted development.

AI reduces the amount of code I have to type.

It does not remove the need to understand the problem.

In some situations, it actually creates a new responsibility.

When someone writes every line manually, they at least have a reason to encounter the implementation details.

When AI generates those details, it becomes much easier to skip them.

That can make development faster.

It can also make mistakes easier to hide.

My current rule

I don't try to avoid AI.

I use it heavily.

But I try not to confuse generated code with understood code.

For me, the workflow is becoming something like:                                                             Something can go wrong anywhere in that chain.

The model might misunderstand the request.

The retrieval system might return poor information.

A tool might return unexpected data.

The application might pass the wrong context.

The final response might sound convincing even though the underlying information is incomplete.

That means building AI systems requires more than just writing a good prompt.

This is why my projects became more complicated

When I look at the AI projects I have built, there is a noticeable pattern.

I started with the obvious question:

"How do I make the AI do this?"

Then the questions became:

"How does it get the information?"

"What tools should it use?"

"What should it remember?"

"How do I know the answer is reliable?"

"What happens when the tool fails?"

"How do I control what the agent can do?"

"How do I test the whole workflow?"

That shift changed how I think about AI development.

The model is only one part of the application.

The surrounding system matters just as much.

AI didn't remove the need to think

This is probably the biggest lesson I have taken from AI-assisted development.

AI reduces the amount of code I have to type.

It does not remove the need to understand the problem.

In some situations, it actually creates a new responsibility.

When someone writes every line manually, they at least have a reason to encounter the implementation details.

When AI generates those details, it becomes much easier to skip them.

That can make development faster.

It can also make mistakes easier to hide.

My current rule

I don't try to avoid AI.

I use it heavily.

But I try not to confuse generated code with understood code.

For me, the workflow is becoming something like:                              The AI can help with almost every step.

But I still need to be responsible for the result.

The uncomfortable part

AI makes it possible to build things much faster than before.

That is genuinely useful.

But it also makes it possible to build something you don't understand much faster than before.

That distinction matters.

I would rather have a smaller application that I understand than a huge application that I can only operate by repeatedly asking another AI what went wrong.

I'm still learning this.

I don't consider myself an expert who has figured out the perfect AI development workflow.

I'm simply building, breaking things, fixing them, and trying to understand what actually works.

And honestly, that is probably the most useful thing AI has changed for me.

It has made experimentation cheaper.

Now the important skill is knowing what is worth experimenting with, what needs to be verified, and what should never be trusted blindly.

Final thought

I don't think AI-assisted development is about choosing between:

"Humans code"

and

"AI codes."

The more useful model is:

Humans decide. AI helps execute. Humans verify.

At least, that's the approach I'm trying to follow.

Because when something breaks in production, "the AI wrote it" probably isn't going to be a particularly useful explanation.

About me

I'm an AI-focused developer building applications around LLMs, RAG, agentic workflows, automation, and modern web technologies.

I document what I learn while building these systems, including what works, what doesn't, and the problems that appear along the way.

Portfolio: My Portfolio

GitHub: My GitHub

AI disclosure: This article was prepared with AI assistance for drafting and editing. The ideas, experiences, and technical perspective are based on my own development work, and I reviewed the content before publishing.

My Journey Building AI Agents, RAG Systems, and AI-Powered Applications

Unni T A — Tue, 29 Sep 2026 21:52:55 +0000

I have been building AI applications to understand what happens when an LLM has to do more than just answer a prompt.

My projects cover research, agentic workflows, RAG, memory, automation, document processing, financial analysis, and AI-powered applications.

Here are some of the projects I have built and what each one taught me.

1. Deep Research Agent

Status: Live

GitHub: Research-AI-Agent

Live Demo: Research AI Agent

The Deep Research Agent takes a research topic and turns it into a structured research report.

Instead of making one LLM call, the application goes through multiple research stages. It generates search queries, collects information, extracts facts, identifies gaps, performs follow-up searches, and then uses the collected information to create the final report.

I built it with FastAPI and LangGraph, with Tavily for web research and ChromaDB for retrieval.

The project also supports report export, follow-up questions, summaries, counterarguments, translation, job history, Docker deployment, and an Ollama-based local mode.

What makes this project different:

The focus is on the complete research workflow rather than simply putting a chatbot interface on top of an LLM.

2. Autonomous Financial Research Agent

Status: Live

GitHub: Autonomous-Financial-Research-Agent

Live Demo: Autonomous Financial Research Agent

This project focuses on autonomous financial research.

The agent uses a ReAct-style workflow to decide what information it needs, select tools, process the results, and continue the research.

It can work with SEC EDGAR filings, earnings transcripts, financial data, news, sentiment, peer comparisons, fact checking, and calculations.

I also built three types of memory:

Working memory for the current research session
Semantic memory using FAISS
Episodic memory for previous research runs

The project also includes conflict resolution, PII redaction, prompt-injection protection, rate limiting, and an evaluation framework.

What makes this project different:

It combines agent reasoning, multiple research tools, memory, financial data, and evaluation instead of treating research as a single search-and-answer task.

3. Autonomous Dental Appointment Bot

Status: Live

GitHub: Autonomous-Dental-Appointment-Bot

Live Demo: Autonomous Dental Appointment Bot

This project applies AI to appointment automation.

Patients can book, reschedule, and cancel appointments through web, SMS, WhatsApp, and voice interfaces.

The system connects the AI agent with application services, PostgreSQL, Redis, Celery, Stripe, and Google Calendar.

I also worked on practical problems such as appointment slot locking, payment webhooks, duplicate event handling, logging, health checks, and error handling.

What makes this project different:

The AI is connected to application workflows and business rules instead of functioning as an isolated conversation interface.

4. NexusBase

Status: Backend functional / Frontend being redeployed

GitHub: NexusBase

NexusBase is an enterprise RAG architecture project.

It uses Next.js, FastAPI, LangGraph, PostgreSQL, and pgvector.

The system routes queries through different paths depending on what the user is asking. Retrieval-based questions can go through vector search and response evaluation before producing the final response.

The entire application is containerized with Docker.

What makes this project different:

The project focuses on the architecture behind an enterprise RAG system, including routing, retrieval, evaluation, and structured responses.

5. MedComply

Status: Live

GitHub: MedComply

Live Demo: MedComply

MedComply is a medical compliance SaaS project.

It is structured as a monorepo with a Next.js frontend, FastAPI backend, and Supabase database migrations.

The system includes organizations, users, documents, authentication, role-based access control, document processing, and AI-assisted analysis.

The repository also includes Docker configuration and GitHub Actions for automated checks.

What makes this project different:

The project combines AI functionality with application-level access control, document management, and compliance-oriented workflows.

6. Aequitas FI

Status: Live

GitHub: Hybrid-Financial

Live Demo: Aequitas FI

Aequitas FI combines structured financial data with RAG.

Instead of treating every question as a document-search problem, the system separates structured SQL analysis from document retrieval.

LangGraph coordinates the workflow, while PostgreSQL and pgvector provide the data layer.

The project also includes temporal comparison, PII redaction, audit logging, human feedback, and automated testing.

What makes this project different:

It combines SQL and RAG in the same AI workflow so that structured data and retrieved documents can contribute to the final answer.

7. Context Synthesizer

Status: Architecture demonstration

GitHub: Context Synthesizer

Live Demo: Context Synthesizer

Context Synthesizer is an enterprise RAG architecture demonstration.

The project shows how information from systems such as Slack, Jira, Google Drive, and Notion could be organized into a unified retrieval workflow.

The interface demonstrates hybrid search, semantic retrieval, reranking, entity relationships, evaluation metrics, and observability.

This project is intentionally presented as an architecture demonstration.

The live external connectors, vector database, embedding pipeline, backend retrieval engine, authentication, and production LLM inference are not currently implemented.

What makes this project different:

The focus is on visualizing and explaining the architecture required for enterprise knowledge retrieval rather than claiming a demo interface is already a complete production system.

What I Learned From These Projects

The biggest thing I learned is that building an AI application is not just about connecting an LLM to a prompt.

The difficult parts are usually around the model.

You have to decide:

What information the system can access
Which tools it can use
What it should remember
How information should be retrieved
How results should be checked
What happens when something fails
When the agent should stop
How sensitive information should be handled
How the system should be deployed

That is why my projects gradually moved from simple AI interfaces toward systems involving tools, retrieval, memory, evaluation, security, and application logic.

I am still improving these systems, but building them has given me practical experience with different ways of designing AI applications.

My goal is not just to make an LLM generate an answer.

I want to build systems around AI that can actually perform useful work.

My Projects

GitHub Profile

Portfolio

AI disclosure: This article was prepared with AI assistance for drafting and editing. The project information and technical details are based on my own projects and repositories, and I reviewed the content before publishing.