I've watched good engineers panic-buy AI certifications, rebrand themselves as "prompt engineers," and burn every weekend on courses that will be obsolete in six months ... all because LinkedIn told them they were about to be replaced. This is an information problem dressed up as a skills problem, and the people selling the courses know exactly what they're doing.
The panic is manufactured. Every "learn AI or be left behind" post is either selling something or guessing at what happens inside engineering organizations from the outside. I've spent the last few years building at JioHotstar, 500M+ users, one of the most complex streaming platforms in the world, watching this play out from inside the building. Here's what I actually see.
AI is automating the commodity 70% of every engineering role. The engineers who understand that and act on it are getting more leverage, more scope, and more impact than they've ever had. The ones treating their commodity output as their value are getting squeezed out of roles that were precarious to begin with.
The uncomfortable part nobody says out loud: a lot of those roles were already on borrowed time. The engineer who existed to write boilerplate CRUD endpoints, churn out weekly reports, or assemble design wireframes from a template was always exposed ... to the next outsourcing wave, the next cheap junior hire, the next reorg. AI just made the exposure faster and impossible to ignore.
The engineers who thrive here share one trait: they already knew their commodity work was commodity, and they were already clawing their way out of it. AI just handed them a faster exit. For everyone else, this is a forcing function, and forcing functions tend to be gifts in disguise when you respond to them in time.
This guide hands you a framework to answer that question for your specific role, with a concrete 90-day plan you can start this week. The whole thing is free and the ideas are yours to use.
This is written for working engineers, PMs, designers, and technical leaders who want to read the landscape clearly and move deliberately. Students and early-career folks can use the framework too, with less urgency, since they're entering the market as it is rather than rebuilding around skills that just got cheap. The reader I have most in mind is the 3–10 year professional who built a career on skills that are being commoditized at scale and needs a map for what comes next.
Every engineering role splits into three distinct layers of work. AI is eating one of them right now, and barely touching the other two. Here's the full map.
Commodity
Leverage
Irreplaceable
Most engineers spend 80–90% of their time in Layer 1, and AI has just offered to do that layer for free. Move your working hours toward Layer 3 on your own terms, or the market will move them for you on someone else's timeline and probably out of your job.
The survival formula is this: audit your week. Deliberately move hours from Layer 1 → Layer 3. The rest of this guide shows you how that plays out, role by role, with concrete actions you can start tomorrow.
One more thing before we dive in: treat that 10% as a floor you build on, not a ceiling you're stuck under. The best engineers I know have methodically grown their Layer 3 footprint to 40–50% of the week. The real goal here goes beyond surviving the AI era. It's using AI as the forcing function to finally do the work you were always capable of.
Frontend Engineer
React · Vue · CSS · Design Systems · Web Performance · Accessibility · Browser APIs
Frontend is the most visibly disrupted role in the AI era. v0, Cursor, Copilot, and Figma AI now turn a one-line description into a functional React component. If most of your week is boilerplate UI code, you're in the danger zone: the specific version of the job you're doing is being commoditized faster than any other role on this list, even though frontend itself isn't going anywhere.
The counterintuitive part: demand for great frontend engineers has never been higher. An AI-generated UI and a UI built with real taste, deep accessibility understanding, and performance engineering are separated by an enormous gap, and that gap is visible to anyone who uses the product. The market is splitting into disposable UI factories on one end and frontend architects on the other, with the middle ground shrinking fast.
Writing boilerplate React and Vue components from a description. Generating CSS from Figma specs or visual references. Creating form validation logic with error states. Writing unit tests for pure functions and utility helpers. Producing responsive layouts from wireframes. Converting design mocks to working code. Basic accessibility fixes like ARIA labels and focus management. Generating Storybook stories for existing components. Writing documentation from code. Creating animation CSS from reference descriptions. Scaffolding new pages with routing.
Reviewing AI-generated components for the accessibility gaps it routinely misses: screen reader compatibility, keyboard navigation flows, color contrast edge cases. Feeding AI your design system's constraints so it produces brand-consistent output instead of generic boilerplate. Running AI performance audits across a codebase and deciding which recommendations are worth shipping for your actual user profile. Generating 10 layout variations in the time it used to take to sketch 2, then applying taste to pick and refine. Having AI write test cases for your logic while you validate the edge cases it gets wrong.
Owning the design system that defines how the entire product looks and feels, and making the hard judgment calls about when to break the rules and when to enforce them. Understanding the full performance budget of a 500M-user app: which CSS property triggers a layout reflow, which JavaScript execution blocks the main thread, which font-loading strategy kills LCP by 200ms. The taste to look at a generated component and say "this is technically correct and accessible and on-brand, but it still feels wrong, and here's why." Knowing which browser quirks will bite you in Safari on iOS 16, which the AI has never debugged at 2am before a launch.
Junior frontend developers who spend their careers writing components they could have described in a prompt to v0 will find it hard to compete in 18 months. The path forward is depth. Own the system: know why every design choice works, not just that it does. Build the performance intuition that only comes from debugging real production incidents on a high-traffic app, the kind of intuition that tells you a 200ms LCP regression came from a font-loading change before you've even opened the profiler.
Learning yet another JavaScript framework. Svelte, Astro, Qwik, Solid, whatever this month's favourite is. Framework knowledge is cheap: documented, promptable, learnable in a week. The durable skill is evaluating a framework against a real production context and owning the migration at scale. The valuable engineer is the one who can say whether a 40-engineer org can actually absorb a React-to-Solid move given its existing component library, and who then leads that migration, not the one who has skimmed the docs for all four.
Find one accessibility issue in your product that affects real users: keyboard users, screen reader users, people with motor impairments. Fix it, then write up why it existed and how you found it. Accessibility is one of the last areas where AI still routinely ships incorrect output, so an engineer with real accessibility instincts stays in perpetual demand.
Backend Engineer
APIs · Databases · Microservices · System Design · Performance · Reliability · Data Contracts
Backend engineering is where the AI disruption gets interesting. The surface threat is real: AI writes CRUD endpoints, generates ORM models, scaffolds APIs, and produces migrations faster than any human. Go deeper into the distributed-systems decisions, the reliability contracts, the failure-mode engineering, and you hit work that depends on institutional context no model has been trained on, which is exactly where backend engineers become hard to replace.
The backend engineers who thrive own the contracts between systems. They carry two years of design-decision context in their heads. They know why the retry strategy looks the way it does and exactly what happens to the downstream queue when someone changes it. Endpoint count is not the measure here; the measure is how much of the system's behavior you can predict and answer for.
Writing CRUD endpoints in any framework. Generating ORM model definitions from schema descriptions. Writing SQL queries and stored procedures from natural language specs. Scaffolding REST and GraphQL APIs with standard patterns. Writing serializers, validators, and error handling boilerplate. Database migration scripts. Integration test skeletons and fixture setup. API documentation from code (Swagger/OpenAPI). Standard authentication middleware patterns. Rate limiting and pagination boilerplate. Docker and containerization configs for common service architectures.
Generating several schema design options and using your knowledge of the real data access patterns to pick the right one. Having AI produce load-test scripts while you define the SLOs being tested and read what the results say about system health. Letting AI propose caching strategies, then validating them against your real traffic patterns, cache invalidation complexity, and consistency requirements. Running AI as a first-pass reviewer on your own PRs, which catches mistakes and sharpens your eye for what to look for. Having AI draft runbooks while you supply the sections that need real system context: the judgment calls, the known failure modes, the things that matter at 3am.
Designing the service boundary that prevents a downstream provider failure from cascading into a full-system outage, the kind of decision that requires understanding six months of incident history and three different team's operational patterns. Knowing the data contract between your service and its 12 consumers, and knowing which of them will silently break when you change the response schema in a way that looks backwards-compatible but isn't. The architectural judgment to decide when to split a service and when the operational overhead isn't worth it. End-to-end reliability ownership, not just keeping the lights on, but understanding the system well enough to predict where the next failure will occur before it does.
The backend engineers I've watched get commoditized described their job as "building APIs." The ones thriving describe it as "owning the reliability of system X." Becoming the person who answers for a system at 3am is the single most powerful career move available to a backend engineer right now. AI will happily take the work off your plate; it can't take the accountability for the outcome, so make that accountability the thing you're known for.
Technology tourism, chasing the latest database or message queue. Kafka vs. Pulsar vs. RabbitMQ. PostgreSQL vs. DynamoDB. Knowing a technology is cheap: it's documented, it's in every tutorial, and an AI can lay out the trade-offs in two paragraphs. Own the problem instead. The tool is interchangeable; your understanding of why your specific system breaks at your specific scale, and your judgment about how to fix it, is not.
Write a "failure resume" for your systems: every significant incident or near-miss, what caused it, and what you personally learned. Keep it for yourself, not for performance reviews. A deep library of failure patterns is one of the hardest things to hand to a model or a new hire, so every outage you survive and document compounds into expertise nobody can shortcut.
Data Scientist
ML Models · Statistical Analysis · Experimentation · Feature Engineering · Business Insights
Data science is splitting in two. On one side sits the work that was always data processing with a statistics wrapper: automated reporting, basic predictive models, EDA on structured data. AI handles that with remarkable competence now. On the other side sits the genuinely hard part that always carried the value, deciding what to measure, defining what a meaningful result even is, turning a statistical finding into a business decision, and catching the moment the data starts lying to you.
Here's the uncomfortable truth: plenty of people carrying the title "Data Scientist" have spent their whole careers in the commodity layer, valued for writing Python, running sklearn, and producing charts. The judgment about what to analyze and why was the actual job, and that's the version of the role now under enormous pressure.
Exploratory data analysis on structured datasets ... producing summary statistics, correlation matrices, distribution plots. Feature engineering suggestions for tabular data. Running baseline models (sklearn, XGBoost, LightGBM) and producing comparison tables. Writing data cleaning and preprocessing pipelines from spec. Generating charts and visualizations from data. Drafting analysis reports and slide decks from findings. Writing statistical test boilerplate (t-tests, chi-squared, ANOVA). Building dashboards from a spec. Documentation for notebooks. Generating SQL for common aggregations and joins.
Using AI to generate a full hypothesis tree for a business problem, brainstorming every possible explanation for an anomaly, and then applying domain knowledge to prioritize which three are worth actually testing. Having AI produce a first-cut feature set from a problem description while you validate each feature against the business logic the model doesn't know. Using AI to write experiment analysis code (sample size calculations, power analysis, significance testing) while you own the experimental design, what constitutes a meaningful effect, what the right control is, what confounds exist in your specific data. Letting AI generate multiple model architectures and then picking the one you can actually explain to the product team and defend when it fails.
Defining what "good" looks like in your domain. A model with 92% accuracy on a fraud detection problem might be catastrophically wrong, only someone who understands the asymmetric cost of false negatives can set the evaluation bar correctly. Knowing when to stop an A/B test before statistical significance because the business context has changed in a way that makes the result irrelevant. The judgment to say "this result is statistically significant but it doesn't make business sense, here's what's actually going on in the data." Recognizing when a dataset is subtly broken in a way that produces plausible but wrong outputs. Translating a finding into a recommendation that gets a decision made.
If your value as a data scientist lives entirely in writing pandas, running models, and producing charts, you're in the danger zone, because the market for that skillset is in structural decline. Get obsessively close to the business problems your data is meant to solve. Become the person consulted on what to measure before any data work begins. That seat, upstream of the analysis, is the one AI cannot take.
Chasing model benchmarks and Kaggle leaderboards. A top Kaggle rank is impressive in one narrow context and close to useless in most others, because it optimizes metric performance on a clean, labeled dataset with a well-defined problem. Real data science is almost never that tidy. The durable skill is choosing which metric to optimize in the first place and recognizing when optimizing it causes harm the leaderboard can't show you, like a fraud model that minimizes overall error while quietly waving through the costliest false negatives.
Find one case in your organization where a business decision was made on data that was subtly wrong: wrong methodology, wrong metric, wrong interpretation. Document what happened, why the data led people astray, and what the right analysis would have produced. This kind of near-miss postmortem is the hallmark of senior data science judgment, and it doubles as a powerful portfolio piece.
AI / ML Engineer
Model Training · Fine-Tuning · Inference · MLOps · LLM Integration · Evaluation · Deployment
The AI/ML engineer holds the most paradoxical position on this list: you build the tools automating everyone else's job while those same tools automate big chunks of your own. The parts going first are exactly the parts that got the heaviest tutorial coverage over the last five years, training loop boilerplate, standard fine-tuning pipelines, basic RAG setups, API integrations. If that's your whole day, read this one carefully.
The parts nobody can hand to a model are the genuinely hard ones: knowing what to evaluate, designing evaluations that catch real failure modes, and making deployment calls in a domain where the outputs are probabilistic, the failures are silent, and the consequences stay invisible until they turn catastrophic.
Fine-tuning pre-trained models on a labeled dataset (increasingly automated by platforms like Vertex AI, SageMaker Autopilot, and OpenAI fine-tuning APIs). Writing training loop boilerplate in PyTorch or JAX. Generating data augmentation pipelines for common data types. Writing standard inference serving code for common model architectures. Building prompt templates for straightforward tasks. Connecting LLM APIs with standard patterns. Writing model card documentation from a template. Creating basic RAG pipelines with off-the-shelf vector databases. Standard MLflow experiment tracking setup.
Using AI to generate candidate evaluation metrics for a new task, brainstorming precision/recall/F1/BLEU/ROUGE variants, and then applying domain knowledge to decide which failure modes actually matter most for your use case. Having AI produce a first-pass dataset analysis (label distribution, quality issues, potential leakage) while you validate the findings against the known messiness of your data collection process. Using AI to generate adversarial test cases and edge-case prompts while you define the failure taxonomy, what categories of failure exist, which are acceptable, which are catastrophic. Letting AI write the benchmark evaluation harness while you specify exactly what it needs to measure and why.
Owning the evaluation framework, because AI cannot self-assess at the depth and domain-specificity your use case requires. The judgment to say "this model is passing all our automated evals but I've seen three production failure patterns our evals don't capture, here's why and here's what we need to add." Knowing when to deploy, when to hold, and when to roll back, a decision that requires understanding the full context of your system, your users, your business constraints, and the model's failure modes simultaneously. Building the monitoring system that catches silent degradation before users do. The organizational courage to say "this model is not ready" when the pressure to ship is enormous.
Most "AI engineers" right now are doing sophisticated prompt engineering and API integration. That work matters, and it's also becoming commodity fast. The ones who'll be hard to replace in 18 months own evaluation rigor: they design test suites that catch failure modes before production, and they know a model passing your evals is only as trustworthy as the evals themselves. Invest in evaluation. Almost nobody is doing it well, which is exactly why it pays.
Fine-tuning for the sake of fine-tuning. Most teams pour effort into model training and starve evaluation. A smaller, thoroughly evaluated model your team understands and can monitor will beat a state-of-the-art model you can't explain to product and can't watch in production. For most teams the math runs the wrong way: every hour on fine-tuning is an hour not spent building the evals that are the actual moat. Own the evals.
Build a "model behavior changelog": a document tracking how your model's behavior shifts across versions, with concrete examples for each category of change. Most teams track performance metrics; almost none track behavioral changes at the example level. The day something breaks in production and you need to pinpoint when the behavior drifted, this artifact is what saves you hours of guessing.
Product Manager
Roadmaps · PRDs · User Research · Prioritization · Stakeholder Alignment · Strategy · Discovery
Product management is in a fascinating position in the AI era. On the surface, much of the PM's day-to-day documentation work, PRDs, user story writing, stakeholder updates, competitive analysis tables, OKR drafts, is deeply amenable to AI generation. AI can produce a passable PRD from a half-page brief. It can synthesize 200 user research notes into themes. It can generate a RICE-scored backlog from a feature list.
What makes a great PM hard to replace lives a layer below the PRD: the judgment about which problem to solve, the nerve to kill the feature everyone's excited about once you see it solves the wrong problem, the organizational footwork to get twelve stakeholders aligned on a direction none of them started out wanting. AI drafts the document in seconds. The call underneath it is still yours to make.
Drafting PRDs and feature specifications from a brief. Summarizing user research notes into themes and insights. Writing release notes and changelogs from commit logs. Creating competitive analysis tables from a set of product URLs. Generating user story templates with acceptance criteria. Drafting OKRs from a strategy document. Summarizing stakeholder meeting notes into action items. Creating first-draft roadmaps from an input list of features. Writing A/B test hypotheses for a feature. Generating interview question lists for user research. Producing feature comparison matrices.
Using AI to synthesize user research at scale, hundreds of support tickets, interview transcripts, NPS responses, into coherent themes, and then applying judgment to distinguish genuine signal from noise that happens to appear frequently. Having AI generate every prioritization framework (RICE, ICE, MoSCoW, Kano) for your backlog simultaneously, and then deciding which trade-offs your specific team can actually execute given their constraints. Letting AI draft the PRD while you personally write the section that matters most, "why we're not building the obvious alternative," which depends on organizational context the model doesn't have. Having AI generate the product brief, then stress-testing it yourself before it ever reaches the team.
Being the person who kills the bad idea before it gets built. That takes the full organizational picture: why the team is pushing for this feature, what political dynamics are in play, what the opportunity cost is against the three other things you could build, and whether the excitement is about a real user problem or just a technology that's fun to build. The judgment to say "this research finding is real, and it still doesn't mean we should build what users are asking for." Strategy lives in a sustained series of hard no's, each one demanding courage and credibility. AI will never say no on your behalf.
PMs who describe their job as "writing PRDs and managing the backlog" will find that job questioned more and more. The ones who describe it as "deciding what we build and what we don't, and answering for those outcomes" will have more leverage than ever. The documentation is just the residue of the judgment, so put your weight on the judgment itself.
Getting better at writing PRDs. A flawless PRD written for the wrong feature is worse than no PRD at all, because it hands the wrong work the legitimacy of process. The skill that holds value is deciding which problem deserves a PRD in the first place, long before you open a doc. Spend your energy upstream, on the problem definition, where a single good call saves a quarter of misdirected build time.
Build a "decision log": a running record of every significant product decision you've made, why you made it, and what happened as a result. Most PMs have no institutional record of their judgment over time. A decision log makes your thinking visible, holds you accountable to it, and gives you real credibility in strategy conversations because you can point to the pattern of your calls over months and years.
Designer
UI/UX · Visual Design · Interaction Design · Design Systems · User Research · Brand · Motion
Design is the role where the AI threat feels most visceral because the output is immediately visible and comparable. Midjourney can produce stunning visuals. Figma AI can generate wireframe variants. v0 can turn a text description into a functional UI. For designers who have been defined primarily by their ability to produce visual output quickly, this is a genuine disruption.
Great design runs on taste, judgment, and user understanding aimed at producing the right output, and it always has. AI can generate a thousand variations in an afternoon and still can't tell you which one is right or why. Production has become cheap; the judgment about what's right is where a designer stays hard to replace.
Generating wireframe variations and layout explorations from a text prompt. Creating icon sets and illustration styles from a reference description. Producing stock imagery, hero visuals, and background graphics. Writing UX copy alternatives for buttons, headlines, empty states, and error messages. Auto-generating component variants in Figma. Creating mood boards from a style brief. Producing first-draft landing pages from copy. Resizing and adapting assets for different platforms and breakpoints. Generating first-pass color palettes and typography pairings from a brief. Creating basic animation concepts from a description.
Using AI to generate 20 layout explorations in the time it used to take to sketch 3, and then applying genuine taste to select, critique, and refine the direction worth pursuing. Using AI image tools to produce research stimuli for user testing (product concepts, packaging variations, landing page alternatives) at a fraction of the cost and time ... enabling more and faster experimentation. Having AI propose accessibility improvements across a design (contrast ratios, touch target sizes, text sizing) while you decide which to implement based on your real user context. Letting AI handle production work (asset resizing, copy variations, documentation) while you invest the saved time in deeper strategic and creative work.
Aesthetic judgment: looking at a technically correct, brand-compliant, accessible design, calling it wrong, and articulating why in a way that shifts the direction. No prompt produces taste. Owning the design language that gives a product one consistent emotional register, the invisible architecture users feel but can't name, the thing that makes a product feel intentional rather than assembled from parts. Understanding the user's full situation, their mental model, their environment, their anxiety in a high-stakes flow, and designing for that real person rather than the idealized user in the brief.
Designers who describe their job as "creating visuals" or "building screens" will find their role questioned more and more. Designers who describe it as "owning the quality of the experience," from research through to the call on what ships and what doesn't, will be more valuable than ever. The visuals fall out of that ownership as a by-product, so anchor on the ownership.
Keeping up with every AI design tool as it launches. Figma AI, Adobe Firefly, Midjourney, whatever ships next month. Knowing the tool is cheap: documented, tutorialized, learnable in a week by anyone capable. The value sits in what you do after the tool generates something, the judgment that decides if it's right, the taste that refines it, the systemic thinking that decides if it fits the rest of the product. Treat the tools as leverage and put your weight on the judgment they can't supply.
Build a "design critique muscle" with a monthly session where you critique AI-generated designs from public sources (product launches, app store screenshots, marketing sites) against explicit criteria. Write the critiques up and share them. Designers who can name precisely why something is wrong, with reasoning, develop a clarity about their own judgment that makes them sharp at directing both AI tools and junior designers.
DevOps / SRE
Infrastructure · CI/CD · Observability · Incident Response · Reliability · Platform Engineering
DevOps and SRE work has a peculiar relationship with AI disruption. The configuration layer, Terraform, Kubernetes manifests, CI pipeline definitions, alert rules, is being automated at remarkable speed. Meanwhile the human judgment that reliability engineering runs on grows more valuable as systems get more complex. Correctly configured infrastructure and a system that behaves well under failure are separated by a wide gap, and that gap is where AI runs out of road.
The best SREs I know think of themselves as reliability owners: people accountable for what happens when things go wrong, carrying the context, the nerve, and the judgment to make the right call under pressure. That ownership is the part of the role AI can't displace, and it's worth far more than fluency with any particular config syntax.
Writing Terraform and Pulumi infrastructure-as-code from a spec. Generating CI/CD pipeline configurations for standard toolchains (GitHub Actions, Jenkins, CircleCI). Creating Dockerfile templates and multi-stage build configurations. Writing Helm chart scaffolding for standard service deployments. Generating monitoring alert rules from SLO definitions. Writing runbook templates for common failure scenarios. Producing infrastructure cost analysis reports from billing exports. Generating Kubernetes resource manifests for standard workload types. Writing bash and Python automation scripts for common operational tasks. Creating network topology diagrams from infrastructure descriptions.
Using AI to generate candidate alert threshold configurations and then calibrating them against your actual incident history, because generic thresholds produce either alert fatigue or missed signals, and only your incident history can tell you which way you're biased. Having AI produce infrastructure cost optimization suggestions (right-sizing, reserved instances, spot pricing) and then deciding which to act on based on the engineering effort, the risk, and the actual savings ... not the theoretical maximum. Using AI to generate runbook content while you add the "judgment call" sections: the cases where the standard procedure doesn't apply, the known failure modes that require off-script action, the context that only comes from having been on the incident before.
Owning the blast radius. The ability to say, and be right, about what breaks, in what order, with what user impact, when a given service or dependency fails. This requires having built the system, lived through its failures, and internalized its failure modes in a way that no amount of reading documentation can replicate. Being the engineer who designed the fallback strategy that kept a 3am outage from becoming a 12-hour incident, who had thought through the failure scenario before it happened, not during. Incident ownership during a live event: the judgment calls made in real time, under pressure, with incomplete information, are irreducibly human.
DevOps engineers who built their careers on configuring infrastructure will feel growing pressure as AI tooling takes over more of that configuration. Move toward reliability ownership: be the person accountable for what happens during incidents, not only for the config that hums along in normal operation. That means carrying a pager, owning postmortems, and accumulating the institutional knowledge that only comes from surviving real production failures. There's no shortcut around that experience.
Chasing cloud certifications as a primary career investment. AWS Solutions Architect, GCP Professional Cloud Architect, Azure Expert all confirm you know a provider's API surface. None of them confirm you can make systems reliable under real production conditions. An engineer who has survived 20 real incidents and owns the postmortems is worth far more than one holding five certifications and no production scars. Get certified if the job requires it, and keep it in its lane: it's a checkbox, not expertise.
Build a "failure library" for your team: a structured, narrative catalog of every significant failure mode your systems have shown, with the context, the response, and the lesson, written as stories rather than bare incident tickets. When a new engineer joins, this library turns months of ramp-up into weeks. The person who builds it, maintains it, and owns it becomes the institutional memory the team can't easily do without.
Data Engineer
Data Pipelines · ETL/ELT · Data Modeling · Data Quality · Warehousing · Streaming · Data Contracts
Data engineering occupies an interesting position in the AI disruption landscape. The pipeline boilerplate, ETL code, dbt model templates, SQL transformations, Airflow DAG scaffolding, is being automated rapidly. But the deeper function of data engineering, which is making data trustworthy enough for consequential decisions to be made on it, is becoming more critical as AI systems consume more data at scale and the cost of bad data compounds exponentially.
The data engineer who's hard to replace can look at an output number, sense it's wrong even when it sits inside the expected range, trace the anomaly back through three upstream transformations, and explain it to a business stakeholder before anyone notices the dashboard is off. Writing the most efficient Spark job is not what earns that trust; catching the silent breakage before it reaches a decision is. No AI does that reliably.
Writing ETL and ELT pipeline boilerplate in dbt, Spark, or Airflow. Generating dbt model templates from schema descriptions. Writing SQL transformations from business logic specifications. Creating data quality check scripts for standard checks (null rates, uniqueness, referential integrity, range validation). Generating schema documentation from existing tables. Writing pipeline monitoring and alerting configurations. Producing data lineage documentation from code analysis. Creating Airflow DAG scaffolding for standard pipeline patterns. Writing data contract templates. Generating API extraction code for common data sources.
Using AI to generate candidate data models for a new domain and then applying knowledge of the actual business access patterns, how analysts will query this, how the data will evolve, what the join performance implications are, to choose the right one. Having AI produce a first-cut set of data quality rules from a business logic description and then validating them against the known edge cases, exceptions, and historical anomalies that the business logic description didn't mention. Using AI to synthesize a pattern analysis across data quality incidents ("your pipeline fails every Monday morning, here's what they have in common") while you identify the underlying systemic cause and design the fix.
Owning data trust at the organizational level. Being the person who can say "this number is correct", and have the organization believe you, because you understand the source, every transformation, every place where data can silently go wrong, and you've built the monitoring that catches problems before they reach the dashboard. A model trained on bad data produces bad decisions at scale, and the AI consuming your data has no way to know that the upstream join is producing spurious duplicates in a specific edge case. You do. The engineer who owns data quality owns the reliability of every downstream decision in the organization.
Data engineers who think of their job as "building pipelines" will feel growing pressure as AI generates more of the pipeline code. The ones who think of it as "making data trustworthy," with the organizational credibility to back the claim, will be more valuable than ever. This is the move from plumber to quality owner, and it's worth making deliberately before the market forces it on you.
Becoming a platform collector: Databricks, Snowflake, BigQuery, dbt, Flink, Kafka, all of them. Platform knowledge is cheap. Every platform ships extensive docs, and every certification just confirms you read them. The durable skill is understanding the data well enough to make and keep promises about it. The engineer who can say "I guarantee this number is correct, and here's exactly how I know" outvalues the one holding five platform certs who can't trace a metric back to its source. Be the engineer people trust with the numbers that matter.
Build a "data incident log": a running, narrative record of every time your pipelines produced incorrect output, with the root cause, the downstream impact, and the fix, written as the story of each incident rather than a list of ticket numbers. Over time it becomes a pattern library of your data system's failure modes, and the engineer who maintains it becomes the institutional memory for why the data can be trusted at all.
Engineering Manager / Leader
Team Leadership · Hiring · Technical Direction · Org Design · Stakeholder Management · Culture
Engineering management collects the most confident "AI can't replace this" reassurances and some of the most specific, credible threats at the same time. Reading a room, sensing team dynamics, making hard calls about people: deeply human, and safe for now. The administrative layer is another story. Status reports, sprint summaries, 1:1 agendas, performance review templates, hiring rubrics, OKR drafts are all being generated by AI at scale, and the managers who will struggle are the ones whose visible output lived mostly in that layer.
The managers who thrive already spent most of their time on the human work: context-setting, team shaping, conflict resolution, technical judgment, organizational navigation. For them AI is a gift, clearing away the overhead that kept them from their highest-leverage work in the first place.
Writing sprint reports and velocity summaries. Generating 1:1 agenda templates from common themes. Drafting job descriptions from role requirements. Writing performance review frameworks and competency matrices. Producing engineering metrics dashboards from raw data. Summarizing 360 feedback into themes. Generating interview question banks from competency frameworks. Writing team communication drafts (announcements, strategy updates, OKR summaries). Creating onboarding checklists for new engineers. Producing capacity planning templates. Writing team norms and working agreements from standard patterns.
Using AI to synthesize team sentiment from 360 feedback, identifying the surface themes, and then applying your direct knowledge of each person's situation to identify the two or three signals that actually matter and require action. Having AI generate candidate interview questions across multiple competency dimensions and then selecting the ones that actually reveal what you need to know about the specific type of judgment you're hiring for. Using AI to produce engineering throughput and delivery data analysis while you interpret what the trends actually mean about team health, process gaps, and individual growth ... because the numbers never tell the whole story. Having AI draft organizational proposals so you can focus on the political and interpersonal work of getting them accepted.
Knowing which engineer on your team is about to quit, three weeks before they know it themselves. Reading the energy in a room. Recognizing when a technical disagreement is really a relationship that went sideways six months ago. Making the call to protect your team from a bad product decision at personal political cost, when the pressure to just execute is enormous. The hiring judgment behind "this resume is perfect and something is off" or "this resume is weak and this person is exceptional, and here's why." Leadership runs on human context that no data set captures, which is exactly why it stays human.
Engineering managers whose identity is built on producing documents and running ceremonies will find their value questioned more and more. The ones whose identity is built on assembling teams that do excellent work and stay together, and who can explain how they do it, will be in extraordinary demand. This is the move from process manager to people leader. If you're unsure which side of the line you're on, ask what value you'd still create if every meeting and document vanished tomorrow. The honest answer is the one that matters.
Getting better at OKR frameworks, agile ceremonies, and management methodologies. SCRUM, SAFe, OKRs, PI Planning, Shape Up. Process fluency is cheap; any intelligent person can read a book and run a ceremony. Own the team instead. The durable judgment is knowing which process fits which context, when to abandon a process because the situation changed, and how to build a team that performs well no matter which process it's running.
Build a "manager's context document" for each person you lead: a living note capturing their career aspirations, their growth edges, their work preferences, the feedback they've received and how they responded, and the specific things you're watching for in their development. Keep it for yourself, not for HR. Managers who maintain this kind of context make personalized development decisions that actually fit each person, and it's the best insurance against the trap of managing everyone the same way.
The nine roadmaps above give you the "what" for your specific role. This section is the operating system that runs underneath all of them: the moves that work whatever your title, plus the mindset shifts that turn a 90-day sprint into a decade-long career advantage.
The Three Mindset Shifts That Matter More Than the Tactics
From "doing the work" to "owning the outcome." Building a feature and handing it off is doing the work. Building it, watching its performance in production, reading the metrics, and driving the next iteration is owning the outcome. AI handles the first part comfortably. The second part needs your accountability, your judgment, and your context held across months, which is why it stays yours. Whatever you're building right now, find a way to stay attached to it after the build is done, through the first incident, the first metric review, the first round of user feedback.
From "learning skills" to "building context." When a new technology shows up, the instinct is to learn it: take the course, get the certification, read the blog posts. That instinct is fine as far as it goes, and it doesn't go far enough on its own. Context, the deep understanding of a specific system, domain, and organization, is what turns a skill into value. A generic React developer is a commodity. A React developer who spent two years building the design system for a specific product, knows every trade-off and why it was made, and can make the next architectural call correctly is someone the company can't easily replace. Skills travel; context compounds where you stand.
From "being good at your job" to "being the person who makes things clear." Every engineering organization has people who do excellent work nobody outside their team ever sees, and people whose judgment shapes decisions across the org, whose opinion gets sought before major calls, whose frameworks become the way the team thinks about a problem. The gap between them is rarely technical ability; it's the habit of articulating your thinking clearly and putting it where others can find it. Write, teach, document, present. Judgment kept private stays invisible and replaceable no matter how sharp it is, while judgment made visible is what gets you in the room.
We are in the middle of a leverage expansion event. And humans are terrible at thinking clearly in the middle of them.
When the calculator arrived, mathematicians panicked. When the compiler arrived, assembly programmers panicked. When cloud computing arrived, sysadmins panicked. Each time, the technology did exactly what the panic predicted and automated a layer of work that used to take human effort. And each time, the people who read the shift early and deliberately moved up a layer ended up with more leverage, more scope, and more impact than the ones who tried to beat the technology at its own game.
AI is the biggest leverage expansion in the history of software engineering, and it marks the end of commodity engineering rather than the end of engineering itself. Engineers who treated their jobs as a pile of tasks, write this code, produce this report, generate this design, will feel it as a threat. Engineers who treated their jobs as a set of outcomes they were accountable for will feel it as a gift, because the gift is exactly what they were already reaching for.
The future belongs to the end-to-end tinkerer
The one who owns outcomes across the whole stack, who can travel from "here's the problem" to "here's why my solution was right" without a committee validating each step along the way.
Who builds things, watches them fail, works out why, and fixes them, holding full accountability for the whole arc from problem to result.
That is the one thing AI cannot be handed. Accountability for the result.
None of this requires a course, a certification, or a LinkedIn Learning subscription. It requires two things: the honesty to audit where your work actually lives across the three layers, and the deliberate choice to do harder work that needs you, using AI to clear the path toward it.
The window for this shift won't stay open forever; the market is moving. It also isn't slamming shut tomorrow. You have 90 days to begin, and that's more than enough time to start.
I publish guides, frameworks, and honest takes on engineering, leadership, and the AI era regularly. If this gave you something real, a framework you'll use or a move you'll make, come find me where I post. I'd love to hear what resonated, what you pushed back on, and what you actually went and did.
New role deep-dives, frameworks, and no-bullshit learnings on engineering and the AI era, sent straight to your inbox and feed. No fluff, no course pitch, no spam. Just the stuff worth reading.