The cash register that shouldn’t have won

In the 1970s, National Cash Register made the best electro-mechanical cash register in the world. The brand was a century old. The product was excellent. The sales force was everywhere. And then a much smaller company called Data Terminal Systems built a computerized register, and inside a few years NCR’s position collapsed.

Here is the part that matters. DTS did not win by selling a cheaper version of the same machine. It won by selling a different machine, one that did things the electro-mechanical register fundamentally could not do, and in doing so it created demand that had not existed before. The customer did not walk in asking for a computer at the checkout counter. DTS showed them they wanted one.

This is the case McKinsey partner Richard Foster opens with in Innovation: The Attacker’s Advantage (1986), and even though the work is four decades old, it is the right place to start a conversation about generative AI and the brokerage business, because the lesson is almost always misread. Incumbents do not lose to a discount. They lose to a better product that serves a need the market had not yet learned to ask for.

I think that is exactly what is about to happen in commercial real estate brokerage. But to see why, you have to throw out the version of the AI story that everyone is telling.

The S-curve, read correctly

Foster’s framework is the S-curve. Plot cumulative investment in a technology against what it produces. Early on you spend a lot for almost nothing. Then the curve goes exponential: each incremental dollar buys a large incremental return. Finally you hit the plateau, where the technology approaches its limit and more investment buys less and less.

Foster’s thesis is that companies which stay on a maturing curve too long get displaced by an attacker who jumps to the successor curve, the one with a higher ceiling. By the time the incumbent recognizes the discontinuity, the attacker is already climbing the steep middle while the incumbent is grinding away at the flat top of an exhausted technology. The advantage is structural. It does not come from working harder.

And here is the line in Foster that everyone skips. He argues that the CEO’s primary job should shift from efficiency-seeking to competitiveness-seeking. The successor curve’s advantage is not that it does the old thing cheaper. It is that it does a new thing the old curve could never reach. The ceiling is higher because the product is different, not because the cost is lower.

Why efficiency is the wrong perspective in brokerage

Most of what gets written about AI in brokerage is a cost story. The pitch is that a small team with the right software stack can produce the same offering memorandum, the same broker’s opinion of value, the same market report, with a fraction of the analysts. Henry AI markets on collapsing twenty hours a week of deck production. VTS reports ninety-three percent time savings on proposals. Savills, pointing its data at an OpenAI partnership, claimed brokers hitting ten times their old output. The numbers are real and they are impressive.

They are also, by themselves, a competitive dead end.

Brokerage is not a business with a fat cost structure waiting to be arbitraged. “Back of house” labor is a relatively small share of the economics, and the part that matters most, the producing broker, is generally paid through commission. That means the largest cost is already variable and already matched to revenue: when a deal closes, the cost of the person who closed it scales with the fee. There is no heavy fixed-cost back office whose reduction hands you a significant competitive edge. Cut the analyst hours and you have saved something real, but you have saved it once.

Worse, you have saved something your competitor can save too. The majors are not standing still, and all have spun up some form of AI initiative, at least on paper. If the entire generative AI story in brokerage is “the same deliverable, produced cheaper,” then the incumbents win, because they have the brand, the balance sheet, the errors-and-omissions coverage, and the relationships, and they will absorb the tools and keep their seat. A cost advantage that the other side can copy is not a sustainable advantage.

So the right question is not how to produce the old product for less. It is what new product the technology now makes possible.

A product that looks like the client’s business

Think about what a brokerage actually sells the client today. Market surveys. Comparable transactions. A financial analysis of a lease or a sale. This is the stock-in-trade, and they have two important features. First, they reflect the broker’s view of the market, not the client’s view of its own business. Second, every major firm produces essentially the same thing. It is a commodity, and it sits squarely on the plateau of the old curve. CoStar can add dashboards for another decade and the deliverable does not change in kind. It gets marginally faster and marginally prettier and remains the same product.

Generative AI makes a genuinely different product possible, and the difference is not speed. It is integration across disciplines. The new deliverable stitches together things that used to live in separate silos and separate professions: the client’s financials, its hiring and headcount signals, its operational footprint, its capital plans, its portfolio, and the market around it, into a single piece of analysis that reflects the client’s own business back to it more clearly than the client’s internal teams can see it themselves. It does not wait for the client to articulate a need. It surfaces the need.

These are capabilities that live only on the successor curve. A traditional stack parses structured fields. The new tools read two hundred leases in free text and extract terms no parser was built to anticipate. They synthesize a company’s earnings calls, its filings, the news, and the market data into one narrative. They answer counterfactuals the old systems cannot touch: what does our occupancy cost look like if we consolidate three offices, what happens to our portfolio if we exit downtown, where does our own hiring plan say we will be short of space in eighteen months. No amount of additional investment in the legacy survey-and-financial-analysis product gets you there, because the problem requires a kind of reasoning the old curve does not possess.

That last point answers the obvious objection. You might assert that the legacy stack only *looks* exhausted because the industry stopped innovating and investing in it a long time ago. Then you could argue that these firms could still be in the exponential part of the curve, but have chosen not to invest further.

But the way you settle the argument is to name capabilities the old product cannot reach at any reasonable level of spend, and the cross-disciplinary, client-specific reasoning above is exactly that. This is structural displacement, not a self-fulfilling forecast. The new product does something the old one cannot, full stop.

Why the incumbents won’t build it

If this product is so obviously better, why won’t JLL or CBRE simply build it first? This is the question Clayton Christensen spent a career answering in The Innovator’s Dilemma (1997), and his answer is uncomfortable: they will not build it because they are well managed, not because they are badly managed.

A large firm allocates resources toward the articulated demand of its largest, most profitable clients. That is good management, and it works beautifully for what Christensen calls “sustaining” innovation. It is also precisely what blinds the firm to a latent need in a segment it does not value. The new product I described is, at first, most valuable to clients the majors find marginally profitable to serve, in deals below the economic floor where a full-service firm can justify a custom, cross-disciplinary effort. The rational manager inside the incumbent cannot build a case for it. The market looks too small, the margin too thin, the need too undefined. So the firm cedes the ground, every time, for reasons that look correct on the spreadsheet.

Christensen’s deeper point is that markets like this cannot be analyzed in advance because they do not yet exist. They have to be discovered through fast, cheap, and flexible attempts. The incumbent is built to predict and execute. The attacker is built to discover. Those are different organizations with different reflexes, and you cannot easily turn one into the other.

You can watch the dilemma operate in real time. JLL Spark, the firm’s venture arm, looks for companies and products that will be useful to JLL’s existing client base. That sounds prudent, and it is exactly the trap Christensen describes. It is an engine pointed at what current clients already want, which is the one place disruption never comes from. The disruptive opportunity sits in a different value network, serving a need today’s clients have not voiced, and the incumbent’s own logic steers it away from precisely that.

The modern DTS

So who is the attacker? Not a single firm, and not, despite the funding headlines, the proptech platforms themselves, CoStar, Henry AI, Dealpath, Sytes, qbiq, Crexi, CompStak: these are the picks and shovels. They are necessary, and they are available to everyone, which means owning a subscription is not a strategy.

The attacker is the experienced-broker startup, and the reason is a variable that both Foster and Christensen leave out, because it does not show up in their case studies. In brokerage, the client relationship moves with the senior broker, not the firm. Morgan Stanley is the client of a particular broker, not of the institution on the broker’s business card. When five or ten senior people leave a top-three firm together, the relationships leave with them.

That is the modern DTS. A small group of senior brokers who own their books, organized from day one around the AI stack, building the new cross-disciplinary product and aiming it at the clients and the deal sizes the majors will not economically serve. They establish density in that underserved segment, they refine the product where the stakes are lower, and then they climb up-market as the advantage compounds, which is Christensen’s new-market disruption run by the book. Foster would add that the cleanest path often runs through a hybrid: keep the traditional sourcing and relationship work that already works, and run the new product underneath it, the way ships carried both sail and steam before they trusted steam alone.

Is there a way for legacy brokerages to counter this threat? The answer is yes and it’s contained inside The Innovator’s Dilemma. Spin off teams within the firm with deep client relationships, engineering support, and the freedom to go after the smaller, early-adopter clients. This group will not meet margin goals, initially. The cost of developing a new product in an entrenched industry, for smaller more sophisticated clients, will make the exercise seem unattractive to current management. But that experiment will help find the future of brokerage.

Another reason that legacy management will be slow to make this change is a misunderstanding of the S-curve, and it is reinforced by the way the business press keeps score. The early data coming out of places like McKinsey and MIT shows that adoption of AI is already exponential, with surveys putting it north of ninety percent of businesses, while measured productivity is still nearly flat. Federal Reserve research in early 2026 put the economy-wide lift around 1.3 percent. The Penn Wharton Budget Model does not see the steep part of the curve until the early 2030s.

MIT’s Project NANDA turned that same gap into a headline: ninety-five percent of enterprise generative AI pilots, it reported, deliver no measurable impact on profit and loss. Interpreted in terms of Foster and Christensen, that is not a failure rate. It is a measurement mirage. The report judges a successor technology by a six-month-to-two-year return standard, the same standard that would have branded electricity a failure when it first entered factories, where productivity barely moved until managers reorganized the work around the electric motor. The return was always going to lag the adoption, because the return is the steep middle, and we are still on the early part of the curve.

Two things hiding inside that same gap are easy to miss and matter a lot. The first is the pile of small wins: a finance team that closes the month in days instead of weeks, an analyst who drafts from something instead of from nothing. None of it shows up on an earnings slide, and all of it compounds. The second is the shadow workforce. More than ninety percent of employees already use AI at work even though fewer than half of their employers pay for it. That is not a governance problem to be stamped out. It is the market telling you where the unarticulated demand already lives, which is exactly the signal Christensen says the incumbent’s formal processes are built to filter out and the attacker is built to find.

So the gap between exponential adoption and flat output is not evidence against the thesis. It supports it. The steep middle waits on the complementary work: redesigning the practice, building the new product, reorganizing around it. The incumbent will find it hard to prioritize that work, because it means dismantling the very deliverable it sells today, and because its own scorecard keeps insisting the technology has not paid off. The startup does it on day one, because it has nothing to dismantle and no scorecard telling it to stop.

This is the third leaf of a pattern worth naming. The end of software displaces the software vendors. The great data reckoning displaces the dashboard and BI vendors. And this displaces the full-service broker, by the same mechanism each time: a successor curve replaces a commodity product with a genuinely better one, and the incumbent’s own economics keep it from following.

NCR had the better brand and the better balance sheet, and none of it mattered, because DTS was not selling a cheaper register. It was selling a different one. The brokerage version of that machine is being built right now, and the window, by the Penn Wharton timing, is roughly five to seven years. It is open today.

A few things I am confident about, and one I am not:

1. The cost story is a trap. If your whole AI plan is to do the old work with fewer people, the majors will out-absorb you.

2. The product story is the opening. Integrate data across disciplines into something that reflects the client’s business better than the client can, and you are selling on the new curve.

3. The attacker is people, not platforms. The senior broker who owns the relationship and commits to the new product is the structural threat. The software is just the engine.

4. What I cannot yet tell you is the date. Nobody can. The honest position, straight out of Christensen, is to plan for learning rather than prediction, conserve enough runway to be wrong twice, and start before the curve makes it obvious.

---

Bibliography

Baek, David Sehyeon. “What MIT’s Project NANDA Got Wrong: The Real Story of Generative AI in Business Is More Complicated and More Promising.” LinkedIn, September 5, 2025. https://www.linkedin.com/pulse/what-mits-project-nanda-got-wrong-real-story-generative-baek-skeqc/

Christensen, Clayton M. “Exploring the Limits of the Technology S-Curve. Part I: Component Technologies.” Production and Operations Management 1, no. 4 (1992): 334–357.

Christensen, Clayton M. *The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail*. Boston: Harvard Business School Press, 1997.

Federal Reserve. Research on generative AI and labor productivity, April 2026.

Foster, Richard N. Innovation: The Attacker’s Advantage. New York: Summit Books, 1986.

McKinsey & Company. “Where AI Creates Value (and Where It Doesn’t).” 2026.

MIT Project NANDA. *The GenAI Divide: State of AI in Business 2025*. Massachusetts Institute of Technology, July 2025.

Penn Wharton Budget Model. Projections on AI’s contribution to labor productivity growth. University of Pennsylvania, 2026.

Reis, Joe. “2028: The Great Data Reckoning.” *Substack*, February 24, 2026. https://joereis.substack.com/p/2028-the-great-data-reckoning

There are three posts in this series on beginning with Claude Code for real estate professionals, although the first two are really for anyone who wants to find a direct route the the most powerful way to interact with Claude.

The first post is for people with little or no programming experience who want to get to work with Claude Code; the path to that lies through the Unix Terminal. The goal of the first article is to show that this path quickly gets one to interacting with Claude Code, which can then provide a path to scripting, skills, projects, and even application development.

Here is the link:

Where to Begin with Claude Code, For Real Estate Professionals (Part 1)

The second post is for those who have had some experience with programming, and who have either used or would like to use an integrated development environment (IDE) with Claude. As in the first post, this one provides the minimum set of skills and steps necessary to get up and running, and like the first the goal is to get far enough to be able to work together with Claude to learn and experiment. It’s a little more challenging.

The link:

Where to Begin with Claude Code, For Real Estate Professionals (Part 2)

The final post in the series gives a sense of what could be accomplished by real estate analysts, consultants, brokers, investors--you name it--with these new and radically different tools.

The link:

Where to Begin with Claude Code, For Real Estate Professionals (Part 3)

I hope you enjoy the tour!

I have built several of these myself, and you can read about them on my website:

https://haikupartners.com

I. Introduction

“When you come to a fork in the road, take it.” --Yogi Berra

A lot of what I’m going to say in these three posts (Parts 1-3) has to do with something about which I feel strongly. If you want to use Claude, then you should find a way to use Claude Code. Everything else, in my opinionated opinion, is a distraction created to get the most people into the Claude tent as possible. Claude CoWork, for example, is a distraction. Claude projects and skills that are created through Claude Desktop are distractions. If you disagree with this based on experience or other bias, skip these posts.

So how can one make the leap into Claude Code? There seem to me to be two ways.

The first question you need to ask yourself is, am I now or have I ever been a programmer? If the answer is yes, then the next question is: have I ever used an integrated development environment? If the answer to either of these is yes, then skip to Part 2; If the answer is no, then this post would be the place to start.

If you choose either path (or even if you choose neither) you can take a look at Part 3 for thoughts about real estate and the what can be done with Claude Code.

II. Arriving at the Terminal

It is possible (and maybe even optimal) to use Claude Code directly from a terminal, and this section will provide as simple of an explanation as Claude and I could come up with for people who haven’t used a terminal interface before to learn how to use one with Claude. Since I am a Mac user, that will be what we explain; however I’m sure that there are direct analogs to everything in the Windows world. And if you are on Linux, you are almost certaiinly facile with the terminal already.

So how can you get started on using a terminal? First of all you need to conquer your fear. If you have used graphical user interfaces your entire time on a computer, the idea of jumping into Unix-land and its character-only terminal might seem like a giant leap backwards, or at least sideways. But since you have undoubtedly using ChatGPT or Claude or another chat interface (or you wouldn’t have read this far) then you are already halfway there. Terminal is just a chatbot that never graduated from middle school.

So in order to figure out how to use Claude Code and the Terminal, I asked Claude for a plan: here is what we came up with:

Phase 1: What You’re Building Toward

Claude Code is a CLI tool (Command Line Interface), meaning you interact with it by typing in a terminal window, not clicking in a GUI. Once launched, it opens a conversational dialog where you can ask it to write, edit, explain, or run code in plain English. That dialog is where you’re headed.

Phase 2: Get a Better Terminal — iTerm2

macOS has a built-in terminal (which someone in marketing decided should be named “Terminal”) but iTerm2 is vastly better: more readable, more configurable, and what most Mac power users run.

• Go to iterm2.com → Download → drag to Applications

• That’s it. Open it like any app.

Phase 3: Install Homebrew (The Mac Package Manager)

Homebrew is the standard way to install developer tools on Mac. Think of it as an App Store for command-line software. You’ll use it once here, and it pays dividends forever.

Open Terminal (or iTerm2) and paste this single line:

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

The installer will walk you through the rest. Takes 2–5 minutes.

Phase 4: What License/Plan Do You Need

(Author’s note: Claude insisted that I include this section).

You can’t use Claude Code for free — access is tied to Anthropic’s paid plans or the API. You have several paths:

Recommendation for a new player: Start with Claude Pro ($20/month). For regular Claude Code users, a Claude Max subscription is likely the more economical option long-term, but starting with ~$20 in API credits or a Pro plan to test your typical workflows first is sensible. You almost certainly have a Claude.ai account if you got this far. Pro is the upgrade from there.

Phase 5: Install Claude Code (The Simple Way)

There is now a native installer — this is the easiest path for a newcomer. To install the native binary, run:

curl -fsSL https://claude.ai/install.sh | bash

Paste that into iTerm2 and press Enter. Done.

Verify it worked:

claude --version

You should see a version number.

Phase 6: Authenticate

Navigate to any folder. Here is where there is both similarity to your Mac finder, and some differences. With any Terminal you need to “cd” or “change directory” to do what you would do with clicks in Finder. Let’s assume that you want to go to your Desktop; you would use cd to get there, and then fire up claude by typing--you guessed it--claude:

cd ~/Desktop
claude

The first time you run it, a browser window opens and you log in with your Anthropic account. If you have a Claude Pro/Max subscription, select that option. No API key is needed and your subscription covers usage.

After that, you’re in the Claude Code dialog. You’re there.

The Minimal Terminal Commands You Need to Know

You only need about five commands to get started:

That’s genuinely the minimum. Once you’re in the Claude dialog, you’re talking to Claude in plain English and can ask it to explain anything you don’t understand or need to do.

Extremely Important!!!

Claude has something called “plan mode.” You invoke it by asking Claude politiely to enter plan mode. Then you tell it what you want to plan out, and it will coach you through all the steps interactively, asking good questions all along the way. This is an expert tip that is equally valuable for non-experts.

Here are some additional resources if you like to read.

Resources for Learning

• Official docs: docs.anthropic.com/en/docs/claude-code/overview

• Terminal basics: Apple’s own “Terminal User Guide” (search in Safari) is surprisingly good for absolute beginners

• Practical shortcut: Once you’re in the Claude Code dialog, just ask Claude itself — “what terminal command do I use to navigate to my Documents folder?” It will tell you.

The Full Sequence, Compressed

1. Install iTerm2 via iterm2.com

2. Install Homebrew (one-line paste in terminal)

3. Upgrade to Claude Pro at claude.ai if you haven’t

4. Run curl -fsSL https://claude.ai/install.sh | bash to install Claude Code

5. Run claude --version to confirm

6. Run cd ~/Desktop then claude to launch

7. Authenticate via the browser window that opens

8. Start talking to it; be nice

The whole thing from zero to first dialog is probably 30–45 minutes, most of which is waiting for installs.

If you liked this post and are feeling ambitious, you can take a look at Part 2 coming soon. It’s more technical and not for everyone, so If you want to see how this might apply to you as a real estate professional, take a look at Part 3: “Claude Code and Real Estate--Some ideas.”

I. Introduction

If you read Part 1, you can skip this section since it repeats.

A lot of what I’m going to say in these three posts has to do with something about which I feel strongly: if you want to use Claude, then you should find a way to use Claude Code. Everything else, in my opinionated opinion, is a distraction to get the most people into the Claude tent as possible. Claude CoWork, for example, is a distraction. Claude projects and skills created through Claude Desktop are distractions. If you disagree with this based on experience or other bias, skip this article.

If you arrived here, I assume that you have written code before, and if you have there is a good chance that you have used an integrated development environment, since they have been around for decades. If you have, then this will serve as a refresher. If not then it is a minimal introduction to something useful and cool.

When you make it to the end of this post, you can head to the third part of this trilogy.

II. IDE for Thee

Here’s the intermediate-level guide. As mentioned in the intro, this assumes that you have written some code at some point, and ideally have used an integrated development environment (IDE). These environments are highly recommended versus just using the terminal since they bundle together all the tools you need in one interface. This includes a text editor, a built in terminal, and lots of plugins to do things like create and maintain a GIT repository.

Note that this section also includes setting up Python. But don’t worry: no pythons will be harmed in using this section! In fact you don’t need to know any Python programming in order to create sophisticated Python programs. It is a language that many novices and hackers find easiest to learn and use, but it’s not necessary to understand it at all: Claude does. If anything goes wonky, just copy and paste the error or screenshot the screen, feed it back into Claude and say “WTF”. Actually it’s more polite to say “I received the following error; can you help?”

If you aren’t sure about how you feel about this idea, take my word for it that you are going to be using one of these IDE things sooner or later..unless you throw up your hands and slink back to Claude CoWork (no shame).

Choosing Your IDE: VS Code vs. Cursor

Both are excellent and nearly identical to set up. The honest difference:

VS Code is the industry standard, free, from Microsoft, with the largest extension ecosystem. Claude Code has an official extension for it with full support.

Cursor is a VS Code fork built specifically around AI coding — it has its own AI features baked in (tab completions, inline edits) on top of Claude Code. It costs $20/month for the Pro tier but many developers find the combined experience worth it. Cursor is built on VS Code but thinks like an AI product first and an editor second.

Recommendation: Start with VS Code since it’s free and officially supported. You can always migrate to Cursor later and your settings transfer automatically.

Phase 1: Install Homebrew (If You Haven’t Already)

Everything else flows from this. Open your terminal (or iTerm2) and run:

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

Homebrew is a package manager for macOS--think of it as an unofficial App Store for developer tools and command-line software that Apple doesn’t ship with the operating system. When you need to install something like Python, Node.js, Git, or hundreds of other tools, Homebrew handles the downloading, installing, and updating for you with a single terminal command (brew install python, for example). Without it, you’d have to hunt down installers manually, manage them yourself, and handle updates one by one. Homebrew also manages dependencies. If the tool you’re installing requires other software to run, Homebrew installs those automatically too. It’s become the de facto standard for Mac developer setups, to the point that most installation guides simply assume you have it.

Phase 2: Install VS Code

Option A — Direct download (simplest): Go to code.visualstudio.com → Download for Mac → drag to Applications.

Option B — Via Homebrew:

brew install --cask visual-studio-code

After installing, do one critical step: open VS Code, press Cmd+Shift+P, type Shell Command: Install 'code' command in PATH, and run it. This lets you type code . in any terminal to open that folder in VS Code — essential for the workflow below.

Phase 3: Get Familiar with the VS Code Layout

Before anything else, orient yourself:

The most important keyboard shortcut to memorize immediately: Cmd+Shift+P opens the Command Palette — it’s VS Code’s universal search for every feature and command. When in doubt, open it and type what you want.

Opening the integrated terminal is how you’ll run Claude Code without leaving the editor:

• Cmd+` (backtick) toggles it open and closed

• Or: View menu → Terminal

• You’ll see a real terminal panel appear at the bottom of VS Code

Phase 4: Install Claude Code

Same as the beginner guide — this is done in the terminal (either iTerm2 or VS Code’s built-in terminal, both work):

curl -fsSL https://claude.ai/install.sh | bash

Verify:

claude --version

Phase 5: Install the Claude Code VS Code Extension

This gives you a graphical panel inside VS Code so you’re not just using the terminal:

1. Press Cmd+Shift+X to open the Extensions panel

2. Search for “Claude Code”

3. Install the one from Anthropic (verified publisher)

4. Once installed, click the Spark icon in the left sidebar to open the Claude Code sessions list, or click the Spark icon in the editor toolbar (top-right corner of the editor) for quick access.

The extension includes the CLI, which you can also access from VS Code’s integrated terminal for advanced features. The extension and CLI share the same conversation history.

Note on Cursor: The extension also works with Cursor. However, automatic detection can be unreliable — if the extension doesn’t auto-connect in Cursor, you may need to install it manually via the VSIX file. VS Code is smoother for exactly this reason.

Phase 6: License / Subscription

(Author’s Note: Claude strongly suggested that I include this here as well as above).

Same answer as the Terminal guide — Claude Pro ($20/month) is the right starting point. You authenticate via browser OAuth, no API key management needed.

Phase 7: Install Python

macOS comes with a very old Python. You want a current version. Via Homebrew:

brew install python

Verify:

python3 --version

You should see Python 3.12 or 3.13 or later.

Phase 8: Set Up Your First Python Project with Claude

This is where things get exciting. Here’s the complete workflow:

Step 1: Create a project folder

mkdir ~/Projects/my-first-project
cd ~/Projects/my-first-project

Step 2: Open it in VS Code

code .

VS Code opens with that folder as your workspace.

Step 3: Open the integrated terminal (Cmd+`)

Step 4: Launch Claude Code

claude

Authenticate via browser if prompted.

Step 5: Ask Claude to scaffold a Python project

Here’s a good first prompt — be specific about what you want:

Set up a Python project for me from scratch. I want:
- A virtual environment using venv
- A clean folder structure with src/ and tests/ directories
- A requirements.txt file
- A simple “hello world” script to verify everything works
- A .gitignore appropriate for Python
​
Walk me through what you’re creating and why.

Claude will create all of this, explain each piece, and you can watch it happen in real time in your file explorer sidebar. If you don’t know anything about .gitignore or venv, ask Claude.

Step 6: Activate the virtual environment Claude creates

Claude will tell you to run something like:

source venv/bin/activate

You’ll see (venv) appear in your terminal prompt, indicating you’re now inside the isolated Python environment.

Key VS Code Features to Learn Alongside This

Python extension: Install the Python extension from Microsoft (same Extensions panel, search “Python”). This gives you syntax highlighting, auto-complete, and the ability to run Python files with a play button.

Inline diffs: When Claude edits files, you see real-time diffs (difference files) as highlighted changes showing what Claude wants to add. You maintain full control; accept or reject each change, although at the beginning you will mostly be just accepting everything and riding along with Claude.

Plan Mode: This is extremely important and bears being said again: before asking Claude to do anything complex, type /plan in the Claude dialog first. In Plan Mode, Claude can only read and think; it cannot write, modify, or execute anything. It’s forced to think first. This is invaluable because you see exactly what Claude intends to do before it does it.

Minimal Terminal Commands for This Workflow

The Workflow in Practice

Once you’re set up, your daily loop looks like this:

1. Open VS Code → your project folder

2. **Cmd+** to open terminal → source venv/bin/activate`

3. Click the Spark icon or **Cmd+** → claude` to open Claude Code

4. Type what you want in plain English — Claude reads your files, makes changes, and shows you diffs to accept or reject

5. Run your code in the terminal to test it

You’re essentially pair-programming: Claude is doing the typing while you’re doing the thinking and reviewing. Ask it to explain anything it does that you don’t understand; that’s more than half of the learning value right there.

If you are on a long plane ride and need something to help you sleep, here are some resources to consult:

Resources

• Official VS Code docs: code.visualstudio.com/docs — the “Get Started” section is genuinely excellent

• Claude Code in VS Code official docs: code.claude.com/docs/en/vs-code

• Python virtual environments: the official Python docs on venv are clear and short

• When stuck: ask Claude Code itself — “explain what a virtual environment is and why I need one” is a completely valid thing to ask mid-session

I hope that this has whetted your appetite to do some downloading and experimenting. Remember that about a year ago few people knew anything about what today would look like, and so your not behind! The key is trial an error and more trial and more errors; except now you have a partner to get you back on track and compliment you obsequiously, while never getting tired or irritable or bored.

If you want some ideas about using this for real estate, check out Part 3 “Claude Code aned Real Estate--Some Ideas.” It’s short and--I hope--motivating!

Real Estate, Finally

What can you make with Claude Code and the tools described in Part 1 and Part 2? The answer, of course, is anything. There are probably projects that you are working on right now--from the mundane to the sophisticated--that you can apply these levers to.

However, that’s not that helpful for getting started. One thing you might try is looking at the haikupartners.com website, which has several articles about real estate projects that we worked on in Claude Code and Python. They won’t provide step-by-step guides like this, but they might trigger some ideas for things to try. For example, one piece discusses how to apply a type of math from bond finance that has application to real estate portfolios. Another maps out an agentic approach to extracting and analyzing data from a public data source (the Bureau of Labor Statistics). One describes (for the math-people) the relative merits of stable distributions versus the normal distribution for the forecasting of headcount growth.

If these don’t whet your appetite, then here are some other ideas:

1. Drive the creation of Excel spreadsheets for discounted cash flow analysis of lease economics through Claude. No more up-arrow-equals-sum-open-parenthesis nonsense. Use Python to drive the model and produce better graphics than Excel could imagine in Bellevue’s wildest imagination.

2. Create a business intelligence front end for your clients that’s completely flexible and interactive and that you can control as their needs evolve. Make it work in real time so that you can use it in pitches and client meetings; the future of data is “right now” not “let me work on that and get back to you.”

3. Build a RAG server (description of this coming soon; watch haikupartners.com) that allows you to query proposals, counter-proposals, commission agreements, exclusive agreements, and leases. Use it to get insight across deals your team or company have in the works to make you a better negotiator.

4. Build a market rent forecasting system that’s more sophisticated than running a linear regression through CoStar data.

5. Build a warehouse of lease or sales comparables on top of a “real” database (like Supabase) that you can refine and build on over your career.

6. Construct a personal CRM that does exactly what you want and doesn’t have the complexity and rigidity of commercial products or the one your company uses.

And so on. Get together with your smartest peers and ask “if we could have anything in terms of data or process automation, what would it be?” Then go ask Claude and give it a try. Let’s finish with a recent interview with Sam Altman (sorry Anthropic) in which he mapped out the factors that will create success over the next few years:

• Master the meta skill of learning how to learn.

• Be adaptable and resilient to change.

• Figure out what people want, and create useful products and services for them.

Here’s the link, hat tip to StockMarket_News:

The Data Is Out There

When you think of government data, what words cross your mind? Complex, boring, and useless might be three of them. And yet, the Bureau of Labor Statistics employs more than 2,000 people who assiduously gather information of great importance to real estate (among other professions), an undertaking that the private sector could never justify or execute.

The Bureau of Labor Statistics publishes employment data for every county in America, every quarter, broken down by industry, ownership type, and wage level. It’s called the Quarterly Census of Employment and Wages — the QCEW — and it is, without exaggeration, one of the richest publicly available datasets for anyone trying to understand local economies.

It’s also free. But it’s not fun. Or at least it wasn’t until the current incarnation of agentic AI, which can encapsulate the complexity of the BLS data structures and make it easy to do something unthinkable a few years ago: have a friendly and informative chat with data.

If you’re an office broker in Manhattan–or any major market–your business depends on understanding where employment is growing, which sectors are hiring, and whether the trajectory is up or down. The QCEW has all of this — roughly 2,000 records per quarter for Manhattan alone, organized by NAICS industry codes at multiple levels of granularity, broken out by federal, state, local government, and private sector ownership. Three and a half years of this data gives you about 28,000 records. Enough to see real trends. Enough to make real decisions.

How can agentic AI make something simple out of something that has previously been genuinely painful: getting this data into a form that is usable? And how could one use this information without having to understand schemas and queries and things like SQL. Hop on board and I will take you on a brief tour of the Agentic Pipeline Express™, a journey (I hope) that will interest the data nerds without boring the people just interested in better data decisions.

But first..

We need to get some background on the nature of the data. All non-data nerds can safely skip this next section (start reading again at Asking Questions of Your Data).

The BLS provides its data through an Open Data Access API that delivers CSV files with quirky field structures. Quarterly extracts have different field layouts from annual files. You need to know FIPS codes (Manhattan is 36061, if you’re wondering). You need to handle missing quarters, rate limits, connection timeouts, and the occasional data quality issue. And once you’ve downloaded the data, you need somewhere to put it and something to query it with.

This is the kind of problem that’s perfectly suited for an AI agent. Not because it’s intellectually difficult — it’s not — but because it involves a long chain of steps, each with its own potential failure modes, that need to be orchestrated intelligently. That’s exactly what I built.

Why an Agent, Not a Script

The traditional approach to this kind of data pipeline is an ETL script: Extract, Transform, Load. You write a Python program that downloads the CSV, parses it, cleans it, and inserts it into a database. This works fine until something goes wrong. And something always goes wrong.

The BLS API returns an unexpected response. A quarter is missing. The connection drops mid-download. A field that was populated last quarter is empty this quarter. In a traditional ETL pipeline, every one of these scenarios requires explicit handling. The code gets longer. The edge cases multiply. The whole thing becomes brittle in exactly the way that matters most — it breaks when you’re not watching and need the data for a meeting tomorrow.

The agentic approach is fundamentally different. Instead of writing code that handles every scenario, you give an AI agent a set of tools and a goal. The agent uses Claude, via the Anthropic API, to reason about what to do. It checks what data already exists in the database. It identifies which quarters are missing. It plans an extraction strategy. It handles errors not by following a predetermined script but by assessing the situation and deciding what to do next.

The comparison with the ETL pipeline is stark. ETL might be faster and cheaper. But the agent approach is adaptive, self-documenting, and dramatically easier to extend. When adding a new data source, one doesn’t rewrite the pipeline. One gives the agent a new tool.

Building the Pipeline

Let me walk through the major functional areas of the system, because the architecture tells a story about how to think about data extraction more generally. Here are the major steps in the process:

• BLS API client and CSV parser: pull one quarter of Manhattan data per call, and extract employment levels, wage data, NAICS industry codes, and ownership breakdowns.

• Data models: type-safe validation on every record, so if the BLS changes a field name or format, the system catches it immediately.

• Error handling and retry logic: deal with the reality that the internet is unreliable, and frankly sometimes weird.

• Incremental updates: assess what’s already in the database and fetch only what’s missing.

• Data validation: flag anomalies and report in American English.

The Database Layer

Once the data is extracted and validated, it lives in Supabase–a managed PostgreSQL database with a clean API layer. The choice of a relational database over flat files or spreadsheets isn’t arbitrary. It’s the difference between having data and being able to think with it. “What’s the largest private-sector industry in Manhattan?” is a join across two tables. “How has finance employment changed over the past three years?” is a GROUP BY with a date filter. “What percentage of Manhattan’s workforce is government?” is an aggregation with a WHERE clause. The database doesn’t just store the data–it makes the data answerable.

But to do this, you have to know SQL, which only data nerds understand, so that brings us to…

Asking Questions of Your Data

A single quarter of employment data is a snapshot. Fourteen quarters is a story–one that spans post-pandemic recovery, inflation, interest rate shocks, and the early AI boom.

Time series data is where this system goes from interesting to genuinely useful for real estate analysis. Employment isn’t static–it moves. Sectors grow and contract. Companies hire in waves. And every one of these movements has implications for office space demand.

The QCEW data, structured as quarterly observations across NAICS industry codes, gives you a granular view of Manhattan’s employment trajectory. You can track total employment quarter over quarter. You can isolate specific sectors — finance, technology, healthcare, professional services–and see which ones are growing and which are flat.

For a real estate professional, employment by industry is a leading indicator. When finance employment ticks up for three consecutive quarters, that’s not just a number–it’s a signal that financial firms are likely to need more space, and soon. When technology employment plateaus, it suggests the wave of tech-driven leasing that reshaped Midtown South may be stabilizing. With three and a half years of data, you can distinguish a genuine trend from a seasonal blip–and that’s the difference between a good bet and a bad one.

The database makes this kind of analysis trivial. The quarterly structure is already built into the schema. Trend analysis is a SQL query. And because the agent keeps the database current with incremental updates, the time series extends automatically as new quarters become available.

The MCP Server: Let’s Have a Chat

Here’s where the system gets genuinely interesting.

MCP stands for Model Context Protocol. It’s a standard–developed by Anthropic–that allows AI models to interact with external tools and data sources. Think of it as a way to give Claude hands: instead of just generating text, it can reach out, query a database, and bring back real answers. You add a configuration entry to Claude Desktop pointing to the MCP server script and your Supabase credentials, restart the app, and suddenly Claude can answer questions about Manhattan employment data by querying your database directly.

In practice, this means you can sit in Claude Desktop and ask:

“Show me employment trends from 2022 to 2025.” Claude queries the database and returns a summary of how total employment moved quarter by quarter across the full three and a half years.

“What are the top 10 industries by employment in Q1 2025?” Claude returns a ranked list with actual numbers.

The shift here is subtle but important. You’re not writing SQL. You’re not opening a spreadsheet. You’re asking questions in English and getting answers in English, and the answers go beyond just answering: Claude is always trying to go that extra step, to anticipate what else you might need. The MCP server handles the translation — it takes Claude’s natural language understanding, maps it to the appropriate query tool, executes the SQL against Supabase, and returns structured results that Claude can interpret and explain.

For someone in my business, this is the difference between having data and using data. I’ve had access to BLS statistics for years. What I haven’t had is a way to interrogate them conversationally, to follow up on an interesting number with “why?”

An Example

All of this might seem pretty abstract, so let’s take a toy example for illustration. We start out with a pretty straightforward question to the MCP server, and then go from there:

Me: ​​Using the BLS data set, can you give me which industry has the highest growth during the total periods covered by the data and the one that has the lowest growth/greatest decline. Please give me a table with the name of the industry and its value in each time period.

MCP: Transportation & Warehousing has the highest growth and the greatest decline is in Manufacturing.

Not very interesting so far, but then it adds something else that it finds interesting.

MCP: Worth noting that Information (NAICS 51) also saw a meaningful decline of -6.1% (195,333 → 183,472), which represents the largest absolute job loss at nearly 12,000 positions–reflecting tech sector contraction in Manhattan during this period.

Well that’s very strange; why would Information be declining. Somebody told me there was a tech boom out there!

Me: Why would information be declining but clearly there is a boom going on in AI?

MCP: NAICS 51 is actually broader than most people expect. It’s called “Information” but it bundles together some very different sub-industries, including 512– Motion Picture & Sound Recording and 513–Publishing (excl. Internet).

Your intuition is right–the tech/AI-adjacent sub-industries (518 and 519) are growing, and growing fast. Together they added ~8,500 jobs. But they’re being completely swamped by losses in legacy media and publishing, which shed nearly 20,000 jobs over the same period. The film/TV industry (512) took a particularly big hit, likely reflecting the writers’ and actors’ strikes and broader industry contraction. Traditional publishing (513) continues its long secular decline.

Me: Can you help me make an infographic that illustrates this?

MCP: Sure, but you should probably speak with my AI friends at Figma if you want something that looks good.

(I made up this last part..I had to figure out the Figma part on my own. So there is still room for us humans, at least for the moment)

Figma produced this, which tells both “Information” stories.

How about a line chart illustrating 518 and 519?

What Comes Next

The BLS QCEW is one dataset. The pattern–agent extraction, structured storage, conversational query–applies to dozens more.

Within the BLS alone, there’s the Current Employment Statistics survey (CES), which provides monthly employment estimates. There’s the Job Openings and Labor Turnover Survey (JOLTS), which tracks hiring and separation rates. There’s the Occupational Employment and Wage Statistics program (OEWS), which breaks down employment by specific occupations rather than industries. Each of these could be extracted by an agent, loaded into Supabase, and made queryable through an MCP tool.

Beyond the BLS, the landscape of public data relevant to real estate is enormous. Census Bureau data on population, income, and commuting patterns. SEC filings reveal corporate financial health and real estate commitments. Building permit data from municipal agencies that signals new construction and renovation activity. Transit ridership data that correlates with office occupancy patterns. Each of these is publicly available, each is painful to work with manually, and each is a natural candidate for the agentic extraction approach.

And then there’s private data. CoStar tracks commercial real estate transactions and availabilities. CBRE and JLL publish research on market trends. Proprietary lease databases track tenant movements and expirations. These sources require authentication and licensing, but the architectural pattern is identical: connect, extract, structure, query.

The vision–and I don’t think it’s a distant one–is an ecosystem of agents that continuously harvest and structure data from public and private sources, all feeding into a unified database layer, all queryable through a single conversational interface. You sit down with Claude and ask: “Which Manhattan submarkets have the strongest employment growth in finance and technology over the past four quarters, and which of those submarkets have rising vacancy?” The system queries BLS employment data, cross-references it with commercial real estate market data, and gives you an answer that would have taken a research analyst a day to assemble.

This is the real promise of the agentic approach to data. It’s not about automating one pipeline. It’s about creating a pattern that scales — where every new data source you connect makes the system smarter, and the cost of asking a new question approaches zero.

The Pattern

Let me bring this back to where we started. Did I make the case that this makes BLS data fun? Perhaps not for all but the most hard-core data nerds. But I hope that for everyone who made it this far, I made the case that chatting with your data is a lot more interesting, and I might even say, more human than downloading CSV files and trying to make sense of their arcana.

The government publishes boatloads of information that help understand Manhattan’s economy at a granular level. It has for decades. The problem was never the data. The problem was the work of getting it into a form where you could think with it–the downloading, the parsing, the cleaning, the loading, the querying.

An AI agent doesn’t just automate that work. It makes the system adaptive. When the BLS changes a field name, the agent figures it out. When a new quarter becomes available, the agent fetches it. When you want to add a new data source, you give the agent a new tool. The system doesn’t just run–it *learns* its way through the task.

And the MCP server closes the last mile. Once the data is structured, you don’t need to be a programmer to use it. You don’t need to write SQL. You ask a question and get an answer. The barrier between “data exists” and “data informs a decision” collapses.

The BLS QCEW agent is a proof-of-concept. The real project is much bigger: point intelligent agents at the internet’s vast trove of public data, structure what they find, and make it conversational. The data is out there. And with Claude and its siblings, now we can actually use it.