Most .NET developers eventually run into document-processing requirements.

Maybe you’re generating invoices, building a reporting system, creating contracts from templates, or converting Word documents to PDFs at scale. On paper, many Word libraries seem to offer similar capabilities. They all support document creation, editing, mail merge, and conversion.

The challenge begins when projects evolve. 

As document-processing requirements grow, factors such as mail merge complexity, document conversion fidelity, API usability, and deployment flexibility can influence library selection.

This blog compares Syncfusion Word Library and Aspose.Words for .NET across the areas that matter most in production applications.

Rather than focusing solely on feature checklists, this blog compares both libraries across document automation, conversion accuracy, baseline performance in representative document-processing operations, developer experience, and deployment options. The goal is to provide a balanced, evidence-based comparison that helps .NET teams choose the right library for their needs.

Streamline your Word document workflow effortlessly with Syncfusion’s robust Word Library.

Explore Now

Syncfusion Word Library vs. Aspose.words at a glance

Both libraries support modern .NET applications and .NET Framework environments. Check the respective version-specific system requirements before deployment.

Quick setup

Library	NuGet package	Installation command
Syncfusion Word Library	Syncfusion.DocIO.Net.Core	Install-Package Syncfusion.DocIO.Net.Core -Version 32.2.4
Aspose.Words	Aspose.Words	Install-Package Aspose.Words -Version 26.8.0

Once installed, both libraries can create and save Word documents with only a few lines of code.

What developers usually care about

Most teams aren’t looking for a library with the longest feature list. They’re looking for one that helps them solve business problems quickly and reliably.

The following comparison focuses on common factors that influence library selection.

Area	Syncfusion Word Library	Aspose.Words
Performance	In the benchmark described later in this article, Syncfusion showed faster execution times for Word-to-PDF conversion, Word-to-Image conversion, mail merge, document comparison, and merge operations.	Performed well across all scenarios and was faster in DOCX-to-DOCX save operations.
Document automation	Mail merge, document comparison, find and replace, form filling, bookmarks, content controls, track changes, ink, SmartArt, document protection, and document conversion.	Mail merge, document comparison, find and replace, form filling, bookmarks, content controls, ink, SmartArt, document protection, track changes, and document conversion.
API experience	Provides a broad API surface with consistent method names and extensive documentation.	Provides a broad API surface with extensive document-processing functionality.
Cross-platform deployment	Supports .NET Framework, .NET, Blazor, MAUI, and deployment across Windows, Linux, macOS, Docker containers, and cloud environments.	Supports .NET Framework and .NET, Blazor including deployment across Windows, Linux, macOS, Docker containers, and cloud environments.
Document conversion	Supports conversion to PDF, HTML, Markdown, RTF, and image formats.	Supports conversion to PDF, HTML, Markdown, RTF, and image formats.
Documentation & support	Extensive documentation, API reference, and dedicated customer support channels through the Syncfusion support portal.	Documentation, API reference, and customer support channels through the Aspose support portal.

Acquire an in-depth understanding of Syncfusion's Word Library, exploring its impressive features through its comprehensive documentation.

Read Now

Feature comparison

When building document-centric applications, developers often rely on more than simple document creation.

Here’s how the two libraries compare across commonly used capabilities.

Feature	Syncfusion Word Library	Aspose.Words
Mail merge	Supported	Supported
Merge documents	Supported	Supported
Split documents	Supported	Supported
Compare documents	Supported	Supported
Bookmarks management	Create, modify, delete, navigate, and extract bookmark content as Word document elements.	Create, modify, delete, navigate, and retrieve bookmark text content only.
Find and replace	Supported	Supported
Content controls	Supported	Supported
Charts	Supported	Supported
Document protection	Supported	Supported
Track changes	Supported	Supported
LaTeX equation support	Supports creating mathematical equations directly from LaTeX syntax within Word documents.	Supports Word equations, but does not provide direct LaTeX-to-equation generation within Word documents.
Digital signature (Word documents)	Not supported for OOXML/Word document digital signatures (planned on the roadmap).	Supports OOXML/Word document digital signatures, including certificate-based signing.

Both libraries cover common Word-processing requirements, but two differences stand out.

• The first is equation authoring. Syncfusion can generate mathematical equations directly from LaTeX syntax within Word documents, which can be valuable for scientific, engineering, educational, and research content. While Aspose.Words supports mathematical equations in Word documents, the Aspose.Words .NET API does not currently expose an equivalent direct LaTeX-to-equation generation process within Word documents.
• The second is Word document digital signatures. Aspose.Words offers certificate-based signing for OOXML/Word documents, which is relevant for compliance and document-of-record processes. Currently, Syncfusion’s .NET Word Library (DocIO) does not provide Word-level digital signature signing through its public API. Support for Word document digital signatures is planned and currently on the Syncfusion product roadmap.

Performance comparison

To better understand how the libraries perform under common document-processing operations, the following benchmarks were conducted under controlled conditions.

Test environment

Parameter	Details
Operating System	Windows 11 Enterprise 24H2
Processor	AMD Ryzen 5 7520U with Radeon Graphics
Memory	16 GB RAM
.NET Runtime	.NET 10
Syncfusion package	Syncfusion.DocIORenderer.Net.Core version 32.2.4
Aspose package	Aspose.Words version 26.8.0

Experience the interactive demos to see the vast functionality of Syncfusion’s Word Library for yourself.

Try Now

Benchmark parameters and workloads

• Runs: Each operation was executed 10 times, and the average execution time is reported.
• Measurement unit: All results are reported in seconds.
• Metric reported: Mean (average) execution time across all runs.
• Input document: Details of the input documents used for each benchmark are provided alongside the corresponding results.
• Benchmark scope: The benchmark focuses on common document-processing operations using tables, images, fields, charts, and text. Performance may vary when processing larger documents, complex layouts, tables, images, charts, tracked changes, or high-volume batch workloads.
• Build configuration: Both libraries were tested in release builds with default configuration.
• Timing: Measurements capture only the execution time of the target operation. Application startup and other one-time initialization overhead were excluded wherever possible.
• Hardware/runtime: See the benchmark environment details provided above.

Results may vary depending on document complexity, hardware resources, platform configuration, and processing requirements.

Operation	Syncfusion (sec)	Aspose.Words (sec)	Lower execution time
Word-to-PDF (4 pages)	0.523	0.746	Syncfusion
DOCX save (4 pages)	0.839	0.309	Aspose
Clone and merge (4 pages)	0.021	0.034	Syncfusion
Mail Merge (10 nested records)	0.078	0.126	Syncfusion
Compare Documents (4 pages)	0.121	0.153	Syncfusion
Word-to-Image (4 pages)	0.927	3.289	Syncfusion

What these results mean

For workloads similar to those tested, faster processing can reduce per-document execution time and potentially improve throughput.

Across the benchmark scenarios tested, Syncfusion delivered faster times for Word-to-PDF, Word-to-image, mail merge, document comparison, and clone-and-merge operations, while Aspose.Words remained faster for DOCX save operations.

Note: For more benchmark details, refer to the following resources:
• Word Library performance benchmark results
• Word to PDF performance benchmark results
• Convert Word to Image in .NET Word Library

Run across modern .NET environments

Modern applications run across cloud platforms, containers, and multiple operating systems. Both Syncfusion .NET Word Library and Aspose.Words support flexible deployment scenarios, helping teams build and scale document-processing solutions across web, server, and cloud environments.

Environment	Syncfusion .NET Word Library	Aspose.Words
.NET Core	Supported	Supported
.NET Framework	Supported	Supported
Linux	Supported	Supported
Docker	Supported	Supported
macOS	Supported	Supported
Cloud/server deployments	Supported	Supported

Where each library may be a better fit

Syncfusion Word Library may be a better fit when:

• The application processes a high volume of Word-to-PDF or Word-to-image conversions and conversion speed matters. 
• The process needs direct LaTeX-to-equation generation inside Word documents for scientific, engineering, academic, or research content. 
• Bookmark-based automation scenarios require retrieving bookmark content as document elements while preserving formatting and document structure.
• Teams prefer a broad API surface with consistent patterns, strong documentation, and support resources that can help with implementation and maintenance.

Aspose.Words may be a better fit when:

• OOXML or Word document digital signatures are required as part of the document processing.
• DOCX save performance is a primary concern, and that operation is part of the critical path. 
• The project requires support for a wide range of Word-processing operations within a single library rather than combining multiple tools.
• Teams want a library that can fit into existing document automation pipelines without changing established processing patterns. 

Discover the user-friendly features of the Syncfusion Word Library, reshaping your document creation process with ease.

Try It Free

Conclusion

Both Syncfusion .NET Word Library and Aspose.Words provide comprehensive document-processing capabilities for modern .NET applications. Aspose.Words offers a mature ecosystem, while Syncfusion stands out with advanced mail merge, broad document conversion support, LaTeX equation generation, and strong performance across common document-processing operations.

The right choice ultimately depends on your application’s requirements, deployment environment, performance expectations, and licensing preferences. Evaluating both libraries against your real-world document-processing needs will help determine the best fit for your projects.

Try Syncfusion .NET Word Library and explore its capabilities through our interactive demos.

If you have any queries, contact us through our support forums, support portal, or feedback portal. We are happy to assist you!

AI can generate code, create test cases, review pull requests, write documentation, and summarize information in seconds. Yet many developers still spend time rewriting the same instructions every time they work with an AI assistant.

• A developer repeatedly explains code review expectations.
• A QA engineer recreates testing guidelines for every feature.
• A content team keeps re-entering formatting requirements for reports and summaries.

The AI may already be capable of performing the task. The problem is that the instructions live inside individual prompts instead of being packaged as reusable guidance.

As AI adoption grows, this creates familiar challenges:

• Inconsistent outputs across project.
• Time spent rewriting instructions.
• Difficult-to-maintain prompt libraries.
• Knowledge that exists in conversations instead of reusable assets.

The question is no longer whether AI can help. The real question is how to make AI perform tasks consistently without having to explain the same thing repeatedly.

That’s where Agent Skills come in.

To help move beyond one-off prompting, we’ve created the Agent Skills Handbook, a practical guide to creating, testing, and scaling reusable AI capabilities.

From repeated requests to reusable intelligence

Let’s look at a simple example. Imagine your team regularly summarizes technical documents.

Without a reusable approach, you might repeatedly write:

Summarize this document, extract key takeaways, and present them as bullet points.

The prompt may work. But after the tenth, fiftieth, or hundredth request, you’re still repeating the same instructions.

Agent Skills take a different approach. Instead of rewriting the instructions every time, you define them once:

• The input the AI should receive.
• The steps the AI should follow.
• The structure of the final output.

Once created, you can apply the same skill consistently whenever the task appears.

The immediate benefit is convenience. The long-term benefit is consistency. Every team member gets the same structured experience without maintaining multiple versions of the same prompt.

What are Agent Skills?

Agent Skills are reusable packages of instructions, resources, and, in some implementations, supporting scripts that give AI agents specialized knowledge and procedures for performing specific tasks.

A skill typically defines:

• Expected inputs,
• Task-specific instructions,
• Processing guidance,
• Constraints and best practices,
• Output requirements,
• Supporting examples and resources.

Think of a skill as a reusable playbook. Instead of describing a process every time, you package the knowledge once and make it available whenever that task appears.

Different AI platforms may implement skills differently, but the core idea remains the same:

• Define expertise once. Reuse it whenever needed.

Unlike a prompt template, a skill can package the knowledge and supporting resources an agent needs to approach a task in a more standardized way.

Prompt vs. Agent Skills

One question developers often ask is: “Why not just save the prompt?”

While prompts and skills are related, they serve different purposes.

Prompt	Agent Skills
Task-specific instruction.	Reusable task knowledge and processing guidance.
Usually invoked manually.	Can be reused across many similar tasks.
Primarily contains instructions.	Can include instructions, resources, examples, and recommended practices.
Solves an immediate request.	Helps standardize how an agent approaches a recurring task.

A reusable prompt saves instructions. A skill packages expertise.

How Agent Skills work

Most skills follow a simple lifecycle:

1. Define the task: Identify a recurring activity such as code reviews, test generation, documentation, or requirement validation.

2. Package knowledge and instructions: Capture the processes, standards, constraints, and examples that help guide the task.

3. Make the skill available: The skill is added to a supported environment or workspace.

4. Agent applies the skill: When a request matches the skill’s purpose, the agent can use the skill’s guidance and resources alongside the current project context.

5. Improve over time: As requirements evolve, the skill can be updated and reused across future tasks.

This approach helps teams reuse expertise instead of repeatedly rewriting instructions.

Why developers should care about Agent Skills

Most developers have experienced prompt sprawl.

• A simple prompt starts with one instruction.
• Then formatting rules are added.
• Then coding standards.
• Then edge cases.
• Then project-specific exceptions.

Eventually, the prompt becomes harder to maintain than the task itself. Agent Skills help solve this problem by separating the task definition from the execution.

For example, instead of maintaining multiple code-review prompts, a team can create a reusable review skill that consistently checks for:

• Coding standards compliance,
• Security concerns,
• Performance issues,
• Maintainability risks, and
• Documentation quality.

When standards change, the skill can be updated once and reused everywhere. This not only saves time but also helps teams apply the same expectations across projects and contributors.

A real-world example: Standardizing AI-powered code reviews

Consider a team managing multiple repositories.

• One developer asks the AI to focus on performance.
• Another prioritizes security.
• A third emphasizes readability.

Even though they’re reviewing similar code, the feedback varies because the instructions vary.

Now, imagine creating a dedicated Code Review Skill.

The skill defines:

Input

• Source code or pull request changes.

Process

• Validate coding conventions.
• Check maintainability.
• Identify potential security concerns.
• Analyze performance considerations.
• Review documentation coverage.

Output

• Structured review summary.
• Improvement recommendations.
• Priority-based findings.

Instead of depending entirely on individual preferences, the skill helps standardize how the AI approaches code reviews. This becomes increasingly valuable as teams grow and development practices expand across repositories.

What you’ll learn in the Agent Skills Handbook

The Agent Skills Handbook focuses on practical implementation rather than theory.

Inside, you’ll learn:

• How to create Agent Skills for real-world development scenarios.
• The difference between prompts and skills.
• How to define clear inputs, instructions, and outputs.
• Techniques for creating maintainable and reusable skills.
• Methods for testing and refining skill behavior.
• Approaches for scaling skills across teams.
• Advanced patterns, best practices, and practical cheat sheets.

Whether you’re building your first skill or creating a shared library for your organization, the handbook provides actionable guidance you can apply immediately.

Who will benefit from this handbook?

• Developers: Standardize recurring AI-assisted tasks such as code reviews, bug analysis, documentation generation, and requirement validation.
• QA engineers: Create repeatable testing processes and improve consistency in test generation and quality verification.
• Technical writers: Establish structured approaches for generating summaries, technical content, and documentation.
• Solution architects: Create reusable standards that support governance, consistency, and scalability across teams.
• AI engineers: Design, test, and maintain skill libraries that can be reused across projects and development environments.
• Beginners: Learn structured AI interaction techniques that go beyond basic prompting.

Why reusable skills become more valuable over time

Reusable skills can turn knowledge that would otherwise remain scattered across prompts, chats, and documents into assets that can be maintained and shared.

Benefit	Why it matters
Consistency	Provides similar guidance across contributors and projects.
Knowledge capture	Preserves team expertise and implementation practices.
Onboarding	Helps new team members access established processes.
Maintenance	Instructions can be updated centrally.
Scalability	Reuse capabilities across multiple projects.

Putting Agent Skills into practice

Understanding the concept is only the first step. The real value comes from applying reusable skills within your everyday development process.

For example, if your team uses AI for planning, coding, testing, and reviewing software, reusable skills can help ensure those activities follow consistent standards instead of relying on different prompts from different developers.

This is especially useful when teams want AI assistance while still maintaining engineering standards, development guidelines, and repeatable processes.

Generic Agent Skills vs. Syncfusion Agent Skills

Agent skills can be used for any recurring AI-assisted processes.

Generic Agent Skills

Organizations often create their own skills to capture:

• Team standards,
• Internal processes,
• Domain-specific knowledge,
• Review and testing procedures, and
• Documentation requirements.

Syncfusion Agent Skills

Syncfusion Agent Skills provide product-specific knowledge about Syncfusion technologies, including:

• Component setup guidance,
• API usage recommendations,
• Implementation patterns,
• Product documentation references, and
• Best practices for working with Syncfusion components.

Rather than requiring AI assistants to infer how a component should be implemented, these skills provide structured guidance that can help the agent align more closely with Syncfusion’s recommended approaches.

Plan, Code, and Deliver Faster with AI

Use AI agents to create implementation plans, generate production-ready code, automate repetitive tasks, and improve code quality across your projects.

Discover Code Studio

Build once. Reuse everywhere.

The biggest challenge with AI isn’t generating output. It’s generating reliable output repeatedly as projects, teams, and requirements evolve.

Agent Skills provide a practical way to capture expertise that would otherwise be scattered across prompts, chats, and documentation. Whether you’re reviewing code, generating test cases, validating requirements, or summarizing technical content, reusable skills help transform ad hoc AI interactions into repeatable processes.

If you’re looking to get started, explore the Agent Skills Handbook for a practical foundation in designing, testing, debugging, and scaling reusable AI capabilities.

For teams ready to apply those concepts in real development environments, Syncfusion Code Studio provides an AI-native development experience that supports reusable skills and standardized development practices. In Code Studio, skills can be made available to agents and loaded when relevant to a task, allowing specialized instructions and resources to supplement the agent’s general capabilities. This helps teams reuse established processes across planning, implementation, testing, and review activities.

For developers building with Syncfusion components and SDKs, Syncfusion Agent Skills give AI coding assistants access to implementation guidance, APIs, setup instructions, and recommended patterns, reducing trial and error and helping the agent generate code that better aligns with Syncfusion APIs and recommended implementation patterns.

Start with one repetitive task. Turn it into a reusable skill. Then repeat the process. Over time, reusable skills can reduce repetitive instruction-writing and help developers focus more on engineering tasks rather than repeatedly explaining the same processes.

For questions or feedback, connect with us through our support forums, support portal, or feedback portal. We’re always happy to help you!

AI is everywhere, and the pressure to adopt it is relentless. But what does responsible, practical AI adoption actually look like for database and software professionals – the people who live closest to the data?

Redgate brought together three experts to find out: Scott Sauber (Director of Engineering at Lean Techniques), Deborah Melken (Data Architect at Advisor360; Microsoft MVP), and our very own Kellyn Gorman.

The result was a candid, experience-led conversation that cut through the hype and got into what’s really happening on the ground – from data governance and security to vibe coding risks and the future of junior developers. Here are the 10 things we learned.

1. Having an “AI story” doesn’t mean building an AI product

Organizations are feeling the pressure to do something – anything – with AI, and it’s pressure coming from all directions: boards, CEOs, their competitors – to name a few.

Scott describes the pattern succinctly: “board members fire up ChatGPT, see something impressive, and the question flows down through the org until every team is being asked ‘what are we doing with AI?”

The result is teams falling for the hype and scrambling to create their own AI narrative rather than a solid strategy.

“A lot of clients come to us and are like, hey, we want to build this chatbot,” Scott added. “And we’re like, cool, but who’s the target user, what’s the use case? They don’t know, but they’re like, ‘we need a chatbot’.”

The panel agreed that, in reality, this knee-jerk response is unnecessary. If an organization doesn’t know why they ‘need’ AI, they don’t need AI.

Further, responding to the mounting pressure of AI adoption doesn’t have to mean building and shipping your own AI feature. Sometimes, they suggest, the smarter move is positioning what you already do as infrastructure that supports AI.

The key takeaway

Before asking what AI you can build, ask what specific problem you’re actually trying to solve. If you don’t know why you need AI, you don’t need AI. You don’t need to ship your own AI feature or build an AI narrative if there’s no reason for it.

2. Slow down to speed up!

That, for good reason, was a highlight quote of the panel. After all, the instinct right now is to move fast and adopt AI everywhere at once. People and organizations are diving in head-first. But, perhaps unsurprisingly, there’s growing evidence that organizations taking this approach are creating more work, and risk, for themselves – not exactly achieving their aim of reducing workload.

“Sometimes, organizations are throwing spaghetti at a wall (with AI),” Deborah commented. “However, if you stop and think about what you’re trying to do – think, ‘maybe we’ll just start in this one place’…once you figure that out, it makes it easier and faster to do something next time.”

Deborah did also address the AI contradiction hiding in plain sight. “AI is supposed to make everything faster, and then you miss the report that says ‘no, people are spending more time, because they’re having to do all the extra work on top of whatever AI is doing’.”

The key takeaway

The conflicting reports are out there for all to see – and perhaps you’ve read some already – but the answer isn’t to simply dismiss AI. Instead, it’s best to pick one concrete use case, learn it properly, and expand from there. That ‘something’ you create with AI will likely then be better for everyone.

“Everyone wants to move faster with AI, but few are truly ready for it.”

What does the AI landscape look like in 2026? Get the full overview in Redgate’s 2026 State of the Database Landscape AI mini report >>

Download the AI mini report

3. AI is overconfident – and that’s your problem to manage

AI tools will tell you you’re absolutely right even when you’re not. Similarly, they’ll produce a wrong answer, be corrected…then produce a different wrong answer with equal confidence!

Deborah described the exhausting loop of talking – almost even arguing – with AI: “No, that’s incorrect. ‘Oh, you’re absolutely correct. Let me give you this answer.’ And a couple of times in, you’re kind of like, let me just do it myself – it’ll be faster.“

Kellyn is direct about this as well: “AI is incredibly optimistic. It’s very happy to tell you, ‘this is a great way to do this’. It will be overconfident – and it absolutely is overconfident.”

For tackling this optimism, Kellyn’s course of action is surprisingly simple: when AI gives you the wrong answer, ask it directly what you could have prompted differently, to receive the correct (or better) answer.

All of this is exactly why experts will still have jobs. Using code reviews as an example, Scott says: “70% of the comments (from AI) are valid, but that also means 30% are not. If you don’t know any better, you might just blindly accept everything it says.”

Knowing exactly which 30% to ignore and throw out, is exactly what human expertise is needed for.

Finally, the panel made it clear to not be afraid of using one AI to check another. And, if you have time, build reusable ‘prompt templates’ – markdown files that give the model its goal and context upfront – rather than starting from scratch every time.

The key takeaway

AI is often overconfident, highly optimistic, and will tell you you’re absolutely right when you’re really not. To tackle this, if you notice AI give you a wrong (or poor) answer, ask it directly what you could have done to receive the more accurate response. Use AI to help you with your own prompt engineering skills. Finally, use one AI to check another – and build reusable ‘prompt templates’ to speed up the process.

4. ‘Garbage in, garbage out’ – AI amplifies existing data problems

AI doesn’t create data quality and governance problems, but it certainly exposes the ones you already have – and makes the consequences even harder to ignore.

As Deborah put it plainly: “If you’re training your models on junk data, you’re going to get junk results. We now need to understand where our data is, where our PII lives, who has access to it, who can see what…All of this becomes amplified with AI.”

The silver lining is that AI is forcing organizations to finally care about things they’d been ignoring for years. The likes of semantic models, column definitions, data lineage (to name a few), are all suddenly urgent, simply because models need them to function.

“People like the phrase ‘semantic models’ now,” Deborah adds. “So now you’re going to tell me what that column, and that table, actually means…that I’ve been asking for, for five years…” Better late than never!

The key takeaway

AI exposes the data quality and governance problems that organizations have been ignoring for years – to a point where they now have to react. It’s never been more important to understand exactly where data lives, who has access to it, and how accessible it is.

5. ‘Zero trust’ applies to AI, too

Database professionals are instinctively cautious about access and permissions (for good reason), and the panel agreed that the same level of caution should be applied to every AI tool. It’s not paranoia to ask questions like, does GitHub Copilot send my schema outside the org? – or, what does Snowflake Cortex do with our data?

Deborah summarizes it as such: “As data people, we think about security first, and I think we think about it in ways that maybe other types of engineering don’t always think about.”

In fact, tooling now exists to block employees from uploading sensitive data to consumer AI products at the infrastructure level.

“If somebody says, ‘I’m going to get an Excel spreadsheet of your loan data and put it up in the free version of ChatGPT,’ and they go to do it – it just stops it,” Kellyn explained. “They can’t upload it. They can’t even open up ChatGPT if you say ChatGPT isn’t authorized.”

The key takeaway

“Only give it (AI) access to what it absolutely needs,” is Kellyn’s top advice. “Just like we would with any other user.”

6. Data retention is a risk on both ends

It’s just instinct to want to hold onto data indefinitely – after all, “data is the new oil” – but hoarding creates its own problems. As Scott says, “sometimes, if you hold on to data too long, it rots, like food on the shelf.”

That’s why defining and actually enforcing data retention policies matters now more than ever – even when it’s a fight. And it’s an issue that cuts both ways, as too much data is also bad for AI.

“Too much information is a problem for AI as well,” Kellyn points out. “If you give it (the AI) too much information, you’ve got old information. How is that going to impact the answers and the hallucinations you get?”

Kellyn’s answer to that question – how to get users to actually delete old data? “AI won’t like it. Just saying…”

The key takeaway

Hanging onto old data is not only bad for you and your team (in the context of strict data retention policies) – it’s also bad for AI. The older the data AI has access to, the less accurate its responses.

7. Vibe coding is creating a new generation of ‘self-coders’

Scott drew a sharp parallel to a past era of Microsoft Access, when business users got tired of waiting for IT and built their own production-critical systems, which then embedded themselves into workflows and became impossible to unpick. With AI and vibe coding, not only has this returned, but it’s accelerated the pattern dramatically.

“I almost feel like there’s some of that coming back,” he says, “the Access database running under Bob’s desk for 20 years. Business people are not wanting to wait for IT, so they’re just vibe coding some stuff. They’re taking an Excel spreadsheet exported from Power BI, importing it, doing some stuff with an app – and that’s all great when somebody’s just doing it themselves.

“But then, they insert it into a critical part of their business workflow – and what happens when that person leaves in six to twelve months?”

The key takeaway

Business people are getting tired of waiting for IT, and AI and vibe coding now allows them to create their own quick-fire solutions – with varying levels of quality. This is a problem for governance, as Deborah says: “We’re expecting the (AI) tool to take care of this stuff (governance) for us – that’s why it’s ‘no code, low code’. But we’re forgetting: ‘no, it’s just a tool’. It can’t do everything for us. We still have to take on that responsibility.”

8. The database world is still playing catch-up

AI tooling for Python and application code is genuinely impressive. For SQL and database work, however, it’s noticeably behind. With the stakes for getting database decisions wrong being so much higher, this is a problem. And while there are some exceptions – such as AI assistance tool SQL Prompt AI – the overall point remains.

Deborah is clear on her thoughts about the structural reasons for this. “I feel like the database is still kind of the afterthought – it’s all about the application”, she says. “The software engineers are making the decisions about which database platforms we’re using.”

Part of what drives the DBA instinct to verify everything is an understanding of permanence that application engineers don’t always share. As one of Deborah’s colleagues put it in a line she quoted: “It’s hard to think of the database as part of the application, because that database and the data in it is going to outlive your application code – it’s just there, it’s always going to be there.”

The trust issue with AI suggestions is real, too – and not only for simple things it does well, but for complex SQL. “I don’t know if it’s because AI is suggesting changes”, Deborah adds. “I think there’s still a trust issue.”

The key takeaway

Some AI tools are impressive. However, some others – such as many for SQL and database work – are lagging behind. There’s also still a trust issue around AI – especially with databases, where the stakes for getting things wrong are so much higher.

Subscribe to the Simple Talk newsletter

Get selected articles, event information, podcasts and other industry content delivered straight to your inbox.

Subscribe now

9. Nobody is hiring junior developers — and that should worry us

When the panel moderator asked the room who was actively hiring junior developers, nobody raised their hand. They were honest about why (and it’s something seen quite widely across the board): AI is handling a lot of what entry-level hires used to do, so the need to bring in junior talent has weakened considerably.

Of course, the longer-term concern is what this means for the people trying to break into the industry – and for the expertise pipeline as a whole.

Scott put it plainly: “How we all learned was we banged our head against a wall against something for a while, and then it got stuck in our head. But if AI is giving you all the answers, I’m just curious how that’s going to turn out long term.”

He also flagged that AI-generated code has a hidden cost, even for experienced developers: “I don’t know the code as well as if I hand typed it myself. When I’m in a meeting three weeks later, I can’t picture the code as clearly in my head.”

The key takeaway

AI is handling a lot of entry-level tasks, so there’s less need to onboard junior employees. It’s also impacting the way we learn, which has typically been by doing things ourselves – things that AI can now do with relative ease. The productivity gains are clear, but at what cost?

10. The AI tools that survive will be the ones with enterprise inertia

The current AI tool landscape is crowded and heavily funded, but the money won’t last forever. “Grok raised $20 billion, but their burn rate is over a billion a month,” Scott pointed out. “That means that $20 billion is only going to last them a little more than a year and a half. At some point, the private equity companies funding this want their returns.”

Kellyn added that it’s apparent that many of the players are essentially sharing the same investor money around, so significant consolidation could be coming. So, what’s the implication for anyone using these AI tools?

Put simply, the platforms most likely to survive are those already embedded in enterprise workflows, with Microsoft Copilot being an obvious example. While it’s not necessarily the best product, it’s the one with the most inertia behind it – so committing to it is safer than building critical processes around a tool that might not exist in two years. That, in its own right, would be a huge governance risk.

The key takeaway

Where possible, favor proven enterprise platforms for production workloads. For prototyping, meanwhile, use lighter, cheaper, or even offline models such as Llama, Ollama, or Qwen. This will keep costs down while you validate whether a use case is worth investing in properly.

In summary: AI is a tool, not a strategy

The common thread running through everything our panelists said is simple: AI is a tool, not a strategy. Used well — with clear intent, proper governance, and realistic expectations — it can genuinely transform how database and software teams work. Used badly, it amplifies every problem you already have. The difference, more often than not, comes down to slowing down long enough to ask the right questions before you start.

FAQs: What your AI strategy is missing

1. Should every company be building AI into their product?

Not necessarily. If you don’t have a clear use case, you don’t need AI. Sometimes the smarter move is positioning what you already do as infrastructure that supports AI, rather than rushing to ship a feature nobody asked for.

2. Why is AI adoption creating more work for some teams, not less?

Adopting AI without a clear problem statement means you’re doing extra work on top of AI outputs – correcting, validating, and managing results. Picking one focused use case and learning it properly is far more effective than going all-in at once.

3. What's the biggest data risk when adopting AI?

Feeding AI poor, ungoverned, or outdated data. AI amplifies existing data quality problems rather than fixing them, which makes data governance, lineage, and retention policies more important than ever.

4. How should companies handle the security risks of AI tools?

Apply the same zero-trust principles you’d use for any other system user – give AI access only to what it absolutely needs. Infrastructure-level tooling now exists to actively block sensitive data from reaching consumer AI products before it ever happens.

5. Which AI tools are worth investing in for the long term?

Favor platforms already embedded in enterprise workflows – they have the inertia to survive the coming consolidation. For prototyping, use lighter or offline models to keep costs down while you validate your use case.

The post What your AI strategy is missing (according to the people who know your data best) appeared first on Simple Talk.

Open-weight model runner Ollama has reintroduced an integration with Claude Desktop that lets users connect Anthropic’s app to models served through Ollama, including models running locally on their own machines.

This effectively means Claude users can tap Ollama’s library, which includes popular models such as Qwen, DeepSeek, Kimi, and GLM, while remaining inside the Claude Desktop interface — with Ollama serving as the gateway to whichever model is handling the request.

A second shot at Claude Desktop

This isn’t Ollama’s first attempt to bring its model catalog to Anthropic’s tools. Back in January, the company added support for Anthropic’s Messages API, allowing Claude Code to be pointed at Ollama and use local or cloud-hosted models instead of Claude.

In April, Anthropic quietly opened a similar opportunity within the Claude Desktop app, adding a developer setting that let it connect to third-party inference gateways. Ollama seized on that with ollama launch claude-desktop, which configured the desktop app to use Ollama, however, the integration lasted mere days — following a Claude Desktop update, users found that the app’s gateway accepted the connection but rejected non-Anthropic model IDs. And so Ollama removed the feature, saying Claude Desktop’s third-party integration had become “limited to Anthropic models.”

Fast forward to Aug. 21, and Ollama quietly introduced a new implementation in v0.33.0 that addresses that mismatch with a dedicated local proxy for Claude Desktop. In a blog post published on Tuesday formally announcing the support, Ollama notes that developers can now configure Claude Desktop to use it as a “third-party gateway provider.” The setup is handled from Ollama itself: users open the Ollama app, select Claude and switch the integration on, after which Ollama configures Claude Desktop’s third-party gateway automatically. Switching it off restores the user’s previous Claude setup.

As part of the update, Ollama has also put that Claude integration directly in its Mac menu, where users can toggle “Use Ollama models” on or off.

Once enabled, models available through Ollama — whether running locally or through Ollama Cloud — appear inside Claude Desktop’s own model picker, allowing users to select one without leaving Anthropic’s app.

Because Claude Desktop is built around Anthropic’s own model options, Ollama also lets users decide which underlying model should sit behind each of those slots. In the example below, selecting “Opus 5” would route the request to Kimi K3, while “Sonnet 5” is mapped to DeepSeek V4 Pro.

It is also worth noting that the “Auto mode” option preserves Claude Desktop’s built-in Auto mode, which lets the app decide when it should ask the user for permission before making changes.

Community questions

The launch prompted a swathe of questions from the community on X, perhaps chief among them: why use an alternative model through Claude Desktop rather than simply use Claude?

The answer, perhaps somewhat unsurprisingly, comes down to choice. The company points to cost, speed and portability, as well as the ability to use models fine-tuned on a developer’s own data. Users can choose between models running locally or through Ollama Cloud, and of course users are still able to lean on Anthropic’s frontier models wherever they like.

Some developers also wondered how any of this differed from using Ollama with Claude Code, which was already possible. Claude Code is Anthropic’s terminal-based coding agent, and could already be pointed at Ollama’s Anthropic-compatible API to use local or cloud models. This release brings that same basic idea to the Claude Desktop app directly.

“The future of AI is open models running everywhere work gets done.”

For now, the new Claude Desktop integration is limited to Ollama’s Mac app, though Ollama suggested in replies on X that Windows support might be in the works.

‘Open models running everywhere work gets done’

Claude Desktop support arrives less than two months after Ollama raised a $65 million round of funding. In a statement issued at the time of the funding announcement in July, Ollama co-founder and CEO Jeffrey Morgan described a future in which open models are available wherever developers choose to work.

“Open models should be easy to run, easy to build with, and available wherever people need them — on your own machine, in the cloud, or both,” Morgan said. “Ollama started as an open-source project, and has since grown into a community of millions of developers. Everything we do next is in service of that community and their best work. The future of AI is open models running everywhere work gets done — and Ollama is here to power this shift.”

The update also builds on Ollama’s broader push to make local models easier to use across existing developer tools, while recent work such as native Apple MLX support has focused on improving local inference on Macs.

Support for Claude Desktop is the latest expression of that strategy: let developers keep the apps they already use, while Ollama supplies the model underneath.

The post Claude Desktop can now easily run Qwen, DeepSeek and Kimi models — after Ollama’s first effort stalled appeared first on The New Stack.

Say a test starts failing and a developer hands it to a coding agent. It digs into the relevant files, runs the test suite, changes two files, then runs targeted validation. The task view shows the files it touched, the commands it ran, what results those commands returned, and the diff it landed on.

Before accepting the patch, the developer reviews that activity. A teammate might reopen the same run later to see why the code changed. The team building the agent can compare thousands of runs to see whether a model or prompt update improved test success or just added more tool calls and cost.

That record needs somewhere to live. Developers and reviewers want a durable version of the run whenever they need it. Engineering wants the same execution data aggregated across runs, because the agent’s behavior is nondeterministic and shifts over time.

“For many agentic products, that record turns out to be application data with a telemetry-shaped workload.”

For many agentic products, that record turns out to be application data with a telemetry-shaped workload. That’s the combination that changes the storage decision.

When a trace becomes product data

Not every agent trace counts as application data. An internal diagnostic trace that can be sampled, expired, or discarded is still telemetry. That boundary can exist within the same trace, where raw diagnostic fields remain internal and the fields needed to reconstruct the user’s task move into product state.

The boundary moves once your product has to retrieve, display, or retain a durable execution record. A developer, for example, might need to see which files an agent inspected, or a reviewer might need to check which commands ran and whether the tests passed.

This doesn’t require exposing a model’s private chain of thought. The product can instead render a projection of observable execution, showing model invocations, tool calls, file reads, command results, errors, timing, and state transitions. That record lets users verify the result and decide how much they want to trust it. In some workflows, it also becomes an audit record, which changes its access and retention requirements.

“Internal diagnostic fields don’t automatically belong in the product view just because they came from the same run.”

Once that execution record becomes product state, it must follow your application’s access model. Code, prompts, retrieved documents, tool arguments, and command output may carry tenant or user data, so the application must enforce the same authorization boundaries when storing and retrieving them. Internal diagnostic fields don’t automatically belong in the product view just because they came from the same run.

Why one agent run produces so much data

Pull request volume scales with the number of patches submitted for review, and issue volume scales with the number of development tasks. Both are just counting units of work at the workflow boundary.

Agent traces scale differently, depending on the execution graph within each task. One request to fix a failing test can trigger multiple model calls, file reads, searches, command executions, test retries, and branches before the agent ever proposes a patch. Each of those steps can produce its own span or event.

OpenTelemetry GenAI semantic conventions, still in development, define separate span types for model inference, tool execution, and retrieval. What gets captured depends on the span type and content-capture policy. Inference spans may carry model identifiers, token usage, and opt-in input and output messages, while tool-execution spans may carry opt-in arguments and results.

The span count tracks what the agent actually does inside each unit of work. If you add a new tool, a retry policy, or a branch, the data volume can increase even though the number of completed tasks hasn’t changed.

“If you add a new tool, a retry policy, or a branch, the data volume can increase even though the number of completed tasks hasn’t changed.”

This same fan-out also shows up outside coding agents. In a case study, Laminar reported more than 500,000 browser events per day. A browser-agent session could run for more than 30 minutes and generate hundreds of thousands of DOM diff events. Laminar used those events to reconstruct a video-like replay of what the agent saw.

Whether the agent writes code or navigates a browser, the same data serves two different purposes. One person loads one trace to understand a single run, and the engineering team scans many traces to find patterns. That combination of point retrieval and cohort analysis gives this data its unusual shape.

Why agent trace data behaves like telemetry

Most records in an agent trace are written once rather than updated. A model invocation or tool result describes an event that has already happened. Scores, annotations, and run status may change later, but teams can store those mutable fields separately or record the changes as new events.

The records also carry high-cardinality dimensions such as model version, prompt template, tool name, session ID, user ID, and outcome. Their value only shows up in context. On its own, an isolated tool-call span doesn’t say much, but a full trajectory can explain a failed run, while a cohort can reveal a regression.

The same dataset therefore serves several distinct readers:

Consumer	Read pattern	Example
Product interface	Point lookup	Load one coding-agent run for a developer or reviewer
Evaluation pipeline	Cohort scan	Compare test success, latency, and cost across agent versions
Platform team	Time-window aggregation	Group errors and latency by model, tool or deployment

A primary application database can serve all three patterns at modest scale, but that changes when wide scans and high-cardinality aggregations start competing with product reads and writes on the critical path.

Outgrowing the primary database

There is no universal event-count threshold for moving traces out of the primary database. The decision shows up in the workload.

The first signal is contention, where ingestion or retention work starts consuming enough I/O and CPU to affect transactional operations. Next comes analytical friction, where evaluations and debugging queries need to scan long time ranges or join large trace tables, and stop meeting your team’s latency target. Eventually, teams resort to forced sampling, discarding traces to protect the application database, even though the product or an audit process requires the complete record.

Langfuse documented both contention and analytical friction as it scaled its open-source platform for LLM observability, evaluation, and prompt management. It experienced Postgres IOPS exhaustion during ingestion and prompt API latency reaching seven seconds under heavy load. Langfuse moved its tracing data from Postgres to ClickHouse, while keeping transactional and latency-sensitive paths isolated.

The store is only half the decision

The database move solved one class of problem, but the original data model created another. Langfuse initially carried separate trace, observation, and score tables into its analytical architecture. Updates required deduplication and cross-table analysis, adding join cost.

“The store is only half the decision. The analytical storage engine addressed the workload, and a data model reduced cross-table work.”

Later, Langfuse collapsed those records into a wide, mostly immutable observations table, with one row per model call, tool execution, or agent step. Initial table loads for large datasets went from seconds to milliseconds, and dashboard load times for large projects improved by at least 10 times over longer time ranges.

Langfuse needed both changes. The analytical storage engine addressed the workload, and a data model reduced cross-table work.

How to choose a storage pattern

Start with the reads your product must support, then choose the simplest architecture that meets those requirements.

At modest volume, keeping traces in the primary database avoids another operational boundary. As analytical contention grows, the application can send trace events to a dedicated analytical store while keeping mutable business records in its transactional database.

Some applications need both systems to share data. A Postgres-backed product might keep users, permissions, and workflow state in Postgres while sending agent events to ClickHouse for analytical queries. If relevant application data already lives in Postgres, change data capture can replicate it into the analytical path.

Start with who reads the trace

Who depends on the record and how they query it matters more than whether a trace looks like a log or a pull request.

If your product needs to reconstruct a durable record of a single run and the engineering team needs to compare behavior across thousands of runs, the trace has become application data with a telemetry-like storage workload.

Map the point lookups and cross-run scans before choosing a store. If both are product requirements, design for both from the first trace you retain.

The post When AI agent traces become application data appeared first on The New Stack.

Learn what's new in Visual Studio Code 1.136 (Insiders)

Read the full article