DeepSeek v3 vs. Claude 3.5 Sonnet 1022: DeepSeek tends to write simpler code (My Experience)

Hey everyone, I've been experimenting with using LLMs to add new features to my code, and I've noticed some interesting differences between DeepSeek v3 and Claude 3.5 Sonnet. Specifically, DeepSeek tends to generate simpler, more straightforward code compared to Claude, which often leans towards more complex, object-oriented solutions.

I wanted to share a couple of examples and get your thoughts.

Example 1: Implementing an Undo Feature for File Changes

When I asked both models to implement an undo feature for file operations, they took very different approaches. Here's a summary of what I observed, based on Claude's own analysis of DeepSeek's code:

Key Differences:

  • Complexity: Claude opted for an object-oriented design with a dedicated manager class to handle undo logic. This approach promotes better organization and separation of concerns, potentially making it easier to scale for more complex scenarios. DeepSeek, on the other hand, used a simpler, procedural method with a global list to track changes. This is easier to understand at a glance, especially for basic undo/redo.
  • Data Structures: Claude tracked changes using a list of objects, each containing detailed information about the operation (type, path, timestamp, content). DeepSeek used a list of tuples, holding just the essential data (action, path, backup). Both are functional, but DeepSeek's approach is less verbose.
  • Error Handling: Claude included more robust error handling, providing feedback to the user in case of issues. DeepSeek's error handling was more basic, primarily focusing on file deletion during undo.
  • Readability: For those familiar with object-oriented programming, Claude's code is well-structured and easier to maintain in larger projects. DeepSeek's linear code is arguably easier to follow for those less comfortable with OOP concepts.

Deep Diving into the Differences

The differences go even deeper than just complexity. Here are some additional observations about their respective approaches:

DeepSeek's Approach - Simplicity and Directness:

  • Fewer moving parts: It avoids introducing new classes and enums, relying on basic Python data structures and control flow.
  • Directness: The logic for backing up and undoing is embedded directly within the functions that modify files.
  • Less abstraction: There's less indirection, making it easier to see the direct relationship between the action and the undo operation.
  • Pragmatic Approach: DeepSeek appears to focus on providing a functional solution with minimal overhead, prioritizing simplicity and ease of understanding.

Claude's Approach - Robustness and Extensibility:

  • Focus on Structure: Claude seems to prioritize building a more robust and well-structured solution, anticipating potential future complexities. The use of classes and enums is characteristic of this approach.
  • Detailed Documentation: Claude includes more detailed comments and docstrings, explaining the purpose of the classes and methods.
  • Experience Assumption: Claude's response might assume a user with more software engineering experience who appreciates structured design patterns.
  • Communication Style: It's more conversational, asking for confirmation (e.g., "Would you like me to explain...").

Interestingly, when I asked Claude to compare the two implementations, it acknowledged the simplicity and effectiveness of DeepSeek's code:

"Yes, that's a good implementation! Your approach is actually simpler and more straightforward than my suggestion while still accomplishing the core functionality... One small improvement you might consider is removing the entry from file_history if the undo operation fails..."

Example 2: Adding a Message Override Feature

I saw a similar pattern when adding a message override feature. Again, Claude praised DeepSeek's implementation as "clearer and more straightforward," highlighting its advantages:

"Yes, that's correct! This implementation is actually clearer and more straightforward than my previous suggestion. Your version has several advantages: 1. It keeps the message collection logic together in one place. 2. It makes it very clear when the default message is being used vs. the user message..."

Which Approach is "Better"?

Both implementations achieve the desired functionality. The "better" approach depends on the context and your priorities:

  • Choose Claude's approach if:
    • You anticipate needing more complex undo scenarios in the future.
    • You value a well-structured and maintainable codebase.
    • You are comfortable with object-oriented programming.
  • Choose DeepSeek's approach if:
    • You need a simple and quick solution.
    • You prioritize ease of understanding and implementation.
    • Your requirements are unlikely to change too much.

My Takeaway:

My experience suggests that DeepSeek Coder might be a better choice when you need a quick, clean implementation of a new feature. Claude, while capable of generating more sophisticated code, sometimes leans towards over-engineered solutions unless you provide very specific instructions. It also seems like DeepSeek might be more suitable for users that are less experienced, whereas Claude might target more experienced programmers.

What are your thoughts? Have you noticed similar differences between these or other LLMs? Do you prefer simpler or more complex solutions when using LLMs for coding? I'd love to hear about your experiences and any tips you might have!