The State of AI & Engineering in 2026

It feels like we’re living in dog years.

So much change, all at once. Opinions are divided on what it means for the way we work but what’s clear is that we’re living in a once-in-a-career moment.

At Lookahead, we wanted to make something useful for the community as we made sense of the changes ourselves. Putting this together helped us learn, we hope you learn something too.

We started by interviewing a few dozen leaders in Australia and the US. Some aren’t named because of who their employer is, but they’re at the frontier and have helped us a lot. We then went to the wider community via our survey. This report exists because people were generous with their time and honest about their experiences, so we’re making it openly available in that same spirit.

Thanks for telling us how you’re feeling. We’re both energised and tired after what has already been a big year. We’re long term optimistic and feel motivated to run hard for a bit. It’s nice to know we’re not alone.

Steve Gilles
Founder, Lookahead

AI isn't just evolving; it's sprinting - at a velocity unseen in any past shift. It’s fun to realise the Stack Overflow’s 2025 Developer Survey is now woefully out of date as it closed in June 2025, before Opus 4.5. Still, back then 84% of developers were already weaving AI into their daily workflow. 2026’s survey will be closer to 100% and “weaving” will be an understatement.

Creating quickly feels amazing, yet beneath the surface, it’s fuelling a new breed of fatigue and pressure that we are only just beginning to grasp.

80% of respondents told us AI's impact on their role over the past year was positive, and 39% were very positive. Only 7% were outright negative.

Only four respondents in 271 chose "very negative".

For senior leadership, the primary observation is the speed of change.

There are also those who are feeling incredibly energised and empowered by the changes afoot.

Some who have ‘seen this before’ are less impressed

Some people felt like they have watched this unfold before; cloud, mobile, Web 2.0 etc and that each wave felt existential when inside it. The pattern they recognise is: a platform shift arrives, everyone re-tools, the roles reshuffle, and five years later it's just how software gets built.

So who is feeling optimistic?

It might be easy to assume that the temptation of increased output makes managers and executives the enthusiasts and individual contributors sceptics but the data shows company size matters most.

The same gradient shows up on a combined index of seven separate questions, so this isn't one question behaving oddly. With the full sample in, this finding now clears our strictest statistical bar.

This is not to say that seniority does not have an effect. C-suite respondents averaged 4.58 against 3.91 for individual contributors - but when we tested tenure, seniority and company size in the same model, company size mattered far more. Those in a sub ten-person company predicted a far more positive impact of AI than those in larger companies. In the combined model, company size carried the most weight (β −0.20, p=0.001); a seniority effect held on (β +0.17, p=0.008), and tenure added nothing once both were in.

There is a caveat that this raises. Are people who are bullish about AI also more likely to join smaller fast-moving companies? Research suggests self-selection of this kind is real: a Management Science study of first-time employment choices (Roach & Sauermann) found people who prefer startup work show measurably higher risk tolerance, stronger preference for autonomy and greater interest in new technology than peers who prefer established firms - so some of the gradient in Exhibit 3.2 is likely people sorting themselves, not company size doing the work.

The words people chose

At the end of the survey we asked an optional question: in one word, how has AI made you feel about your work? 186 people answered, and the answers do not mirror our headline 80% positive result.

excited the most common single answer, from 11 people

empowered 8 · the late responses pushed it off the top spot

exhausted 5 · followed by tired, 4 · optimistic also 5

stressed 3 · alongside anxious, 4, and hectic, rushed, scared and cautious, 2 each

Somewhat alarmingly, when we do some basic semantic analysis of the words used, the world is not all that rosy.

Borderline words move the split by only a point or two whichever way they're classified. The late responses skewed positive - the mid-survey data was a dead heat - but the gap between asking for a rating (80% positive) and asking for a feeling (43% positive) remains the point.

The last 12 months have clearly been a year that most people found beneficial but at the same time found exhausting.

Read: The first four lines are what everyone expected. The last one isn't - 45% report code quality decreasing against 33% reporting it improving.

Boilerplate code all decreased for 84% of respondents. What didn't is the work that was always hard: architecture, edge cases, and verifying correctness.

In our interviews the benefits were stark at times; one organisation measured three times the output per engineer per week. Another delivered a project scoped at two weeks in three days and a six-month project in two months. One engineering leader described diagnosing an incident in seven minutes that would previously have taken four hours.

Ok but what does going faster mean?

When we asked people to name the single biggest benefit, speed came first - but the other answers underneath it describe something more specific than going faster.

Speed, freed-up time and less grunt work account for 69% of answers between them.

For many leaders speed is not the only benefit. For Pierre and Dave there is now an opportunity to place more bets on more things:

Another benefit mentioned repeatedly is that the barrier to entering an unfamiliar stack or domain has disappeared. Someone with no Android experience can now be productive in Android; that wall has largely vanished.

Does speed mean better?

Almost nobody is finding an increase in quality as a result of AI. We think that might change.

This indicates a classic bottleneck shift: speed without proportional review capacity transfers technical debt downstream. While commits are faster, defects are simply reaching production sooner.

The industry's most rigorous measurement effort found the same shape.

As shipping becomes cheaper and faster, the question of responsibility and accountability rises. Who does the work? What does ‘doing the work mean’? And what happens when things break? These emerging questions are pulling engineering teams in competing directions.

Leaders are closer to the tools

A year ago, senior leaders prided themselves on being hands-off. Today, many are back on the tools. Whether for fluency, prototyping or setting specifications. Practicing leadership has returned as a requirement for the role.

Note what Paul is describing: leaders practicing again - closer to the tools for fluency, prototypes and specs. Whether that extends to committing production code is a separate question, and it's where disagreement amongst leaders begins to emerge.

Of the 137 respondents who lead a team, 51% told us they've become more hands-on since adopting AI tools and 24% less. The extent is the interesting part: almost half of that 51% didn't pick "somewhat more". A full 23% of engineering leaders picked much more - almost as many as reported no change at all.

Almost as many leaders picked the strongest possible increase as picked no change at all.

So what does "being on the tools" actually mean? For some like Paul it means leading from the front. However some leaders offer a counter perspective to this.

For Wendy it is critical that whoever is writing production code retains responsibility and accountability for that code.

Alex North shared a similar view pointing to the practicalities of the situation: if code is cheap now, then having the most expensive person in the building producing it is a poor use of money and time.

Ray Tung, VP of Engineering at Kasada, had a slightly different concern. A senior leader who picks up real delivery work becomes a potential bottleneck because now critical time bound delivery is expected of the person with the least available time in the organisation. Routine, non-critical work is best delegated to junior engineers for skill development, but when delegation isn't possible, picking up these tasks yourself helps clear blockers and keep momentum going.

For Ciaran Hale, CTO at Deputy, being close to the work is less about personally producing every output and more about retaining the judgement to assess its quality. AI can make it easier to create something that looks convincing, but leaders still need enough context to distinguish a useful result from one that creates more work downstream.

For Chaitanya Kuber questions how much of this is happening inside companies at all.

Mic Neale at Block has seen this first hand:

Are we all builders now?

One of the most consequential things that happened this year is that non-engineers found out they can build. Not just spec it or wireframe it: build it. That has created friction but it has also broken down a barrier that sat between engineers and everyone else for decades. A working prototype turns out to be a far better way to communicate an idea than a document describing one.

Literally zero respondents told us they were seeing no cross-role movement. Non-engineers are shipping working prototypes as functional pull requests. Production ownership though remains squarely with Engineering for now but this might be up for debate.

Engineering picks up work from its neighbours more often than it hands work back.

James Brett gave us some insight into where things could be heading:

Role boundaries are blurring, but ownership is not. While non-engineers can now generate functional prototypes, many in the industry remains firm on where accountability for production lies.

Carl Woodward, CTO at Ordermentum, watched this boundary resolve by itself. His product managers leaned into writing code, then pulled back once it dawned on them that shipping meant being on call. Ciaran Hale sees AI as expanding what product managers and designers can explore independently, particularly for early concepts and small improvements. But he is clear that this should not remove engineering judgement from more complex work, where requirements, architecture and long-term maintenance still matter. Vanessa Ung from Lorikeet questioned if a product built by generalists still works in three years.

Of the 22 leaders we interviewed, only one expects this blurring to reverse.

What about design?

Pierre Bergamin (CTO at InDebted) runs an engineering organisation with no UX or UI designers at all. The function was not downsized but it was removed completely. Paul Keen (VP Eng at Culture Amp) went the other way entirely and leaned hard into design: "we're finding designers have been the biggest unlock with AI tools. We found that they can pick up prototypes, they actually write pretty good code." John Allsopp would go further still: hire more designers, because engineering has stopped being the constraint.

Despite Paul and John’s optimism our survey is pointing to the design function to be at risk (see caveat below).

Engineering and product are both named as growing more often than shrinking. Design runs the other way.

One caveat before you read too much into that. 233 of our 272 respondents work in engineering. Eleven are product managers. Fourteen are designers. Exhibit 5.3 tells you what engineers believe is happening to design, which is not the same as what designers are experiencing. We can't tell you the second, and we won't pretend otherwise.

As AI makes code faster and cheaper to produce, engineers bring more value through deciding what to build, how it should work and whether it’s reliable. System design is becoming more important, but opinions on code review are divided: does it now demand more human judgement, or will AI take on that work too? There’s also an unresolved question about how junior engineers will gain the experience to become senior engineers.

System design and product thinking matter more

We asked respondents to select up to three skills that had grown most in importance, and up to three that were becoming less important. System design led the gains at 56%, closely followed by product thinking at 53%.

Read: Where a skill has a long bar on one side and a short bar on the other, the profession agrees. Where both bars are long, it doesn't.

Code review appears near the top of both lists. So does prompt engineering. At first glance this seems odd but we feel it represents two groups that are emerging. Each of these groups have reached opposite conclusions about the same job. One group believes that review is where human judgement is needed: the model produces ‘the work’, the engineer decides and deciding is now ‘the work’. The other group believes that review itself is being automated — agents checking agents — and that prompt craft is a transitional skill, disappearing as models stop needing to be coaxed. The industry will undoubtedly shift one way, and our guess is the latter.

This begs the question, has our definition of what makes a great engineer changed at all? For our interviewees the response was mixed.

James Brett, however, suggests that the evolving nature of engineering work might leave some developers at a disadvantage.

One point of near-total agreement amongst those we interviewed: refusing to use AI is now disqualifying. Some described engineers not using AI as ridiculous, comparing it to refusing an IDE out of stubbornness or pride.

What about juniors?

This was the single most-raised topic. 17 of our 22 interviews brought it up unprompted but only 14% of respondents named erosion of junior skill development as the most significant downside of AI. The routine tasks juniors used to cut their teeth on are now below what a model does unsupervised. As a result, the entry-level work is disappearing. The traditional pathway from graduate to senior which ran for years no longer has an obvious first step. Nobody is disputing this change.

From there the interviews divide. The pessimists worry that the on-ramp has gone and no replacement is in sight. James Brett went furthest, telling us he used to worry about the talent pool and no longer does — because he doesn't think the industry needs one coming in. Paul Keen's version is personal: his son is studying computer science, and he expects him to graduate and never write a line of production code.

The optimists though have a counter argument.

Early labour-market data gives weight to concerns about entry-level jobs. Stanford’s Digital Economy Lab has been analysing US payroll data from ADP. Its August 2026 update found that employment among 22–25-year-olds in occupations highly exposed to AI was roughly 19% below where it would have been had it kept pace with peers in less-exposed occupations. That gap had widened from 15% a year earlier. Experienced workers showed no comparable gap.

The declines were concentrated in occupations where AI automates tasks rather than helps people do them, and appeared to reflect reduced hiring rather than increased job losses. That echoes what our interviewees describe: fewer opportunities to get started. But the researchers stress that these patterns do not prove AI caused the decline. We read them in the same spirit: an early warning, not a verdict.

This debate will not be settled in this report. The median respondent to our survey has 17 years in the industry, and 50% lead a team. Every account of the junior experience in this report is a seasoned person's account of it. That is worth noting.

Engineering gets a budget line?

Token spend arrived as a management question this year, and the survey suggests most teams are still working out what to do about it. The modal budget is $150–$500 per engineer per month, and 14% run uncapped but measured.

Small companies spend more per head than large ones: 46% of respondents at 1–10 person companies are in the $150–500 band, against 12% at companies over 1,000.

For most of the leaders we interviewed, token budgets are a distraction and fundamentally the wrong management lever. Access to frontier AI models is now as essential as providing an engineer with a laptop; you don't ration the CPU cycles used for a build, and you shouldn't ration the tokens used for a solution. This represents a paradigm shift where the goal is thriving, not rationing. Instead of policing invoices, effective leaders are focusing on fostering a culture of continuous learning to ensure their teams stay relevant.

For Tim, framing AI as a budget line misses the point: it is a tool that expands what is possible, and we are only just beginning to map those new frontiers. If a leader finds themselves cutting AI budgets to save on costs, they have likely built the wrong culture. In this new reality, heavy token usage is not a cost to be managed, but a proxy for engagement and the necessary price of technical survival.

Between those two sits a governance camp running real instrumentation — quotas with peer-visible usage, prompt-quality and session-length metrics, hard subscription caps with no top-ups. Others are still reaching for the right unit of measurement altogether.

Underneath all of it sits a shared warning that has nothing to do with budgets.

One thing several interviewees converged on independently, and it matters more than the budget itself.

Wendy Glasgow reaches the same conclusion from the opposite direction: a well-written prompt uses fewer tokens, so heavy usage can signal weak craft rather than strong output. Vanessa also cautions around the future cost of tokens. She says it will ultimately depend on your organisation and whether your core value proposition revolves around using AI.

Clears the strictest statistical bar in the manager-vs-IC family.

Nearly two in three organisations have changed how they interview, and the parts they changed are the parts that tested whether someone could write code. Underneath that, the market itself has tightened in a way that our respondents describe very differently depending on where they sit — and the people closest to the work are the ones still defending the coding test.

The interview loop got taken apart

60% told us their interview process has changed because of AI, with 24% describing the change as significant. When we asked which parts, the answer was unambiguous.

Values interviews and reference checks were largely left alone.

The dominant new pattern in our interviews is a practical exercise where AI is not merely allowed but expected, and the candidate is judged on how they frame the problem and critique what the model produced.

Several organisations described versions of the same thing: an hour with an unfamiliar codebase and your own tooling, where what's assessed is navigation and judgement rather than the finished solution. Paul Keen's team now lets candidates use an agent on the coding test and then asks them to explain what it wrote and why.

A significant camp has gone further and abolished coding tests outright.

And a stubborn minority has gone hard the other way - not out of nostalgia, but on a specific bet: that AI-assisted loops can be gamed, and that watching someone think, unassisted and in the room, is now the scarcer signal.

Others keep them for specific roles rather than abandoning them wholesale.

Our respondents are split almost exactly down the middle on whether coding tests remain relevant - 58% say yes, 42% say no. What's more interesting is who says what.

The people who run hiring loops day to day are the most convinced they still work.

Who is actually hiring

Among the engineering leaders in our sample, the hiring market looks tight. Only 4% are hiring more engineers. A quarter are hiring fewer, and almost as many are holding headcount flat while restructuring what the roles are.

Software engineering is still the hardest role to hire for, named by 34%, with engineering leadership second at 28% and AI engineering third at 27%.

The seniority split on this question is one of the largest effects anywhere in our data. 36% of C-suite respondents are hiring fewer engineers, against 12% of managers. Managers, in other words, mostly do not yet know.

What people are getting wrong in hiring came up repeatedly, and the most common answer was about role definition rather than candidate quality.

Where our interviewees do agree is on what to look for instead. The word that came up most was shipping.

This push for visible output creates a new hiring heuristic that is a fundamental misinterpretation of the shift. The trap for hirers is viewing AI as a reason to replace seasoned expertise with 'AI natives' or using it as a justification to reduce headcount based on raw speed. Instead, AI is a tool for learning and maintaining relevance. Don’t ignore the reality that seasoned judgement remains the primary requirement for using these tools effectively.

What people are paid

The compensation picture is flatter than the productivity numbers would suggest. 57% of respondents told us their total package stayed the same over the past year. 22% saw an increase, 6% a decrease, and 15% preferred not to say.

Where packages did move, they moved meaningfully: a median increase of $20,000, with a mean of $26,889 and a range running from −$30,000 to +$168,000. Increases were concentrated at larger companies: 40% of respondents at 201–1,000-person companies saw a rise, against 14% at companies of 1–10.

Separately, we asked engineering leaders what is happening to the premium their company will pay for exceptional engineers. Not one respondent said it was falling significantly. 37% said it is rising; 56% said no change.

57% said their total package stayed the same

+$20k median change among the 62 people whose pay moved

0% of engineering leaders say the premium for exceptional engineers is falling significantly

Advice for people looking for work

Drawn from what our interviewees said they actually respond to.

• Ship something, then show it. The single most common answer we got. Manik Surtani would rather see one small thing you actually built than a CV. Paul Keen wants a green-lit GitHub. James Brett sets the ceiling — five to ten shipped products and a real conversation about model trade-offs.
• Spend real money on frontier tools. Treat it as a retraining cost, not a subscription. John Allsopp put it best: "if you haven't been working for six months it might be an ask to spend $150 a month on tokens, but think of it like this: it's like five bucks a day, that's a cup of coffee a day. If you can find that money, develop those capabilities… build something, and be ambitious, right? You'd be astonished by what you can build."
• Bring an opinion, not a feature list. "Tried Cursor, Claude Code and Codex: here's why I landed where I did" is the new interview currency. Wendy Glasgow told us it's the exact thing she listens for.
• Treat a gap as a reset, not a liability. Gareth Stokes doesn't care if you've been out six months. Tim Lucas is blunter: most of what mattered six months ago isn't relevant now anyway, so the field restarts more often than it used to — use the time to restart ahead of it.

Advice for people hiring

• Define the first ninety days before you write the job ad. The most common complaint we heard was undefined AI roles, not weak candidates - if your ninety-day description reads like a solutions architect, hire one of those instead.
• Test the job as it actually exists. Interviewing without the tools people use daily is, as Oz Nova put it, a misrepresentation of the work. Judge problem framing and critique of the output, not typing.
• Screen out the age shortcut. Assuming younger candidates are AI-native by default is a bias, not a strategy - Oz Nova was emphatic that it's simply wrong.
• Recalibrate your gut on purpose. Dave Slutzkin's point: the person best suited to how development now works may not look like what you pictured, and gut feel was trained on the old job.

Public debate about AI often centres on job losses. Our respondents were more concerned about becoming too dependent on AI and losing their skills. 35% chose over-reliance and skill atrophy as AI’s most significant downside, making it the most common answer by a wide margin. Just 10% chose job security, one of the least-selected responses.

Only 2% of respondents told us there is no significant downside at all.

Early research gives us reasons to take concerns about over-reliance seriously. In an MIT Media Lab experiment, 54 participants wrote essays using an LLM, a search engine or no tools. The LLM group showed the weakest brain connectivity measured by EEG and struggled to quote their own writing. The authors describe the potential cost of this reliance as “cognitive debt”. It’s a small preprint study of essay writing, so we should be cautious about applying its findings to engineering.

Closer to the workplace, Microsoft Research and Carnegie Mellon surveyed 319 knowledge workers about 936 examples of AI use. Greater confidence in AI was associated with less reported critical thinking. The study measured people’s perceptions of their effort, rather than testing whether their skills had declined. Read the study.

Neither study proves that AI causes lasting skill loss. Both raise questions that echo the concern expressed by 35% of our respondents: are we losing practice in the skills we still need?

The workload paradox

Here is the pairing that defines the year. Shipping got faster for 92% of people. Workload and pressure went up for 68%. And job satisfaction is the most divided question in the entire survey.

The mechanism our interviewees describe is cognitive, not organisational. The job used to reward hours of uninterrupted single-task flow. It now rewards supervising several parallel streams of machine output - checking, redirecting, context-switching - which is a different kind of tiring, and it taxes exactly the people who were best at the old mode.

More people said satisfaction decreased a lot (17%) than said it increased a lot (13%).

Respondents with 15 or more years in the industry report higher job satisfaction than those with less.

Honesty note: this pattern is graded as a Strong signal (q=0.069), a clear pattern rather than a proven fact. Workload runs the other way - newer engineers report higher workload and pressure - with the same grade (q=0.098).

What our survey missed

Three things came up across our interviews that we didn't specifically deal with in our survey but felt were important call outs.

The emotional cost of the transition. Around thirteen of our twenty-two interviews touched on it unprompted. This deserves to be called out.

Dave Slutzkin offered the most concrete version of why this lands unevenly: the job's cognitive profile has shifted from long uninterrupted flow to supervising six things at once, which disadvantages those who honed their craft through focus.

Everyone we spoke to loves the speed of prototyping. However many raised the question of what happens next?

Security specifically was raised by respondents as something we should have asked about and didn't. So was the gap between AI ambition and AI strategy.

Sitting under that strategy gap is a risk category that velocity metrics simply don't see: code shipping faster than anyone can security-review it, AI tooling adopted ahead of any policy on what data it touches, and agents operating with credentials nobody has audited. Our survey didn't ask, our respondents told us it should have, and we agree.

The environmental and social cost. Two interviewees raised it independently, and several survey respondents wrote it into their free-text answers.

Ciaran Hale also emphasised the need to be deliberate about where AI is used. The technology carries real infrastructure and energy costs, so the goal should not be more AI-generated output for its own sake, but better outcomes where the value clearly justifies the resource involved.

System design interviews have often felt like theatre: a performance that reveals little about how someone would design a real system. The frustration was with the interview, not the value of the skill.

Now, system design tops the list of skills our respondents say have grown in importance. As AI makes code easier to produce, deciding how the pieces fit together matters more. That renewed emphasis on design and judgement is one of our most encouraging findings in this report.

Read: Positive bars are skills the profession agrees have gained. AI/ML fundamentals fell furthest on net, with testing and validation close behind - the second of those is worth worrying about given how much more code is being produced.

The interviews get at why. When generating code stops being the constraint, the constraint moves to knowing what should be built, how it should be built and future implications of what was built. Unsurprisingly Product thinking (+48 net) and system design (+38) sit as clear skills that are rising in importance. In many ways this is not new but what it reflects is how people are spending their time and the blurring of lines between the once segregated role types.

One of our interviewees inverted a piece of advice the industry has given for two decades. The conventional wisdom was to go deep on one stack. Carl Woodward's argument is that libraries and frameworks become more important rather than less, because a well-designed library gives a model better material to work with - and that going wide now beats going deep.

A related observation came up several times: the collapse of stack specificity. Respondents told us the skills that really declined weren't on our list at all — they named coding itself, and knowledge of particular frameworks. If a model can pick up any stack in an afternoon, being the person who knows Rails deeply is worth less than being the person who knows what to build.

Is the forward-deployed engineer just a presales architect?

Several interviewees made the same observation about role titles from different angles. The forward-deployed engineer, on this reading, is a solutions architect or a sales engineer with a better name, and the pattern is a recurring one rather than a new one.

That doesn't make the role fake. It makes it old. And an old role coming back under a new name is exactly what this section is about.