But speed isn’t everything. These tools still need guidance, context, and careful oversight.

In this article, Birgitta Böckeler (Distinguished Engineer, Thoughtworks) shares practical strategies for using AI responsibly, helping developers harness its power without sacrificing quality or maintainability.

Clean code makes AI shine

In their early days, tools like GitHub Copilot mostly acted as advanced autocomplete assistants, predicting the next few lines of code. Today, AI has leveled up to agents that can tackle multi-step tasks – refactoring files, running tests, or even updating entire repositories.

AI agents can now fix failing tests, optimize dependencies, and even propose small architecture tweaks. Still, as Birgitta points out, these time-saving powers come with their own set of headaches:

Developers now need to give clearer context, define their goals more precisely, and double-check AI outputs with extra care.

Because these systems lack persistent memory, developers keep session notes or hand-offs to track project state. Birgitta Böckeler notes that AI assistants work best in modular, well-structured codebases where context and dependencies are clear.

In contrast, legacy or entangled systems often cause the AI to misinterpret relationships or overlook hidden dependencies. As a result, productivity improvements depend heavily on the specific context in which they are implemented.

Claims of 80% faster development rarely hold. AI speeds up small tasks, but big architecture, integrations, and testing still need human expertise.

AI can produce code fast, but it needs human oversight

Böckeler also addressed the growing gap between the hype surrounding AI and what it can actually do.

Many online demonstrations show AI building games or applications in mere minutes, but these impressive-looking outputs often exaggerate reality. In most cases, they produce only basic scaffolding or boilerplate code rather than fully functional, production-ready solutions, reminding developers that human oversight and refinement are still essential.

The quality of AI-generated code still depends on professional oversight, since trade-offs, compatibility concerns, and maintainability are inherently contextual and beyond the AI’s current reasoning capacity.

For example, an AI might correctly adjust a memory limit when a process fails, but it can miss deeper dependency conflicts. It may also merge methods incorrectly if compatibility rules are unclear or generate rigid test cases that complicate debugging instead of simplifying it.

Don’t blindly trust AI-generated code

To help developers navigate these realities, Böckeler proposed a useful mental model:

AI assistants should be treated like junior developers. They are fast, capable, and eager to help, but they can also be overconfident and prone to mistakes.

Understanding their limits is key; like mentoring a new team member, trust must be conditional and context-dependent. Blindly accepting AI-generated code can lead to subtle bugs and long-term maintainability issues.

The hidden pitfalls of AI-generated code

Drawing from her own experience, Böckeler emphasized several recurring pitfalls:

• Superficial fixes: AI often suggests quick solutions that don’t address deeper architectural problems.
• Problematic test cases: Generated tests can be too brittle or too vague, sometimes requiring as much debugging as the original code.
• Reinforcing poor design: In messy or poorly structured systems, AI may perpetuate suboptimal design choices, increasing future maintenance costs.
• Increased code churn: Studies show more rework is needed on AI-generated commits, often within weeks.
• Unexpected debugging effort: Developers frequently spend more time fixing AI outputs than initially anticipated, highlighting the need for careful oversight and management.

This is why Böckeler recommends a proactive, disciplined approach: AI-generated code should never be accepted at face value but reviewed and thoroughly tested. Checkpoints and version control help roll back unwanted changes, and breaking complex tasks into smaller steps improves AI accuracy.

At the team level, quality control should remain a shared responsibility – automated tests and pull requests aren’t enough.

Monitoring quality metrics and integrating AI gradually helps prevent long-term risks to maintainability and security. Above all, expectations must remain realistic: AI cannot guarantee fixed productivity gains or eliminate the need for experienced developers.

The key lies in responsible use

In closing, Böckeler said that AI coding tools have become a permanent fixture in software development. They are robust, adaptable, and increasingly embedded in professional workflows, but their actual value depends on how responsibly they are used.

Developers must learn not only how to operate these tools, but also how to supervise, evaluate, and sustainably integrate them.

The challenge ahead lies not in automation itself, but in ensuring that it enhances productivity without compromising quality, maintainability, or team cohesion.

The post Treat Your AI Assistant Like an Overconfident Junior Developer appeared first on ShiftMag.

“Some of what we used to do has suddenly become easy, which increases the leverage of the other things that we do, things like setting goals, project management, and breaking down projects into milestones. But we’re not yet at the place where ‘genies’ are going to replace us. It’s just not true.“, said legendary Kent Beck, talking to ShiftMag recently at the Craft conference in Budapest.

By ‘genie,’ Beck, of course, means AI coding tools.

We still have to observe what the ‘genie’ does with the code because sometimes it’s useful, and sometimes it’s damaging.

The implementation stuff has gotten easier, and that is exactly why other skills, like breaking down projects, setting goals, and project management become much more highly leveraged.

The Forrest vs. The Desert

Beck’s work has significantly shaped how teams worldwide approach building software, emphasizing iterative development, continuous feedback, and close collaboration. He is the author of several books, including ‘Test-Driven Development: By Example‘ and ‘Implementation Patterns,’ which have become cornerstones of modern software engineering practice.

At the conference, Beck presented a compelling metaphor contrasting two distinct work cultures in software development, which he called “The Forest and The Desert.” As he put it:

In the forest, we lead with purpose, not with pressure, unlike in the desert, where pressure drives every decision.

This concept provides a framework to understand different approaches and values within teams and organizations.

The Forest represents a dynamic, adaptive environment where change is expected and embraced. Teams operate with purpose, not pressure, preparing continuously for inevitable shifts in the project landscape. This environment encourages experimentation, learning, and collaboration.

The Desert symbolizes a rigid, high-pressure setting focused on strict adherence to fixed plans and deadlines. Change is viewed as an enemy, and leadership emphasizes constant pressure to “do more with less,” often resulting in burnout and reduced innovation.

Leadership Approaches

In the Forest, leadership is about nurturing purpose and enabling teams to adapt and learn. Leaders recognize that some efforts may not yield immediate results but are investments in future adaptability.

In the Desert, leaders rely on control, deadlines, and pushing teams to meet exacting standards. They often measure progress through rigid metrics and status colors (e.g., project status is never truly green, as green means stagnation).

Handling Change

Forest teams plan for change by embracing uncertainty and preparing for it. Retrospectives and flexible processes are essential tools to evolve workflows. Desert teams attempt to force reality to fit predetermined plans, resisting change and viewing deviations as failures to be punished.

Value of Changes

Most feature changes in software have little or no impact on value. The Forest is optimized to identify and implement the few changes that truly matter. The Desert churns out frequent small changes, often producing noise rather than meaningful progress.

Metrics and Accountability

In the Desert, metrics are used to control and pressure individuals, often focusing on quantitative outputs like keystrokes or lines of code, encouraging competition and blame. In the Forest, metrics serve as tools for self-awareness and team reflection, never used to publicly single out individuals. Accountability is framed as a celebration of trust and responsibility, fostering a culture of openness.

Bridging the Forrest and the Desert

Dependencies in the Forest encourage collaboration across teams to resolve issues collectively. Compliance in the Forest is embraced as a resource that ensures quality and trustworthiness, not as a bureaucratic hurdle.

Kent highlighted the real challenge of bridging these two “parallel universes” of software development cultures. Misunderstandings arise because of fundamentally different assumptions and language around success, failure, and accountability.  

Lessons Learned from Kent Beck:

Lead with Purpose, Not Pressure: Cultivate a team culture that motivates through shared goals and meaning rather than fear of failure or punishment.

Prepare for Change, Don’t Resist It: Build flexibility into processes; expect and plan for shifts rather than trying to freeze plans.

Use Metrics Wisely: Employ metrics as tools for learning and improvement, not as weapons for blame or control.

Celebrate Accountability: Foster transparency and trust by encouraging team members to openly share progress and challenges without fear.

Manage Dependencies Collaboratively: Encourage cross-team communication to resolve dependencies rather than letting them become bottlenecks.

Embrace Compliance as a Resource: View regulatory and quality requirements as enablers of trust and product value, not obstacles.

Recognize the Culture You Are In: Understand whether your environment is more “Forest” or “Desert” and adapt your strategies accordingly. If possible, advocate for practices that move your team towards a more sustainable, Forest-like culture.

The post Kent Beck: AI ‘genies’ are not replacing developers yet appeared first on ShiftMag.

Modern technology organizations are failing the very people who build their future — developers, was a data-backed wake-up call by Dr. Cat Hicks, a psychologist researching software team, delivered at Craft Conference in Budapest.

In tech teams, developers often feel unseen and unprepared for rapid change. One engineer admitted, “So much of my work never sees the light of day. That’s hard.”  

Why Developers Feel Invisible and Anxious at Work

Data tells the same story: a recent survey found that 88–90% of engineering managers believe they make developers’ work visible to the company, yet only 24% of developers agree.  

At the same time, roughly 43–45% of developers report anxiety that AI will render their skills obsolete. These gaps fuel real distress on teams: code-review anxiety, for example, can spike avoidance and withdrawal behaviors by around 40%, delaying work and eroding trust. Many devs feel trapped in a career treadmill – unsure if they’ll be noticed or needed – and the resulting stress leaks into every sprint and standup.

Burnout and Code Review Anxiety

Hicks’s research shows this isn’t just burnout – it’s a systemic problem of perspective and culture. Managers who see devs as isolated “cogs” create pressure to crank out quick wins. Devs respond with survival tactics – racing through tasks or hiding mistakes – but little of it builds lasting value.

The cost is high: projects stall, innovation sputters, and talented people become disillusioned. “When people avoid or procrastinate code reviews,” notes one psychologist, “it leads to delays in software. It also results in less cohesive teams and lower-trust teams”. In other words, anxiety and invisibility on the team translate directly into lost productivity and morale.

The Brains-in-Jars Fallacy

Hicks calls this destructive mindset the “brains in jars” model. Per that metaphor, developers are treated as fungible problem-solvers – machines whose output is all that matters. Teams push for metrics and milestones as if everyone works in isolation, ignoring the messy realities of people, collaboration, and learning.

But developers aren’t brains in jars. They bring history, creativity, and social needs to their work. When organizations adopt the brains-in-jars view, they underestimate how much developers learn from each other and how context shapes reasonable solutions. They assume any developer can jump in and instantly produce perfect code, which leads to punishing mistakes and ignoring the need to nurture skills.

What It Means to Treat Developers as Interchangeable

This flawed model drives what Hicks dubs “riddle productivity.” Teams obsessed with answering today’s riddle – shipping this feature or hitting this sprint goal – chase short-term wins. They fail to tend to the long-term ecosystem. The result?

“The more a team fixates on demonstrating short-term performance,” Hicks warns, “the less able they are to protect the foundations of long-term performance .” Engineers report crunching for deadlines and then fixing the same bugs again later.

Meanwhile, ample research shows that this pressure damages code quality and creativity. One developer’s lament—that their careful design never makes it to production—reflects a system that rewards output over insight.

Most developers have deep, sophisticated learning strategies, and their organizations… don’t care.

When Performance is Measured by Tickets Closed

Hicks paints the human side of this fallacy. Developers describe deep intuition and learning tactics they use daily – constant refactoring, personal projects, knowledge-sharing – but organizations often refuse to recognize or support those efforts.

Instead, “performance” is measured by ticket closures and story points. When people are measured this way, they stop experimenting or asking questions. They hide what they don’t know lest it count against them. Social learning—the conversations, pair programming, mentorship—is seen as an indulgence rather than the norm.

In a brains-in-jars culture, “learning on the job” becomes a risky gamble, and many devs stop asking for help or even stop proposing improvements. Innovations get shelved, and the organization’s collective knowledge becomes brittle.

Riddle Productivity vs. Cumulative Growth

The brains-in-jars mindset feeds a contest culture, like every sprint is a competition. People hoard knowledge to get ahead. They fixate on being the fastest coder or writing spotless code on the first try. Short-term metrics climb, but teams lose resilience. “Contest cultures” reward only immediate victories, not collaboration, says Hicks, and that creates a cycle of stress.

Developers become anxious that any mistake will be their downfall. Meanwhile, team members compete quietly over code ownership and recognition, fragmenting trust. Hicks argues there is a better alternative: a thriving, cumulative culture. In a flourishing culture, teams view each challenge as a shared puzzle (“a riddle we solve together”), not a duel.

Embracing Learning over Speed

The goal shifts from “be the best this sprint” to “learn and improve for next week.” Instead of hiding mistakes, people share them openly so everyone can learn. Instead of valuing only quick fixes, the team invests in documentation, mentorship, and tooling that pays off over time.

Growth is seen as a long game. As one leader summarized Hicks’s insight: teams should “amplify under amplified voices” and break out of fixed mindsets. In practice, this means encouraging side projects, pairing juniors with seniors, and celebrating learning, even if it looks like slower delivery in the short term.

The more a team fixates on demonstrating short-term performance, the less able they are to protect the foundations of long-term performance.

Developers Are Like Seeds, They Need Soil to Flourish

To move beyond brains-in-jars and contest culture, Hicks offers the “Seed and Soil” metaphor as a solution (borrowed from social science). Developers are like seeds: they have enormous growth potential but need the right soil to thrive. No matter how talented a developer (seed) is, growth is stunted if the organizational environment (soil) is toxic or unforgiving.

Even modest developers flourish in rich soil. Walton and Yeager’s psychological-affordance research underscores this: interventions only stick when the context supports them. A learning workshop or new tool will wilt on dry ground; teams must first nurture the soil of culture.

Hicks defines three “psychological affordances” – essentially the nutrients in the soil – that are essential for developer thriving:

• Learning Culture: Teams must make learning itself a core goal. This means praising questions, tolerating failure as part of the process, and dedicating time to training or experimentation. In an authentic learning culture, mistakes are dissected constructively, and knowledge-sharing (like post-mortems or tech talks) is routine. Devs feel safe exploring new techniques because the team values the growth outcome over blaming the gap.

• Social Acceptance (Belonging): Every team member must feel valued as a whole person, not just a code machine. This includes respecting diverse backgrounds and perspectives, celebrating small wins, and ensuring everyone’s voice is heard in planning and reviews. Belonging means leaders and peers signal that they want your input and that failures won’t ostracize you. Hicks’s data show that when developers feel this acceptance, they write better code and take more ownership.

• Self-Efficacy: Developers should believe in their ability to learn and contribute, even when tackling complex problems. This is built by giving people autonomy, appropriately challenging tasks, and feedback emphasizing progress. When developers build confidence through small wins, they’re less likely to freeze in the face of unfamiliar tools or AI uncertainty. Organizations can boost self-efficacy by pairing novices with mentors and framing AI as a tool that augments skills, not a threat.

These conditions – learning culture, belonging, and self-efficacy – form the fertile ground that lets developers “live up to their potential,” as one researcher puts it. But, seeds need soil, light, and water: in organizations, those correspond to support for learning, trust among colleagues, and belief in personal agency.

Invest in the Developer Environment, Not Just the Stack

On a human level, managers should listen to developers’ frustrations. A survey response like, “Most developers have deep, sophisticated learning strategies, and their organizations… don’t care,” is a wake-up call. The action starts with simple steps: ask developers what they want to learn next quarter; publicly praise someone for pairing or reviewing another’s code; invest in a learning stipend or a retreat. These are small seeds that, with enough care, can grow into thriving ecosystems.

Small Seeds, Big Change: How to Begin Today

In doing so, organizations take a science-backed approach. “We must study the world as it comes to us,” Walton and Yeager remind us, meaning we must address root causes, not just symptoms. By tending the soil (affordances), we enable seeds (developers) to flourish. It’s a shift from “every developer for themselves” to “all developers together.”

The stakes are high: well-supported developers stay curious, write better code, and innovate more. And the business wins too – resilient teams that avoid churn and build maintainable products. As Hicks puts it, teams should no longer “chisel (roadmaps) out of rock while muttering about how ‘selectivity accelerates deliberation.'”

Instead, let’s turn on the lights, share the roadmap, and plant a garden of knowledge that pays off for years to come.

Innovation Needs Psychology

Dr. Cat Hicks is currently working on a book with CRC Press that will be released in 2026. The book aims to provide a human-centered roadmap for building healthier, more innovative technology teams.

I really believe, as a scientist in tech, that how we support innovation is with good psychology.

That’s what makes the lasting technology that we all want for the world.

The post Dr. Cat Hicks on Why Developers Feel Anxious At Work appeared first on ShiftMag.

Marianne Bellotti, a software developer with more than 20 years of experience and the author of Kill It with Fire, recently spoke about it at the Craft Conference.
Read on for the most important facts from this lecture, which can help IT industry leaders and software architects better organize and work efficiently on large projects.

Managing the fear of making mistakes

“Murder Boards” have a long history in politics and military operations, but they actually started at NASA as part of the engineering process.

In highly risk-averse, technical endeavors where extreme efforts are made to prevent mistakes (e.g., satellite operations), murder boards aggressively review, without constraint or pleasantries, a situation’s problem, assumptions, constraints, mitigations, and proposed solution.

The board’s goal is to kill the well-prepared proposal on technical merit; holding back even the least suspicion of a problem is not tolerated.

Such argumentative murder boards consist of many subject matter experts of the specific system under review and of all interfacing systems.

Working on large software projects also requires making significant and strategic decisions, and the fear of making mistakes is an integral part of the entire process. That’s precisely why Marianne adds that building and deploying technology is inherently very risky, and so much engineering management is managing fear on a team. Also, fear changes the decisions people make.

Murder boards are not code reviews

That is precisely why, adds Marianne, the Murder Board represents a panel of expertise. This way of knowledge or organization is used when working on and developing one of the projects, which is challenging. It also helps to see how errors can be removed or thrown out while developing large software solutions.

Although the Murder process could be a crucial part of software development, it is definitely not an alternative or different style of code review, a compliance/oversight activity, or a replacement for post-mortems.

When it comes to briefing colleagues regarding the murder board process, it is important that both parties have prior knowledge of the project plan, its historical context, and, in fact, everything that any large organization would do, only applied to the technical area, i.e., the IT industry.

Preventing failures

Marianne says that many did not trust the murder process and were afraid of it, and in fact, one of its leading roles is to protect colleagues from threats and fears that can arise in the demanding process of software development:

It is easiest to design and develop a plan at the beginning. Still, from the moment of checks and iterations until the execution of the plan, the fear meter starts to increase, which is exactly why you should have a murder board prepared in time.

Marianne adds that through good organization based on the murder board, two types of failure can be prevented:

Technical Failure:

• Scenarios where cascading failures will have unpredictable secondary effects;
• Board members: Principal engineers, staff engineers, architects.

Social Capital Failure:

• Embarrassment;
• External but also internal;
• Board members: Business leaders, strategy, legal, marketing/PR.

Best for high-stress/high-fear projects

Marianne also mentioned that one of the surprising benefits of murder boarding is that it can make people feel like their colleagues have their backs. Also, having your decision validated by more senior people can help reinforce a blameless culture if the worst does happen.

Before you set up your murder board, you should have in mind the following:

• I like to give my murder boards a day or two to submit questions to the team;
• The best murder boards will result in an in-depth discussion, so giving the attackers a chance to think through which concerns are the most serious and giving the defenders a hint on what the board might focus on helps everyone.

At the very end of her lecture, Marianne concluded that:

• Murder boards fit very specific situations: High-stress/high-fear events. The events are necessary and unavoidable;
• Opportunity to thoroughly vet plans, but not a code review, Should not be a regular part of the development life cycle;
• Done well, they build trust and confidence and help the team support one another.

The post Improving software architecture through – murder appeared first on ShiftMag.