GForge Insights
RAG AI Isn’t The Answer – By Itself
At GForge, we’ve been developing AI-enhanced DevOps and collaboration tools for almost a year—and much of that journey has meant navigating the ever-shifting landscape of AI hype versus real help.
Retrieval-Augmented Generation (RAG) has been central to our research and engineering efforts, riding its own roller coaster through the hype cycle. So when I read the Reddit post “After Building Multiple Production RAGs, I Realized – No One Really Wants Just a RAG,” it hit home. We’ve seen this pattern many times before.
The RAG Reality Check
Here’s the usual story:
The team gets excited about RAG. They picture a system that understands intent, retrieves the right documentation, and delivers precise, conversational answers—ChatGPT for your private knowledge base.
Instant value. Simple implementation.
Then they build it… and realize that “just a RAG” fixes maybe 30% of the problem.
A full solution needs query rewriting, reasoning, governance, audit trails, access control, and knowledge base management—plus integration into real workflows. The prototype that looked easy becomes a production system requiring deep coordination between data, context, and people.
“Deploy a RAG in a weekend” turns into “build a coherent knowledge platform that understands your organization.”
What RAG Actually Reveals
Here’s what teams building production RAG systems keep discovering:
Teams building production-grade RAG systems learn fast:
- Your knowledge base is broken. Documentation is inconsistent, outdated, or locked in Slack threads and people’s heads. Garbage in, garbage out.
- Retrieval isn’t reasoning. RAG finds information—it doesn’t interpret it or recommend next steps. Users need multi-step reasoning and reformulation, not just retrieval.
As one Reddit commenter put it:
“Stakeholders don’t just want context retrieval—they want reasoning, reformulation, and memory.”
Another added:
“Every serious RAG project I’ve seen eventually drifts toward something more agentic.”
They’re right. The easy tool exposes the hard problem.
Anybody Remember E-Forms?
In the 1990s, JetForm promised to digitize enterprise paperwork. The idea was simple: turn paper forms into online forms and automate the workflow.
But the moment organizations built those digital forms, they found the simple version wasn’t enough. They needed validation, branching logic, data cascading, versioning, and backend integration. The “form” was just the start; the real work was system integration.
Adobe eventually acquired JetForm, folding it into a broader suite of document and workflow tools. The lesson: the tool reveals the problem—but never solves it by itself.
RAG is following the same path.
RAG’s Real Lesson
RAG looks simple because it targets a shallow need:
“I want ChatGPT to know my documents.”
That’s as deceptively simple as saying:
“I want my paper forms online.”
Once you implement it, you uncover deeper issues—data structure, workflow coherence, governance, and reasoning—that demand a holistic system, not a bolt-on feature.
Why Fragmentation Looks Like Simplicity (Until It Doesn’t)
This pattern echoes across modern tool stacks:
- Slack handles communication—but not project traceability.
- Jira tracks issues—but not code reviews.
- GitHub manages code—but not deployment pipelines.
- Jenkins deploys—but doesn’t connect tasks to results.
Each tool promises simplicity on its own. Together, they create integration debt—fragile connections through APIs, plugins, and scripts that break whenever one tool updates.
To regain visibility, you add yet another tool to tie them together. And suddenly, your “simple stack” is a maintenance ecosystem of connectors instead of a product platform.
What True Integration Looks Like
When your work lives in a single, coherent platform, relationships between artifacts are native, not stitched together.
A task knows the code that fixed it.
The deployment knows who committed it.
The conversation thread knows the context behind the decision.
This isn’t magic—it’s shared data and intentional design.
That’s why the best teams stop bolting tools together and instead adopt a unified platform that handles planning, collaboration, and delivery natively.
The GForge Difference
GForge was built from the ground up to unify your work. It includes nearly everything you’d expect from Slack, Jira, GitHub, and GitLab—but without the integration tax.
- One data model. Every task, commit, and discussion shares context.
- One platform. No brittle APIs or plugin maintenance.
- One flow. Plan, code, and deploy without leaving your workspace.
The real answer to tool fragmentation—and to “just a RAG”—isn’t adding more layers.
It’s choosing a platform designed for your work from the start.
Ready to consolidate your stack? See why teams are switching from Jira, GitHub, GitLab, and Atlassian.
Why Do We Keep Choosing Complexity?
I watched a team spend a year building an event-sourced order system. By year two, half the events were no longer relevant to the business, the audit log had become write-only because nobody trusted its integrity, and they were maintaining a dozen projections just to keep the lights on. Three years after launch, they rewrote the whole thing as a boring CRUD app with a simple changelog table—and shipped it in three months. They shipped it in three months.
The architect who championed event sourcing had moved on by then. The team that remained ate the cost.
The story is familiar to software teams everywhere: we invest in complex systems and DevOps tools that promise scalability but deliver more moving parts to maintain.
Chris Kiehl wrote about this exact dynamic—not event sourcing per se, but the broader pattern. He built an event-sourced system, discovered it was harder than expected, and had the honesty to say so publicly. Most people don’t. They just quietly maintain the complexity they chose.
His closing question cuts through all the noise:
“For which core problem is event sourcing the solution? If you can’t answer that concretely, don’t do it.”
If the answer is vague—”auditability,” “flexibility,” “it seems cool”—a simple history table solves 80% of the value with 5% of the complexity.
Why This Keeps Happening to Software Teams
The pattern isn’t unique to event sourcing. It’s everywhere. A prestigious architectural pattern or project management platform gets championed by someone influential. It is smart—in the right context. But the context gets lost. Teams adopt it because “everyone uses it,” or because it seems like the forward-thinking choice. By the time they realize it doesn’t fit their workflow, they’re already committed.
And incentives are misaligned. The advocate gets credit for being visionary. The maintenance team pays the long-term cost. That asymmetry keeps complex software ecosystems alive even when they’re clearly failing.
And here’s the uncomfortable part: the incentives are misaligned. The person who advocated for the new pattern gets credit for being visionary. The team maintaining it four years later bears the cost. This asymmetry is why prestigious patterns persist even when they’re clearly failing.
The same thing happens with tools. A startup uses Jira because it scales. A mid-market company uses it because the startup did. A mature team uses it because “everyone uses it”—and by then, they’re stuck. They’ve built workflows around its constraints. Migrating looks catastrophic. So they stay, paying the integration tax: tracking deployment progress in Jenkins, planning in Jira, code review in GitHub, and spending 40 minutes a day context-switching between them.
It’s the classic DevOps platform sprawl problem—teams juggling five “integrated” tools to do the work one well-connected systemcould handle.
They know it’s inefficient. But the alternative feels riskier than staying put.
What Actually Matters
Before you commit to something that constrains your future—whether it’s an architectural pattern, a tool, or a whole platform—ask these questions honestly:
- What problem does this solve, concretely? Not theoretically. Concretely. If you can’t articulate it in a sentence without hand-waving, you’re probably not solving it.
- Are we buying capability or bloat? Does it integrate cleanly with the rest of our stack, or are we buying integration complexity along with it?
- Who pays if we’re wrong? If it’s not the people who championed it, that’s a red flag.
These aren’t flashy questions. They won’t make you sound forward-thinking in a meeting. But they’re the difference between a choice that scales with your business and a choice that becomes technical debt. These questions apply as much to software collaboration tools as to architecture choices.
Try This Instead
- Start with the smallest thing that works. CRUD + a changelog/history table first. Add sophistication only when a real constraint shows up.
- Time-box experiments. If the promised benefits aren’t visible within a fixed window, roll back.
- Write the de-adoption plan before adoption. “How would we back out of this in three months?” If you can’t answer, don’t start.
- Make incentives symmetrical. The champion should own maintenance outcomes for at least one cycle.
When your DevOps and project management tools evolve with your team instead of ahead of it, you stay fast—and stay sane.
Read Kiehl’s full post.—it’s honest, well-reasoned, and exactly the kind of writing we need more of online: admitting when the cool thing wasn’t the right thing.
Ready to simplify your stack? See why teams are moving away from Jira, GitHub, GitLab, and Atlassian to a unified platform. Or try GForge free for up to 5 users.
GForge 25.0 Released!
The GForge Group team is happy to announce the release of GForge 25.0! This is primarily a feature release, though it includes a number of bug fixes and infrastructure updates.
Key Highlights in 25.0
- Core System
- Added support for Microsoft SSO (oAuth). We already supported this for SaaS, this feature is for on-prem customers who want to configure their GForge instance to only use Microsoft (and not others like Google, etc)
- Continued work on the migration from AngularJS ot Angular
- Fixed an issue with Postfix not restarting cleanly during GForge restarts.
- Site Admin
- Site Admins now receive email and in-app notifications when a user account is locked, enabling more proactive support.
- Added configuration options related to authentication:
- Password aging rules
- Password reuse rules/restrictions
- Notification preferences on account lockouts
- Introduced a new cron job administration page allowing Site Admins to view and manage the status of all GForge cron jobs.
- Fixed a bug where the User Administration page incorrectly displayed groups.
- Version Control
- Git Blame is now available while browsing Git repositories.
- Fixed a bug where switching from Subversion to Git still allowed commits to the SVN repository.
- Corrected the example provided for using Subversion over SSH.
- Tickets
- Mass Update now allows the addition of tags to multiple tickets (note: tag removal is not supported yet)
- The Planning Board now includes direct links to it’s underlying data sources.
- Fixed a bug where saved queries spanning multiple sprints would fail to load properly.
- Improved performance when displaying tickets with high activity (e.g. follow-ups, commits).
The 25.0 ChangeLog details all the changes made in this release.
GForge 23.1 Released!
The GForge Group team is happy to announce the release of GForge 23.1! This release is primarily a bug-fix release with a fair number of new features included!
Key Highlights in 23.1
- Single Sign-On – Our Single Sign-on support now support numeric external IDs (used by a few, specific SSO vendors).
- Tickets – Improvement to planning boards specifically when showing/hidding specific rows and columns.
- Security – Fixed a number of security vulnerabilities found by both internal and external audits.
- Angular 14 Migration – While this doesn’t impact our customers in any obvious way, this is a large undertaking to pay some technical debt.
- Releases – For non-contributing project members (e.g. project members associated with but not contributing to a project) releases not specifically marked as “Released” are now hidden. This allows for releases to be better planned without giving access to them to specific members. Also, users may now add a “watch” to a release to get updates when the release changes. Finally users only see tickets on a roadmap unless they are contributors.
The 23.1 ChangeLog details all the changes made in this release.
GForge 23.0 Released!
We’re happy to announce the immediate availability of GForge 23.0. This release is primarily a bug-fix release with a fair number of new features included!
Key Highlights in 23.0
- SSO – Many improvements to our Single Sign-On support.
- Security – Fixed a number of security vulnerabilities found in an audit.
- Angular 14 Migration – While this doesn’t impact our customers in any obvious way, this is a large undertaking to pay some technical debt.
- Releases – We’ve made a number of improvements to the visibility of releases, particularly in the case where you want to prevent a release from being accessible but want to keep all its associations to tickets, etc intact.
The 22.2 ChangeLog details all the changes made in this release.
Health Checks: Tasks
This category looks at Tracker Item volume, status, and history.
Note: Because a Project can contain multiple Trackers (for, e.g., Development Tasks, Customer Support, Server List, and whatever else you need), each check can generate multiple fail or warning messages.
Long-Running Tasks
Definition: The number of tasks that have been open longer than 90 days, with some activity in the past seven days.
What it means: Tasks that linger for weeks or months clog your Standup, Burndown, and planning process. These tasks can also be a quiet drain on team productivity – making slow progress on a task requires way more task-switching than small, focused ones.
How to fix? Look at each long-running task, and ask these questions:
- Is this still worth doing? Close it if it’s not valuable.
- Is the task too vague? Clarifying the goal can make it easier to reach.
- Is the task too broad? Create sub-tasks that can go faster.
Recycled Tasks
Definition: The number of tasks that are currently open, but have been closed more than twice in the past.
What it means: Much like Long-Running Tasks, Recycled Tasks get in the way of good planning and tracking. They’re usually re-opened unexpectedly, usually because “done” is poorly-defined or regularly gets “un-done” somehow.
How to fix? Much like Long-Running Tasks, look at each Recycled Task and see if it should be refined in scope or killed permanently. Some tasks that keep coming back have an underlying technical or business-process cause – attack that instead of just changing the band-aid over and over again.
Stale Tasks
Definition: Tasks that are currently open and assigned or in a Sprint, but with no activity in the past 30 days.
What it means: Assigning a task or adding it to a Sprint represents a commitment to completing that Task. Tasks that sit for weeks with no progress are taking up attention and Story Points from other priorities.
How to fix? For each Stale Task, do one of the following:
- Bump the priority
- Re-assign to someone with bandwidth
- Un-assign, and come back to it later
Health Checks: Commits
This category of health checks focuses on the code you check into your GForge Next project, how it relates to task management, team and file sizes.
Commits Per Tracker Item
Definition: The number of separate commits associated to each Tracker Item in your project. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: Having too many commits makes it harder to understand the associated Tracker Item’s history later on. It can also skew Sprint, Burndown, and Release metrics to look bigger or smaller than they really are.
How to fix? Although you can add or remove associations between a commit and a Tracker Item, it’s better to look forward than try to change history. When planning a Sprint or Release, consider the size of each Tracker Item, and break them down into smaller tasks that might affect fewer files, or involve fewer iterations for each TI.
Commits with Tracker Items
Definition: The percentage of commits in the last 90 days that are associated (or not) to a Tracker Item. Also checks for commits that are tied to more than on TI.
What it means: Pushing commits without an associated task is an easy way to mess up your code base over time. It’s also bad for team collaboration and Sprint and/or Release tracking.
How to fix? To fix existing commits, you can create Tracker Items, and associate them using the SCM Commits listing. Click a commit and use the “Tracker Item Associations” section at the bottom of the commit details view.
You can (and should) also fix the process for pushing commits to your project:
- Go to the Project Admin SCM tab, and choose “Require” for the “Associate Tracker Items” option.
- You might also check the “Restrict Tracker Item Associations” setting, depending on whether you want to allow associations between commits in this project and Tracker Items from other projects.
- Usually, this setting should be “Yes” to keep it to the current project.
Committers
Definition: The number of users with commits in the last 90 days, and the proportion of all commits made by each user.
What it means: For smaller projects (with only one or two contributors) this check won’t mean much. For full-sized Agile teams (4-5 contributors) or larger, traditional teams (10 or more contributors), this check can help you understand if work is balanced properly between team members.
How to fix? If you’re not using Tracker Items (and requiring that commits tie to them), then you should start right away. Having a specific task should be required in order to make code changes anyway, and an official task list lets the Product Owner, Scrum Master, or even the team itself to balance tasks among contributors by size, functional area and dependencies. Proper task balancing will lead to balanced commits from the team.
Files Per Commit
Definition: The number of files changed (or added, or removed) by each commit. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: In general, commits should touch less than ten files. Large commits (many files and/or many lines of code) are harder to review, harder to understand later, and more likely to cause merge conflicts with other commits.
How to fix? This is another one where what’s done is done. Going forward, make sure that the team is doing proper analysis on task sizes during planning, and on the changes to be made when working each task. If a specific task requires changing many files, try to find a way to iterate on it, changing a few files in one commit, reviewing/merging that commit, then moving on to the next set of files.
Of course, sometimes you’ll just need to bite the bullet – a breaking change in a dependency/library, an urgent security fix, etc. But those hefty commits should be the exception and not the rule.
Introducing: Project Health Checks
GForge Next has everything that teams need to plan, execute, and document their work. You can start with simple features like kanban and source control, add workflow steps, code reviews and wiki articles, even integrate your build process and Zoom meetings.
But embracing all of these features and flexibilities can eventually make anyone feel a little lost:
On the one hand, we want all of these features. We need them. OTOH, we can’t (or really, really don’t want to) pay for training or plugins, or spend hours in Stack Overflow, to get the best use out of the tools we’re already paying for.
What we really need is a tool that tells us how we’re doing as we use it. Automatically. One that grows with our usage, making recommendations that apply to our process. Most importantly, one that doesn’t get in the way of actual productivity.
That’s why, starting in version 23.0, we’re rolling out a new item in Project Admin Reports called Project Health Checks. This new report will be run automatically against each active project in GForge Next, and provide insight, metrics and advice on features you may want to use, configuration options that need tweaking, or processes that may not be working for you. All of these Checks are designed to help you spend less time on your tools and more time getting things done.
Data + Analytics = Advice
Because GForge Next is a single service (with a single API and database), we can take a comprehensive view of each project – from users and roles, to releases, tasks and sprints, to the code changes, and even the configuration of access controls, workflow and integration settings – and look for patterns across all types of related data.
Report Format
The Project Health Check is run automatically once a month, and all project admins are notified when results are available. Each report is organized into Categories, Checks, and Results:
In the screen shot above, “Commits” is the Category. Other Categories include Tasks, Sprints/Releases, Backlog, and Project Configuration, and more are planned for later this year.
Within each Category are a number of Checks, each of which looks for a single kind of pattern, warning, or possible improvement.
Each Check can yield one or more Results, depending on how many Users, Trackers, or other related data appears in your Project.
You can collapse and expand Categories and Checks. Collapsed sections will show summary counts of the Results that are hidden, like the colored boxes at the top of the report.
Result Types
Checks fall into these categories:
- Green boxes are OK/Success results, which shows that your project is performing well in this area.
- Yellow boxes are Warning results. These don’t necessarily indicate a problem, but a trend that’s going the wrong way, or an easy opportunity for improvement.
- Red boxes are Failed results. These results may point to a problem with your process, or a measurement that is way outside recommended boundaries.
Navigation and Customization
For the Warning and Failure Results, clicking on the result will take you to a blog post, wiki article or video with details about the issue, why it might affect you, and how to fix it.
Our Health Checks make some assumptions about projects and teams in general, and not all of these assumptions will apply to your situation. If there are Checks or Results that don’t make sense, you can turn them off completely, and exclude them from totals and future Health Check reports. Disabled Checks can be re-enabled at the bottom of the report.
What’s Next?
As we start running Health Checks for SaaS customers, GForge staff will be contacting project admins directly to offer personalized walkthroughs of the data, discuss fixes, process improvements, or GForge Next features that might help, and get feedback on wording, content, and future Checks to be implemented. SaaS users can also use the “Get Support” button anytime to request help with this new feature.
GForge 22.2 Released!
We’re happy to announce the immediate availability of GForge 22.2. This release is primarily a bug-fix release with a fair number of new features included!
Key Highlights in 22.2
- HTTP/2 Support added – To learn more about the benefits of HTTP/2 here.
- Tickets can now be filtered based on whether or not they have attachments.
- Tickets can also be filtered based on they have a parent and/or child ticket.
- Users can now react (thumbs up/down) on comments.
- File Uploads – Fixed the issue where file uploads would die after 20MB regardless of the configured value.
- REST API – Updated missing and incomplete documentation.
- Site Admin – Searching projects by name has been improved.
- Browse Projects – Users could only search for projects they knew about in prior GForge versions. This version allows users to browse all projects they have access to.
Looking Ahead to 23.0
We want to point out some important changes coming in GForge 23.0 (spring 2023). This version will add support for Kubernetes and it is going to have a new ticket editor. We’d love to get some feedback on the new editor before it is released so if you would like a sneak peak you can register a test project or you can send us an email and we can shoot over some screenshots. Additionally, for you users interested in Kubernetes, if you have any specific questions or would like to beta test this in your environment we’d love to hear form you. Just contact us at feedback@gforgegroup.com.
The 22.2 ChangeLog will help you understand the changes you can expect.