Have you ever opened an application log, found a long stack trace, and spent the next hour trying to figure out what actually went wrong?
As developers, we get used to reading exceptions. But understanding an error quickly is not always easy, especially when the logs come from a background worker, a third-party API, a message consumer, or a service running in production.
Sometimes the exception tells us exactly what happened. Other times, it only gives us the starting point for an investigation.
That got me thinking: What if developers could ask an AI assistant to explain an error without needing to send their logs to a hosted AI service?
That is the idea behind LogLens AI.
What I Built
LogLens AI is a small AI-powered debugging assistant designed for .NET developers.
The goal is simple: paste an exception or log excerpt, ask for an explanation, and receive a structured response that helps you investigate the problem.
The assistant is intended to provide:
- Plain-English explanations: What the exception means.
- Likely causes: Possible reasons the error occurred, based on the supplied evidence.
- Debugging steps: What to inspect next.
- Suggested fixes: Potential changes to investigate, rather than unverified guarantees.
- Evidence and limitations: Which parts of the log support the explanation and what additional information might be needed.
For example, a developer could submit a NullReferenceException from a background service and ask the tool to explain the likely cause, identify what to inspect, and suggest a way to prevent the same failure.
The first version focuses on .NET exceptions and application logs rather than trying to become a general-purpose AI agent.
Demo
Code
GitHub repository: https://github.com/Dianaiminza/LogLensAI
How I Built It
I chose a small architecture that keeps the application understandable and easy to run locally.
The technology stack
- C# and ASP.NET Core Minimal API for the backend.
- HTML, CSS, and JavaScript for the initial interface.
- Ollama for local model inference.
- An open-weight language model compatible with the local inference setup.
- xUnit for automated tests.
- Docker for optional containerised setup.
The API receives the log excerpt, validates the request, applies basic sanitisation, and constructs a prompt asking the model to explain the error in a consistent format.
The model returns the analysis, which the interface displays to the developer.
Why use a local model?
Sending logs to an external service can be a concern when they contain internal hostnames, account identifiers, access tokens, or other sensitive information.
Running inference locally offers a way to keep the model interaction on the developer's machine. It does not eliminate every privacy or security risk, so the application also needs input validation, secret redaction, and careful handling of diagnostic data.
Why keep the first version small?
It would be tempting to introduce agents, multiple model providers, vector databases, and complex orchestration immediately.
But the first question is much simpler:
Can a developer provide an ordinary .NET exception and receive an explanation that genuinely helps them debug it?
That is the core workflow I want to build and test first.
Why Does Open Innovation Matter?
Open innovation matters because useful developer tools should not be limited to teams that can afford expensive subscriptions or proprietary infrastructure.
Open-weight models, open-source libraries, and community-maintained tools make it possible for individual developers to experiment, learn, and build practical applications using technology that is accessible to them.
For a project like LogLens AI, openness has several benefits:
- Accessibility: Developers can experiment with local AI without making a hosted AI subscription a requirement.
- Transparency: The source code can be inspected, tested, and improved by the community.
- Adaptability: Developers can modify the prompts, parsing logic, and model configuration for their own workflows.
- Community learning: Contributors can learn about ASP.NET Core, local inference, prompt design, testing, and responsible AI integration in one small project.
Open innovation is not just about making source code public. It is also about making the technology understandable, usable, and open to improvement.
The initial test cases will include:
- A
NullReferenceException. - An HTTP request failure.
- A database connection exception.
- An invalid or empty request.
- A model service that is unavailable.
- A log excerpt containing a test credential that should be redacted.
The aim is not to prove that AI can replace debugging. It is to see whether a small, local-first assistant can make the initial investigation faster and clearer.
What's Next?
The first milestone is a working local application with a simple interface, a functioning model integration, and automated tests.
After that, possible improvements include support for structured JSON logs, configurable redaction rules, exportable diagnostic reports, and Docker-based setup.
I would also like to hear from .NET developers about which errors they spend the most time investigating and what information they would want an AI debugging assistant to provide.
If you could automate one frustrating part of debugging a .NET application, what would it be?
Built for the DEV Community's Hacktoberfest Open-Source AI Challenge: Side Hustle!
Top comments (0)