Your AI Lead Should Be an Engineer
'AI' is not a job description
I’m increasingly seeing job postings for “be the person who tells us how to use AI.” They typically bundle in building out internal ‘AI workflows’ to automate processes, assisting with acquisition decisions, and integrating commercial tools into the organization’s setup.
I’ve done these tasks, and some of them I’ve even done well. If you insist on this role being one person because that’s what you have money or the billet to hire for, you should hire an engineer. By an engineer, I mean someone who has written a lot of code, is familiar with software development practices, and is going to be comfortable hands-on building out tooling, even if they’re not coming from a traditional software development background.
This is because there is no such thing as an ‘AI workflow’ for automation that doesn’t include traditional engineering. There are only data pipelines with AI components. Building AI tools is engineering+, not engineering-.
Let’s Look at This Job Posting
Here’s an excerpt from the skills and experience section of a recent posting I came across, lightly anonymized.
None of the following words or phrases appear anywhere in this posting: software, code, engineering, data pipeline. And yet: connecting to external tools via APIs is coding. Collecting, cleaning, and reporting on large amounts of data is data engineering. Building a CRM with robust data modeling and normalization logic is an engineering project. These tasks have nothing to do with AI beyond potentially enabling it — they’re completely standard engineering tasks.
The bullet I want to spend the most time on is “designing AI workflows to automate processes.” There is no such thing as an AI workflow for automation — there are only data pipelines with AI components, and you may not even know if you need an AI component until you sit down and scope it.
What Is an ‘AI Workflow’?
The simplest AI workflow I’ve ever done professionally looked like this:
Pull data from an existing database via a SQL query
Deduplicate and clean the data, which involved making specific calls about what constituted a duplicate
Send each row to an LLM via API calls, along with a prompt, and get the results back
Build an evaluation harness to try out different prompts and measure accuracy against human labels
Build tables and visualizations to display the results
Handle data storage so when new data comes in, you don’t waste API calls on data you’ve already run
Push to GitHub
This is basically just data science. Knowing only how to make an API call to an LLM does not get you anything without the rest of it.
And most of the workflows I build that incorporate AI are considerably more complicated from an engineering perspective. I’m usually not handed the data — I’m building a pipeline to pull it from wherever it lives, which frequently involves web scraping. My data cleaning and analysis workflow nearly always has more moving parts. I’m often building a website to display the results. More real automation — things that run in real-time in response to a user action, or that integrate with your existing databases, or that make a decision for you — require even more of a software-building skill set1.
How much can you vibe-code this? To some extent. But we’re not at the point where you don’t need some background. If your toolbox is only AI, you will reach for AI whether or not it’s the right tool, and you probably don’t even have a good sense of which AI component to use.
What about no-code tools? For some bounded, well-defined tasks, those will work. But for the kinds of custom pipelines with AI components that I see in real life, the tooling just isn’t there yet.
Web scraping a site that doesn’t want you to scrape it, where the formatting varies considerably page-to-page, may require a workflow that combines LLM API calls to discover structure along with data processing, if what you want is a repeatable, transparent process2. Using agents and also building an evaluation harness that can tell you what tool calls they’re making and how variable this is across runs requires code.
The problem with hiring someone who’s only comfortable with no-code tools isn’t that they can’t build anything — it’s that you’re going to hit a wall, and you can’t know before you invest the time scoping out projects how much of a limitation this will present.
This matters for what skills you look for and how you describe the role, and it matters for salary: if you set the salary at “generalist business analyst,” you will not get this skill set.
Don’t Be Like Data Science
Data science had a significant mismatch between requirements, duties, and desired outcomes, and it did not go well. Organizations hired data scientists expecting someone to come in and “make their data useful.” What the data scientists got instead was data engineering, data cleaning, and building dashboards — and everyone was disappointed.
And “make our data useful” was also never something one data scientist could come in and do. It takes organizational buy-in, a data infrastructure that’s already in place, and a lot of scoping before you can determine whether any particular project is feasible and what it needs. The same is true now with AI. Hiring an “AI person” and expecting them to transform how your organization works will produce the same result: a frustrated person doing work they didn’t sign up for, and an org that’s not getting what it thought it was buying.
What does being ready look like? Some of it is data access: your data needs to live somewhere that allows integrations with their tooling, and you need to be willing to grant them.
Some of it is willingness to change. For organizations that run heavily on Excel for analytics, a lot of the available gains from AI only materialize if you’re willing to move to code-based workflows. An engineer can help you get there, but they can’t make your staff do that.
And some of it is just your time. AI coding tools allow for building quickly, which means the person you hire needs fast feedback loops. If stakeholders aren’t available to weigh in, that’s a bottleneck.
“AI” is not a job the way “software developer” or “data engineer” is a job. It’s a problem space. Figure out what problems you’re trying to solve and whether you’re set up to solve them — and if you are, hire an engineer.
A note on “engineer”: the right flavor depends on what you’re building. If you want event-driven, user-facing products — a button that triggers a model, a real-time chatbot — that’s a software engineer. If you want classification models with rigorous evaluation pipelines, that’s closer to data science. I think the coding-versus-not-coding distinction matters more than which of those you hire for. But if you want both — real data software with mature analytics — that’s a team, not a person.
Which you SHOULD want, but that’s another piece.
LOL: "Don't Be Like Data Science" 😆