Forem: Karl Wirth

Best Practices for Coding with Agents

Karl Wirth — Mon, 09 Mar 2026 15:58:45 +0000

You already know coding agents can write code. The interesting question is what happens when you stop thinking of them as code generators and start treating them as junior developers who need good specs, clear test criteria, and visual references — just like a human would.

We build Nimbalyst this way every day. Here’s our workflow:

Write a plan in markdown. Edit this. Iterate.
Have the agent enrich it with architecture diagrams and data models. Edit this. Iterate.
Iterate on mockups until the UI is right
Have the agent write tests from the acceptance criteria. Edit this. Iterate.
Tell it to implement until tests pass
Walk away. Check in from your phone.
Review the work. Suggest changes.
Commit
Update plan document, documentation, website

Each step produces context that the next step consumes. By the time the agent starts writing code, it has the spec, the architecture diagram, the database schema, the mockup, and the test suite — all in one workspace, all visible to it. That’s why it works.

Plan First

Every feature starts as a markdown file with YAML frontmatter: status, priority, owner, acceptance criteria. We type /plan and iterate on the document with the agent until the goals and implementation approach are solid.

Plan document with YAML frontmatter, status bar, and inline AI diff in Nimbalyst

The plan isn’t a throwaway note. It tracks status as work progresses (draft -> in-development -> in-review -> completed), versions with git alongside the code, and serves as the single source of truth. When the agent later implements, it reads this document. When we review the work, we compare against it.

The difference between this and a Jira ticket: the plan is a rich markdown document that the agent can actually parse and act on, not a text field nobody reads.

Diagrams and Data Models in the Same Workspace

A text plan can only communicate so much. We ask the agent to add visual context:

“Add an architecture diagram showing the WebSocket connection flow between the client, server, and notification service.”

It creates an Excalidraw diagram in the workspace. We see it rendered, drag things around, tell the agent to adjust (“move the queue between the API and the notification service”), and iterate until the architecture is clear.

Excalidraw architecture diagram with AI chat sidebar in Nimbalyst

For database work, we ask for a data model:

“Create a data model for the notifications schema.”

The agent generates a .datamodel file that renders as a visual ERD. Tables, foreign keys, field types, all editable. We review it, ask for changes, the agent updates it.

Data model rendered as visual ERD with AI chat in Nimbalyst

The critical thing: these artifacts live alongside the plan and the code. When the agent later implements, it doesn’t need us to re-explain the architecture or the schema. It reads them directly.

Mockup, Annotate, Iterate

For anything with a UI, we create mockups before touching code. The agent generates .mockup.html files — real HTML/CSS that renders live in the workspace.

HTML mockup with before/after diff slider and AI chat in Nimbalyst

We review visually. Use annotation tools to circle what needs changing. The agent sees the annotations, understands the spatial context, and regenerates. Three or four rounds and the mockup matches what’s in our heads.

This replaces the Figma-to-engineering handoff entirely. The mockup is already in the workspace. When the agent implements the UI, it already knows what it should look like. No exporting, no describing screenshots in words, no “make it look like the design.”

Tests Before Implementation

Before writing any implementation code, we have the agent write tests. This is where the earlier context pays off.

“Write Playwright E2E tests for the notification center based on the plan and mockup.”

The agent reads the acceptance criteria from the plan, references the mockup for expected UI behavior, and generates test cases. We review them, add edge cases, and now we have an executable definition of “done.”

Every test fails. That’s the point.

Implement Until Green

Now we tell the agent:

“Implement the notification system. Run tests after each major change. Keep going until all tests pass.”

The agent works iteratively. Implements the database migration from the data model. Runs tests — schema tests pass. Builds the WebSocket server. Runs tests — connection tests go green. Implements the frontend. Runs Playwright — catches a CSS issue from the screenshot, fixes it, reruns. Eventually: all green.

This isn’t prompt-and-pray. The agent has the plan for architecture guidance, the data model for the schema, the mockup for the UI, and the test suite for verification. It loops through code-test-fix cycles autonomously.

Walk Away, Check In From Your Phone

Once the plan is solid, the tests are reviewed, and the agent is pointed in the right direction, we don’t sit and watch. We go to lunch. Take a meeting. Go for a walk.

The agent keeps working.

When it finishes or needs input, we get a notification on our phones. The Nimbalyst mobile app shows session status, the full transcript of what the agent did, and file diffs. If the agent needs a decision, we tap our answer and it continues. If all tests pass, we review the changes from wherever we are.

Nimbalyst mobile app showing active agent sessions and status

Nimbalyst mobile app showing file diff review on phone

This is not “set it and forget it.” We stay engaged. But the engagement happens on our terms — on the train, at the coffee shop, between meetings. The agent’s work doesn’t stall because we’re not at our desk.

Review the Work

When the agent finishes, we review. Nimbalyst shows every file the agent touched in a sidebar, with full diffs for each one. We click through the changes, see exactly what was added, modified, or removed, and compare it against the plan and mockup.

Diff review showing file changes with red/green inline diff in Nimbalyst

This isn’t reading a pull request cold. We wrote the plan, reviewed the tests, and approved the mockup. The review is checking whether the agent followed through on decisions we already made. It usually did. When it didn’t, we tell it what to fix and it iterates.

The files sidebar makes this fast. We see the full scope of changes at a glance — no scrolling through a massive diff. Click a file, review it, move on.

Commit

Once the review looks good, we commit directly from the workspace. Nimbalyst has a built-in git commit flow — the agent proposes a commit message based on the changes, we review or edit it, and commit.

Git commit dialog with AI-proposed commit message in Nimbalyst

No switching to a terminal. No copying file lists. The commit happens in context, right after the review, while everything is still fresh. The agent’s proposed message is usually accurate because it knows what it did and why — it read the plan.

Update the Plan and Docs

After committing, we close the loop. The plan document gets updated: status moves from in-development to completed, acceptance criteria get checked off, and any implementation notes get added for future reference.

Session kanban board showing work items across phases in Nimbalyst

We also update documentation, CHANGELOG entries, and website content if the feature is user-facing. Because the agent has full context of what was built, it can draft these updates too. We review and merge.

This step matters more than it seems. Without it, plans drift from reality, docs go stale, and the next person (or agent) working in the area starts from incomplete context. Closing the loop keeps the workspace honest.

Why Context Continuity Is the Real Unlock

Coding agents are good at writing code. What limits them is context fragmentation.

In a typical setup, the spec lives in Confluence, the mockup in Figma, the tasks in Jira, the tests in your IDE, and the agent runs in the terminal. The agent gets fragments through MCP calls or copy-pasted text. It’s reading a book one sentence at a time through an API.

This workflow works because every artifact — plan, diagram, data model, mockup, test, code — lives in the same workspace and is directly readable by the agent. No handoffs. No context translation. No “let me describe what the Figma mockup looks like.”

The result:

Plans give the agent architectural direction it can actually follow
Diagrams show how pieces connect without verbal explanation
Data models define the exact schema to implement
Mockups provide a pixel-accurate UI target
Tests give a machine-verifiable definition of done
One workspace means none of this is lost in translation
The agent isn’t smarter in this workflow. It just has everything it needs.

The Workflow

Plan. Enrich with visuals. Mockup the UI. Write tests. Implement until green. Review from anywhere. Commit. Close the loop.

We ship features this way every day. The agent handles the mechanical iteration. We focus on the decisions that actually require a human: what to build, what the architecture should look like, whether the tests cover the right scenarios, and whether the final result is what we wanted.

That’s how we build Nimbalyst, and it’s how Nimbalyst is designed to let you build too.

Context Is the New Code

Karl Wirth — Mon, 09 Mar 2026 15:54:24 +0000

The Prompt Isn’t the Problem

The prompt is the last mile. The tip of the iceberg. What actually determines the quality of AI-generated code is everything you give the agent before the prompt: your spec, your architecture diagram, your mockup, your data model, your existing codebase, your test suite, your acceptance criteria.

That’s context. And context is the new code.

The Evidence

Consider two approaches to the same task. Same Claude Code model. Same feature request: “Build a team management settings page.” Same developer.

Approach 1: Prompt only The developer opens a Claude Code session and types: “Build a team management settings page where admins can invite members, assign roles, and remove people.”

The result is a generic CRUD page. Hardcoded role values. No error handling for edge cases. No loading states. No confirmation dialogs. No empty state. Functional but shallow. The AI had to guess at every design decision, and it shows.

Approach 2: Context-rich session The developer writes the same prompt, but the Claude Code session also has access to:

A 2-page spec with acceptance criteria, edge cases, and error states
A visual wireframe showing the exact layout, including empty state and delete confirmation
An entity diagram showing Team, TeamMember, and Invitation entities with relationships
The existing codebase’s component library and style patterns
Three relevant test files showing the project’s testing patterns
The result is a production-quality page matching the existing design system. Proper role-based access control. Loading skeletons. Error boundaries. Confirmation dialogs. Empty state. Tests following project conventions. Practically shippable.

The second approach doesn’t just produce marginally better code — it produces categorically different output. The AI stops guessing and starts executing. Same model, same prompt, radically different results. The difference is context.

Why Context Beats Prompts

A prompt tells the AI what to do. Context tells the AI what you know, what you’ve decided, and what good looks like.

Context provides constraints
“Build a settings page” has infinite solutions. A mockup showing the exact layout has one. Constraints improve output because they reduce the solution space to the right answer.

Context provides patterns
When Claude Code can see your existing components, it follows your patterns. When it can see your test suite, it writes tests the same way. Without context, it invents patterns. With context, it matches yours.

Context provides decisions
A spec with edge cases represents decisions you’ve already made. “When you remove the last admin, show an error” is a decision. Without that context, the AI either ignores the edge case or makes a different decision. Your context encodes your judgment.

Context provides standards
A data model with specific field names, types, and constraints is a standard. It eliminates the “what should I name this column?” decisions that produce inconsistent code when made ad hoc.

The Craft of Context

If context is the new code, then crafting context is the new programming.

Here’s what good context looks like for a feature:

Plan/Spec (markdown): What the feature does, who it’s for, acceptance criteria, edge cases, error states, non-requirements (what it explicitly doesn’t do)
Architecture (Mermaid or Excalidraw diagram): How the feature fits into the existing system. Services, databases, APIs involved.
Mockup (HTML/CSS): What the UI should look like. Layout, components, interactions, states (loading, error, empty).
Data model (visual schema): Entities, relationships, fields, constraints, indexes.
Existing code (codebase access): Component library, style conventions, test patterns, API conventions.
Test cases (markdown): What success looks like. Expected behaviors, user flows, and validation criteria the AI can code against.
And here’s the key: you’re not building all this context by hand. You’re building it with your AI agents. Claude Code helps you write the spec, generate the architecture diagram, scaffold the mockup, draft the data model. The AI is your co-author for context, not just for code. You bring the judgment and decisions; the agent helps you capture and structure them.

Each piece of context eliminates a category of decisions the AI would otherwise make randomly (or badly). The more context, the less variance. The less variance, the higher quality.

Excalidraw architecture diagram providing visual context for AI agents in Nimbalyst

The Context Workspace

This is why we built Nimbalyst as an integrated workspace rather than a standalone AI chat.

If context matters most, then the tool should optimize for context creation and delivery:

WYSIWYG markdown for writing specs that Claude Code can read and edit
Mermaid and Excalidraw diagrams embedded in specs for architecture context
MockupLM for visual mockups that Claude Code can see and reference
Excalidraw for data model and architecture diagrams that Claude Code uses as a blueprint
Session linking so context from previous sessions carries forward
File-to-session tracking so the AI knows which sessions touched which files
Everything in one workspace. Everything visible to Claude Code. No copy-pasting context from one tool to another. No “let me describe what the mockup looks like.”

The Implication for Teams

If context is the new code, then context quality is the new code quality.

Code review becomes context review. “Did you provide enough context before asking the agent to code?” “Is the spec missing edge cases?” “Does the mockup match the design system?” “Is the data model normalized?”

The best developers won’t be the best coders. They’ll be the best context crafters — people who can build complete, precise, well-structured context that produces excellent AI-generated code on the first try.

FAQ
Q: This sounds like you’re just saying “write better specs.” A: Partly, yes. But it’s more than specs. It’s the combination of specs + visual mockups + data models + existing code patterns all being visible to the AI simultaneously. That integration is the key — not any single piece of context.

Q: Doesn’t this make the PM role more important than the developer role? A: It makes context creation more important than code writing. Whether that’s the PM’s job or the developer’s job depends on your team structure. Many developers write their own specs. The point is that whoever crafts the context determines the output quality.

Q: What about complex code where context isn’t enough? A: Context doesn’t replace engineering expertise. For performance optimization, distributed systems, complex algorithms — you need deep technical knowledge. Context gets you 80% of features. The other 20% still needs human engineering judgment.

The Future is Small Teams

Karl Wirth — Mon, 09 Mar 2026 15:13:26 +0000

We’re a small team building software for small teams. That’s not an accident, it’s our thesis.

The future of building software, and honestly the future of building anything, belongs to small teams of 3 to 7 people. Not solo founders grinding alone. Not 500-person departments or 10,000 person companies with layers of coordination. Small, tight groups where everyone knows what everyone else is doing, where decisions happen in minutes instead of meetings, and where each person brings real leverage because they’re each commanding their own teams of AI agents.

Why Small Teams Win Now

Small teams have always had advantages: speed, trust, low communication overhead. But those advantages used to hit a ceiling. A 4-person team simply couldn’t produce the output of a 40-person team, no matter how efficient they were.

AI agents change that math completely.

Today, a single person working with AI agents can do the work that used to require a team of 5-10 people. They can write code, generate documentation, analyze data, create marketing assets, and manage workflows, all with AI handling the execution while they provide direction and judgment.

Multiply that by 3-5 people, and you have a unit that can match or exceed the output of teams many times their size. Each person becomes a force multiplier, not just a contributor.

The Coordination Cliff

Here’s the thing that doesn’t scale: coordination.

Brooks’s Law told us decades ago that adding people to a late software project makes it later. The underlying reason hasn’t changed — communication overhead grows exponentially with team size. With n people, you have n(n-1)/2 possible communication channels. At 5 people, that’s 10 channels. At 10 people, it’s 45. At 20, it’s 190.

AI agents amplify this problem in a new way. When each person is running multiple agent sessions, each producing code, documents, and decisions, the surface area of what needs to be coordinated explodes. It’s not just keeping 5 people aligned — it’s keeping 5 people and their dozens of concurrent workstreams aligned.

Small teams navigate this naturally. At 3-5 people, you can maintain a shared mental model of the entire project. You know what everyone is working on. You can make decisions in a quick conversation rather than a formal process. You can review each other’s AI-generated output without it becoming a full-time job.

Beyond that size, the coordination cost starts eating the productivity gains from AI. You need project managers, alignment meetings, documentation standards, approval workflows — all the overhead that slows large organizations down. The AI makes each individual more productive, but the organization can’t absorb that productivity because it gets lost in coordination.

What Small Teams Actually Need

If small teams are the future, what do they need from their tools?

Individual leverage. Each person needs to be maximally effective on their own. That means deep AI integration — not a chatbot in a sidebar, but an AI agent that can read your codebase, execute tasks, create artifacts, and maintain context across long working sessions. The individual unit of work needs to be powerful.

Shared context without overhead. The team needs to stay aligned without status meetings and Slack threads. That means shared workspaces where you can see what others are working on, what their AI agents have produced, and what decisions have been made — all without anyone having to write a status update.

Lightweight collaboration. When you do need to coordinate, it should be fast and direct. Review someone’s AI-generated code. Comment on a plan document. See what changed in the last session. Not through a heavyweight process, but through tools that make collaboration feel as natural as working alone.

Unified workspace. Small teams can’t afford to juggle 10 different tools. They need their documents, code, diagrams, plans, and conversations in one place — not because “all-in-one” is a feature, but because context switching is the enemy of the tight feedback loops that make small teams fast.

What We’re Building

This is exactly what we’re building with Nimbalyst.

For individual work, Nimbalyst gives you an AI-native workspace where Claude Code agents run directly in your editor. You can write code, create documents, draw diagrams, manage plans, and execute complex multi-step tasks all with an AI agent that has full context on your project. You’re not copy-pasting between a chat window and your tools. The agent works where you work.

For collaboration, we’re building the connective tissue that keeps small teams aligned. Shared workspaces where your teammates’ work is visible. Session histories that let you understand what happened while you were away. The goal is to give small teams the shared awareness that large organizations try to achieve with meetings and managers — but without the overhead.

We use Nimbalyst to build Nimbalyst. We’re a small team. We run agent sessions for everything from feature development to marketing content to bug fixes. And every day we learn what works and what’s missing when a handful of people are trying to move fast with AI.

The Bet

Our bet is simple: the teams that will build the best products over the next decade will be small. Not because small is trendy, but because the economics have fundamentally shifted. AI agents give individuals leverage that used to require headcount. And the coordination costs of large teams haven’t gotten any cheaper — if anything, they’ve gotten worse as the pace of AI-assisted work has accelerated.

3-7 people, each with their own teams of agents, sharing a workspace, moving fast, staying aligned. That’s the unit we’re building for. That’s the future we see.

No More Marketing Bottleneck: How We Automated the Software-to-Marketing Pipeline

Karl Wirth — Mon, 02 Mar 2026 15:34:08 +0000

Most companies have a gap between shipping software and telling the world about it. A feature is built. Then someone writes release notes. Someone else updates the docs. Someone asks for screenshots. A marketer rewrites the changelog for the website. A designer records a demo video. Weeks pass. The marketing site still describes the old version.

This problem might have been tolerable pre-AI, but at the speed with which we are releasing features with coding agents, it is unacceptable.

We closed that gap. At Nimbalyst, when we release a feature, we run a coding-agent powered pipeline to update our documentation, synch it to GitBook, generate our website content for Cloudflare, cut product videos and screenshots with Playwright, and update the website with those videos.

The Problem: Every Feature Ships Twice

Building a feature is one job. Telling people about it is a second job that's just as much work:

Release notes need to be written and formatted
Documentation in needs new pages or updated sections with accompanying videos and screenshots
Website copy needs to reflect the new capability
Screenshots need to be captured in both light and dark mode
Product videos need to show the feature in action
Changelog entries need to be added

In most teams, each of these is a manual handoff. Developer finishes the feature, writes a Slack message, product manager drafts docs, marketer updates the website, designer records a video. The chain is slow, lossy, and nobody owns the whole thing.

We decided the whole thing should be a coding-agent-powered pipeline.

The Automated Pipeline

Here's what happens when we ship a feature for Nimbalyst:

1. Feature ships → Content gets written

When a feature is released, in Nimbalyst, we ask our coding agent (use both Claude Code and Codex) to write a short markdown document describing the feature for our website and our documentation. It leverages the feature plan document, the code itself, and the release notes to do so. We edit what it wrote and iterate on this with the coding agent.

When we are satisfied with the response, we instruct the coding agent to change the documentation in github, update the relevant YAML data files that drive our website copy, and write a blog.

2. Content → YAML Files → Website deploy → Cloudflare Pages

Our website copy lives in YAML files in a git repo, not a CMS. That means Claude Code can edit marketing content the same way it edits source code. There's no proprietary editor to navigate, no API to call, no format to translate. A feature description becomes website copy in the same git repo, in the same session, reviewed with the same diff tools.

When needed, we open the YAML files that were changed in Nimbalyst either to spot check or to make some manual edits that are easily made by hand then described. We might not like what the coding agent did and then we ask for a rework or addition.

We run our staging site locally with npm dev and can review the updated page there.

Our marketing site is Astro on Cloudflare Pages. Git push to main and it deploys. Updated YAML copy, new blog posts, revised feature descriptions — they all go live with a git push. You can see the result at nimbalyst.com.

As noted, we follow this same process for our new blog, but we have a /blog command for this.

3. Docs update → GitBook syncs

Our documentation lives in a markdown file that syncs to GitBook. When the coding agent writes or updates a doc, it again is just a markdown file in a git repo. Push to main, GitBook picks it up. No manual copy-paste into a docs platform, no separate editing workflow.

Again, we review the changes made in the markdown file in Nimbalyst and iterate on it with the coding agent, for example, asking for a mermaid diagram or excalidraw to illustrate a key point.

Our coding agents write docs that are accurate because the have the full context — they can read the source code, the plan, understand the implementation, and write documentation that matches what the feature actually does, not what someone remembers it doing. See the finished product at docs.nimbalyst.com.

4. Text → Screenshots and Videos → Live on our Docs and Website

So far so good, but text is easier. What about the images and videos needed to explain the feature. We use Playwright to capture product videos directly from our running application. Not screen recordings where someone clicks through a demo — automated, scripted captures that show exactly the workflow we want, every time.

Our YAML data files include structured screenshot comment blocks that describe what each image or video should show (editable by human, updatable by agent). Playwright reads these specs, sets up the application state, and captures the assets. Light mode and dark mode variants. Specific crop regions — full window, editor pane, sidebar, toolbar, zoom.

When the product changes, we re-run the Playwright pipeline and get updated visuals that match the current UI. No re-record. No "the screenshots are from three versions ago" problem.

Each Playwright spec choreographs a complete sequence: launch the app, set up realistic data, navigate to the right screen, trigger AI interactions, and capture at the exact moment the UI tells the story. The specs capture both light and dark theme variants automatically, and video specs include a DOM-injected cursor that shows natural mouse movement — making the footage look like a real person using the product, not a robotic test run.

The screenshots and videos follow the same pipeline as text content. They are stored in git and pushed to the website and/or the documentation site or included as part of the blog. We use the same screenshot and video creation process to make assets for social when we need them.

5. Everything is connected and reviewable

Every piece of this pipeline produces artifacts in a git repo: changelog entries, documentation, website copy, screenshot specs, images, videos. We can have our coding agent read, leverage, and update every aspect of the pipeline and website. And we humans can do the same... reviewing and approving the agent's changes with red/green diffs and editing and updating all in markdown, code files, html mockups, and sessions. We see exactly what changed, can revert anything, and have a complete history of every marketing asset.

Why This Matters

Speed compounds

A single feature update might touch five different marketing surfaces. If each takes an hour of manual work, that's half a day per feature. Ship ten features a month and you've lost a full week to marketing maintenance. Ship 10 features every few days and you simply cannot keep up if this is manual.

Automated, the same updates take minutes. The content is drafted, reviewed as a diff, and deployed in one session.

Accuracy by default

When Claude Code or Codex write docs and marketing copy, each is reading the actual source code, plan files, specs, and diagrams. The feature description on the website matches what the feature does because they're derived from the same context. No telephone game between developer, PM, and marketer where details get lost or simplified incorrectly.

Visuals stay current

The Playwright pipeline means our screenshots and videos always show the current product. Every time the UI changes, we regenerate assets. The marketing site never shows an outdated interface — a problem that plagues every fast-moving product.

One repo, one workflow

Documentation, marketing copy, blog posts, changelog entries, screenshot specs — they all live in git repos. We use the same tools for all of them: Nimbalyst for editing and review, Claude Code for drafting and updates, git for version control, Cloudflare and GitBook for deployment.

There's no context-switching between a CMS, a docs platform, a design tool, and a video editor. It's all code and content in the same workspace.

The Nimbalyst Difference

You could build this pipeline with any coding agent in a terminal. But the full loop works better in a visual workspace like Nimbalyst:

Visual review matters. When Claude Code or Codex updates website copy, we see the rendered result in the same workspace. When it writes a blog post, we see formatted markdown. When Playwright captures a screenshot, we can view it immediately. And not just see and review these files, we can visually edit in Nimbalyst and collaborate iteratively with the coding agents.

Parallel sessions keep the pipeline moving. We run Codex and Claude Code sessions in parallel. Nimbalyst manages these sessions so we can coordinate across them without losing context. You can easily see what files each session changed and open and edit them, the status of sessions, find and resume sessions, and commit from the session with AI assist.

Diffs are the review mechanism. Every change Claude Code makes, whether it's source code, YAML copy, or markdown docs, shows up as a reviewable diff. We approve marketing changes with the same rigor we approve code changes. That's only practical in a workspace designed for it.

What We Learned

Treat marketing content as code. We moved our website copy into YAML files, our website into github pushed to Cloudflare, and our docs into markdown, which made it possible to automate the entire marketing surface. If your content is trapped in a proprietary SAAS editor or a proprietary CMS, your coding agent will have a harder time with it.

Invest in structured specs. Our screenshot comment blocks in YAML files seem like overhead but they let Playwright regenerate every marketing visual automatically. The upfront structure pays for itself every time the product changes.

The loop matters more than any single step. Automating docs alone is useful. Automating website deploys alone is useful. But automating the full loop — feature to docs to website to videos is qualitatively different. Nothing falls through the cracks because there are no cracks.

Ship features and ship the story simultaneously. When the marketing pipeline is automated, you don't have a backlog of "features we shipped but haven't told anyone about." The story ships with the feature. Your website is always current. Your docs are always accurate. Your videos always show the real product.

We went from a world where marketing was a separate project that lagged behind engineering to one where they're using the same tools at the same speed. See the finished product on our website and documentation.