Jude Edwards

AI can build an app in an afternoon. But getting it safely into other people's hands is a whole other challenge! This is the problem that I've been working on these past few months. I'm proud to finally share how we solved it with Block App Kit! engineering.block.xyz/blog/from-loca…

Oh this is gonna be GOOD 🐨

“Here’s the part that” is the new emdash

AI agents have been creating code reliably for >6 months now, and the result has been an explosion in the amount of apps and software. The next challenge is capturing the intent behind that software so that agents can also maintain it long-term, without human intervention.

ai-fed, human-finished.

@morgmode hi @morgmode

Is this thing on?

Thank you @claudeai and @ChatGPTapp for being the place my non-coder family and friends now go to describe their "great app idea".

As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes: 1. Prototyper: comes up with brand new ideas; churns out many ideas, most of which don't ship 2. Builder: quickly turns a prototype/idea into production-grade product/infra 3. Sweeper: cleans up the UI, simplifies the code and system, unships, optimizes performance 4. Grower: takes a product that has been built and iterates on it to improve Product-Market Fit 5. Maintainer: owns a mature system to make it secure, reliable, fast, and efficient as it scales Many people span across 2 roles, and sometimes 3 roles. I also notice that these roles are not really tied to job function -- eg. across Anthropic, some designers match category 1, some 2, some 3; same for engineers, PM, DS. A healthy team needs a mix of these, depending on the product: - A product that is new and pre-PMF needs people that are strong at 1+2+3 - A product that is growing and has found PMF needs 2+3+4 and some 5 - A product that has strong PMF needs 3+4+5 and some 2 Maybe product roles of the future will look more like this, and less like the domain-specific roles of today?

@0xblackbirdoff Yes! The team is working on this now. There are quite a few pieces involved so (as you might guess) it’s not a straightforward path to open source. If you’re interested in trying it out in the meantime, please feel free to email me. My email is provided at the end of the article.

@jedwards_27 Looks pretty cool! Do you have plans to opensource it somehow?

AI can build an app in an afternoon. But getting it safely into other people's hands is a whole other challenge! This is the problem that I've been working on these past few months. I'm proud to finally share how we solved it with Block App Kit! engineering.block.xyz/blog/from-loca…

Does anyone have a good prompt/skill recommendation to generate nice-looking mermaid diagrams from code or design docs? This prompt would sit on top of something like mermaid.ai/docs/ai/mcp-se… or github.com/excalidraw/exc… to improve the quality of the agent's output.

@bakshim Re: sandboxing, we leaned heavily on our security partners to help us ID all the data ingress and egress paths within the building and viewing flows. We then locked each path down using the available controls for each piece of the stack (e.g. CSP, JWTs, etc). We deny by default.

Love the opinionated stack for consistent controls @jedwards_27. Once these AI-generated apps are live and being used/composed with other tools, what kind of continuous security monitoring or anomaly detection do you have in place? Things like unexpected data access patterns or behavior changes. Also curious to know more about any sandboxing used to host

@bakshim Great question! We baked observability into the platform to emit logs and events for each app session. We use a combination of deterministic tools (e.g. Datadog monitors and alerts) and non-deterministic tools (e.g. Builderbot automations, ad-hoc agent sessions) on top of that.

@behradkhodayar What you're describing is a combo of Builderbot (x.com/blocks/status/…) and Block App Kit. But yes, that's an accurate representation of how many engineers at Block are working these days & one way that BAK fits into the workflow for development 👍

Great read & approach in SoC. Is the following assumption true & anything u may add to this? Engineer: "@ builderbot migrate service X to API v4" Builderbot: -> plans the migration -> splits into subtasks -> launches N Goose agents Goose agents: -> inspect code -> edit files -> run tests -> query internal systems via MCP Builderbot: -> aggregates outputs -> opens PRs -> requests approvals Block App Kit: -> renders plans -> shows diffs -> enforces policies -> tracks deployments

@Kevinduan2014 All of the above! The important thing is to make it close to impossible for the agent to deploy unsafe apps. Whether that's sensitive data being baked into the app code, secrets being passed around in the open or a weak auth model (e.g. over-reliance on security-by-obscurity).

@jedwards_27 I guess the harness for deployment needs integration with security, auth, data access control which needs to be ready for the kit. What do you think is the most critical

We built an internal AI system called Builderbot. It coordinates agents across our entire codebase. Engineers tag it in Slack, and it researches, plans, and ships. The story so far: - 200,000 operations per day. - 1,500 pull requests merged per week. - 15% of all production code changes across Block. What used to take months now takes days. How we built it: block.xyz/inside/block-r…

My son and I vibe-coded a fish tank together this morning! Legitimately spent 45 mins just watching the fish and adding in different features. So cute and fun :)

:bufo_waves_hello_from_the_void: