How we work

AI is core to how we build. The lever is context.

A lot of companies are using AI for code. Most of them are using it the same way — autocomplete, snippets, occasional refactors. The model writes a function, the engineer reviews it, the work moves on. The gain is real but bounded; it caps at “faster typing.”

That’s not how we work. The lever isn’t the tooling — it’s the depth of what the tools can read.

Most engineering teams treat documentation as a deliverable — something written after the work, for people who weren’t in the room. The doc summarizes what got built. It rarely captures why.

We write our docs the other way around. They are not summaries; they are operating manuals. The order lifecycle, the formula AST, the integration semantics, the working-time utilities, the notification channels, the announcement system, the disclosure rules, the brand voice, the marketing strategy — each lives as a document dense enough to be the source of truth. They are written for a reader who needs to act on what they read.

That writing posture changes what a model can do. When Claude reads our docs, it is not reading a high-level overview; it is inheriting the operating context that a senior teammate would carry. The result is not faster typing — it is qualitatively different work. Plans that anticipate side effects. Code that respects existing conventions. Decisions that account for adjacent systems.

A typical task on the platform: add a feature that affects how invoices are generated.

Without depth-of-context, the work shape is: an engineer reads the invoice service, decides what to change, writes the change, hopes nothing downstream breaks. The model helps with syntax. The decisions stay manual.

With depth-of-context, the work shape is different. The model has read the order lifecycle, the billing flow, the resource model, the integration log for Zoho Books, the audit-log expectations, the notification channels that fire on invoice events, the data models for line items and credit notes, and the operational disclosure rule that affects what gets shown publicly. It plans the change knowing that immediate-invoice generation differs for Aabcoonline-sourced orders, that the canceled-order line item rule must be preserved, that the weekly-job timing is Monday 7am UTC, that audit logs need the matching action keys, that the credit-note application timing is downstream of approval.

The change ships in one pass instead of three. Not because the model is faster — because it is operating with the full picture instead of a slice.

The same posture applies outside engineering. Marketing has its own depth — a brand voice doc, a four-layer strategy, page-by-page website specs, a vocabulary rule, an operational disclosure rule. Operations has the admin handbook, the playbooks, the configuration reference. Design has the brand principles and the visual language that holds across surfaces. Each domain has the same shape: deep written context that a person — or a model — can act on.

That is what the agent network is. Specialists with curated context for each function. The engineering agent today; marketing, design, and operations in development. Each one builds on the same lever — the writing.

The investment is not in tooling. It is in the writing that makes the tooling work.

Working at Blitz means writing as part of building. Not docs after the fact, but docs that shape what gets built. If you build a system, you write how it operates. If you make a decision, you write why. If you set a policy, you write what holds and what doesn’t.

That writing becomes the company’s substrate. Future teammates read it. Future models read it. The work compounds — not because we work more, but because the work we do today carries forward more clearly than it would otherwise.

The team stays small. The output doesn’t.