Most of our conversations this year have touched upon the subject of AI. Sometimes the discussion centres entirely on it, but more often, it is woven into other topics: a hiring plan frozen since spring; a slide for the board promising a productivity boost that no one on the engineering team fully believes in; or a lead Engineer spending half their week reviewing pull requests.

We started keeping an informal list. Seven questions come up far more frequently than others - the very questions engineering leaders search for online the night before a planning meeting. Here, we present each of them, accompanied by the latest data we could find and our own perspective on the matter.

Will AI reduce the number of developers we need?

It's nearly always the first question. The data points somewhere other than the headlines. Indeed Hiring Lab's July 2026 analysis found that US software development job postings have grown almost 15% since late February 2025, while overall postings fell 7% over the same stretch. The more useful detail for anyone planning a team is who's being hired. Senior roles accounted for 71% of the increase between May 2025 and May 2026, and job titles mentioning AI accounted for 37%.

Consequently, companies are not hiring fewer developers overall, rather, they are hiring different types of specialists. Demand has shifted toward individuals capable of managing artificial intelligence, evaluating its output, and integrating it into real-world systems, at the expense of roles primarily focused on creating initial drafts.

That reframes the decision. "How many people can AI replace?" turns into "what mix of people does our roadmap actually need?", which is a harder and much more useful question. We worked through the numbers on one version of it in 10 developers or 3 Elite Engineers. If you're not yet sure whether your constraint is people or judgement, the capacity vs capability framework is a quick way to find out before anyone touches the headcount plan.

Should companies still hire junior developers?

Yes. Fewer of them, though, and for a different job than five years ago.

The pressure on entry-level roles is real. CNBC's October 2026 report, drawing on Stanford's 2026 AI Index, notes that employment for early-career software developers aged 22 to 25 has fallen by around 20% since generative AI took off, even as roles for more experienced developers expanded. Plenty of CTOs read that as permission to stop hiring juniors entirely.

We'd argue against it. In the same piece, Indeed economist Sneha Puri puts the risk in one line: "Today's entry-level talent becomes tomorrow's senior experts." If you stop hiring junior staff in 2026, by 2029 you will be competing for the same scarce senior Engineers against everyone else who made the same decision - and at whatever price the market dictates.

What has to change is what juniors spend their time on. On an AI-heavy team, they learn faster by reviewing generated code, writing the tests that catch its mistakes and sitting in on design discussions than by writing boilerplate an agent produces in seconds. Our guide to restructuring engineering teams around AI goes into how to set that role up without slowing the senior people down.

How do you measure the ROI of AI coding tools?

Sooner or later a CFO asks this, usually after noticing the tooling line in the budget has tripled. The awkward part is that the most misleading metrics are precisely the easiest to extract. Lines of code, PRs, and closed tickets - all of these increase when a team starts using artificial intelligence, regardless of whether a valuable product is actually delivered. Swarmia's September 2026 piece on measuring AI ROI makes the point well: software has no single productivity metric, and the moment you pick one as a target, Goodhart's law quietly ruins it.

A small basket of measures, taken before and after rollout, tells you far more:

• Lead time from first commit to production
• Change failure rate, and how long it takes to recover
• Review time per pull request, and average PR size
• Rework, meaning how much recently shipped code gets rewritten within a few weeks
• A short quarterly survey asking Engineers where AI helps and where it gets in the way

Read them together. If throughput rises while rework and failure rate climb alongside it, the tools aren't paying off yet. They're moving cost from writing code to fixing it.

Who reviews all the AI-generated code?

This is the one that senior Engineers raise when the CTO isn't in the room. In an October 2026 post, GitHub reported that one in three pull requests on its platform now involves an AI agent. A year earlier, their share was less than one in ten. According to GitHub’s own projections, if this pace continues, within two years the majority of code uploaded to the platform could be written by software agents, with "a significant portion of it potentially never being fully read by a human."

The capacity for conducting reviews is not growing at anything approaching that pace. In most teams, the task still falls to the same three or four experienced specialists, who try to squeeze these reviews in between the tasks they consider their core work. Purchasing additional licenses for AI tools only lengthens the queue of tasks facing them.

Teams that handle this well do a few unglamorous things. They put review time into sprint planning instead of hoping it happens. They keep pull requests small enough to read properly. And they make sure every product area has at least one person with the judgment and the authority to reject code that looks right but isn't. We describe that workflow in more detail in how Elite Engineers orchestrate AI instead of just using it.

Can you trust AI-generated code in production?

Developers are cautious here, and their caution is worth listening to. The 2026 Stack Overflow Developer Survey, which drew more than 30,000 responses, found that 48% of developers trust AI output when they can easily validate it. Only 16% extend that trust to most tasks beyond important work decisions. How they use it backs this up. According to Stack Overflow's summary of the results, AI is mostly used for generating code in familiar areas (67%) and for debugging (61%), while just 20% use it for deploying, operating or troubleshooting production systems.

In other words, trust in the working environment is not an inherent property of the model itself. It depends on whether your team can verify the results generated by the model. This requires tests that validate actual behaviour rather than relying on mocks, clear accountability for each service, and people who know the system well enough to spot an error that appears plausible at first glance. It's also why the same AI tool gives very different results depending on who's holding it.

A simple solution: outline what artificial intelligence can do independently (generating code skeletons, test drafts, documentation); what it can assist with, while the final decision remains with the human (API design, data models); and which tasks remain entirely in human hands - such as security-critical processes, payments, and architectural trade-offs. Most teams never reach an explicit agreement on these matters. Those that do argue far less.

What skills do Engineers need in the AI era?

Typing speed has never been the crux of the matter. And now, even less so. Engineers who derive the most benefit from AI typically share a few common habits. They define the problem precisely before submitting any request. They approach generated code with greater scepticism than code written by a colleague, as it often looks flawless even when incorrect. They understand the overall system well enough to judge when an otherwise correct function is actually unsuitable for the specific use case. And they know when it is better to close the tool and do the work manually.

Moderation should also be on this list. When generating code costs almost nothing, the person who asks, "Do we really need to build this?" is often the one who saves you the most money.

We wrote these up in 6 underrated senior Engineer skills that matter more in the AI era, and turned them into interview criteria in our 10-point hiring checklist for CTOs. If you change one thing in your hiring process this quarter, let candidates use AI during the technical exercise. Then watch what they check.

Will AI fix our delivery problems?

Probably not. It's worth saying plainly, because this hope sits behind a lot of AI budgets.

AI amplifies whatever team it lands in. Give it to a team with clear ownership, solid tests and strong reviewers, and that team gets faster. Give it to a team with vague requirements, fragile pipelines and a single overstretched lead, and you get more code arriving at the same weak points, only sooner. Problems that existed before the rollout are still there afterwards, usually louder.

If that sounds uncomfortably close to home, we listed the warning signs in AI won't fix a weak engineering team. The flip side of the same idea is that AI doesn't replace Engineers; it reveals which ones are elite.

Where should CTOs start with AI and their engineering team?

If several of these questions are already on your desk, the order you tackle them in matters more than the answers to any single one. What tends to work:

1. Baseline your metrics before changing tools, structure or headcount. Without a before, there's no after.
2. Pilot with one team that has clear product boundaries. Give it a defined review process and an agreed AI ownership map, then run it for a full quarter.
3. Look hard at your core. Who actually has the judgment to review, make decisions and own a domain end to end? Count them.
4. Then revisit headcount, using the seniority mix your own data supports rather than the one in last year's plan.

The third step is the stage where most of the CTOs we speak with get stuck. They lack sufficient personnel with this kind of judgment - specifically, the highly skilled AI specialists who are driving the labour market recovery described by Indeed. This is also the most fiercely competitive segment of the market.

That's the gap we built "Elite Systems. Elite Teams." to close. We put together dedicated engineering teams of Elite Engineers from Bulgaria, vetted against what "elite" means to us, who join your standups, work in your codebase and share ownership of the system rather than just the backlog. If one of these seven questions is sitting with you right now, talk to us before it ends up on the board's agenda.