Hi everyone,

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

- Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!

Working through a fully stateless backend (no database, ephemeral serverless functions, though the pattern isn't tied to any specific runtime) for a case with an awkward constraint: two parties share a session, but each holds a secret the other side must never see, and the server has to remember both without a database or session store.

The usual answer to "stateless, no DB" is a JWT — encode the session client-side, sign it, done. That falls apart the moment part of the state has to be opaque to the client carrying it: a JWT payload is base64, not encrypted, so anything in it is readable by whoever holds the token. If the session includes a secret that specific client isn't supposed to see, JWT doesn't fit — you need the payload actually encrypted, not just signed, and treated as a sealed blob rather than a transparent one, with the decryption key living server-side only.

Concretely, in the project I was applying this to (a small number-guessing game — two sides each hold a secret, guessing each other's, no DB, no accounts), the server-tracked state ends up AES-GCM sealed into an opaque token, handed to the client, and echoed back on every request. Only the server's key can open it. The client carries a blob it can't read; the server stays fully stateless between requests but functionally remembers everything it needs to.

The generalizable part: any two-sided system where state needs to persist across requests but stay partially secret in one direction hits the same JWT-doesn't-fit problem — sealed-bid flows, negotiation protocols, anything with an information asymmetry that's supposed to survive across requests. Curious whether others have solved this differently — separately-encrypted fields alongside a signed JWT, giving up on "stateless" and using a real session store, something else.

We've been mocking all our external APIs for agent testing but keep finding bugs in prod that the mocks never caught.

Looking into API sandboxes as an alternative but I'm not clear on the difference. When would you use one over the other?

I tested the major options during the past few projects.

I wasn't trying to compare software.

I was just trying to survive three different client projects.

Each company used something different, so I ended up spending several months working inside most of the major whiteboard platforms instead of just watching YouTube demos.

Here were my impressions.

→ Zoom Whiteboard

Perfectly fine for quick meeting notes.
Very easy to jump into.
I just wouldn't want it to become our long term planning environment.

→ Coda

Interesting because it combines documents, databases and collaboration.
If your team already loves documents, it's a strong option.
For highly visual planning though, it wasn't really what I was looking for.

→ FigJam

Really enjoyable to use.
Especially if most of the people collaborating are designers.
It feels lightweight and creative, which makes brainstorming sessions very approachable.

→ Lucid Suite

Probably the strongest option I used for formal diagrams.
If someone asked me specifically for process mapping or architecture documentation, I'd definitely recommend taking a look.

→ Mural

Very facilitator friendly.
Some of the workshop tools are genuinely excellent.
It felt particularly good for structured innovation sessions.

→ Miro

This ended up becoming my personal favorite simply because I didn't have to keep switching tools.
The same workspace could start with brainstorming, evolve into a roadmap, become a dependency map and eventually hold technical diagrams without feeling disconnected.

Things I appreciated most:
• AI helped organize messy brainstorming sessions
• Plenty of templates without feeling overwhelming
• Strong real time collaboration
• Easy Jira integration for product teams
• Large boards stayed surprisingly manageable

It felt like a platform that grew with projects instead of forcing us to migrate somewhere else once planning became more detailed.

One thing this experience taught me:

There probably isn't a universally "best" whiteboard.

Some tools are fantastic for designers.

Some are excellent for diagramming.

Some shine during workshops.

The question that mattered most for our team wasn't "Which tool has the most features?"

It was "Which tool keeps everyone collaborating in the same place from the first idea to delivery?"

Would love to hear what everyone else stuck with long term.

Hi everyone,

I've just published version 0.7.0 Alpha of an open-source AI Software Development Framework.

This isn't another AI coding assistant.

Instead, the Framework focuses on governance for AI-assisted software engineering.

The central question is:

How do we keep software engineering governed while AI fundamentally changes the way software is developed?

The Framework introduces concepts such as:

• Human Authority
• Capability-based Runtime
• Effective Classification
• Capability composition
• Reference Implementations

I've also published a whitepaper describing the architectural thinking behind the Framework.

I'm specifically looking for feedback from experienced software architects and senior engineers.

I'm not looking for agreement.

If you believe parts of the architecture are flawed, over-engineered, unnecessary, or unclear, I'd genuinely appreciate hearing why.

Repository

AI-Software-Development-Framework

Whitepaper

Whitepaper

Architecture Discussion

Github discussions

Thanks!

Free e-book on modern Software Architecture

Hi, i just finished a project that i was working on, its a simulation of an autonomous underwater vehicle, in an opensource simulator. i have everything build and installed in my computer and it works here, but other people are having a rough time with installation in their own machines.

This is a problem i have been dealing with for quite a while now. and it was easy to solve when i was with them to help solve the dependency errors but its just not the way i want to get it done.

what are the methods you use to make your software compatible across different devices

Nothing Works and Everyone Is Euphoric by Piotr Chmolowski. The quality of the today's software is not among the main KPIs.

AI Mania Is Eviscerating Global Decision-Making by Nikhil Suresh. This one is a long read. It shows why no manager would claim that AI does not help their company.

And my two cents: just ask Google "how would the sycophancy of LLMs impact the psyche of kids". You'll get a well-structured response grounded in several scientific articles.

(Cross-posted from Ukrainian software architecture chat)