It’s 2026! Why aren't you 10x vibe coding?

2025, What a year! Though the last few have been a run; Post Covid, the software development world shifted and shifted again.

Remote shifted back to hybrid and in-office models. Changes in the cost of debt forced start-ups and scale-ups to refocus on revenue before growth. "Do more with less" became a mantra even before LLMs appeared. Engineer salaries stagnated and often fell, with layoffs occurring as frequently as we used to ship new software. In the post-agile era, modern software engineering faces the threat of being overtaken by vibe coding and LLM agents.

Predictions of large skills gaps in IT and software engineering remain, but it doesn’t feel like it on the ground. Career progress and growth occurs within jobs rather than through job changes. However, that's the least of our challenges: organisations and work methodologies are shifting bigly.

How can we best operate? Do we roll with the punches? Could we bottle this chaos and find great new ways to work? I believe these shifts create space for great work, but we will need to chart new paths to reach great outcomes.

What's a staff engineer anyway?

The role of staff-plus engineers is relatively new and remains ill-defined. With all this change, that's both a blessing and a curse. Anxiety, frustration, or disappointment can arise when new or shifting expectations surprise us. But with an awareness of the conditions in hand, we can acknowledge the situation, and switch modes. Taking notes from Cynefin, we might do well to operate by sensing, reacting and bringing what's needed, rather than working to what was needed last month and last year.

What might that mean for how we do our jobs?

Paper Planes, Not Jet Schematics

In 2025, I discovered that my work as a staff engineer was most successful when executed in shorter cycles. Unsurprisingly, a key lesson from Agile that I need to apply to my staff work. My long-term thinking often became irrelevant before usefulness due to shifting needs and priorities. If a task wasn't actively progressing and nearing completion, it was as if it didn't exist.

I needed to be more nimble, finding new collaboration points and quick paths to success, rapidly turning around results or new data. However, juggling too many tasks also diluted focus and slowed progress.

In 2026, my work needs to intersect with the organisation more frequently, delivering valuable outcomes in the shortest cycles possible. Although this approach may seem non-optimal, it ensures that results speak for themselves and can secure approval and focus for subsequent steps.

That doesn’t mean I can’t have agendas and pursuits, but they need to be mission-critical and action-oriented, or relegated to side hustles that can be called on when useful.

Let 'better' set the direction of travel for your teams.

Traditional strategy and planning often turns into multi-year plans and roadmaps. Doing that now can risk generating much waste and sorrow, leaving you high and dry when the flow shifts.

We need to use strategy to set agendas and direction, guiding us forward rather than relying on longer-term goals, plans, and expectations.

I think the teams I support will massively benefit from knowing what they are there for, and which direction 'better' product, system and architecture are in. It will help them strip the noise from the key messages that they can then use to keep focus on driving forwards. Teams need to know where they’re going, and instead of following a fixed plan, I want to equip them with tools to positively adapt to change.

This may be working with the team, building a dynamic strategy towards 'better'. It may also involve collaborations with other senior leaders to ensure that the team can get clarity of brief that will result in good software, long term. Either way, the way to build something coherent and maintainable will need my support.

Team ownership challenge accepted.

Through vibe coding, LLM saddling, or revenue-before-scale re-orientation, doing more with what we have means many teams will end up owning and operating broader sets of work. And this might well include large chunks of valuable but unpolished functionality. In 2026, there is a predicted increased demand for on staff augmentation, along with the complexities of onboarding, offboarding, and ownership that will accompany it.

For a staff engineer, this means we need to imagine, and help others realise, good management of broader portfolios. And methods to manage a portfolio that might contain a mix of legacy, imperfect and experimental work.

How can I help teams not get swamped? By finding better ways of owning and operating. I'm expecting to be spending time with teams and tech leads, finding ways to own more, and still getting things done. Toil, incidents, bugs and customer issues will need to be managed differently - can we look to better communication, automation and use LLMs to manage toil? Will a focus on self healing (not just reporting of faults) and self-informing systems provide to both the team, org and our customers? Can we add this into what we own, and build new systems with this in mind?

Architectures-of-the-future still need to be built.

We will need to build architectures that meet future needs which are hard to foresee, and do so incrementally as we scan ahead and deliver in small cycles. Post-microservice architectures that both have a strong event orientation, and high-level business domain focus are likely to be ones that allow good combinations of scale, evolutional building and Agentic operation.

It's a bet worth placing, but how do we get there with the above challenges is going to be a big mission and maybe a key driver for 2026: understanding that we need future architecture that can be built in pieces and be successful on the way is probably the most interesting and valuable problem that presents itself.

We need to try new things, but we need to talk first.

Staff engineers bring experience, practice and ways of getting stuff done, but we don't scale. In the midst of this change and challenge are all those ace engineers you are there to support and help do great things. My aim will be to help others navigate, and build great things.

In 2026 I want to have more chats, and be in less meetings. In the distributed world I live in I can't rely on a coffee room or corridor chat. These can't be typical mentor chats - these need to be 2 way streets - I need both information to steer what I prioritise and I need to assist and support the problems folk need to solve.

Change is inevitable, but suffering is not. We can be the glue that holds things together, but this glue needs information to cure. I think chats could be the 2 way street to do this. Dear reader, do you have other suggestions?

Conclusions: Throwing shapes

If you see the same patterns in 2025, here is what i plan to do to find success in 2026

1. Reduce Cycle Time and Thoughts in Progress: Focus on minimising cycle time and the number of tasks in progress. This approach allows for quicker iterations and more immediate feedback, enabling you to adapt swiftly to changes and deliver results efficiently.

2. Set Teams Up to Ride the Waves: Collaborate with your teams to clearly define their mission and set navigation buoys as guides forward. This clarity will help teams stay focused on their objectives and adapt to changes without losing sight of their goals.

3. Equip teams to handle a Broad Operational Portfolio. Point them toward building low to no maintenance products, ensure useful documentation and information flows happen, to reduce distraction and toil.

4. Iterative, Evolutionary Suiting Architecture: Emphasize the importance of developing architectures that are adaptable and can evolve over time. This approach allows teams to react to unforeseen challenges and opportunities, ensuring that systems remain relevant and effective as needs change.

5. Talk More: Encourage regular, meaningful conversations that go beyond formal meetings to share insights, address challenges, and support each other's growth. This will help build a cohesive and resilient team environment.

Cover photo by Hans-Peter Gauster on Unsplash