The rapid advancement of AI, particularly coding agents, is accelerating software development, leading to bottlenecks in other areas like product management, marketing, and legal. This necessitates a shift towards highly empowered, generalist engineering teams capable of leveraging AI to handle broader responsibilities and drive transformative business growth.
Mind Map
Genişletmek için tıkla
Tam etkileşimli Mind Map'i keşfetmek için tıkla
Thank you for being here, Andrew.
It's great to have you back for year two.
It's good to be back.
It's always been such a cool gathering that you put together.
I was telling you this earlier, but Andrew's fireside chat last year was the most liked
and the most watched on YouTube afterwards.
So we're thrilled to have him back for year two.
Yeah.
[APPLAUSE]
Maybe jumping off of that, in the year
since we've been here, I feel like there's
been a ton that's happened in the AI space.
What has happened faster than you would have expected,
and what's been slower?
So I think the hype has exceeded my expectations.
And then also the doomsaying narratives also got more traction, unfortunately,
that would have guessed, including the job apocalypse, which I don't think is going to be a thing.
And on the more positive side, coding agents probably took off faster than I would have guessed.
And the frontier coding agents, I know the hype is that everything AI changes every three months
or whatever, and that hype isn't entirely true, but that does feel true for coding agents
where it feels like the frontier of what we can do
with coding agents and it's so competitive.
I think six months ago, I was almost all Claude Code.
These days, I'm still a lot of Claude Code,
but also increasingly open AI codex,
with a mix of Gemini CLI and one
of the supports of open code as well, because it's open code.
So the mix of coding agents we use
has been changing rapidly.
I wouldn't have guessed a year ago
that I'd be coding so much on my phone as well.
So these workflows, like many of you
have a Mac Mini in my office.
So all these workflows changing really rapidly.
And then agentic workflows are really
starting to make their way into enterprises.
That feels pretty good as well.
So on that note on the software engineering note,
what does the future of software engineering
look like in your mind?
So about a year ago, I was writing about the product
management bottleneck, which is this observation
that if building becomes much faster,
then deciding what to build or the product management work
of scoping the project, we're getting customer feedback,
deciding what to build, becomes the bottleneck.
It feels like over the last year,
the product management bottleneck has become much worse
in a good way because software building
has become much faster.
But it turns out when writing software becomes 10
or 100 times faster, not only is there
product management bottleneck, pretty much everything else
becomes a bottleneck.
So some of my teams have seen the marketing bottleneck,
because we can build so many features,
our marketers are struggling to figure out
what a new feature did in order
to figure out how to communicate it.
Previously, if you had a product that needed legal compliance,
if you took three months to build it,
waiting a week for legal to sign off is maybe OK.
But now, if you're building a day,
then wait a week for legal to sign off,
that's a legal compliance bottleneck.
And there's design bottleneck and so on.
So I think a lot about how software engineering teams
in the future will be organized,
and I don't think I know the answer.
But increasingly, I find myself setting up
very small parts, you know,
anywhere from one to 10 engineers in a team,
I've often generalist, high context,
highly empowered generalists,
that are given a set of very wide guardrails
within which they can just run like crazy
and build in ship code, and even drive decisions
like writing, marketing, copy that are traditionally
outside the purview of engineering.
Maybe by definition, let's say you
have a team that needs software engineering, product
management, a little bit of you need
to need terms of service, needs some marketing copy,
you need some design.
So you need five functions represented
in a team of two humans.
Then by definition, or by the pigeonhole principle,
these two humans have to play more than a single role
for human.
But the good news is it turns out,
I don't think I'm a very good marketer.
But when I use AI, I'm still not a good marketer.
But I'm slightly less bad compared
to what I had to do with my AI assistant.
So I find these small teams of high context
generalists that are deeply technical
but able to use frontier technology
to do a little bit of other roles as well.
Like, everyone had engineers, frankly,
use AI to take the first draft of a terms of service,
to then take to a lawyer for the lawyer
to finally polish it before it goes out.
But I find that these processes allow
teams to move much faster.
So that's been really exciting.
- And what's the right background for these folks?
Are these engineers by background?
Are they coming in from different disciplines
and learning to code for the first time?
What are you seeing here?
- Yeah, so a lot of the people I work with most closely
have deep engineering and technical expertise.
And then also are highly empowered, slight generalists
that step into other roles and acquire
this mix of skills, often with AI supporting,
where they didn't have that training.
I think people can succeed from any direction.
I've seen your product managers become much stronger
at coding and then participate in these teams.
I think just because so much of AI coding and engineers
maybe had a natural advantage, understanding
the frontier tech.
So I see engineers play this role successfully the most
often.
But there's definitely a smaller number of product managers.
I've seen marketers learn to code in pretty effective ways.
I've seen operations people start to build more and more
products.
I think it's actually possible for people of any background
to learn to do a lot of this.
But the largest number of bodies doing this well right now
seems to be people that came from an engineering background.
But we encourage everyone from whatever background
to see if we can play these roles.
What advice would you have for folks
who are trying to get more into this new software engineering
space, whether it's particular tools to try or mindsets to have
or skills to pick up?
Yeah, so this one way I've been thinking about the future
of software engineering, this is a mental model I have in my head,
which is that because of a lot of providers of many tools
like RAG, agent framework, things like evals, God rails,
It turns out that the--
oh, as well as-- so these are AI building blocks.
They're also non-AI building blocks,
things like user interface components or identity
of mechanisms and front and back end persistence databases
and so on.
So I think that in computer science,
we've always had a wonderful set of building blocks.
And with agentic coding, building blocks
are proliferating because more and more people
are building open source or proprietary API base
or whatever types of building blocks.
So there's just wonderful building blocks all around us.
And so I find that developers that
have a good mastery of enough building blocks
can often put them together in combinatorially many ways
to very rapidly build software.
Maybe you have a picture of building with LEGO bricks.
If all I have is like a white colored LEGO brick,
I can build some stuff that's not that interesting.
But I'm mixing a black LEGO brick, a yellow one,
and a brown one, and a green one, and throwing
some squiggly pieces of Lego, then what I can build
grows combinatorially or grows exponentially
as a function of the number of Lego bricks I have.
And I think of a lot of the building blocks
we now have access to as being akin to that too.
So I find that the developers, they're able to have
a good sense of what these building blocks do.
And DeepLearning.AI offers a lot of long form short courses
to help people master these wonderful building blocks
provided by tons of people.
And then the other challenge is to use coding agents
to rapidly assemble these building blocks
into the software that you want.
One challenge that coding agents have
is a lot of building blocks are so new that the coding agents
do not know how to use them.
I think until recently, the leading coding agents
where nano-banana was released after the knowledge cut-off
date of a lot of leading models.
So it's just a new idea of how to call the nano-banana API.
even knew that nano-banana existed.
So one project that one of my friends, Rohit Prasad,
and I have been passionate about is Context Hub,
which is kind of a stack overflow for AI agents,
for AI agents to get the latest documentation
on what are the latest APIs, SDKs, building blocks
they can use, as well as a way for agents
to give feedback to the documentation
to try to improve it for everyone.
And so it turns out there are a number of APIs
that I personally use that I find the syntax slightly annoying
to remember.
But I find that by using Context Hub to load the latest
docs, I let the coding agent actually make all of these API
calls for me.
And so it actually has helped my own coding work
accelerate quite a bit.
Maybe two notes there.
We also launched something called Context Hub.
So we're colliding on names, but it's a very different type
of Context Hub.
And so, yeah, his is much more useful
for working with coding agents, so you should go to use that.
And then deep learning.
So I think we at LangChain were the second people
behind OpenAI, I wanna say, to DeepLearning.AI class.
And I know, I've talked to so many people
who have heard of LangChain through deep learning,
and I'm sure a lot of the audience members here as well.
So if you haven't tried out deep learning,
you should absolutely go take some courses.
Maybe on that note, how do you think about education
changing in this new world of AI,
and have you started to bake any of those practices
into how the deep learning courses are run
or how you think about that?
- Yeah, so we're trying a lot of ways
to improve the education experience.
So in terms of training, the thing that's clear
is that what people have to learn
has changed significantly.
I think for developers, with the learning coding agents,
learn these building blocks,
maybe learn some product management
or these types of general skills
to make us more effective.
So what we learned is changing.
And DeepLearning.AI, Coursera, and we've tried
to provide a lot of that training.
But separately from what to learn,
there is the delivery of training.
And it feels like we've been thinking
about how we'll learn and transform for a long time.
And it feels like it's actually not quite here yet.
One thing we launched just several weeks ago
is a new website in our preview called CodeDream.ai,
in which the vision was rather than taking an online course,
come and have a conversation.
This is not a course, it's a conversation
where the experience you tried to build was for you to come
and get on a simulated video call with me,
say, where if you feel like leaning back and listening
to me talk and present to you in a one-on-one video, similar to video call, about context
health and coding agents, you can lean back and I'll just show you some ideas. Or if you
want to interrupt, you know, me, you interrupt my AI and ask a question, you could do so
at any time. And one thing I actually personally play around a lot with is replacing videos
and slides with JavaScript. And what that means is instead of a video, when I present,
I demo something in a video, if you could click into the video and type your own prompts
or type your own queries into the video window.
So instead of a static video that just plays, the video area is interactive and this creates
more ways for people to interact.
So check out code dream.ai if you want and have a kind of a conversation with me or with
my AI where I'll present to you in AI form how to use Context Hub's coding agents.
I think we're still, we're actually frankly still iterating and improving these experiences every day.
Is that clicking into the video and typing, is that live today or is that more of a future direction?
That's live. So imagine if instead of me screen sharing in a video, I am, you know,
JavaScript sharing in a video and so you can interact with whatever I'm called screen sharing
because it's running JavaScript code, not a canned video. So yeah, we're still, actually,
If you have a favorite, we'll love your feedback.
But it feels like I think the transformation of education
has been over-hyped.
I think something is coming.
But today, taking online courses,
I wish we had something way better than online courses.
And I will say we have something better than the courses
we had 10 years ago.
They're much more interactive.
It turns out for a lot of our courses, this morning,
we just launched a new course on Transformers,
by AMD Sharon Jo.
And I find that rather than just having videos, which
is mostly what we had a decade ago,
we now built much more interactive visualizations.
There's a lot more fun stuff to play with than courses
had a decade ago.
But that bigger transformation, I actually
spent a lot of time thinking about that.
Maybe going from software engineering to everywhere else,
How do you see enterprises adopting AI
and is it faster than you expected, slower?
What's the right way to do it?
What lessons can people learn?
- So I think every enterprise, I'm guessing all of yours,
are excited about AI adoption.
One thing we've seen is over the many businesses,
one of my teams, AI Aspire,
which is an AI advisory firm
that my business partner, Chris Tann, and I co-founded,
We talk to large businesses all the time,
sort of largest kind of Fortune 50, Fortune 500,
G2000 businesses about the AI strategies and transformation.
So some consistent themes, right?
All of us have invested in the bottom-up innovation,
that a thousand flowers bloom strategy,
and for the most part is not paying off.
So CEOs and boards are asking, where is the ROI for AI?
I think we should keep on investing in bottom-up innovation.
Let's keep on doing that.
But it turns out that bottom-up innovation often results in point solutions that drive
incremental efficiency gains, which are actually a good thing, but not the transmission, not
the broader transformation that AI has been promising us and that I think we should work
to deliver.
So just to illustrate this as an example, my team is working with a number of banks.
We actually do a lot of work on financial services, but we work with a number of banks,
and if you think about the process of underwriting a loan, there may be five steps.
You got to market the loan product, get the application,
review and approve the loan, do the final diligence,
and execute the loan.
So there's the five steps of that.
Number of teams have noticed that the step
in the middle of loan approval, we could use AI to do that.
And if we could automate that, then instead of a human
spending an hour reviewing the loan application,
we could have AI do it with--
and that's great.
We should absolutely do that.
But it turns out that if your entire process
underwriting the loan stays the same except for automating
what was previously one hour of human time.
That's a small incremental efficiency gain.
So what a number of banks have said is, you know what,
instead of doing this efficiency gain, which is worthwhile,
let's rethink the entire workflow and market a get approved
in 10-minute loan product.
Because rather than waiting around for a week for a human
to be free for an hour, we can send the loan application,
the AI right away for a decision.
But the challenge with implementing this
in a lot of businesses is, this takes someone
with a broader scope to rethink and redesign
the entire workflow.
Because now you have to market a get approved
in 10 minutes product.
You have to route the application to approval,
not in a day, but right away.
So marketing data infra needs to be involved.
Then yes, AI can make the initial decision.
And then final diligence execution
probably needs to scale up as well.
And so I find that bottom-up innovation is really valuable.
It generates lots of ideas.
But often it takes--
and that has to be complemented with a top-down motion
of having someone with the broader scope
to change how all of these steps operate to then
create growth.
And I find that many businesses talk about cost savings.
That's fine.
It's worth doing.
But I try to push for more imaginative things
we could do with AI, which is drive growth.
Because we can only save so much money,
but growth has almost no practical ceiling.
So the more exciting ideas I find
usually relate to driving business growth rather than
savings.
Are there any good examples of driving that business growth
that you've seen that you're particularly excited about
or think other people should look at and learn from?
- Yeah, so let's see, the bank example is a real one, right?
We're working on our banks on that
and financial institutions on that
and other businesses have also done that.
I don't know, I find that,
let's see, maybe one other pattern,
customer service, contact centers.
Often viewed as a cost savings thing
and you know, that's fine, cost savings are nice,
but when you can automate customer service
or automate or augment part of it,
then the ability to serve customers many more much faster
that delivers a more delightful customer experience
and drive growth.
I think that actually speaking with a number of businesses
that have been working on automating the drive through
voice application, drive through order process,
I think that also results in the more delightful
customer experience and drive growth.
So I'm seeing that there are more and more of these examples
popping up in different places of the economy.
There's some I know about that I don't know
that permission to talk about,
but I'm actually pretty confident
with the number of things business are working on
that there'll be more and more examples of these things.
- You mentioned ROI earlier,
and from a lot of conversations
that I've been having yesterday and today,
I know a lot of people are thinking about that
and thinking about how to measure that.
And I don't actually know if, in some scenarios,
maybe in the cost or in the call center,
it's maybe easy to think about measuring that,
but how would you advise people
to think about measuring ROI and any advice for them there?
- Yeah, I wish I knew.
I find that, I think probably challenges,
businesses are so diverse.
So measuring ROI is like measuring business,
which is very hard for a one-size-fizzle answer for.
But there's one thing, I feel like the projects
that excite me most are measurable,
should be measured, deserve measurement,
But there are some things where we swing for the fences
and create so much value.
We're not debating the disk drive 2% growth
and then minus the 1% cost of implementation.
It's just glaringly obvious this is transforming the business.
And of course, we still need to measure it, especially
when we're publicly traded, company, blah, blah, blah.
But I find that those things are to really--
there's actually one thing I've learned.
Sometimes driving incremental gains is harder than driving transformative gains.
Because if you tell someone to improve their business results by 2% next year,
then they're like, all right, my boss is telling me to work 2% harder or 5% harder or
whatever.
But if you try to search your ways to drive 20% business growth or
50% business growth, then you can't just get everyone to work 50% harder in the
company and you have to come up with more creative solutions.
that often leads to, oh, just one lesson I learned.
At AI Aspire, we've had many businesses
literally send us spreadsheets with hundreds of ideas.
Like, so I'm solving one financial institution
that sends us a spreadsheet with over 300 ideas
and asks us to help them sort out of these 300 ideas,
which ones to put real capital to invest behind.
And it turns out that the analysis is really difficult.
I wish I was smart enough to glance through it and say,
Oh, this idea and this idea.
But I find that when faced with that many ideas,
often brainstorming the top, down, and bottom of motion,
is actually a lot of work to do the technical analysis
to figure out what is possible.
And then also the business analysis
to figure out which ones could drive meaningful change.
And then it's actually a lot of work
on the technical and the business analysis
to narrow it down.
There was a small handful of bets
to put very meaningful resources behind.
- And these swing for the fences type things,
you're often seeing these being the top down ones.
That's correct.
- Yeah, I find that businesses, hopefully not take one
wild swing for the fences, is more a portfolio
of a handful of thoughtful beds where if anyone pays off,
it will be meaningful for the business.
But it turns out, one of the things I love about
agentic code is we run tons of experiments,
we're a prototype all the time.
So the cost of prototype is plummeted.
But sadly, you can't do everything, right?
on a $100,000 budget, and at some point,
putting meaningful resources behind every one
of a small portfolio of a handful of projects
does make sense, but so because of the resource allocation
needed at that level, it often takes a little bit more
of a top-down motion to allocate the amount of resources needed.
- One of the things that I feel like has been talked a lot
recently about enterprise adoption of AI
is for deployed engineers.
Will every company have forward deployed engineers?
How do you see, why do you think they're so impactful
and how do you see this playing out in the future?
- So I think the Silicon Valley buzz, you know, things,
definitely having a moment of FDEs.
I think, and I know Aaron was on stage,
he really very thoughtful to hear about it
like one or two days ago as well.
So I think FDEs are a great idea.
And many businesses, but I think looking at the future,
what do you think is a ratio of FDEs in the company,
versus the number of just AI engineers employed by the company.
I think that most businesses will have a lot more in-house engineers
and a smaller team of FDEs maybe embedded.
So that's why I like FDEs.
I'm excited about the growth.
Let's help more people get jobs as FDEs.
But I think the hype is also, as is often the case, a bit greater
than the actual reality.
But it is a good thing.
But building agent work flows is hard.
It requires understanding of business.
It requires customer-facing skills, often to make it reliable,
get to drive observability, evals,
work with the customer to push back,
or something that's not actually technically feasible,
work with the stakeholders to figure out what workflow
to automate, help with the change management.
So this is a very valuable role that
takes deep technical judgment.
Having FBEs embedded can really accelerate projects.
There's one other thing I see as challenging
for a lot of businesses, which is,
is there any way to get a vendor neutral FDE, right?
That turns out to be challenging,
and depending on what vendors you want to be
really embedded with, because what we see in AI
is that the leading AI model rapidly changes.
So I have no idea what would be the leading AI model
a year from now.
I'm actually not at all sure what would be
the leading coding agent a year from now.
And so in moments of uncertainty like this,
optionality is very valuable.
So candidly, many vendors are coming to all of our businesses
and offering 20%, 30% discounts, but signing a three-year contract,
right, whatever.
Not giving any advice, just saying what I do.
I personally almost never signed longer than a one-year contract,
regardless of the discounts offered,
because I value that optionality to work with whatever vendor
would be the best in the year's time that I don't know about.
And then when we work with FDEs, one question
that I think businesses are asking
is when you have a handful of FDEs
from one company in your company,
how much does letting them embed everything
with one AI model or whatever, reduce your optionality
one or two years from now?
So I think these are some of the businesses
that companies are wrestling with.
And this is why I--
I think I personally have used Lang Smith a bunch of times.
I think Harrison did a great job making it so easy to use.
I think those types of more vendor neutral tools
are very valuable for observing, maintaining
optionality for the long term.
And the vendors are great.
Work with the vendors.
But preserving optionality for yourself in the long term
also seems important.
- On the topic of kind of like vendor neutral,
especially in the model space,
one of the things we've talked about a little bit
throughout the past few days is kind of like
open source models.
How do you see those progressing and do you see them,
how do you see them relative to the frontier models?
- Yeah, yeah, it's been fascinating
how it's remained persistently.
I'm gonna say like maybe six to nine months
behind the frontier models,
but the frontier models are expensive enough
that for many use cases,
My teams use a lot of the open-weight models, sometimes fine-tuned, sometimes without fine-tuning.
So I hope we can all keep on supporting the open-weight model.
Over the last two weeks, I've been concerning noises out of the White House about inspecting models before their release.
I'm actually quite concerned about that in touch with a few friends in the administration about this.
And I feel like a lot of war on open-source open-weight models is still being waged,
sometimes in the name of US China,
or sometimes in the name of whatever arguments
people are coming up with.
But I feel like if we can all protect open source, open weight,
it will make the world much richer,
and also help all of us preserve optionality.
One thing I've discussed with a few folks
is basically the importance of getting the data strategy
right before building agents around them.
And so as you work with companies
who are building agents and presumably want those agents to connect to data in some form.
What have you seen work well there?
What does those requirements boil down to?
Yeah, this is a great question.
So when AI Aspire, we meet with large businesses, one very common pain point is rethinking the
data architecture.
Because over the last 10, 20 years, we've put so much effort into organizing our structured
the data, the tables, relational data, the spreadsheets.
And that's great.
That's currently important.
But now the AI can process unstructured data--
so text, images, PDF files, audio, maybe video--
organizing that to get it to AI or agents in the right time,
in the right place, for it to create value,
is suddenly much more valuable than it used to before.
And I've done a lot of work looking at the market.
There are many vendors starting to talk
about dealing with unstructured data,
but I've not been able to find a single good solution
that I'm actually politically satisfied with.
So within my teams, AI Fund, AI Aspire,
we've been running a bunch of crazy experiments
in building rearchitects of our own data.
If it ever works, I'll probably talk more about it.
But I should spend a lot of time thinking
about how to rearchitect our own internal unstructured data
to get it to the agents, for the agents to use at the right time.
I actually foresee that just as many businesses had very large data architecture problems,
data architecture kind of a work to reorganize the structured data, over the next few years
there will be very large, I'm going to say tens of millions, maybe hundreds of millions
of dollars types of projects in many businesses to rethink the data architecture to make the
data more AI ready or more agent ready.
What's the issue with their existing data architecture that doesn't make it AI ready
or agent ready?
Boy.
Now, fragmentation, governance, data's over the place, no consensus scheme, some of this
sitting on someone's laptop, the permissions were designed for humans, not for agents,
so did agent inherit my permissions, how do we manage governance and observability?
I feel like, we've all seen, right?
So many businesses have massive, you know,
buckets of tons of PDF files that no one's looked at
for the last 20 years.
You see in financial services,
a lot of documents are retained for compliance reasons.
So previously, there was no point looking at it
'cause no one had the time,
but sorting that out of AI to look at
turns out to be really valuable.
Oh, by the way, one small thing.
This doesn't actually the whole data architecture thing,
but I think CJ is speaking links.
- Yeah.
- I just wanna say one little lesson I've learned
for AI coding, hopefully CJ will be happy,
I'm saying this, I personally use MongoDB a lot.
Because, let's see, MongoDB, because,
we all love relational databases, right?
But I find that when I'm iterating and prototyping rapidly,
the need to redesign the database schema is so annoying.
And we've all had that, one in a hundred times
that we asked AI to do a database migration
and did something clever like,
erase my whole database instead, right?
Almost never happens.
But the fact that it almost never happens but doesn't never
happens is a little bit annoying.
So I find that having a NoSQL where I can dump whatever
data I want into a database and then figure out the scheme
when I'm reading it rather than when I'm writing the database,
it lets me iterate much faster.
NoSQL doesn't always scale to the largest production
workloads, so the very large production
of those enterprise rate, eventually, you know,
I use more relational databases,
more very scalable solutions.
But I think NoSQL is more scalable
than most people realize these days,
and it drives that pace of iteration.
Maybe I just get so frustrated if I've designed, you know,
some database scheme, right, go, oh, shoot,
I want to add a field.
It's just so annoying to have to refactor the entire database.
So I find that these are examples of the workflow
that we're all making to drive faster iteration,
to take advantage of the fact that AI agents
can code really fast.
So let's not get slowed down by these other things either.
- Yeah, it's interesting how coding agents change
not only what we do, but also the technology choices
that are good for what to build on top of.
I think I speak for everyone when I say,
thank you so much for being here,
thank you for sharing all your thoughts,
and thank you for all you do for the ecosystem.
- Thank you, thank you all so much.
(audience applauding)
[BLANK_AUDIO]
Videodaki o ana atlamak için herhangi bir metin veya zaman damgasına tıkla
Paylaş:
Transkriptlerin büyük çoğunluğu 5 saniyeden kısa sürede hazır
Tek Tıkla Kopyala125+ Dilİçerikte AraZaman Damgasına Atla
YouTube URL'sini Yapıştır
Tam transkripti almak için herhangi bir YouTube video bağlantısı gir
Transkript Çıkarma Formu
Transkriptlerin büyük çoğunluğu 5 saniyeden kısa sürede hazır
Chrome Uzantımızı Yükle
YouTube'dan ayrılmadan transkriptlere anında eriş. Chrome uzantımızı yükle ve izleme sayfasında tek tıkla herhangi bir videonun transkriptine ulaş.
