Tubi Meetup: How to Turn AI into an Engineering Team

If the cost of generating code keeps falling, will writing code still be an engineer’s most valuable skill? If one person can orchestrate multiple agents at once, will teams get smaller—or will they take on larger systems? And when implementation speed is no longer the bottleneck, how should we plan the next chapter of our careers?

For the past two years, when we talk about AI programming, we tend to fixate on a very narrow question: how to write a better prompt, how to make ChatGPT, Claude Code, Codex, or Cursor produce code faster. But once AI actually enters a project that runs for months, spans multiple modules, and must ultimately ship, what determines success is rarely how brilliant any single conversation was—it’s whether the project has a stable engineering system behind it.

That is exactly the theme I’ll be sharing at this week’s Tubi Meetup: turning AI into an engineering team.

This talk will not demo the magic trick of “type one sentence, generate an app.” Instead it starts from three real and very different engineering cases: a lightweight local AWS emulator written in Rust, a wearable system that stretches from sensors in a soccer shoe all the way to cloud-side machine learning, and several 400–600 page Chinese technical books that can build and publish themselves automatically. One is pure software, one is hardware/software, one is knowledge content—yet all three converge on the same conclusion:

AI-native engineering is not prompt engineering. It is the construction, around AI, of executable context, task decomposition, feedback-driven verification, and a delivery system.

Writing Faster Is Not the Same as Shipping Faster

The traditional engineering workflow is usually described as understanding requirements, designing, coding, debugging, and testing. AI has dramatically compressed the implementation cost within that loop, but it has not automatically eliminated architectural trade-offs, accountability for quality, or the need to verify facts. On the contrary, when code and prose can be produced several times—or several dozen times—faster than before, vague requirements, unstable interfaces, and missing tests get amplified at exactly the same speed.

As a result, engineers’ work is migrating: away from personally completing every implementation detail, toward defining the problem, writing down constraints, designing verification methods, decomposing and scheduling tasks, reviewing AI output, and handling the exceptions and unknowns that no template can cover.

I summarize AI engineering throughput as a multiplicative formula:

Model capability × context quality × task decomposition × feedback speed × verification rigor × human judgment.

It’s multiplicative because if any single term approaches zero, the whole system can fail. The strongest model, if it doesn’t know a project’s long-term rules, can only guess again and again; the most complete spec, without fast tests and external feedback, cannot stop a “looks reasonable” error from quietly spreading.

Building a Protocol-Grade Software System

The first case, Rustack, is a lightweight local AWS emulator built in Rust, modeled on localstack. It currently covers 18 services and 779 routed operations, starts in under a second, and ships as a roughly 8 MB Docker image.

The hard part isn’t writing a handful of CRUD handlers—it’s protocol breadth and compatibility. AWS SDKs care about request signing, HTTP routing, XML or JSON serialization, error models, and a great many subtle behavioral semantics. An endpoint that “can return a result” is not the same as one that’s compatible with real clients.

Rustack didn’t begin by blanketing every service. It picked S3 first as a vertical slice: a client request flows through signature validation, protocol parsing, business logic, and storage, and finally produces a response the SDK can understand. S3 is complex enough to surface problems with XML, SigV4, streaming data, object versioning, and Multipart—and at the same time it has mature SDKs and third-party compatibility tests, which give AI machine-readable failure signals.

This process gradually produced three layers of project context. AGENTS.md holds the long-lived engineering rules—error handling, the concurrency model, quality gates, and “never leave a TODO behind.” Skills hold repeatable workflows. Specs constrain the current feature’s data model, component relationships, boundary conditions, and exit criteria. A prompt is disposable; this context can be versioned, reviewed, and evolved along with the project.

More importantly, external tests become AI’s best teacher. An initial DynamoDB implementation may have CRUD that “looks correct,” but the Alternator test suite goes on to expose expression precedence, exact numerics, nested paths, ReturnValues, pagination limits, and validation ordering. The compatibility rate climbing from roughly 40% to over 80% was not achieved by letting the agent play Russian roulette—it came from converting each failure into a reproducible semantic gap, a regression test, and a spec correction.

Building a Full-Stack Hardware/Software System with AI

The second case moves into hardware and software: sensors mounted in a soccer shoe collect acceleration, turning, running, and ball-contact data during play; a phone or sideline device receives it; and the cloud handles processing and personalized analysis.

“Build a soccer sensor” is not an actionable requirement. What actually drives engineering work are constraints: weight, size, battery life, sampling rate, transmission latency, communication range, number of concurrent devices, water and impact resistance, data integrity.

Early in a project, AI is excellent at helping software engineers build a domain map quickly: derive physical quantities from user goals, derive sensors, sampling, and computation from those physical quantities, then extend onward to communication, mobile, cloud, and machine learning. But the MCU (microcontroller), IMU (inertial measurement unit), GNSS (global navigation satellite system), BLE (Bluetooth Low Energy), and power management choices can only be treated as candidate hypotheses. The final answer must return to datasheets, reference designs, dev boards, current analyzers, RF testing, and real motion data.

A project like this must design hardware, firmware, mobile, the cloud control plane, and the data pipeline all at once. The most effective way to parallelize is not to wait for the PCB before writing the app, but to stabilize the data contract first: how device ID, session, sequence number, timestamp, sampling rate, sensor values, battery, firmware version, and quality flags are expressed; how packet loss is detected; how the two shoes and the phone are time-aligned; how the protocol evolves forward.

Before the hardware arrives, software can generate simulated data streams—normal, packet-loss, out-of-order, clock-drift, and multi-user concurrent. The Rust parsing core, the iOS session layer, the cloud ingress, and the visualization can all run against this “digital twin” first. By the time real devices connect, the system boundary is no longer entirely unknown.

Yet the most important reminder from this case is still this: AI’s output is only a verifiable engineering hypothesis. Average power consumption cannot be obtained by simple addition; a BLE nominal range is not the same as the in-field range inside a shoe and behind a human body; IMU data that looks trustworthy may contain bias, thermal drift, and clock drift. Software leans on tests; hardware ultimately leans on measurement.

Building a Long-Lived, Consistent Knowledge System

The third case is using AI to write a 400–500 page technical book. Most of us have more or less adapted to using AI for documents, blog posts, emails—one-off long-form content. But how do you build a book? The difficulty isn’t producing a fluent paragraph; it’s keeping facts, structure, terminology, and voice consistent across hundreds of thousands of words.

Book writing has many correspondences with software engineering: the reader contract is like a PRD, the book’s throughline is like system architecture, the terminology and concept contract is like an API, the knowledge graph is like a dependency graph, fact-checking and style-checking are like tests and linting, and the Typst/PDF build plus GitHub Release map to build and release.

The agent doesn’t need to “remember the whole book” in its context. The constraints that truly matter can live in the repository: each book has its own writing contract, whole-book plan, chapter plans, research materials, review records, illustrations, and build output. The writing contract specifies the target reader, the narrative stance, how formulas and analogies are used, and which phrasings count as AI-speak, translationese, or lecture-hall drone.

A chapter is not produced by a single prompt either. The more reliable pipeline is: whole-book planning, chapter planning, research questions, source compilation, first draft, technical review, structural review, style review, fact-checking, diagram production, typesetting and rendering, and final human proofreading. Separating research from writing reduces the chance that “plausible but nonexistent” facts slip into the manuscript; independent review helps surface the problem where every chapter looks fine on its own but together they have no throughline.

The real-world cost is also worth stating honestly: for a 400–600 page book, the agent work is at least about 25 hours and may consume 40%–50% of a Codex Pro weekly quota, while a human still needs roughly 5–10 hours for rough review, proofreading, and workflow optimization. AI has not turned publishing into one-click generation; it has compressed months of repetitive labor into tens of hours of agent execution, and shifted human attention to the throughline, the trade-offs, the facts, the voice, and ultimate accountability.

The Shared Method Behind All Three Projects

Rustack’s ultimate verifiers are tests, compatibility suites, and benchmarks; the wearable’s ultimate verifiers are instruments, physical units, and field data; the technical book’s ultimate verifiers are sources, reviewers, and reader comprehension. The verification methods differ, but the engineering loop is remarkably consistent:

Intent → Constraints → Specs → Task Decomposition → Agent Execution → Verification → Independent Review → Artifact & Memory.

No failure should ever be patched only ad hoc inside the current conversation. It should settle into a new test, spec, skill, or engineering rule, so the next execution starts from a higher baseline. This repository memory that keeps accumulating is the true compounding asset of AI engineering.

The Engineer’s Future in the Age of AI

The final theme of the talk pulls the lens back from projects to engineers themselves. AI doesn’t just speed up coding; it is changing the unit of software production. Teams used to measure progress in lines of code, commits, or PRs; in the future, the more meaningful unit is the “verified increment of capability”—the complete closed loop from requirements and design through implementation, testing, and runtime evidence.

That also means the development lifecycle will redistribute attention. Boilerplate, mechanical migrations, and isolated implementations will keep getting cheaper; domain modeling, architectural trade-offs, verification design, incident analysis, and accountability for user consequences will keep getting more important. Teams won’t automatically vanish because agents exist, but their topology will change: humans own direction, permissions, trade-offs, and escalation paths; different agents take on research, specs, implementation, testing, and review; real users and production environments continue to supply the final feedback.

For individuals, the moat of the future has at least four layers. The bottom layer is fluent use of models and tools; above that is system design and domain understanding; then comes verification capability and accountability; the top layer is leadership and engineering taste—knowing what is worth doing, when a result is good enough, and when you must stop and redefine the problem. The tool layer is the easiest to learn and the easiest to copy; the three layers above it are what create durable differentiation.

The talk will also lay out a concrete 30/90/365-day action framework: first pick a real, repetitive task and build context and regression tests around it; then spend 90 days completing an end-to-end project, letting failures settle into specs and skills; finally, build your own domain assets and AI engineering method, so you can lead people and agents together to deliver complex outcomes.

See You This Sunday at Tubi Meetup

If you already use Codex, Claude Code, Cursor, and the like but still feel AI can only handle scattered tasks; if you’re wondering how to get agents involved in long-running projects, cross-team collaboration, or hardware/software development; or if you care about the new responsibilities of engineering managers and architects in the AI era—come join this Tubi Meetup.

The event runs July 19, 2026 (this Sunday), 14:00–17:30. We’ll walk through all three cases in full, the unified methodology, and the “future of engineers” theme, with live demos interspersed throughout.

If you’ll be attending in person, please scan the QR code below to register on Huodongxing.

If you’d like to watch the livestream, scan the QR code below to log in to Geekbang.

This is not a talk about “getting AI to write a bit more code.” It’s a discussion about how to reorganize engineering work itself.

When implementation becomes cheap, defining the problem, establishing feedback, and judging quality are becoming an engineer’s most expensive capabilities. I look forward to seeing you at Tubi Meetup this Sunday afternoon.