Where thinking in engineering happens now | Vanta

Solutions

Partners

Resources

Plans<br>Log inLog inGet a demo

Get a demo

BlogEngineeringJune 17, 2026

Where thinking in engineering happens now<br>Written by

Yanxi Chen<br>Senior Software Engineer

Reviewed by

No items found.

Accelerating security solutions for small businesses<br>Tagore offers strategic services to small businesses.

A partnership that can scale<br>Tagore prioritized finding a managed compliance partner with an established product, dedicated support team, and rapid release rate.

Standing out from competitors<br>Tagore's partnership with Vanta enhances its strategic focus and deepens client value, creating differentiation in a competitive market.

This blog is part of our Trustcraft series, in which we dig into Vanta’s approach to building with AI. Read the first blog in this series to learn more about how we define Trustcraft.<br>I sent two long docs and a recorded walkthrough for review. The walkthrough did all the work. The docs barely got opened.<br>That was the moment I started questioning a habit I'd had for years.<br>I’m a Senior Software Engineer at Vanta, and throughout my career, I defaulted to a doc-first workflow. A doc isn't just an alignment artifact, it's the thinking. The act of writing forces you to confront tradeoffs you'd otherwise paper over. The reader's frustration with a long doc is the cost of the author having actually done the work.<br>I still believe writing is thinking. However, as AI moves into the dev cycle, I just don't believe the page is where it has to happen.<br>How AI actually changed my dev cycle<br>AI made building cheap enough to think against running code, and conversation rich enough to think out loud against a partner.<br>Both moves do the same thing underneath: They make rigorous thinking less dependent on me being careful.<br>Pre-AI, surfacing the implicit dependencies of a design or testing whether my framing was right depended on me being careful enough to catch them on the page. Now they get caught in the trying: by an agent pushing back during step one, or by a prototype bumping into them during step two.<br>The doc is still where I capture what I learned. It's not where the learning has to happen anymore. In other words, AI has shifted what kinds of thinking depend on attention.<br>Here's what my dev cycle looks like now.<br>Step one: Make sense of the goal<br>The thinking part of this used to be a doc-writing exercise: You'd write your way to clarity. Now I do most of it in conversation with an agent: think out loud, sketch a decomposition, surface the assumptions I'm making, push back on my own framing.<br>There's still a written artifact at the end—a short plan, maybe a page—but it's a capture of thinking that already happened, not the place where the thinking happens.<br>Step two: Build a working slice<br>Not a slideware POC but an actual end-to-end thing that runs. AI lets me wire it up in a day or two. The POC's job is to make the abstract concrete. You can argue about a design decision for an hour in the abstract or build the smallest version of it and see what you actually need.<br>Step three: A recorded walkthrough<br>The walkthrough does what a framing doc used to do—walk a reviewer through why each piece is the way it is. Except they're watching real behavior, not reading speculative design, and I'm explaining the decisions in line.<br>The walkthrough is a short-lived artifact, though: It serves the moment of review, then the doc that comes next is what carries the reasoning forward.<br>Step four: A short doc that captures decisions already made<br>By the time I'm writing the doc, the prototyping has done the deciding. The doc isn't where I figure things out, it's where I capture what I figured out for reviewers and for whoever has to make a related call later. It lays out the decisions and the reasoning behind them: the alternatives considered, the implicit dependencies, what assumptions I'm betting on, what's deferred on purpose.<br>What this looks like in practice<br>The use case<br>A recent example. I had to figure out where to host a new service we were spinning up. Pre-AI, this would have been days of design-doc writing.<br>The approach<br>What I did this time was different. I talked the decision space through with an agent first, decomposing it into the axes that mattered: operational model, cost shape, lock-in, build pipeline, etc.<br>Then, I built a working prototype of one of the hosting options. Two days, end-to-end, using our existing scaffolding for the security-sensitive pieces. I also built two POCs for the other two options, which cost about a day and a half on top of the first POC: Once the first POC was load-bearing, each additional option was mostly a swap of the deploy model.<br>The findings<br>I found things I would not have found from a doc:<br>Some hosting platforms ran the monorepo root build target even when I configured them not to—behavior their docs didn't describe<br>Some spawned preview builds on every PR in the monorepo, even for changes in...