This one is personal. It is based on my own experience, conversations with friends who are in the middle of these decisions right now, and patterns I keep seeing repeated across the industry. It is not a framework or a methodology. It is my opinion on a question that more people are asking than are willing to talk about publicly.
You have the offer letter open in one tab and LinkedIn in the other. Or you are sitting in day three of a four day quarterly planning session, watching a room full of adults debate how many story points fit in a t-shirt size while a facilitator asks everyone to dot-vote on sticky notes that will be photographed, transcribed into Jira, and never looked at again. Somewhere around hour six, while someone argues that a large is really two mediums, you start wondering if Office Space was a documentary.
Or maybe the question is not whether to leave. Maybe you are a director who just lost three engineers this quarter and you are staring at exit interview notes that all say the same thing. Maybe you are a Chief Technology Officer who signed a seven figure AI tooling contract and your organization still ships at the same velocity it did in twenty twenty-three, except now it ships with more expensive software licenses.
Whatever side of this you are on, the diagnostic is the same. There are three kinds of engineering organizations right now.
First, the AI-Native. The organization has fundamentally changed how it builds, tests, reviews, and deploys software. Agents are part of the workflow. The software development life cycle has been redesigned. Governance is lean and real. Engineers ship.
Second, AI on paper. The organization bought the tools. Maybe ran a workshop. Posted an AI policy on the intranet. But the software development life cycle has not changed. The approval gates have not changed. The team structures have not changed. AI is installed but not adopted. It is a line item on a slide, not a way of working.
Third, Not Yet or Never. The organization has not started. There is no AI tooling budget. There is no pilot. There may be active resistance from leadership, from security, or from a culture that views AI as a threat rather than a capability. Some of these organizations are early and will catch up. Some of them have made a decision, whether they admit it or not, that they are not going to change. If you are sitting in a Not Yet organization, the question you need to answer honestly is whether it is not yet or never. The difference between those two words is the difference between an organization that is behind and an organization that is done.
The gap between these three is not small. It is not slightly better tooling. It is a fundamentally different way of building software. The question, whether you are asking it about your next job or your current one, is which kind of organization you are sitting in.
Now, let us start with the basics. Before you even get to the AI question, there are signals that tell you whether an organization values the people who work there. These apply regardless of whether the organization is AI-Native, AI-on-Paper, or Not Yet. They are a leading indicator for everything else, because an organization that gets these wrong is not going to get the harder stuff right.
Look at business model durability. A green flag is when the core business is not easily replaced by AI. Or if it is exposed, leadership has a credible plan to adapt and is already executing on it. You are not joining a company that will be a case study in disruption by twenty twenty-eight. A red flag is when the revenue depends on work that AI is learning to do faster and cheaper every quarter, like manual testing services, staff augmentation, basic development outsourcing, or rote content production. If nobody in leadership is talking about it, or they are talking and doing nothing, you are joining a company whose business model has an expiration date that is closer than your vesting schedule.
Then there is compensation. Market rate or above is the green flag. It is revisited as the market reprices. Nobody fights you over ten thousand dollars when you ship five hundred thousand dollars of value a quarter. The red flag is pay below market, justified by internal equity. If compensation bands were last updated before AI changed the value curve, your best people know they are underpaid. They are polite about it until they are not.
Healthcare and benefits matter. Modern, comprehensive, and revisited regularly is the goal. The organization treats benefits as part of how it competes for talent, not as a cost to minimize. The red flag is a legacy package nobody has renegotiated in years. High deductibles, limited mental health coverage, and benefits that signal we care about you on the careers page but we care about the budget on your pay stub.
Consider paid time off. Real time off is the green flag. People take it. Leadership models it. Nobody tracks whether you took a Friday after a big ship. The red flag is unlimited time off where the unwritten rule is two weeks a year and anything more gets a raised eyebrow. Or a fixed bank so small you hoard days like currency.
Work location is another signal. Flexible is the green flag. Remote, hybrid, or in-office based on what works for the team and the work, not based on a CEO's real estate anxiety. The organization trusts engineers to produce results regardless of where they sit. If there is an office, people go because they want to, not because someone is tracking badge swipes. The red flag is a mandatory return to office with no clear reason beyond collaboration and culture. Badge swipe tracking. Managers who equate presence with productivity. Or fully remote with always on camera expectations and Slack response time monitoring. That is surveillance with a friendlier name.
How work is measured tells you everything. Results are the green flag. Features shipped, problems solved, and customers served. Nobody cares what hours you kept or how many commits you made on a Tuesday. The red flag is measuring hours. Timesheets, utilization tracking, and core hours policies. The organization measures input because it does not know how to measure output. If someone asks you to log your hours against project codes in twenty twenty-six, they are telling you they manage a cost center, not an engineering organization.
Finally, work life expectations. A sustainable pace is the green flag. The organization ships fast because the system is designed for speed, not because people work nights and weekends. Engineers have lives outside the company. The red flag is a nine-nine-six culture, whether they call it that or not. Nine AM to nine PM, six days a week. Always on Slack. We work hard and play hard in the job description usually means you just work hard. You will ship a lot in year one and be looking for the exit by year two.
Here is a note on that last point. Some AI-Native organizations run nine-nine-six and they score green on everything else. They have the org design. They have the tooling. Unlimited tokens. Small teams. Fast deploys. Lean governance. The software development life cycle is right. They also burn enormous hours and enormous token budgets, and the velocity is real. These are not broken organizations. They are intense ones. If your life lets you go hard for two years and you want to, that is a legitimate choice. You will learn faster there than almost anywhere else. But if you are evaluating where to spend the next three to five years, you need to know the difference between an organization that ships fast at a sustainable pace and one that ships fast because it combines good design with raw hours. Both work. One has a shelf life for the people inside it.
An organization that nickels and dimes your compensation, your healthcare, and your time off is telling you how it values its people. Ask yourself if this company will give you unlimited tokens. Will it invest in frontier model access without making you justify every API call to finance? If it will not invest in your wellbeing, it will not invest in your tools. The way a company treats your benefits is a preview of how it will treat your infrastructure.
Right. Now for the AI specific diagnostic. This separates AI-Native from AI-on-Paper. If your organization is Not Yet, most of the green flags will not even be recognizable to you. That is itself an answer. And a note for those of you in regulated industries like financial services, healthcare, or insurance. Some approval gates exist because a regulator requires them. That is real. The question is not whether governance exists. The question is whether your organization piled discretionary process on top of regulatory requirements and never separated the two. Most have not. That is where the theater lives. Be honest about which side describes your organization.
Look at team size per feature. A green flag is about five engineers, all of whom ship code. The team owns the spec, the code, the tests, and the deployment. Nobody on the team has a role that is only coordination. The red flag is eight to twelve people across product, design, engineering, quality assurance, security, and DevOps. Half of them do not write code. Coordination overhead is the majority of the cost.
Consider AI tool access. Green flag is infrastructure. Frontier models are available, no ticket required, no token tracking, and no procurement committee. Try a new tool Tuesday, use it Tuesday. Red flag is rationed access. One model approved six months ago, two generations behind. Tokens are tracked. Every new tool requires a security review that takes longer than the tool's useful life.
Ship frequency is a clear signal. Green flag is days. Continuous deployment is the default. Red flag is quarterly at best. Release trains, code freezes, and scheduled deployment windows. A hotfix needs the same approval chain as a new feature.
Testing shows the shift. Green flag is automated, full stack testing where AI agents write and maintain tests. The testing pyramid is a square because the cost constraint that shaped the pyramid is gone. Red flag is a manual quality assurance team clicking through spreadsheet scripts every release. Automated coverage is low because nobody had time to write tests, and now nobody has time to maintain the ones that exist.
Code review turnaround is vital. Green flag is hours. The process is redesigned for AI-assisted volume. Red flag is days. Two senior engineers bottleneck everything. Reviews are superficial because reviewers are overwhelmed. Everyone knows it, and nobody changes it.
Bureaucracy is a major differentiator. Green flag is low. Security is built into the pipeline. Architecture decisions do not need a six week review board. It is flat enough that an engineer with a good idea can get it in front of someone who can say yes within a day. Red flag is high bureaucracy. Four day sprint plannings. Two hour refinement sessions. Daily standups that take forty-five minutes. Retrospectives that produce action items nobody tracks. Ceremonies that exist because someone read a book in twenty-fourteen, not because they produce outcomes. Architecture Review Boards, Change Advisory Boards, and security sign-offs. Twelve layers of management between you and anyone who can make a real decision. Governance is theater.
The software development life cycle itself must evolve. Green flag is a cycle redesigned for AI-native speed. Lean governance and no human bottleneck at every stage. Red flag is a twenty-nineteen process with AI bolted onto the coding step. Everything upstream and downstream is exactly as slow as before. The bottleneck moved, but nobody adjusted.
Engineer trust is the foundation. Green flag is autonomy over tools, workflow, and decisions. You are hired for judgment and allowed to use it. Red flag is approved tools, approved workflows, and approved everything. Deviation is discouraged. Engineers are treated as interchangeable line items.
Finally, look at leadership. Green flag is when leaders build. Your director has commits in the repository this month. Your Vice President of Engineering can demo the product and explain the architecture because they have been in the code. Technical leadership means technical work, not just attending steering committees. Red flag is when leaders only manage. Your director's last commit was three years ago. Your Vice President of Engineering has not opened an integrated development environment since they got promoted. They manage headcount, attend reviews, and produce slides. Their technical judgment is based on what someone told them in a one-on-one, not on what they saw in the code.
If you scored mostly green flags on both tables, you are in an AI-Native organization. If you scored green on the baseline but red on the AI table, you are in an AI-on-Paper organization. Good company, but has not changed how it builds. If you scored red on both, you may be in a Not Yet or Never organization. The question from the beginning applies. Is it not yet or never? What you do with that answer depends on who you are.
Now. If you are a developer, consider someone like Priya. She spent eighteen months at an AI-Native startup. Twelve engineers, no quality assurance team, and no release train. She shipped features end to end. Her pull requests merged in hours. She deployed when the code was ready, not when the calendar said she could. She paired with AI agents the way a previous generation of engineers paired with each other, except the agent never called in sick and never had a conflicting meeting.
Then a Fortune five hundred company came calling. A forty thousand dollar raise. A senior title. A name-brand resume line. She went to the onsite and they walked her through the floor. She saw the quality assurance bullpen. She asked about deploy frequency and the hiring manager said they do releases every two weeks, sometimes three. She asked about pull request turnaround. Usually under a week. She asked what AI tools the engineers used. We have an autocomplete tool, and we are evaluating agentic options for next year.
She turned it down. It was not an easy decision. She ran the numbers twice. She called her partner. She lost a night of sleep over walking away from that kind of money and that kind of name on her resume. But she kept coming back to the same calculation. The forty thousand dollars was not enough to cover the cost of slowing down. If she spent two years in that environment, she would come out the other side with a senior title and a skill set that had stopped compounding the day she walked in.
Priya can wait. The right role will come. A company that scores on the left column and pays what she is worth will find her, or she will find it. AI-native engineers are the scarcest resource in the market right now and that is not changing anytime soon. She does not need to take the first offer that waves money at her. She needs to take the offer that lets her keep building at the pace she has earned. The money will catch up. It usually does for engineers at this level, and when it does, she will not have traded two years of compounding to get it.
That is the math most developers do not run. Your career compounds the way interest does. Two engineers starting at the same level today will be in completely different places in twenty-four months depending on which column they work in. The one shipping with AI agents is not two years ahead on a linear scale. They are operating in a fundamentally different paradigm, and the distance grows every quarter.
Now, before you start updating your resume, if you do not love your current team, or the work feels stale, or your manager is someone you tolerate rather than someone who makes you better, but the organization itself scores on the left column, then pause. If you have real time off, frontier model access, trust, and a pipeline that gets out of your way, that setup is rarer than you think. Burnout is real. A bad quarter on a good team in a good organization is not the same thing as being in the wrong place. Sometimes the answer is a different project, a different team, or a hard conversation with your manager about what you need. Do not confuse a bad quarter with a bad company.
And if you are thinking about staying because you want to be the one who transforms the place, do the math. By the time you drag an AI-on-Paper organization into operating like it is twenty twenty-six, it will be twenty twenty-eight. You will have spent two years fighting governance committees and educating skeptical Vice Presidents while engineers at AI-Native companies spent those years shipping. The market is paying a premium for people who build, not people who managed change programs.
One more thing, because I do not want to pretend this is simple. Not everyone can leave. You might be mid-vest on equity that represents real money. You might be on a visa tied to your employer. You might have a pension timeline or a financial situation that makes jumping a genuine risk, not just an inconvenience. And the AI-Native startup that ships daily is not automatically the right bet either. Startups fold. Runway runs out. Equity can be worth zero. The diagnostic tells you what to look for, not what to do. Your constraints are yours and nobody else gets to dismiss them.
You can work these signals into your interview conversations. Not as an interrogation, but as the questions you actually care about. Ask how many people it takes to ship a feature from idea to production. Ask what AI tools the engineers use today, and who decides what is available. Find out what the token budget is per engineer, or if there even is one. Ask how often they deploy to production and if they have a separate quality assurance organization. What is the average time from pull request opened to pull request merged? How many approval gates sit between code complete and production? Ask when was the last time they removed a process, a gate, or a standing meeting. If you want to try a new AI tool next week, what do you need to do? What changed about their software development life cycle in the last twelve months?
If the answers sound like the left column, go. Build things. Grow. If the answers sound like the right column, you are walking into twenty-nineteen with better autocomplete. The logo on the building and the number on the offer letter will not change that.
So. If you are a leader, the diagnostic above applies to you the same way it applies to developers, except the stakes are higher and the questions are different. Consider someone like Kevin. Director of Engineering, four years in the role, with about one hundred and fifty engineers. He was good at his job. He cared about his people. He spent six months building a business case for agentic development tools. He showed productivity data. He got his Chief Technology Officer on board. The proposal went to the budget meeting and the Chief Financial Officer sided with the Vice President of Quality Assurance. The argument was that developers could not be trusted to test their own code, let alone trust AI agents to do it. The QA organization needed to stay. The manual testing process needed to stay. The token budget was cut in half because, in the CFO's words, we need to see proof before we invest further.
Kevin sat in that meeting and realized he was not fighting a resource allocation battle. He was fighting a belief system. The organization believed, at the leadership level, that engineers were not trustworthy enough to own quality. That the only reliable way to ensure software worked was to have a separate group of humans manually verify every change. He had spent eighteen months managing friction instead of building things. His technical skills were atrophying while he sat in budget meetings arguing for tools his team needed a year ago.
Kevin started asking himself a question that most leaders avoid. Is this where I want to spend the next three years? Not how do I fix this organization? That is the question leadership tells you to ask. The real question is whether the years you spend fighting governance committees and belief systems are years you want to trade for the years you could spend building.
Kevin took an individual contributor role at a company that ships with AI agents. Senior staff engineer. Smaller title. Less direct authority. A pay cut he does not talk about. The first three months were humbling. He had not written production code in over a year and the tooling had moved faster than he expected. But he is shipping features again, and his technical judgment is rebuilding in ways that matter. He told people he took a step back. Some of them believed him.
That path is not for everyone. Some leaders want to lead. If that is you, the diagnostic still applies, but the questions you need to ask when evaluating your next role are about whether you will have the authority and the organizational support to actually change things, or whether you are signing up to manage friction for three years while your own skills decay.
Here are the questions to ask when you are interviewing for a leadership role. Not the polite ones. The ones that tell you whether the organization will let you lead or whether you are walking into Kevin's budget meeting on day one. Ask how fast this organization has changed a major process in the last twelve months. Ask which one, and who drove it. If you need to eliminate an approval gate or disband a review board, what does that process look like and who has to agree? What constraints will you inherit that you cannot change? Regulatory is fine, but we have always done it this way is not. Does the engineering organization own its deployment pipeline, or does another team control when code goes live? What is the token budget for AI tools, and who controls it? Is there a separate quality assurance organization, and if so, is that negotiable?
Ask what happened to the last leader who tried to change the software development life cycle. Did they succeed, and are they still here? How does the Chief Financial Officer view engineering investment? Is it a cost center or a value driver? If you want to restructure teams to ship with two to three engineers instead of eight to twelve, what stands in your way? What does the executive team believe about AI adoption right now? Are they aligned, or are you walking into a political fight? Can you hire the AI-native engineering talent you need and pay above market to get them? Or will you lose every candidate to a compensation committee that takes three weeks to approve an offer and then counters forty thousand dollars below ask?
Find out the security chief's posture on AI tooling. Are they a partner who helps engineers move fast within guardrails, or are they the person who wants to unplug every machine that connects to an external API? You will know the answer within ten minutes of meeting them. Also, ask what percentage of your time HR will require you to spend on non-engineering work. Talent reviews, calibration sessions, engagement survey action plans, and mandatory HR one-on-ones. Some of it is necessary. If the total consumes forty to fifty percent of your calendar, you are not being hired to lead engineering. You are being hired to service a process.
If the answers tell you that the organization is ready to change and you will have the authority to drive it, that could be the right move. If the answers tell you that you will spend your first year building consensus for things that should have been decided already, navigating a security chief who treats every API call as a threat vector, and losing candidates to a compensation committee that moves slower than the market, you are signing up for Kevin's experience with a better title.
The same compounding math that applies to developers applies to you. The years you spend managing organizational friction are years you are not building, not growing technically, and not learning the paradigm that is reshaping the industry. Some of the best career moves in the next two years will be leaders who step back to individual contributor roles at AI-Native companies. Not because leadership does not matter, but because leading in an organization that will not change is not leadership. It is administration.
Now, if you are an executive, both columns in that diagnostic describe engineering organizations you are paying for. One ships. The other performs elaborate rituals about shipping. Both cost real money every month. Only one produces proportional results. The AI-on-Paper organization is not cheaper. Eight people and seven weeks to ship what two people ship in days is not a staffing model. It is a tax on organizational indecision. You are paying fully loaded costs for coordination overhead, manual testing cycles, approval queues, and every person in the value stream who touches a feature without writing a line of code.
I was in a steering committee last quarter where the Chief Financial Officer finally did the math nobody had bothered to do before. They were spending three hundred and twenty thousand dollars per feature shipped. He found a comparable company with twelve AI-native engineers spending seventeen thousand dollars per feature and shipping ten times the volume. The room got quiet. The CFO did not need another AI strategy deck. He needed the diagnostic and a calculator.
The developer is deciding where to invest their career. The leader is deciding whether the next organization will let them lead or make them administer. Your challenge is different from both. You own the governance model, the HR model, the operating model, and the metrics. You are the person who can actually redesign the organization so that it retains the Priyas and empowers the Kevins instead of losing them. But that only works if you are willing to change the things you control.
Here are the questions you should be asking yourself and your leadership team. Not next quarter, but now. Have you redesigned your software development life cycle for AI-native development, or did you bolt AI onto the twenty-nineteen process? The bottleneck has moved from coding to everything around the code. If your governance, review, testing, and deployment processes have not changed, you have a faster engine on the same chassis. Your engineers know this. It is why they leave.
Can your organization hire and retain AI-native talent? The engineers who operate in AI-Native environments are worth more than your compensation bands reflect. If your talent team is rejecting candidates on internal equity grounds and your compensation committee takes three weeks to approve an offer, you are not competing for talent. You are watching it walk to your competitors while your process runs its course. Can you pay above market for the people who will transform your output? If the answer is no, HR will not allow it, that is the answer.
Have you built an environment where your best people want to stay? Retention is not a bonus problem. It is an organizational design problem. Engineers stay where they can build. They stay where code review takes hours, not days. Where they deploy when the code is ready. Where nobody rations their tools or questions their judgment. If your organization scores on the right column of the diagnostic, your best people are not leaving because of compensation. They are leaving because the organization tells them every day, through its processes, that it does not trust them.
What is your security chief's actual posture on AI tooling? Is security a partner that enables engineers to move fast within guardrails, or is it the department that blocks every external API, delays every tool evaluation, and treats every AI initiative as a risk to be mitigated? If your security chief's default is no until proven safe rather than yes within these boundaries, your AI adoption will move at the speed of your security review queue, which is to say it will not move.
Does your HR model create value or consume it? Mandatory talent review cycles, calibration sessions, and engagement survey action plans. Ask yourself honestly if this operating model helps your leaders build better teams, or if it consumes forty to fifty percent of their time on process that produces slides nobody acts on. Your Kevins are sitting in those meetings instead of building. Some of them are deciding to leave because of it.
Have you redesigned your governance model, or is it still theater? The approval gates that made sense when humans wrote all code at human speed do not make sense when agents produce code at three times the velocity. Every week you defer this redesign is a week your teams absorb the drag and your best people reconsider their options.
Are you willing to build a parallel organization? You may need to build a new organization rather than transform the existing one. The existing organization has twenty years of accumulated process antibodies. A parallel organization demonstrates what is possible without requiring you to win every internal argument first. It also gives your best people a place to go that is not your competitor.
Are you measuring what matters? If you are measuring utilization instead of cycle time, you are optimizing for the wrong thing. Your board does not care if your engineers are busy. They care if the company is shipping. Revenue per engineer tells you whether the AI investment is producing returns. Feature cost tells you whether your organization structure is a multiplier or a tax.
If your organization scores on the right column, your best people already know it. The question is not whether you can afford to change. It is whether you can afford not to. Working on it is not the same thing as having changed. Running a workshop is not the same thing as having redesigned your governance model. Buying the tools is not the same thing as having built an organization that can use them.
Which column describes your organization today? And what are you going to do about it this quarter, not next year? Because every Priya who interviews at your company is running this diagnostic in her head before she leaves the parking lot. Every Kevin on your leadership team is doing the math on how many more budget meetings he is willing to lose before he stops fighting and starts building somewhere else.