Travel Advisory: 2026 as an engineering lead

Kia Ora, here’s the travel advisory for anyone looking back to 2026 and looking for a slice of what life was like as an engineering leader across a big org and a bootstrapped but well established product.

My position is unique in that I’ve had the pleasure of being across two organisations in 2026. First Education Perfect (EP), a 60ish person product and engineering team and a ~300 person org. Second, myWorksites (MWS) a b2g SAAS company with 10 people and bootstrapped within a services company of ~25. Both products are web applications. Each of these orgs are profitable, and have significant legacy systems to contend with.

On both orgs I have been a team leader with 3-4 people reporting to me, most recently I shifted from ‘engineering lead’ to ‘product & engineering lead’. I swapped over from EP to MWS June 2026.

The unique perspective I can bring is about the comparison of AI adoption and some of the challenges that appear to be universal across teams..

AI has brought me back to shipping production code

The IC <-> EM pendulum is something I have always vibed with, and I’ve timed my swing back to individual contributor focused roles around the acceleration of AI coding tools in 2024. If it wasn’t for the dramatic change in the job, I don’t know if I would have had the interest to stick around in a pure management role. Not that coding was boring, but for building web applications I felt like my biggest impact was to be running teams and growing peoples capability as individual contributors. Now with so many new skills to learn, it feels like an important time to have hands-on experience with AI. If and when I go back to a pure management position, it will help me build that team empathy and understanding of what the actual job requires.

The progression through tooling has been wild over the last two years. In 2024 I spent most of my time contributing within a tab completion or integrated chat environment like windsurf provides. Towards the end of 2024 I started experimenting with Claude Code, mostly staying in the inner loop and checking each change to keep the agent on the right path. By February I was deeply experimenting with Ralph loops, but not having much success. As of May 2026 I have been doing 95% of coding outside an IDE without a human in the loop. My time is spent talking with customers, testing, reviewing, design, grilling sessions and supporting my team.

Adoption friction is a thing

Even the most enabled large corporations will still run into policy which challenges AI adoption. EP would get access to new models within days, through the github copilot program and a google workspace subscription there was a reasonable breadth of models available to try and experiment with. Even though leadership would absolutely remove the blocks, there are just more steps to remove them in a larger org. Consider the impacts of ISO27001 and needing to change your risks and mitigations listed. In order to adopt a new practice like dropping explicit acceptance criteria and manual test recording, you must collaborate with the CISO the CTO, principle engineers and whoever happens to owns quality. If you’re unlucky this might end up at a board level decision and you are waiting a month or more to make a change.

Another challenge can just be in the IT process. At EP you can’t just run your own AI IDE of choice (windsurf at the time), because it gives you access to a wider set of models, and the security team needs to lock you down to just what is approved. Software that tracked subscriptions would snitch on you if you accidentally signed up for something shadow-it-ish. I get that risks exist, but the friction is real.

The best policy for adoption is one which is extremely open to tooling and models that people want to experiment with. Security sucks when you pick up this approach, I get the pain our security friends feel. It sucks. But we must take the balanced risk vs benefit approach. Security exists to enable us to take risks. Care a lot about the mitigations, but don’t worry about a perfect 0 risk solution, because you’re never getting there.

Education perfect was not running any official AI training targeted at developers. Much of it was focused on adoption across the rest of the org. Within the engineering and product group AI often overtook the regular guild meetings, slack channels about AI were quite popular and many of our engineering lead chats were about how teams could pick up their AI capabilities faster.

MadeCurious, the company wrapped around myWorksites, stopped all staff twice this year (with a third day planned) so far to train on AI through facilitated workshops by Joshua Vial, a trusted coach the team has held for 10+ years. This has definitely had an impact on the culture. People take it quite seriously when you stop them from doing their normal job for a couple days to learn how to use this new tool. When I started in June the adoption was pretty well embedded, 100% of people used claude code with non engineers actively pushing PR’s and features for user facing production releases.

What is true everywhere is that adoption is being forced from the top down and the uncomfortable truth is that this is not unanimously received as a good thing. I have seen more than one person burn out of the industry in the last 12 months as AI automates or completely changes their day job. There is much pressure on leaders to be an evangelist and meet new ambitious targets for velocity or quality as a result of having new AI tooling. Individual contributors are needing to broaden and change their skillset. It seems like deep focused coding work has gone by the wayside; although I think deep work and thinking is still very much part of the job.

We got pretty far but we are no dark factory yet

The dark factory is what people call a software development lifecycle that involves no humans and can run all day and night with no lights on. This is not where I am at yet, although I can see us converging on something like that in the future. There is a lot of the job that won’t change though. Engineers, designers and product outcome people will get together and collaborate on designs and what to build. But the actual building might happen 24x7 in the background with minimal human input.

In June, there were still people at education perfect that use copilot as a tab completion engine. I would say 75% of engineering was using Claude code. The most ‘pilled’ of engineers would be just as enabled as anywhere I imagine. Ralph Loops, Workflows, browser use all the skills etc. The overall way of working was only just beginning to change. At EP product and design was not pushing production code yet.

Comparatively at MWS a bootstrapped and established business, 100% of people at the org from founder through to designers are using claude code. Everyone has shipped production code on a complex regulatory system in the last month. Being a smaller org has its benefits here, but I would credit the progress on the dedicated training sessions and the leadership by example from the top levels. When everyone is vibe coding you feel like there is a lot of authority to do the same.

Our teams are far from leaders, but I think we are slightly ahead of the curve. The hype in the industry right now is insane though and all of the ““If you’re not doing X you’re NGMI” is ridiculous and overblown. The people selling hype on the internet almost always have something to gain from the angle they are selling; you just have to follow the money to understand what is going on.

The overall vibe in teams is one where you are constantly playing catch up. This is I think the first time in my career that everyone has felt like a beginner who is just exploring and experimenting and trying the next thing to see what works. As an example, we were heavily experimenting with beads but progressed on within a couple months because the harnesses and models improved to start doing a good enough job of documenting tasks and ticking them off.

Engineers are having a mixed experience

Although my experience sounds like it’s been smooth sailing, I would say the major challenge in 2026 has been in change management within dev teams. The work we are doing looks drastically different and this has proved to be a real challenge for people to adjust to. People have uncertainty that we can keep up with the acceleration in code generated. We ask ourselves, “Are we building ourselves into a corner?”. Every experienced developer shares this experience from being a newbie, they get these alarm bells ringing along with the accelerated pace of development.

Being an early adopter is not a sign of capability, everyone is dabbling. Managers who are not on the coal face should not bias how someone is performing purely on how much they are adopting the new tools. AI can increase the amount of work produced, but it tends to be a multiplier for the overall quality of work one was capable of anyway, not a fix-all solution.

The people who really seem to have figured AI out the most are the skill stackers. People who are just wading in and experimenting. Seeing someone experimenting in weird ways and failing is a sign that they will probably know more than you in a couple months time. Each model release also comes with a bit of adjustment to understand the capabilities so you need to have these set tasks to throw over to an AI to figure things out.

Many engineers are mourning the loss of code as a craft. This hits across all levels of engineering, and particularly it hits the people who have never stepped out of the IC coding role. Managers/Leads have already managed this change in identity and realized that you can still write code by hand for fun, or write code on the side to satisfy your curiosity.

There is still a huge amount of skill in not just the using of AI but also in the people and communication side of building something together. Although AI can produce a LOT of documentation, it’s barely fit for human consumption and most of the time you can say the same thing to your team in about 1/3rd the words if you summarize and write by hand. Writing english is the high leverage skill engineers should still be working on in 2026

AI just produces a ton of stuff and that’s overwhelming

This daunting realization that we are shipping so much has also come with a lot of slop-fear and maintainability pains. We constantly talk about it in the team. I would say we are 3 months from not reading a subset of PR’s. But reading code as a skill I think is still important, and I feel like pulling an engineer aside and reading some code together, expecting them to find their way around it is still mandatory.

Navigating this comprehension problem is also very interesting when it comes to non engineers contributing to the codebase. We now have a variety of people building on our product that never existed before, product people and account executives are wading right in. Our approach to this for mws is to assign a buddy engineer or two to make sure that we have some understanding of the architectural approach and ensure the quality bar is met.

With this increase in code being merged we have also seen a bottleneck in the PR process. In a team of 6 engineers + 3 product people writing code we see a stacking up of 20-30 PR’s in recent weeks. By the time your thing gets in front of someone for review you probably forgot how it works and can’t answer questions as you would hope. Things we have put in place to try and combat this are risk analysis skills, PR raising skills, stacking prs, smaller commits.

One of the side effects of AI producing a ton of stuff is you don’t get a good feeling for the level of human effort and understanding behind the artefact. You can end up wasting time reviewing something that is an explicit YOLO project. Our team introduced a label for this as a result. Yoloing is not a goal or anti-goal, there is a time and place for it and we lean into it for prototyping or proving out the shape of a refactor. This is something you would have to really argue about before, but I love that you can go to a refactor discussion with a working proof of concept to show your idea to people now.

The code bloat problem is equally met with a ‘documentation bloat’ problem. We share more AI generated artefacts and they feel like they have value at the time of generation. But it can be quite hard to discern exactly the intent by some of these documents. If the author has not fully reviewed them and shared it with you, it can really waste the reader's time. No different than the AI YOLO case above with code. Respecting the human time by being upfront with your level of self review of the doc first is a minimum requirement.

As our team ships more and engineers take on more responsibility outside of just writing code there are more skills to learn and more systems to be put in place to keep us on track. The systems we are focusing on building are things like permission frameworks / design systems / porting guidelines / risk analysis bots and feature verification agents.

Are we slipping into AI slop miasma?

Overall code quality is far greater than the legacy systems which already exist. Both EP and MWS own some legacy code. What profitable business doesn’t? As we have taken our hands off the writing of code, the amount of testing has increased. To be more concrete I have seen more tests be written and more thorough approaches to testing features pre-release in the last 12 months than ever before. Seemingly everyone is able to AI vibe a really solid senior engineers work out of an agent. Sometimes that direction is slightly off course and needs correction but I would say we are overall making a better quality product while going faster.

We tightened up a lot of our CI/CD process in the last year. Projects have stricter linting rules and static analysis checks than ever before. In August I built and re-built a major project 3 times with different combinations of skills on the harness to try and come to a better 20k PR stack to merge. This was a worthwhile effort as it only added a couple days effort and burnt through several peoples claude tokens for the week.

Fear of slop is high in teams. Fear of losing skills, not gaining the skills they thought they would be. People genuinely enjoyed writing out boilerplate code and solving problems by hand and they no longer get paid to do that. It’s a real concern for many people still and this was something I have seen everywhere I’ve worked and has come up in all the discussions I have had with peers.

The less your team knows about the tech, the faster you go – and I’m yet to run into slop which has slowed us down. On two occasions I have worked with teams who are less strong at building UI/UX. Our largest overall velocity increase has come in that frontend work. Especially when it comes to the boilerplate, stuff that has already been done elsewhere but is 10% different. That stuff can ship extremely quickly. Are we experiencing a bit of gate keeping when it comes to proving our knowledge as engineers is still important? Or are we 6 months out of catastrophic technical debt realisations..

More people are shipping and engineers still end up owning it

Working with Product has changed. My buddies in product can just do way more and I LOVE it. I love that we can give a PM access to a data warehouse and they can come back with a PRD + queries for the metrics which support a feature, metrics for how we can track adoption and get a first signal. At EP I was fortunate to have a PM, who would go really deep on the complex data model. We would collaborate in claude code with the repo, developing queries to test theories about the system and business viability of certain solutions. Her work REALLY enabled the team to understand the problem from the businesses perspective as a theory could be accompanied by a real query that backed it up and could be argued about.

People writing code is not absolutely accepted and appreciated though. I’ve seen a proliferation of build your own internal tools that have been received with disdain from engineering. People fear supporting work they didn’t create or approve of. Things like browser extensions which are super useful but no one knows how to support that. Custom CRM’s. Vibe Coded ports of legacy systems. They can result in a 20k LOC project landing on a team with little context, the team then needs to sign it off for security and support it forever. Show me a developer that would be stoked with that role!

Another example of the product role transforming is that PRD’s are not all you get anymore. Great Product people are building features and prototypes, taking them to customers then coming back to the team with a couple thousand lines of code in the product which shows the idea they are hoping to experiment with.

A pattern I have seen when it comes to product builders and engineering working together is that more collaboration is required and there is a significant need for engineering to follow and clean up as sub-optimal ux or architecture is shipped in order to prove a product feature or concept.

Autonomous product teams are still working great

Ways of working have not changed as much as I would have thought. Empowered product teams and a lot of authority for senior engineers to break down work is still the best. For 6+ years I have sought out teams that work this way, so I can’t compare to what a classic SCRUM team looks like in 2026, but I can only imagine that they are not seeing the acceleration that an empowered product team can get. The more you distribute capability for product decision making the faster you can go and the more likely you are to realize the benefit of AI tooling which helps drastically reduce the time to build.

The job is thinking, and that’s fundamentally still what we are doing

Building software is still thought work, even if the writing code part is now 90% automated. As a leader I expect my team to still be able to stand up and explain the decisions and architecture and options which they went through to land on a particular solution. Simply generating a solution does not mean you have done the thinking. We are being paid to do the thinking and build the long term context over years.

I’m having more fun building software now than I have in years. I also don’t know exactly where we are going with this acceleration in delivery, and how badly we might regret all our building in 2026. Both of these statements are true and that is just being real about the uncertainty we are facing right now in the industry. We are learning as we go, some of our decisions right now will cost us.

There is plenty of work to be done as a leader. Help build the skills your team needs to move outside pure engineering and hand writing code work. Make room to let them test and explore the new skillset that is needed. Focus the team on building a codebase and platform that is ready for non engineers to make significant product features.

Shipping faster does not mean thinking less. We still get permission to take time to think through a problem and figure out the best solution .