DEV Community: Syed Ibrahim

A Case Study in Integrating the Zoom Native SDK into a Flutter Monorepo

Syed Ibrahim — Fri, 14 Aug 2026 10:40:07 +0000

Forking a plugin, fighting Gradle and AAR packaging, migrating a repo to Git LFS, and chasing a SQLite ABI conflict that passed a green build — and what it took to keep all of it from leaking into the rest of the application.

Integrating a third-party SDK into a Flutter application can look deceptively simple:

Add package → Initialize SDK → Authenticate → Join meeting

That's roughly what I expected when I started integrating the native Zoom Meeting SDK into my Flutter monorepo. It didn't turn out that way.

The hard part wasn't calling Zoom's APIs from Dart. It was making a large native SDK coexist with an application that already had its own database layer, Android build configuration, package architecture, and repository constraints.

By the end, the integration touched:

Forking an existing Flutter Zoom plugin and owning the native bridge myself
Android namespace changes and Gradle AAR packaging restrictions
Jetpack Compose / ViewBinding alignment
280+ MB Android binaries and 145+ MB iOS binaries, and a Git LFS migration to hold them
A duplicate libsqlite3.so that turned into a genuine ABI compatibility bug
Introducing a MeetingService abstraction so my courses domain package never has to know Zoom exists
Making Zoom an optional, per-client dependency, since not every client on the platform needs video conferencing

The most important lesson wasn't about Zoom. It was about how to integrate a native SDK without letting the SDK dictate the architecture of the application around it.

1. The Starting Point

My app is a Flutter monorepo with multiple packages:

cortex/
├── app/
├── packages/
│   ├── core/
│   ├── courses/
│   ├── exams/
│   ├── profile/
│   └── ...

The courses package handles lessons, and, when appropriate, lets a student join a video conference. The obvious implementation would have been for courses to talk to Zoom directly — but that immediately creates coupling: now the domain package knows about a specific vendor.

I separated two concerns that are easy to conflate:

The application needs a way to join a meeting.
Zoom is one implementation of that capability.

That distinction shaped everything that followed.

2. Why I Forked the Plugin Instead of Using It As-Is

I started with the flutter_zoom_meeting_sdk package. It's a thin wrapper around Zoom's native Meeting SDK — its own dependencies are just flutter, http, and plugin_platform_interface. That's the plugin, not the SDK: it doesn't bundle any Zoom binaries. The documented setup is to download mobilertc.aar yourself from the Zoom App Marketplace and manually copy it into the plugin's own installation folder inside .pub-cache (android/libs), then hand-edit that copy's Gradle file to add Zoom's required dependencies.

That's workable for a quick prototype, but not for something I intended to keep working long-term. Anything placed by hand inside .pub-cache disappears the moment someone runs flutter pub cache clean or the plugin version changes — the build stops being reproducible from the repository itself, since the actual SDK binary and the Gradle edits it needs never get committed anywhere.

On top of that, the plugin also pulled in http for its own JWT-handling helpers, which overlapped with networking infrastructure I already had in the app. And since Zoom's SDK is large and native, I wanted direct control over its Android and iOS build configuration rather than treating it as an opaque pub.dev dependency I couldn't touch.

So I created my own local package:

packages/zoom/

and moved the native bridge into it — copying the plugin's Kotlin/Swift bridge code into my own package, and moving the SDK binaries (and the Gradle changes they require) into the repository instead of .pub-cache. The goal wasn't to rewrite Zoom's SDK — it was to own the Flutter-to-Zoom bridge, while still using Zoom's actual native binaries underneath. That package became the boundary between my application and Zoom, and let me drop the third-party plugin from my dependency tree entirely.

I also took ownership of the Android namespace, changing it from the upstream plugin's com.simitgroup to com.testpress.flutter_zoom_meeting_sdk, updating package declarations, manifest entries, and Gradle config to match. Once you fork a native plugin, you inherit its entire native build identity — it's no longer "a package from pub.dev," it's part of your codebase.

I also had to rework how the native bridge managed Flutter's platform-channel event sinks. The original implementation captured the EventSink too early — before the Flutter engine had finished initializing — so events from Zoom sometimes arrived to a listener holding a stale null reference. The fix was to resolve the sink lazily via a closure at the moment it was actually needed, rather than caching it at construction time. It's a good reminder that a platform channel existing in code doesn't mean its runtime endpoint is ready the instant an object is constructed.

3. Android Build Problems: AARs Are Not Normal Dependencies

AARs don't drop in like a normal file

The Zoom Android SDK ships as an AAR — mobilertc.aar. My first instinct was to treat it like any local file:

implementation(files("libs/mobilertc.aar"))

Android Gradle Plugin doesn't allow that when you're building another AAR yourself — the resulting library would be broken because the local AAR's classes and resources wouldn't be packaged correctly. The fix was to configure a local flatDir repository and resolve it as a proper dependency instead of an arbitrary file:

implementation(
    group = "",
    name = "mobilertc",
    ext = "aar"
)

The SDK raised the floor on the rest of the toolchain

Zoom's SDK also came with its own minimum requirements for the rest of the Android build: minSdk 26, NDK 27.0.12077973, Java 17 as both source and target compatibility, and core library desugaring enabled (coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:2.0.4")). None of that is optional — it's what the native SDK needs to link and run, so I had to raise my app's own Android build to match.

The namespace change had downstream fallout

The namespace change from earlier surfaced stale imports and references to native constants that didn't exist in my SDK version, and Zoom's native UI components required aligning ViewBinding and Jetpack Compose (via the Compose BOM) with the rest of the app's dependency graph. None of this was a Dart problem — it was the cost of bringing a large native Android SDK into a build that already had its own dependency graph.

4. Then GitHub Rejected the Repository

Once the SDK was building locally, I hit a completely different wall: GitHub wouldn't accept the push. mobilertc.aar was around 282 MB, and the iOS MobileRTC binaries were around 145 MB — both well past GitHub's 100 MB per-file limit.

Compression wasn't a real option. An AAR is already essentially a ZIP archive, so zipping it again doesn't meaningfully shrink 280 MB. I needed a system built for large binaries: Git LFS.

Instead of storing the full binary in the Git object database, Git LFS stores a small pointer and keeps the actual payload in LFS storage. Since the binaries were already committed to history, tracking them going forward wasn't enough — I had to migrate history itself:

git lfs migrate import \
  --include="*.aar,MobileRTC" \
  --include-ref=refs/heads/feat/zoom-plugin

This rewrote hundreds of commits on the feature branch, which then had to be force-pushed.

Git LFS introduced its own gotcha shortly after: Gradle choked trying to process mobilertc.aar when it was only ~134 bytes — a pointer file, not the actual archive, because the real LFS payload hadn't been pulled. The fix was making sure .gitattributes correctly tracked the binaries and running git lfs pull to materialize the real files:

*.aar filter=lfs diff=lfs merge=lfs -text
MobileRTC filter=lfs diff=lfs merge=lfs -text

The underlying lesson: Git LFS is transparent to your build system only when the working tree actually contains the real binary. Without the LFS client, or without pulling the objects, your compiler sees the pointer, not the SDK.

5. The Real Problem: Two `libsqlite3.so` Files

Once the SDK was compiling, I hit the most interesting failure of the whole project:

Execution failed for task ':app:mergeDebugNativeLibs'
2 files found with path 'lib/armeabi-v7a/libsqlite3.so'

Gradle pointed to two sources: mobilertc and sqlite3-native-library. I wasn't intentionally shipping two SQLite libraries — one came from Zoom, and the other turned out to come from my own database stack.

I use Drift for local storage, and the dependency chain looked like:

packages/core → drift → sqlite3 → native SQLite

The key detail: newer versions of the sqlite3 package moved native SQLite compilation into Flutter's Native Assets system. So even without anyone writing sqlite3_native_library anywhere, the dependency graph was quietly producing a libsqlite3.so of its own.

Here's the part that made this more than a packaging annoyance: two files with the same name aren't necessarily the same binary. Zoom's native database layer expected specific SQLite symbols, and when the wrong implementation got packaged, the dynamic linker couldn't resolve one of them:

java.lang.UnsatisfiedLinkError:
dlopen failed:
cannot locate symbol "sqlite3_trace_v2"
referenced by "libZMDB.so"

The tempting, wrong fix

Gradle offers a built-in escape hatch:

packaging {
    jniLibs {
        pickFirsts.add("**/libsqlite3.so")
    }
}

This makes the build succeed — Gradle just picks one of the duplicate files and moves on. But pickFirst only answers which file gets packaged, not which implementation is actually compatible with everything that loads it. In my case, the build went green and the app still crashed at runtime. A successful build is not the same thing as a correct native integration.

The actual fix

Instead of overriding the packaging decision, I traced the dependency graph back to its source:

drift → sqlite3 3.x → Flutter Native Assets → libsqlite3.so

Once I knew why a second SQLite binary existed, the fix was straightforward — constrain the version so the newer Native Assets path never kicks in:

dependencies:
  drift: ^2.21.0
  sqlite3: "<3.0.0"
  sqlite3_flutter_libs: ^0.5.30

I kept sqlite3_flutter_libs deliberately — it's not redundant with sqlite3. sqlite3 provides the Dart-side FFI interface; sqlite3_flutter_libs provides the native library that interface talks to on platforms where Zoom isn't involved. Removing it would have broken Drift on any build where Zoom's native SQLite wasn't present. The fix worked because it changed what gets generated, not which of two already-generated binaries wins a coin flip.

One thing worth being explicit about: this pairing is the pre-3.0 model. sqlite3's own upgrade guide recommends dropping sqlite3_flutter_libs entirely once you move to sqlite3: ^3.0.0, because 3.x switched to Flutter's hooks system to download and bundle SQLite automatically — sqlite3_flutter_libs is a no-op from 0.6.0 onward. I went the other way on purpose. Upgrading to 3.x wouldn't have solved my problem; it just moves how the second libsqlite3.so gets generated, from an old build script to a hook, while still generating one. Staying on sqlite3 <3.0.0 with the real sqlite3_flutter_libs (0.5.x, before it became a no-op) is what actually avoided producing a second native SQLite build in the first place.

At this point the native integration problem was solved — Zoom initialized, authenticated, and joined meetings without crashing. But a different problem was still open: the integration worked, yet I didn't want the rest of the application to know how it worked.

6. Separating Zoom from `courses`

courses shouldn't know Zoom exists. So at the core layer I defined an abstraction:

abstract class MeetingService {
  Future<void> joinMeeting({
    required String jwtToken,
    required String meetingNumber,
    required String password,
    required String displayName,
  });
}

courses only depends on MeetingService — it has no idea whether the implementation is Zoom, Teams, Meet, or nothing at all. I introduced a small registry in packages/core so an implementation can be registered without core ever importing Zoom:

packages/core
    ├── MeetingService
    ├── MeetingServiceRegistry
    └── meetingServiceProvider

packages/zoom
    └── ZoomMeetingService implements MeetingService

Laid out in full, the composition looks like this:

                         ┌───────────────┐
                         │      app      │
                         │  Composition  │
                         │     Root      │
                         └───────┬───────┘
                                 │
                       registers implementation
                                 │
                                 ▼
┌──────────────┐        ┌─────────────────┐
│   courses    │───────▶│      core       │
│              │        │                 │
│  Conference  │        │ MeetingService  │
│      UI      │        │    Provider     │
└──────────────┘        └────────┬────────┘
                                  ▲
                                  │ implements
                                  │
                         ┌────────┴────────┐
                         │      zoom       │
                         │                 │
                         │ ZoomMeeting     │
                         │ Service         │
                         └────────┬────────┘
                                  │
                          Native Zoom SDK

courses depends on a capability (MeetingService), not on zoom directly. zoom implements that capability. app is the only place that knows both exist, and it's the only place that wires them together.

Since I already use Riverpod, it became the composition layer:

final meetingServiceProvider = Provider<MeetingService?>((ref) {
  return MeetingServiceRegistry.instance;
});

courses reads the provider and calls joinMeeting() — it never imports package:zoom. The lobby UI wraps this in a simple loading state (joining = true/false) around the tap-to-attend button, so a native initialize/authenticate/open-meeting sequence can't be triggered twice by an impatient double-tap.

7. Making Zoom Optional, Per Client

This platform serves multiple clients, and not all of them need video conferencing — some don't offer live classes at all. Bundling a ~280 MB native SDK into every client's build regardless of whether it's ever used isn't a reasonable default, so Zoom needed to be a dependency that could be included or excluded per client rather than something every build carries permanently.

The first version of this was more literal than it needed to be: dynamically rewriting pubspec.yaml at build time based on a zoom_enabled flag, then running flutter pub get before building each client. It worked, but it made the Dart dependency graph itself something the build had to mutate on every run, which is fragile in ways that are hard to see until CI catches it.

The version that stuck moved the decision to the build composition layer instead: whether a given client's build includes packages/zoom — and therefore registers ZoomMeetingService against MeetingService — is a per-client build-time decision, resolved once at the composition root rather than by rewriting the dependency manifest at runtime. Clients that don't need conferencing simply don't pull the package in, don't carry the native binaries, and never touch the SQLite/Gradle complexity described above. Clients that do need it get the full MeetingService → ZoomMeetingService wiring.

The requirement was never that the Dart abstraction disappear for clients without conferencing — MeetingService can stay defined in core either way. The actual requirement was narrower: clients without conferencing shouldn't carry the native Zoom SDK. Once that was the target, the composition-layer approach was the simpler way to hit it. If MeetingService isn't registered for a given client, that capability just isn't available, and the surrounding UI treats it like any other feature that client doesn't have.

8. What the Final Package Actually Looked Like

Zoom's pieces were scattered across a lot of this article, so here's the whole thing in one place:

packages/
└── zoom/
    ├── lib/
    │   └── zoom_meeting_service.dart
    ├── android/
    │   ├── src/main/kotlin/com/testpress/flutter_zoom_meeting_sdk/
    │   ├── libs/
    │   │   └── mobilertc.aar
    │   └── build.gradle.kts
    └── ios/
        ├── MobileRTC.xcframework/
        ├── MobileRTCResources.bundle
        └── zoom.podspec

Dart layer — ZoomMeetingService, the concrete implementation of MeetingService.
Android — the Kotlin bridge plus mobilertc.aar, resolved as a flatDir dependency.
iOS — the Swift bridge plus MobileRTC.xcframework and its resource bundle, wired through zoom.podspec.
Git LFS — tracks the native binaries in both platform folders.
core — owns the MeetingService abstraction and registry; never imports this package.
app — the only place that imports zoom directly, and only for clients that need it.

Everything Zoom-specific stays inside this one package. Nothing outside it needs to know Zoom is what's behind MeetingService.

Solutions That Didn't Work

Some of the most useful information here is what I tried and abandoned:

Attempt	Result	Why
Use the upstream plugin directly	Too much external/native coupling	SDK and build assumptions baked into the plugin
Commit the native binaries normally	GitHub rejected the push	Past the 100 MB per-file limit
Compress the AAR before committing	Didn't help	An AAR is already a ZIP archive
`pickFirst` on the duplicate `libsqlite3.so`	Build succeeded, app crashed at runtime	ABI/symbol mismatch between the two binaries
Remove `sqlite3_flutter_libs` entirely	Fixed the duplicate, broke Drift elsewhere	Drift still needs a native SQLite on builds without Zoom
Let `courses` call Zoom directly	Worked, technically	Wrong dependency direction — domain package coupled to a vendor
Dynamically rewrite `pubspec.yaml` per client	Worked, but fragile	Better handled once, at the build composition layer

9. What the Native Dependency Graph Taught Me

At the Dart level, my dependency graph looked harmless:

courses → core → drift

The actual build graph was closer to:

core → drift → sqlite3 → Native Assets → libsqlite3.so
                                              │
zoom → mobilertc.aar → libZMDB.so ───────────┘

A package can introduce native behavior transitively, in ways that are invisible from pubspec.yaml alone. I wasn't thinking "I added a native SQLite library" — but that's exactly what the dependency graph was doing on my behalf.

That's also why pickFirst deserves more suspicion than it usually gets. It's the right tool when two dependencies genuinely ship the same binary. It's the wrong tool when they ship different builds of the same-named library — at which point it silently converts a build-time error into a runtime linker failure, which is strictly harder to debug. My build-time error (Duplicate libsqlite3.so) was actually more useful than the alternative would have been, because it forced me to find the real source instead of papering over it.

The debugging pattern that worked, in order: read the exact build error before touching Gradle; ask why the duplicate exists in the first place; trace the transitive dependency; understand what changed between versions; and fix the source of the conflict rather than the symptom.

Principles Worth Keeping

A few things generalize beyond Zoom:

Depend on capabilities, not vendors. courses → MeetingService, not courses → Zoom. The vendor sits behind an interface the domain layer never has to know about.

Solve dependency conflicts at their source. A version constraint that prevents an unwanted binary from being generated is more maintainable than a packaging override that arbitrarily picks between two binaries that already exist.

A green build isn't proof of a correct native integration. pickFirst can make Gradle stop complaining while the dynamic linker still fails at runtime. Native compatibility has to be validated at runtime, not just at build time.

Large vendor binaries need their own storage strategy. Once your repository contains hundreds of megabytes of native SDK, Git LFS isn't an afterthought — it's part of the architecture.

Own the fork when the third-party wrapper doesn't fit. Forking a plugin isn't inherently bad. It's the right call when the native SDK is central to your app, the existing wrapper carries incompatible assumptions, and you need real control over namespaces, build configuration, and reproducibility. The important thing is to own the fork intentionally, rather than accidentally maintaining a fragile copy of someone else's package.

Conclusion

What started as "add Zoom meetings to my Flutter app" turned into a broader exercise in figuring out where responsibility actually belongs: the native SDK behind a plugin boundary, the Zoom-specific implementation in its own package, the courses domain depending on a capability instead of a vendor, large binaries in a system built for large binaries, and the decision of which clients even carry Zoom pushed out to the composition root instead of baked into the domain code.

The mysterious libsqlite3.so collision turned out to be the most valuable failure in the whole project, because chasing it down — instead of silencing it with pickFirst — is what taught me the question worth asking whenever two native dependencies collide:

When two native dependencies collide, don't immediately ask which one should win. Ask why both are there in the first place.

Why Not Every AI Application Needs Vector Embeddings

Syed Ibrahim — Wed, 15 Jul 2026 13:43:40 +0000

How building an AI chapter generator taught me to stop reaching for a vector database first.

When I started building my AI chapter generator, I spent hours researching vector databases. I was convinced I needed one.

I didn't.

The idea

The project was simple on paper. A user uploads a long lecture video, the app transcribes it, figures out where the instructor moves from one topic to the next, and spits out timestamped chapters.

Before I'd written a single line of the actual feature, my brain had already decided what the architecture should look like. Long text plus AI app equals: chunk it, embed it, store it, retrieve it. That's just the shape everyone's trained to see these days.

So that's the road I went down. I spent an evening comparing Pinecone, Chroma and FAISS. I read through chunking strategies, fixed size chunks, overlapping windows, semantic chunking, all of it. I had a RAG pipeline half sketched out in my notes app.

Then I stopped and asked myself something a lot more basic:

What problem am I actually trying to solve?

I didn't have a good answer. So I backed up and started over.

What embeddings actually do

If you're newer to this stuff, here's the plain version.

An embedding turns a piece of text into a list of numbers that captures what it means. Text with similar meaning ends up with similar numbers. That's really the whole trick behind it. It turns "how similar are these two ideas" into "how close are these two points," which is something a computer can check almost instantly, even across millions of documents.

That's a genuinely useful trick, but notice what it's actually for. It's for finding things. If you've got 10,000 support articles and someone asks a question, you can't just feed all 10,000 into the model every time. It wouldn't fit, and even if it somehow did, it'd be painfully slow. Embeddings let you narrow that pile down to the handful of articles that are actually relevant, and only those get handed to the model.

That narrowing down is retrieval. And retrieval turns out to be a different job than reasoning.

Retrieval vs reasoning

This is the part that took me a minute to actually get, and I think it's the bit most people gloss over.

Embeddings solve retrieval. They're good at finding a needle in a haystack you can't fully read.

LLMs handle reasoning. They think through whatever's in front of them.

RAG is called Retrieval Augmented Generation because retrieval is just a preprocessing step that decides what the model gets to look at. It doesn't make the model reason any better once it's looking at the right thing. It just makes sure it's looking at the right thing in the first place.

Which leads to an obvious question. What if the model already has the right thing?

That was basically my situation. The whole transcript was already right there. Nothing was buried somewhere I needed to dig it out of. There was nothing to find. Just something to work through, in order.

But don't long transcripts still need chunking?

Yes, and this tripped me up for a bit, so it's worth spelling out.

A one hour lecture transcript is way too long to comfortably send in one model call. So you still have to split it up somehow. That part's unavoidable.

But there are two different reasons you'd chunk something, and I'd been mushing them together in my head without realizing it.

Chunking for retrieval splits text so you can search it. Each chunk gets embedded and scored against a query, and only the best matches get used.

Chunking for context just splits text because of size limits. Every chunk still gets used, in order, nothing gets filtered out.

I needed the second kind. Not "which piece is most relevant," but "here's the whole thing in pieces, go through all of it, in order." That doesn't need embeddings. It just needs a loop.

The moment it clicked

Once I'd separated retrieval from reasoning in my head, and chunking to search from chunking to fit, things got a lot clearer fast.

I asked myself how a person would do this task. Not an AI, an actual human sitting there watching the lecture.

They wouldn't be scanning through looking for the paragraph most "similar" to some query, because there's no query. Nobody's asking a question. They'd just watch it from start to finish and notice, naturally, when the instructor wrapped up one idea and moved on to the next.

That's when it actually clicked. Chapter generation is about sequence, not similarity.

Embeddings answer "where in this pile does something like X show up." My problem was "where does this one, ordered thing change." Those aren't the same problem wearing different clothes. They're genuinely different problems, and no clever chunking-for-retrieval trick was going to fix that, because retrieval was never actually the job.

What I thought I needed

Transcript
   │
   ▼
Chunk for retrieval
   │
   ▼
Embed each chunk ──► Vector database
   │                         │
   │      (similarity search)│
   ▼                         ▼
        Query-relevant chunks
                │
                ▼
              LLM
                │
                ▼
            Chapters

What I actually built

Transcript
   │
   ▼
Chunk sequentially (for size, not search)
   │
   ▼
LLM reads each chunk in order,
carrying forward a rolling summary
   │
   ▼
Flag topic transitions
   │
   ▼
Merge + align to natural pauses
   │
   ▼
Chapters

Same input, same output, half the pipeline.

What I actually built

Here's the workflow, roughly:

Transcribe the video.
Split the transcript into sequential chunks of a few minutes each, keeping order and timestamps intact.
Feed each chunk to the model along with a short rolling summary of everything before it, and ask it to flag where the topic shifts.
Merge the transitions that land close together, and snap each boundary to the nearest natural pause so a chapter doesn't start mid sentence.

Step 3 is really the whole trick. Each chunk carries context forward from the ones before it. The model isn't staring at six disconnected fragments trying to guess how they relate, it's walking through the lecture the way a person would, carrying the thread as it goes. That continuity is what actually lets it notice "okay, this is where the topic changed." It's also exactly what a similarity search would throw away, since similarity search treats every chunk as its own isolated thing to be scored.

No vector database, no embedding calls, no retrieval step.

The real reason I dropped embeddings

I could frame this as a story about cost or speed. Fewer moving parts, lower latency, no vector DB bill. Those were real benefits and I did get them. But that's not actually why I made the change, and leading with that would kind of miss the point.

The real reason is simpler. Embeddings would have solved a problem I didn't have. My bottleneck was never "how do I find the relevant part of this transcript," because the whole transcript was the relevant part. Bolting retrieval on top wouldn't have made the output better, it would've just added machinery answering a question nobody was asking, while the actual question, where does the topic change, stayed exactly as unsolved as before.

Cost and latency got better as a side effect of cutting something unnecessary. They weren't the reason it was unnecessary.

Embeddings are still great, when you actually need retrieval

None of this is an argument against embeddings. I still use them all the time, just for a different kind of problem.

Say you're building a support bot on top of 10,000 help articles. Someone asks a question and there's no way to hand the model all 10,000 articles at once, it needs to find the handful that are actually relevant first. That's exactly the retrieval problem embeddings were built for, and it's a great use of a vector database there.

The difference between that and my chapter generator isn't the amount of text involved, both had plenty. The difference is whether the model needs to search across a bunch of separate things, or read through one thing it already has in full.

Needs retrieval: company docs, big knowledge bases, research paper libraries, product manuals, support article collections, long chat history archives.

Doesn't need retrieval: summarizing a single document, translating text, classifying content, pulling structured data out of one file, reviewing a single codebase, generating chapters from one transcript.

If the model already has everything it needs sitting in front of it, embeddings don't help it reason better. There's nothing to find, so there's nothing for retrieval to speed up.

A question worth stealing

Before I add a vector database to anything now, I ask myself one thing, and it's worth stealing if you don't already ask it:

Does my AI need to find information, or does it already have it?

If it already has everything, embeddings won't make the answer any sharper. They'll just add cost, latency, and one more system that can quietly break on you.

Final thoughts

I almost built a whole retrieval pipeline for a problem that had nothing to retrieve, just because that's the default move everyone reaches for. The real lesson here wasn't about embeddings specifically. It was about catching myself solving the problem the tutorials describe instead of the one actually sitting in front of me.

The best architecture isn't the one with the most pieces. It's the one that solves the actual problem with the least stuff bolted on.

See it in action

The ideas in this article weren't just theoretical—they came from building a real application.

If you'd like to try it yourself, here's the live demo:
https://trywaypoint.streamlit.app/

OpenSpec: The Missing Layer Between You and Your AI Coding Assistant

Syed Ibrahim — Mon, 15 Jun 2026 13:14:35 +0000

If you have spent any time doing AI-assisted development or vibe coding, you already know the problem.

You open a new chat.
Start building something.
The AI just runs with it.

No alignment, no scope, no shared understanding of what you are actually trying to do.

That works fine for small throwaway tasks. But when you are working on a real codebase, things go sideways fast.

The AI makes assumptions. Scope creeps. You end up with code that technically works but does not match what you had in mind.

OpenSpec fixes this by introducing one simple idea

agree on what you are building before any code gets written.

It gives you and your AI coding assistant a lightweight structure to follow for every change you make. Before implementation starts, you define the intent, the scope, and the approach. The AI reads that and works within those boundaries instead of guessing.

The result is more predictable output, less back and forth, and something that matters a lot in fast-paced development ~ the reasoning behind your decisions is actually preserved instead of disappearing into chat history.

What is OpenSpec?

OpenSpec is a spec-driven development framework. It sits between you and your AI coding assistant as a lightweight planning layer.

The idea is simple. Before your AI writes a single line of code, you and the AI agree on a spec. What you are building, why you are building it, how you are going to build it, and what is out of scope. Everything is written down and locked in before implementation starts.

It works with the tools you already use ~ Claude Code, Cursor, Codex, Copilot, Antigravity and more. No API keys, no complex setup. Your specs live right inside your repository as markdown files.

Every change you make in OpenSpec goes through four artifacts:

Proposal ~ the why. What you want to build and why it matters
Specs ~ the what. The requirements and expected behavior
Design ~ the how. The technical approach and decisions
Tasks ~ the steps. Broken down implementation plan

Installation and Setup

Prerequisites

Node.js 20.19.0 or higher

Install

npm install -g @fission-ai/openspec@latest

Initialize

cd <your-project>
openspec init

Once initialized, it will ask you to select which AI tools you want to set up. OpenSpec supports 28 tools including Claude Code, Cursor, Codex, Copilot and more. Use Space to toggle and Enter to confirm.

After selecting your tools, OpenSpec sets everything up automatically ~ agent skills, slash commands, and config files for each tool you selected.

Once setup is complete, restart your IDE for the slash commands to take effect. Then you are ready to start your first change with /opsx:propose <what-you-want-to-build>

The Four Artifacts

Every change in OpenSpec progresses through four artifacts.

Each artifact builds on the previous one, ensuring implementation starts only after the change is fully understood.

1. Proposal

The Why

The proposal captures the intent behind the change.

Questions answered here:

Why are we doing this?
What problem are we solving?
What value does this provide?

This is where intent gets locked in.

2. Specs

The What

Specs define the requirements and expected behavior.

Questions answered here:

What should happen?
What should the system do?
How should it behave?

These become the source of truth during implementation.

3. Design

The How

Design documents describe the technical approach.

Questions answered here:

Which architecture should we use?
What tradeoffs are involved?
What technical decisions need to be made?

This phase often prevents expensive mistakes before they reach production.

4. Tasks

The Steps

Tasks break the implementation into manageable pieces.

Questions answered here:

What needs to be done?
In what order?
How do we know we're finished?

This becomes the execution plan for both humans and AI agents.

Your First Change

Let's walk through a real example. We are going to add a new User Profile API endpoint using OpenSpec from start to finish.

Step 1: Start the Change

Run the propose command in your AI coding assistant:

/opsx:propose "add-user-profile-api-endpoint"

Your AI will generate all four artifact files automatically:

Created openspec/changes/add-user-profile-api-endpoint/
✓ proposal.md — why we're doing this, what's changing
✓ specs/       — requirements and scenarios
✓ design.md    — technical approach
✓ tasks.md     — implementation checklist
Ready for implementation!

Here is what each artifact looks like:

proposal.md

# Proposal: Add User Profile API Endpoint

## Intent
Users need a way to retrieve and update their profile information
through a dedicated API endpoint.

## Scope
- GET /api/users/:id endpoint
- PUT /api/users/:id endpoint
- Input validation and error handling

## Approach
Use existing REST conventions with JWT authentication middleware.

specs/api/spec.md

# Delta for API

## ADDED Requirements

### Requirement: User Profile Retrieval
The system MUST expose a GET endpoint to retrieve user profile data.

#### Scenario: Fetch profile
- GIVEN an authenticated user
- WHEN GET /api/users/:id is called
- THEN the user profile is returned

design.md

# Design: Add User Profile API Endpoint

## Approach
- Use Express router for route handling
- JWT middleware for authentication
- Joi for input validation
- Return 404 if user not found

tasks.md

# Tasks

## 1. Route Setup
- [ ] 1.1 Create user profile route file
- [ ] 1.2 Register route in main router

## 2. Handlers
- [ ] 2.1 Implement GET /api/users/:id handler
- [ ] 2.2 Implement PUT /api/users/:id handler

## 3. Validation and Error Handling
- [ ] 3.1 Add input validation
- [ ] 3.2 Add error handling middleware

Step 2: Implement

Once you are happy with all the artifacts, run:

/opsx:apply

Your AI now works through the tasks one by one following the spec exactly:

Working through tasks...
✓ 1.1 Created user profile route file
✓ 1.2 Registered route in main router
✓ 2.1 Implemented GET /api/users/:id handler
✓ 2.2 Implemented PUT /api/users/:id handler
✓ 3.1 Added input validation
✓ 3.2 Added error handling middleware
All tasks complete!

No guessing, no assumptions, no scope creep. Your AI follows the spec and nothing else.

Step 3: Archive

Once everything is verified, run:

/opsx:archive

This closes the change completely. It merges your delta specs into the main specs folder and moves the change to the archive permanently.

Archiving add-user-profile-api-endpoint...
✓ Merged specs into openspec/specs/api/spec.md
✓ Moved to openspec/changes/archive/2025-01-24-add-user-profile-api-endpoint/
Done! Ready for the next feature.

The reasoning behind every decision is now preserved in your repository forever. Next time anyone touches this code ~ including an AI agent ~ the why is already there.

Tips from Real Usage

After using OpenSpec for a few months in fast paced AI driven development, here are a few things I have learned.

Always review the proposal before moving on
The proposal is where intent gets locked in. If something is off there, it carries through to every other artifact. Spend an extra minute here and save yourself a lot of back and forth later.

Be specific with your scope
The more specific you are about what is out of scope, the better your AI performs. Writing "out of scope: custom error pages" is more useful than leaving it vague. AI agents take boundaries seriously when they are written down.

Do not skip the design artifact
It is tempting to jump straight to implementation. But the design phase is where you catch bad technical decisions before they become bad code. Many times the design phase alone has saved me from going down the wrong path.

Use it on existing codebases
OpenSpec is brownfield first. You do not need a fresh project to get value from it. Drop it into an existing codebase and start using it for your next change. The value shows up immediately.

Your specs are living documentation
Every time you archive a change, your specs folder gets more complete. Over time it becomes a genuine source of truth for how your system works and why decisions were made. That is valuable for your whole team, not just for AI agents.

Conclusion

AI coding assistants are powerful. But power without direction is just noise.

OpenSpec is not about slowing down. It is about making sure that when you move fast, you are moving in the right direction. In vibe coding and fast paced AI driven development, the biggest risk is not writing bad code. It is building the wrong thing confidently.

After using OpenSpec for a few months, the biggest shift I noticed was not in the code quality. It was in how much context was being preserved. The why behind decisions no longer lives in chat history or someone's head. It lives in the repository, right next to the code it describes.

If you are doing any kind of AI assisted development and you are not using a spec driven approach, give OpenSpec a try. It takes five minutes to set up and the value shows up on your very first change.

Start with:

/opsx:propose "your-first-change"

And see what happens.

Google Just Made AI Memory Official at Cloud NEXT '26 - And It Made Me Uncomfortable :(

Syed Ibrahim — Sun, 26 Apr 2026 11:39:11 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

I'll be honest. I didn't sit through the full Google Cloud NEXT '26 keynotes. I caught the highlights in between work. That's my level of "following the news."

But one announcement stopped me: Agent Memory Bank, now generally available inside the Gemini Enterprise Agent Platform.

Here's what it does in plain English: your AI agent can now remember things across conversations. Not just inside one session, but across sessions. It dynamically builds memory from past interactions, stores it, and pulls it back when relevant. Using Memory Profiles, agents can recall high-accuracy details with low latency so they don't lose context. (Google Cloud)

Sounds great on paper. But it made me think about something that happened to me recently.

I Already Experienced AI Memory. Without Asking for It.

A few weeks ago I was trying to fix a Decoder init failure on specific Snapdragon/MediaTek chipset phones. It was showing up in Sentry on our Android player SDK, ExoPlayer related. So I was using an AI tool to work through it, asking questions, going back and forth.

At some point I closed that chat and started a completely new one. Different day, different question. But somewhere in that new conversation the AI referenced something specific from the ExoPlayer session. Something I hadn't brought up at all.

So I asked: "are you reading my previous chats?"

It said no.

I gave it the exact context it had referenced. Still denied it.

That's the part that didn't sit right with me. Not that it remembered. That it remembered and then said it didn't. If a system can recall something it claims it cannot access, and then confidently insists otherwise, that's not just a bug. That's a trust problem. Because now I'm sitting there wondering what else it knows that it's not telling me. And the easy fallback is always "AI can make mistakes" which okay, sure, but that line is doing a lot of heavy lifting. It quietly removes accountability. The system moves on. I'm left holding the confusion.

Now Google Is Making Memory an Official Feature

Agent Engine Sessions and Memory Bank, which give agents persistent context across interactions, are now generally available. (The Next Web)

In some ways that's actually more honest. At least now it's documented, intentional, and in an API you can actually inspect.

The idea makes sense for what I build. I work on Django-based AI SaaS. Right now every session resets. Users repeat themselves. Agents forget context. Google showed a demo where a customer moves from text chat to a phone call and the agent seamlessly remembers exactly where they left off. (Google Cloud) That kind of continuity is genuinely useful.

Think of it like a user_preferences table in Django, except Google manages the entire memory layer for you.

But My Trust Questions Remain

If unofficial memory already existed and got denied, what happens with the official version?

What exactly gets stored, and for how long?
Can my users actually delete their memory and trust it's gone?
How do I explain this to users in India who are already cautious about data privacy?
And most practically, where is the clean pip install Django walkthrough?

The codelab demo showed Memory Bank costing less than $5 (Google Codelabs), which is a good sign. But I need to see full production pricing before I build anything serious on top of it.

My Prediction

Persistent agent memory is the right direction. Google's pitch is a unified stack: chips designed for models, models grounded in your data, agents built with those models, all secured by the infrastructure. (Google Cloud) If that holds up, it could genuinely be the default for AI SaaS in 12 months.

But the trust layer has to come with the feature. Users need to know what's remembered, what's stored, and what "delete" actually means.

Google has a real chance to set that standard properly with Agent Memory Bank, especially because the unofficial version already exists and nobody is really talking about it clearly.

Make it transparent, Google. The feature is good. The trust needs to catch up.

DEV Community: Syed Ibrahim

A Case Study in Integrating the Zoom Native SDK into a Flutter Monorepo

1. The Starting Point

2. Why I Forked the Plugin Instead of Using It As-Is

3. Android Build Problems: AARs Are Not Normal Dependencies

AARs don't drop in like a normal file

The SDK raised the floor on the rest of the toolchain

The namespace change had downstream fallout

4. Then GitHub Rejected the Repository

5. The Real Problem: Two libsqlite3.so Files

The tempting, wrong fix

The actual fix

6. Separating Zoom from courses

7. Making Zoom Optional, Per Client

8. What the Final Package Actually Looked Like

Solutions That Didn't Work

9. What the Native Dependency Graph Taught Me

Principles Worth Keeping

Conclusion

Why Not Every AI Application Needs Vector Embeddings

The idea

What embeddings actually do

Retrieval vs reasoning

But don't long transcripts still need chunking?

The moment it clicked

What I thought I needed

What I actually built

What I actually built

The real reason I dropped embeddings

Embeddings are still great, when you actually need retrieval

A question worth stealing

Final thoughts

See it in action

OpenSpec: The Missing Layer Between You and Your AI Coding Assistant

What is OpenSpec?

Installation and Setup

Prerequisites

Install

Initialize

The Four Artifacts

1. Proposal

2. Specs

3. Design

4. Tasks

Your First Change

Step 1: Start the Change

Step 2: Implement

Step 3: Archive

Tips from Real Usage

Conclusion

Google Just Made AI Memory Official at Cloud NEXT '26 - And It Made Me Uncomfortable :(

I Already Experienced AI Memory. Without Asking for It.

Now Google Is Making Memory an Official Feature

But My Trust Questions Remain

My Prediction

5. The Real Problem: Two `libsqlite3.so` Files

6. Separating Zoom from `courses`