DEV Community: Rubab Zahra

How AI Is Answering Complex Project Queries in Seconds

Rubab Zahra — Tue, 01 Sep 2026 14:08:15 +0000

Developers and project managers waste hours every week hunting for simple answers. You need to know which tickets went over estimate. You want to see what changed recently. You need to check if anything is blocking a specific issue.
In most tools, that means opening filters, scrolling boards, checking time logs, and piecing the information together manually. This friction is so common that many teams accept it as normal. It shouldn’t be.

The Real Cost of Manual Lookup
Every time someone digs through tickets to answer a basic question, context is lost, and momentum slows. Status updates turn into meetings. Simple questions become Slack threads.
Decision-making gets delayed because the data exists but is hard to surface. Traditional project tools store the information. They just don’t make it easy to retrieve it when you need it.

What Changes with Conversational AI
Modern AI assistants connected to project data change this pattern. Instead of navigating interfaces, you ask a direct question in natural language and receive a structured answer based on real workspace data.
Examples of questions that previously required manual effort:

1. How much time did I log last week?
2. Which tickets have logged time higher than the estimate?
3. What is currently blocking this ticket?
4. What changed on this project recently?

Show me my open tickets with status and priority
A well-built AI assistant can answer these in seconds by reading tickets, time entries, status history, and relationships, then summarizing the relevant information clearly.

Why This Matters for Engineering Teams
Speed of information access directly affects delivery. When answers are available immediately, teams spend less time coordinating and more time building. Risks surface earlier. Overruns become visible before they compound. Managers and engineers share the same source of truth without extra reporting work.
The key difference is context. Generic AI chat tools give generic answers. Project-aware AI understands your actual tickets, estimates, logs, and history. That makes the responses useful instead of vague.

Moving from Searching to Asking
The shift is subtle but powerful. Instead of searching through the tool, you ask the tool. The interface becomes conversational rather than navigational.
This doesn’t replace human judgment. It removes the low-value work of locating information so judgment can focus on decisions. Teams that adopt this approach report spending less time on status chasing and identifying problems faster. The data was always there. The bottleneck was access.

Looking Ahead
Project management tools are evolving from static boards into intelligent systems that understand the work happening inside them. The ability to ask complex questions and get accurate, contextual answers in seconds is becoming a practical advantage rather than a novelty.
The teams that benefit most will be the ones that stop treating information retrieval as a manual task and start treating it as a conversation. When your project data can answer for itself, everyone moves faster.

Why Software Estimates Are Always Wrong (And What Actually Helps)

Rubab Zahra — Tue, 18 Aug 2026 07:45:49 +0000

We’ve all been there.
You sit in planning. You carefully break down the work. You assign story points or hours. Everyone agrees the sprint looks reasonable. Two weeks later, the board is still full of half-finished tickets, and someone asks, “What happened to the estimate?”
The usual explanations are familiar: “Developers are too optimistic,” “We didn’t account for meetings,” or “Requirements changed.” While those things happen, they’re symptoms, not the root cause.
Estimation fails for structural reasons. Understanding those reasons is more useful than trying to get better at guessing.
The Planning Fallacy Is Real
In the 1970s, psychologists Daniel Kahneman and Amos Tversky described the planning fallacy: the consistent tendency to underestimate how long tasks will take, even when we have experience with similar work.
We focus on the best-case scenario and underweight historical data. Even when we try to correct for this by adding buffers, the buffers themselves are often optimistic. The result is a plan that looks clean on the board and fails in reality.
This isn’t a personal failing. It’s a predictable cognitive bias that affects almost every team.
Unknown Unknowns Dominate
Software work contains a high percentage of unknown unknowns — problems you don’t know exist until you start solving them.
Hidden dependencies, edge cases, integration surprises, performance issues, and unclear requirements only surface once implementation begins. Traditional estimation assumes most of the complexity is visible at the start. That assumption is usually wrong.
The more novel or interconnected the work, the larger the gap between what you can see in planning and what actually appears during development.
Estimates Are Forecasts, Not Commitments
One of the most damaging habits in software teams is treating estimates as commitments.
An estimate is a prediction made with incomplete information. A commitment is a promise. When we blur the two, pressure increases to lowball numbers, and then the team spends the sprint defending the original number instead of adapting to new information.
High-performing teams separate the two. They use estimates to forecast capacity and risk, and they protect delivery commitments more carefully.
What Actually Improves Planning
If perfect estimates are impossible, the useful goal is better systems for dealing with uncertainty.
Here’s what tends to help more than better guessing techniques:
Look at your own historical data.
Teams that track actual cycle time, throughput, and how often tickets exceed their estimates make better forecasts than teams that rely only on gut feel. The data already exists in most tools — it’s just rarely used well.
Make uncertainty visible.
Instead of a single number, surface the assumptions and open questions. High-uncertainty tickets should be treated differently from well-understood ones. Discovery work is often more valuable than pretending the path is clear.
Shorten the planning horizon.
The longer the forecast, the more it drifts from reality. Smaller increments and more frequent re-planning reduce the cost of being wrong.
Treat estimates as temporary.
Revisit them as new information appears. A plan that cannot change is more dangerous than an imperfect one.
A More Useful Sprint Planning Practice
Data-driven planning doesn’t mean removing human judgment. It means grounding judgment in evidence.
A healthier approach looks like this:

Review recent throughput and cycle times before committing work
Flag tickets that historically run over estimate
Identify known blockers and dependencies early
Adjust capacity based on real availability, not ideal availability
Update the plan as reality changes instead of defending the original numbers

This accepts that estimates will be imperfect and builds systems that recover quickly when they are.
The Role of Better Tooling
Most teams already generate useful signals — time logged versus estimated, how often work exceeds estimates, where blockers appear, and how long items sit in each status. The problem is usually visibility and accessibility.
When that information is hard to surface, teams fall back to intuition. When it’s easy to query and understand, planning improves.
This is one of the reasons we built conversational access to project data in Everia. Being able to ask questions like “Which tickets exceeded their estimates?” or “What changed on this project recently?” removes friction between the data and the decision.
The goal isn’t perfect prediction. The goal is faster learning from reality.
Final Thought
Estimation will always be imperfect because software development contains irreducible uncertainty. The teams that perform best are not the ones with the most accurate initial guesses. They are the ones that notice when reality diverges from the plan and adjust quickly.
Stop searching for a better way to be right on day one.
Build better ways to be less wrong over time.

Why We Stopped Building AI Prompt Workflows and Unified Our Stack Instead

Rubab Zahra — Tue, 28 Jul 2026 14:26:41 +0000

As developer teams, we've spent the last two years falling in love with AI, only to quietly fall out of love with the operational nightmare required to maintain it.

Every engineering leader in 2026 has had the same realization: LLMs are brilliant at generating code and structuring text, but terrible at maintaining context across your actual development stack.

To fix this, the community built a band-aid ecosystem. We wrote custom CLAUDE.md repository rules. We configured Anthropic's new ‘’Claude Skills’’ (SKILL.md folders) to automate recurring status reports. We spun up Model Context Protocol (MCP) servers to bridge our databases to LLM chat windows.

And for a month or two, it felt like magic. Then the maintenance tax kicked in.

The "AI Scripting" Trap

If your engineering workflow relies on a sprawling library of markdown prompts, API keys, and local context bridges, you haven't actually automated your engineering management; you’ve just given your developers a second full-time job as ‘’prompt engineers’’.

Here’s what typically happens in practice:

A developer opens a sprint task in Jira or GitHub Issues.
They realize they need a contextual update on the underlying requirements.
They open an external AI window, copy-paste the raw brief from a separate documentation wiki, paste in two recent commit logs, and trigger a custom prompt script.
They wait for the AI output, clean up any hallucinated assumptions, and manually paste the resulting updates back into the task board.

Notice the problem? The engineer is still acting as the manual human router. Every single time a requirement changes, a branch gets merged, or a QA test fails, the manual synchronization loop starts all over again.

Tool Sprawl is the Silent Killer of Velocity

According to recent European workspace productivity benchmarks, knowledge workers toggle between disconnected software apps more than 1,200 times per day. For engineering teams, this tool sprawl is even more brutal:

Product Requirements live in Notion or static Google Docs.
Active Sprints live in Jira or Linear.
QA Test Logs live in spreadsheets or legacy bug trackers.
AI Assistance lives in an isolated chat window on another monitor.

When your execution layer is split across four different database schemas, your AI assistant operates in a complete data vacuum. It can't "see" that a spec change made on Tuesday invalidates a QA edge case logged on Thursday.

To give AI real agency, you don't need more prompt templates or heavier MCP setups. You need a unified database architecture.

The Shift Toward Native Context Architecture

Instead of pasting context into external models, modern high-performing teams are shifting toward native contextual workspaces. This exact bottleneck is why platform-unified hubs like Everia are seeing rapid adoption across developer teams.

Rather than forcing developers to jump between siloed tools and manage fragile AI prompt scripts, Everia brings product specifications, active sprint tickets, and QA testing loops into a single unified database layer.
When your documentation and execution engines live under the same hood:

Requirements are natively linked to code tasks: When a product manager updates a requirement in the live spec, downstream developer tickets and QA targets update in real time.
AI operates with full project memory: Because the AI assistant sits directly on top of your live workspace history, asking for a "Weekly Sprint Rollup" or "Risk Assessment" requires zero context-pasting. The system already knows your entire git history, bug logs, and team updates.
QA is built into the sprint loop: Testers don't have to chase down developers on Slack to ask what was built; the QA checklist is attached directly to the pull request and original feature brief.

Stop Maintenance Sprawl Before It Consumes Your Sprint

Building custom developer tooling is fun; it’s in our DNA as engineers to automate our own workflows. But at a certain point, maintaining custom AI agent scripts and bridging disconnected point solutions becomes a massive distraction from actually shipping product.

If your team is spending more time writing SKILL.md files, debugging API bridges, and chasing down out-of-date specs across five tabs than writing production code, it's time to simplify your architecture.

Give your developers a single source of truth where requirements, execution, and AI intelligence live together seamlessly.

👉 Check out how Everia unifies docs, sprints, and QA in one intelligent workspace.

What does your team's current AI setup look like? Are you managing local prompt scripts and MCP servers, or moving toward unified workspaces? Let's discuss in the comments below!

Your AI Gives Confident Wrong Answers Because Your Docs Are a Mess — Not Because the Model Is Bad

Rubab Zahra — Wed, 08 Jul 2026 14:05:35 +0000

There is a specific kind of frustration that comes from asking an AI a question about your own project and getting an answer that is confidently, plausibly, completely wrong.
Not hallucination in the traditional sense; it is not making things up out of thin air. It is retrieving something real from your documentation and presenting it as current, even though it was superseded three sprints ago.
It is blending two contradictory sources because both matched the query semantically. It is telling you the payment module has five known issues when there are actually nine, because three of them only exist in a Slack thread the retrieval system never indexed. Most teams blame the model. The model is rarely the problem.
The Real Failure Point in RAG Pipelines
Retrieval-Augmented Generation works, in theory, by pulling relevant documents from your knowledge base and using them as context for the language model's response. The model's job is to synthesise and present. The retrieval system's job is to find the right sources.
The failure almost always happens at the retrieval layer, and more specifically, at the data layer underneath retrieval. Here is what most "AI over your docs" implementations look like in practice:
Documents dumped into vector DB
↓
Embeddings generated
↓
Query comes in
↓
Similarity search returns top-k chunks
↓
LLM synthesises response
This works fine for a static, well-curated knowledge base. It breaks down badly for the actual documentation reality of most engineering teams, which looks more like this:
A requirements doc written in week 1 that was partially updated in week 4 and never finalised
A troubleshooting PDF from a vendor that predates the current integration version
Jira tickets where the resolution is in a comment thread, not the ticket description
Slack threads where the actual decision was made but never written down anywhere official
A wiki page that three people edited in conflicting directions and nobody owns
A similarity search has no concept of which of these is current. It finds what is semantically relevant. Relevance and recency are completely different things, and naive RAG treats them as the same thing.
The Three Structural Problems
Problem 1 — No Source Hierarchy
Most RAG implementations treat all sources as equal. A decision made in a Slack thread last week has the same retrieval weight as a requirements document written six months ago, if both match the query embedding.
This is fine when sources are consistent. It produces confident wrong answers when they contradict each other, which, in active engineering projects, they frequently do.
The fix is not a better embedding model. It is source metadata that the retrieval system can actually use: timestamps, document type, status (draft / approved/superseded), and explicit supersession relationships between documents.
A requirements doc marked "superseded by REQ-v2" should not be retrieved as a current source. But if that metadata does not exist in your data layer, the retrieval system has no way to know.
Problem 2 — Chunk Boundaries Break Context
Standard RAG implementations split documents into chunks for embedding, typically 500 to 1000 tokens. The assumption is that relevant information clusters within those boundaries.
For technical documentation, this assumption fails regularly. A requirement might be stated in paragraph two, qualified in paragraph five, and have a critical exception noted in a comment thread that was never incorporated into the document itself. A chunk-based retrieval system picks up paragraph two, misses paragraph five entirely, and has no idea the comment thread exists.
The result is an answer that is technically grounded in a real source and substantively incomplete in a way that matters for the actual decision being made.
Problem 3 — No Relationship Graph Between Entities
This is the deepest structural problem and the one that is hardest to retrofit. In a well-structured engineering knowledge base, entities have relationships: a requirement links to the tickets that implement it, which link to the test cases that verify it, which link to the bugs that were found during testing, which link back to the requirement if the bug revealed a spec gap.
These relationships are the context that makes an answer actually useful. Most doc-over-AI implementations treat documents as independent artifacts. They retrieve based on semantic similarity to the query, not based on traversing the relationship graph between relevant entities.
So when you ask "what are the known issues in the payments module," you get whatever documents mention "payments" and "issues" in proximity, not a traversal of all tickets, bugs, test failures, and requirement gaps that relate to that module.
What Actually Fixes It
The answer is not a better model or a more sophisticated retrieval algorithm, though both help at the margins. The answer is fixing the data structure before the AI ever touches it.
Concretely, that means three things:

Explicit status and recency metadata on every source. Every document, ticket, and thread needs machine-readable status: current, draft, superseded, resolved, open. This is boring to implement and has nothing to do with AI; it is just good data hygiene that most teams skip because it requires discipline to maintain. Without it, your retrieval system is operating blind on the most important dimension of document quality.
Supersession relationships tracked explicitly. When a new requirements doc replaces an old one, that relationship should exist in the data layer, not just be inferable from timestamps. When a Jira ticket's resolution contradicts the original description, the resolution should be the canonical source, not a comment with equal weight to everything else.
Entity relationships as first-class data. Requirements link to tickets. Tickets link to test cases. Test cases link to bugs. Bugs link back to requirements. If these relationships exist in your tooling, a well-designed retrieval system can traverse them rather than doing flat similarity search. The answer to "known issues in the payments module" becomes a graph traversal, not a keyword hunt. The Tool Layer Problem Here is the uncomfortable part: most teams cannot implement this properly because their knowledge lives across four or five tools with no common schema and no shared relationship layer. Requirements are in Confluence. Tickets are in Jira. Test cases are in TestRail. Bugs have their own workflow. The relationships between them exist in someone's head and in informal cross-tool links that were never designed to be machine-readable. When you try to build "AI over your docs" on top of this structure, you are not building a knowledge system. You are building a similarity search over a pile of disconnected artifacts and hoping the model is smart enough to compensate for the missing structure. It is not. It is confidence, and confidence is not the same as correctness. We ran into this while building the knowledge and Q&A layer for Everia, the tool we work on day to day. The insight that changed how we thought about it was that the AI's job should be retrieval and citation from structured data, not inference over unstructured data. Once requirements, tickets, test cases, and docs all lived in one schema with explicit relationships between them, the question "what are the known issues in the payments module" became a structured query with a verifiable answer, not a retrieval gamble. Not every team is going to rebuild their tooling stack to fix their RAG implementation. But the principle applies at whatever layer you can act on it: the more structure you can add to your data before it hits the retrieval system- explicit status, supersession relationships, entity links- the less work you are asking the model to do, and the less often it will do that work confidently wrong. The Quick Audit If you are running or evaluating an "AI over your docs" setup, these four questions will tell you most of what you need to know:
Does your retrieval system know which sources are current versus superseded? If the answer is "it can probably infer from timestamps," that is a no.
Can your system distinguish between a document's original content and its amendments? Requirements change. Tickets get updated. If the AI is retrieving the original version of a document that has been materially changed, it is working from stale ground truth.
Are entity relationships traversable or just inferable? If the link between a requirement and its test cases exists only as a cross-tool URL someone pasted into a comment, it is not traversable. It might as well not exist from the retrieval system's perspective.
Can every answer be traced back to a specific source with a specific status? If your AI cannot cite the exact document and version it is drawing from, you cannot verify whether the answer is current. Confidence without citation is not a knowledge system — it is a very convincing guess.

Curious how others have approached the source recency and supersession problem specifically — it feels like the least-discussed failure mode in RAG implementations but consistently the most expensive one in practice. What have you found that actually works?

Why "Just Ask the AI" Doesn't Work When Your Docs Are Scattered Across 6 Tools

Rubab Zahra — Tue, 30 Jun 2026 07:53:31 +0000

A teammate asked a simple question last sprint: "What are all the known issues in the payments module?"

Should've been a 30-second answer. Instead, it turned into a 45-minute archaeology dig, a Word doc called "Payments - Known Issues," a troubleshooting PDF from the payment provider, an integration guide, a handful of Jira tickets, and two separate Slack threads where the actual root causes were discussed but never written down anywhere official.

By the end, we thought we had the full picture. We weren't actually sure.

The "just plug in an LLM" trap.The obvious reaction here is "just connect ChatGPT to your docs." A lot of teams do exactly this, wire up a vector DB, dump every doc into it, and call it done.

It works, until it doesn't, for a specific reason: most LLM-over-docs setups have no concept of source reliability or recency. If your "Known Issues" doc says something was fixed, but a Jira ticket from yesterday reopened it, a naive RAG setup will happily blend both into a confident-sounding answer that's wrong. It doesn't know one source is stale.

The second problem is scope. A generic LLM plugin bolted onto your docs folder doesn't know what a "module" is in your codebase, doesn't know which tickets are linked to which requirement, and doesn't know that a Slack thread from three weeks ago superseded the PDF from the vendor. It just does a similarity search and hopes for the best.

What actually closed the gap for us

The fix wasn't a smarter model. It was making the underlying data structured before the AI ever touches it, so the AI's job becomes retrieval and citation, not guessing.

Concretely, that means: Every doc, ticket, and test case lives in one schema, not six separate tools with six separate APIs
Tickets are explicitly linked to the requirements and components they affect, not just tagged with free-text labels
When a doc gets superseded by a newer source (a fixed ticket, an updated integration guide), that relationship is tracked, not left for the AI to infer from timestamps alone
Every answer the AI gives links back to the exact source paragraph or ticket it pulled from, so you can verify it in one click instead of trusting it blindly

We ended up building this into Everia (the project tool we use day-to-day) because it was easier to fix at the data layer than to keep tuning prompts across six fragmented sources. Asking "what are the known issues in the payments module" now pulls together docs, tickets, and Slack threads, returns a cited list, and takes about 8 seconds instead of 45 minutes.

The general lesson, tool-agnostic. Most teams skip straight to the model and wonder later why the answers are confidently wrong half the time. If your engineering velocity is constantly taking a backseat to administrative tool configuration, it's a sign your underlying environment needs structural consolidation over superficial plugins.

If you're building or evaluating any "ask your docs" feature, the question worth asking isn't "which LLM is best at this." It's: does the underlying data know what's current, what's superseded, and where each fact actually lives?

An LLM is only as trustworthy as the structure underneath it. Most teams skip straight to the model and wonder later why the answers are confidently wrong half the time.

Curious if others have solved the "stale source vs. current source" problem differently: versioning docs explicitly, tagging deprecated content, something else? What's worked for your team?