This New AI Role Is Exploding  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: This New AI Role Is Exploding - Category: #podcasts - URL: https://share.snipd.com/episode/348dcbe1-bf81-4e9f-8fe4-5a74dba8aea3 ## Document Notes ## Highlights - **Forward Deployed Engineers Are Rising Fast** - Forward Deployed Engineers (FDEs) bridge models and real customer needs by embedding with product teams. - Demand for FDEs jumped ~800% as companies tailor LLMs into scalable, client-specific solutions. Transcript: Jerod Santo This new AI role is exploding. AI-related job losses and future non-hires are the talk of the software town right now, but at least in the short-slash term, a new AI-led tech role has emerged with a massive increase Of job postings, up 800% over the last nine months. Quote, forerunners in the AI race such as Anthropic and OpenAI are actively recruiting software engineering specialists called forward deployed engineers, FDEs, to help with tailoring AI models to meet customer needs. More than just working with back office coders, these engineers are embedded within customer and product engineering teams. End quote, still not sure what a forward deployed engineer or an FDE does exactly? Quote, unlike traditional software engineers, FDEs go beyond writing code to go out in the field and understand where AI can make the biggest impact. Their mission is to bridge the last mile of AI, transforming a general purpose model into scalable AI solutions that reflect complex client requirements and solve their problems. And quote. If this trend has any staying power and if you want to be in demand in 2026, now is the time to ensure you can confidently and truthfully put FDE on your resume. ([Time 0:00:43](https://share.snipd.com/snip/130491b0-8c46-4035-98c8-6a1b817211fb)) - **Developers Prefer Low-Pain Deployment Platforms** - Younger developers prefer platforms that remove operational pain rather than platforms that test skill. - Corey Quinn argues this generational shift could marginalize raw AWS usage outside entrenched users. Transcript: Jerod Santo Younger devs won't tolerate pain in the AWS. Corey Quinn, who is hilarious by the way, finally realized what I've known since the first time I tried shipping a Rails app on EC2. AWS, for the uninitiated, it's pure pain. Quote, recently I was spitting up yet another terribly coded thing for fun because I believe in making my problems everyone else's problems and realized something that had been nagging At me for a while. Working with AWS is relatively painful. End quote. Corey lays out what a typical zero to one AWS setup often requires, then compares it to the silky smooth experience Vercel provides on top of AWS. His explanation for the discrepancy, it's generational. Quote, this feels generational to me. For folks of a certain age, Gen X and millennials, AWS and GCP have made their bones. We came of technical age with the platforms and we are used to their foibles. Azure is of course the boomer cloud, but Gen Z is using platforms that aren't designed as tests of skill to let customers prove how much they want something. End quote. Hat tip to Corey for calling Azure the boomer cloud. That's amazing. However, I don't think this is a generational thing. There's an entire group of elder devs like myself who have always preferred Heroku-style deployment platforms over AWS. While his view of the past seems skewed from inside the AWS bubble, he might be right about the future. Quote, AWS spent two decades building the most powerful cloud platform in the world. They may spend the next two watching it become irrelevant to anyone who wasn't already bought in. ([Time 0:02:06](https://share.snipd.com/snip/3c631a6d-9611-41a1-a81d-6cd1055ded82)) - **Build An Agent To Learn Agents** - Write an LLM agent yourself to truly understand their strengths and limits. - Building an agent delivers hands-on clarity about agentic programming and its implications. Transcript: Jerod Santo You should write an agent. Thomas Toczek makes the case that to truly grok LLM agents, so you can be the best hater or stan that you can be, you need to write one. Quote, agents are the most surprising programming experience I've had in my career. Not because I'm awed by the magnitude of their powers. I like them, but I don't like like them. It's because of how easy it was to get one up on its legs and how much I learned doing that. End quote. I this experience back in April when Thorsten Ball's post walked me through it step by step. Thomas isn't wrong. Building an agent for yourself brings clarity to what is likely the most important developer-facing technology of the decade. ([Time 0:03:46](https://share.snipd.com/snip/ab817615-f56c-429d-b6b7-bde57a528c57)) - **React As The Dominant Platform** - React has shifted from framework to platform and benefits from a reinforcing loop of LLMs, prompts, and developer output. - New frameworks face systemic inertia because tools and prompts now default to React code. Transcript: Jerod Santo Dead Framework Theory. Paul Kinlan says he was wrong last October when he predicted that LLMs would abstract away framework choice. Well, maybe he wasn't wrong, but he was wrong about the timeline. Quote, the reality is more interesting and more permanent. React isn't competing with other frameworks anymore. React has become the platform. And if you're building a new framework, library, or browser feature today, you need to understand that you're not just competing with React, you're competing against a self-reinforcing Feedback loop between LLM trading data, system prompts, and developer output that makes displacing React functionally end quote. When he says self-reinforcing feedback loop, he is not exaggerating. Today I learned Replit, Bolt, and tools like them are literally hard-coding React into their system prompts, quote, they have to. If you're building a tool today to attract developers, you need to give them code they can maintain. ([Time 0:05:31](https://share.snipd.com/snip/35026d1d-fd51-4d3e-90aa-fe1844411cfe)) - **Don't Vibe Code Your Unit Tests** - Do not let LLMs randomly generate unit tests; they often produce brittle and noisy tests. - Instead, craft or correct tests one at a time to ensure they are constructive and maintainable. Transcript: Jerod Santo We're still trying to figure out this whole agentic coding thing. Should we make the agent write the tests and we write the implementation ourselves? Or should we write the tests and make the agent write the implementation? Or maybe we should just sit back and say, hey, agent, take the wheel. Andrew Gallagher has thoughts on these questions. Quote, there is a growing sentiment that LLMs are good for crud, boilerplate, and tests. While I am not so sure about how good AI is at making crud or thumping out boilerplate, a year of working as an SWE in the modern LLM-powered AI codescape has proven to me that LLMs write Unconstructive, noisy, brittle, and downright bad unit tests. Please, do not vibe code your unit tests. End quote. Andrew does say there's a way to get good tests from LLMs, but right now it requires you to make them right tests one at a time. ([Time 0:06:51](https://share.snipd.com/snip/25a4eaae-34cb-46b2-aac0-7362bf365389))