Weekly Dev Call Updates — Building BrainDrive in Public

BrainDrive Development
,
21

August 31, 2026 Update

Dave W was out this week, so Dave J ran the call solo: a walkthrough of BrainDrive as it stands today, where Resume Builder landed after Friday’s review, and the sequence he is working through while Dave is away.

Key Highlights

  • Resume Builder is 90 to 95 percent there. The interface was rebuilt from a structured form to “just talk to it,” and Friday’s review left a short list of visual cleanups (fonts and similar) rather than functional gaps.
  • Every miss becomes a process fix. The form-vs-conversation detour was traced back to where the interview and docs failed to steer the AI, and the fix is an explicit “read the style guide before any UX decision” step in the build.
  • A second test app, Brief Builder, is being built alongside Resume Builder to prove the app infrastructure is reproducible and not a one-off. A third may follow.
  • Neon to self-hosted Postgres is finished and documented in the Library so the next infrastructure change can lean on it.
  • This week’s targets: Internet Search capability, app lifecycle (install, update, uninstall), then Job Discovery.

What We Covered

BrainDrive today, from the top: The walkthrough covered the parts owners control: model selection (BrainDrive Models, OpenRouter, or your own local model by IP), GitHub-backed backups with full version history, and migration between a local copy and a hosted one in either direction. The four default pages (Finance, Fitness, Career, Relationships) all run on the same pattern: an interview, a spec, and a build plan that hands you achievable steps instead of an impossible task. Projects extend that pattern to anything you want, from ESP32 hobby inventory to a small art business.

Resume Builder and the “just talk to it” lesson: Dave J built a very structured form; Dave W wanted a conversation. The redesign is done and the app now runs through the normal chat interface. The interesting part was the post-mortem: where in the interview or the Library did the direction get missed, and what needs to be hard-targeted in the docs so the AI reads the style rules before making UX choices. That is the compounding loop we keep talking about, applied to our own factory.

Less code, more markdown: Most of this week’s app work was on the data behind the apps, the interview flow and spec markdowns, rather than code. The goal is to lean on the model’s intelligence and keep the app layer thin, which is why Brief Builder exists as a second proof that the infrastructure generalizes.

How the factory works: The business side produces a product spec, user stories, and an evaluation plan. The tech side answers with a work spec, an implementation plan, and a test plan, with syntax checks and small tests at each milestone. Every decision and the conversation behind it is recorded, so when a fork comes up, the history usually already points the way.

App lifecycle and capabilities: Right now the app assistants live in their own environment inside BrainDrive so the foundation can be iterated quickly. The next step is making each app its own entity with its own repo and location, so install, update (a flashing button, one click), and uninstall are seamless. Internet Search will be the first capability, meaning nothing you use directly, but something apps and projects can draw on. SearXNG is the likely first provider, with other search capabilities open to anyone who wants to build one.

What’s Next

Get Internet Search working and tested on its own, then wire it into Job Discovery so a job search populates inside BrainDrive and you can say “tailor my resume for this one.” Application Preparation (resume plus cover letter against a specific listing) follows. Dave J does not expect to get past that point before Dave W is back Wednesday, but the remaining steps in this sequence are few, and after it the focus shifts to more apps and assistants. Foundation and capability contract docs get updated as each piece lands so any developer, human or AI, can build an app from them.

Watch the full recording:

22

September 7, 2026 Update

Labor Day call, both Daves on, and the first one where Dave W’s AI sat in live to run the agenda. Two hours, mostly decisions: freezing the first Resume Builder candidate for a formal evaluation run, clearing a backlog of documentation pull requests, and settling how the two of us test.

Key Highlights

  • Resume Builder is being frozen for its first formal evaluation run. The candidate branch is named, the last fix set is agreed, and Dave J calls the freeze tonight. Dave W’s evaluation starts on that exact revision.
  • Eight documentation PRs merged on the call, including the Model Evaluation spec v1.0, the Software Factory spec v1.1, and the Build Gate. The docs queue is empty for the first time in weeks.
  • How our testing lanes fit together is now written down. Dave J’s Build Gate proves a candidate is worth evaluating; Dave W’s evaluation plan proves the accepted stories at the UI. Neither re-grades the other.
  • Our AIs are getting their own forum accounts. Each of us will have an agent that reads and replies here on our behalf, so a PR review or a question does not wait for a human to notice it.

What We Covered

Freezing a candidate: A freeze pins the exact commit, spec version, evaluation kit, and judge that a formal run will grade, so the verdict is about one fixed thing and anyone can reproduce it. The last two weeks were a fix-then-retest loop with no fixed target. Today we drew the line: a short list of fixes goes in before the freeze, everything else moves to candidate two, and rows those later fixes affect are recorded as Blocked rather than holding the run. The overnight check that used to put a full day on the critical path becomes a confirming row with a provisional verdict the next morning.

The docs queue: Every spec, plan, and template we accept lives in a docs repo with an approval gate that needs both owners on governance changes. Seven PRs had been waiting on review, and one gate quirk kept blocking merges after approval. We worked through all of them live, including moving the Evaluation Protocol into its own folder and accepting the Model Evaluation spec, which now says a model is recommended for a role only after every app it would serve has passed its own evaluation kit with that model.

Two testing lanes, one artifact: Dave J asked twice last week how his build-side testing and Dave W’s evaluation-side testing should merge. The answer is they do not merge. They stay separate and meet at the Build Gate record, which is a required input to the freeze. Anything Dave J wants proven at the UI becomes an evaluation row; any code defect the evaluation finds goes back through his gate as a reproduction.

Desktop is its own thing: Install, update, and uninstall branch by operating system, so a Docker pass cannot stand in for the desktop builds. That becomes a build item when app lifecycle work resumes.

Agents on the forum: Each of us gets a bot account here. Each agent writes only to its owner’s workspace, can open documentation PRs but never merge them, and answers only its own owner’s mentions. They start in a private staff area until the loop guards are proven, then move to the public categories.

What’s Next

Dave J freezes tonight and runs the Build Gate on that revision; Dave W starts the formal Resume Builder run on it. Dave J’s Software Factory documentation lands in the docs repo this week, then the two-pipeline dev environment so bug fixes and new features stop sharing a branch.

Watch the full recording:

23

September 14, 2026 Update

This week’s call was mostly about the BrainDrive Software Factory: the formalized, AI-run process we’re using to build BrainDrive as a small team, with a walk through every stage of the line. Dave J also had a couple of product updates from last week.

Key Highlights

  • Code freezes are now in place, so Dave W, Dave J, and the AI all test the exact same build.
  • The Rust desktop app’s sidecars are coming to life: the workspace came up on Windows with apps loading from their own GitHub locations via the catalog. Windows wraps up first, then Mac.
  • The Software Factory is now running end to end as a working rough draft, and every stage is visible and fixable rather than conceptual.
  • Each run through the factory is getting tighter, and the same process is designed to eventually power “BrainDrive Code” for every owner.

What We Covered

Why a factory at all: Building a superior user-owned alternative to big tech AI means playing a different game. Instead of raising venture capital and hiring a huge team, we’re leveraging AI to keep the core team small and leaning on the open source community, which already exists at scale. The factory is how we make that work legible to AI so it can partner with us at every step.

Freezes and the desktop app: Freezes let us lock a candidate so everyone tests the same thing, with no mystery midnight updates. On the desktop side, apps are moving out of the monolithic install and into a catalog-driven model where BrainDrive discovers and pulls in apps from wherever they live. This is a step toward an open app marketplace where apps like Resume Builder can run in BrainDrive or any system that speaks the same open protocols.

The stages of the Software Factory: Dave W walked through the full line. Select decides what enters the factory via a prioritization workflow and produces a sequencing doc. Specify and Spec use an interview process to define what success looks like as user stories. Evaluation Plan defines how the AI and the team will know the user stories are met, including judge kits for things like interview quality. Ground and Plan gives the AI the project profile, build context, build plan, and running learnings. Build breaks the plan into bounded work specs that are each built and verified before moving on. A standard Build Gate runs before hand-off. Evaluate and Remediate runs the full acceptance criteria against a frozen candidate, preceded by a quick smoke test to catch obvious breakage. Then Qualify and Package seals the evidence, Release ships it, Capture and Learn feeds lessons back into the factory, and Dispose clears the finished work.

Why it matters to developers: Every decision, its reasoning, and its sources are now on record, so when something goes wrong we can trace it back to the context we gave the AI and fix the docs. Keeping context windows tight limits hallucinations, and it lets us use frontier models for planning while cheaper, faster models handle the coding, which stretches the token budget much further.

What’s Next

Finish the Windows desktop cleanup and port to Mac, then freeze builds for both desktop versions. Keep running work through the factory, dialing in each stage for speed and evidence of the dividends it’s returning. Longer term, this foundation is what BrainDrive Code will be built on, letting any owner describe what they want in plain language and have their BrainDrive build it.

Watch the full recording:

24

September 21, 2026 Update

This week we shared progress on the systems behind BrainDrive: the shared knowledge library that keeps our work aligned, the evaluation process for getting apps ready to ship, and the Personal AI Architecture principles that keep people in control as BrainDrive expands into applications.

Key Highlights

  • We continued building the shared BrainDrive Library and the separate owner libraries that give our AI partners reliable company, operational, and technical context.
  • Resume Builder remains our proving ground for an AI-assisted evaluation process that can verify both whether an app works and whether the experience matches what we intended.
  • BrainDrive’s managed model moved from GLM 5.2 to OpenAI’s GPT Luna 5.6 after our testing found a strong combination of instruction following, performance, and price.
  • Desktop evaluation work is extending the same process across Windows and macOS so apps can move through a repeatable path from build to verification to installation.
  • We began updating the Personal AI Architecture for applications, with digital property rights, memory ownership, portability, and open competition at the center.

What We Covered

A shared operating memory: We are continuing to strengthen the BrainDrive Library as the source of truth for the company while building separate owner libraries for our different areas of responsibility. The goal is practical continuity: an AI partner should be able to understand how the system works, where operational records live, how infrastructure is maintained, and what has already been decided without rebuilding that context every time.

Evaluation as part of the factory: Resume Builder is already coded and working. The current work is about creating a dependable process for determining whether it works the way we intended. We discussed the familiar split between planning, building, and testing, and how AI can compress each part when the process has clear checkpoints and evidence. That includes evaluating function and experience, then carrying the same approach into desktop apps across multiple operating systems.

What model testing is teaching us: Our real-world tests led us to move BrainDrive’s managed model to GPT Luna 5.6. We also started testing Qwen’s 27B model as a local option. Its instruction following looks promising, although its longer reasoning can add latency and token cost. This is why BrainDrive stays model-flexible: the best choice depends on the job, the hardware, and whether someone values local privacy, speed, price, or maximum capability most.

Property rights for AI applications: As BrainDrive begins supporting more apps, the Personal AI Architecture needs to preserve the same ownership guarantees that apply to memory and conversation history. A person’s workflows and accumulated context should not disappear because a platform changes direction. Open source keeps the software available, while portable memory and open interfaces let the value created by an AI system continue accruing to its owner. The longer-term goal is an open marketplace where network effects improve the ecosystem for individuals, builders, and infrastructure providers without creating platform lock-in.

What’s Next

Our immediate goal is to reach a Resume Builder freeze that two human owners and the AI evaluation process all agree is complete. In parallel, we are moving the desktop flow toward verified app installation and making sure the documentation and architecture are ready for the next phase of BrainDrive app development.

Watch the full recording:

25

September 28, 2026 Update

This week was all Software Factory. Dave J walked through the cleanup work on the factory’s process documents, how close Resume Builder is to a full test run, and how Resume Builder will plug into systems other than BrainDrive.

Key Highlights

  • Nearly the whole week went to the Software Factory, our AI-run process for planning, building, and testing BrainDrive apps.
  • We’re finishing version 1.4 of the factory’s process documents: consistent terminology and clear contracts, so every AI on the team works from the same information.
  • Once 1.4 is locked, the next Resume Builder build goes through a pre-freeze check and then a full test across all of our user personas.
  • Resume Builder is already running as a desktop app outside our test environment. Next we publish the “handshake” that lets other systems call it over MCP.
  • A working factory is how a two-person team scales development without raising a lot of outside capital and getting pushed toward user lock-in.

What We Covered

Getting the factory’s context right: With two people working alongside about five AI teammates, every AI needs the right information in the right place at the right time. That includes keeping contexts separate, so the AI that plans and builds an app can’t see the tests it will be graded on. Much of last week went to making the factory consistent end to end. Terminology matters more than it sounds: if one document says “smoke test” and another says “spot test,” an AI may decide there are two different tests. Since we work from call transcripts, getting our own language consistent is part of the job.

Why Resume Builder takes weeks: Coding Resume Builder could have taken a day. The real goal is to use it as our first app built and tested by the factory, and our first app that can run outside BrainDrive. Once it ships, a lot follows: a working factory, faster app launches, other builders able to use the same factory, and proof that apps can follow the Personal AI Architecture without adding lock-in. Many teams use AI to ship faster and then pile up bugs. We’re putting the same effort into AI-driven testing so the product that ships is better.

Using Resume Builder outside BrainDrive: Each app will publish two handshakes. The basic Personal AI Architecture (PAA) handshake says what the app is and how to talk to it. The fuller handshake tells the host where its memory and user data live. Because it runs over MCP, the protocol side is already handled. Resume Builder doesn’t keep any data; it takes your information in, does its work, and hands everything back. So any host system with a chat interface, a form, or even a terminal can use it as the engine.

What’s Next

Lock version 1.4 of the factory documents, run the pre-freeze check on the next Resume Builder build, and move into a full persona test. Dave J hopes to turn to apps by the end of the week.

Watch the full recording:

26

October 5, 2026 Update

This week Dave J explained the evaluation pillar of the Software Factory, what he got working over the weekend, and why AI has to run the whole plan, build, and test loop for a small team to see the full benefit.

Key Highlights

  • The factory has three pillars: plan, build, and test. Planning and building are working well, and the past week and a half went almost entirely to testing (evaluation).
  • Over the weekend, Dave J got three pieces in place: the evaluation framework, a test router that runs on it, and handling for real-world problems like rate limits, slow responses, and models dropping out.
  • A complete Resume Builder test run was going on during the call. It should end in a bug report that feeds straight back into the build process.
  • Earlier, sending bug reports straight back into the build loop turned a week of failed fixes into a four-hour AI run that finished.
  • People belong at two points in the loop: at the start, defining what we want, and at the end, confirming the result hits the target.

What We Covered

Building a QA team out of AI: Large software companies have dedicated quality assurance (QA) teams that get handed documents and test against them. We’re putting AI at the front of that job: turning user stories into tests that AI can run, checking the quality of chat responses, and keeping a map of which tests to re-run when a part of the app changes. Dave J has looked for anyone else writing about building a QA team with AI and hasn’t found anyone. One lesson so far: hand an AI too many tests at once and it starts picking a few and cutting corners. So we break the work into smaller pieces.

Why the whole loop matters: If AI speeds up planning but not building, work piles up at the build stage. If it speeds up building but not testing, the QA side gets swamped. The benefit only adds up when AI handles all three steps. For an open-source project running on limited capital, this is how we avoid the usual pattern of raising money, handing control to shareholders, and drifting toward extracting value from users.

When the AI says it’s done and it isn’t: Our ongoing problem has been AI reporting work as finished when it isn’t. The fix that’s held up: break the work into small chunks, each with a roadmap ID and its own check. A separate verifier, working in a different context from the builder, confirms each step before the next one starts. That’s how the framework itself got built, and we’re now applying the same approach to evaluation.

What’s Next

Finish the current Resume Builder test run and act on its bug report. Then finish adding and checking the rest of our tests. The goal is to reach the point where we’re testing Resume Builder, not using Resume Builder to test the factory.

Watch the full recording:

27

October 12, 2026 Update

This week Dave J explained why we stopped and reset the testing side of the Software Factory on Friday, the single spec that came out of the weekend, and how we’ll know by tomorrow whether we can reuse what we’ve already built.

Key Highlights

  • Our fix for AI cheating on tests worked, then went too far. The rules meant to keep the AI honest started keeping the two of us apart as well, and the system it was growing into would never have run.
  • On Friday we stopped, agreed a plain set of rules for how testing should work, and set one goal: reuse the two pieces that already work, the evaluation engine and our 29 tests.
  • Dave J first tried to split the remaining work across two specs. They didn’t line up at the end, so he wrote one spec that covers the whole problem.
  • Before building anything, he had a second AI model pretend the spec was already built and report what would go wrong. That turned up problems an ordinary review had missed.
  • We should have something to run within a day or two. If it can’t complete a simple test run by then, we stop reusing and rebuild.

What We Covered

When anti-cheating rules go too far: We want a full quality assurance (QA) team made of AI, so that every change is tested against the whole app and not only the part we touched. To stop the AI from marking its own work as passing, we used two models with strict instructions. Those instructions spread through our documents until the system was treating the two of us as if we shouldn’t talk to each other either: each of us doing our part in a vacuum. Part of this week is finding where our documents say that and taking it out.

One spec instead of two: The evaluation engine works and the tests are proven, so the missing piece is what sits between them and manages the whole run. Splitting that into two specs meant the halves didn’t always meet. One spec, with reuse as its main goal and Friday’s rules as its limits, did. The test Dave W set for it: someone who has never seen the Software Factory, person or AI, should be able to read it and run it without a fifteen-minute explanation.

Different tests, different rules: On Friday we also sorted our testing into types. Cheap, low-risk tests are ones the AI can run whenever it wants, with no permission needed. Others need specific data or a cap on what they can spend. The strict part, locking the code and sealing the test data, happens only at the final “freeze” run, where we need a result we can stand behind.

Reuse or rebuild: Dave W pushed on this. In the past, trying to save existing work has usually ended with starting over anyway, and code is cheap to write now. Dave J’s answer: a lot of effort went into those tests, so it’s worth one day to try. If a simple run doesn’t work by tomorrow, we start a new spec.

What’s Next

Build from the new spec and get a first spot-check run all the way through. Then fold the testing spec into the main Software Factory spec, so one document covers planning, building and testing.

Watch the full recording:

28

October 19, 2026 Update

This week Dave J walked through where the Software Factory stands: what works today, what’s left, and the proof of concept that answers the “weeks or months?” question we left open on Friday.

Key Highlights

  • The full loop now works end to end on a real feature. Dave J handed the factory one spec for BrainDrive’s login, and it planned, built, tested and reported on its own, with people stepping in only where we’ve chosen to.
  • On that first run it found a real BrainDrive bug we didn’t know about. It then took its own bug report, fixed the code and re-ran the tests to prove the fix.
  • Results now come from evidence, not the AI’s say-so. Every test ends as pass, fail or “unable to test”, and the evidence is saved so a whole run can be replayed later to see exactly what the AI did.
  • Writing tests used to be the slow part. Now Dave J reviews the user stories, asks the AI to create the tests, and they’re done “before I got back with coffee.”
  • What’s left is mostly making our specs consistent, so the factory always gets the right information up front.

What We Covered

Plan, build, test, learn: That’s the Software Factory in one line. Coding agents can already build what you describe. Testing is where everyone gets stuck, and it’s the piece a two-person team needs if we want the leverage of a whole development floor, quality checks included.

How the build side stays honest: After the AI builds, a separate check asks “are you really done, or did you just hand me a note saying you’re done?” before anything moves on. The build process is all Markdown instructions with no custom code, so it gets better as new models come out instead of needing a rewrite. Fast, inexpensive coding models are good enough for this stage now.

Five levels of testing: Quick spot checks, AI quality checks and single-user diagnostic runs are cheap enough that any developer can run them as often as they like. A pre-freeze run tests everything we already have with one persona. The final freeze run locks the code and sends five personas and three different AI models after edge cases. We kept the login bug as a standing “sniff test”: if a run doesn’t find it, the run didn’t work.

Specs are next: The specs we used combined Dave W’s product view with Dave J’s technical view in one document. The tests stay separate, so the AI that builds never sees the tests and the AI that tests never sees how it was built.

Back to the foundations: Now that the factory works, we’ll bring the specs for everything already built up to date and run each one through it. There’s content to write about this too. It goes beyond “vibe coding” into what people are starting to call agentic coding: you describe the work, and the AI comes back with tests that prove it works.

What’s Next

This week we write and refine specs and run them through the factory, tuning the factory and its tests as we go. Dave J is also moving our development work off the Resume Builder branches onto a clean base, so we can test core BrainDrive and start doing releases.

Watch the full recording:

29

November 2, 2026 Update

This week Dave J showed the Software Factory running on our real specs: AI now turns a spec into tests, runs them and hands back a report without him touching anything. We also agreed what gets done this week.

Key Highlights

  • We planned to start loading BrainDrive’s specs into the factory today. Dave J started on Friday and has already finished the first three.
  • BrainDrive has roughly 700 acceptance criteria, the specific checks that say a feature works. Dave J estimates about 20-25% are through so far.
  • We saw a full run on screen. The factory found a login bug, sent its own bug report to the builder, got a fix and re-tested until it passed.
  • The goal this week: an automated test for every acceptance criterion we can, so we know exactly where the gaps are.

What We Covered

Why testing is the hard part: Most AI software tools focus on building, and any good model can build now. What matters is whether you planned well and whether the AI can prove it built what you asked for. A few weeks ago the AI wasn’t reporting its progress accurately. So we gave it a running record of where it is, and tied each user story and acceptance criterion in a spec to an actual test.

Reports a person can act on: We’ll never fully remove people from this, because sometimes the problem is that we didn’t define what we wanted clearly enough. So when the AI says something is broken, the report has to carry the evidence, and Dave J can decide in minutes instead of spending half a day digging. Every test ends as pass, fail or blocked. Pass and fail are about the product. Blocked means the test itself couldn’t run, and that’s what we’re stamping out right now.

Report only, or report and repair: Dave J picks a spec and a lane, and each lane works like one employee. Report only tells him what’s right and what’s wrong. Report and repair also fixes what’s wrong and tests again. There’s one lane running today, and we’ll open more once a Docker setup issue is fixed.

Three kinds of test: Code checks are slow to do by hand, and so is judging whether the AI is any good, like whether the career page acts like a real career coach. Those are the two we want automated first. Checking the user experience is quick for people: we can run BrainDrive on Mac, Windows and Linux and catch most problems ourselves. It’s also where AI struggles most. Those tests still go into the factory, but they can’t be allowed to hold up a run.

Why we’re using specs we already have: It proves the factory on work we understand. It also gives us regression checks, so a small fix in one place can’t quietly break something somewhere else. A new feature will inherit what it depends on, so a new finance feature would also test login, chat and journaling.

What’s Next

Dave J keeps working through the remaining 10 or so specs, aiming to have most of the tests in by the end of the week. He’ll also check how well the AI judging works, and fix the Docker setup so more lanes can open. Next week we start fixing what the factory finds. After that comes the big test: handing it a brand-new spec and watching it do every step in one go.

Watch the full recording: