DocuLens AI: What I learned building an AI reviewer in 24 hours

I built DocuLens AI as a focused 24-hour AI-driven development exercise: a source-first document reviewer that can ingest documents, analyze them with an LLM, answer questions, and point back to the material it used.

The important part was not “I asked AI to write code faster.”

The useful part was seeing how much one engineer with a disciplined AI harness can ship when the scope is tight, the specs are explicit, and the system is designed around reviewability from the beginning.

I also deployed the final demo version on AWS. That made the exercise more useful: it was not just a local prototype or a screenshot. It had to pass through packaging, configuration, infrastructure decisions, and deployment checks.

DocuLens AI is not presented as a production-ready legal or compliance product. It is a demo / assessment-grade vertical slice. That distinction matters. The goal was to build enough of the product shape to evaluate the engineering approach without pretending the tradeoffs disappeared.

What I built

The app is a document review workflow with:

• React frontend
• Node.js REST APIs
• authentication
• PostgreSQL persistence
• document ingestion
• MiniMax-backed AI analysis and chat
• source-grounded answers with citations
• retrieval fallback and a pgvector path
• prompt safety wrappers
• CI quality gates
• Docker and AWS deployment path
• OpenSpec / SDD artifacts for planning and review

That is a lot for 24 hours, so the architecture had to stay boring.

The app does not try to be a general AI workspace. It has one job: take source material, make it usable for review, and keep the AI response attached to evidence.

The real constraint was not time

The 24-hour limit was useful, but time was not the main constraint.

The main constraint was trust.

A document reviewer that cannot show where an answer came from is not very useful. A confident summary without citations is just another thing a human has to audit manually. So I treated source-grounded behavior as a product requirement, not a nice-to-have.

That changed the build order.

Instead of starting with a polished chat UI, I focused on the path from ingestion to answer:

document → chunks / metadata → retrieval → grounded prompt → answer → citations

If that path is weak, the rest of the app is decoration.

Where AI helped

AI helped most when the work was already shaped.

It was useful for generating implementation slices, filling in repetitive API and UI plumbing, writing tests, drafting prompts, and keeping momentum across the stack.

But it only worked because there was structure around it:

• specs before broad implementation
• small tasks instead of one giant prompt
• CI checks to catch basic regressions
• source-grounding rules in the AI layer
• public-safe documentation instead of vague claims
• a narrow product contract

When I gave the model a bounded job, it moved fast.

When the task was underspecified, the model did what models do: it filled gaps with plausible choices. Some were fine. Some needed correction. The lesson is simple: AI can compress implementation time, but it does not remove the need for engineering judgment.

Deployment changed the quality bar

Deploying the final version on AWS forced practical decisions that a local demo can avoid.

The app needed Docker packaging, environment separation, database assumptions, deployment documentation, and CI gates that made the delivery repeatable. That is where many AI demos fall apart: the code exists, but the system cannot be operated or explained.

For me, the AWS deployment was part of the proof. It showed whether the architecture was coherent enough to leave my machine.

What the quality gates were doing

For this kind of build, quality gates are not ceremony. They are the harness.

The app needed enough checks to make changes reviewable:

• type and build checks to catch obvious code issues
• API boundaries that stayed understandable
• prompt wrappers that limited unsupported answers
• citation behavior that could be inspected
• deployment notes that described the path without hiding gaps
• OpenSpec artifacts to preserve intent outside the chat

The OpenSpec / SDD part was especially useful. It forced the work into named decisions and acceptance criteria. That made it easier to keep the 24-hour build from turning into a loose pile of AI-generated files.

The tradeoffs

A 24-hour vertical slice has real limits.

The retrieval path is enough to demonstrate the product behavior, not enough to claim mature production evaluation. The pgvector path is there as an evolution route, not a magic fix. The prompt safety wrappers reduce obvious failure modes, but they are not a substitute for domain-specific evals.

Even with AWS deployment, this is still a focused demo, not a hardened SaaS product. The value is that the deployment makes the demo more honest: configuration, infrastructure, and operating constraints are visible instead of ignored.

Those caveats are not failures. They are the point of the exercise.

A good AI-driven build should make the tradeoffs visible. If the demo hides them, it is harder to trust the engineering behind it.

What I would carry forward

The main lesson from DocuLens AI is that AI-driven development works best when it is source-first in both directions:

1. the product grounds answers in source documents;
2. the development process grounds implementation in specs, tests, deployment checks, and review gates.

That combination is where the speed came from.

Not from asking a model to “build an app”.

From giving it a narrow slice, a source contract, a quality bar, and a way to verify progress.

For AI QA Automation and engineering work, that is the part I care about most: using AI to shorten the loop without weakening the loop.

← All posts