Building with AI at Block: What I Shared at Construct I/O
I gave a 10-minute talk at Ohio State's Construct I/O Builder's Summit on how Block is actually integrating AI into engineering — not as a side feature, but woven into how we plan, build, and ship.
In October 2025, I spoke at Construct I/O: The Builder's Summit, a conference hosted by the Ohio State University Center for Software Innovation. The session was called "Building with AI" — moderated by Dr. Arnab Nandi, with 10-minute talks from Dan Manges (co-founder of RWX), Patrick Shuff (AI Infrastructure at Meta), and me.
My 10 minutes were about what it actually looks like to build AI-natively at scale within Block — not as an experiment, but as the new default.
Zero-Interest Code
During the session, Arnab introduced a framing I haven't been able to stop thinking about: we're living through the zero-interest code era.
The analogy is to zero-interest mortgages. When capital is essentially free, people borrow more than they should. They take on houses they can't maintain, at prices that don't reflect the underlying reality. It works — until the rates change and the debt comes due all at once.
AI has made code nearly free to produce. You can generate in an afternoon what used to take a sprint. That sounds obviously good, but it carries the same risk: teams are accumulating codebases at a rate that outpaces their ability to understand, maintain, or reason about them. The technical debt is cheap to create and expensive to repay. The rates will change.
This is the backdrop to everything I talked about in my 10 minutes. The opportunity is real. So is the trap. The engineering orgs that come out ahead won't be the ones that generated the most code with AI — they'll be the ones that generated the right code, with the discipline to say no to the rest.
What We Built: Goose
One of the more concrete things I could point to was Goose, an open-source AI agent we built at Block and have since released publicly. Goose isn't a chat interface — it's an extensible agent that connects language models to real systems: codebases, internal tooling, deployment pipelines. It can actually do work.
By the time of the talk, engineers at Block were using Goose as a daily collaborator — not just for writing code, but for navigating unfamiliar systems, generating test coverage, and automating repetitive tasks. Our CTO Dhanji Prasanna, who drove a lot of Block's AI-native transformation, framed the goal as saving a meaningful percentage of manual hours across the entire company — not just engineering. The early signals were already pointing there.
Beyond Engineering: Everyone Is a Builder Now
Here's the part that doesn't get enough airtime in most AI-in-engineering conversations: AI hasn't just changed how engineers work. It's blurred the line between who is an engineer and who isn't.
At Block, we've seen PMs, designers, and operations teams prototype things that used to require an engineer to touch. Someone who wants to explore a data question doesn't need to file a ticket — they can work with an agent to get there themselves. A product manager can mock up a working proof of concept before the spec is even written.
This isn't about replacing collaboration between functions. It's that the surface area of who can build has expanded. Jack Dorsey has been direct about this: the intelligence tools we're building internally are meant for everyone, not just the technical staff. Everyone at Block is officially a builder now. That's the culture we're building toward, and it changes how you think about team structure, tooling access, and what "shipping" means.
The Embedded vs. Bolt-On Question
The instinct a lot of engineering orgs have with AI is to treat it like a feature you bolt on. You add a Copilot license, you spin up a chatbot, you call it an AI initiative. That's not what we're doing.
Jack has said publicly that "most companies are late" to understanding how much intelligence tools change what it means to build. I think the reason isn't that companies lack access to the tools — it's that they haven't changed how they operate around them.
We pushed to get AI into every layer of the engineering process: planning, code review, QA, deployment. But also: research, writing, customer support workflows, internal knowledge management. The goal isn't a single "AI-powered" feature. It's a practice where AI is a natural part of each step — and that requires both access (everyone has the tools) and transparency (you can see where and how it's being used).
Dhanji has made the point that driving this requires leaders to use these tools daily themselves. If the people at the top aren't doing it, the signals you send to the org are confused. You can't mandate a culture of experimentation; you have to model it.
Show, Don't Tell
One of the themes I kept coming back to in the talk — and something that cuts across both the AI question and the customer trust question — is that the prototype is the argument.
When someone on your team is skeptical about whether AI can help with a particular problem, the fastest way to change their mind isn't a presentation. It's a working demo. Build the thing, show it to them, let them use it. That's true inside engineering and across every other function.
The same logic applies to customer concerns. Some of our users have strong feelings about whether AI is involved in products they trust with their money. The right response isn't better messaging. It's building something so clearly good that the quality speaks for itself.
The teams that are winning with AI at Block are the ones prototyping constantly, sharing what they learn — including the failures — and letting real results make the case. That culture is more valuable than any particular tool.
The full Construct I/O conference lineup is on the OSU Center for Software Innovation's LinkedIn. You can also read more about Goose at github.com/block/goose.