Something remarkable happened in February of 2026. With the release of Anthropic’s LLM model Opus 2.6 and OpenAI’s ChatGPT 5.3, LLMs became dramatically better at coding – to the point they could start pumping out decent code at a rapid pace with guidance and validation by human developers.

These releases were accompanied by much fanfare about “agentic” coding, which could either mean LLM’s with access to command line tools that gave them the ability to manipulate and interoperate with other applications, or LLMs that could be set up like a team of human developers to run competitively and autonomously.

At the same time, the massive layoffs that had been occurring over the previous 2 years at Microsoft, Meta, and Amazon accelerated. While in previous years this was explained as a correction after a period of over-hiring since 2020 due to low interest rates, in 2026 this was explained as an attempt to free up cash to spend on data centers for LLM model training and LLM inference.

I’m not deep into the principles of AI, myself. I just work as a software developer on AR and VR projects who occasionally plays with GenAI tools like ComfyUI and the various coding tools. But LLMs, since February, have rapidly taken over the world of software development.

And it occurred to me that I need to document this as the transformation is underway. Having spent the past decade in touch interfaces, AR and VR headsets, and depth cameras, I’ve noticed how quickly something new can become old and then commonplace, while we loose a sense of what our lived experience was like before, take your choice: smartphones, turn-by-turn car maps, podcasts, social media, 4Chan, Tumblr, the Musk buyout of Twitter. This can be bad, since if we don’t remember how things were before these technologies came along, we will have trouble seeing how they change the way that we think about the world.

It’s been four months since LLMs really broke out in the field of coding. This led to a massive influx of cash and hype into Anthropic and OpenAI as the prepare for IPOs this year. Generally, the public statements of companies preparing for IPOs about their capabilities and potential are inherently untrustworthy. This isn’t helped by the fact that the way both companies have tended to market their prowess is by emphasizing how potentially dangerous they are for the future of humanity – on the notion that something that can kill all of humanity can also save it?

In June of 2026 there does seem to be a bit of a blowback. This can be seen by the prevalence of articles actually talking about an AI “blowback”. Companies like Uber and Microsoft are cutting back on their API expenditure on tools like Anthropic Claude and OpenAI Codex, after initially encouraging their internal developers to spend what they needed to improve internal software and learn the tools.

I don’t think this is due to  any sort of recognition of an incapacity in the AI tools so much as a problem with scaling up its use. A lot of money, for instance, has probably been wasted trying to get non-tech office workers to use these LLMs to manage their emails and time. That sort of enforced AI use has created a lot of resentment and suspicion that by using AI in these ways, you are simply training your replacement. While in coding-focused roles, it has been a problem of acceptance and disseminating knowledge about how to use LLMs effectively to write or co-write code.

Over the past four months, there has also been a lot of hand-wringing about what LLMs can and cannot do. There has been a rise in software developers emphasizing that they are “senior” developers along with a discourse about the qualities of a “senior” developer – about to get along with others (senior developers have people skills, dammit), intuition about how to put code together, knowledge of how to properly “architect” code in a potentially pragmatic manner. These explanations are also usually accompanied by concern over the fate of “junior” developers, and hand-wringing that without junior developers we’ll never have future senior developers.

It feels like a bit of a slight of hand. By showing concern for “junior” developers, developers with jobs get to distance themselves from another group they are basically saying can be replaced by LLMs, which making a case for why their roles should be inviolate. Part of what is fascinating about this is that pre-2026 and going back 20 years, “senior” developers typically described themselves as being 10x solo devs who knew the intricacies of certain software languages or microservices or TDD so well that other devs would simply slow them down. But no longer.

It also feels like an attempt to head off another inevitable question. Why should companies pay senior developers so much when a decent LLM for $200/mo can give junior developers 10x coding kung-fu powers?

Back to the blowback. Microsoft Co-pilot is not transforming the business world and is instead creating a lot of resentment and frustration. Graduating classes over the past month have been boo-ing commencement addresses that give basically good advice about how this generation of students needs to adapt to and master the new technology. The Trump DOD has taken an adversarial position against Anthropic, which insisted that they wouldn’t allow their tech to be used to blindly target civilians, while the Trump administration has reversed its laissez-faire stance on AI and recently forced Anthropic to take down its two newest frontier models, Fable 5 and Mythos.

It is worth pointing out that one of the most sweeping cultural effects of LLMs at the moment is the disruption of the mechanism for posting and applying for jobs. People are using LLMs to rewrite their resumes to fit job postings while HR departments and recruiters are using LLMs to draft their job postings and then evaluate submitted resumes for those jobs. The general effect is overload on all sides. Every job hunter is applying to hundreds of jobs, most of which they are not qualified for, while companies are turning away a lot of people that actually are good fits for open positions because there is no great way to differentiate the slop from the gold. LLMs appear to have made the job market not only inefficient but potentially dysfunctional.

All of which makes the most valuable person in the current job market a junior developer with good LLM coding knowledge with personal connections at a company looking for software developers. Everyone else has good reason to sweat because LLMs really are pretty decent coders, and its hard to know what we are going to do with this knowledge.

Mark Pincus founded Zynga—the company behind Words With Friends, FarmVille, and Zynga Poker—and has arguably created more hit consumer products than anyone in history. At Zynga, eight of 10 major game launches became massive hits, reaching over a billion players. Over the past five years, Mark has been synthesizing everything he’s learned about building successful consumer products and turning it into a book, Life at the Speed of Play, which comes out on June 23. This is the first interview he’s done about the book.

In our in-depth conversation, we discuss:

1. His “Proven, Better, New” framework: copy what’s proven, make it better so that 10 out of 10 people say “f*ck yes, I’ll use this”—then add something new

2. Why being less ambitious is the path to the most ambitious ideas

3. His rule of thumb that your instincts are right 95% of the time, but your ideas are wrong 75% of the time

4. “Kill hope before hope kills you”

5. How to raise kids in the age of AI

—

Brought to you by:

WorkOS—Make your app enterprise-ready, with SSO, SCIM, RBAC, and more

Vanta—Automate compliance, manage risk, and accelerate trust with AI

—

Episode transcript: https://www.lennysnewsletter.com/p/the-common-pattern-behind-successful

—

Archive of all Lenny's Podcast transcripts: https://www.dropbox.com/scl/fo/yxi4s2w998p1gvtpu4193/AMdNPR8AOw0lMklwtnC0TrQ?rlkey=j06x0nipoti519e0xgm23zsn9&st=ahz0fj11&dl=0

—

Where to find Mark Pincus:

• X: https://x.com/markpinc

• LinkedIn: https://www.linkedin.com/in/markpincus

• Website: https://www.lifeatthespeedofplay.com

—

Where to find Lenny:

• Newsletter: https://www.lennysnewsletter.com

• X: https://twitter.com/lennysan

• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/

—

In this episode, we cover:

(00:00) Introduction to Mark Pincus

(02:46) The Proven Better New framework overview

(07:29) Earning the right to innovate

(08:30) What “better” really means

(12:03) Quick summary of the framework

(12:40) Examples of the framework in action

(13:30) How to use proven correctly on your platform

(15:13) The moral arbitrage of copying

(23:55) Be less ambitious

(28:25) The Bolt.new story and staying humble

(33:15) Kill hope before hope kills you

(37:00) Using AI as a failure machine

(40:08) Why Zynga’s games succeeded (it wasn’t virality)

(48:36) The future of consumer social apps

(57:05) How to know if your product is a B+

(1:01:25) Distribution in the age of AI

(1:15:39) Make everyone a CEO

(1:18:18) Stay close to the metal

(1:21:35) Why Mark says micromanagement is beautiful

(1:23:35) The expert witness

(1:25:05) The number one job of a CEO is to be right

(1:26:35) What Mark is teaching his five kids

(1:35:14) Mark’s “why”

(1:37:08) Mark’s new book: Life at The Speed of Play

—

Referenced:

• Tribe.net: https://en.wikipedia.org/wiki/Tribe.net

• Zynga: https://www.zynga.com

• Sid Meier: https://en.wikipedia.org/wiki/Sid_Meier

• Electronic Arts: https://www.ea.com

• CityVille: https://en.wikipedia.org/wiki/CityVille

• Words With Friends: https://wordswithfriends.com/

• Scrabble: https://playscrabble.com

• Reddit: https://www.reddit.com

• TED Radio Hour, MIT Media Lab founder, 1984 TED talk.: https://www.ted.com/talks/nicholas_negroponte_5_predictions_from_1984

• Peter Thiel on LinkedIn: https://www.linkedin.com/in/peterthiel

• FarmVille: https://en.wikipedia.org/wiki/FarmVille

• Craig Newmark: https://en.wikipedia.org/wiki/Craig_Newmark

• How to consistently go viral: Nikita Bier’s playbook for winning at consumer apps (co-founder of TBH, Gas, advisor, investor): https://www.lennysnewsletter.com/p/how-to-consistently-go-viral-nikita-bier

• Angry Birds: https://www.angrybirds.com/

• OMGPop: https://en.wikipedia.org/wiki/OMGPop

• Draw Something: https://en.wikipedia.org/wiki/Draw_Something

• Slack founder: Mental models for building products people love ft. Stewart Butterfield: https://www.lennysnewsletter.com/p/slack-founder-stewart-butterfield

• Brian Chesky’s new playbook: https://www.lennysnewsletter.com/p/brian-cheskys-contrarian-approach

• Garry Tan on LinkedIn: https://www.linkedin.com/in/garrytan

• Brian Armstrong on LinkedIn: https://www.linkedin.com/in/barmstrong

• Jason Citron on X: https://x.com/jasoncitron

• Stanislav Vishnevskiy on LinkedIn: https://www.linkedin.com/in/svishnevskiy

• Jeff Bezos on X: https://x.com/JeffBezos

• Andy Jassy on X: https://x.com/ajassy

• Niantic: https://nianticlabs.com

• Pokémon Go: https://pokemongo.com

• Bing Gordon on LinkedIn: https://www.linkedin.com/in/binggordon

—

Recommended book:

• Life at the Speed of Play: Launch Products People Love!: https://www.amazon.com/Life-Speed-Play-Launch-Products/dp/0063352575/ref=tmm_hrd_swatch_0

—

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.

—

Lenny may be an investor in the companies discussed.

In part 3 we looked at creating the researcher. As promised, today we’ll look at the author.

You’ll notice in the following code a great deal of similarity to what we’ve seen before. The goal is to create a code “template” that we can follow as we create any agent; departing only for the agent’s special requirements and abilities.

As usual, we start with the factory method:

def create_author_chain():
    """Creates the author chain."""
    def author_invoke(state):
        research = state.get("research_findings", [])
        research_text = "\n\n".join(research) if research else "No research available."

        prompt = author_prompt_template.format(
            main_task=state.get("main_task", ""),
            research_findings=research_text,
            draft=state.get("draft", ""),
            review_notes=state.get("review_notes", "")
        )

        try:
            response = llm.invoke(prompt)
            content = response.content if hasattr(response, 'content') else str(response)
            return content if content else "Draft in progress..."
        except Exception as e:
            print(f"Author error: {e}")
            return "Error generating draft. Please try again."

    return author_invoke

# Creating a callable object
author_chain = create_author_chain()

We start by getting the research findings as a collection. We join all the entries into a single text string, or if there are no findings, we create the string “No research available.”

A local variable, prompt, is created from the author_prompt_template and passed to the invoke method of the LLM. The local variable content will contain the metadata or just the response from the LLM if there is no metadata.

The structure, so far, is identical to what we’ve seen before.

Next, we create the author_prompt_template used above,

author_prompt_template = """
You are a professional blogger.

Main Task: {main_task}

Research Findings:
{research_findings}

Current Draft: {draft}

Review Notes: {review_notes}

Instructions:
- If this is the first draft (no current draft), create a comprehensive post based on the findings
- If there is a current draft and review notes, revise the draft to address all feedback
- Use professional tone
- Make the post consise (aim for 250-500 words)

Write the complete post now:
"""

This is pretty self-explanatory. The interpolation variables (e.g., {draft}) will be filled in when the create_author_chain runs.

Finally, we create the author_node,

def author_node(state: ResearchState) -> dict:
    """Author node that creates or revises draft."""
    print("\n>>>Author")

    draft = author_chain(state)
    print(f"Draft created: {len(draft)} characters")

    return {
        "draft": draft,
        "revision_number": state.get("revision_number", 0) + 1
    }

Reviewer

The reviewer follows the same pattern, so we might as well look at it here. We start with the factory

def create_reviewer_chain():
    """Creates the reviewer chain."""
    def reviewer_invoke(state):
        draft = state.get("draft", "")
        revision_num = state.get("revision_number", 0)

        if len(draft.strip()) < 100:
            return "APPROVED - Draft is minimal but acceptable."

        if revision_num >= 4:
            return "APPROVED - Maximum revisions reached. The report is satisfactory."

        prompt = reviewer_prompt_template.format(
            main_task=state.get("main_task", ""),
            draft=draft
        )

        try:
            response = llm.invoke(prompt)
            content = response.content if hasattr(response, 'content') else str(response)
            return content if content else "APPROVED"
        except Exception as e:
            print(f"Review error: {e}")
            return "APPROVED - Error in review, proceeding with current draft."

    return reviewer_invoke

# Creating a callable object
reviewer_chain = create_reviewer_chain()

The reviewer will either approve the draft or kick it back directly to the author for revision. The only other part here is creating the node for the reviewer.

def reviewer_node(state: ResearchState) -> dict:
    """Node that reviews the draft."""
    print("\n>>REVIEWER")

    review = reviewer_chain(state)
    print(f"Review: {review[:100]}...")

    is_approved = "APPROVED" in review.upper()

    if is_approved:
        print("✓ Draft APPROVED")
        return {
            "review_notes": "APPROVED",
            "next_step": "END"
        }
    else:
        print("✗ Revisions needed")
        return {
            "review_notes": review,
            "next_step": "author"
        }

In the next post we’ll finally see how the nodes are used in creating a workflow.

Now that Microsoft.UI.Reactor and the project templates are on NuGet.org, getting started is a LOT simpler than it used to be.

If you want the absolute shortest path to a running app, it's really just this (assuming you already installed the .NET SDK):

dotnet new install Microsoft.UI.Reactor.ProjectTemplates
dotnet new reactorapp
dotnet run -a x64

That's it!

So let's take a quick look at what those three commands actually do, and more importantly what kind of app Reactor generates for you.

Creating the app

The first command installs the template:

dotnet new install Microsoft.UI.Reactor.ProjectTemplates

You only need to do this the first time.

Next:

dotnet new reactorapp

If you run that in an empty folder, the template uses the folder name as the project name and drops the generated files right there.

And finally:

dotnet run -a x64

That builds and launches the app with the x64 architecture, which is generally the right thing to do for a WinUI desktop app (if you are on ARM64 you can use arm64 instead).

If you prefer creating the app in a named folder instead, you can also do:

dotnet new reactorapp -n MyFirstReactorApp
cd MyFirstReactorApp
dotnet run -a x64

Project Contents

One of the nice things about the template is that it stays very small. You're not dropped into a huge starter app with a lot of moving parts. The interesting bits are basically just:

- App.cs
- <ProjectName>.csproj

And honestly, that's a pretty good first impression for Reactor, because the whole point is that your UI is just C# code.

Let's start with App.cs

The generated app looks like this:

using System;
using Microsoft.UI.Reactor;
using Microsoft.UI.Reactor.Core;
using Microsoft.UI.Reactor.Layout;
using Microsoft.UI.Xaml;
using Microsoft.UI.Xaml.Controls;
using static Microsoft.UI.Reactor.Factories;

ReactorApp.Run<App>("MyFirstReactorApp", width: 900, height: 600);

class App : Component
{
  public override Element Render()
  {
    var (name, setName) = UseState("World");

    var titleBar = TitleBar("MyFirstReactorApp").Flex(shrink: 0);

    var body = Border(
      FlexColumn(
        Heading($"Hello, {name}!"),
        TextBox(name, setName, placeholderText: "Your name")
           .AutomationName("NameInput")
      ) with { RowGap = 16 }
    ).Padding(24).Flex(grow: 1, basis: 0);

    return FlexColumn(titleBar, body)
        .Backdrop(BackdropKind.Mica);
    }
}

This is pretty simple, but at the same time there's actually a lot going on here, so let's break down the basics.
The very first interesting line is this one:

ReactorApp.Run<App>("MyFirstReactorApp", width: 900, height: 600);

This is the app bootstrap. Reactor opens the window, hosts the app, and renders your root component. If you're used to XAML app startup plumbing, this is refreshingly simple.

Then we get to the App component itself:

class App : Component
{
    public override Element Render()

The Render methods are the key to Reactor. You don't create a window and start mutating controls. Instead you render an element tree that describes what the UI should look like right now, and it returns a light-weight description of the UI - not the UI objects themselves.

The next line is probably the most important one in the whole sample, and if you're coming from XAML probably the most unfamiliar one:

var (name, setName) = UseState("World");

UseState is one of many "hooks" you'll find in Reactor. You have some state. You render UI from that state. Events update the state. Reactor re-renders and patches the native WinUI controls in place.

The sample keeps this super simple: the initial value is `"World"`, so the heading renders as:

Heading($"Hello, {name}!")

which means the app starts out showing `Hello, World!` using a Textblock with the Heading style. The "Heading" is merely a simple short-cut for creating a TextBlock with the style preset, to keep your code simple and concise. There are a bunch of these short-hand statements like HStack and VStack for Horizontal and Vertical StackPanels.

Then the text box wires straight into that same state:

TextBox(name, setName, placeholderText: "Your name")

This is a nice little detail because it immediately shows the controlled-input model. As you type into the text box, `setName` gets called, the component renders again, and the heading updates live.

So type `Reactor`, and the heading becomes `Hello, Reactor!`.

That's a tiny app, sure, but it's also the whole Reactor loop in one screen.

The rest of the file is mostly layout and presentation.

var titleBar = TitleBar("MyFirstReactorApp").Flex(shrink: 0);

gives you a title bar, while:

FlexColumn(...)
Border(...).Padding(24)

build up the body using ordinary C# composition instead of XAML markup.

And finally:

.Backdrop(BackdropKind.Mica);

adds a Mica backdrop so the sample already feels like a proper Windows app.

That last part is worth calling out: Reactor isn't drawing some fake custom UI surface. It's building real WinUI UI under the covers.

The project file is small too

The generated project file is also pretty lean:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows10.0.22621.0</TargetFramework>
    <Platforms>ARM64;X86;X64</Platforms>
    <UseWinUI>true</UseWinUI>
    <WindowsPackageType>None</WindowsPackageType>
    <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="..." />
    <PackageReference Include="Microsoft.UI.Reactor" Version="..." />
  </ItemGroup>
</Project>

Again, nothing wild here, and that's a good thing.

UseWinUI makes this a WinUI project, WindowsPackageType is set to None so you start with an unpackaged desktop app, and Microsoft.UI.Reactor just comes in as a normal NuGet package.

That's really the big story here: Reactor now feels like a regular part of the .NET ecosystem. Install a template, create a project, run it. Edit it in Visual Studio, VS Code, or just Notepad for a bit of personal torture. Or have your favorite agent iterate on it. Because everything is code, you're more likely to get compile time errors instead of XAML runtime errors which really helps with both your and an agent's inner dev-loop.

What you get when it runs

When the app starts up, you get a small native desktop window with a title bar, a greeting, and a text box asking for your name.

Type in the box, and the heading updates immediately.

That might not s- ound like much, but it's actually a very good first sample because it teaches the right thing right away: the UI is a function of state.

No XAML. No view models. No binding setup. Just state in, UI out.

A lot of starter templates try too hard to impress you. They throw in navigation, settings pages, MVVM layers, mock data, half a dozen folders, and a bunch of code you're supposed to delete later.

This one doesn't.

It gives you one component, one piece of state, one layout, and one interaction. Just enough to understand the model, and not so much that you have to reverse engineer the template before you can start building your own app.

And that's probably exactly what a first Reactor app should be.

Where to next?

If you want learn more start with the Build 2026 presentation which covers a lot of the basics:

- Building WinUI Apps with C# First Patterns and AI Assisted Workflows

Next check out the official Reactor Documentation, but I'd like to call out a few key pages to study:

• Reactor for XAML developers
• Hooks - A key concept in Reactor apps

Next go study the samples. Here are a few I found interesting:

• Reactor Gallery - Lots of great samples in one big demo app. Run this app and study each sample.
• Validation Showcase - Great example of how to do even intricate input validation with very little code.
• Reactor IDE - A Visual-Studio style app demonstrating docking/draggable windows.
• Particle Storm - High-performance particle rendering using Win2D.