Andrew Ng punctures the AI illusion: the hype has gone too far, and the company of the future will be a 10-person team plus AI agents rebuilding the data architecture

Recently, at Interrupt, the agent conference hosted by LangChain, Andrew Ng had a conversation with LangChain founder Harrison Chase about AI agents. The core of the entire discussion was not simply about how powerful agents are, but centered on a more practical question: once AI agents make software development faster, where will the real bottleneck shift to?

Andrew Ng first mentioned that over the past year, the heat and hype in the AI field exceeded his expectations. By contrast, what deserves more attention is the rapid progress of coding agents. He said that six months ago he used almost exclusively Claude Code, but now he has started mixing in tools like OpenAI Codex, Gemini CLI, and OpenCode. The capability boundaries of coding agents are changing fast—even workflows like writing code on a phone are starting to feel natural.

But the biggest change brought by coding agents is not just faster coding—it's the redistribution of the entire software production chain. Andrew Ng proposed the concept of the "product management bottleneck": once code implementation speed increases 10x or even 100x, what limits team efficiency is no longer just engineering implementation, but "what exactly should we build." Requirements definition, user feedback, prioritization, and product boundaries all become more important.

At the same time, marketing, legal, design, and compliance may also become new bottlenecks. In the past, if a product took three months to develop, waiting a week for legal sign-off was acceptable; but if a product can now be built in a day, then waiting another week means legal itself becomes the obstacle.

Therefore, software teams of the future will be smaller, faster, and more dependent on generalist talent.

Andrew Ng mentioned that he is increasingly assembling small teams of one to ten people, whose members are often high-context, highly empowered engineers with strong technical skills. They don't just write code—they also use AI to complete product definitions, marketing copy, first drafts of terms of service, and more. AI won't instantly turn engineers into great marketers or lawyers, but it can let them produce a usable first draft that professionals can then review.

On how agents are developed, Andrew Ng used the metaphor of "LEGO bricks."

Today's developers face not just models, but a large number of building blocks: RAG, agent frameworks, eval tools, guardrails, UI components, identity authentication, databases, and more. The better developers understand these modules, the faster they can assemble usable systems. But the problem is that APIs, SDKs, and tools change so fast that models may not know the latest usage. Therefore, an agent's capability depends not only on the model itself, but also on whether it can obtain timely, accurate, and actionable context.

On enterprise adoption, Andrew Ng believes many companies are pursuing bottom-up AI innovation, but this "letting a hundred flowers bloom" often only brings point improvements and struggles to achieve true transformation. For example, a bank using AI to automate loan approvals—if it merely turns one hour of manual review into AI review, the value is limited; the bigger opportunity is to redesign the entire process and launch a "10-minute approval" loan product. That requires marketing, data, approval, due diligence, execution, and other functions to change together.

He also reminded companies not to treat AI merely as a cost-cutting tool. Cost savings have a ceiling, while growth offers far more imagination. In scenarios like customer service, call centers, and drive-through ordering, AI's value is not just reducing headcount, but serving more customers faster, improving the experience, and thereby driving business growth.

On technology selection, Andrew Ng particularly emphasized the need to guard against vendor lock-in. AI models and agent tools change too fast—no one can be sure which model will be the strongest a year from now. Therefore, companies should try to preserve their options and not easily sign overly long contracts just because of discounts. Vendor-neutral observability and management tools like LangSmith, as well as open-weight models, all help companies stay flexible amid rapid change.

Finally, he grounded the key foundation for enterprise agents in data architecture. In the past, companies mainly focused governance on structured data, but for agents to truly work, they must be able to handle unstructured data such as text, PDFs, images, audio, and video. The reality is that many companies have fragmented data, permission systems designed for humans rather than agents, and insufficient governance and observability. Andrew Ng predicts that in the coming years, companies will launch large-scale data architecture overhauls to make their data truly AI-ready and agent-ready.

The key takeaway from this conversation: AI agents don't just make code get written faster—they are forcing companies to rethink products, organizations, data, processes, and technology selection. The companies that truly benefit from agents are not those that simply automate a single step, but those with the ability to rebuild their entire business systems around agents.

Below is the full conversation, translated and compiled by InfoQ:

The Rise of Coding Agents

Harrison Chase: It's been a year since our last conversation, and a lot has happened in AI during that time. Which things developed faster than you expected? And which things were slower than you imagined?

Andrew Ng: I think, first of all, some of the heat and hype exceeded my expectations. Also, some doomsday narratives received more attention than I anticipated, which is a bit unfortunate. For example, the so-called "end of jobs"—I don't believe that will actually happen. On the more positive side, coding agents may be developing faster than I expected.

Today's frontier coding agents are advancing very quickly. People always say AI completely changes every three months—that's not entirely accurate—but with coding agents, it actually feels somewhat true. The frontier of what we can accomplish with coding agents is changing very fast, and the competition is fierce.

About six months ago, I used almost exclusively Claude Code. Now I still use Claude Code heavily, but I'm increasingly using OpenAI Codex as well, and I also mix in Gemini CLI. I also support OpenCode, because it's open source.

So the mix of coding agents we use is changing very fast.

A year ago, I also wouldn't have imagined I'd be writing so much code on my phone. Many workflows are changing rapidly. For example, like many people here, I have a Mac Mini in my office, and these development workflows are changing very fast.

In addition, agentic workflows are truly entering enterprises. That also feels encouraging.

Harrison Chase: Staying on the topic of software engineering, in your view, what will the future of software engineering look like?

Andrew Ng: About a year ago, I wrote about the "product management bottleneck" problem. The idea is that if building software becomes much faster, then deciding what to build—that is, product management work, including defining project scope, gathering customer feedback, and deciding what to do—becomes the bottleneck.

Over the past year, I've felt this product management bottleneck has gotten worse in a good way, because building software has become much faster.

But it turns out that once writing software becomes 10x or even 100x faster, it's not just product management that becomes the bottleneck—almost everything else becomes a bottleneck too.

Some of my teams have already hit the marketing bottleneck. Because we can build so many features, marketers struggle to keep up—figuring out what a new feature actually does, and then thinking about how to communicate it externally.

In the past, if a product required legal compliance, you spent three months building it and then waited a week for legal sign-off, which was perhaps acceptable. But now, if you can build it in a day and then still have to wait a week for legal sign-off, that becomes a legal compliance bottleneck. Design becomes a bottleneck too, and so do other functions.

So I often think about how software engineering teams will be organized in the future. But I don't think I already know the answer.

That said, I'm increasingly assembling very small teams, perhaps one to ten engineers. These people are usually generalist, high-context, highly empowered engineers. The team is given a very broad set of guardrails, and then they can push forward aggressively within that scope—building and shipping code, and even making decisions that traditionally fall outside engineering, such as writing marketing copy.

Suppose you have a team that needs software engineering, product management, a bit of terms of service, some marketing copy, and some design. In other words, this team needs five functions but has only two people.

Then by definition—or by the "pigeonhole principle"—each of the two people must take on more than one role.

The good news is, I don't consider myself a great marketer. But even when I use AI, I'm still not a good marketer—just slightly less bad than I would be without an AI assistant.

So I've found that these small teams work very well: the members are high-context generalists with strong technical skills who can use cutting-edge technology while also taking on parts of other roles.

For example, frankly, any engineer can use AI to draft a version of the terms of service, then hand it to a lawyer for final polishing before publishing. I've found that these kinds of processes let teams move much faster. That's very exciting.

Harrison Chase: What's the ideal background for these people? Are they engineers to begin with? Or do they come from other disciplines and learn to code for the first time? What have you observed?

Andrew Ng: Many of the people I work most closely with do indeed have deep engineering and technical backgrounds. At the same time, they are fully empowered and somewhat generalist in nature. They step into other roles and, with the support of AI, acquire hybrid skills that may not have been the areas they were originally trained in.

I think people can successfully transition from any direction. I've seen product managers become much stronger at writing code and then join teams like this.

However, because AI programming itself is deeply tied to engineering, engineers may have a natural advantage in understanding cutting-edge technology. So the people I most often see succeeding in this kind of role are engineers.

But there are indeed a few product managers who can do it. I've also seen marketers learn to code in very effective ways, and operations people start building more and more products.

I believe people from any background can potentially learn to do many of these things. But the largest group currently doing it best still seems to be people with engineering backgrounds.

That said, we encourage people from any background to try and see whether they can take on these roles.

How to Get Into AI Software Engineering

Harrison Chase: For those who want to enter this new field of software engineering, what advice do you have? For example, which tools are worth trying, what mindset should they have, or which skills should they learn?

Andrew Ng: I've recently been thinking about the future of software engineering in a certain way—it's a mental model in my head. There are now many tool providers offering all kinds of building blocks, such as RAG, agent frameworks, evals tools, guardrails, and so on. These are all AI building blocks.

At the same time, there are also many non-AI building blocks, such as user interface components, authentication mechanisms, front ends and back ends, persistent databases, and so on.

So I think that in computer science, we've always had a great set of building blocks. And with the development of agentic coding, building blocks are rapidly increasing, because more and more people are building open-source modules, proprietary API modules, or other types of building blocks. So we're surrounded by many excellent building blocks.

I've found that if developers can master enough building blocks well, they can usually assemble these modules quickly in a combinatorial way to build software.

You can imagine building things with LEGO bricks. If I only have one white LEGO brick in hand, I can build something, but it won't be very interesting. But if I add black, yellow, brown, and green bricks, plus some oddly shaped LEGO pieces, then as the variety of LEGO bricks I own grows, the things I can build grow combinatorially, even exponentially.

I think many of the building blocks we can use now have a similar effect.

I've found that developers who understand well what these building blocks can do become very powerful.

DeepLearning.AI also offers many short courses to help people master these excellent building blocks from different organizations and developers. Another challenge is how to use coding agents to quickly assemble these building blocks into the software you want.

One problem coding agents face right now is that many building blocks are so new that the coding agents don't know how to use them.

For example, until recently, the knowledge cutoff of the models underlying many leading coding agents was earlier than the release date of nano-banana. So they didn't know nano-banana existed, nor how to call the nano-banana API.

So my friend Rohit Prasad and I have been paying close attention to a project called Context Hub. It's a bit like a Stack Overflow for AI agents.

AI agents can use it to get the latest documentation on what new APIs, SDKs, and building blocks are available; at the same time, agents can give feedback on the documentation, helping to improve it for everyone's benefit.

In fact, there are some APIs I use frequently myself, but I always find their syntax a bit annoying and hard to remember. But after loading the latest documentation through Context Hub, I can have a coding agent make those API calls for me.

So it really has sped up my coding work a lot.

How AI Is Changing Education

Harrison Chase: Let me add two things here. We've also released something called Context Hub, so we've had a name collision, but it's a very different kind of Context Hub. Andrew's Context Hub is more helpful for using coding agents, so everyone should go try it. Following on from this topic, in this new AI world, how do you see education changing? Have you already incorporated some new practices into how DeepLearning.AI runs its courses, or into your thinking about education?

Andrew Ng: We're trying many ways to improve the educational experience. As for training content, it's already clear that what people need to learn has changed significantly. For developers, they need to learn coding agents, learn these building blocks, and perhaps also learn some product management or similar general skills to make themselves more effective.

So, what we need to learn is changing. DeepLearning.AI and Coursera have been trying to provide this kind of training.

But beyond "what to learn," there's also the question of "how to deliver the training." We've been thinking about "how learning will change" for a long time, but it feels like the real change hasn't fully arrived yet.

A few weeks ago, we launched a preview version of a new website called CodeDream.ai. The vision behind it is: don't just take online courses—come have a conversation.

It's not a course, but a conversation. The experience we want to build is one where you can have a simulated video call with me.

For example, if you want to lean back and listen to me explain Context Hub and coding agents in a one-on-one video call, you can do that, and I'll show you some ideas.

If you want to interrupt "me"—that is, interrupt my AI—and ask questions, you can do so at any time. One thing I've personally been experimenting with a lot is using JavaScript instead of videos and slides. What does that mean? That is, when I demonstrate something in a video, what if you could click into that video and type your own prompt or query in the video window?

In other words, the video area isn't a static video that can only be played—it's interactive. This creates more ways to engage with the learning content.

If you're interested, go try CodeDream.ai and have some kind of conversation with me or my AI. I'll show you, in AI form, how to use the coding agent in Context Hub.

Frankly, we are still iterating and improving these experiences every day.

Harrison Chase: You just mentioned that you can click on the video and type in content—is that feature live now, or is it a future direction?

Andrew Ng: It's live. Imagine that instead of me sharing my screen in the video, I'm "sharing JavaScript." Because it runs JavaScript code rather than a pre-recorded video, you can interact with what I call my "screen share."

If there's anything you like or dislike, feedback is very welcome. That said, I do feel that the transformation of education has been overhyped in the past. I think certain changes are coming.

But today, taking online courses is still the mainstream. I hope we can have something much better than online courses. Of course, we do have better courses now than a decade ago. They're more interactive. For example, this morning we just launched a new course on Transformers, taught by Sharon Jo from AMD. I've found that compared to ten years ago, when it was mostly just videos, we now build a lot more interactive visualizations. Today's courses have a lot of hands-on things you can play with that are more interesting than a decade ago.

But that bigger transformation in education—I've genuinely spent a lot of time thinking about it.

Enterprise AI adoption: what works and what's not enough

Harrison Chase: Extending from software engineering to other domains, how do you view enterprise AI adoption? Is it faster or slower than you expected? What's the right approach, and what can people learn from it?

Andrew Ng: I think every enterprise—and I guess that includes all of your companies—is very excited about AI adoption. We've seen some common themes across many enterprises. One of my teams, AI Aspire, is an AI consulting firm I co-founded with my business partner Chris Tann. We've been talking with large enterprises, including Fortune 50, Fortune 500, and G2000 companies, about their AI strategies and transformations.

There are some consistent themes.

Almost every enterprise has invested in bottom-up innovation—the so-called "let a hundred flowers bloom" strategy. But overall, the returns from this strategy haven't been obvious. So CEOs and boards are asking: where's the ROI on AI?

I think we should still keep investing in bottom-up innovation; we should keep doing it. But the reality is that bottom-up innovation usually produces point solutions that deliver incremental efficiency gains. That's actually a good thing, but it's not the broader transformation that AI once promised us—and I think we should strive to deliver that transformation.

Let me illustrate with an example. My team is working with several banks.

Andrew Ng: We've done a lot of work in financial services. Take the loan underwriting process, for example. It might have five steps: marketing loan products, receiving applications, reviewing and approving loans, doing final due diligence, and executing the loan.

Many teams have noticed that the middle step—loan approval—can be done with AI. If we can automate that step, then what used to take a person an hour to review a loan application can now be done by AI. That's great, and we should certainly do it.

But the problem is, if your entire loan underwriting process stays the same and you've only automated an hour of human work, that's just a small, incremental efficiency gain.

So some banks say, in that case, why not rethink the entire workflow and launch a loan product with "approval in 10 minutes."

Because we no longer need to wait for a person to have a free hour a week later to review the application, we can immediately send the loan application to AI and have it make a decision right away. But in many enterprises, the real challenge of implementing this change is that it requires someone with broader authority to rethink and redesign the entire workflow.

Because now you're marketing a "10-minute approval" product. You need to route applications immediately to the approval step rather than processing them a day later. Marketing, data, and infrastructure all need to be involved. Yes, AI can make the initial decision. But the final due diligence and execution steps may also need expanded capacity.

So I've found that bottom-up innovation is very valuable—it generates lots of ideas. But it must be combined with top-down moves, meaning someone with a broader view and authority needs to change how all these steps operate in order to truly create growth. Many enterprises talk about cost reduction.

Cost reduction is fine and worth doing. But I'd rather push people to imagine more imaginative things AI can do—namely, driving growth.

Because the money we can save is always limited, but growth has almost no practical ceiling. So I've found that the more exciting ideas are usually about driving business growth, not just saving costs.

Harrison Chase: Have you seen good examples of AI driving business growth? Are there any cases that particularly excite you, or that you think others should pay attention to and learn from?

Andrew Ng: Yes. The bank example just now is a real case. We're working with some banks and financial institutions on this, and other companies are doing similar things.

Another pattern is customer service and call centers. Customer service and call centers are usually seen as cost-reduction scenarios. Cost reduction is certainly good. But when you can automate customer service, or automate and augment part of it, you can serve more customers faster, thereby delivering a more delightful customer experience and driving growth.

I've also spoken with companies that are automating voice applications for drive-throughs—that is, the ordering process at drive-through restaurants. I think this can likewise deliver a better customer experience and drive growth.

So I see more and more examples like this emerging in different parts of the economy.

There are also some cases I know of, but I don't have permission to discuss publicly. However, based on what I've seen companies doing, I'm very confident that more and more such cases will appear in the future.

How to measure ROI

Harrison Chase: You just mentioned ROI. Based on my many conversations yesterday and today, I know a lot of people are thinking about this, and about how to measure ROI. In some scenarios, like cost savings or call centers, it may be relatively easy to measure. But how would you advise people to think about measuring ROI? Any suggestions?

Andrew Ng: I wish I knew the answer. I've found that the challenge may be that enterprises are extremely diverse. So measuring ROI is like measuring the business itself—it's hard to have a one-size-fits-all answer. That said, one thing is that the projects I'm most excited about are usually measurable, and should be measured—they deserve to be measured.

There are things where we need to "swing for the fences" to create very large value.

In that case, we're not talking about "will this bring 2% growth, minus 1% implementation cost." Some projects have such obvious value that they will visibly transform the business.

Of course, we still need to measure it, especially if you're a public company.

But one thing I've learned: sometimes driving incremental gains is actually harder than driving transformational gains. If you tell someone to improve business results by 2% next year, they might think, okay, the boss just wants me to try 2% or 5% harder.

But if you're looking for ways to grow the business by 20% or 50%, you can't get everyone in the company to try 50% harder. You have to come up with more creative solutions.

This often leads to new ways of thinking.

One thing I've learned at AI Aspire is that many enterprises will literally send us a spreadsheet with hundreds of ideas.

For example, one financial institution sent us a spreadsheet with over 300 ideas, asking us to help them judge which of these ideas are worth actually investing capital in.

It turns out this analysis is very hard. I wish I were smart enough to glance at it and say, this idea is good, that one is good. But when facing so many ideas, it usually takes both top-down and bottom-up brainstorming.

It requires a lot of technical analysis to judge what is technically feasible, and a lot of business analysis to judge what could drive meaningful change.

In the end, you need to narrow these ideas down to a handful of bets worth committing significant resources to.

Harrison Chase: These "swing for the fences" projects—you usually see them driven top-down, right?

Andrew Ng: That's right. I think it's better for companies not to make just one crazy big bet, but to build a portfolio of a few carefully considered bets. If any one of them succeeds, it will have a meaningful impact on the business.

That said, one thing I love about agentic coding is that we can run lots of experiments and keep prototyping. The cost of prototyping has dropped dramatically.

But unfortunately, you can't do everything. With, say, a $100,000 budget, you can't do it all. At some point, it makes sense to commit meaningful resources to each of a small portfolio of projects.

And precisely because resource allocation is needed at this level, it often takes more top-down action to allocate the required resources.

Resident engineers: hype or real demand

Harrison Chase: Recently, a frequently discussed topic in enterprise AI adoption is the Forward Deployed Engineer, that is, Forward Deployed Engineer. Will every company have FDEs in the future? What do you think? Why do you think they're so influential? How will this evolve?

Andrew Ng: In Silicon Valley buzzwords, FDEs are indeed at a moment of high attention. I know Aaron also talked about this topic in depth on stage a day or two ago. I think FDE is a great idea.

Many companies will need this role. But looking ahead, what do you think the ratio will be between the number of FDEs at a company and the number of regular AI engineers the company hires?

I think most companies will have more internal engineers, while possibly embedding a small FDE team. So I like FDEs and am excited about the growth of this role. We should help more people get FDE jobs.

But I also think that, like many things, the hype around it may be slightly ahead of reality. Still, it is genuinely a good thing.

Building agentic workflows is hard. It requires understanding the business and customer-facing capabilities. To make systems reliable, you usually also need to do observability and evals well, work with customers, judge that certain requirements are actually technically infeasible, decide with stakeholders which workflow should be automated, and help the company with change management.

So it's a very valuable role that requires deep technical judgment. Having FDEs embedded in a company can indeed dramatically accelerate projects.

But I also see many companies facing another challenge: is it possible to get a vendor-neutral FDE?

That's actually hard, and it depends on which vendors you want truly embedded in your company. Because in AI, we've seen leading models change very quickly.

I don't know what the leading AI model will be a year from now. And I'm completely unsure what the leading coding agent will be a year from now.

So in times of uncertainty like this, optionality is extremely valuable.

Frankly, many vendors come to our companies offering 20%, 30% discounts, on the condition of signing a three-year contract, things like that.

I'm not giving advice, just sharing how I do things myself. No matter how big a discount is offered, I personally almost never sign contracts longer than a year. Because I value this optionality highly—I want to be able to work with the best vendor at that time a year from now, and right now I don't know who that will be.

When we work with FDEs, one question companies ask is: if you let a few FDEs sent by a certain company embed in your company and have them deeply bind everything to one AI model or platform, how much does that reduce your optionality a year or two later?

I think this is exactly what many companies are thinking about and struggling with. This is also why I've personally used LangSmith many times. I think it's great that Harrison has made LangSmith so easy to use.

These more vendor-neutral tools are extremely valuable. They can help companies with observability, and also help companies preserve optionality over the long term. Vendors are of course great, and companies should work with vendors. But in the long run, preserving your own optionality is just as important.

Build a data strategy before building agents

Harrison Chase: Speaking of vendor neutrality, especially at the model level, we've talked a lot about open-source models over the past few days. What do you think of how these models are developing? How do you see their relationship with frontier models?

Andrew Ng: This is very interesting. Open-weight models seem to have consistently lagged frontier models by about six to nine months. But frontier models are expensive enough that in many use cases, my team also uses open-weight models heavily. Sometimes we fine-tune them, sometimes we don't. So I hope everyone will continue to support open-weight models.

Over the past two weeks, I've heard some things from the White House side that worry me, such as pre-release review of models. I'm actually very concerned about this, and I've been staying in touch with some friends in government.

I feel the war against open-source and open-weight models is still ongoing. Sometimes it appears in the name of "America competing with China," and sometimes under various other pretexts.

But I believe that if we can jointly protect open-source and open-weight models, it will make the world richer and help all of us preserve optionality.

Harrison Chase: I've discussed with some people a question: before building agents around data, it's very important to get the data strategy right first. When you work with companies building agents, they most likely also want these agents to connect to data in some form. What approaches have you seen work well? What do these requirements ultimately boil down to?

Andrew Ng: That's a great question. When talking with large enterprises at AI Aspire, a very common pain point is: they need to rethink their data architecture. Over the past 10 or 20 years, we've invested enormous effort in organizing structured data, like tables, relational data, spreadsheets. That's of course good, and it's still important today.

But now AI can process unstructured data, like text, images, PDF files, audio, and maybe video. How to organize this data so it can be used by AI or agents at the right time and place, and create value, has suddenly become far more important than before.

I've also spent a lot of time watching this market. There are now many vendors talking about how to handle unstructured data, but I haven't yet found a good solution that truly satisfies me.

So in my teams, including AI Fund and AI Aspire, we're running a bunch of somewhat crazy experiments trying to re-architect our own data. If these experiments really work, I may talk more about it later.

But I have indeed spent a lot of time thinking about how to re-architect our internal unstructured data so it can be handed to agents at the right time.

I foresee that, just as many companies once faced very large structured data architecture problems, in the coming years many companies will also have very large data architecture overhaul projects. The scale could reach tens of millions, even hundreds of millions of dollars. The goal is to rethink the data architecture to make data more AI-ready, or rather, more agent-ready.

Unstructured data and the coming architecture overhaul

Harrison Chase: What's the problem with existing data architectures? Why aren't they AI-ready or agent-ready enough?

Andrew Ng: There are many problems. First, fragmentation and governance issues—data is scattered everywhere with no unified consensus schema. Some data is even sitting on someone's laptop.

There are also permission issues. Many permission systems were originally designed for humans, not for agents. So does an agent inherit my permissions? How do we manage governance and observability?

I think we've all seen this situation: many enterprises have huge numbers of PDF files piled up in massive storage buckets, untouched for the past 20 years. In financial services, many documents are kept for compliance reasons. Nobody used to have time to look at them, so there was no point in reading them. But now, if you have AI organize and analyze this content, it becomes extremely valuable.

By the way, a small point—this isn't entirely part of the data architecture topic, but I think CJ will speak next. I'd like to share a little lesson I learned in AI coding. I hope CJ doesn't mind me saying this. I personally use MongoDB quite often.

Of course we all love relational databases. But I've found that when I'm rapidly iterating and prototyping, redesigning the database schema is really annoying.

We've probably all experienced that situation: you ask AI to do a database migration, and it does something "clever," like deleting the entire database. While this almost never happens, it's not impossible, which is a bit annoying.

So I've found that with NoSQL, I can throw any data I want into the database first, and then handle the schema at read time, rather than fixing the schema at write time. This makes me iterate much faster. Of course, NoSQL isn't always suitable for the largest production workloads. For very large enterprise-grade production systems, I'll eventually use relational databases more, or more scalable solutions.

But I think NoSQL today is more scalable than many people realize, and it enables a faster iteration cadence.

Sometimes I get especially frustrated: I've already designed a database schema, and then suddenly realize, oh no, I want to add a field. Then you have to refactor the entire database, which is really annoying.

So I think these are all examples of us adjusting our workflows for faster iteration. Since AI agents write code so fast, we shouldn't let other things slow us down.

Original video link: