AI coworkers need earned trust, reliable checks and clear goals

SUMMARY

In 30 seconds

Lauren Tan and Roman Ugarte describe AI bots that join existing work tools, handle specialized responsibilities and earn broader permissions over time. Tan’s engineering workflow lets agents run applications and produce evidence for review, backed by architecture and static checks; she says critical infrastructure may still need human oversight. Ugarte argues that faster execution shifts the bottleneck toward defining goals and keeping a coherent product experience, so the team tests important interface changes internally before shipping.

1Start with a small task and expand a bot’s responsibilitiesThe guests describe marketing, support and data bots that gain access as their owners learn what they can do.
2A shared specialist bot can carry a team’s practicesTan describes sales and engineering bots shared across colleagues, rather than a separate copy for every employee.
3Read-only access is a first step toward trustUgarte describes a data bot that answers questions in Slack using read access, before taking on broader actions.
4A Slack thread can connect product feedback to a working prototypeTan says her bot launched a cloud coding agent that returned screenshots and videos, letting colleagues iterate together in the thread.
5The smallest coding loop lets an agent run and check its own workTan distinguishes functional correctness from broader quality, including performance and resource use.
6Turn repeated review into constraints in the codebaseArchitecture, lint rules and dependency checks can catch recurring mistakes without repeated model review; sensitive changes may still require people.
7Product direction becomes a constraint when implementation speeds upThe team may fix routine bugs automatically, but Ugarte says it holds important user-interface changes for internal testing rather than shipping every idea.

Takeaways

Start with a narrow, read-only bot and expand its access as its work earns trust, Ugarte suggests.
Place shared bots where work happens, with a domain expert responsible for their role and permissions.
Teach coding agents to run the application, observe problems and iterate before automating the wider workflow.
Tan recommends encoding recurring review requirements in architecture and static checks; she keeps humans involved for sensitive changes.
Ugarte says fast implementation makes product direction and deciding what not to ship more important.

TopicsCoding agents Human-AI Collaboration Developer workflows & testing Software engineering Agent orchestration

FULL TEXT

Read the edited text by chapter

Show transcript

Transcript only

Give bots a role in existing work

The guests describe persistent AI teammates that use tools and respond to objectives. They discuss specialist and shared bots for different company functions.

The Lightcone hosts introduce Lauren Tan and Roman Ugarte as members of the team that incubated Grok Bot and took it from an initial codebase to launch in seven weeks. The product is intended to create persistent AI teammates with names, roles, skills and access to tools.

Ugarte says the idea grew from observing long-running coding agents with clear goals and tools. The team wanted something similar for non-engineers: work organized around bots rather than chats or files, with access to the tools people already use and the ability to act proactively.

He says both enthusiastic and less enthusiastic AI users responded well to the internal prototype. Users can begin with a simple task and configure the bot more deeply as they find useful work for it.

Ugarte describes a progression from a basic task to an objective and eventually a job responsibility. His marketing example gives a bot advertising accounts and a budget, then asks it to collaborate with a design bot on assets and tests.

A support bot with the right tools might reproduce issues and handle some tickets end to end. Ugarte expects domain experts to build and manage shared bots, giving them credentials and responsibilities suited to the work.

Tan uses Grok Bot as an outer loop for engineering. Instead of manually gathering context from coworkers, Slack and bug reports before starting a coding agent, she can bring bots into the thread where that context and collaboration already exist.

Bot organization depends on the person. Tan describes specialists by function or a bot dedicated to one customer across functions; she prefers a small number of broader bots with some specialists. Ugarte likes assigning each bot a problem it actively monitors.

The guests say team bots can be shared across an organization. A person with domain knowledge can build a bot and give colleagues access, spreading an automation beyond engineering into support, sales or other functions.

Tan shows a sales workflow in which shared bots research leads and handle operational steps such as quotes and deals. Instead of every employee maintaining a separate copy, the team can contribute to a shared specialist that reflects its practices.

SLIDE 1 / 5Shared bots across a sales workflowThe diagram shows account research, quote preparation and deal review as related roles.

Identity, access and collaboration remain open problems

Shared bots need to understand ownership and permissions. The guests recommend starting with limited access and increasing it as confidence grows.

Ugarte says multiplayer use introduces unresolved questions. A bot in a Slack thread may not know who owns the decision or has the right expertise; identity, authentication and authorization become product-design problems as well as model problems.

His proposed analogy is onboarding a person: give the bot a computer and credentials scoped to its role and experience, then expand access as trust grows. He calls permissioning an industry-wide question without a single settled answer.

The participants discuss bots talking to each other. Tan says one of her engineering bots can ask a data specialist for information in a visible Slack thread, allowing her to see their exchange while investigating whether a user problem is widespread.

The discussion turns to safety and the context provided to models. The guests say trust is still being established and that communication and permissions are continuing areas of work.

Ugarte describes a data bot built to answer routine questions in Slack with read-only database access. He sees this as a first step: later a bot might take actions, and eventually own a broader outcome, though he considers that last stage still distant.

Connect a Slack conversation to a coding agent

Tan shows a feature built through an extended thread with colleagues and a cloud agent. She explains the guardrails and reusable skills behind the workflow.

Asked about her path from a Slack request to a pull request, Tan shows a feature discussion involving a colleague and her bot. The bot spawned a Cursor cloud agent with a machine capable of running the application.

SLIDE 2 / 5A feature discussion shared with a coding agentTan shows a thread in which a bot starts a cloud agent and reports its proposed approach.

The agent returned prototypes, screenshots and videos to the thread. Tan says coworkers could give feedback early in a shared conversation rather than waiting for one person to build a finished proposal privately.

SLIDE 3 / 5Screenshots returned for a feature prototypeThe prototype artifacts let colleagues discuss interactive output in the same thread.

The example grew to about 200 messages, and Tan says the group completed the feature through that thread without her opening Cursor for the project. She attributes that degree of autonomy to prior investment in skills, codebase constraints and static checks.

Tan says some agents now merge their own pull requests and people review the resulting artifacts. She notes that this workflow took time to establish; it is not simply an overnight switch.

Her pstack collection packages engineering skills for agents and is available in the Cursor plugins repository. Inspired by another personal toolkit, she encourages people to adapt and combine skills to fit the way they work.

The participants discuss how visible agent work in shared Slack threads helps colleagues learn techniques from one another. Tan still keeps some personal bots outside team channels and adds engineering bots where collaboration happens.

Build the smallest useful verification loop

Tan starts by enabling an agent to run software and check its work. She uses architecture and static analysis to reduce repeated review while retaining oversight for sensitive work.

Looking ahead, Tan imagines bots with their own identities and ways to use services; the guests describe a goal of working inside existing company tools rather than rebuilding every business application. These are their product aspirations.

Ugarte contrasts software with other knowledge work. Code has tests, compilation and deployment infrastructure, and much of its context lives in a repository; other company knowledge may be scattered across people, documents and inaccessible systems.

As organizations automate more execution, he expects clearer objectives and measures to matter more. Performance in a desktop client may be measurable, while defining a meaningful marketing improvement can require more judgment.

Tan describes the smallest useful coding loop: an agent writes code, runs the application as a user would, observes issues and revises the code. Giving the agent that feedback can remove a manual step in which an engineer runs everything for it.

SLIDE 4 / 5The basic agent verification loopTan’s sketch links writing code, running it and finding problems.

She distinguishes a result that performs the requested function from good code: it may still be slow or resource-intensive. Engineers must improve the environment and checks that make better code more likely by default.

Once the inner loop works, an outer automation can respond to an alert, reproduce a problem and use those same tools to propose a fix. Tan says she also uses bots to coordinate other agents through projects.

The hosts ask how much automated review is enough when thorough review consumes large numbers of tokens. Tan says multiple-model adversarial review can help, but may overfit to feedback that misses the wider product goal or future plans.

SLIDE 5 / 5Move recurring corrections into the codebaseThe inverted pyramid prioritizes architecture and static analysis, with prose and human review as additional layers.

Her preference is to encode recurring expectations in the codebase, API design and static analysis. Rules and skills remain useful layers, while infrastructure, databases and deployment can still merit human involvement because of their sensitivity.

For example, her Electron team forbids imports across main and renderer process boundaries using a dependency checker. Tan clarifies that the check does not measure execution time; it prevents a class of heavy code from being pulled into a sensitive rendering path.

Tan says quality and speed are more attainable together after this investment, while acknowledging that her lab gives her effectively unlimited tokens. She sees her work as exploring future workflows and ways to make routine engineering more economical.

Choose what to build and what to leave alone

Ugarte says alignment on product direction becomes harder as execution accelerates. The team distinguishes maintenance from changes that reshape a user’s daily experience.

Ugarte says the team increasingly spends time agreeing on its roadmap and what good looks like. Colleagues can already produce many potential changes, but merging every side project would make the product inconsistent.

A feedback-processing bot can help find and fix small bugs automatically. By contrast, Ugarte says changes to core interface elements are tested internally for longer: moving familiar controls repeatedly can frustrate users, so ideas without strong internal acceptance are not shipped.

Tan says rapid generation does not mean shipping every possible feature. She directs much of her automated work toward maintenance, performance and user-reported bugs, leaving people more time to think about the product experience.

Tan’s route from finance into engineering

Tan explains how spreadsheet programming, a startup and public writing led to engineering opportunities. She credits communication and mentors as well as technical work.

Tan studied accounting and finance and discovered that she enjoyed building spreadsheets and Visual Basic macros. A startup with a classmate and involvement in Australia’s startup community helped her find her first technology job.

While learning to code, she wrote publicly about what she learned. Members of the Ember community invited her to speak at a conference; she credits that experience, communication skills and mentors with helping her grow as an engineer.