Cross-Trained Practitioners

Query Find people who work across two or more professional domains and have written or spoken publicly about how AI works differently in each domain they practice in. Examples: lawyers who code, doctors who build software, teachers who do data analysis, engineers who write professionally, scientists who do craft work, tradespeople who also program. The key signal is someone articulating the mechanism — not just "AI is better at code than writing" but WHY, grounded in their lived experience of what each domain provides. Look for accounts where someone says something like "in domain A, I can verify AI output easily because of X, but in domain B, I can't because Y" — or where they describe bringing habits, tools, or verification patterns from one domain into another. Also look for people who have explicitly built tools or workflows that transplant verification patterns across domains (e.g., a developer who built a citation-checking tool for legal work; a scientist who brought experimental methodology into evaluating AI writing). Search in: practitioner blog posts, conference talks, podcast interviews, Twitter/X threads, Reddit, Hacker News comments, LinkedIn posts, YouTube. Prioritize first-person accounts where the person explicitly names both domains and reflects on the difference. Be aware that some accounts may involve posturing ("of course I knew AI would be bad at X") — look for accounts that describe specific mechanisms or specific workflow adaptations, not just general claims of unsurprisedness. --- Full Report Cross-trained practitioners comparing how AI behaves across their domains Research scope and selection criteria This review focuses on cross-trained practitioners—people who either (a) actively work in two or more professional domains, or (b) have a “dual identity” that is clearly reflected in their public practice (e.g., clinician–developer, lawyer–developer, tech writer–engineer). The target signal is mechanistic explanation grounded in lived workflow, especially statements of the form: • “In domain A, AI output is cheap to verify because X; in domain B, it isn’t because Y.” • “I transplanted verification patterns from domain A into domain B by introducing tool/process Z.” Sources were selected from practitioner-first channels: personal blogs, conference/podcast transcripts, and social posts where the author self-identifies their cross-domain background and describes concrete verification habits or workflow redesigns. Mechanistic frame that keeps recurring Across the strongest accounts, “AI works differently” is rarely reduced to “AI is stronger at X than Y.” Instead, it’s explained through three interacting mechanisms: verifiability, feedback-loop speed, and consequence structure. A clear articulation comes from in a podcast interview: he argues that hallucinations in code are less damaging because software has built-in mechanisms to expose errors (compiler errors, failing tests, observable runtime behavior), whereas other domains often lack a fast, cheap, airtight verification loop. In his phrasing, code has something close to “fact-checking built in,” while “legal briefs” do not. That same podcast segment makes the cross-domain comparison explicit: running the code (or seeing it fail) is a form of verification that simply doesn’t exist in many document-centric knowledge jobs. A closely related rule shows up in a clinical context (veterinary medicine) as a distilled heuristic: use AI where “doing the work yourself is time consuming, but verifying is easy.” This “verification rule” is presented as a safety-oriented boundary for clinical usage, and it generalizes cleanly across domains. Finally, multiple practitioners emphasize the difference between probabilistic generation and deterministic execution: if you need a guaranteed transformation (same input → same output), you should push work into scripts, tests, or databases rather than leaving it inside an LLM’s generative step. Medicine and software ###, clinician–developer: feedback loops and “testability” are fundamentally different On, Onyeije repeatedly compares clinical workflows to software-building workflows and highlights a key mechanical divergence: medicine often requires time-delayed, noisy confirmation (labs, imaging, follow-up), while software can provide near-immediate confirmation by running or testing. He frames “software development” as pattern recognition under uncertainty—similar to clinical medicine—but adds that the cadence differs because in software “you can test your hypothesis in 30 seconds instead of waiting for morning labs.” That time-to-verification difference becomes a practical argument for why certain AI-assisted development styles (“vibe coding”) can be unusually empowering for clinicians: if a clinician can translate their domain intent into a prototype and then quickly test and iterate, they can compress a kind of “build–measure–learn” loop that is otherwise slow in clinical operations. He also contrasts medical culture’s expectation of stability with the “move fast” cadence of AI software ecosystems. In his view, experienced clinicians have deep pattern recognition about what breaks in real practice, but often expect tools that evolve slowly; in contrast, trainees may be comfortable with rapid iteration but lack scar-tissue about which shortcuts can become safety hazards. In a separate post, he reframes clinical LLM use as a division of labor: he argues LLMs excel at imposing structure on complexity (synthesis, prioritization, contextualization, documentation), while clinicians retain judgment. He explicitly ties legitimacy to review and verification, describing AI as a “sophisticated tool that requires verification,” analogous to other clinical instruments. Workflow transplant pattern: converting clinical intent into buildable artifacts A key “transplant” move in Onyeije’s writing is the idea that clinicians can treat software like a clinical toolchain: you “prescribe” existing abstractions rather than building from scratch, and you use AI to eliminate syntax friction while keeping domain intent in the driver’s seat. He describes building a consultation-note generator using familiar developer infrastructure components (e.g., databases and deployment layers) and using LLMs to scaffold code from plain-English specifications. This is less about “AI writes better” and more about restructuring the workflow so that verification happens at the right layer: clinician reviews outputs; deterministic components handle repeatable steps; rapid iteration exposes errors early. Law and software ###: foundations and “maturity” differ between software and legal practice In a comment thread sparked by a lawyer urging peers to “talk to a software developer” to understand the near future, Bridges self-identifies as “a lawyer, long time developer and building in legal AI,” and argues legal work is unlikely to reach the same near-term “vibe” state as software engineering because legal work lacks comparable “foundations.” This is notable because it’s not merely a capability claim; it’s a systems claim: the practice environment, institutional tooling, and verification norms in software are more conducive to rapid agentic acceleration than in law. ###: regulation changes the verification loop and the pace of substitution Barrett explicitly compares three domains he has worked across: software development, legal, and healthcare. He argues that legal and healthcare are more similar to each other than to general software development because they require long-accumulated professional knowledge and experience. He also foregrounds regulation/compliance as a key differentiator: basic software skills can be learned quickly and are loosely regulated, while legal work is tightly governed, which slows down how quickly AI-driven change can fully propagate. This is an example of a cross-domain mechanism that is neither “model capability” nor “prompting technique,” but the institutional verification envelope: who is accountable, what standards must be met, and how errors are detected and sanctioned. ###: “make it so you can open the case and verify it” A particularly crisp, mechanism-centered account appears in a podcast transcript on. Von Zastrow describes coming “from a software and robotics background,” then demonstrates a legal research workflow where the AI layer is integrated with a real case-law database. The key point is verification: returned results include links and citations, and “you can click to open the case,” making it “not ever going to be an AI generated case… because you can open it and verify it.” This is exactly the transplant the user prompt asks for: move legal AI from “plausible synthesis” to “auditable retrieval + synthesis,” where the human can perform fast spot-checks against primary sources. He further describes agentic behavior as repeated searching and follow-ups—closer to a litigator’s multi-step research process than a single-shot answer. ###: cross-domain identity built around process synthesis The same site describes Lambert’s own cross-domain identity—“Librarian-Lawyer-Knowledge Management-Competitive Analysis-Computer Programmer”—and frames his working style as connecting “unrelated items” into a process that yields better information than any individual input alone. This is a practitioner-intent description of the exact habit that often underlies verification-pattern transfer: treating workflows as composable systems rather than as isolated craft acts. Workflow transplant pattern: legal citation checking as “unit tests for briefs” A concrete example of verification-pattern transplant in law is the emergence of lightweight citation-checking tools that treat citations as machine-verifiable claims. In a post promoting an app called “Euni™ - Citation Checker,” describes building a tool that lets attorneys “instantly verify citations—whether individually or in bulk,” with each result including a link so attorneys can double-check sources. He notes it is powered by the ’s API, and cites its scale as “9M+ cases across 2,000+ U.S. courts.” A complementary comment by emphasizes an important second-order verification issue: even if a citation exists (API says valid), you still must confirm it stands for the proposition being asserted. In other words, the tool can “unit test” existence/lookup, but semantic fit remains a higher-level verification step. This “two-layer verification” (existence check → meaning check) is a recurring cross-domain theme: AI makes it easy to produce plausible structure, so practitioners invest in mechanized checks for the easiest-to-mechanize failure modes first. Engineering and writing ###: turning documentation into testable statements Silva is explicitly introduced in podcast and show materials as “a tech writer by day and engineer by night,” and as Head of Docs at, author of “Docs as Tests,” and creator of “Doc Detective.” The mechanism he focuses on is the verification gap in documentation: documentation often encodes procedures that drift over time, and LLMs can accelerate drafting but can also accelerate the spread of incorrect steps. His answer is to transplant software QA norms: treat docs as testable claims about product behavior, and run tests continuously (on PRs and on schedules). The podcast summary describes his workflow as running full doc test suites on every PR and on scheduled daily runs, covering UI procedures, CLI commands, API calls, screenshots, and more. Crucially, the same summary highlights Silva’s distinction between deterministic tests (repeatable, stable signal) and probabilistic tools that can help bootstrap but “can’t be trusted on their own.” This is an explicit “why”: AI output is unstable, so you need stable gates. Silva’s broader point—again aligning with the user’s requested signal—is that the professional role becomes curation + verification: technical communicators hold standards and decide what can ship, rather than merely producing text. at: separating probabilistic “orchestration” from deterministic execution In “Treating Prompts Like Code,” Soper describes being a Senior Technical Content Engineer in a context where many contributors lack familiarity with doc tooling (build systems, style constraints, nav structure). His key workflow adaptation is to treat LLMs as orchestrators over a deterministic substrate: if a transformation is already well-specified, make it a script. He summarizes this as: “Claude orchestrates; the script executes,” calling it a “cleaner, more reliable division of labor” than asking an LLM to reinvent the wheel for each run. He generalizes further: if you need deterministic output, “don’t use probabilistic tools.” This is another explicit “why” grounded in engineering constraints rather than model mystique. ###: “prompt ownership” is too narrow—own the system A LinkedIn post by Ferri-Benedetti argues that technical writers should “design and maintain the prompts” that generate docs—and more broadly should lead end-to-end docs automation. The most mechanism-relevant detail appears in comments: pushes back that “own the prompt” is too narrow, warning that writers might fixate on prompt engineering when sometimes “traditional” imperative automation is better. This is an explicit argument about tool choice grounded in reliability and fit: prompts are not a universal substrate for verification-stable automation. ###: importing software “best practices” into AI agent use Crawford’s “As we may vibe” is a first-person account of a former software engineer/product manager who became a writer and nonprofit leader and then returned to building software via coding agents. He describes a key failure mode: agents behave like “junior engineers” and may skip basic professional practices such as writing automated tests. His response is explicitly cross-domain: he “leveled up” agents with “best practices from the software world,” including regression tests, test-driven development, branch-based changes, and test environments. He also describes adopting “skills” documents (small, reusable procedure documents) as an alternative to a single monolithic process document—directly crediting this pattern to Simon Willison’s “skills.” via Willison: the verification-cost principle stated plainly Willison republishes a Narayanan principle that concisely links the mechanism across domains: AI is helpful—even when error-prone—when “it is faster to verify the output than it is to do the work yourself.” This principle shows up again and again in practitioner discourse because it is a workflow claim, not a benchmark claim. It predicts where cross-trained practitioners will succeed with AI: domains with cheap verification pathways and high reuse of stable constraints. Tool and workflow patterns that transplant verification across domains A synthesis of the strongest “verification transplant” patterns in the sources above looks like this: First, make the object of work testable. In software, the object is executable code; Willison argues this is the defining advantage of coding agents because they can execute what they write and iterate until it works. Silva applies the same idea to documentation by treating procedures as statements that can be tested by automation, turning “docs correctness” into an enforceable property rather than a vibe. Second, force grounding through inspectable artifacts. Von Zastrow’s legal-research demo is a canonical example: answers come with citations and links into a real case database so the user can open and verify. The veterinary episode similarly recommends grounding in vetted documents and explicitly warns that LLMs can invent citations, so sources must be checked. Third, separate probabilistic generation from deterministic execution. Soper’s “Claude orchestrates; the script executes” is a generalized recipe for moving repeated, exact transformations out of the LLM and into code. Bahr’s citation checker similarly takes a frequent failure mode (invented or malformed citations) and pushes verification into an API lookup step that behaves deterministically. Fourth, treat cross-domain expertise as process, not prose. Crawford describes eliciting best practices from software engineering and encoding them into modular “skills” documents that can be selectively retrieved by agents. Silva’s discussion of skills files similarly frames them as portable, reusable “actionable docs” for agent harnesses, but emphasizes human curation and a quality bar. A compact rubric for identifying more “good” cross-trained accounts If you continue hunting beyond this sample, the most reliable filter is not platform but whether the person’s story includes an explicit verification mechanism. The best accounts tend to answer at least one of these questions in concrete terms: • What is the domain’s fastest “ground truth” feedback loop (compile, run, cite lookup, chart review, lab result, peer review)? • What does “verification” cost relative to “generation,” and how does that change which tasks are safe to delegate? • What parts of the workflow were redesigned to make outputs auditable (tests, links, checklists, scripts, CI gates)? • Where does verification stop being cheap (semantic fit, proposition support, missing context, regulatory constraints)? These questions map directly onto why cross-trained practitioners are unusually articulate: they can compare not just “AI performance” but the surrounding epistemic infrastructure—what the domain provides for catching mistakes, how errors manifest, and who pays when they slip through.