Blog Posts

Walk into any well-functioning engineering team today, and you’ll likely find something remarkable: they’ve solved the testing problem. After years of painful debugging sessions, missed deadlines due to technical debt, and production fires caused by undertested code, most mature teams have embraced Test-Driven Development not as a methodology, but as professional standard practice.

If you’ve been following my usual deep dives into AI, engineering, and process optimisation, you’ll notice something different about today’s piece. While I typically assume familiarity with technical concepts and tools, I’ve tried to provide extra detail and context for readers who might not be accustomed to command-line interfaces or agent-based workflows. The reason? We’re at an inflection point where AI agents are becoming genuinely transformative for professional work, and the most interesting applications often come from unexpected quarters.

“Refactor my data storage to use S3 instead of storing large items in NoSQL.” I fired this request at Claude whilst working on my stealth SaaS project, expecting the kind of comprehensive architectural guidance that had served me well in previous interactions. Instead, I got a confused response that mixed storage patterns, assumed requirements I hadn’t specified, and provided code that wouldn’t integrate with my existing CQRS architecture.

“How are you actually structuring your work when AI is doing half the thinking?” The question came from a software engineer with over thirty years of experience, someone whose career spans from assembly language to modern cloud architectures. We were discussing my recent transition from using OpenAI and Claude subscriptions to the use of API tokens for my development agents after months of intensive development on a stealth SaaS project.

Sarah stared at the quarterly metrics on her screen, feeling the familiar knot of confusion that had been growing for months. As CTO of a rapidly scaling fintech startup, she’d championed aggressive AI adoption across her engineering teams. Claude Code for development workflows, Cursor for intelligent editing, CodeRabbit for automated reviews: her developers were reporting 3x to 10x productivity gains in individual coding tasks. Yet somehow, their team velocity hadn’t budged. Features still took the same time to ship. Technical debt was accumulating faster than ever. Her most senior engineers were burning out trying to manage an explosion of AI-generated code that junior developers couldn’t properly evaluate.

Following my post last week about mentoring developers when AI writes half their code, an old acquaintance and exceptional leader, Meri Williams, reached out to share that they had just given a talk on the same topic at LDX3: “Rethinking growing engineers in the age of AI”. Having watched and enjoyed that talk, combined with several conversations I’ve had with other senior technologists this week, I spent a good deal of the weekend thinking more deeply about what the mentors themselves need to develop. These discussions and Meri’s insights have inspired the post that follows, though it takes a different direction from these initial conversations. If AI can accelerate code production but not wisdom, what does it truly mean to be senior? And how do we develop and exercise technical leadership when we’re individual contributors without formal authority?

The developer beside you types a brief prompt into GitHub Copilot and watches as perfect React components materialise on screen. Within minutes, they’ve built a feature that would have taken hours just two years ago. They submit their pull request with satisfaction, having delivered exactly what was requested. But here’s the uncomfortable question: are they actually becoming a better developer?

You’ve been coding for three years, but you still panic when Stack Overflow is down. Your AI coding assistant handles most debugging, but when it fails, you’re lost. The code you committed yesterday works, but you couldn’t explain how or why if your life depended on it. You’re not alone, and it’s not entirely your fault. Across the industry, organisations are making what appears to be a rational decision: hire junior engineers, add AI tools, and watch productivity soar. The simple mathematics seems compelling when you compare the annual cost of a junior engineer plus AI tools against a senior engineer with the same AI investment. This calculation is creating a generation of engineers with years of experience but minimal problem-solving depth. More critically, it’s building a false economy that will compound for years, creating operational fragility that only becomes apparent when systems fail at 2 AM.

In March 2024, Neil Hollis (@neilpaints on Instagram) stood on stage at Adepticon, holding the Golden Demon award for best single Warhammer 40,000 miniature. His Aeldari Exodite, a dinosaur-riding warrior crafted from converted parts, was undeniably stunning and absolutely deserved the win. The paint job was masterful, the conversion work inspired. Yet within hours, the miniature painting community erupted into fierce debate. The controversy wasn’t about his brushwork or colour choices. It was about the backdrop, a lush prehistoric landscape that Hollis had generated using AI.

The software engineering job market has entered an unprecedented state of paralysis. Senior engineers with decades of experience find themselves competing for junior roles, whilst companies post job advertisements that sit unfilled for months. Behind closed doors, engineering leaders whisper about AI replacing their teams, and CFOs question whether they need to hire engineers at all. This pattern is particularly evident across the UK and Australian markets, where I observe similar contractions in engineering hiring through my consulting work. The phenomenon extends to other developed economies including the United States and European markets, suggesting this isn’t merely a regional correction but a global strategic miscalculation driven by AI expectations.

This article presents a systematic approach to decision documentation that transforms how engineering teams maintain institutional knowledge and make decisions. You’ll learn how to implement pull request workflows for team decisions, create accessible documentation hubs for technical and non-technical stakeholders, and build sustainable processes that reduce repeated discussions whilst improving decision quality. The framework addresses the critical challenge of context erosion in engineering teams and provides practical templates and workflows you can implement immediately.

Engineering leaders face a unique cognitive burden: brilliant at generating solutions and spotting opportunities, yet often overwhelmed by their own creativity. This article explores how to apply engineering principles to idea management, transforming creative overflow from a source of stress into a systematic advantage. Learn practical frameworks for reliable idea capture, evaluation methods like RICE scoring and the Eisenhower Matrix, and how AI tools can enhance your thinking process. Discover how to build your “external brain” — a systematic approach to managing ideas that reduces mental overhead whilst ensuring your best concepts receive the attention they deserve.

Two engineering teams receive identical AI coding assistants on the same Tuesday morning. Both teams have similar technical expertise, face comparable project complexity, and work with equivalent resources. Six months later, Team A has transformed their development process. They ship features 40% faster, produce fewer bugs, and report significantly higher job satisfaction. Team B has barely engaged with their new AI tool. Productivity has stagnated, morale has declined, and several developers are actively job hunting.

There’s a peculiar ritual that plays out in technology companies across the globe every Monday morning. Engineering managers gather around their laptops, squinting at dashboards filled with red numbers from the weekend’s incidents. Product managers hover nearby, calculating the cost of delayed feature releases. Meanwhile, customer support teams brace themselves for another week of explaining why the platform “experienced some technical difficulties.”

We’ve all been there. You’re having a perfectly productive conversation with ChatGPT about your marketing strategy when suddenly you need to pop out for a coffee. When you return, you start a fresh chat and find yourself typing the same tedious preamble: “I’m the marketing director at a B2B SaaS company, we focus on mid-market clients, our tone is professional but approachable, we’ve got a £50k budget for Q2…”

Last week, I watched a junior developer use Claude to solve a distributed systems problem that would have sent me into an existential crisis just two years ago. The solution was elegant, well-documented, and production-ready. The developer understood every line of code, could explain the trade-offs, and knew exactly how to modify it for their specific use case.

At Wyrd Technology, we’ve lost count of how many times we’ve sat in client meetings listening to the same warnings: “Hybrid apps are slow.” “The user experience is terrible.” “You’ll never match native performance.” These concerns aren’t dishonest. They were entirely valid assessments of hybrid development circa 2015, when PhoneGap dominated and native bridges felt like digital duct tape. But here’s what we’ve witnessed over the past decade: whilst critics continue rehearsing these decade-old talking points, the hybrid development landscape has undergone a complete transformation. We’ve built hybrid applications that power demanding business workflows, financial platforms processing real-time data, and consumer applications serving millions of users. Instagram leverages React Native to share 85-99% of their codebase between iOS and Android. Bloomberg delivers financial data through hybrid architectures. These aren’t compromised solutions, they’re strategic advantages.

I’ve been experimenting with Claude 4 this week. It’s impressive: sharp, nuanced, and quite good at pulling meaning from dense technical writing. Naturally, I wanted to explore further, especially Claude Code. That is when I hit the wall. Despite paying for a Pro account, I found that access to Claude Code is not included. Instead, it sits behind a separate pay-as-you-go API billing model, with no practical way to trial it without committing to a credit card and a potentially unpredictable spend. That friction, minor as it seems, is enough to stall exploration.

In Part 1, we looked at the early stages of AI integration—add-on tools, search assistants, and rule-replacing prompt hacks. Now, we step into the deeper end of the pool. This is where AI stops sitting quietly on the side and starts calling your APIs. Where it moves from actions to them. Where agents take meetings, models adapt in real-time, and your architecture diagram starts to look like it was drawn by a sentient whiteboard marker.

You’ve probably seen the posts. “By the end of the year, 90% of all code will be written by AI.” “Software engineers will become prompt whisperers.” “We trained a GPT model on our Slack history and now it’s running product strategy.” It’s an exciting time to be in tech—if only because watching the hype train barrel down the tracks without brakes is strangely exhilarating. If you believe the internet, we’re just months away from replacing delivery teams with a well-tuned prompt and a generous OpenAI bill.

In the first two parts of this series, we explored how Agile metrics like story points and velocity—originally meant to support transparency and delivery—often become counterproductive. When used as performance measures or planning anchors, they distort behaviour, encourage estimation games, and shift the team’s focus from solving real problems to managing appearances. But once you’ve recognised that traditional metrics are part of the problem, the obvious next question is: what should we measure instead?

Agile promised to make software delivery more adaptive, more collaborative, and more focused on outcomes. But for many teams, the ceremonies and metrics intended to support those goals have become rigid rituals—followed because they’re expected, not because they work. Nowhere is this more evident than in Program Increment (PI) Planning. PI Planning is meant to foster alignment. It promises shared priorities, early risk identification, and structured planning at scale. But when it’s treated as a tool for certainty—rather than collaboration—it quickly turns into a high-stakes forecasting exercise. Teams are pulled into multi-day sessions, expected to estimate and commit to weeks of work in advance, even as the ground shifts beneath them.

Agile was supposed to be a game-changer. It promised speed, flexibility, and a laser focus on customer value. Teams worldwide embraced its principles, hoping to deliver better software faster. But somewhere along the way, many teams lost the plot. Instead of focusing on customer value, they began chasing numbers—velocity, story points, and burndown charts. Metrics meant to provide insights became the goal in themselves. Developers found themselves estimating endlessly, discussing the difference between a “3-point story” and a “5-point story” as if their careers depended on it.

At Wyrd Technology, we’ve always aimed to blend innovative software consultancy with thoughtful, deliberate solutions to complex technical challenges. As we’ve grown, our vision has become clearer: our identity should reflect the rich meaning behind our name—“Wyrd,” an ancient Norse and Saxon concept symbolising fate, interconnectedness, and the weaving together of past, present, and future.