October 16, 2026

AI for the Over 40 - Week 36: Do We Still Need Developers?

We launched an internal initiative called AI Activation, a group focused on activating AI for ourselves and our clients through lived experience. Thirty people signed up. Not everyone made the first meeting, but the level of voluntary interest tells you something: people are excited about what is possible and want to figure out how to make it real.

The very first topic that came up was development estimation. How can we use AI to improve how we estimate development projects? It is a reasonable question. Estimation is time-consuming, inconsistent, and high-stakes, exactly the kind of work AI should be able to help with.

Twenty minutes into the discussion, one of our developers raised an objection: Why are we spending so much time discussing how AI can help us estimate? The bigger question is, what are we getting paid to do when AI fundamentally changes the nature of the work itself?

He was right. We were using AI to improve a process built on the assumption that the work would remain fundamentally the same. Better estimation is valuable, but it does not matter how accurately you estimate a 60-hour development effort if AI is about to compress the development itself into two hours. The unit of work you are estimating is changing underneath you. That is not an estimation problem. It is a business model question.

That developer’s question is one that this entire industry is already asking, and in many cases, already answering. High-profile layoffs citing AI have made headlines, with companies cutting developer headcount and citing AI capabilities as justification. The question is not being avoided. It is being answered in the bluntest possible terms: termination letters.

But the answers tend to land in one of two extremes. Either “AI replaces developers,” which justifies cutting people, or “experienced developers are irreplaceable,” which avoids the harder conversation about what is actually changing. What is missing is an honest answer that lives in the middle. I have spent 35 weeks building my own version of that answer, mostly without realizing it.

The case against developers: why AI seems to replace them

Before I defend developers, let me make the strongest case I can against them. If I cannot articulate why smart people are asking this question, I have no business answering it. And the strongest case does not come from a hypothetical. It comes from my own series.

I am not a developer. I wrote code earlier in my career, legacy CAL in NAV, but I have not been a working developer in years, and I do not write Python, JavaScript, or modern AL. Over the past 35 weeks, I have built things that would have previously required a developer, or more accurately, things that would have previously required a developer if they had been worth building at all.

In Week 10, I used AI to solve a contract routing problem that had been frustrating our team forever. I built it with Microsoft Forms and Power Automate, no developer, hours to build instead of weeks. In Week 11, I sat down with AI and turned an idea into a working prototype, and a project our developers had estimated at 60 hours of work became a functional prototype in two hours without me writing a line of code. In Week 18, I built an integration between Outlook and Todoist that solved a 20-year personal frustration, a system that flags emails, creates prioritized tasks, handles attachments, and applies conditional logic based on who sent the email, built myself, iteratively, with AI guiding each step. In Week 28, I spent the better part of a week building an AI-powered career development system, not a simple chatbot but a multi-component system with diagnostic assessments, personalized development plans, and coaching workflows.

Every one of these projects would have previously required one of two things: hiring a developer or deciding it was not worth the investment. In most cases, it would have been the second. The contract routing problem was not important enough to justify developer hours. The Outlook-Todoist integration was a personal annoyance, not a business priority. The career development system was an idea that would have died in a prioritization meeting.

AI did not just let me do developer work. It made viable an entire category of solutions that would never have existed because they could not meet the investment threshold. That is the case against developers, not that AI replaces what developers currently do, but that AI enables millions of non-developers to build things that were previously impossible for them, eliminating the need for a developer to be involved at all.

And I believe that case is genuine. It is not hype. I lived it. I documented it for 35 weeks. Now, let me tell you why it is incomplete.

Where AI hits a wall building software

Here is the pattern nobody talks about when they celebrate what non-developers can build with AI: every project I just listed hit a wall. And there was always a wall.

Wall 1: Why AI tools do not scale past one user

Every solution I built worked for me. For one person, with my permissions, on my machine, solving my problem. The moment any of those solutions needed to work for someone else, multiple users, different permissions, shared data, error handling for when things go wrong, and I am not there to fix them, the project either died or required a developer.

The career development system I built over a weekend hit platform constraints that I could not resolve on my own. Without a developer, I got stuck and settled for something much simpler than what I had originally designed, not because the vision was wrong, but because I did not have the technical ability to get there. My Outlook-Todoist integration works beautifully for me. If I wanted to deploy it across a team of consultants with different email configurations, different Todoist accounts, and different priority rules, that is not a prompting problem. That is an engineering problem.

There is a reason personal tools and enterprise systems are different categories. It is not just complexity; it is accountability. When a tool I built for myself breaks, I troubleshoot it over coffee. When a tool used by 150 people breaks on a Friday afternoon during month-end close, someone needs to be able to diagnose it, fix it, and ensure it does not happen again. That someone understands system architecture in ways that natural language prompting cannot substitute for.

Wall 2: The AI prototype to production gap

That 60-hour-to-2-hour prototype story from Week 11 is the most powerful evidence in the case against developers. It is also the most misleading if you stop there. Here is what happened after those two hours: I could not even get the prototype to compile. AI produced the code, but I needed a developer to get it running.

That part did not take long, and once it compiled, we had something to look at, something to react to. It did not work well, but it made the abstract concrete, which was genuinely transformative, because in the old model, clients would not see anything real until weeks of development had passed and most of the budget was spent. But the prototype was not the product. It was the starting line.

Once I could see something real, I realized how much I had missed in my own design. Then came everything that makes software actually work in a business: edge cases the prototype did not handle, integration with existing systems, security considerations, performance at scale, data validation for inputs that do not look like the happy path, and, critically, the iterative refinement that happens when real users interact with something real and discover that what they asked for is not quite what they need.

We spent as much time getting from prototype to production as we would have in the old model. The difference was not that AI eliminated the hard work. The difference was where the hard work happened.

Wall 3: How AI changes software development budgets

This is the part that matters most for understanding what is actually changing. Project budgets are not driven by how quickly a developer can produce code. They are driven by business value, the cost of the problem weighed against the expected benefit of solving it. The budget is a function of the problem, not the labor.

In the old model, a massive portion of that budget got consumed before anyone could see anything real. Requirements gathering, design documents, and first development cycles ate through it, and by the time a client could evaluate what they were getting, 60 to 70 percent of the budget was gone. Whatever was left went to getting the product to a minimum viable standard, not the vision, not what the client actually wanted, just something that cleared the bar of good enough.

Every consultant and developer knows what that moment feels like. The client’s original vision was ambitious, but you have burned through the budget getting to something functional, and now you are negotiating which features get cut, which improvements get deferred, and which compromises everyone agrees to live with. The product ships at minimum viable product, not because that is what anyone wanted, but because that is where the money ran out.

AI changes where the budget goes, not how much there is. The prototype arrives in hours or days instead of weeks, the client sees something real early and reacts early, and the expensive cycles of building the wrong thing shrink dramatically. But the freed-up budget does not go back into the client’s pocket. It goes to the work that used to get cut, the refinement, the edge cases, the below-the-line improvements I wrote about in Week 32 that never happened because the effort threshold was too high. For the first time, the budget stretches past minimum viable product toward what the client actually envisioned.

The result? Same budget. Dramatically better product. And the work that gets you from a minimum viable product to the real vision, the architecture decisions, the integration design, the judgment calls about what matters most, that is developer work. The hardest, most valuable kind.

Why AI coding prototypes are not the hard part

I need to go back to that Week 11 prototype, the one that compresses 60 hours into two, because I have been telling an incomplete story, and the missing part changes the argument. Those two hours were real. But they were not the whole effort.

Before I ever started vibe coding, I had spent hours researching the problem. I had consulted with peers and domain experts, explored different approaches, and developed a deep understanding of what the solution needed to accomplish, why everyone I spoke to told me what I wanted to do was not possible, and what the architecture should look like. All of that happened before any code was produced.

Then, when I sat down to create the design, I had an advantage most non-developers do not have: the coding background I mentioned. I have not written production code in years, but I know enough to describe what I want in precise technical terms, and I could specify logic, structure, and architecture in language that AI could act on immediately. And I did something else that rarely happens in real projects: I told AI exactly what I wanted and exactly how I wanted it built.

That last point is the one that matters most, because in real client engagements, it almost never happens. Most clients come to us with a general idea of the outcome they want. They know the problem they are trying to solve, but they cannot specify the solution technically, or worse, they come to us with AI-generated specifications that look thorough but have not been validated against how their business actually works. They need someone to take their vision, often vague, sometimes contradictory, always evolving, and translate it into something buildable.

That translation work is iterative. It requires knowing enough about the technology to see possibilities the client cannot imagine and enough about the business to know which possibilities actually matter, and it requires building shared understanding between two humans, a process AI can support but cannot replace, at least not yet.

So the 60-to-2 story is real, but the reason I could do it is precisely that I brought decades of domain expertise, hours of prior research, a technical vocabulary from my coding background, and the ability to specify exactly what I wanted. Strip any of those away, and the two-hour prototype does not happen. The steelman proves the counterargument. What looks like “AI replacing developers” is actually “a domain expert with technical vocabulary using AI to skip the initial coding step.” The initial coding step was never the hard part.

What developer jobs look like in the AI era

If the walls I hit are where non-developers stop, and real developers start, then the developer’s job is not disappearing, it is concentrating and changing.

Work that is compressing includes writing boilerplate code, building standard pages and reports, and translating well-understood requirements into well-understood patterns. If 60 percent of a developer’s week was this kind of work, that 60 percent is now under serious pressure.

Work that is expanding includes architecture decisions, integration design, and data validation, not writing the validation code, but knowing what to validate. Understanding which business rules must be enforced deterministically and how to design for graceful failure when probabilistic systems produce unexpected output falls here, too.

Emerging work is the bridge between probabilistic AI and deterministic business systems. Someone needs to architect the intake layer that takes unstructured AI output and transforms it into structured, validated, postable transactions. These roles barely exist today, but they will be essential within five years, and the people best positioned to fill them are not AI specialists who need to learn business systems. They are business system developers who have built AI literacy.

Why developers are becoming systems thinkers

The developer who asked “what are we getting paid to do when AI changes the nature of the work?” was demonstrating exactly the skill that makes developers indispensable. He was not defending his job. He was diagnosing a problem. That is not a coding skill. That is the ability to look at a system, technical or organizational, and see where the foundational assumptions no longer hold.

That is what developers do. Not write code. Think in systems. And AI does not replace that; it makes it more valuable because the systems are getting more complex, not simpler.

What developers should learn to stay relevant

If you are a developer reading this, the honest message is that the ground is shifting under you, and the direction of the shift should inform what you invest in learning next. If 60 percent of your current work is writing code that AI can generate from a natural language description, that 60 percent is going to compress. Not disappear overnight, but the trajectory is clear, and pretending it is not will not protect you.

What will protect you is becoming the person who can work at the boundaries: the boundary between what a non-developer can prototype and what an enterprise needs to run in production, the boundary between what AI suggests and what the business system accepts as truth, and the boundary between a working demo and a solution that handles the messy reality of multiple users, edge cases, and Friday-afternoon failures during month-end close.

Those boundaries are where the value is concentrated. The developers who invest now in understanding where AI output requires human judgment before it touches a system of record will be the ones whose roles expand rather than compress.

Self-assessment: Is your developer role at risk from AI

1. Divide your current work into three categories. What percentage of your week is work that AI could generate from a clear description? What percentage requires judgment, architecture, or domain expertise that AI cannot replicate? What percentage is work that did not exist two years ago? Be honest, the ratio tells you where you are exposed and where you are positioned.
2. Build something with AI that is not your job. If you are a developer, try building a business analysis framework using an AI conversation instead of code. If you are not a developer, try building something with AI that you would normally ask a developer to build. Notice where you hit the wall.
3. Ask your own version of the developer’s question. In your next team meeting about AI, stop and ask: Are we using AI to do the same things faster, or are we rethinking what we should be doing?

What is next in this AI and jobs series

This is the first in a series of articles asking the uncomfortable questions that everyone in our industry is thinking, but few are asking publicly. Next: Do we still need consultants? Then: Do we still need partners? And finally: Should not AI make everything cheaper? The answers might surprise you. They are certainly not as simple as yes or no.

This post is part of my “AI Over 40” series. It first appeared on LinkedIn: Do We Still Need Developers?

Read more AI and Copilot blogs.

Trending Posts