14 lessons from Silicon Valley in 2026

From October 6 to 9, we traveled through San Francisco and different cities in the Bay Area on the NewHack mission. We visited companies, walked around Stanford, explored spaces for building and spoke with people making decisions amid the changes brought about by artificial intelligence. The records, photos and available reading are on the mission page.

A queue of tasks generated by agents, energy equipment developed in a garage and a conversation about alumni networks may seem unrelated. Over the week, they began to connect. In each case, technical capability needed to find a problem, a relationship of trust and a path to real use.

I organized these lessons from our conversations and observations, adding my own perspective on how to apply this experience in Brazil. Some ideas appeared in more than one meeting. That repetition was one of the most useful parts of the trip: it let us compare the same principle across organizations of different sizes and markets.

1. Opportunity begins with the question the market stopped asking

At Brex, the conversation returned to the difficulty foreign founders faced in obtaining corporate credit in the United States, even when their companies had funds. The account revealed an opportunity created by questioning the reference used to assess that customer. The existing model's shortcomings came before the choice of technology.

This reasoning resurfaced when we discussed AI products. Starting with a chatbot can narrow the investigation too early. First, there is a person trying to solve something, a step that does not work and an assumption about the customer that may be wrong. Automating that step without reviewing it can make the problem circulate faster.

For a Brazilian startup, I would start with cases in which a customer with a legitimate need gives up, waits too long or has to work around the process. What is the company assuming about them? What evidence is missing? The opportunity may lie in changing a rule, a reference or a way of delivering, and only then choosing the right technology.

2. With AI, attention and judgment become more valuable

One example from the conversation at Brex stayed with me: agents find problems and add them to a task queue faster than people can review them. Automation increased detection, but the organization still needed to decide what mattered and finish the work. The volume produced could become a new attention debt.

At Netflix, the AI discussion also led to the ability to review, compare alternatives and choose. Generating more code, analyses or versions of an experience expands the possibilities. The company needs to be able to assess those possibilities against a clear objective.

This changes the metric I would want to track. Beyond the time taken to produce a first response, the time until a deliverable is accepted and used matters. Waiting for approval, rework and corrections are part of that calculation. A team becomes more productive when it can complete what matters to the customer more effectively.

3. Prototyping has become more accessible. Learning from a prototype requires a method

The visit to Replit and the conversation on our final afternoon in San Francisco put software development at the center of the journey. At Replit, education, examples and support for the first experience emerged as ways to bring more people into building. Free Mode came into this conversation about lowering the barrier to exploring an idea. Its limits and costs need to be checked in the product; initial access does not cover every aspect of running an application.

The most interesting effect of this change is shortening the path between a hypothesis and something another person can try. A founder can move beyond an abstract discussion and put a workflow in front of a customer. The quality of that encounter depends on observing use: where the person gets stuck, what information is missing and whether they reach the expected result.

I would use this speed to test a small question. Then I would check data persistence, permissions, failures and maintenance before expanding use. A demonstration helps us learn. Turning it into a recurring operation adds responsibilities that need to be part of the decision.

4. The unit of cost may differ from the unit of value

At Agora.io, we discussed voice infrastructure and experiences with agents. A company may consume services by the minute, call or model usage, while its customer wants a confirmed appointment, a resolved support request or a completed registration step. That difference helps explain why a good demonstration still needs a business model.

Cost per minute describes one part of the operation. Perceived value depends on the entire journey. One conversation may be quick and solve nothing. Another may require corrections, several attempts and a handoff to a person. Latency, interruptions and the ability to understand a change in intent affect both the experience and the bill.

Before setting a price or expanding a pilot, it is useful to measure the cost of a task completed to a good standard. That calculation includes infrastructure, integration, retries and review. The pricing approach should follow the business; the discipline is to keep both the unit that generates cost and the outcome the customer values visible.

5. Distribution is part of building the product

Our meeting with Nicolas Camara of Firecrawl brought distribution through developers into a conversation that began with infrastructure. An API can be part of many applications without being visible to the end user. Its discovery and adoption depend on the person building, the problem that person has encountered and how easily they can reach a first useful integration.

The company's public history helps explain that closeness: Firecrawl grew out of work on Mendable, when obtaining and organizing web content proved to be a recurring problem. In September 2026, the company announced Alexandria and a US$75 million Series B round. The round provides context for that moment, but the lesson I take concerns the relationship between a clearly defined problem, the person facing it and how the solution reaches them.

Documentation, examples, technical content, meetups and Developer Relations can all be part of that path. For entrepreneurs, I would design distribution alongside the first experience: who finds the product, in what context, what task they try to perform and what help they receive until they succeed. Tracking integration and return usage teaches us more about adoption than looking only at a launch's exposure.

6. Community grows stronger through recurring exchange

At Replit, community work was connected to teaching, listening to users and helping builders learn from one another. At AGI House, in Hillsborough, proximity among people building AI showed another way to bring experience and opportunities together. These are different experiences, connected by the possibility that a conversation can continue as a project, a contribution or a new question.

The visit to Google and the conversation with Martin Lima of Cubo Itaú at Plug and Play added another layer: funds, partners and communities can connect a technology to companies that already have a need. The relationship gains substance when the person making the connection understands both sides. Curation and continuity help turn a meeting into collaboration.

In my view, a community needs to give people a reason to return even before they buy. Learning, receiving feedback, sharing work and helping someone are concrete reasons. At NewHack, I want to use this principle to connect content, gatherings and programs. The sign of quality is what people become able to do together, supported by clear rules and care for those taking part.

7. Culture shows up in who can decide and the context they receive

During the Netflix visit, culture was one of the topics that helped connect autonomy and responsibility. The company's official document emphasizes context, informed decisions and people responsible for leading them. The idea is compelling because it poses a practical question for leaders: does the team have enough information to decide?

At Google, the tour of Bay View brought another dimension. Spaces for concentration, interaction and joint work make certain exchanges easier. For a small team, the lesson lies in the routine it wants to create. A product discussion and a task requiring concentration may need different conditions.

To apply this, I would choose a reversible decision and make the objective, owner, limits and review point explicit. Autonomy becomes more concrete when people know what they can resolve and when they need to involve another area. It is also useful to observe time spent waiting for authorization and rework caused by a lack of alignment. Culture can be assessed in that daily routine.

8. Reinvention requires preserving capabilities and reviewing delivery

The visit to Adobe brought the perspective of a company that has lived through more than four decades of change. Its history spans publishing and digital creation, the subscription model and the arrival of generative AI in its products. Each move changed parts of the experience, operations and route to market.

What interests me in this story is how an accumulated capability can find a new way to serve customers. Understanding creative professionals, their workflows and their requirements remains relevant as tools change. At the same time, the company needs to review what it delivers, how it charges and how it demonstrates usefulness in a new setting.

For a startup, this perspective helps prevent the business from becoming tied to the first solution it created. It is useful to separate the problem being addressed from the current implementation. If a new technology has changed costs or customer expectations, which knowledge still helps and which choices need to be made again? That review also extends to messaging, channels and marketing.

9. Context and memory can become operational assets

At Pear VC's office in San Francisco, we met Hexagon and Milo. The proposal discussed brings an assistant closer to the context of the team's emails, meetings, files and decisions. The underlying problem is familiar: information exists, but it needs to be reconstructed every time someone is about to act.

Useful memory needs to preserve relationships. Who decided? Why? Under what conditions? Is the decision still valid? A request for a meeting, for example, does not confirm an appointment. Commercial intent does not confirm a contract. Retrieving a sentence without those distinctions can produce a convincing response and an inappropriate action.

I would begin with an important routine and record the source, owner, execution conditions and evidence of completion. This improves the team's work and creates a more useful foundation for AI. When the system begins suggesting or performing actions, keeping context current, permissions and ways to correct mistakes also become part of the product.

10. Relationships and experience help you start. The new business still needs to learn

The walk around Stanford, including our meeting with Giselle at the Law School, created space to discuss study, admissions and everyday campus life. Later, at the Hexagon meeting, alumni networks and the experience of second-time entrepreneurs emerged as resources for building a company. Spending time together creates references and relationships that can continue after university.

Previous experience can help someone recognize problems, build a team and start a conversation. It can also carry assumptions that no longer describe today's customer or market. When launching a new product, including after a period of development in private, attention needs to turn into use, feedback and learning.

The conversation with Martin at Plug and Play reinforced the importance of approaching a relationship with something useful to offer. For a Brazilian founder, knowing an industry, explaining how their customers buy or presenting a local need can add depth to the first contact. I would distinguish the capabilities I can reuse, the relationships I can cultivate and the hypotheses I need to test again.

11. AI also needs to learn to act in the physical world

At Circuit Launch, in Mountain View, the conversation covered robotics, data and Physical AI, artificial intelligence applied to systems that perceive and act in the physical environment. A simple example made the challenge understandable: shaking hands involves distance, force and adjustment to contact. Describing the gesture in text does not provide all the experience needed to perform it.

When a system acts on a machine or object, other assessment conditions emerge. Lighting, the position of a part, a person's movement, a lost connection and recovery from an incomplete attempt can change the outcome. A controlled demonstration offers initial evidence; operation requires understanding variation in the environment.

For Brazil, this perspective opens up questions in industrial production, logistics, agriculture and other sectors with physical problems. Each opportunity needs to be defined with people who understand the operation. I would start with one task, measuring successful attempts, interventions and failures, and include the recovery path in the test. The result needs to make sense under the conditions in which it will be used.

12. A hackathon can start a company. Continuity builds the business

At ElectricFish, in San Carlos, we learned about a story that began at a hackathon and continued in a garage. The initial collaboration developed into work on an energy solution. The journey added engineering, manufacturing, technical requirements, partners and questions about deployment.

This connects with an important part of my own experience with hackathons: bringing people and challenges together can open paths that had not yet been mapped out. ElectricFish's story makes the subsequent work visible. The team kept going, revised its proposal and sought the conditions to bring what it was building into real use.

For those organizing innovation programs, I would follow that bridge after the final presentation. Which teams continue? Which hypothesis will be tested? Who can contribute knowledge, access or an initial pilot? There is also a question for the founder: what is missing between the prototype we can show and the product someone can operate and maintain?

13. The right resource needs to match the uncertainty still to be reduced

The conversation at ElectricFish covered grants, support programs and development milestones. At Pear VC, the context brought capital closer to company building. These meetings help us look at resources more precisely: a startup may need research, trials, access to facilities, specialized knowledge, customers or money to expand an operation.

A grant can support a defined technical objective and usually comes with criteria, milestones and obligations. A program may offer relationships and structure. An investment involves a different relationship with risk, equity and growth. These possibilities require their own assessment; what worked for one company does not establish eligibility or conditions for another.

The lesson is to map the next piece of evidence needed and then look for a suitable resource. Building a prototype, manufacturing consistently, installing it at a customer and proving use are distinct milestones. When that difference is clear, the team can formulate its request better, estimate the work required and assess whether a partner brings the business closer to the next stage.

14. Learning becomes richer when the group turns it into a decision

At Plug and Play, we held a debriefing round to share what each person had noticed. The same meeting led to different questions about education, recruitment, legal services, the automotive market and corporate environments. Hearing these perspectives expanded what any participant could have recorded alone.

This was one of the most important lessons for me. A trip gains depth when there is room to reflect on what happened. Someone working in a regulated organization sees deployment constraints another person may miss. Someone serving small businesses may recognize a need that has not yet surfaced in a discussion of a global platform.

On returning, I would choose a few hypotheses to investigate in Brazil. For each one: what problem do we want to solve, which observation from the mission prompted the idea, what changes in our context and what test can inform a decision? An owner, a deadline and a review criterion help bring that experience into operations.

I leave these four days with more specific questions about what we want to build. The combination of technology, culture, relationships and distribution appeared in very different companies and environments. For NewHack, this experience connects with our work of bringing founders, specialists and companies together and creating conditions for those connections to continue through learning and execution.

The next step is to bring this work into everyday practice: choose a hypothesis, speak with the people facing the problem and test it carefully. The full stories and photos from the mission are open to anyone who wants to explore the meetings in more depth or return to one of these questions.