Data and ML engineering rarely happen one task at a time. While one pipeline is running, we investigate a failed job. While that is blocked, we review a dashboard, inspect data quality, update documentation, or prototype a model.
The new full-page Genie Code experience appears designed for exactly this reality. It provides a command center where threads can continue running in the background, notebooks and files open beside the active conversation as tabs, and previous work remains searchable. Each thread entry can show its latest activity and the number of assets and lines of code changed.
That raises a more interesting question than what the interface does. Can one engineer safely supervise ten useful Genie Code projects at once, and achieve more throughput without creating more rework? I have designed the following community experiment to find out. This post describes the method, not results that have already been measured.
The hypothesis
The full-page command centre could shift Genie Code from a coding assistant into a workspace for supervising parallel agentic work. My hypothesis is that running multiple well-scoped Genie Code threads will increase completed work per focused hour, provided every thread has clear boundaries, reusable context, and explicit review checkpoints.
The counter-hypothesis matters just as much. Beyond a certain concurrency level, additional threads will increase context switching, approval queues, duplicate work, and review effort faster than they increase useful output. So the goal is not to prove ten threads beat one. It is to find the practical concurrency limit and the controls needed to operate safely.
The ten-thread experiment
I would run the same ten projects in two modes. Sequential mode completes or pauses each project before starting the next. Concurrent mode launches all ten as separate Genie Code threads and supervises them through the full-page command center. Each run uses the same starting assets, prompts, permissions, and acceptance criteria.
Genie Code works across notebooks, SQL, Lakeflow Spark Declarative Pipelines, dashboards, jobs, models, serving endpoints, and Unity Catalog assets, which makes this a representative workload rather than a purely synthetic one.
What I would measure
Eight measures, each chosen because it can move in the wrong direction under concurrency.
Throughput. Count the projects that satisfy their acceptance criteria within a fixed two-hour window. A thread is not complete merely because Genie Code stops working. Its output must pass the predefined review.
Wall-clock completion time. Time from the first submitted prompt to each accepted output. Parallelism should reduce elapsed time for independent work, especially where threads spend time running code, querying data, or waiting for approval.
Human attention time. Only the time spent writing or refining prompts, reviewing proposed actions, inspecting assets, correcting output, resolving conflicts, and doing final validation. This separates agent execution from the engineer's actual supervisory effort.
Blocked time. How long each thread waits for tool approval, missing information, human clarification, compute completion, access, or another thread's output. The command center lets you switch away while a thread keeps working. The experiment tests whether that converts blocked time into useful work or just grows the review queue.
Rework rate. Prompts requiring correction, generated changes rejected, assets edited again after review, tests failing after an apparently completed task, and work duplicated between threads. The most important measure may not be how fast Genie Code generates output, but how much of it survives review.
Review latency. The interval between a thread becoming ready for review and the engineer reviewing it. If ten threads finish together, the engineer becomes the bottleneck, and concurrency without review capacity can increase total lead time.
Context recovery time. On returning to a thread, how long does it take to understand what it attempted, what it changed, what remains blocked, and what decision is required next? The action summary, changed-asset count, searchable history, and adjacent asset tabs should reduce this cost.
Safety interventions. Tool actions rejected, actions blocked by auto-approve, attempts to modify shared or production assets, permission failures, unexpected external calls, and destructive operations proposed. A productivity experiment that ignores preventing mistakes reaches the wrong conclusion.
The technical operating model
Ten vague prompts would not be a fair test. Parallel work needs an operating system.
Use one outcome per thread
Each thread should have one named outcome, explicit input assets, clear exclusions, acceptance tests, a stopping condition, and defined actions that require approval. That prevents two agents from unknowingly modifying the same asset or solving overlapping versions of the same problem. A useful opening prompt structure:
Outcome:
Produce [specific deliverable].
Inputs:
Use only [tables, notebooks, files, pipelines or endpoints].
Do not:
Do not modify production assets, permissions, secrets or shared tables.
Acceptance criteria:
1. ...
2. ...
3. ...
Review checkpoint:
Stop and ask for approval before [write, deploy, publish or destructive action].
Final response:
Summarize the result, assets changed, tests executed, unresolved risks and recommended next action.Put global standards in instructions
Workspace and user instructions are persistent and apply broadly across Genie Code interactions, which suits coding conventions, preferred libraries, response requirements, and workspace-wide operating rules. Workspace instructions generally take precedence over user instructions. For this experiment, workspace instructions could require every thread to avoid production writes unless explicitly approved, prefer governed Unity Catalog assets, add tests for changed logic, state assumptions, report every modified asset, separate completed work from recommendations, and stop when acceptance criteria are ambiguous. Instructions should stay concise and broadly applicable. They are limited to 20,000 characters and do not proactively retrieve external information merely because it is mentioned.
Put specialist workflows in skills
Skills should contain task-specific procedures rather than global behaviour. Potential workspace skills here include pipeline failure triage, SQL performance review, data quality investigation, dashboard acceptance checks, PII-safe data profiling, ML experiment evaluation, and deployment readiness review. Skills can package instructions, examples, reusable code, and executable scripts. They load when relevant or are invoked explicitly with an @ mention, while global instructions apply to every response. A skill should be narrow, example-driven, and version-controlled. Changes to a skill do not affect an already active thread, so updated skills should be tested in a new thread. That detail matters for a controlled experiment: all ten threads should start with the same skill versions.
Treat MCP as a capability boundary
MCP connectors can give Genie Code access to external documents, data, and operational tools without copying all that context into prompts. Supported options include native connectors, Unity Catalog functions, AI Search, Genie Agents, external MCP servers, and custom MCP servers hosted through Databricks Apps. I would not enable every connector globally. Each thread should receive only the tools it needs.
Workspace administrators determine which MCP servers are available, and users select from approved sources. Native connector authentication is per user, and OAuth tokens are not shared between users. The experiment should record whether MCP reduced manual context gathering and whether irrelevant tools increased tool-selection errors.
Select approval modes by risk, not convenience
Genie Code supports several approval behaviours: ask every time, allow a tool within the current thread, always allow, and auto-approve, where a classifier reviews proposed actions. Auto-approve can reduce approval overhead, but it is a productivity feature and does not enforce security. Databricks explicitly recommends keeping it off for production data, sensitive workspaces, and shared resources where an incorrect approval would have material consequences. I would use ask every time for production, shared, security-sensitive, or destructive work - allow bounded development actions in the current thread; and auto-approve only for isolated, reversible, non-production experiments. I would not always allow just to make the benchmark look faster. The scorecard should report both time saved and interventions avoided or required.
What would make the experiment credible?
A useful community result should publish more than a screenshot of ten active threads. I would report a side-by-side scorecard across both modes, with these rows: accepted projects completed, total elapsed time, human attention time, median blocked time, median review latency, rejected or corrected outputs, duplicate or conflicting changes, safety interventions, and context recovery time. Alongside it, I would publish the ten initial prompts, the acceptance criteria, the instruction files, the skill names and versions, the enabled MCP tools per thread, the approval modes, a sanitised thread-state timeline, examples of successful and unsuccessful handoffs, and the practical concurrency limit observed.
My expected finding
I do not expect ten to be the universally optimal number. The likely value of the full-page experience is not unlimited parallelism. It is making waiting work visible and resumable while preserving the context needed for review. The optimal pattern may be a small active portfolio: a few threads executing, a few waiting for external work, one or two ready for review, and no more review-ready threads than the engineer can safely validate. That would make the full-page command centre less like ten chat windows and more like a supervised work queue.
The real productivity question is, therefore, how many concurrent Genie Code threads one engineer can review safely before human attention, not agent execution, becomes the limiting resource. Full-page Genie Code is currently in Beta, and scheduled tasks are coming soon, so this is a good time for the community to test the operating model, identify bottlenecks, and share evidence rather than only feature impressions.
A few questions for the community
For those already using full-page Genie Code, what is your sustainable number of concurrent threads?
What becomes the bottleneck first: prompting, approvals, review, compute, context recovery, or conflicting changes?
What operating rule made the biggest difference in keeping parallel threads from stepping on each other?
For more interesting topics to discuss, feel free to connect with me on LinkedIn: linkedin.com/in/lingeshwarankanniappan.
Sources
What's new in Genie Code at Data and AI Summit 2026, Databricks blog: databricks.com/blog
Use Genie Code, Databricks documentation: docs.databricks.com
Customize Genie Code with custom instructions, Databricks documentation: docs.databricks.com
Extend Genie Code with agent skills, Databricks documentation: docs.databricks.com
Connect Genie Code to MCP servers, Databricks documentation: docs.databricks.com