What Is an AI Engineer in 2026? Join My Live Research Series
Plus, new community idea, updating the AI Engineering Buildcamp content, experimenting with multi-agent setup and new Claude 4.6 models, and a collection of useful resources.
Over the past year, I’ve noticed that the titles AI Engineer and Gen AI Engineer are appearing more frequently: on job boards, in LinkedIn profiles, in community discussions.
At the same time, the role itself is still forming. There is no stable, commonly accepted definition.
What an AI Engineer is supposed to do depends heavily on the company, the team, and the problem they are solving. The role is being shaped in real time through the interaction between two sides of the market: what companies expect and what candidates can deliver. As a result, expectations remain inconsistent and sometimes contradictory.
That prompted me to start my own research on the topic. In this newsletter, I’ll share how I structured that research and what sources I’m using. And I also want to invite you to a four-part live Zoom series in which I’ll present the findings in greater depth.
Motivation Behind My Research
Since I run the AI Engineering Buildcamp, questions about the role, hiring decisions, and real-world tasks are directly relevant to me and the course participants. Recently, during an Office Hours session, one participant asked for concrete examples of AI Engineer take-home assignments used in interviews. It was a very practical question.
I have prior industry experience and regularly speak with people whose work aligns with what many call AI Engineering. But I am not currently employed in that position. I did not want to rely only on indirect exposure or conversations. Instead, I started collecting actual data to analyze and share insights later.
If the role is still evolving under market forces, then the only way to understand it is to look at real signals: what companies are posting, what candidates are building, and how interviews are structured in practice.
What I Plan to Use as Input
I plan to base my research on a combination of information sources: personal experience, structured data collection, and conversations with practitioners.
Below, I describe five primary sources for my research.
Source 1: My Own Industry Experience
I have worked with ML and AI for over 15 years and now teach at the AI Engineering Buildcamp. Over time, I’ve developed a clear view of what the AI Engineer role should look like: how the day is structured, what kind of problems they solve, and which skills are needed.
I’ll present my structured perspective on the role before we look at external data on the first event in the series: “A Day of an AI Engineer.” I’m curious to later compare my view with the current market reality.
Source 2: 1500+ Scraped Job Postings
To understand the demand side, I collected more than 1500 job postings from the last three months across several major cities: Los Angeles, New York, London, Amsterdam, Berlin, and others.
Not all of these roles are explicitly titled “AI Engineer.” Many use alternative titles while still involving AI or generative AI work. That variation is part of the problem I want to analyze.
This dataset allows me to examine:
How companies name these roles
What responsibilities they assign
Which skills and tools are repeatedly required
Where “AI Engineer” overlaps with ML Engineer or other adjacent positions
This part of the research focuses on terminology, expectations, and skill requirements across markets. It will be presented during the second event in the series: “Defining the AI Engineer Role.”
Source 3: Twitter and Reddit Interview Stories
I also looked at discussions on Twitter/X and Reddit, where engineers frequently share “Just got asked this in my interview” posts and reflections on what they do in their roles.
For this part, research agents helped me to collect the data. For example, Grok analysed X (Twitter) posts and helped me identify recent interview-related discussions.
This content captures informal but recent interview patterns, which often reveal details not visible in official job descriptions.
Source 4: Direct Conversations with Industry Contacts
Social media posts are useful, but I also want direct input.
I plan to speak with:
People who hire AI Engineers to understand their interview process
Some of the members of the DataTalksClub Slack community who are currently going through interviews or working on the role
Engineers I connect with on LinkedIn who already work in these roles
Some of these conversations may become public podcast episodes. Others will remain private but will be used for the analysis.
Sources 3 and 4 will together form the foundation of the third event, “AI Engineering: The Interview Process,” where I’ll focus on interview structure, evaluation criteria, and how hiring decisions are made.
Source 5: 60 GitHub Repositories with Take-Home Assignments
To understand how candidates are evaluated, I collected around 60 public GitHub repositories where people shared their take-home assignment solutions.
To gather repositories, I also experimented with deep research agents from Google and OpenAI, similarly to searching discussions on social media. But for GitHub, the agents were less effective:
They did not reliably find 100 repositories as requested
They sometimes found one real result and hallucinated additional ones
They were useful for generating better GitHub search queries
In practice, the workflow became hybrid. I used agents to craft stronger queries, then manually reviewed and aggregated the repositories for local analysis.
This resulting dataset allowed me to understand what companies actually ask candidates to build at home. In the fourth and final session in the series, I’ll break down the patterns in these assignments: “AI Engineering Take-Home Assignments.”
What I’ve Been Working On Recently
1) AI Shipping Labs Community
I want to share a sneak peek at what we’ve been building with my team:
AI Shipping Labs is an invite-only community for action-oriented builders focused on AI engineering and AI tools. The idea is to create an environment where members can move from ideas to shipped projects with clarity and support.
We are designing it as a practical working space with clear frameworks, implementation guidance, and peer collaboration. Planned activities include collaborative problem-solving, mentorship on technical challenges, interactive group coding sessions, and guided project-based learning with curated resources.
This is still a work in progress and is being shaped by feedback. We’re currently deciding which platform to use to host it, so I’d love to know what you’d prefer.
Please fill in this poll about where you’d prefer to host the community:
Subscribe to get notified when we launch.
2) Week 3 on AI Engineering Buildcamp and the New Upcoming Cohort
This week, I’m recording videos for Week 3 at the AI Engineering Buildcamp, focusing on agent frameworks.
I begin with first principles by demonstrating a basic agent loop, then move to PydanticAI, along with a mini-project on web search. I'll also cover different model providers like Anthropic and Gemini, and compare popular frameworks such as LangChain, Google ADK, and the OpenAI Agents SDK.
This time, I'm diving deeper into the mechanics of agent loops and tool calling, helping users understand what happens behind the scenes when using popular frameworks like LangChain.
3) Preparing for Monday’s Live Session, A Day of an AI Engineer
I began preparing for Monday’s live session, “A Day of an AI Engineer.” I used my Telegram brain-dump workflow to capture raw thoughts as voice notes during breaks, let the system structure them automatically, and then turned that structured output into a draft transcript for the talk.
4) In-Person Workshops
This year at DataTalksClub, we are putting more emphasis on offline events.
On February 17, we are hosting an in-person meetup at Zalando in Berlin, focused on agents and guardrails in real engineering systems. I will talk about how modern code agents are structured and what actually matters in practice, and Zalando engineers will share how they built a guardrailed internal support agent for incident triage and stakeholder Q&A. There will be pizza, drinks, and time to talk after the sessions!
A few weeks later, on March 10, I’ll host a hands-on data engineering workshop at Exasol Xperience 2026. We will work through a full, realistic pipeline using Exasol Personal on AWS, ingest and clean more than 1 billion rows of NHS prescription data, and finish with an AI-powered analytics dashboard for fast exploration. Members of the DataTalksClub community can attend the conference for free using the code EXA-VIP-RDTC.
My Experiments
In a previous newsletter, I wrote about my Telegram Writing Assistant. It takes raw voice notes, text messages, and links that I send to a private Telegram channel and converts them into structured Markdown drafts.
1) Multi-Agent Setup
As I began using it more extensively, especially for research-driven pieces, the workflow became more demanding, and the context window began to fill up quickly. This led to slower response times and occasional loss of detail. The architecture was doing too much in a single pass.
To address this, I experimented with Claude Code subagents and refactored the system into a small multi-agent setup. Instead of one overloaded process, specialized agents now handle distinct tasks. The separation reduced context pressure and made the workflow more predictable.
2) Testing Sonnet 4.6 and Opus 4.6
Another update to my Telegram Assistant relates to the recent release of Sonnet 4.6 and Opus 4.6.
Since the assistant runs on Claude Code, I tested both in my workflow. I noticed improved planning. The system feels more organized when coordinating steps and drafting. But I feel that most of this improvement comes from software updates in Claude Code rather than the model itself.
Some friends call Claude 4.6 a breakthrough. After a few tests, I wouldn't go that far yet. I switched the assistant to Opus 4.6 and will let it run in production for some time to see if there's a noticeable difference.
If you’re interested, I can write a separate newsletter breaking down the architecture updates and experiments behind my Telegram Assistant in more detail.
Tools
Docling: a document processing library that parses complex formats such as PDFs, Office files, audio, and images into a unified structured representation ready for AI workflows. It supports advanced PDF understanding, OCR, local execution, and integrates directly with agent frameworks like LangChain, LlamaIndex, and Haystack. Resource shared by Léonore Tideman from AI Engineering Buildcamp.
LangExtract: a Python library for extracting structured, source-grounded data from unstructured text using LLMs. You define the schema with a few examples, and it handles long documents through chunking and parallel processing, supports cloud or local models, and provides interactive HTML visualizations to review extractions in context.
Resource
Top 50 Large Language Model (LLM) Interview: a curated collection of 50 interview questions for LLM-related positions shared by Hao Hoang. The questions cover fundamentals like tokenization and attention mechanisms, fine-tuning techniques, generation strategies, and more.
Edited by Valeriia Kuka
Thanks, Alex, for the great effort, I really appreciate it. It truly helps.
That said, I’ve been feeling concerned about how AI is evolving these days. As someone working in the field, I’m honestly feeling overwhelmed by how fast everything is moving. It seems like there’s always something new happening, and I sometimes feel like I can’t keep up with the pace of change in the industry.
Do you have any advice on how to manage or overcome this feeling?
Nice! I didn’t know about the event in Zalando in Berlin. I would love to join but it is full. Is there a waiting list I can join?