AI Engineer World's Fair 2024
AI Engineering Without Borders
Read the talk
AI Engineering Without Borders
AI engineering needs useful categories, but its durable foundations lie in human constraints, changing model capabilities, and turning those capabilities into tools people can use.
From a talk by swyx
A piece of paper determines whether you can cross
Without the right piece of paper, you cannot cross a line in the sand. The border is a human convention, but its consequences are real: documentation determines where a person can go. That tension opens swyx’s keynote—boundaries can govern our lives without being inherent properties of the world.
AI crosses several boundaries that people treat as separate domains. In swyx’s account, training on predominantly English text can still produce multilingual capabilities; the corpus need not be evenly divided among languages. Modality boundaries are similarly permeable. He cites turning Llama into a vision-language model with roughly $100 of post-training, without specifying the model version, training setup, cost scope, or resulting quality. The point is that a model’s initial modality need not permanently define what it can become.
Other boundary crossings are less welcome. Fluent generation does not reliably distinguish a hallucination from information memorized in a model’s world representation. Copyright is another boundary that model behavior does not automatically respect, although the keynote leaves that topic aside. Crossing boundaries creates both capabilities and engineering obligations.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What does an AI engineer do?
For someone identifying as an AI engineer—or trying to hire one—a definition has practical value. One familiar definition draws a line at the model API: it helps separate the responsibilities of people building models from those applying them. That boundary can organize a team even if it does not fully describe the discipline.
There are other useful ways to organize the work. At an earlier AI Engineer Summit, swyx distinguished the AI-enhanced engineer, the AI products engineer, and the non-human agentic AI engineer. A hiring discussion can instead start from job descriptions, as in Elicit’s conversation on How To Hire AI Engineers.
| Definition | What it organizes |
|---|---|
| API boundary | Where team responsibilities meet |
| Engineer subtypes | Different relationships between AI and engineering work |
| Job descriptions | Roles and expectations within a team |
These definitions answer different practical questions; none necessarily exhausts what AI engineering can become.
A workable definition is not yet a shared foundation. Stopping at “you have your perspective, I have mine” leaves no common basis for deciding which claims hold across teams and viewpoints. The next question is what remains true when the organizational boundaries change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
As the field matures, its concerns multiply
Conference programming makes these definitions concrete. In a conversation with Raza Habib, swyx described AI Engineer conferences as his highest-stakes expression of what the field currently is. Earlier tracks covered retrieval-augmented generation (RAG), code generation, agents, and multimodality. Those topics remain, but they no longer encompass all the concerns a competent practitioner must hold together.
The analogy is Inside Out: maturity adds more concerns to juggle. Once an application works, the engineer may need to migrate to open models, build evaluations—and reconsider whether those should have come first—scale inference, or deploy into a Fortune 500 organization. These are overlapping responsibilities, not successive replacements for the original application techniques.
Management adds hiring AI engineering teams and setting company AI strategy. Alongside the technical and organizational tracks sits the community itself. Its value cannot be established just by advertising that a conference has a good network; people have to experience it. Shared photos and posts also let those outside the venue participate, including swyx, who is addressing the gathering remotely.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tracks are invented; constraints are discovered
The difficulty with treating those tracks as fundamental divisions is knowing how they were made. Looking back at The Rise of the AI Engineer on its first anniversary, swyx finds a list of disciplines that largely became the topics of his conferences and meetups. The categories began as an organizing choice.
Why separate agents from code generation, when an agent can generate code? Why separate RAG from open models, when a system can use both? A competent AI engineer needs familiarity across these areas. Conference organizers draw one set of boundaries; employers draw another. Neither set obliges reality to behave accordingly.
Physical regularities offer a different standard. An alien civilization arriving on Earth would discover the same gravity, solar energy, and magnetic field, regardless of its institutions or preferences. That thought experiment supplies the test: which foundations of AI engineering would independent practitioners discover again, even if they started with different categories?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Engineering connects constraints to human benefit
To look for those foundations, swyx compares definitions of software engineering with broader definitions of engineering. The software definitions he attributes to IEEE and Google Developers emphasize design, implementation, testing, documentation, and lifecycle management. The broader engineering definitions he cites emphasize applying natural sciences for humanity’s benefit. His criticism concerns the emphasis of those particular software definitions, rather than establishing that software engineering as a profession lacks obligations to people.
AI engineering sits somewhere between these descriptions: software practice encountering more of the real world’s constraints than a typical software engineering career might demand. The resulting question is not merely how to implement a system, but what constraints govern it and what human purpose it serves. The proposed “laws” that follow are starting points for debate, not a complete theory with the status of physics.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Human rates and temporary technology baselines
Start with the person using the system. Swyx uses 80 spoken words per minute versus 200 read words per minute as a design heuristic, not a universal human limit. The disparity matters: speech and text interfaces have different throughput needs because people consume them differently. A generation rate that suits one interaction mode need not suit another.
Then separate relatively stable human constraints from contingent facts: things that are true for now. Apple Intelligence supplies the example. Swyx cites Apple’s advertised 30 output tokens per second for local inference. Apple’s foundation-model report places that historical measurement on an iPhone 15 Pro, before speculative decoding; it is generation throughput, not prompt-processing speed. His broader argument is conditional: if local models become widely available on phones, their performance establishes a practical baseline for intelligence cheap enough to treat as an everyday utility.
These baselines also change. Swyx adds trends as a third category, invoking Moore’s law as an analogy for planning around sustained technical progress. Unlike gravity, these are not physical laws. Their usefulness lies in helping an engineer avoid bets that depend on an obvious, improving limitation remaining fixed.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Plan for better context use and cheaper intelligence
Context is the first trend. Swyx recalls discussing MPT-7B with Mosaic a year earlier: roughly 60,000–70,000 tokens of context, with what he describes as substantial loss. The long-context example corresponds to the specialized MPT-7B-StoryWriter-65k+ fine-tune, rather than the base model generally. He contrasts that earlier capability with people in the audience who have trained million-token context windows.
Context length and context utilization are different capabilities. A larger window tells you how much material can be supplied; it does not establish how reliably the model uses that material. Swyx points to the recently released Claude 3.5 Sonnet as evidence of improving utilization. His description of complete utilization is an assessment of that progress, not a guarantee that every token will be used correctly across tasks. The engineering trend to watch is therefore both capacity and effective use.
Cost is another changing constraint. Swyx reports a 99.55% decline in the cost of GPT-3-level intelligence over the preceding two years. He tentatively estimates an 80–90% decline for GPT-4-level intelligence, referencing GPT-4, Llama 3, and newer models. These are historical comparisons without a specified capability benchmark, workload, pricing basis, or serving conditions. They support his commodification argument, but do not supply enough detail to calculate a particular application’s savings.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Utility needs its own dimension
Where does this leave AI engineering among competing AI philosophies? A line between effective altruism (EA) and effective accelerationism (e/acc) might place engineers somewhere in the middle: concerned about safety, while also wanting progress. But that single axis does not express the purpose of the work.
Swyx proposes a second dimension: utility. His phrase is “utility maxis”—people who look at available capabilities and want to use them for humanity’s benefit. Safety and acceleration remain concerns, but neither alone answers what useful thing an engineer will build.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From an untamable monster to mass transit
Working across boundaries begins with questioning the ones already in your head. Avoid personal dogma, easy consensus, and passive reactions. Disagree with your own conclusions, with peers productively, and with the status quo. That makes a conference more than a social occasion: it can become a point at which an engineer’s understanding and career change direction.
The closing image is a Shoggoth, the monster used as a metaphor for an unfamiliar model beneath its friendly interface. An AI engineer looks at it and sees the possibility of mass rapid transit. The ambition is to turn a difficult force into a tool that people can use, rather than stopping at the judgment that it cannot be tamed.
That ambition requires movement between the categories people have created. Jump between conference tracks, friend groups, disciplines, and modalities. A gathering like this offers room to make connections outside the boundaries of a job—and to discover what becomes possible when those boundaries no longer determine whom you learn from or what you build.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The original essay proposing AI engineering as a discipline and outlining its emerging tools and responsibilities.
Elicit's discussion of AI engineering skills, team roles and hiring, with a companion podcast and hiring materials.
Apple's technical overview of its initial on-device and server models, including iPhone inference optimizations and measured generation speed.
MosaicML's original model-family announcement explains the long-context StoryWriter variant and its training setup.
The historical announcement for the first Claude 3.5 Sonnet release.
Further reading
A meta-analysis of silent and oral reading rates, including variation across readers and tasks.
- Software Engineering Code of EthicsDocumentation
The IEEE-CS/ACM professional code places public interest, safety and welfare among software engineers' obligations.
Read the complete timestamped transcript
- 0:00
[on-hold music] I've been thinking a lot about borders recently for no particular reason.
- 0:17
Uh, and borders are a very innately human thing. If I don't have the right piece of paper, I cannot cross this line in the sand. Like, it's a very, very real problem that I face and many, many people face every single day.
- 0:28
And borders are just one kind of constraint that humans just make up. And I think that's very interesting that we respect borders so much, but AI does not. AI is a border disrespector.
- 0:37
It is very, very easily multilingual. [lip smack] So if you trained an LLM on mostly t- mostly English text corpus, it's gonna learn other languages just as a side effect. It's going to be very natively multimodal because you can, you can turn Llama into a vision-language model with just, like, a hundred bucks of just post-training. [lip smack]
- 0:56
There's-- It's very, um, disrespecting of ground truth borders because it can just-- it doesn't know the difference between hallucination and memorizing from a world model. And it also doesn't respect copyright, which is a whole other topic that we won't get into today, but it's also super fascinating.
- 1:11
And how does that relate to do with AI engineering, right? Like, I think a lot of you here are here because you are interested in that concept, at least.
- 1:17
Maybe you identify as an AI engineer, maybe you're trying to hire an AI engineer.
- 1:22
So there're a lot of definitions floating around, and I, I confess that, you know, I've, I've contributed to that. Um, is AI engineering a, a, an API line, right?
- 1:29
That's the, that's the line that a lot of people have, and that's come under some debate recently. And yeah, that, that's one form of AI engineering, and I think that is useful to some people for understanding, like, where the responsibilities in a team might stop and end and start with, uh, the other people on the team.
- 1:43
Or maybe it's there's different subtypes, right? Like la-last AI Engineer Summit, I talked about the three types of AI engineer that I was seeing emerge: the AI-enhanced engineer, the AI products engineer, and the non-human agentic AI engineer.
- 1:58
Or it could be a job description that maybe you try to sort of list out, and this is something that, um, on the Latent Space podcast we recently went through with Elicit, talking about the different roles that they see within their teams as well.
- 2:10
So, okay, if I broadly have any of these three things, do I-- have I nailed down a good definition of AI engineer that is workable? Yes, right. But is that something that we're happy with?
- 2:19
Is there something that we can-- Is there, is there nothing left to explore? I think the answer is no. I think there's more to explore. I think the very easy cop-out as well for people discussing this is that you have your opinion, I have my opinion.
- 2:31
You come from your point of view, I come from my point of view. We agree to disagree, or we agree that, you know, the, the different, different strokes, different folks, and then we move on.
- 2:39
Um, I don't really like that just because there's no shared agreement on the things that is ground truth to everybody.
- 2:47
So I want to raise that challenge a little bit more. I was in a podcast with Raza Habib, who's one of the speakers today, talking about what this conference is and why this conference is-- does what it does.
- 2:58
And I always say that AI engineer conferences are effectively my highest stakes expression of what I think the state of AI engineering is. So this time last year, twenty twenty-three, AI years are two times of human years, [chuckles] um, uh, we had a few tracks.
- 3:13
We had a few topics that were up for debate. We had RAG, Code Gen, and then agents and multimodality. Um, all those tracks are repeated here today. I have some speakers, uh, illustrated here just for illustrative purposes.
- 3:23
These obviously are not every, not everyone involved. [lip smack] Um, but I think just like the inside out metaphor that, uh, I've been thinking a lot about, um, as the AI engineer matures, so does the number of concerns that you have to juggle in your head.
- 3:36
So this year, you know, after you're a competent AI engineer, this year you're now faced with, like, "Okay, I have to migrate to open models. I have to build up my evals.
- 3:44
Maybe I should have done that first." That's a whole topic of discussion. "Maybe I should scale up my inference, or maybe I should deploy it to the Fortune 500.
- 3:52
And maybe on the management side of things, I should be hiring teams of AI engineers and managing AI strategy for my company." Um, I think the last track, you know, like I talked about the nine tracks in, in AI engineers, it's always about the network, the, the community, the network that we're building.
- 4:05
Um, that's probably the single most important part of this conference, and that's the part that we cannot sell. We cannot-- I cannot put on the website, "Hey, we have a good community," 'cause no one will believe us.
- 4:13
You have to come and see for yourself. But please, for those w- of you who've been uploading to the Google Photos album, who've been tweeting out your photos, uh, and sharing them on LinkedIn, please keep doing that.
- 4:22
That's a way for myself and everyone else who is not at the conference to try to sh- join in on the fun.
- 4:29
Um, the reason I'm not comfortable with any of these tracks, because I s-- is because I know how they were made, because I made them up. And I know that because [chuckles] I was, uh, looking at, um, the, the original document for the rise of the AI engineer.
- 4:41
It's, uh, we're celebrating the one-year anniversary today. And, uh, just down in the document somewhere, I just listed out the, you know, disciplines that I thought the AI engineer would have, and those eventually became mostly mapping to the tracks that I have been exploring in these conferences and the meetups that I do.
- 4:57
And it's arbitrary. Like, why is there a separate agents track from Code Gen? Why is there a separate RAG track from open models? Like, these are all related. Um, what-- You know, they're, they're all of a kind, and o- obviously, as a competent AI engineer, you should be familiar with all these things.
- 5:11
And that brings us back to this mindset of having boundaries and borders, right? These are all made up by someone. I made them up for this one, but, you know, you're gonna live in a world where your boss made it up at your company.
- 5:24
And these are not reflective of how reality actually has to operate, right? If, if you start with all the rules and a different group of people came in, would they agree on the same rules?
- 5:34
Probably not, just because they're made up. But the laws of nature are, are hard to make up because the reality actually works that way. If you had an alien civilization come down to Earth, they would discover that gravity works the same, the sun, uh, the energy from the sun works the same, the magnetic field works the same.
- 5:49
So what are the laws of AI engineering? We'll, we'll come, we'll come to that via definitions of software engineering and real engineering. So I went and looked up definitions of software engineering, and IEEE talks about the application of engineering to software
- 6:01
with the design, implementation, testing, and documentation of software. Google Developers talks about mostly the same thing. They also mention software lifecycle management. Okay, like really reasonable definitions, uh, of kind, until you look at real engineers.
- 6:15
Real engineers talk about applying natural science, sciences, uh, utilizing them for benefit of humanity. Both the IEEE and the National Association of Engineers agree on that, uh, and it's curiously missing from software engineering, like the, the benefiting humanity part, the understanding natural laws part, completely missing from software engineering.
- 6:32
So my proposal to you is that AI engineering is somewhere in between, right? The, the [laughs] the, the, the software engineering, but then encountering a lot of the, more of the real world constraints than you would in a typical software engineer career.
- 6:44
So if we know the laws of Earth, and they are independently derived, they cannot-- No matter what point of view you're looking at, they all are the same laws, then what are the equivalent laws of AI engineering?
- 6:53
I have a few. You can come up with more, but I'm just gonna propose some to start off debate.
- 6:58
There's constants. So for example, if you're designing for humans, you should respect the fact that humans only speak at 80 words per minute, but they read at 200 words per minute, right?
- 7:07
So there's an inherent disparity there. There's also cons- contingent facts. There are things that are true for now instead of true forever. And true for now facts are, for example, like the Apple Intelligence.
- 7:17
When they ship a local model on every phone, then that inference speed of 30 tokens per second that they're advertising becomes the baseline speed limit or speed barrier of what intelligence that is too cheap to meter should look like.
- 7:31
And these things, they're not set in stone. They're not actual physical laws. So they also trend over time due to forces and momentum. And I want to establish a little bit, like I think it's under-- it's very beneficial for AI engineers to understand what the Moore's laws of AI is so that you can plan for them, so
- 7:46
that you don't have to make the bad bets that are not gonna last, just obviously just because of overwhelming evidence. The first bet is the improving of context, right?
- 7:56
Um, a year ago, I was interviewing Mosaic and talking about MPT-7B with their whopping 60,000, 70,000 token context with a lot of loss. Today, sitting in the audience, we have people who have trained million token context windows, and we've also p- uh, have from Anthropic, uh, which just released Claude 3.5 yesterday, uh, last week, um, the, the
- 8:16
fact that, you know, that we have complete utilization. It's not just about the length of context, it's also about the utilization of context. And I think Greg, who's sitting in the audience as well, would be very happy with how Claude is improving on their utilization of their very, very long context windows.
- 8:29
There's also the cost of intelligence, the commodification of intelligence. So in the past two years, we've seen a 99.55% decline in the cost of GPT-3 level intelligence. The cost of GPT-4 level intelligence has probably come down maybe 90%, maybe, maybe 80%, um, from, from GPT-4 to Llama 3, and now all the, the, the newer models that are-
- 8:48
Finally, I think it's worth commenting a little bit on where AI engineering stands in contrast to other AI philosophies. There's EA versus EAC, and maybe we're in the middle.
- 8:56
Like we, we care about safety, but we also want to accelerate, right? It's kind of like a weird combination of, of the two things. My proposal is that that one dimension isn't enough to express how AI engineer differs from the other philosophies, and actually you need to add a second dimension to talk about utility.
- 9:10
We are utility maxes above all else. We see what's out there, and we want to use it to benefit humanity.
- 9:16
So my message to everyone at the World's Fair is to try to disrespect borders a little bit. Try to avoid your own dogmatic beliefs, lazy consensus of other people, or passive reactions.
- 9:24
And in other words, try to disagree. Disagree more. Disagree with your own conclusions, disagree with each other productively, and disagree with the status quo. And I think there you'll find that this conference becomes more of a useful landmark in your careers rather than just a party, which it can very well be.
- 9:41
Uh, but my final analogy, which I really like, is that AI engineers are the kind of person that looks at Shoggoth and sees instead of a monster that cannot be tamed, they wanna turn them into mass rapid transit.
- 9:51
And the kind of person that looks at that, looks at, you know, a force of nature and wants to turn it into tools that are useful for people is the kind of AI engineer that I would love to speak to and welcome at conferences like this one.
- 10:02
So that's my view of what borders and AI engineering without borders should look like. I, I very much encourage you to jump between tracks, to jump between friend groups, to jump between disciplines and modalities, because here's the one place that you can do that outside of your work, um, and to mingle with everyone else that we've gathered.
- 10:17
So I hope you enjoy doing that. Um, I wish I was there in person, but just share them online, and I hope to see you in person at the next one.
- 10:24
Bye. [outro music]