Staff AI Engineer @ Vasion
Focused on shipping high-leverage developer experience (DevX) platforms and practical AI that accelerates product delivery.
Also: Husband, and most importantly — Father 👨‍👧 (the title that dwarfs the rest).

• 🚀 Staff AI Engineer: Building & scaling business‑critical printing platforms at Vasion and executing on company-wide AI strategy.
• 🧠 Domains: Developer Experience (internal platforms, velocity tooling), Applied AI in DevX, systems thinking.
• 🛠 Languages: Go (systems & services), TypeScript (platform & tooling).
• 🎯 Superpower: Executing fast without sacrificing architectural integrity or code quality.
• 🌱 Always improving: Feedback loops, operability, developer productivity.
• 🎤 Speaker: Go, platform engineering, AI-in-the-loop, developer productivity.
• 🍂 Perspective: Tech is transient; craftsmanship and impact endure.

Guiding principles:

1. Latency kills momentum — shorten idea → prod cycle.
2. Platforms must feel like products (DX = UX).
3. AI is not magic; it's an accelerant. Treat it like any other component with observability & guardrails.
4. In the LLM era, raw intelligence is rarely the bottleneck; curiosity and motivation are. The leverage now goes to the engineer who keeps probing the tools and wiring them into real workflows.
5. Documentation is an interface; if it's not ergonomic, it decays.

The constraint shifted: the ceiling is set less by what you “know” today, and more by how relentlessly you explore, instrument, and apply new capability.

I resonate deeply with the observation that very few people have internalized just how productive you can be with LLMs for coding—and fewer still actually pick up the practice. The saturation point (people truly extracting the leverage) is still tiny.
So I optimize for:

• Rapid curiosity loops (question → prototype → validation).
• Turning one-off AI assists into reusable internal accelerators.
• Lowering the activation energy for teammates to adopt the same leverage.
• Treating "I haven't touched that tech before" as a solvable integration problem, not a blocker.

• 🖨 Scaled business-critical print orchestration at Vasion (high-volume, multi-tenant workloads).
• 🤖 Drove AI strategy execution: pragmatic adoption (assistive coding, workflow augmentation, knowledge surfacing).
• ⚙️ Built internal tooling that materially reduced SDLC cycle¹ time & onboarding friction.
• 📈 Introduced metrics-driven platform governance (golden paths > tribal knowledge).

^{1. I know it has cycle twice, within the acronym and without it. It felt weird removing cycle so I decided to keep it and add this note.}

A few recent / representative talks (more at https://bostonc.dev/speaking/):

• 2024 · Brainrot Golang (GoWestConf)
  Using Go to procedurally generate “brainrot” style short-form video content—leveraging humor + pop culture to teach automation, content pipelines, and creative misuse of tooling. Abstract
• 2024 · log/slog: Structured Logging in Go (Utah Go User Group)
  Practical migration patterns to Go’s log/slog; designing consistent, queryable telemetry surfaces; performance & adoption tips. Abstract
• 2023 · Database Best Practices Panel (GoWestConf)
  Panel discussion on schema strategy, query ergonomics, operational safety, and balancing performance with clarity in Go services. Overview

Topics I enjoy exploring on stage:

• AI woven into DevX (not bolted on)
• Developer platform productization
• Instrumenting the engineering lifecycle (flow + quality signals)
• Turning curiosity into compounding team leverage

Core:

• Go, TypeScript
• gRPC / REST, Event-driven architectures
• SQL, Redis, S3-compatible storage
• Docker, k8s, Docker Swarm, GitHub Actions
• LLM integration patterns (RAG, embeddings, function calling, eval harnesses)

Adjacents / Practices:

• Domain-driven design
• Architectural fitness functions
• Developer portal / IDP patterns
• CI/CD pipeline ergonomics
• Incremental refactors over rewrites

• Default async; synchronous when collaboration tension is high.
• Feedback in minutes/hours, not days.
• Prefer readable over clever; prefer boring infra over fragile novelty.
• Instrument first, optimize next.
• Raise context, not just opinions.

• Time-to-first-meaningful-change for a new engineer.
• Change fail rate & mean recovery time.
• Drift between intended architecture and actual runtime topology.
• Latency of build → deploy → validate loop.
• Actually solving the customer's problem.

Outside of work:

• Dad time > everything.
• Enjoy distilling complexity into teachable mental models.

• 🌐 Website / Writing: https://bostonc.dev
• 🧵 X: https://x.com/bstncartwright

Thanks for stopping by.
If something here resonated, don't hestiate to reach out.