An architect doesn’t just design solutions. They also spot systemic problems long before they blow up.
People rarely talk about this because many either don’t notice it or don’t fully understand it.
It’s messy, behind-the-scenes work.

To uncover these problems, architects look for signals in how systems actually behave.
So where do those insights come from?

1. Code reviews
Architects can spot patterns that hint at future issues just by looking at the code. For example:
– Running an app as root inside a Docker container → high risk of executing malicious code with elevated privileges
– Treating RPC calls like local functions, especially inside loops → serious performance degradation

2. Incident retrospectives

3. Customer feedback
Both are already “post-failure” signals. Something has gone wrong.
But if the architect doesn’t act on them, the same issue will hit again, usually harder.
You can’t foresee everything, so this is a goldmine of insight.

4. Team communication
Breakdowns in communication between dev, QA, DevOps, and product often point to deeper architectural issues:
– Poor system decomposition that impacts performance
– Bad naming that leads to duplicated functionality

5. How adjacent teams actually work
You can often spot architectural flaws by looking at the workarounds teams are forced to use. For example:
– Infrastructure defined only imperatively (scripts, docs, or just in someone’s head) → high risk of manual errors and insecure setups (like a DB exposed to the internet)
– QA needing a full week to run tests because the environment is too heavy to spin up per PR → low solution quality

6. Business feedback about engineers
“Developers have gotten slow” usually means technical debt has piled up and was missed at the architectural level.
“Developers ask dumb questions and don’t get obvious things” often means the architecture wasn’t thought through well enough for the team to execute.

Where do you personally find your insights?

Inference is when you call a model to get a prediction or an answer based on given conditions.

1. Prompt engineering
The most common approach. You pass instructions and context directly to the model.

2. Dynamic context
Models are trained on general data, but business problems require your up-to-date, internal data.
Before inference, you prepare context, for example by querying your database.
Then you run standard prompt engineering using that prepared context.

3. RAG (Retrieval-Augmented Generation)
Sometimes it’s hard to prepare context without involving AI. For example, when you get a free-form user query and need to find relevant data.
Full-text search tools like Elasticsearch can help, but the quality is often not great.

This is where AI helps:

• Convert text into numerical vectors (embeddings) using AI

• Store both the data and vectors in a vector database

• Perform vector similarity search without AI involvement

• Inject the retrieved context into the prompt for inference

4. Function calling
Prompt size is limited. When context becomes too large, previous approaches stop working.
Instead of passing all the data, you provide the model with a list of available functions.
The model decides which function to call to get the data it needs.
You effectively act as a router for the model.

5. MCP (Model Context Protocol)
Being a router becomes expensive as inference logic gets more complex.
External system APIs can be registered as MCP servers.
During inference, the model can directly query them through its internal tools to get required data.

Example: Gmail MCP server. You ask the model to find emails from former colleagues. The model queries Gmail and filter required emails.

6. AI agents
Complex business processes are typically handled by BPM engines like Camunda.
But when transitions between states aren’t strictly defined, BPM falls short.

That’s where AI comes in.
AI manages the execution of the process, and each step can be handled by different models. This is what we call an AI agent.

This isn’t a full reference, just a simplified guide.

There are two popular takes on serverless architecture:
– It’s expensive
– It’s just “functions as a service”

Both are fundamentally wrong and usually point to a misunderstanding of what serverless is really about.

In a traditional server-based system, about 90% of the code is garbage. Moving data from one place to another, transforming types, reading and writing storage, building layers of abstractions on top of more abstractions.
Only about 10% actually represents real business logic.

The problem with this “garbage code” is that you still have to write it and maintain it.
The biggest issue with that approach is slower time to market.
A less obvious but very painful one is cost. HR costs dominate modern software development.

You can easily find the theory yourself, so let me give you something practical.
I built a FinOps product from scratch that reduces infrastructure costs for Fortune 100 companies.
I personally analyzed their infrastructure spending. And here’s the reality:
the salary of a single DevOps team often exceeds the total infrastructure cost of the entire company.
Hardware is a commodity, like bread. Over time, it only gets cheaper.

Serverless lets you delegate 90% of that garbage code to managed services and focus on the 10% that actually matters.

“But isn’t it cheaper to run everything on-prem?”

Infrastructure might be cheaper, sure.
But HR costs will grow significantly and dominate.
The total cost of ownership ends up much higher than a serverless alternative.
Why try to optimize a commodity? This is exactly the mistake you’ll see in most criticism of serverless.
Sometimes it’s just ignorance, sometimes it’s deliberate manipulation.

And it’s not just about infrastructure, it’s also about everything around it.
With serverless, you get infinite automatic scaling, high availability, durability, and more out of the box.
With traditional server setups, all of that has to be built and maintained manually by expensive experts.

What changed with AI?

A server-based system that used to take a year to build can now be replaced with a serverless solution in a matter of days.
Generate the configuration, add minimal code, and you’re done.

Example.

In the attached diagram, you see a typical serverless architecture for a web application.
It uses AWS services since they’re the most advanced today.

Regular users interact with data. Their managers see analytics on top of that data.
The only places where you actually need code are highlighted in red: frontend and minimal data transformation in streaming.

That’s what modern architecture looks like now.

Some enthusiast vibe-coded a simulator that lets you test how your architecture would behave in real life.

– You can set and control a budget
– Adjust load on the fly
– Visually build your architecture diagram
– Configure sharding and replication
– Run chaos testing (random failures, spikes, network latency)
– Share diagrams and scenarios with others

Great for learning, no doubt.

For real-world validation though, I felt a couple of gaps:
– No clear understanding of how load maps to component parameters. Right now it’s a black box.
– No integration with external systems.

It would be great if you could feed the product a JSON diagram with components and connections and have it automatically validate the setup against requirements.
Of course, you still can’t avoid testing on a real environment. But it’s slow and expensive. A tool like this could give you fast, cheap feedback upfront.

Enjoy.

Domain-Driven Design: Tackling Complexity in the Heart of Software was written in a way that lets people interpret its ideas however they want.
Or you can read Head First Domain-Driven Design once, understand everything, and move on. That book was created specifically to remove the confusion.

DDD helps you structure complex domains. That’s it.

Once the domain is structured, you evolve it incrementally. At that point, you don’t need the full DDD “heavy artillery” anymore, you can keep things simple.

Also, we now have serverless and AI that writes code. Over the past five years, development has quietly shifted back toward procedural programming.
Where we once had to invent complex domain logic, today we delegate 99% of that abstraction overhead to serverless platforms and end up with minimal code written in the simplest way possible.

DDD ideas still work well with serverless. But the full-blown DDD “bazooka” is overkill.

DDD is a great tool, but still just a tool with a very narrow area of use.

Today I want to talk about a topic every CTO needs to understand, and that’s also very useful for architects and managers.

I brought this up before here but for many people it’s still not obvious. And honestly, repeating a good point in a new wrapper probably does no harm 😁

Recently I had an argument on LinkedIn with my former colleague, who is now an architect at EPAM. I recommend reading the thread and the debate there.

Alexey describes tactics for increasing developer throughput:

• On their project, the bottleneck is user acceptance testing, which takes clients months because the process is overregulated and inefficient.

• No feature can be released until acceptance testing is complete.

• Alexey suggests using feature flags on steroids so developers can keep cranking out features instead of waiting for releases.

At first glance, it may look like Alexey came up with a brilliant optimization. He gave developers a way to keep producing even when releases are blocked.

But in reality, this optimization makes overall throughput much worse.

1. Every feature that has been built but not released is work in progress, or WIP.

2. To increase throughput, you reduce WIP, not increase it.

3. Increasing WIP in front of a bottleneck makes throughput significantly worse.
   The testers are already taking months to do their work. And now we introduce an “optimization” that increases the load on them by tens or hundreds of times.

4. By the time the feature is finally released, it may no longer even be needed.
   Apparently waiting months to release one feature wasn’t bad enough, so we turned that delay into years. And over years, even regulations change.

5. Managing WIP is expensive.
   Managing feature flags, refactoring the database, switching flags on and off, cleaning them up.

6. Bugs found during acceptance testing require rework in other features.

7. Rework becomes extremely expensive.
   Try remembering a feature you worked on a year ago. Or worse, one you didn’t build at all because the person who did already left the company.

Alright, enough boring theory. Let’s make it simple.

Why keep pumping out features into a drawer if no one will see them in production for months or even years?

So what should you do in this situation?

1. Speed up acceptance testing. In Alexey’s case, that seems unrealistic.

2. Reduce developer output, for example by significantly reducing the number of developers.

Sounds weird, right? To increase overall throughput, we actually need to reduce developer throughput 🤣
Welcome to the world of process management.

If you want to dive deeper into this topic, I recommend the classic The Goal, or the more modern repackaging The Phoenix Project + The Unicorn Project.

So, on your projects, are you reducing WIP or increasing it?

A subscriber asked a fair question. I refer to this a lot here, but I don’t think I’ve ever explained it properly.

It means:

1. Focusing on what actually matters

2. Tradeoff analysis
   Understanding the pros and cons of alternatives.

3. A pragmatic mindset
   Recognizing that best practices and patterns are useful, but they’re just tools. In real life, they’re often only partially applicable.
   Modern distributed architecture isn’t “monolith vs. microservices.” It’s a mix of many patterns and non-patterns.

4. Objective and rational decision-making

Let me give a simple example of how a developer thinks vs. how an architect thinks (taken from a real puzzle).

We need to build a system to store user avatars.

➖ A developer will put them in S3.
Because it’s “the most efficient way” and “that’s how it’s always done.”

➕ An architect might store them in an existing PostgreSQL database.
Why? Because avatars rarely change, fit within limits, and modern databases handle files just fine. This can significantly simplify the system.

The developer’s reaction:
“But that’s an anti-pattern, you shouldn’t store files in a database. This architect is weird.”

If no one in a company thinks like an architect, the company just drifts from one trend to another, from one pattern to the next.
It’s a constant storm.

For some reason I honestly don’t understand, system design has become a mandatory step in architect interviews.
Feels like it comes from a popular misconception: architects produce diagrams 🤦‍♂️

Context:
– usually lasts 1–1.5 hours
– 15 minutes: candidate clarifies requirements
– 15 minutes: candidate presents a solution
– 30–60 minutes: candidate “designs” the solution (let’s be real, they don’t design anything, they just draw something)

I consider these interviews useless, even harmful.

1. In 30–60 minutes, candidates produce low-quality decisions.
There’s simply not enough time to think things through. Architecture isn’t about best practices and patterns. It’s about pragmatism and efficiency.

2. The reasoning behind decisions is spoken, not captured, and often gets lost.
– The candidate forgets what they said
– Important nuances get lost because reasoning is just “in the air”
– The interviewer zones out while waiting and misses the reasoning entirely

3. The interviewer can’t really validate anything.
– They may disagree, but don’t have time to fully challenge it
– They may not understand the solution, but don’t have time to clarify
– At best, they can tell whether the candidate can say something reasonable and produce a mediocre solution in 30–60 minutes

4. Drawing diagrams is one of the least important parts of an architect’s job.
An experienced architect can sketch a solution of any complexity in an hour. I even ran a poll among experienced architects, and most spend less than 10% of their time drawing diagrams.

5. AI can draw diagrams as well as inexperienced architects
(which, statistically, are the majority being hired, no offense).
It still performs worse than experienced architects because it can’t focus on what matters and simplify properly. But here’s the key point: you’ll never filter out a strong architect with system design interviews anyway.
So what’s the point?

So what is system design actually good for?
It shows the candidate that your company has weak architecture processes, low operational efficiency, and low architectural maturity.

What should you evaluate instead for an architect role?
The core responsibility of an architect is making architectural decisions.
That’s the skill you need to assess.

Give a small problem and see how the candidate approaches it
(a few questions, 5–10 minutes to think).

I like giving architectural puzzles.
In 5 minutes, you can clearly see how a person thinks and solves problems.

“You criticize system design because you can’t pass it.”
In 17 years, I’ve never failed a single system design interview.

What do you think about system design?

An architect makes the most important technical decisions in a company.
When designing a system architecture from scratch, there are usually 50+ architectural decisions. Out of those, 3–5 matter far more than the rest.
Today we’re talking about those. Let’s call them Big Bang Decisions.

Big Bang Decisions shape the entire architecture. If you get one of them wrong, you will absolutely wreck the whole system.
In other words, they’re high-risk.

So how do we reduce that risk?

When forming a Big Bang Decision, we make hypotheses.
Architects usually call them assumptions. They log them, finalize the architecture, and go relax in a jacuzzi with a mojito 🛁
Six months later, everything blows up. The architect points to the log and says, “Well, that was an assumption, not a fact. Not my fault.”
It’s a common approach. And a terrible one.

Can we improve it? Absolutely.
For every hypothesis, the architect should build a prototype by hand to validate it.
Both the hypotheses and the prototypes should be documented directly in the decision itself. That benefits the architect and gives developers a working baseline they can build on.

An invalidated hypothesis is also a win. You just saved the company serious time and money by not implementing the wrong solution.
In my experience, up to 30% of hypotheses turn out false even for experienced architects. For inexperienced ones, it can be as high as 80%.
Now imagine how much damage unchecked assumptions can cause 😈

What counts as a prototype?

Anything minimally functional:

• Bash script.

• CLI tool.

• Plugin.

• Or even a fully deployed system.

Should the architect really build it by hand?

Yes. Who else?
It’s a great way to get grounded and feel how the architecture actually behaves in real life.

But isn’t that slow?
We have public clouds. Serverless. And now AI that writes code.
You can build a solid prototype in 4–8 hours.
I’m serious. I was doing this even before AI. I’ve deployed ultra-complex Hadoop clusters with outdated dependencies and dug into the guts of a Chromebook when needed.

Let’s look at a real example ✨

Recently I was designing architecture for a nonprofit.

The Big Bang Decision there was: where will staff and volunteers run their core business processes?

Hypotheses:
– AmoCRM is suitable as the foundation for their operational workflows
– AmoCRM can be extended to support nonprofit-specific needs

The prototypes confirmed both:

– AmoCRM was deployed and configured around their key processes
– A custom widget with an analytics dashboard for the nonprofit owner was built

During prototyping, I also discovered that the widget approach from the AmoCRM landing page wouldn’t work well for this case. A different extension strategy was required. Without prototyping, the developers would have hit that wall much later.

Both prototypes took one day. One additional day to polish the widget for a demo.
The nonprofit owner couldn’t believe how smoothly everything worked. So I validated the architecture and won stakeholder confidence at the same time.

Now for the real question:
How do you reduce risk in your architectural decisions?

It’s well known that a successful product solves real problems people have, not imaginary problems invented by the founder 😁

So how do you actually find real problems?
The classic answer is: talk to people.

But it’s the 21st century. When something truly hurts, people don’t keep it to themselves. They rush to complain about it online.

And for some reason, they especially love doing this on Reddit.
It has ugly design, constant bugs, random bans, and developers who seem to make very questionable decisions.
But hey, life is life. People genuinely go there to share what’s bothering them.

So I decided to collect all the pain from Reddit and add AI analysis to user complaints, answering questions like:

• Is this actually a real problem?

• What’s the root cause?

• How hard is it to solve?

• How popular is this problem? (Building products for ultra-niche audiences is a very specific kind of pleasure.)

The results of this analysis are automatically published every day in this Telegram channel ‼️

Founders, here’s a free database of ideas for your next product 🎁

P.S. This was painful to build. Reddit locked down their API, and I had to invent all kinds of hacks and workarounds to parse the data automatically 🤯

Some time ago, a tool called Clawdbot popped up.
All it really does is add a UI on top of AI models via messengers.
You can message it in WhatsApp and ask it to generate unit tests in Claude, or parse your email via a Gmail MCP server. Which is actually nice, but not exactly groundbreaking.
We could already do all of this before with Claude and ChatGPT. We could even give commands from our phones. The only difference now is that the commands go through a messenger.

But on X, a viral trend exploded – “Clawdbot is changing our lives. We are about to become superhumans.”
This led to some truly hilarious situations:

• People are mass-buying Mac minis to run the bot, even though it can run on any cheap commodity hardware.
  The creator of Clawdbot is literally asking people to stop buying Mac minis and donate that money to him instead 🤣

• People give commands to the bot in WhatsApp so that it sends their own message to a friend… in WhatsApp 🤯

• Almost nobody uses local AI models, even though the bot supports them. Most people just use the Claude API. Result: massive surprise bills.

• People hand over their personal secrets to the bot: logins and passwords so the bot can “work for them”.
  Even though we have known for at least 10 years that machines need scoped tokens, not human secrets.

• People delegate their personal accounts and even their lives to bots, despite the fact that AI agents cannot be protected from prompt injection even in theory. And the creators of agent frameworks have been warning about this since day one.

Hackers are celebrating. Thousands of users are voluntarily handing over their access and their lives for free.
Basically, a herd of sheep escaped the fence and consciously ran straight into the wolves’ camp 😄

In moments like this, the only winners are Apple, Anthropic, and hackers who suddenly got a nice pile of cash.

This wave of idiocy will soon end with people declaring Clawdbot “bad, expensive, and insecure”.
Even though its modest use cases are actually quite useful, and its real target audience understands that perfectly.

Wishing all of us some calm in these dark times 😀

My former colleague, now a Director of Engineering and overall a great guy, Fabiano, did a breakdown of a recent case in Brazil where a large bank fired 1,000 employees. The official reason was low employee productivity.

The company had been secretly measuring productivity based on activity at the work computer: mouse clicks, keystrokes, and similar nonsense. Then they fired everyone whose activity was below 40 percent per day.

Basically, they copied Elon Musk’s Twitter/X purge playbook one-to-one.
Let’s unpack what went wrong.

1. The company had no idea how to measure real productivity like impact on team success, work quality, or successful releases. So they measured mouse clicks instead.
This can work, but it creates a massive number of false positives.
Some of the laid-off employees said things like: “I got promoted a month ago for high performance, and now I’m fired for being supposedly unproductive.”

2. The company never told employees that high productivity was a priority.
You might say, “Come on, of course productivity matters to companies.”
Sure, but 99% of companies are operationally inefficient. Banks are probably even worse.
You can be highly productive personally and still be constantly blocked by other people and departments. The end result is low output.
Also, if you truly want high productivity, you have to pay significantly above the market.

My prediction:
The remaining employees will start simulating productivity by constantly moving the mouse, but they will leave the company within a year. Their salaries were not raised, obviously.

What amused me the most was the reaction of the labor union.
They did not mention any of the points above. Instead, they complained about violated rights, offended feelings, and “spy software.” Like, wow, what a bloodthirsty bank for monitoring its own work computers.

Elon Musk’s methods are great when you need to create a miracle in a swamp.
– Convincing the world that electric cars are not just golf carts.
– Getting a country back into space when the tech has been collecting dust for 60+ years.
But they do not work when you need stable long-term results and low risk.

What do you think about this move?

I rolled up my sleeves, fired up OpenAI Codex which I had been wanting to try for a while, and in about 30 minutes vibe-coded a CLI that turns static diagrams into animated GIFs.
Source code is here.

Before:

After:

So far I tested it with Excalidraw exports. It might work with others too. I will check when needed.

Codex is really impressive. Zero hallucinations and it was proactively helpful.

Have fun 🎁

Architectural mistakes have serious consequences. So how do we minimize them?

1️⃣ Expand your knowledge breadth and stay grounded.
I have already written a lot about this.

2️⃣ Validate hypotheses with prototypes.
I will write a separate post about this.

3️⃣ Get feedback from a second pair of eyes.
That is what we will talk about today.

Humans are subjective by nature, even when they try to be objective.
A second pair of eyes quickly checks your solution for subjectivity and effectiveness.

If a company has multiple architects, that is a huge advantage. You can get expert feedback quickly. Sometimes it turns into a holy war though.

But what if there is only one architect in the company? 🤔
This is very common. Few companies actually grow to the point where they need several architects.

You can ask developers or business stakeholders for a review, but most of the time you hear: “Looks cool”, “Nice”. Or sometimes an honest answer: “I do not understand anything.”

Can generative AI help with reviews?
AI still cannot make architectural decisions, and its feedback will be of a specific kind. However, it can already perform basic checks for objectivity and effectiveness. That is something my product supports for architectural decisions.
It will not replace an expert, but it can significantly simplify their work.

You can also ask peers outside your company, but that usually violates NDAs, and people are understandably reluctant to do that.

So far, I have come to one effective solution: teach teams how to make architectural decisions.
This is necessary anyway when there is only one architect in the company. A company cannot survive if the architect becomes a bottleneck.
But this only works in the long term.

Do you see more effective ways to get feedback when there is only one architect in the company?

One food delivery service worker shared a disturbing behind-the-scenes reality.

1. Priority delivery is a sham.
   Non-priority orders are deliberately delayed by 5 to 10 minutes so that priority orders feel faster by comparison.

2. A hidden “desperation index” is used for couriers.
   The system estimates how badly a courier needs money by analyzing behavior, like frequently accepting unprofitable orders, and then stops offering them good-paying ones.

3. Tips do not go to the courier. They go straight to the company.
   If the system sees that a customer regularly tips, it reduces the courier’s base pay for that order by the amount of the tip.

4. “Driver Benefit Fee” and “Regulatory Response Fee” do not go to couriers.
   They are used to pay lawyers who fight courier unions. In other words, customers are paying to make couriers’ lives harder.

I never really thought about it before, but it turns out humanism is one of the core internal requirements I apply in my solutions almost instinctively.

There is one more internal requirement: integrity. That one I think about quite often.

What are your core internal requirements when you design solutions?

✅ Which database should we use?
✅ Where should we deploy the application?
❌ Which unit testing framework should we choose?
❌ Which IDE should we use?

2. Technical
An architect should focus on solving technical problems. Even though sometimes you have to step into other areas, each area already has its own experts.

3. Decisive
It must be clear what decision was made and why.
“We can use X and gain performance but increase maintenance costs, or use Y and lose performance but reduce maintenance costs” is not a decision. It is unclear what to do next.

4. Clear
A decision should contain zero fluff and minimal text, while still clearly conveying the meaning. Otherwise, it becomes hard to understand and even harder to work with later.
You can use the SIRI technique.

5. Objective
A decision must be based on facts, not personal opinion, no matter how much experience the architect has.
A subjective decision is irrational by definition, even if it feels rational to its author.

How often do you see decisions that have all five of these characteristics?

I wrapped all of this into a cheat sheet.

The private equity firm ESW Capital acquires a new product every week.
The core challenge is how to keep this pace while still maintaining architectural quality.

The company went through several stages and eventually settled on the last one:

• Architecture done by developers
  ➕ fast in the short term
  ➖ quality suffers

• One architect per product
  ➕ high quality
  ➖ focus on non-critical details
  ➖ narrow, product-only perspective

• Shared pool of architects across all products
  ➕ broad, cross-product perspective
  ➖ still too much focus on non-critical details

• Architect pool + delegation to developers
  ➕ high speed
  ➕ excellent quality
  ➖ long learning curve

A full breakdown of the remaining challenges, metrics, and conclusions is on Boosty.

💬 Open to new opportunities
Let’s talk about how I can help your team build a scalable architecture.

How often have you finished an architecture artifact and then realized you forgot to cover one key aspect? That leads to rework, and it hurts. And the cost of rework for an architect is really high.

I solve this by working top-down. I build a kind of outline for the artifact.
What aspects are worth covering, on average?
🔹 Critical decisions.
Usually there are at most three, and they form the foundation of the solution.
🔹 Whiteboard.
A high-level description of the solution as a component or process diagram.
🔹 External interfaces.
How the system being changed interacts with external systems. This includes a diagram, integration protocols, and an ADR.
🔹 Internal interfaces.
How components, or steps in a process, interact with each other. This includes a diagram, integration protocols, and an ADR.
🔹 Data model.
An ER diagram with crow’s foot notation that covers only the most important fields (I skip things like id and timestamps), because someone else can fill in the rest.
Read and write use cases with actors (who queries what, and who writes what).
And of course, an ADR.
🔹 Topics.
This is the business domain broken down into subdomains.

How do you identify those subdomains?
Remember how we defined the system’s Inputs and Outputs?
Now we define Core Functions. These are actions (verbs) that describe how an Input becomes an Output.
For example: “Build an employee profile” for the Input “Employee data” and the Output “Employee profile” from the previous post.
Those Core Functions are our topics.

⚡️So in the end, we get a solution skeleton that makes it hard to miss important decisions.

Here are some examples of finished architecture specs that follow this outline.

How do you make sure you don’t miss key aspects of a solution?

1) How Stripe tried to automate customer discovery before AI was a thing
In 2017, Stripe decided to launch an outbound customer discovery function.
Normally you’d staff this with ~30 SDRs, but Stripe ran lean, and Jeanne was given 4 people.

To make up for the lack of hands, the team created Project Rosalind: a massive database of potential companies with attributes like business model, industry, needs, and org structure.

The ambition was big: generate personalized outreach emails as a “template with variables” where the system would plug in the right arguments, case studies, and value props based on the company type.
But without AI, the accuracy just wasn’t there. Real personalization wasn’t achievable. The idea was right, but the tech wasn’t ready yet.

Years later at Vercel, they did the same thing again, but this time with AI agents that actually worked.

2) How Vercel cut a team of 10 SDRs down to 1 with AI
At Vercel, Jeanne set a goal: train an agent to perform like the best SDR on inbound leads.
A GTM engineer took a simple but brilliant route: he fully replicated the best SDR’s workflow:

• what they research

• how they find data

• how they decide a lead is “good”

• how they craft the first message

Six weeks later, the agent did it all end-to-end:

• analyzed the inbound lead

• gathered company context

• generated a personalized reply

• suggested the next step

A human just hit “send.”

Result: one SDR does the work of ten. The rest were moved to outbound prospecting, where the human touch matters more.

Agent cost: about $1,000/year.
Cost of a 10-person SDR team: over $1M.

3) How sales at Vercel started running in sprints
Vercel ships product updates so frequently that sales can’t always keep up.

To avoid drowning in chaos, they set up a system:

• An AI agent reviews all calls (via Gong transcripts) and flags where a rep explained a new feature incorrectly, missed a key point, handled an objection poorly, or confused the customer.

• Once a week, the team reviews these like bug reports.

• The next week becomes a “sales bug-fix sprint”: update demos, refine messaging, and practice better phrasing.

Sales starts to look like engineering: measurable, predictable, and continuously improvable.

4) Build vs Buy: why internal agents beat off-the-shelf tools
The market is flooded with AI sales tools right now, but they usually have two problems:

• They only solve slices of the workflow.

• They don’t know your internal context.

An internal agent, on the other hand:

• plugs directly into your CRM, email, Slack

• uses your data

• mirrors the logic of your best people

• costs basically nothing

For example, Vercel built a “lost-deals analysis agent” in two days with one engineer. Now it finds the real reasons deals are lost, often ones the team hadn’t even considered.

Source code for the mentioned agent.
Original interview with Jeanne:

An architect who can no longer write code can slide downhill pretty fast. You lose touch with reality and start designing solutions that only work in a vacuum.
Rapunzel-architect is exactly about this.

So what do you do if an architect’s job usually is not about writing production code?

Here’s what I do:

• I used to grind algorithms on HackerRank and even got a gold badge.

• I write fitness functions for my architectures

• I build prototypes to validate hypotheses and reduce risk for the most critical decisions in a solution
  “decisions in a solution” for strict lovers of Russian 😄

• I bootstrap my own products like this and build small automation tools that make my life easier

• I do the dirty work on projects where developers do not have time to reach yet
  for example, helping clean up technical debt. At the same time, I stay out of developers’ critical and urgent tasks. I do not want to produce garbage code.

How do you stay hands-on?