I didn't make it to 200 in this test match. The game is declared at 194. I shall close the updates here and start new thread for day 2. Long and mixed day.

Oh, the panel discussion postponed to tomorrow afternoon. The day ends here with some announcement. End of the day.

That was a good talk. It was still a lot of high level walkthrough yet rooted in low level impact. But also a good storytelling that moves the devs. This was the last talk of the day before the panel discussion.

Codebase health is everyone's responsibility. You need owners, drivers and torchbearers for that. Quantification is super helpful to know the problem from what to why. Preventing regression is just as important.

Chaitnya's presentation and impact metrics is very impressive. Gives you a test of enterprise metrics that are very relevant and rooted, yet dramatic. Managing high traffic codebase, developer friction and balance between building tools and using them.

With these tools, developers are paying a lot less tax. But developers wouldn't care of this scale. What matters is the CI complexity. This eventually leading to 90% fewer tests using FactsMap. Less that 50% tests for integration.

Another guardrail was to prevent the regression. But this meant a lot of the friction of the devs. Another solution for this with thunderstorm doctor.

Tools, rules and guardrails were the principles. Rules created package levels based on impact. Directional boundaries of using the package across the levels to keep the dependency in control.

Thunderstorm Migrate should do large scale compile safe refactor using codemods. Not AI. Okay. What's Codemods?

Worst of the worse of the case scenario all (P90-P70-P50) touched 139k files. There are dumping grounds like utils, types, common. And pulling large packages.

Project Thunderstorm: Downstream files per commit and Set of files that are impacted. A cli package that gives the visibility of the tax for every change.

Dense forest codebase, leading to full blown wild fire. Instead the analogy of the lake with content drop ripples.

This reminds me that SOLID principles are not really followed in enterprise codebase. Now they have payment for it this way. The codebase is really shit. Making the CI cost very very high. Very very real impact on product quality.

But FactsMap and Selective Validation was always around. But it's a very old codebase that is also massive. In reality, the dependency graph is a very convoluted/complex. Highly highly coupled and a mess.

FactsMap helps in finding only what's changed and what's the dependency graph that flags to check for selective validation.

Too much validation happening. And FactsMap, sounds like Graphify. Rust based inhouse dependency graph engine. This is not md, actual json.

CI check is the recurring node of bottleneck at every step from review, merge queue and deployment. Way too many tests, even more in agentic era.

Atlassian is apparently a very huge monorepo. Just for Jira, everyday 200 PR. And expecting 2000 PR. AI does increase the code throughput but shipping faster? not really much.

The talk is titled 'How Atlassian refused to let CI become a bottleneck for agentic engineering.'

Chaitanya Deorukhkar now from Atlassian how his own experience of the a bottleneck with agentic engineering while at Jira.

Kumar ends the talk by mentioning how the work hours stay the same some more AFK and more tasks have been cramped into the workday.

Listing a few dark sides, like prompt injection, goal hijacking etc. These days I don't much see the orchestration and multi agent flow unreliability and solutions around it.

Bijoy felt burnt out and stepped out a while back. Now Kumar moves to the Dark side of the this autonomous flow goes rogue.

He confesses but also stresses his own role in generating the 10 slide talk on agentic dev pipeline + MCP for React Nexus 2026.

Kumar has his own harness/Nexus harness. He called his agent clause. But seems like it's Sonet 5 on Pi.

Yet Kumar still flags the need of code review and security. Although hopeful now with newer models.

The autonomous dev pipeline consists of product agent, coding agents. QA agent. Reviewer Agent. Now the manual process that takes 3-4 days now takes 45 mins.

Agent Composer now looks at the reasoning, planning, reflection, retries with plan. Execute. Observe etc responsibilitoes. The MCPs keep giving the reality checks.

Kumar then talks about the breakthrough actually. Agent + MCP brain and the hands.

With collapses the trust and 50% token wastage is inferred with harness overload.

Kumar then moves to the reality check where agentic pipeline generic fails. And catastrophically. Increasing the infra cogs and increasing the build time from 2min to 47min.

The PPTs are good. Purple and emoji titled. Sloppish. Kumar moves to MCP which what, why and where. He rushed through it.

Kumar moves to talk about the evolution of AI integration. From auto complete to chat LLMs to Agentic loops. From low to medium to full agency.

A 2 hour coding task that turns into a 3 day is a developer tax, as Amit says. Where generally it takes PRD a day, design 2 hr. Implementation 2 hr. UT+IT are painful, boring & that takes 3rd hr. Build and test will take another hour. Reviews and deploys with latency another day.

Amit Panigrahi now comes in to talk about autonomous architecture from a perspective to make the agents more collaborative. He opens with an anecdote about a simple task that takes time to ship and the efficiency of that.

Kumar wishes a very long careers to everyone and hopes they can change there jobs. But I missed the specific points which low enough to be interesting like the code smells and frequent failure examples.

In general this feels again but shallow or high level approach. Kumar points to make the tasks bounded, clear context, patterns already exist and human review outputs.

Kumar summaries this as refactoring, test generation, boilerplate, code review as things that work. But struggles with architecture and edge cases. It definitely breaks the business context and ownership.

Kumar then moves on to talk about code review using agents. It find potential memory leaks and file extension issue and gives priority issues. But according to Kumar, the blind spot for AI is the business logic.

Kumar talked about a a few code smells and frequent ai failures in optimization attempts. Kumar too advocates for test cases and how generating them is easy and helpful. Mocking becomes easy.

Break ke baad now Kumar Prince on shipping React with AI coding agents: what works. What breaks. What scales. His first time and first talk at React Nexus.

Break time for 20 mins. Much needed. But this feels slower to grasp. Coffee ☕ now with Bijoy. Needed something hot.

ThunderID, a full open source RBAC for fully owned code. Apparently someone from WSO2 will doing a demo of this upcoming product.

The real gate is on the server for the data, where could have same app that creates different user classes. The token has to be single source, gate all routes, all components and all data. UI is just courtesy.

Asgaedeo is a the former name of the rebranded WSO2. It's an sdk with react hooks and tiers. It feels like this really makes the RBCA seamless to develop.

The identity platform WSO2 plug happens and says RBI is a client. Drop-in react ask. Roles built in. Enterprise grade and free.

Route. Component. Data. These are three places to enforce these conditions for the role based access control. I thought he would say: FE, BE and DBMS. But I guess these the same.

Hiding the component with if condition in the UI, but the headless endpoints could still be open. Omal says there are three places to ensure these permission.

Omal says he will talk about the authorization which is a hard problem to solve. Same app but different tiers.

Rishab finished. Now Omal Wijegunawardana from WSO2. Starts with an open question on confidence on role based access control on react application. I am embarrassed. This is a tricky question and always want to have full confidence on this, but it's always bit hopeful.

Rishab plugs Opencode, uses it in light code. But also the desktop app. Opencode also allows you set the permissions.

Rishab now shows the workflow orchestrator which are a set of .md files that has migration orchestrator, analyzer, committer, executor, gap reporter, reviser and validator.

I think this approach could be useful to crate agentic workflows: analyze. Verify. Utilize the analysis to generate the code. Confirm. Revise and commit. Use subagentic workflows for these.

This talk to feels little high level and too relevant. Slow though. Rishab also categories the skills into Discovery, Manipulation and Validation types.

Rishab has them slightly different from a skill. 1. The persona (who). 2. The context injection (the map) 3. The constraints (The guardrails). 4. Few-shot examples (the pattern). 5. Chain of Thought (the logic check)

Tests are definitely the bedrock for the migrations. Creating prompts can slow you down for migrations. More agentic workflows can be helpful. And goes to explain the five components of a prompt.

Rishab now moves to testing. Like do legacy TDD, and keep those for the modernized TDD.

The second thing needed for the context for the migration needs the business logic and meaning as well.

Ofcourse, putting everything in agent.md is not a good idea. Disturbed systems of agent.md is more efficient.

This is second plug for Graphify, after Nattu did it in the previous talk. Migrating to a framework would need a tree like structure of agent.md

Creating a context needs to be deep dived. We would do that using dependency graph. And this beyond package json. Folder by folder. Functions by functions. What does this code mean and do. We could use Graphify.

Rishab breaks that into three parts. Analysis taking 50% time. Code generation which is often 80% correct. The third part is verification to take that accuracy to 95% to 100%.

We generally are reluctant to migrate, but legacy code may have issues like security issues. Trying to do it but faster in agentic era could be helpful.

Now Rishab starting to talk about performing the large scale migrations. Or modernization with AI. He starts with his story about spotting a black panther while on a trek on foot and could his himself in time.

Nattu is done. Now another migration story using the agents by Rishab Bhattacharya. Feels good that one more talk is down. But it has lightened the urgency in general.

This is full CEO style sell of agentic era and now the product plug. Codewalnut. Free masterclass on AI coding. A product engineering company fully scared in this january and started to teach themselves the new ways in their lab. And decided to take it out for all to be shared.

Nattu plugs Radhika Menon as a pathbreaking merchant Navy ship captain who won bravery award. Hands on work: Graphify, Agent Memory, Mutliagent workflow, knowledge graphs. This is the new playbook.

Bijoy appared to be now engaged but no he is really very sleepy today since the last sessions. This talk is loud and engaging. But I can easily not worry about missing this one.

Nattu goes on a history trip. Storytelling time with wide visuals. About industrial revolution and scale and pace achieved through it. Comparing that again with agentic engineering. Tells another story with similar metaphor.

I really liked Apurv's resources. This appears to be really useful and relevant talk. Now there another sponsor talk. Codewalnut by Nattu Alagappan. A CEO talkingabout Agentic Approach in React. He is candid and sells his candidness to gain trust.

You can find Apurv's slides here: design-system-skill-slides.vercel.app/

The skill needs to be updated and be living. It shall be automatically be updating either why agents or routines. Such skills can be used to generate, fix, migrate.

The skill is actually limited to only Vision Language Models. It must be able to see. That makes this hard for a set of models though without extensions.

There is a disable-model-invocation flag that is used to not let the model auto invoke the skill and only invokes when the user uses /slash command. New nuance noted.

The reference docs in the Apurv's skills also generates, verifies and audits the workflow outputs. It also have deterministic scripts to feel the context.

Agent Skills skeleton 🩻 : SKILL.md, references, scripts, assets. I shall regularly also refer to agentskills.io. it's been a while.

Guidlines are generally the dos and donts. The model is generic, stale and blind. Our own design system is not open nor the model is trained on it.

Actually these are regular good design practices. Including the use of central variables in our style sheets. In component API, a skill can use it.

Apurv mentions three layers for such design system. Design tokens. Component API and Guidelines.

Amazon, GitHub Primer, Adobe Spectrum all have their design systems and foundation. Apurva refers to them as examples. This is cool. I shall evolve my global.css in art repo into a system through this.

Apurv is placed well post lunch. He gives a GitHub screenshot to generate a UI. But the code, although the design is perfectly rendered, its not a good system that can be maintainable and scalable. Apurv establishes the importance of design system from audience interactions.

The issue is actually getting it to follow your design system, even though it's good at following the screenshot. This is a pain point for me as well. I wish I had worried more about this problem than settled with it.

The second half is almost fifty minutes late. Apurv Khare from Procore is returning to the conference for the third time. Apurv is talking about getting the AI to actually follow your design system.

The MCs started their engagement again. I am bit worried about of the packed nature of the conference. A lot to take post lunch. The energizer appears to be about guessing a meme.

Oh, locator.js seems fun. Akshay mentioned it in his talk that it started to break after migration and I passed it. Bijoy stayed curious and digged about it. It's really cool. Click on the component in the browser to locate the code in the IDE.

The good part so far was that there did not feel much AI agents being shoved so far though. Most were rooted in engineering possibilities. The second half though feels packed with all agentic approaches.

Zoho sponsored talk could have been a tweet. The payment app presentation could have been a flowchart.

The prerendering components talk and the third middle state in component lifecycle talk could have been a small email.

I liked the TanStack Start intro. It felt fresh and motivating. Although, could easily have been available otherwise. Still.

Overall, the conference so far feels underwhelming. Hardly feels original or relevant. The keynotes are generally broad handbooks or wider picture. Often the most unoriginal. In this conference, keynote is the most fresh.

Smile's session is done. Time for lunch now I think. 30 mins break and resuming at 13:45.

Good observability and good logs have a case and being mindful about what we log and what we must not log. Payment UI is a lot more than just UI. Design for clarity. Engineer for trust.

This can be solved by checking the capabilities and then conditionally offering the options.

Someone from audience mentions that in Safari, would not allow the pop up and redirection flow do not work on some browsers webview and safari.

Oh. This is the hundredth note of the day. Bijoy says he would have loved to individual reactions to the note. But that's too much db work too. Smile is essentially walking through different Good flows in payment ux.

Always prefer Actionable Errors over vague ones. Sometimes the payment succeeds but checkout fails. They call is ghost order: payment done but order fails.

Smile says 'Something went wrong' is not a good UX and trust is at stake. Good feedback with error strategies. Telling upfront whether you were charged or not. And a nudge to alternative or possible downtime on an option.

Different providers have different token models, some API key + URL. Some redirect and have return URL. Some use multi use token. Some have just the single use token.

The edge cases is the beauty here. Auth token lifecycle when the user leaves and comes back and the flow breaks.

Flow: Frontend starts -> backend creates session -> PSP returns token or session id -> token goes to FE etc..

Different payment methods: Wallet, Cards and Single Use methods.

Smile is at Wayfair. JSlover is the community meetups. Smile also approaches towards payment from frontend perspective as well. The presentation is little too colourful and childrens book theme.

Now MCs before the new talk. Smile Gupta tells her experience of building payments. Hoping to hear more of idempotency and webhooks for better payment reliability.

Datathon 2026 with Zoho and Karnataka Police with price pool to solve real world issues of Karnataka Police. Some people I know might be interested in this. Talk over.

After a long Catalyst demo, the talk seems to go back to the title..oh, no Catalyst plug again.

Oh, the list goes on. They QuickML too and can import the dataset and can give you a model with api endpoints.

Zoho also gives authentication components. Including third party services. Also has buckets and S3 to bucket easy migration path. Has push notifications and mail service components too.

Catalyst also provides serverless for BE needs. Can also take docker images. Also cloud scale for db needs and backend as services.

Vignesh now attempts to one shot deploy the application using Catalyst with Sonet. Meanwhile walks through the platform's UI that syncs your GitHub for repos with automated framework selection and auto deploy option with build path and Install command.

Oh, this is going to be a long Catalyst plug with FE React and Nodejs BE. I don't know how this is relevant yet to the talk title.

Catalyst plug for full stack hosting from FE hosting and deployment to Object Storage to Event Bus. Like Bijoy disses, everyone now has there own AWS.

Oh, Zoho sponsor plug now. Zoho makes SaaS with 55+ apps with different tools. 150 million users with 16 data centres. That's a big scale for RD and full stack from bare metals

Apparently the time to ship has not really much changed although the time to build has shrinked. Bottleneck is shipping now, not building.

Vignesh from Zoho. Titled 'AI Solved*' coding. Vignesh is a veteran in Zoho for past 10 years. Ai doesn't decide where the app runs, where the data lives, how to autoscale, and auth.

Next is Zoho. Could be a full sponsor plug. Bijoy is unimpressed by the conference in general, thing you could anyway get over internet. I already shared that sentiment. But also seen worse. But also need now think of ways to make the best of this conf.

All of this migration for what: react compiler, less legacy debt, async in render, actions and useOptimistic (oh this plug returned), future-ready (lol, sure) and performance.

Oh, there is no single entry point during the runtime. Creating a separate build at infra level and serving them with instant rollbacks is the option. React 19 is also stricter.

Now updating to react 19. Apparently there is not escaping directly to 19 bypassing 18 because of the concurrency update. It is mostly removals and semantic changes. Agents can do large chunk.

Lol. Rollout and rollback strategies. Akshay mentions directly have if else statement in the root createRoot(el).

Asserting intermediate states may not work in tests from 17 to 18 migrations since 18 is now batching your states.

Auditing our package before updating is important, who is yet supporting and who is not. And in some cases, even replace them.

Sloppy language returns with patterns like '...worked fine...until it didn't....'. But very engaging and interactive slides. Devs can make a great use of HTML+CSS presentations.

And nuances around each of the types of updates in synchronous and concurrent modes. The render in concurrent modes breaks the rendering during user interactions like click and can be observed in our dev tools

Type errors, uts and e2e start breaking. Akshay gives a direct technical insights into such migrations. .

Updating the type first and then moving on to the real work of updating the code that takes months.

Even with the agentic approach, will have a lot uts breaking, runtime errors. Concurrent rendering was the most challenging chapter in the migrations.

Now, Akshay Ashok to talk about the migration pain with practical notes and hard earned lessons. React Upgrade at scale.

Back into the Audi, the boring engineering terms antakshari seems to have caught some momentum.

It's still a bit convoluted what problem and pain point the OpenUI really solves. But it appears to be an abstraction above the text for better and streamlined UI outputs with preferred reusability and efficiency.

OpenUI Lang saves on tokens and better than json. Although 5-10% error rates.

Use case mostly for conversational analytics as well. OpenUI is its own schema/language for efficiency.

Already at the OpenUI stall. They seem to have a SaaS or B2B for improved UI outputs by your agents. You may also generate UI at scale with pace, but that's a separate use case.

Oh, 15 min break now. Coffee and rest room time. Also, they have live picture broadcasting application? Let me check.

It's 11:16. Break please.

For example use Activity API for search and shopping card. But not for toast and tooltip (too cheap anyway). Use it for chat sidebar. Don't use for login modal (used only once anyway).

This middle state saves the struggle to recreate the users state preserving the UI memory that nobody was preserving before the Activity API.

In the sleep or background state, with mode as a props, deprioritises the re-rendering, selectively keeping a few states. Helping to stop destroying what users come back to.

Generally there could be a third middle state in the middle: background. React needed this third middle state. There were hacks arounds with states and css, but nothing was good.

Solving the unmounting crisis with css display none is not a good solution since it keeps firing the functions without the UI. React has historically coupled the visibility with existence.

Are mounting and unmounting states enough? There is nothing in between. Unmounting destroys everything, including the focus.

Piyush has brought in energy and candid drama. Feels like the personalities of the speakers were curated as a salad.

Oh, Piyush Assudani, a designer engineer is next. No break yet. He is talking about how react's activity API fixes the hidden problems.

Archana was on a straight train, full performance and speed. No breaks. I hope for a break now. But there might be one more talk.

Simple takeaways: micro-granular isolation of static and dynamic ,l, LCP Optimization, DX evolution and lighter serves.

Static Layout shell can have components specific cache life.

Also, partial prerendering is not for all. There are obvious limitations where fresh info is needed. The next evolution in Nextjs 16 on cache components.

In implementation tips, Archana mentions some best practices such as suspense boundaries, separate the dynamic and static zones, prioritise, use server components, cache expensive CMS etc.

The browser can paint the static part immediately improving the LCP and dynamic content can fill in progressively steaming in on user request.

Static Shell with header, hero, layout etc with dynamic island like inventory. Reviews and rating that can steam progressively at runtime.

This is where partial prerendering comes into picture and need. Instant paint with dynamic data. It's introducted in Nextjs 15 taking the best of both worlds.

Nextjs evolved the rendering landscape with SSR, always fresh with slow and expensive. SSG, too super fast but stale for dynamic. ISR, balance of both. (Self plug: this very page is ISR) But still rebuilds everything.

Archana starts with why rendering matters. First and foremost, noone stays on slow sites for more than 2 secs. Also google rankings depend upon that using LCP

Sorry. She is Archana Agivale. Archana says that performance is not only about how much data you send to the client but also about when you render it.

New talk started. Man, back to back things. Now Anuja on web performance using partial prerendering. Shit I wish for a break. Too much to grasp.

First two talks were so packed. Sreetam has really been inspirational for all the over engineering he has done on his personal dev site. Bijoy wants to know why he moved out of Sveltekit.

There are a few cool things to explore in TanStack Start like composite components and deffered hydration. Nextjs is battle tested but so is TanStack too.

TanStack CLI can also be used to get guidance and also library for hotkeys. TanStack Start is mentioned to be 'argent ready' first actual.mention of agentic engineering actually of the day. Quite very late. Both talks feels very rooted in engineering philosophies and dev x.

The TanStack Library keep the experience very consistent. We can also render the server components inside the loader?

Also, the streaming SSR with shell now. There are also server functions on build time to build once and serve.static data. One route but many choices we get.

Also, the middleware across boundary with client() and server() contexts. And rendering is considered as a dial with full SSR, dataonly SSR, client only and per route. Travelled from Sveltekit actually.

Route own the entire data contract, the loader data is cashed. The really cool thing though is the server functions, beyond regular HTTP endpoints. A static json function file is being sent from server whenever called for?

Plug for Typescript. How much it helps. But also, types become the new thing to manage. 'type-fest' package gets a plug too. With App Router it helps a bit. But TanStack Start really takes care of the types. Also, URL state belongs to the route.

Sreetam's preference for Vite pushed into TanStack before Nextjs had it's Turbopack fixed. TanStack Start was also fully open, and framework agnostic. And client first by default.

Oh, Sreetam also tried Sveltekit. Vite. Remix as well. Nextjs never used Vite, stayed on Turbopack and it improved too eventually.

Now that it's a server first framework, 'use client', serialisation props, composition footgun. Also, now the cashing too is something we must keep thinking about.

Sreetam's motivation to move away from Nextjs to Cloudfare was the possibility of bills. That's the biggest and most common and very relatable motivation. This is once again motivating me to try TanStack

He plugs sreetamdas.com stated in 2021, tried to plug in everything he could. Started with plain HTML CSS, React SPA, Nextjs pages router, Cloudflare and TanStack Start.

Too much boring plug trying to quirkily sell his company's product: remote hiring. Uses Elixir, at the backend. So nitche.

Sreetam believe TanStack Start is the best way to create fullstack. I guess he is making a case through his own personal dev site moving from Nextjs to TanStack.

The next session is by Sreetam Das on React with Server without compromise. Making a case for trh TanStack Start.

Tapas ends his talk now making a plug about his book 'React Clean Code Rule Book'.

The reason why this is happening is due to user demands.

The biggest change in the React is not it's features. The bigger picture now focuses on where your application is running. The shift is that now it's running server, moving away from client.

Today, there nothing called global state. Things have changed. No complex lifecycle is needed to be talked about. Suspense is used widely. Move towards Server State and edge based architecture.

Tapas now takes a case study of the eBook selling site. Client UI triggerong Nextjs App Router to Razorpay, Supabase and Vercel Blob (PDF). Entirety handled with React.

Irrespective of what framework you choose among these three, any framework works. But recommending TanStack for founding teams. For New teams, Nextjs is recommended because a lot of things come out of box. The paradigm shift in React from Client to Server essential enables this.

Router level routers in all three frameworks, server first mutation, streaming SSR, hydration optimization all are present in all frameworks under different names, React is becoming the framework enabling all of this in backend.

Nextjs was pioneer App Router Mental Model. Actually defined the vocabulary for all.

Framework bloodbath: Nextjs, React Router v7, and TanStack Start. All of them solve similar and same problems.

Moving to edge, made up for the roundstrip from serverside. useOptimistic hook is a good example of such mental model and philosophy.

There are handful of dynosores in the audi who started react in 2013. From 2015, something that started as a client heavy library, through 2020 hooks era, today it's serverside platform.

Around 2018, 1.2mg avarage js bundle and sequencial network waterfall was invested for better data orchestration. The talk really feels humane, informative. Far removed from sloppy feels.

Someone is calling Tapas on his comp during a live presentation. Lol. The continues to talk about the complexity crisis in the single page dash with SEO, and almost zero loading time.

It didn't care about backend. Slowly, through years, pushing through constraints for innovations for fullstack: routing, fetching etc.

Tapas now walking through the history since 2013. Had single responsibility to manage state for UI rendering on the final DOM. That's all.

I like Tapas's flow. Saving personal intro for NOT the beginning of the talk. A serial community founder all on React and YouTuber.

Tapas says React is evolving ever and always something to learn. It has long stopped just being UI library. Now streaming. Server side rending, serverside components.

Oh, this is a first time his talk was accepted. Hello applied every single time and only this time his talk is accepted. Now a keynote this year.

Okay. MCing is done now. Keynote time by Tapas Adhikari who apparently speaks at every React Nexus, this time talking about how React is becoming a platform.

The dramas and rehearsed jokes are okay. The auditorium too feels almost occupied by now. Would have loved to have these jokes and drama spread out throughout the day.

MCs call out the overpresense of the AI topics in the schedule. And try to make a case for the irreplaceablity of the engineers.

Except for the Zoho, I have never heard of other sponsors like Code Walnut or imagekit.io or others. Only Zoho descrip got a serverless service pitch.

The new generation of MCs are keeping the presentation very scriptedly candid. Engaging intros, although sloppy. It's hard to appreciate copywriting these days.

The conference started really on time. The MCs have really well rehearsed beginning. The auditorium is still filling.