OpenAI recently published an engineering account of GPT-Live. It described how they designed the system to maintain continuous voice interaction while separating latency-sensitive media processing from broader application work. The live path contains the media pipeline and inference loop, while delegation, tool use, persistence, and other application logic run behind an asynchronous RPC boundary.

Hi r/softwarearchitecture,

We are back with Lesson 16 of our technical deep dive into the SysML v2 standard.

In our previous lesson, we made values physically meaningful with types and units. Today, we are modeling who owns the physical hardware those values belong to. In software engineering, the distinction between composition (strong lifecycle binding) and aggregation (loose reference) is foundational. SysML v2 finally brings rigorous semantics to this concept for system models, where one wrong keyword can accidentally double a spacecraft's mass budget.

I’ve uploaded the full video lesson directly to this post so you can watch the workflow right here.

1. The SysML v1 Ambiguity

In SysML v1, whole-part relationships were typically drawn with diamonds. Shared aggregation (the hollow diamond) had no agreed-upon execution semantics in the underlying UML specification, meaning different tools and teams interpreted it differently. Composite aggregation (the filled diamond) made a stronger lifetime claim, but tool support for verifying that claim was inconsistent.

2. The v2 Shift: Ownership and Lifetime Semantics

SysML v2 makes ownership and lifetime a strictly enforceable part of the model's formal semantics. The core rule is: a nested occurrence is composite by default. Add the ref keyword, and it becomes a reference to something owned elsewhere.

Three technical distinctions make this reliable:

• ref is for Occurrences, Not All Usages: The composition rule applies to occurrences—things with physical or temporal lifetimes like parts, items, actions, connections, and ports. Attributes represent data values (numbers, strings) and are referential by definition, making ref attribute legal but technically redundant.
• Composition is a Lifetime Claim: A composite part's physical existence is tied to its parent's lifetime. If the whole is destroyed, the composite occurrence is destroyed with it. A satellite does not compose its ground station, its orbit, or its operator.
• The Architect's Test: When in doubt, ask: "If I deleted the parent system from my model, would this nested element physically cease to exist in the real world?"If yes, use a composite part. If no, use a referential ref part.

3. The Multiplication Trap & Redefinition

Consider a satellite with one shared power bus. If you instantiate standard subsystem templates (like Comms or Thermal) that each contain a default part bus, those internal buses evaluate as composite by default. A script crawling this model will count the main satellite bus plus the internal subsystem buses, quietly multiplying your mass rollup with phantom components.

The fix is to redefine the inherited composite bus as a reference and bind it to the single real sibling bus. (Note: In SysML v2, binding implies symmetrical equality, not an instruction to evaluate and copy a value in one direction).

Code snippet

package SatelliteSystem {
    part def PowerBus;

    part def CommsSubsystem {
        part bus: PowerBus; // A composite bus by default
    }

    part def Satellite {
        // 1. The single real physical bus owned by the satellite (Composite)
        part powerBus: PowerBus;

        // 2. Instantiate the subsystem, redefining its internal bus as a reference bound to 'powerBus'
        part comms: CommsSubsystem {
            ref part :>> bus = powerBus; 
        }
    }
}

Visualizing this: In SysML v2, composite parts appear nested with a solid border (or a filled diamond edge), while reference parts use a dashed border (or a hollow diamond edge).

4. SysML v1 vs. SysML v2

Next lesson, we are moving from architecture to domain-specific meaning with metadata def, which lets you mark a requirement as safety-critical without building an entire SysML v1 Profile first.

For the software architects here: This maps heavily to composition vs. aggregation in OOP design. Have you ever encountered a system bug because a shared component's lifecycle was accidentally treated as an exclusively owned composite? Let's discuss in the comments!

I've been working on a database and it has forced me to reconsider what reliable means. A service can keep answering requests while its state is already corrupted. Most teams I've seen would consider a service is reliable as long as it's responding to requests, but that is wrong.

I’ve started thinking about reliability in terms of invariants: properties that must remain true. A balance can’t become negative. A cache’s counter must match its actual entries. A secondary index must stay consistent with its source data.

These invariants usually break because an operation has multiple side effects, writes to memory, disk, or another service, and a failure occurs between them.

This is where architecture matters. Every system has recovery boundaries: an operation, a transaction, a request, a job, a worker, or the entire process.

A boundary should recover only if it can guarantee that all its side effects completed, were rolled back, or can be safely discarded. If it can’t make that guarantee, recovering may simply allow the system to continue with invalid state.

Sometimes the safest response is to crash your whole process. Sometimes crashing would turn a bad request into an outage. Neither “always recover” nor “always crash” is a useful rule.

The real question is: what is the narrowest boundary at which you can prove the system is still consistent?

Anyhow I've written a blog post about it. I hope at least some find it interesting or helpful. It's focused on Go specifically but a similar pattern works for other languages with more of a try/catch syntax.

Let me know if you use a similar approach or something totally diff. Thinking in terms of invariants is pretty new to me and I'm looking to learn more from other peoples experiences.

Disclaimers: I wrote the article, it is not AI slop regardless of what it sounds like. Also I am the one building Traceway and the blog is on Traceway's website.

We are a small team of 3 to 4 developers building a custom ERP for a few customers.

Our current system has basically become a big ball of mud.

Before I joined, there was already a complete rewrite with the goal of making things more modular, but over time it ended up in pretty much the same place:

• modules, but no real boundaries
• everything can access everything
• one database and one schema
• lots of foreign keys and relations across modules
• almost no events
• a huge common module where more and more shared stuff ended up

Now my boss wants to start from scratch again.

He recently came across Self Contained Systems (SCS) and thinks this could solve the problem.

The idea would be completely separated systems with their own:

• database
• deployment
• backend
• UI

Communication between systems would only happen through defined contracts.

I understand why he likes it. The boundaries are hard to break. A developer working on one SCS cannot simply access the database or internal code of another one.

My concern is that we are only 3 to 4 developers building a fairly traditional ERP. We don't really need independent scaling or independent deployment for organizational reasons.

I'm worried we could end up with a distributed big ball of mud, while also adding things like:

• network communication everywhere
• eventual consistency
• harder transactions
• retries and failure handling
• contract versioning
• more infrastructure
• harder debugging and local development

I would rather go with a modular monolith with strict boundaries.

One deployment, but properly separated domains/modules. No direct access to another module's internals, no cross module repositories, explicit contracts, events where they make sense, and possibly separate DB schemas to reinforce ownership.

We could also use in process events initially without introducing Kafka or another broker.

My boss's main argument is basically:

And I think he has a valid point. Our previous attempt clearly failed.

At the same time, I don't think the previous system ever had real or enforced module boundaries in the first place.

One problem for me personally is that I don't have a huge amount of architecture experience yet, especially with running microservices or SCS in production. I understand the theoretical downsides, but I lack the real world experience to confidently argue which of those downsides will actually matter for a small team like ours.

My boss has around 30 years of development experience, so I also don't want to argue against his approach just because I personally prefer another architecture.

What would you choose for a team and product like this?

Am I underestimating the advantages of SCS here?

Or are we introducing distributed system complexity mainly to enforce architectural discipline that could also be enforced inside a modular monolith?

I'm especially interested in experiences from people who have worked with both approaches in smaller teams.

Been rewriting the material we give juniors before interviews and went through the full GoF list to work out what's actually worth their prep time. Ended up dropping 10.

Most of them weren't close. Prototype is record and with. Flyweight happens under you in ArrayPool<T> and string interning, you're not writing it. Interpreter is every LINQ provider ever shipped and you're not writing one of those either. Abstract Factory only survives as a "so how's that different from Factory Method" gotcha. Memento and State I cut without much thought.

The two I'm less settled on:

Bridge. Eight years in, mostly line-of-business .NET, and I've never watched anyone reach for it deliberately. Every time I think I'm looking at Bridge it turns out to be Strategy with extra steps. If someone has a case where the distinction earned its keep in a real codebase I'd like to see it, because I've started to suspect it only exists in books.

Composite. I use it constantly and have never once decided to. It falls out of expression trees and validation chains and you notice afterwards. Not sure that's a thing you can usefully teach someone to reach for.

The one that actually bugs me is Iterator. It comes up in nearly every interview and never under that name. It's yield return, it's deferred execution, it's "why did this enumerate twice", it's IAsyncEnumerable<T> and what await foreach does with your cancellation token. Nobody has ever asked me to walk them through the Iterator pattern. Makes me think the name is the dead part rather than the idea.

Worth saying this is all from line-of-business web APIs and a lot of EF Core. If you're doing game dev or anything compiler-adjacent I'd expect a completely different list and I'd be curious what's on it.

Link: https://devos.zerohive.ai/

Our engineering team at Zerohive works on large codebases, and we use different coding agents (Claude, Codex, Cursor) basis individual preference.

We kept running into problems where one person's agent will end up rewriting or undoing decisions made by someone else. It led to agents re-introducing bugs which we'd fixed last month. We kept reaching out to each other offline to ask "Hey, why did we store xyz in redis instead of persisting on DB" when the agent proposed redoing the architecture.

We spent months collaborating by making ARCHITECTURE.md, DECISIONS.md, LESSONS.md, ADRs etc and shared skill libraries - but they were soon ineffective as the codebase scaled. We also tried code memory platforms but they could only fetch the 'what' but not the 'why', no provenance on architecture or code patterns so reintroducing bugs problem wasn't solved for complex codebases.

So we built DevOS.

DevOS understands the codebase, correlates the decisions made in the chat sessions with final code outcome, and has a deep understanding of the why behind the code and the architecture. It understands architectural choices, alternatives considered, tradeoffs made and final decisions taken w.r.t code or architecture.

Exposed to coding agents as an MCP, DevOS searches files, symbols, decisions and dependencies in parallel so that models make better changes in fewer iterations and exponentially lesser tokens which otherwise would be spent by agents in grepping the codebase.

Agents can now understand the architecture and codebase better, along with the rationale that went behind the architecture, and context can be shared between teammates within their coding agents.

Use lesser tokens, collaborate better. Completely free to try, no paid tier.

Link: https://devos.zerohive.ai/

Recurrent-depth Transformers or Looped Transformers, reuse the same set of layers for several passes before producing a token.

During inference, the weights stay fixed. What changes is the hidden state: each new pass works on the output produced by the previous pass. Because the model is trained this way, it can learn to use those extra passes effectively. Simply repeating the layers of a normal Transformer would not necessarily improve the result.

The article explains:

• What is meant by layers, blocks, and passes.
• Why another pass can improve the results even if the weights are constant.
• How each pass uses the input information and the updated hidden state from the previous pass.
• How backpropagation calculates gradients used to update the shared weights.
• Why the described model traces gradients through only the last few passes during training.
• How the model can decide when to stop repeating the block.
• Why the KV cache can grow with more passes and how its slots can be reused.
• Where memory can be saved by reusing layers and what additional passes cost in time and computation.

Link : https://crackingwalnuts.com/post/recurrent-depth-transformers

I’m really struggling with this conceptually. I’m self-teaching (since before the AI boom, not a vibecoder), and for B2B SaaS for example, the principle sounds so attractive. I’ve never considered building for regulated industries, but have always thought it seems like the perfect balance for data sensitive enough that a bad query would be an enormous issue.

That said, even when planning and coding hobby projects to try and learn the separate schema implementation with something like Postgres + Python API (any framework) + React, for example, implementation seems like an absolute nightmare. On the flip side, the tradeoff of faux isolation, per-se, through a shared schema with a tenant_id column seems so error prone.

So, as someone with no production experience, I’m looking to understand if separate schema in-practice is worth the loaded up-front cost or not. Any insight appreciated!

Ok so we are trying to get some real ci cd pipeline security visibility across a pretty chaotic setup and im kinda stuck on what is realistic here..

For context we have multiple teams with their own github orgs, random self hosted runners, some old jenkins jobs, some new stuff in github actions, plus a few weird one off deploy scripts that no one wants to touch. Appsec wants one view of where secrets, misconfigs, risky steps etc are across the whole thing and how it ties back to repos and prod, without us building a giant spreadsheet every quarter. Has anyone here gotten decent visibility into people and pipelines and processes like this with an aspmm style tool instead of homegrown scripts? Appreciate any thoughts

Hi guys! I’m fairly new to working mainly with Cloud Architecture, and I’m a very visual thinker. Nowadays, I find it quite challenging to work with AI on complex issues while maintaining a common understanding of the algorithm and, more importantly, clearly communicating what the desired state should be.

I often ask the agent to create a Mermaid diagram of its plan, but the problem is that I can’t easily edit it. Then I started using Excalidraw. The issue there is that it’s difficult for the agent to edit the diagram, and it’s also more expensive for the agent to understand it, since it needs to take a screenshot and process the image.

So, I decided to create a tool that allows both the agent and me to co-draw a diagram.

Here’s the repo: https://github.com/domolitom/crosspoint

What do you guys think about this? Is there an even better approach?

I wrote this after finally sitting down and doing the math on something that's bugged me for a while: what a "temporary" shortcut actually costs versus what doing it right up front would have cost.

Short version - a pricing feed integration got a REST call hardcoded directly into a business-logic service under a 3-day deadline. Worked fine but then the upstream moved to Kafka. Then a subset of suppliers moved to MQTT. Three rewrites of the same core logic in five months, and the last one shipped a retry loop with no idempotency check, which caused a duplicate-payout bug that took a full night to trace back through two layers of accumulated "temporary."

The part I found most interesting writing it is the fix (a port/adapter boundary between business logic and transport) would've cost about a day up front. The three rewrites cost about three weeks combined, plus the incident. The shortcut didn't save time, it just moved the bill downstream and changed who paid it.

The full writeup in the comments for anyone that's interested.

I'm curious how you draw the line on which shortcuts are safe to take under deadline pressure and which ones you regret later, is it always obvious in the moment or only in hindsight?

With all of the "FUD" in the software engineering space, I found it perplexing that even with the smartest models building things for people, the lack of people knowing what to build, what questions to ask, what constraints to give, and most importantly, how to ensure these things do not sprawl or lack fundamental testing parameters was pretty high.

On the SDD side, the concept is good in theory, but really is just a rebrand of "big design upfront" with the hope that a smart enough reasoning in a frontier model, or a continuously looping agent on-premise will just solve the problem.

So, I decided to blend the concepts of SDD with just enough TDD and architectural design in my tool called NodeSpec.io. The architectural component was the hardest because the canvas lives at any level of abstraction. A "node" is considered a bounded set of context related to a specific technology/framework/language (in this case could be as small as an object or class, or as large as a set of tightly coupled services with a defined external interface), a platform (i.e. AWS Cognito), or external service/API. The edges represent known relational movement of data between nodes, either authentication, read/write, streams, events, etc.

My favorite part is the canvas an actual logic-bearing architectural reference and not just a static diagram. If you export a cloud service, it exports as context with instructions and tests for a machine or human developer to build against.

This project has taken me 4.5 months, and decided to do the open core path so that regular everyday people and software architects to build better and faster with the fast moving technology space today.

One of the hardest problems I'm solving right now in the platform-version is a repository reverse engineering capability so you could hand NS a git, a set of deterministic logic scans and bundles code based on readme and file contents, then uses your AI as the final step to provide an assessment, visualization on the canvas, and ability to work and govern your development across a team without breaking the fundamentals of GitOps.

Would love feedback from devs, architects, or regular dudes who read reddits like this and tinker or build within their companies.

github: https://github.com/NodeSpec/NodeSpec

​

I have a distributed execution lifecycle with:

INITIAL — first attempt, no parent

EXPLICIT_RETRY

SAFE_RUNTIME_RETRY

There is an existing closed mode called RETRY_RESOLUTION, originally defined only for retries of an already-admitted execution.

A new requirement now needs the same role/state validation before every attempt, including INITIAL.

The choices are basically:

widen RETRY_RESOLUTION to include INITIAL

introduce a new umbrella mode like ATTEMPT_START_RESOLUTION

keep separate initial/retry modes

My concern is semantic stability rather than naming. INITIAL has no retry lineage, while actual retries require a parent. This vocabulary is also used around audit and authorization-adjacent validation.

Would you consider widening the existing mode backward-compatible because the wire value stays unchanged, or a semantic breaking change that deserves a new versioned abstraction?

Especially interested in anyone who has dealt with this in production state machines, workflow engines, distributed systems, or long-lived contracts.

Why I chose Offline-First over Cloud SaaS for private academy HR and payroll
When building Oncilla OS, an operating system for private language academies, directors kept repeating the exact same complaints:
Bloated ERP systems that take weeks to set up and configure.
Hesitation to upload staff National IDs and payroll files to third-party cloud servers.
Fatigue from expensive recurring monthly subscriptions.
The design solution was a local-first interface focused on task density. In the staff drawer, all essential details from instructor credentials to monthly payment allocations—are verifiable at a glance, with Pay Salary placed as the direct primary action.
The app runs locally on the machine, loads with zero latency, and operates completely offline without storing operational data on remote servers.
I would appreciate your feedback on the layout density and information architecture.
#oncillaos #oncillaSpace #edtech #operatingSystem

We run a batch job that selects every user matching a predicate - has_installed = false currently ~50M rows — reading them in pages over several hours and writing a record for each one. Separately, an event stream tells us when a user's flag flips to true, which is the moment we're supposed to act on them. But that flip event is discarded for any user whose record hasn't been written yet, so anyone who flips while the job is still running is silently dropped. To cover that gap, we emit one "re-check this user" message per selected user: 50M messages asking "is the flag true?" of a set we built by selecting "flag is false" - so essentially all of them are guaranteed no-ops.
How do you detect rows entering a predicate without doing work proportional to the size of the set?

With AI and Vibe Coding, it can be more reliable if standard patterns are imposed in context, which are well documented and have existed for decades.

One pattern I have rediscovered and am successfully applying is the hexagonal clean architecture.

The result is that AI Is much more reliable.

Each component has limited responsibilities and a specific place.

For those interested in learning more:

https://adrianofoschi.com/blog/architecture-as-a-standard/

Edit: To address some legitimate criticisms. This isn't about imposing clean architecture as a standard, but simply demonstrating that AI is more reliable based on documented standards. Every decision left to AI increases the margin for error.]} Note:

When building Oncilla OS at Toolbox Studio, the engineering objective was clear: develop a high-performance, offline-first operating system engineered specifically for language academies and training centers.

The latest release focuses on enterprise-level data resilience, privacy compliance, and native disaster recovery:

Local Data Sovereignty & Zero Cloud Dependency Operational databases containing student records, attendance tracking, and financial ledgers should remain under the full control of the organization. Oncilla OS eliminates third-party cloud vulnerabilities by operating 100% locally on the host machine.

Encapsulated Disaster Recovery (.oncilla Snapshots) System administrators can generate full portable database snapshots in a single click. The platform uses native system file dialogs to export encrypted .oncilla recovery files directly to local drives or cold storage, completely bypassing external API endpoints.

Hardware-Bound Security Architecture Access control integrates unique Hardware ID (HWID) binding alongside cryptographic Disaster Recovery Keys, ensuring workspace authentication remains strictly tied to authorized institutional devices.

Zero Latency Execution Local storage architecture removes network bottlenecks. Student registries, CRM pipelines, and financial ledger calculations render instantly without loading states or API throttling.

Perpetual License vs Subscription Fatigue Modern enterprise software should be an asset, not a perpetual monthly liability. Oncilla OS restores the standalone software model with zero recurring monthly platform fees.

Designing enterprise infrastructure requires prioritizing local reliability and user data ownership over cloud convenience.

How is your organization addressing local data ownership, disaster recovery, and subscription bloat this year?

#EnterpriseUX #SoftwareArchitecture #OfflineFirst #LocalFirst #DataPrivacy #DatabaseDesign #EdTech #ProductDesign #B2BSoftware #SystemDesign #DisasterRecovery #ToolboxStudio #OncillaOS

I've been experimenting with running multiple coding agents on the same project.

The problem wasn't getting agents to write code.

It was coordinating them.

Once you have multiple agents working in parallel, you start dealing with questions like:

- Which agent is working on what?

- How do you prevent two agents from picking up the same task?

- How do agents know what needs to happen next?

- How do you track what each agent actually did?

- What happens when you want the agents to keep working without manually managing every step?

So I built orcy.

It's an open-source coordination layer for AI coding agents.

The basic workflow is:

Mission → Claim → Execute → Review

Agents can claim atomic tasks, work in parallel, route themselves toward relevant work, and leave an auditable trail of what happened.

The idea is pretty simple:

Instead of one AI agent doing everything, let multiple agents operate as a coordinated system.

I'm looking for developers who are already experimenting with Claude Code, Codex, OpenCode, Cline, or other coding agents to try it and tell me where the idea breaks.

GitHub: https://github.com/waterworkshq/orcy

Would love feedback, especially from people already running multiple agents on the same codebase.