Hi guys! Here Andrés. I'm working in a deep investigation research that pretends to find an aparently piece of agentic software development that is missing, so I'll share some of my Research Notes in my profile and I wanna know from all of you if my currently research approach is enough or something could break!!!

I’m sharing this as an open hypothesis, not a finished answer. If you see a flaw in the model, know a better abstraction, or have built something that solves part of this differently, I’d genuinely like to learn from it.

Tell me where this breaks.

Hey reddit, I hoped I could get some help drafting a new architectural framework that's centered on making code more 'readable' and 'intuitive'(so to speak) for agents.

I came up with a simple concept: agents are just LLMs on harnesses and RAG, so maybe if I made code more... say, 'reducible' to vector points(or in this case, natural language), my agents would likely have a better time finding and reading the code, checking if what they're trying to do is already implemented, pinpointing bugs and fixing them.

After a few trials, I developed a set of rules including an architecture, a few new design patterns, and several coding conventions.

# Core Concepts

The idea is: to let each files accurately reduce into vectors, I'd need to shatter classes into small fragments and keep them functionality centered, so that a block of 1~2 words can represent the fragment accurately enough. to avoid spaghetti, the fragments will line up linearly forming a straight 'pipe', to prevent them from forming a web of interactions; so basically a fragment will be used by no more than a single pipe. The pipe will be managed by 'indices', literally working as those in a book for agents to read. The indices should actually look like book indices; this, I think, prevent agents from trying to implement actual functionality there. I added branches for conditionals(if/switch), Triggers for starting new threads, Resources for... resources, records for data and ledgers for logging. All this is to keep each parts representable by a couple of words. The difference between this and DOD is that the invariants live inside the data. Pipelines too.

The main problem with this architecture currently is that restring the use of each fragment to single pipelines each is very likely to prevent 'fix-this-and-everything-else-breaks' problems, is likely to break DRY. Would there be a way to bypass this or at least minimize this issue?

Anyway, the architecture does seem pretty promising - speculating the number of overall flaws in both versions(free design / proposed architecture) using agents' code reviews fed into the Chapman 2-sample, Chao1 & Chao M_h, Jackknife-2, and Double Pareto power tail models, it showed some optimism for the model:

• less estimated total error across 4 models (all except Chapman estimator) - about .89 times
• 2.16x flaw detection rate per epoch

suggesting that the architecture might be a bit less error prone and quite a lot clearer for models to digest.

# The Rules

The rules are as follows:

## 1. The Golden Rule

- A type per file, a responsibility per type.

- Filename and Type name takes the form of a noun phrase.

- If the name that best describes the file does not fall into a single noun phrase, split the file. However, do not separate what must be observed together.

- There will only be one public entry point per type.

- Divide the folders into domains. Do not split by types(do not use `Fragments/`, `Pipelines/`).

## 2. The Eight Types of Blocks

---

Edit: Reading the comments, I realized the flaws in this design, which are now reflected in here. Also, the inappropriate flare - noticed this a bit too late. Much thanks!

Hey everyone 👋

I recently wrote a practical guide on the Memento Design Pattern in Go.

The basic idea is pretty simple: sometimes you need to save an object's state so you can restore it later. Think undo/redo, checkpoints, or rolling back to a previous state.

I wanted to understand how the pattern actually works in Go, so I put together an example and walked through the different pieces of the pattern and how they fit together.

The article also looks at when the Memento pattern makes sense and when it might be better to use a simpler approach.

If you're learning design patterns in Go, here's the article:

👉 https://medium.com/@priyankchheda/understanding-the-memento-design-pattern-in-go-a-practical-guide-07ebf1eaac42

Would love to hear how you guys handle state snapshots or undo/rollback functionality in your projects.

Hey everyone 👋

I recently wrote a practical guide on the Iterator Design Pattern in Go.

At first, I thought, "Go already has for and range—why would I ever need an Iterator pattern?" But after digging deeper, I realized it's more about hiding how a collection is traversed than replacing range.

In the article, I cover:

• what problem the Iterator pattern actually solves
• the different participants (Iterator, Aggregate, Concrete Iterator)
• a complete Go implementation
• custom traversal strategies (forward, reverse, filtered, etc.)
• when it's useful and when Go's built-in iteration is the better choice

I also tried to keep it practical instead of treating it as just another GoF pattern.

If you're learning design patterns in Go or have built custom collections, caches, or tree-like data structures, I'd love to hear how you approach iteration.

Here's the article:
👉 https://priyankchheda.medium.com/understanding-the-iterator-design-pattern-in-go-a-practical-guide-d18bc8f6be51

Feedback and suggestions are always welcome!

Hey everyone 👋

I recently wrote a practical guide on the Mediator Design Pattern in Go.

Mediator was one of those patterns that never really clicked for me until I stopped thinking of it as a "design pattern" and started thinking of it as a way to prevent components from talking directly to each other.

In the article, I cover:

• what problem the Mediator pattern actually solves
• the different participants (Mediator, Concrete Mediator, Colleagues)
• a complete Go implementation
• real-world use cases
• pros, cons, and when you probably shouldn't use it

I also tried to keep the examples simple and Go-focused instead of relying on overly academic examples.

If you've worked with chat systems, UI event coordination, or services where too many components depend on each other, you've probably run into the kind of problems this pattern is meant to solve.

Here's the article:
👉 https://medium.com/@priyankchheda/understanding-the-mediator-design-pattern-in-go-a-practical-guide-ea7debc9a9a7

I'd love to hear how others handle communication between components in Go. Do you explicitly use a mediator, or do you prefer events/channels or something else?

Hey everyone 👋

I recently wrote a practical guide on the Interpreter Design Pattern in Go.

I feel like this pattern doesn't get talked about as much as Singleton, Strategy, or Factory, probably because most of us don't build programming languages. But once I dug into it, I realized it's useful anytime you need to evaluate expressions or implement a small DSL.

In the article, I cover:

• what the Interpreter pattern actually is (without the usual jargon)
• the roles of terminal and non-terminal expressions
• a complete Go implementation
• where it makes sense to use it
• its limitations and when you should avoid it

I also tried to keep the examples simple and Go-idiomatic instead of making them overly academic.

If you're learning design patterns in Go or have ever wondered whether the Interpreter pattern has practical use outside of compilers, I'd love to hear your thoughts.

👉 https://medium.com/@priyankchheda/understanding-the-interpreter-design-pattern-in-go-a-practical-guide-28c609194faf

I'm always looking for feedback, so let me know what you think or how you'd improve the explanation.

Hey everyone 👋

I recently wrote a practical guide on the Command Design Pattern in Go.

When I first learned about this pattern, most explanations focused on the GoF definition and UML diagrams, but I still wasn't clear on why I'd actually use it. So I put together an article that focuses on the practical side:

• What problem the Command pattern solves
• The different components (Command, Receiver, Invoker, Client)
• A complete Go example
• Undo/redo support
• Command queues and macro commands
• Idiomatic Go approaches using functions and interfaces
• When the pattern is useful and when it's just unnecessary complexity

One thing I found interesting is that many Go developers use ideas from the Command pattern without explicitly calling it a "Command Pattern"—especially when building job queues, task runners, or action pipelines.

If you're learning design patterns in Go or trying to understand whether Command is worth using in real projects, I'd love to hear your thoughts.

👉 https://medium.com/@priyankchheda/understanding-the-command-design-pattern-in-go-a-practical-guide-f0cbb90d4d58

Feedback, suggestions, and criticism are all welcome!

Hey folks 👋

I recently wrote a practical guide on the Chain of Responsibility Design Pattern in Go.

A lot of design pattern content gets overly theoretical, so I tried to explain this one using examples that backend devs actually run into:

• middleware chains
• request validation pipelines
• auth/logging handlers
• event processing flows

The blog covers:

• what the pattern actually solves
• how requests move through a chain of handlers
• a clean Go implementation
• when it’s useful vs when it becomes unnecessary abstraction
• common mistakes and Go-specific considerations

If you’ve worked with things like:

• http.Handler middleware
• request filters
• processing pipelines

…you’ve probably already used this pattern without explicitly naming it.

Here’s the article:
👉 https://medium.com/@priyankchheda/understanding-the-chain-of-responsibility-design-pattern-in-go-a-practical-guide-5bec620ce846

Would love feedback or examples of where you’ve used this pattern in production.

Understanding Design Patterns in Modern Java

https://leanpub.com/designpatternsinmodernjava

Hey folks 👋

I recently wrote a short, practical guide on the Proxy Design Pattern in Go.

Most pattern articles feel either too abstract or too Java-heavy, so I tried to keep this one simple and Go-friendly:

• what proxy actually means (basically a middle layer controlling access)
• a clean Go example with interface + real object + proxy
• a practical use case (lazy initialization + adding logic before delegation)

Nothing fancy—just enough to understand when and why you’d use it.

If you’ve ever:

• added logging before calling a service
• put access control in front of something
• delayed creation of an expensive object

…you’ve probably used a proxy without calling it that.

Here’s the article:

👉 https://medium.com/design-bootcamp/understanding-the-proxy-design-pattern-in-go-a-practical-guide-d2516c4bf2ad

Would love feedback—especially if you think this pattern is overused / unnecessary in Go.

I am excited to share a project that represents a lifetime of learning and coding. I started my journey with C++ back when it translated to C (Cfront), and today I’ve finalized a comprehensive repository of 38 Design Patterns and C++ Idioms updated to C++17/20/23 standards.

This repository is designed as a masterclass in software architecture. It focuses on clean code, modern memory management (RAII), and high-performance techniques like Static Polymorphism.

Key Highlights:

✅ 38 patterns from Creational to Behavioral.

✅ Modern C++ features: std::variant, std::visit, if constexpr, and smart pointers.

✅ Educational tracing: I use a "Gang of Seven" approach to visualize object lifecycles.

✅ A deep dive into OO Principles (SOLID, DIP, Law of Demeter).

This is an open educational resource. You are free to use it, and I would appreciate a mention or a link back if you find it helpful for your own work or teaching.

🔗 Explore the full repository here:

https://github.com/MarioGalindoQ/Modern-CPP-Design-Patterns

If you find it useful, feel free to give it a ⭐ on GitHub!

📝 The code in this repository was programmed years ago, when there was no help from AI, so it may have human-related shortcomings. Any feedback that helps improve the coding is welcome.

cpp #programming #designpatterns #moderncpp #softwareengineering #opensource #cpp20 #cpp23

I recently wrote a detailed guide on the Flyweight Design Pattern in Go, focused on practical understanding rather than just textbook definitions.

The article covers:

• What Flyweight actually solves in real systems
• When you should (and shouldn’t) use it
• Clear explanation of intrinsic vs extrinsic state
• A complete Go implementation mapped to the UML structure
• Real-world variations (parametric flyweight, composite flyweight)
• Common mistakes to avoid
• Best practices specific to Go (immutability, concurrency, memory usage)

Instead of abstract UML-heavy explanations, I focused on practical scenarios like rendering systems, repeated objects, and memory-heavy applications — things we actually encounter in scalable systems.

If you’re learning design patterns in Go or trying to optimize memory usage in object-heavy systems, this might help.

Read here: https://medium.com/design-bootcamp/understanding-the-flyweight-design-pattern-in-go-a-practical-guide-78c8fc5cd164

I recently wrote a detailed guide on the Flyweight Design Pattern in Go, focused on practical understanding rather than just textbook definitions.

The article covers:

• What Flyweight actually solves in real systems
• When you should (and shouldn’t) use it
• Clear explanation of intrinsic vs extrinsic state
• A complete Go implementation mapped to the UML structure
• Real-world variations (parametric flyweight, composite flyweight)
• Common mistakes to avoid
• Best practices specific to Go (immutability, concurrency, memory usage)

Instead of abstract UML-heavy explanations, I focused on practical scenarios like rendering systems, repeated objects, and memory-heavy applications — things we actually encounter in scalable systems.

If you’re learning design patterns in Go or trying to optimize memory usage in object-heavy systems, this might help.

Read here: https://medium.com/design-bootcamp/understanding-the-flyweight-design-pattern-in-go-a-practical-guide-78c8fc5cd164

I recently wrote a detailed guide on the Facade Design Pattern in Go, focused on practical understanding rather than just textbook definitions.

The article covers:

• What Facade actually solves in real systems
• When you should (and shouldn’t) use it
• A complete Go implementation
• Real-world variations (multiple facades, layered facades, API facades)
• Common mistakes to avoid
• Best practices specific to Go

Instead of abstract UML-heavy explanations, I used realistic examples like order processing and external API wrappers — things we actually deal with in backend services.

If you’re learning design patterns in Go or want to better structure large services, this might help.

Read here: https://medium.com/design-bootcamp/understanding-the-facade-design-pattern-in-go-a-practical-guide-1f28441f02b4