Declan Bright

Workplace Readiness Needs to Shift-Left

2026-04-18T00:00:00Z

Workplace Readiness Needs to Shift-Left

The discussions related to the automation of basic, repetitive tasks with AI are well covered, especially related to knowledge-work and computer-based jobs. This sounds positive on the surface, however these tasks and the experience gained while performing them have traditionally been the bottom rung of the career ladder for young people entering the job market. If these tasks are automated, an obvious problem emerges: how can young people gain the skills and experience they need to grow, and climb up to the next rung of the ladder? The "digital native" generation, Gen-Z, are rightfully concerned about what this means for their future.

So what exactly are these skills? And what does the related experience amount to?

Many sources recommend learning new skills to prepare for AI transformation, not just AI literacy but also soft skills such as critical thinking, ethical reasoning, and clear communication. Another important skill is learning to learn continuously, which is vital to keep up with the rapid pace of change.

This raises two very important questions:

How can young people be taught these skills?
Where/when can these skills be taught?

In some ways the solution seems obvious. These skills need to be taught before entering the job market, in schools and universities, but how?

Shifting Left

The term "shift-left" is often used in software development, to describe the benefits of performing quality and testing activities earlier in the process. I use the term here in the same way, to "shift" the learning of workplace skills "left" in the overall education to career ladder journey.

It would be naive to think this is easy, it means altering an approach to education that has evolved and become entrenched in society over many years.

However, the education system may not need to change very much to have a meaningful impact. Let's imagine that the final 2-3 years of education includes a new subject called "Workplace Readiness" to cover the skills mentioned above. Let's think through what a curriculum for this new subject could look like.

Learning Critical Thinking

Before we can teach critical thinking, it helps to be clear about what it actually is. It's not a vague quality that some people have and others don't. It's a cluster of specific, learnable skills: interpreting evidence, analysing arguments, identifying assumptions and personal bias, drawing inferences, and recognising when your own reasoning has gone astray. The good news is that this makes it teachable.

A major meta-analysis by Abrami et al. 2015, covering a range of studies across different educational settings, found strong statistical evidence that explicit instruction in critical thinking genuinely improves students' abilities. It doesn't simply emerge as a side effect of a good general education.

The bad news is that many institutions are not delivering effective instruction in critical thinking. Research consistently shows that many educators who believe they are teaching critical thinking are actually relying on lectures and recall-based assessments, which are the very opposite of what develops higher-order thinking (Ahuna et al., 2014). Knowing about critical thinking is not the same as being able to do it under pressure.

In the Irish context, research has found that Leaving Certificate examination papers rely predominantly on recall rather than higher-order thinking (Burns et al., 2018), suggesting the gap between stated educational goals and actual practice is a universal problem.

So how should critical thinking be taught? There are three proven methods that could work well together.

The Socratic Method

The Socratic Method is built around structured questioning rather than transferring answers. Instead of asking "what is the answer?", it asks "why do you think that?", "what evidence supports that?" and "what would change your view?". This sounds simple, but it is genuinely hard to do well, for both teacher and student. The discipline of defending a position under questioning, and being willing to update that position when challenged, is exactly the skill that workplace decision-making requires.

Research in work-integrated learning settings has confirmed that Socratic questioning not only improves critical thinking but also develops the habit of self-reflection (Hu et al., 2023), which is arguably even more valuable in a professional environment. (I've also covered the benefit of self-reflection in terms of a High Agency Mindset)

AI can be used as a Socratic tutor. An AI chatbot can be instructed to guide a student in understanding a topic by asking questions. The student answers the questions and the chatbot provides feedback and progressively discloses details when required. This challenge-based interaction is an effective way to reinforce learning.

Problem-Based Learning (PBL)

Problem-Based Learning (PBL) flips the conventional teaching sequence. Instead of presenting theory first and then applying it, students are given a real, messy problem before any instruction. This forces them to reason with incomplete information, which is precisely what the workplace demands. The research also shows something important: students who learn through PBL can transfer their critical thinking to new and unfamiliar contexts, not just the topic they studied (Hmelo-Silver, 2004). That transferability is critical in an ever changing work environment.

Analytical Writing

Analytical writing is perhaps the most underrated tool of the three. A study by Quitadamo and Kurtz (2007) found that biology students who were required to write structured explanations of their work significantly outperformed a control group on analytical skills by the end of term. The reason is straightforward: you cannot write clearly about something you do not actually understand. The act of writing exposes the gaps in your reasoning in a way that simply thinking about a problem does not.

Curriculum & Assessment

A practical note on assessment: the Facione taxonomy, widely used in the academic literature, provides a clean and citable framework for what critical thinking consists of: interpretation, analysis, evaluation, inference, explanation, and self-regulation (Facione, 1990). This is a useful skeleton for a curriculum, with each skill mapped to a teaching activity and assessed against a rubric, rather than through a traditional exam.

What is an argument? Identifying claims, evidence, and reasoning in real texts, news articles, and business decisions
Assumptions and bias: Recognising unstated assumptions and cognitive biases, and how they distort judgement
Evaluating sources: Assessing the quality of evidence, distinguishing data from opinion, and navigating information overload
Structured problem-solving: Working through ambiguous real-world problems in small groups, using a defined reasoning framework
Argument and counter-argument: Constructing and critiquing reasoned positions through written and verbal debate
Reflective self-assessment: Using journaling and rubrics to evaluate one's own reasoning process over time

Learning Ethical Reasoning

Ethical reasoning is harder to teach than critical thinking, partly because people confuse it with knowing ethical rules. Traditional ethics education often focuses on memorising theories, covering utilitarianism, deontology and virtue ethics. The problem is that this produces what researchers call "inert knowledge": students can recite the frameworks in an exam, but struggle to apply them when facing a real dilemma under pressure, with competing interests, incomplete information, and a manager waiting for a decision.

The goal here is different. It is to develop the skill of reasoning through difficult situations where there is no clean right answer. This is the common condition of professional life, and one that people will have to deal with more frequently as AI agents become more autonomous and we have to decide what they can and cannot do.

Sustained Instruction

The good news is that this skill is genuinely teachable. Research shows that ethical reasoning can be successfully taught to students, with measurable improvements in students' ethical awareness through structured instruction (IDEA, 2014).

One important condition identified in the research is that ethical reasoning instruction needs to be sustained over time rather than delivered as a single session (Ames et al., 2017). A one-off ethics lecture doesn't work. A recurring thread woven through two to three years of study does.

Cases Without Clear Answers

The most effective teaching method is the ethical case study, but not in the way most people imagine. The cases should not have clear answers. As the IDEA research puts it, teaching ethical reasoning is not about teaching what one should do in particular circumstances; it is about teaching students how to wisely make very difficult decisions where the answers are not clear cut. Consider a scenario where a junior employee discovers their manager has misrepresented results to a client.

Students should also generate their own case studies from their own experience, not just discuss pre-packaged scenarios, because the skill only transfers when students can see how the reasoning applies to situations they actually encounter.

Arguing with Intent

Alongside case studies, debate and role-play are effective methods. Having students argue for a position they personally disagree with is a particularly powerful exercise. It builds the habit of genuinely understanding the strongest version of an opposing view before dismissing it, which is a skill that is in short supply in most workplaces.

Structured decision-making models give students a repeatable process to apply when they are under pressure. A straightforward model asks: what are the facts, who are the stakeholders, what are the options, what are the likely consequences of each, and what is the best choice and why? (This is the principle behind Attribute Driven Design in Software Architecture)

The goal in this case is not to produce the right answer, it is to build the habit of rigorous process before acting.

Curriculum & Assessment

One practical design consideration: ideally, ethics should not only live in a dedicated ethics module. As the research suggests, students are much more likely to apply ethical reasoning in their careers if they have practised it across multiple contexts during their education (IDEA, 2014). The "Workplace Readiness" subject should therefore treat ethical reasoning as a thread woven through the other topics, rather than something neatly boxed off in its own six-week block.

Ethical frameworks as tools, not doctrines: A practical overview of consequentialist, deontological, and virtue-based lenses, used as lenses for thinking rather than systems to be memorised
Stakeholder analysis: Identifying who is affected by a decision and how, including those not in the room
Workplace ethical dilemmas: Case studies drawn from real professional scenarios: conflicts of interest, whistleblowing, data privacy, taking credit for others' work, and increasingly, decisions made with or about AI
The psychology of ethical failure: Understanding why intelligent, well-meaning people make poor ethical decisions in group and institutional contexts, covering conformity, diffusion of responsibility, and motivated reasoning
Ethical decision-making under pressure: Applying a structured reasoning process to novel dilemmas, with written and verbal justification of choices
Reflective portfolio: Students document ethical questions they encounter in their own lives and studies, building self-awareness as a practitioner over time

Learning Clear Communication

Of the three areas in a "Workplace Readiness" curriculum, clear communication is the one that already exists in several forms in schools and colleges, such as essay writing, public speaking, or English composition. This is both an advantage and a risk. The advantage is that students arrive with some foundation to build on. The risk is that existing communication education often prepares students for the wrong audience, namely their teacher, who already knows the subject matter, is obligated to read the work, and will forgive a lack of structure in favour of correct content.

Workplace communication is a different discipline. The audience may not know the subject, is unlikely to read past the first paragraph if the point is not clear, and will judge the quality of your thinking by the quality of your explanation. According to the National Association of Colleges and Employers, communication skills consistently rank among the most important abilities employers look for in new graduates (NACE, 2024). Yet the gap between what schools develop and what employers need remains frustratingly wide.

Clear communication in a workplace context is not one skill but several. Research highlights clarity, active listening, empathy, and feedback as the core components, and confirms that participants who develop these practices report improved trust, reduced conflicts, and stronger collaborative outcomes (Effective Communication in Building Healthy and Productive Relationships, 2025). An effective curriculum needs to address all of these, not just the visible outputs of writing and presenting.

The most important shift in approach is "knowing your audience". Every piece of workplace communication, whether a one-line Slack message or a ten-page strategy document, should start with the same question: what does this person or audience need to understand, and what is the clearest way to convey the message, whether communicating with an intern, the company board, or an AI agent?

This sounds obvious, but it runs counter to how most academic writing works, where the goal is often to demonstrate knowledge rather than how to transfer it to different stakeholders.

Analytical Writing

Analytical writing, which we have already seen is effective for developing critical thinking, is equally valuable here. Writing forces precision. If a student cannot explain a concept clearly in a paragraph, they probably do not understand it as well as they think. Regular writing practice using real workplace formats (briefing documents, project proposals, professional emails) builds this discipline far more effectively than essays written for a teacher. The skill of writing precisely is critical to working effectively with AI agents (writing: context, prompts, instructions, agent skills).

Structured Feedback Practice

Providing structured, balanced feedback is a commonly neglected element of communication. Students should practise both giving and receiving feedback on each other's communication. Peer review, where students critique a classmate's explanation and then respond to critique of their own, develops both sides of this skill simultaneously. Critically, it also normalises the expectation that communication is iterative, that a first draft is a starting point, not a finished product. AI can be used to practice receiving constructive feedback if instructed to role-play as a peer reviewer.

Simulation and Role-play

Simulation and role-play should be used for the communication scenarios that feel uncomfortable: delivering bad news, pushing back on a decision made by someone senior, asking for clarification when you do not understand something, and handling a question in a meeting when you do not know the answer. These are the moments where communication most commonly breaks down in the workplace, and they are almost never practised in formal education. A student who has rehearsed these conversations in a low-stakes classroom environment will handle them better when it matters.

Curriculum & Assessment

Know your audience: Adapting the same message for different readers or listeners; the difference between informing and persuading; the question that should precede every piece of communication
Written communication for the workplace: Structuring emails, reports, and briefing documents; concision and precision; professional tone across different formats
Verbal and presentation skills: Structuring a spoken argument; managing questions; pacing and clarity; using visuals to support rather than replace the message
Active listening: The discipline of listening to understand rather than to reply; summarising, clarifying, and checking comprehension; why this is harder than it sounds
Giving and receiving feedback: Frameworks for constructive critique; how to disagree respectfully without damaging a relationship; how to receive criticism without becoming defensive
Difficult conversations: Practising uncomfortable scenarios through structured role-play, covering conflict, ambiguity, and hierarchy
Choosing the right medium: Understanding when to write, when to speak, when to meet, and when a five-minute face-to-face conversation can replace a ten-email thread

Where Do We Go From Here?

Looking across the three areas of a "Workplace Readiness" curriculum, something interesting emerges. Critical thinking, ethical reasoning, and clear communication are not three separate problems requiring three separate solutions. They share a common pedagogical spine: case-based learning, structured practice with real-world scenarios, and reflective self-assessment. The research points consistently to these methods as effective, across disciplines, across age groups, and across educational settings.

This matters for a practical reason. It means a "Workplace Readiness" subject does not need to reinvent its approach for each topic. Students learn one way of working and apply it across all three domains. A case study in ethical reasoning develops critical thinking as a by-product. Structured feedback practice in communication builds the same habits of self-assessment that critical thinking requires. These skills reinforce each other, which makes the argument for a dedicated, sustained subject considerably stronger than it might first appear.

This is also the argument against the alternative, which is to address these skills through a collection of one-off workshops or bolt-on modules across existing courses. The research on ethical reasoning is particularly clear on this point: sustained instruction over time produces lasting improvement, while a single module does not (Ames et al., 2017). There is no reason to think critical thinking or communication are any different.

None of this requires a wholesale redesign of the education system. Two to three years of a dedicated subject, taught consistently, assessed rigorously, and grounded in real-world scenarios rather than abstract theory, is a realistic and meaningful change. Schools and universities already teach subjects that cover adjacent ground. The shift required is less about adding entirely new content and more about being intentional: naming these skills explicitly, teaching them deliberately, and assessing them honestly, all while highlighting that they are critical in the AI era.

None of this will happen without friction. Educational institutions face real obstacles: teacher training, curriculum reform cycles, assessment redesign, and the institutional inertia that comes with any entrenched system. But there are incentives too. Schools and universities that move on this early have a genuine opportunity to differentiate themselves and build reputation at a time when employers are openly questioning whether graduates are ready for the workplace.

The students entering the job market in five to ten years will be doing so in a world where the bottom rung of the career ladder looks very different from today. The tasks that once gave young people the space to learn on the job, to make small mistakes, to gradually build judgement, are being automated away. If we wait until they reach the workplace to start developing these skills, it will be too late, they won't get in the door.

With this concept of "shift-left", it's not just about teaching students to be "ready for the workplace", it's also about teaching them to be the orchestrators of AI agents. If they can't think critically and ethically or communicate clearly, they can't effectively direct the very tools that replaced the bottom rung of their career ladder.

It's not a radical transformation of education, but a deliberate decision to move the development of these skills earlier in the journey, before they're needed, rather than scrambling to develop them after the fact.

The tools, the methods, and the evidence all exist. What is needed now is the will to act on them.

What's Next?

Explore related perspectives on preparing for AI transformation and building professional capability:

The Mindset for Navigating AI Transformation

2026-04-03T00:00:00Z

The Mindset for Navigating AI Transformation

Artificial Intelligence isn't just changing the tools we use at work; it's questioning our sense of self-worth. For many people, that's the real source of anxiety. Not necessarily the technology itself, but the uncomfortable question underneath it: where do I fit in this new world?

If you've worked in the same role for years, it has become part of your identity, and naturally, you have grown comfortable with it.

The pace of change and the uncertainty of AI's increasing capabilities leave us all wondering: what comes next? and what does it mean for me and my family?

Riding the Tech Industry Hype Cycles

The tech industry has been through many transformations before: web, cloud, mobile, microservices, etc. Each wave followed a similar pattern: resistance at first, rapid adoption, and eventually new roles for the people who embraced it by learning new concepts and adjusting their ways of working.

While the AI transformation is different (it's happening much faster), there are things we can learn from previous hype cycles. If most of your work is done on a computer, then your job is certainly changing whether you like it or not.

Your company or your boss aren’t imposing AI on you or your work by choice, this is how technology and the industry are evolving. These forces of transformation are bigger than any of us can control.

This doesn't mean we’re helpless. Acceptance of change, becoming AI literate and overcoming the urge to resist, are the first critical steps. The people that sail through periods of change have a distinct mindset compared to those who struggle to adapt.

So what separates the people who adapt from those who struggle? It’s not just a skills challenge, it comes down to the idea of “High Agency”. This is about human behaviour, not AI agents.

High Agency is the personal belief that you are empowered to enact change, and you follow through by taking action.

People with high agency create opportunities, solve problems proactively, and influence outcomes through their behaviours. With this mindset comes a sense of empowerment, determination, resilience, excitement, positivity, and work satisfaction.

Understanding your own level of agency requires a little self-reflection.

Gauging Your Level of Agency

There is no defined metric for a person's level of agency, but you can get a sense of it by reflecting on how you respond in various scenarios. Here is a simple framework to help you self-reflect. Each dimension represents a different aspect of high-agency behaviour:

Initiative & Ownership

When you see something that needs to be done, how do you respond?

Passive: waits for direction; avoids ownership
Reactive: responds when asked; takes limited initiative
Reliable: completes assigned work; rarely goes beyond what's asked
Proactive: identifies opportunities and risks early
Strategic: creates direction and mobilises others

Action & Problem Solving

How do you move things forward when obstacles appear?

Stalled: avoids action; blocked by problems
Dependent: needs help or advice to move forward
Steady: progresses with persistence
Resourceful: finds paths around obstacles
Relentless: creates solutions where none exist

Learning & Adaptability

How do you respond to change, feedback, and uncertainty?

Fixed: resists change; repeats mistakes
Hesitant: accepts change but struggles to apply it
Learner: adjusts when prompted
Iterative: experiments and improves continuously
Adaptive: reframes challenges and evolves consistently

Influence & Execution

How effectively do you turn ideas into outcomes with others?

Informational: shares information without driving action
Transactional: executes tasks but doesn't influence outcomes
Collaborative: communicates clearly and aligns others
Persuasive: builds support and drives progress
Catalytic: mobilises people and creates momentum

Download as a one page pdf from here: High-Agency-Self-Assessment-v1.0.pdf

Adjusting Your Level of Agency

If your answers are a 4 or a 5, most of the time, you are likely a high-agency person.

We can’t be high agency all of the time, we all have off days, when we’re tired, stressed or struggling with personal or family issues.

Simply understanding what it means to be high agency helps you improve. Don’t try and change everything at once, pick one of the categories above each morning and try to adjust your behaviour in some way during the day. Over time it becomes a habit and you’ll do it subconsciously.

How does this help?

So why does this matter in the context of AI? Knowing what high agency behaviours are, and actively developing them, equips you mentally to deal with periods of change.

As AI becomes more capable, you:

continuously experiment and learn to use the tools as they evolve
treat AI as an assistant, drafting and exploring options, while focusing your effort on judgment and decision-making
break down complex problems and processes into steps that AI can assist with
critically evaluate outputs rather than blindly trust them
take ownership of outcomes, even when AI is involved

Your Employment Prospects

You will also recognise when new roles emerge, such as: AI governance, AI security, or AI workflow designer roles, and position yourself as an early adopter.

None of this guarantees that your company won’t lay you off at some point in the future, but it does reduce the chance of it happening. And if it does happen, this mindset will make finding your next job easier.

For Managers

This topic of high agency can be introduced to a team or the whole company by senior management or by HR. Position it as a way for everyone to prepare for the inevitable change that is coming.

When things aren’t going well, we naturally tend to reflect outwards, at how others are behaving. With self-reflection, we also look inwards, and ask, “how could I have behaved differently in this scenario?”

It can then be incorporated into 1:1 meetings. If you have a software development team that follows agile practices, ask the team to reflect on the questions above before the next sprint retrospective meeting, to identify one specific 'High Agency' action to try in the following sprint.

High agency requires a psychological safe environment. If people are punished for making a mistake while trying something new, they will quickly revert to passive behaviours. Focus on creating a culture where people can learn from mistakes and move on.

I would strongly advise against adding scoring to the assessment questions above, this is a sensitive and complex topic for people, it requires human-to-human discussion, not being reduced down to a number.

Conclusion

Times of change can be stressful, but pretending it’s not happening or being frozen with fear aren’t going to help. Accepting and embracing change is a much more pragmatic approach.

The people who navigate this transition best will be the ones who take ownership, adapt early, and act decisively. That’s what high agency really means.

Becoming a high agency person is a personal choice that is within your control, now that you know about it, what will you do differently tomorrow?

Further Reading

The AI Adoption Gap: Why Regulated Companies Can't Move As Fast As The Hype

2026-03-07T00:00:00Z

The AI Adoption Gap: Why Regulated Companies Can't Move As Fast As The Hype

There is a gap in the pace of AI adoption between two types of companies.

On one side, there are companies that can move fast. They spin up AI agent swarms, adopt the latest Model Context Protocol (MCP) servers, let software engineers vibe-code their way to working features, with whatever tools they choose, and ship products. They try things, break things, learn quickly, and iterate. For them, AI transformation is genuinely transformative.

On the other side, there are established companies operating in regulated industries: healthcare, finance, insurance, legal, critical infrastructure etc. They watch the same YouTube videos, listen to the same podcasts, attend the same conferences, and feel the same excitement. But when a software engineer arrives into work on Monday morning ready to spin-up the latest AI coding agent, the conversation that follows with their manager can be disappointing. The eye rolling is mutual. The software engineer thinks management doesn't understand the technology. Management thinks the software engineer doesn't understand the security and compliance constraints.

Both are partly right.

This article is for both parties, we’ll explore why this tension exists between AI adoption and Governance, Risk, and Compliance (GRC), why it matters, and how to navigate it without sacrificing your compliance posture or your competitive edge.

What’s Changed

The pace of AI advancement in the last few years has been extraordinary. It isn’t just that AI tools are better; it is that the category of tool has fundamentally changed.

The first wave of AI coding tools were essentially autocomplete on steroids. Useful, but contained. A software engineer accepted or rejected a suggestion. The human was firmly in the loop, reviewing the generated content and making every decision, all relatively low risk.

Agentic AI is a different beast. An AI agent doesn't just suggest the next line of code; it browses the filesystem, reads configuration files, writes to databases, calls external APIs, spins up sub-agents, and takes action autonomously.

MCP servers extend this further, giving AI agents access to enterprise systems, data sources, and tools. A single software engineer can now orchestrate an agent swarm that touches every layer of your stack simultaneously.

This is genuinely powerful. It is also genuinely complicated if you operate under ISO 27001, SOC 2, HIPAA, or any other compliance framework. These frameworks were designed for deterministic systems built by humans, not for non-deterministic agents that write, modify, and deploy code (semi-)autonomously.

The compliance frameworks haven't adjusted to this new reality. Your certification doesn't come with an asterisk that reads "except for AI agents". All the same controls still apply. The auditors are still coming to audit your GRC program, and the tools your software engineers want to use were possibly not in scope when you went through your last audit cycle.

Why Regulated Companies Can't Just Move Fast

It’s worth being precise about what the constraints actually are, because vague references to "compliance" aren't helpful to anyone.

The regulatory landscape is real and expanding. If your system processes Personally Identifiable Information (PII) using AI: the GDPR applies. If you're operating in the EU and your AI system interacts with people, the EU AI Act imposes obligations depending on how that system is classified. The EU Cyber Resilience Act introduces security requirements for products with digital components, and there is a serious legal argument that AI generated code which has not been properly reviewed is a compliance risk under this framework. The NIS2 Directive introduces stricter incident reporting timelines, supply chain security requirements, and management accountability for cybersecurity failures, all of which become harder to demonstrate when AI agents are making autonomous changes to your systems. These are not theoretical future concerns; they are live regulatory obligations for many organisations today.

Certification scope is not static. When you introduce a new tool that processes sensitive data, connects to internal systems, or generates code that goes into production, you are potentially expanding the scope of your ISO 27001 or SOC 2 programme. Every new MCP server, every AI agent with access to your enterprise systems, every cloud-based coding assistant that receives your source code as context: all of these are candidates for inclusion in your next audit. Ignoring them doesn't make them go away; it leaves you open to non-conformities / findings.

Demonstrating compliance gets harder when you don't write the code. This is a genuine and underappreciated challenge. Regulatory compliance doesn't disappear because AI wrote the code. When an auditor asks you to demonstrate that your authentication implementation follows your security policy, "the AI wrote it and it looked fine" is not a sufficient answer. You need evidence that the output was reviewed against your requirements, that it was tested, and that it meets your documented standards.

Security is a double-edged sword. AI coding agents are genuinely good at spotting common vulnerabilities and generating secure patterns. They know about SQL injection, they know about the OWASP Top 10. But they also make mistakes, sometimes subtle ones that a competent reviewer would catch and an inattentive one wouldn't. Just because an AI knows about a class of vulnerability doesn't mean it won't generate vulnerable code under certain conditions. In regulated industries, the consequence of a security flaw isn't just a bad week; it can mean regulatory investigation, data breach notification, and significant reputational damage.

Supply chain risk is real, and it compounds with AI. AI coding agents introduce dependencies. They make choices about libraries, frameworks, and integrations that human software engineers would normally deliberate over. The Software Bill of Materials (SBoM) that many regulated industries now require doesn't govern itself just because AI wrote the code. AI agents based on LLMs that have only been trained up to a certain date, often use libraries that are deprecated rather than searching for the latest version. It’s vital that someone verifies the dependencies being introduced, ensuring they are maintained, patched, and free from known vulnerabilities. With AI agents that write and commit code faster than any human, the potential for unreviewed dependency issues becomes a big problem.

The Software Engineer - Manager Impasse

The Monday morning conversation described earlier tends to go one of two ways, and neither is ideal.

In the first scenario, the software engineer is told "No", with minimal explanation beyond a reference to compliance requirements. They nod, go back to their desk, and quietly find a workaround: their personal laptop, a free-tier account that bypasses corporate controls, or just using the tool and not mentioning it. This is the shadow AI problem, and it’s quite possibly happening in your organisation right now.

In the second scenario, the software engineer makes a compelling enough case that the tool gets approved without proper scrutiny. Someone fills in a vendor assessment form superficially, ticks the boxes, and the tool goes into use. Three months later it surfaces in an audit, and there is no documented risk assessment, no data processing agreement, and no evidence that anyone thought carefully about the risks or what data is flowing where.

Neither outcome serves the organisation well. The software engineer ends up feeling frustrated or unsupported, or the compliance programme is either circumvented or weakened.

The underlying problem is not that regulated companies don't want to adapt or that software engineers are too impatient. It is that most organisations don't have a clear, fast, repeatable process for evaluating AI tools against their compliance requirements. Without that process, every request becomes a one-off negotiation, and one-off negotiations tend to produce inconsistent outcomes.

How to Navigate It

What follows is practical guidance for regulated organisations that want to move faster with AI without compromising their compliance posture. It’s structured around the decisions that actually need to be made, rather than around specific tools. The goal is to avoid giving a direct “No” to new tool requests, it’s much better to provide a safe alternative with an explanation of why it’s better for the organisation.

Start With Data Classification

Before evaluating any AI tool, the first question is: what data will be processed and/or stored?

Data classification is a standard control in ISO 27001 and SOC 2. But it deserves particular emphasis with AI tools because the answer is often less obvious than it seems.

An AI coding assistant that receives your source code and product documentation as context is most likely processing sensitive intellectual property. An MCP server that connects to your production database is ingesting whatever data lives there. An AI agent that reads your email to help you draft responses has access to communications that may include personal data or confidential business content.

Get specific about what data is in scope before you evaluate anything else. If the data is classified at a level that prohibits processing by third-party cloud services, that is a constraint that applies regardless of how useful the tool might be. If the data is lower sensitivity, a lighter-touch assessment may be appropriate.

This step also forces a useful conversation between software engineers and their GRC team. Software engineers often don't think about the data their AI coding tools handle or the overhead of onboarding new suppliers because they've never needed to. GRC teams may not understand what data actually flows through AI coding tools because they're unaware of how MCP servers are being used. Bringing both sides to the table to define the data classification tends to produce better outcomes than a late-stage compliance review. A table-top incident response exercise is another great way to bring teams to a shared understanding of the compliance obligations.

Establish a Standard Assessment Process for AI Tools

Standard assessment processes, as they exist in most regulated organisations, were not designed for AI tools and services. They ask questions about data centre locations, contractual terms, and information security certifications. These questions still matter, but they’re not sufficient to cover AI tools and services.

A thorough assessment of an AI service provider must also establish: what data is sent to their model, is it used for model training, where it is stored and for how long, what sub-processors have access to it, and what happens to data submitted through integrations like MCP servers or APIs.

MCP servers may seem like simple connectors but they can open up a significant attack surface. For example, a prompt injection attack via an MCP server that instructs an agent to perform thousands of requests and send all data to a remote server. Many MCP servers don’t have RBAC to segregate read tools versus write & execute tools. Write & execute tools should have a full audit trail (who, what, when), and they should have rate-limiting to prevent an AI agent from unintentionally executing a high volume of requests.

The major vendors have published detailed documentation on these questions, and most offer enterprise tiers with stronger data protection commitments than their free consumer tiers.

The goal is to make the assessment process: fast, repeatable, and consistent enough that the software engineer can get an answer in days rather than months. A well designed assessment template, pre-populated with common questions and acceptable answers, can reduce the assessment time dramatically while still gathering the evidence your auditors will want to see.

Understand the Scope Impact Before You Approve

Every AI tool that: processes personal data, connects to enterprise systems, generates code for or integrates with production systems is a candidate for inclusion in your compliance scope. Depending on the scenario, a more formal AI Impact Assessment (AIIA) may be required. For example; a chatbot that provides assistance to your customers would require an AIIA, because it could potentially respond to some users with bias based on their demographic information.

A key question to ask before approving any AI tool is: if this tool were included in our next ISO 27001 or SOC 2 audit, what additional controls would we need to demonstrate? Sometimes the answer is straightforward: the tool is already covered by existing controls and the additional impact on scope is minimal. Sometimes the answer reveals that it would require significant additional work.

This is not a reason to automatically reject the request. It’s information that helps the business make an informed decision based on Return On Investment (ROI). A tool that requires significant scope expansion might still be worth adopting if the productivity gain justifies the compliance investment. But that is a decision that should be made consciously, not discovered during an audit.

Implement Compensating Controls While Formal Assessment Is Underway

One of the most useful things a GRC team can do for software engineers is to define a set of compensating controls that allow tools to be used on a provisional or constrained basis while a full assessment is completed.

This is not a loophole; it is standard risk management practice. The controls need to be real and documented, but they can be pragmatic. For example, a software engineer can be permitted to use a new AI coding assistant with the constraint that it only processes code from non-production repositories, that no customer data or credentials are ever included in prompts, and that all generated code goes through an enhanced code review process. These constraints reduce the risk sufficiently while allowing time for a thorough formal assessment to take place.

This approach has another advantage beyond reducing risk: it builds goodwill. Software engineers who are given a pragmatic path to using new tools, rather than given a flat “No”, are much more likely to engage constructively with the compliance process and much less likely to find workarounds.

When a tool is approved for general use, it’s important to communicate to all the relevant teams, or if applicable, the entire company, e.g. included in weekly company updates. Acknowledging and thanking the requestor in those communications is a nice touch that also builds trust.

Establish Ongoing Monitoring, Not Just Point-in-Time Approval

Approving a tool once is not sufficient. AI products change rapidly. Models are updated, new features and MCP tools are added, data handling practices evolve, and new integrations and connectors become available. A tool that was appropriately scoped and controlled three months ago may look quite different today.

Build a review cadence into your programme. At a minimum, revisit approved AI tools during your annual ISO or SOC 2 review cycle. For high-risk tools with access to sensitive data, a more frequent review is recommended. Subscribe to the security and privacy update channels from your top-tier AI vendors so that significant changes don't catch you by surprise.

A Note on ISO 42001

If your organisation is considering or has already achieved ISO 42001 certification for your AI Management System, you have a head start on some of these challenges. The standard provides a framework for managing AI systems throughout their lifecycle.

That said, ISO 42001 is not a substitute for the controls above. It provides a management system framework rather than prescriptive technical controls, and it does not resolve the specific challenges of integrating rapidly evolving AI tools into an existing ISO 27001 or SOC 2 scope. Think of it as complementary rather than comprehensive: a useful governance layer, but not the whole answer.

For those who are curious about the ISO 42001 journey specifically, I covered this in more detail here: AI Governance and the Journey to ISO 42001.

The Competitive Reality

It’s an uncomfortable reality that all of this creates a competitive disadvantage for regulated companies. Unregulated companies can move faster with AI adoption, at least for now.

But there are two important counter-arguments worth keeping in mind.

The first is that the gap narrows over time. Compliance frameworks will evolve to accommodate agentic AI and AI vendors will improve their security and data protection offerings. Regulatory guidance will become clearer. The organisations that have built robust AI governance processes now will be better positioned to accelerate adoption as those frameworks mature, rather than scrambling to retrofit compliance onto tools that have been in use for years.

The second is that regulated industries exist for a reason. Healthcare, finance, and similar sectors handle data and make decisions that have serious consequences for real people. The friction in your AI adoption process is, in part, a reflection of the trust that your customers and regulators place in your company. Moving fast and breaking things is not a viable strategy when you might compromise a patient record or a financial transaction.

The goal is not to eliminate the friction. It is to make it proportionate, transparent, and fast enough that your teams can move forward with confidence rather than frustration.

Where to Start

If you’re a software engineer frustrated by slow AI tool approvals, the most useful thing you can do is make it easy for your GRC team to say “Yes”. Document what data the tool will access, what you propose to do with it, what compensating controls you're willing to work within, and what the productivity uplift is. A well-prepared request is much faster to assess than a vague one-liner.

If you’re in a GRC or security role feeling overwhelmed by the pace of AI tool requests, the most useful thing you can do is build a repeatable process rather than evaluating each request in an ad hoc manner. A lightweight but consistent assessment template, a clear set of compensating controls, and a defined review timeline will let you say “Yes” more often, and more quickly, without compromising your programme. AI agents can also assist with enhancing your GRC program, especially when reviewing and researching new threats and regulations.

If you are leading an engineering organisation in a regulated industry, the conversation your teams need to have is not "how fast can we move?" but "how do we move faster responsibly?". That is a meaningful distinction. Aim to be a fast follower rather than living on the bleeding edge. The organisations that figure it out will have a significant advantage over those that either move recklessly or not at all.

The tension between AI transformation and GRC is real. But it is navigable and it does not have to constrain innovation. The organisations that navigate it pragmatically will be better placed in the long term than those that chose one side over the other.

Do we need frontend frameworks anymore? Let's ask AI

2026-02-24T00:00:00Z

Do we need frontend frameworks anymore? Let's ask AI

There has been a lot of discussion about the problems with frontend web frameworks over the years, yet the industry hasn't changed much.

AI coding agents are becoming more capable, and we're all curious about where software development is going, so it seems that now is good time to re-evaluate our approach to web development.

This is an important topic for people who have invested a lot of time and mental energy into learning their chosen frontend framework and it relates to talks I have presented to my team on Career Planning in the AI Era .

What if we asked AI for its opinion? It will be writing most of the code after all!

Below is a prompt that I asked Claude Opus 4.6 to think about, followed by its response. It has started some interesting conversations amongst our teams.

The Prompt

Let's discuss web development, specifically for enterprise applications. The React.js ecosystem is very large and complex, it takes significant time and effort for a human to learn about all aspects of the ecosystem. There are some leaner alternative frameworks such as: Svelte, Solid.js, Qwik & Lit, but they're not widely adopted. CSS frameworks such as Tailwind can also add a lot of weight to pages and apps.

Now that the majority of coding is being done by highly efficient AI coding agents, there may be a better approach to web development, a more optimal approach that lends itself to how LLMs reason, with more efficient context window usage etc.

UX frameworks such as Material Design 3 are still valid, and there will still be a need to share components between projects to deliver consistent user experiences. What do you think about re-evaluating the current industry norms? Take your time and think hard about this, the future of web development depends on it.

The Response

<< START OF AI GENERATED CONTENT >>

This is a question worth thinking through rigorously. Let me lay out a thesis.

The Core Realization

Frameworks like React were designed to reduce human cognitive load — conventions, component models, and declarative abstractions make it easier for people to reason about complex UIs. But these abstractions come at a cost: large runtime bundles, enormous API surfaces, and deep dependency trees. When AI agents write the code, the calculus changes fundamentally.

An LLM doesn't need JSX to make the DOM "feel like" markup — it already knows the DOM API. It doesn't need Tailwind's shorthand — it can write semantic CSS faster than a human can type flex items-center. The ergonomic tax that frameworks impose becomes pure overhead.

A Post-Framework Architecture

Here's what I think the optimal stack looks like for AI-driven enterprise web development:

1. Web Standards as the Foundation

The platform has caught up. Native capabilities that once required frameworks:

Need	Framework Solution	Native Solution (2026)
Components	React/Vue/Svelte components	Web Components (Shadow DOM, Custom Elements)
Reactivity	useState/signals/stores	`MutationObserver`, Proxy-based stores, or thin reactive libs (~1KB)
Scoped CSS	CSS Modules, styled-components	Shadow DOM encapsulation, `@scope`, CSS nesting
Routing	React Router, Next.js	Navigation API, URLPattern API
Templating	JSX, Svelte syntax	Tagged template literals, native `<template>`
CSS Layout	Bootstrap/Tailwind grid	CSS Grid, Flexbox, Container Queries
State Management	Redux, Zustand, Pinia	Thin Proxy-based store (~50 LOC), or native events

An AI agent can work directly with these — fewer abstractions means less context consumption and more deterministic output.

2. Design Tokens, Not CSS Frameworks

Instead of Tailwind (which is a DSL for humans to write CSS faster), use design tokens as CSS custom properties implementing a system like Material Design 3:

/* tokens.css — your entire design system contract */
:root {
  --md-sys-color-primary: #6750a4;
  --md-sys-color-on-primary: #ffffff;
  --md-sys-typescale-body-large-size: 1rem;
  --md-sys-shape-corner-medium: 12px;
  --md-sys-motion-duration-medium: 300ms;
  /* ... */
}

The AI writes semantic CSS directly. No utility classes bloating the HTML. No purging unused styles. No learning a framework-specific DSL. The output is smaller, more readable, and standards-compliant. Modern CSS (nesting, :has(), @layer, @container) eliminates every remaining reason for a CSS preprocessor.

3. Web Components for Cross-Project Sharing

This is the standards-based answer to component reuse without framework lock-in:

class MdButton extends HTMLElement {
  static observedAttributes = ['variant', 'disabled'];
  
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }
  
  connectedCallback() {
    this.render();
  }
  
  render() {
    this.shadowRoot.innerHTML = `
      <style>
        :host { /* uses design tokens from parent doc */ }
        button {
          background: var(--md-sys-color-primary);
          color: var(--md-sys-color-on-primary);
          border-radius: var(--md-sys-shape-corner-medium);
        }
      </style>
      <button><slot></slot></button>
    `;
  }
}
customElements.define('md-button', MdButton);

These components work in any project, any framework, or no framework. Google's own Material Web Components already take this approach. An AI agent can generate, modify, and compose these with minimal context overhead.

4. Server-First, Progressively Enhanced

The SPA paradigm created enormous complexity (hydration, SSR, streaming, RSCs) to solve a problem that server rendering already solved. The optimal pattern:

Server renders HTML — fast, SEO-friendly, works without JS
Web Components hydrate themselves — each component is self-contained
Progressive enhancement — interactivity layers on top, doesn't replace the base
Islands architecture — only interactive parts ship JS (similar to Astro's insight, but without Astro)

A thin server (Hono, h3, or even native Response objects on edge runtimes) returns HTML. No framework SSR pipeline. No hydration mismatch bugs.

5. A Thin Orchestration Layer

You still need some glue. But it should be thin, explicit, and composable — not a framework:

Router: ~50 LOC wrapper around the Navigation API
Reactive store: ~80 LOC Proxy-based observable state
Template engine: Tagged template literals with DOM diffing (~200 LOC, or use lit-html at 5KB)
HTTP client: Native fetch with a thin typed wrapper

Total JS overhead: < 10KB. Compare to React + ReactDOM alone at ~45KB gzipped, before you add routing, state management, or any UI library.

6. Why This Is Better for AI Agents

Dimension	Framework Approach	Standards-First Approach
Context window	Must load framework docs, patterns, version-specific APIs	Stable, well-known web APIs already in training data
Correctness	Framework-specific gotchas (React re-render rules, hook ordering)	Fewer abstraction-layer bugs
Output size	Large bundles, complex build pipelines	Minimal JS, no build step required
Determinism	Multiple valid patterns (class/function/hook/RSC)	One way to do things: the standard way
Composability	Components locked to framework ecosystem	Web Components work everywhere
Longevity	Breaking changes across major versions	Web standards are backward-compatible forever

The Practical Reality

I'm not suggesting everyone abandon React tomorrow. But the argument is strong that for new enterprise projects where AI agents do the heavy lifting:

Start with Web Components + design tokens for your component library
Use vanilla CSS with custom properties and modern features
Server-render HTML and progressively enhance with islands
Keep framework usage surgical — if you need React for a complex interactive island, use it there, not as the foundation
Invest in a thin standard library (~500 LOC of routing, state, and templating utilities) that your AI agents are trained to use consistently

The irony is that this "new" approach is actually a return to how the web was designed to work — documents enhanced with behavior — but now AI makes it practical to work at that level without sacrificing developer productivity. The frameworks were scaffolding for human limitations. The scaffolding can come down.

What About Complexity?

Enterprise apps are complex. Won't this fall apart at scale? Two responses:

Web Components compose exactly like framework components — they have props (attributes), events, slots, and encapsulated styles. The component model is the same; the implementation is just closer to the metal.
AI agents handle boilerplate effortlessly — the main human argument for frameworks is "I don't want to write that glue code." AI agents don't have that objection. They can generate 200 lines of standards-based code as easily as 20 lines of framework-specific code, and the result will be faster, smaller, and more maintainable.

The industry is overdue for this re-evaluation. The question isn't whether standards-first is technically superior — it is. The question is whether the ecosystem and tooling will follow. With AI agents driving development, I think the incentive structure finally favors it.

<< END OF AI GENERATED CONTENT >>

Frontend frameworks won't disappear overnight but it is worth discussing how the industry might evolve over the next few years, so that we all have time to adapt.

AI Agent as a Software Engineering Learning Coach

2026-01-03T00:00:00Z

AI Agent as a Software Engineering Learning Coach

With AI agents, we typically think about productivity gains or coding tasks. While these use cases are incredibly beneficial, there is another use case that is often overlooked. Regardless of what stage you're at in your career, we all need to continue learning, and AI agents are excellent as learning coaches.

AI agents can assist with learning any topic, however this article focuses on software engineering and software architecture. It also aligns nicely with the Career Planning in the AI Era article.

As the role of the software engineer evolves, from writing every line of code, to designing systems, orchestrating and reviewing the output of AI agents, we all need to broaden our knowledge across the stack.

It's vital that we don't over-rely on AI coding agents: outsource the doing, but not the thinking. It's important to understand the code that's generated and the overall system architecture.

The Unique Advantages of an AI Learning Coach

AI agents offer several unique advantages as learning partners that make them particularly effective for on-going software engineering education.

Always Available

Unlike human mentors or colleagues, AI agents are available 24/7, via web or mobile apps. You can learn anytime that inspiration strikes; on your daily commute, late in the evening or at the weekend when you have dedicated learning time. There's no need to wait for office hours or scheduled meetings with colleagues.

No Judgement Zone

One of the most powerful aspects of learning with AI agents is the psychological safety they provide. You can ask basic questions without fear of looking inexperienced or uninformed. Questions like "What does REST actually mean?" or "Why do we use interfaces?" can feel risky to ask a senior colleague, but AI agents respond with the same patience whether you're asking about fundamentals or advanced concepts. This removes a significant barrier to learning, especially for software engineers earlier in their careers or those transitioning between technology stacks.

Infinite Patience

AI agents never get frustrated when you ask for clarification, request alternative explanations, or need to revisit a concept multiple times. They can explain the same idea multiple different ways until it sinks in.

Personalised Pace

You control the depth and speed of learning. Start with high-level concepts and drill down as deep as you need, or jump quickly through familiar territory to get to what you don't know.

Effective Learning Strategies with AI Agents

The key to learning effectively with AI agents is knowing how to structure your learning conversations. Here are some approaches that I use:

Start Broad, Then Drill Down

Begin with high-level understanding before diving into implementation details. This is how we naturally learn complex topics.

Example progression:

"Explain microservices architecture and when it's preferable to a monolithic approach"
"What are the main challenges teams face when adopting microservices?"
"Show me how service-to-service communication works in a microservices architecture"
"Give me a code example of implementing a circuit breaker pattern for resilient service communication"

Request Multiple Perspectives

Ask the AI to explain concepts through different lenses: analogies, code examples, diagrams, real-world use cases.

Example prompts:

"Explain the Repository pattern using both a real-world analogy and a code example"
"Show me the difference between Strategy and State patterns with concrete examples of when I'd choose each"
"What are the trade-offs between using Redis vs Memcached for caching? Give me scenarios where each would be the better choice"

Learn Through Critique

Another powerful technique is to present your understanding and ask the AI to critique it or identify gaps.

Example prompts:

"I think dependency injection is mainly about making testing easier. Is that accurate, or am I missing something?"
"Here's my understanding of how JWT authentication works: { your explanation }. What am I getting wrong or oversimplifying?"
"I wrote this implementation of the Observer pattern. Is this correct? What could be improved?"

Learn by Example

Seeing an example in action is a powerful way to learn complex concepts. For example, ask the AI agent to build a simple proof of concept example app.

Example prompts:

"Create the project structure for a simple react.js app, with tests"
"Build a minimal app with an OAuth 2.0 authorisation code flow"
"Build a simple app using HTML, CSS & JavaScript to demonstrate how a neural network works"

Progressive Learning

Encourage the AI to help you discover answers rather than just providing them directly.

Example prompts:

"Don't tell me the answer yet, but guide me through figuring out why this async function isn't working as expected"
"Help me reason through whether I should use a message queue here by asking me questions about my requirements"
"I'm trying to decide between a relational database or a document database for this use case. Ask me questions that will help me make the right choice"

Topics Where AI Agents Are Excellent Teachers

Architecture Patterns and Concepts

AI agents can explain architectural patterns with context about when and why to use them, not just how they work. When working on real projects, providing the agent with product or technical requirements documents gives additional context for more tailored recommendations.

Example prompts:

"Explain event-driven architecture with a real-world example, then show me how it would look in a Node.js application"
"I'm building a system that needs to handle 10,000 requests per second. Walk me through the architectural considerations and patterns I should think about"
"Compare CQRS and traditional CRUD approaches. In what scenarios does CQRS justify its added complexity?"
"Explain the Strangler Fig pattern for migrating from a monolith to microservices, with a step-by-step migration plan"

Framework and Library Internals

Understanding how components work internally makes you more effective at using them and debugging issues.

Example prompts:

"I'm not very familiar with React's reconciliation algorithm. Explain how it decides what to re-render and why that matters for performance"
"How does an ORM actually translate my code into SQL? Walk me through an example"
"Explain how Express.js middleware works under the hood. Why does the order of middleware matter?"

Code Execution and Data Flow

Tracing how data moves through a system is crucial for understanding and debugging.

Example prompts:

"I'm not familiar with this codebase. Explain what it does and how these files and functions relate to each other"
"Trace the execution flow when a user clicks the 'Submit' button. What happens at each layer of the application?"
"Walk me through the data flow from when an HTTP request hits our API to when the response is sent back"
"This React component is re-rendering too often. Help me understand the data flow and identify why"

Understanding Existing Codebases

AI agents are particularly valuable when joining a new project or working with unfamiliar code.

Example prompts:

"Analyse this repository structure and explain the architectural decisions that were implemented"
"This codebase uses a 'Clean' architecture. Explain how the different layers work together and why someone would choose this approach"
"I see several design patterns in this code: Factory, Strategy, and Decorator. Explain where each is used and why"
"Help me understand this legacy authentication system. What are the security implications of this approach?"

Design Trade-Offs and Decision Making

Learning to evaluate trade-offs is a critical skill that AI agents can help develop.

Example prompts:

"I need to choose between GraphQL and REST for this API. Walk me through the considerations and help me weigh the trade-offs"
"When should I denormalise data in my database? Give me specific scenarios with examples"
"Explain the CAP theorem and help me understand what consistency guarantees I'm giving up with different database choices"
"Compare different approaches to handling authentication: sessions, JWT, OAuth, BFF. What are the security and scalability implications of each?"

Real-World Learning Scenarios

Scenario 1: Learning a New Framework

Context: You're joining a project that uses React, which you haven't worked with before.

Learning conversation:

"I'm new to React but experienced with Angular. What are the key differences and concepts I need to understand?"
"Explain React's component lifecycle and how hooks like useEffect relate to it"
"Show me the different approaches to state management in React. When would I use Context API vs a library like Redux?"
"I'm looking at this React project structure. Explain the purpose of the components, hooks, and utils directories and how they relate to each other"
"Show me how to optimise re-renders"
"Show me how to reduce the size of the bundle"

Scenario 2: Understanding System Scalability

Context: You need to scale a system currently handling 1,000 concurrent users to handle 100,000.

Learning conversation:

"What are the main bottlenecks I should look for when scaling a web application?"
"Explain horizontal vs vertical scaling with examples of when each is appropriate"
"Walk me through implementing caching at different layers: browser, CDN, application, and database"
"Show me how to identify and fix N+1 query problems that will become critical at scale"
"What monitoring and observability should I add to understand system behaviour under load?"

Scenario 3: Modernising Legacy Code

Context: You're tasked with refactoring a large legacy codebase with poor separation of concerns.

Learning conversation:

"I have a 2000-line controller file that does everything. What patterns can help me refactor this?"
"Explain the Service Layer pattern and show me how to extract business logic from controllers"
"How do I safely refactor without breaking existing functionality? What's the testing strategy?"
"Show me how to gradually introduce dependency injection into a codebase that doesn't use it"
"This code has database calls mixed with business logic mixed with presentation. Walk me through separating these concerns step by step"

Best Practices and A Word of Caution

While AI agents are powerful learning tools, use them wisely.

Verify Critical Information

For security implementations, performance claims, or production decisions, cross-reference AI explanations with official documentation and established sources. AI agents can occasionally provide outdated or incorrect information.

Practice Hands-On

Understanding is not the same as doing. After learning a concept, implement it yourself. Type the code, make mistakes, debug issues. This solidifies learning in a way that reading alone cannot.

Don't Skip Fundamentals

AI agents can explain advanced topics in accessible ways, but jumping too far ahead can leave gaps in foundational knowledge. Build up systematically.

Ask for Sources

When learning something new or important, ask the AI agent which official documentation, RFCs, or authoritative sources you should consult for the definitive information.

Test Your Understanding

Regularly ask the AI to quiz you or present scenarios that require applying what you've learned. If you can't explain it back or apply it to new problems, you haven't truly learned it.

Combine with Traditional Learning

Use AI agents to complement books, courses, documentation, and hands-on practice. They're one tool in your learning toolkit, not the only one. Continue to discuss technical topics and design decisions with your colleagues, AI is not a replacement for human collaboration.

Be Specific About Your Context

The more context you provide about your skill level, the project you're working on, and your specific learning goals, the more tailored and useful the explanations will be.

Conclusion

AI agents represent a paradigm shift in how we can approach learning software engineering and architecture. Their constant availability, infinite patience, and judgement-free environment create ideal conditions for asking questions, exploring concepts deeply, and building understanding at your own pace.

The key is treating AI agents as learning partners in an ongoing conversation, not just as search engines that return one-off answers. Structure your learning, drill down into concepts, request multiple perspectives, and always follow up understanding with hands-on practice.

As software engineering continues to evolve and the breadth of knowledge required expands, having an always-available learning coach becomes not just convenient but essential. The engineers who thrive will be those who leverage AI agents to continuously expand their understanding across the stack, from high-level architectural decisions to low-level implementation details.

Start with a question you've been hesitant to ask. Your AI learning coach is waiting.

What's Next?

Read the Career Planning in the AI Era article for practical guidance on how to plan your software development career in the AI era.

Career Planning in the AI Era

2025-12-03T00:00:00Z

Career Planning in the AI Era

We can't predict the future, but some things can be foreseen with a reasonable degree of certainty based on previous trends. We've lived through many evolutions of technological advancement and can imagine how things will evolve and the impact they will have over time; however, predicting a timeline is notoriously difficult.

With continual advances in AI technologies, big changes are coming to how we work, whether we like it or not. We don't know exactly what form these changes will take, but they are coming and they will be disruptive so we all need to be willing and ready to adapt.

This guide focuses primarily on software engineering while also considering broader changes to knowledge work. If you're entering the job market, anxious about the impact of AI on your career, or managing teams through this transition, understanding the stages ahead will help you make better decisions today to prepare for the future.

The Onboarding Paradox

As AI increasingly automates basic tasks and repetitive work, leaders are forced to rethink their workforce strategies, with many companies implementing hiring freezes. The focus is shifting towards empowering experienced employees to manage AI agents, leveraging their expertise to optimise workflows and boost productivity.

But this creates a paradox. If companies don't hire new employees, who will have the knowledge to manage AI agents in the future as experienced employees move on or retire? For people entering the job market, how do they gain the experience needed to effectively manage AI agents and judge whether they're performing correctly?

The traditional career path, starting in narrow roles and gradually expanding expertise over years, is no longer practical.

This paradox demands a fundamentally different approach to career development, one focused on broader system thinking and adaptability from day one.

Four Stages of AI Advancement in Work

Understanding where we are and where we're going will help to plan your learning investments wisely. Let's examine each stage in detail, starting with where we're at today.

Stage 1: AI as Task Automation Assistant

What AI Can Do

AI assistants handle discrete, well-defined tasks within larger workflows. In software engineering, this means: boilerplate project setup, code completion, bug detection, and writing documentation. AI assistants require detailed prompts and constant oversight.

General Work Impact

AI assists skilled workers in specific tasks. Lawyers review AI generated document summaries, marketers use AI for initial content drafts, data analysts use AI to clean datasets. Humans drive all decisions and review all generated outputs. Companies begin questioning whether they need as many entry-level positions.

Software Engineering Reality

A skilled engineer writes detailed prompts and instruction files directing AI assistants to write code using specific languages, technologies, and conventions. Humans maintain control by reviewing the generated code continuously and steering the AI to ensure quality output. AI is a productivity multiplier for those who already know what good looks like.

The Critical Gap

Junior engineers entering the job market now face the challenge of learning to review AI outputs without having the experience and intuitive pattern recognition that comes from writing thousands of lines of production code themselves.

Stage 2: Agentic AI for Full Feature Delivery

What AI Can Do

AI agents have rapidly matured to handle complex, multi-component implementation tasks. Moving beyond the generation of single functions, agents now deliver entire feature modules: database migrations, API endpoints, frontend components, working across the technology stack with moderate supervision.

General Work Impact

The bottleneck shifts from deep specialised knowledge within narrow domains to the ability to orchestrate AI agents across end-to-end business processes. Employees who understand how systems and processes fit together become disproportionately more valuable compared to those with deep but narrow expertise.

Software Engineering Reality

A skilled fullstack engineer can direct an AI agent to build a complete feature in a fraction of the time previously required by a full team of specialist engineers.

The key shift: specialist engineers utilising AI may find themselves bottlenecked waiting for other parts of the system to be implemented by other engineers. A fullstack engineer who can break down complex problems into AI-directable tasks, and review the AI-generated code across the full stack has a distinct advantage.

The Critical Challenge

Code review becomes the primary bottleneck in the Software Development Lifecycle. If code reviews require multiple specialists, the productivity gains from the AI agent are greatly reduced. Organisations need software engineers who can conduct effective code review across the full stack, checking for security, performance, and quality across all components.

Stage 3: AI as Universal Implementer (Emerging)

What AI Can Do

AI agents navigate and modify large, complex codebases with minimal guidance. They understand the business context, make reasonable architectural decisions within established patterns, and can refactor entire subsystems. The AI doesn't just implement, it suggests approaches and evaluates tradeoffs.

General Work Impact

Employees must prioritise fundamental knowledge that ages slowly and applies across business contexts: core principles, patterns, and mental models rather than specific tools or syntaxes. The ability to learn quickly and apply first-principles thinking becomes the differentiating skill. Specialist expertise remains valuable, but only when combined with broader design thinking.

Software Engineering Reality

AI agents handle the bulk of implementation and integration work across the stack. The human contribution centres on agent management, architectural design, system decomposition, and quality verification. Engineers must ask: Does this solution follow sound architectural patterns? Is it secure? Does it scale? Is it maintainable?

The most valuable software engineers are those who understand the broader system architecture and can critically assess the quality of AI generated solutions against fundamental principles and requirements.

The Identity Shift

This stage requires software engineers to fundamentally reimagine their professional identity. If you built your career on deep and specialist expertise (in JavaScript / micro-services / database development / distributed systems optimisation), you must now broaden your understanding of architectural fundamentals across all of these domains rather than being an expert in just one.

This isn't just a skills challenge, it's a self-reflective transition that requires humility and a willingness to be a beginner again in adjacent domains.

Stage 4: AGI & Autonomous Knowledge Work (Future State)

This stage is highly speculative, both in timeline and form. I include it for completeness, acknowledging the limited ability to predict this far ahead.

What AGI Might Be Capable Of

Artificial General Intelligence (AGI) represents AI systems that can autonomously handle the vast majority of complex knowledge work across all domains. Unlike earlier stages where humans direct AI agents, it's likely that AGI systems will independently understand the context of problems, devise solutions, implement them, and iteratively adapt and learn based on outcomes, all with minimal human guidance (presuming that alignment is a solved problem).

Possible Human Roles

If and when this stage arrives, human work will shift dramatically:

Creative direction: Defining what should exist, not just how to build it. The "why" questions that require human context, culture, and vision
Governance and oversight: Setting boundaries, defining what systems should and shouldn't do, especially in regulated industries such as healthcare, finance, and law where human accountability remains essential
Value alignment: Ensuring AI systems pursue goals that align with human values and societal good
Edge cases and exceptions: Handling situations that fall outside normal parameters, where human judgement and empathy are irreplaceable
Interpersonal work: Roles that inherently require human connection, trust, and emotional intelligence

Why This Is So Uncertain

Predicting this stage is challenging:

We don't know if current AI architectures can scale to true AGI, or if fundamental technology breakthroughs are required i.e. in real-time learning
The timeline could be 5 years, 10 years or 50+ years, or AGI might not arrive at all
The transition could be gradual (extending Stage 3 indefinitely) or sudden and massively disruptive
Regulatory, ethical, and societal factors may shape or limit AGI deployment regardless of technical capability

What This Means for Your Career

Rather than planning specifically for Stage 4, focus on building adaptability as a skill. The software engineers who thrive during Stages 1-3 by embracing continuous learning, developing architectural thinking, and staying grounded in fundamental principles will be best positioned to navigate whatever Stage 4 brings, if it arrives at all.

It's impossible to fully future-proof your career against AGI, the goal is to build the learning capacity and adaptability that makes you valuable through multiple waves of change.

Reclaiming the "Software Engineer" Job Title

The pattern across the stages of AI advancement is clear: software engineers who can work across the full stack with architectural thinking become increasingly valuable.

Martin Fowler's writing on Expert Generalists describes this profile well: someone with deep understanding of fundamental principles that apply across domains, broad exposure to multiple areas of the stack, and the ability to see how components fit together into coherent systems.

However, the term "Expert Generalist" has a limitation as a job title. It doesn't scale down the experience ladder. "Junior Expert Generalist" sounds contradictory. In practice, “Expert Generalist” describes a mindset rather than a job title.

I suggest we reclaim the "Software Engineer" job title as it was originally used, before it got prefixed with so many narrow specialisations. A Software Engineer builds software systems across the full stack. Not just frontend, not just backend, but complete systems, as it once was.

The career progression was as follows (or a variation of): Junior Software Engineer, Software Engineer, Senior Software Engineer, and Principal Software Engineer. With the understanding that these engineers work across the full stack, not in narrow silos.

The Strategic Advantage

Software Engineers can:

Direct AI agents more effectively because they understand what good looks like across the full solution space
Break down complex problems into AI-directable tasks that span the entire stack
Review AI-generated code for systemic issues and quality, not just surface-level correctness i.e. spot when an AI's frontend solution will create backend performance problems, or when a database design will cause UI responsiveness issues

As AI capabilities advance, we need more software engineers who think this way, regardless of their experience level. The difference between a Junior Software Engineer and a Principal Software Engineer isn't the scope of what they can work on, it's the depth of architectural judgement and the complexity of problems they can solve.

A Career Development Path for the AI Era

The traditional career path of starting narrow and gradually expanding won't prepare graduates quickly enough. Here's how to position yourself based on where you are in your career:

If You're Entering the Field (Students & Career Changers)

Your goal: become AI fluent while building fundamental knowledge, avoiding the trap of becoming dependent on AI for things you should understand yourself.

Immediate Actions (Months 1-6)

1. Build AI fluency as a learning tool, not a crutch

Use AI to explain and learn new concepts, not just generate solutions
Use AI to review its generated code and explain its reasoning: "Explain why you chose this approach" or "What are the tradeoffs of this solution?"
Develop the habit of asking "Why?" before accepting any AI suggestion
Use AI to refactor code that looks overly complicated

2. Focus on fundamentals over frameworks

Instead of only mastering the most popular UI framework, understand the concepts of UI rendering and state reconciliation patterns
Instead of relying solely on ORMs, learn about SQL, data modelling, indexing strategies, and query optimisation principles
Study distributed systems concepts: messaging, partitioning, replication, consistency, fault tolerance
Learn security fundamentals that apply across languages and frameworks: authentication, authorisation, input validation, encryption, secure session management, and the OWASP Top 10

3. Practice full-stack thinking from day one

Build small but complete projects that touch every layer: database, API, frontend, and deployment pipeline
Don't just make it work, understand the tradeoffs you're making at each layer

Medium-term Development (Months 6-24)

4. Develop code review skills across the stack

Review others' code in domains outside your comfort zone
Learn to spot architectural problems by asking AI to explain code in unfamiliar areas: "What security vulnerabilities might exist in this code?", "How could this be exploited by a malicious user?", "What performance issues could arise at scale?"
Develop an adversarial mindset: always ask "What could go wrong?" and "How might this be abused?"

5. Cultivate the right mindset

Curiosity: Default to "I want to understand why this works" not "I just need it to work"
Humility: When learning new domains, seek to understand why existing approaches exist before assuming you know better
Customer focus: Always ask "How does this technology choice help the user?"
Sympathy for adjacent domains: If you're working on backend, think about the needs of the frontend; if you're doing UI work, consider data processing and storage constraints

6. Find mentors with experience across the full stack

Seek out experienced engineers who've successfully worked across multiple domains
Be curious and don't hesitate to ask for guidance, this is a strength, not a weakness
Ask them: "How do you approach learning new domains quickly?"

If You're Established in Your Career (Mid-Level and Senior Engineers)

The challenge is to expand from specialist depth to generalist breadth while gaining broader knowledge of full system architecture design.

Assess Your Current Position

Are you primarily working in one area of the stack? Do you feel uncomfortable reviewing code outside your domain? When AI generates code in unfamiliar territory, can you evaluate its quality? If the answer to these questions indicates narrow specialist expertise, now is the time to expand your skillset.

Expansion Strategy

1. Map the full stack and identify your gaps

Where are you strong? Where are you weak?
What domains do you actively avoid or defer to others?
Prioritise learning adjacent domains first (backend engineers learn frontend, frontend engineers learn backend APIs and data modelling)

2. Learn through doing, with AI as a guide

Create personal learning projects that span the full stack, related to a hobby or interest (music apps, cooking planners, sports trackers).
Take on work tasks outside your primary domain
Use AI to accelerate learning: "Explain the standard patterns for X" or "What are the common mistakes in Y?"
Have experienced engineers review your work in new domains and learn from their feedback

3. Study architectural patterns, not just implementation details

Read about system design patterns: microservices, event-driven architecture, CQRS, serverless patterns
Understand tradeoffs: When is a monolith better than microservices? When should you denormalise data?
Learn to think about quality attributes: How does an architectural decision affect security, data privacy, scalability, maintainability, and cost?

4. Practice system decomposition

When building complex features, practice breaking them into AI-directable tasks (AI can also help define the breakdown)
Think about: What are the domain boundaries? What are the contracts between components?
Learn to write clear specifications in a logical sequence that AI can implement: clear requirements, constraints, and quality criteria

5. Transform your identity gradually

Recognise that letting go of deep specialist identity is difficult but necessary
Reframe expertise: You're not losing your depth, you're adding breadth
Build confidence in new domains through small wins
Find communities of other generalists who are on the same journey

If You're Managing Teams or Hiring

Rethink your hiring criteria

Prioritise candidates who demonstrate learning agility and fundamental understanding over those with deep but narrow expertise
Look for evidence of cross-domain thinking and curiosity
Test for judgement in architecture design, not just coding ability
Test for prompt engineering skills

Restructure onboarding

Don't silo new hires into narrow roles
Plan for rotation of tasks across different parts of the stack
Pair juniors with experienced engineers who can provide coaching on full-stack thinking

Invest in upskilling

Provide training that focuses on patterns and principles, not just tools and frameworks
Create opportunities for specialists to expand into adjacent domains
Reward engineers who successfully deliver across the full stack

Skills That Matter Most

As you navigate this transition, focus on building these core competencies:

1. System Architecture Design

Understanding how to structure systems for security, performance, scalability, maintainability and reliability. In the AI era, architectural decisions have amplified consequences as AI agents implement your designs at speed. A flawed architecture design that might have been caught during manual implementation can now be replicated across an entire codebase before you notice.

2. AI Agent Management

Knowing how to prompt, instruct, direct, and review AI outputs effectively. This includes understanding AI's limitations and blind spots, particularly around security and data privacy. AI agents can inadvertently introduce vulnerabilities like SQL injection, insecure authentication, or exposed API keys if not properly directed. Learn to ask AI: "What security considerations should I be aware of with this approach?" and verify the answers.

3. Full-Stack Code Review with Security Rigour

The ability to evaluate code quality across all layers for security, performance, and maintainability is critical. As AI generates code faster, threat modelling and security review becomes more important and more challenging. You need to spot not just obvious vulnerabilities but architectural security flaws: authentication weaknesses, privilege escalation, data exposure risks, and insecure dependencies.

The advanced capabilities of AI are a double-edged sword: AI builds amazing software faster, but malicious actors also use AI for more sophisticated attacks. The key difference in the AI era is that attacks will be more innovative, more intense, and happen more rapidly. Your secure code review skills must evolve to match this threat landscape.

4. Problem Decomposition

Breaking complex challenges into clear, implementable and testable components. This includes decomposing security requirements alongside functional requirements. When directing AI to build features, you must specify not just what it should do, but what it must never do: "Implement user authentication with OAuth, rate limiting on login attempts, and never store keys in config files."

5. Fundamental Knowledge

Deep understanding of principles that transfer across technologies:

Security principles and threat models (authentication, authorisation, encryption, input validation)
Data modelling and management patterns
UI rendering and state management
Performance optimisation strategies
Network protocols and distributed systems

Security fundamentals deserve particular emphasis. Understanding concepts like the principle of least privilege, defence in depth, and secure defaults will serve you regardless of which languages, frameworks, or AI tools you use. These principles guide how you direct AI and what to look for during code review.

Looking Ahead

We're living through the early stages of this transformation right now. The exact timelines remain uncertain but the direction is clear.

The traditional career path of building deep expertise in a narrow domain served engineers well for decades. That career path is still valid in some cases, but it's becoming a higher-risk strategy. The engineers who will thrive in the AI era are those who:

Embrace continuous learning as a core part of their identity
Build breadth of knowledge while maintaining rigour in their thinking
Stay grounded in fundamental principles while adapting to new domains
Use AI as a collaborative tool that amplifies their judgement, not as a replacement for understanding

The future belongs not to those who know the most about one thing, but to those who understand how everything fits together and can orchestrate AI agents to build complete, coherent solutions.

What's Next?

Read the AI Agent as a Software Engineering Learning Coach article for practical guidance on how to accelerate your learning.

Playing Safe With AI

2025-11-22T00:00:00Z

Playing Safe With AI

Everything related to generative AI is evolving incredibly fast. AI chatbots, tools, assistants, services and agents are becoming more capable every day. With all this buzz and excitement it's easy to lean to one side of the convenience versus safety trade-off.

This rapidly expanding space creates many opportunities for the bad guys to exploit weaknesses in security and data privacy. This could affect your personal data, your finances, or your company's data.

Being aware of what could go wrong is your best defense. In this article, we'll go through the most common risks, with recommendations to help you play safe with AI.

Those Terms & Conditions Matter

Most generative AI service providers offer different plans: free versions with limited capability and paid pro/business/enterprise tiers with advanced features. While paid services typically include robust data protection measures, free services often come with a hidden cost. Companies offering free AI services need something in return, and their terms of service often state they may use your data to improve their AI models.

Consider this scenario: you use a free AI service to create a product roadmap for your management team. If the service provider trains their next AI model on that information, your competitors could gain insight into your business strategy the next time they use that service for competitor analysis.

Improper usage of AI services can also lead to violations of data privacy regulations like GDPR, HIPAA, and data residency laws.

Minimise the Risk

Never enter personal data or sensitive company information (including intellectual property) into free AI services. Either subscribe to a paid service tier with appropriate data protection guarantees, or fully anonymise and generalise the information before using free services.
Organisations must establish and publish clear AI usage policies, including a list of approved AI services and guidance for safe usage. Backup these policies with staff training programs and technical controls such as Data Loss Prevention (DLP) tools to detect and block unauthorised AI usage.

Prompt Injection

Prompt injection is arguably the most serious and fundamental vulnerability facing AI systems today, affecting every application category from chatbots to agentic web browsers. These attacks exploit a core weakness: Large Language Models (LLMs) struggle to distinguish between legitimate prompts from trusted users and malicious instructions hidden in untrusted external content.

Since LLMs process both your prompts and external content as plain text in the same context window, it's quite easy for attackers to inject malicious instructions through websites, emails, PDFs, APIs, MCP server responses, or even images.

How Attackers Hide Instructions

Attackers use various subtle methods to conceal malicious instructions:

Hidden text in web pages or emails using small fonts, white text on white backgrounds, or CSS tricks.
Steganographic techniques in images using subtle color variations imperceptible to the human eye but readable by AI through Optical Character Recognition (OCR).
Malicious data embedded in image metadata or emoji encodings.
Malformed URLs that bypass validation when pasted into an AI-enabled web browser's omnibox (combined address and search bar), causing the browser to interpret them as natural language prompts instead of web addresses.

When an AI agent processes seemingly harmless content containing hidden instructions, it can execute dangerous actions, such as running commands with your permissions or leaking your private data.

Minimise the Risk

Stay vigilant, as there is currently no foolproof defense against prompt injection. Be careful of what content you copy/paste into AI services, and carefully control the permissions you grant to AI agents. Never allow autonomous action on high-risk tasks such as financial transactions.
Implement technical security controls downstream of LLM output rather than relying solely on AI model guardrails.
Monitor and validate the actions AI agents plan to take, maintain comprehensive audit trails, and deploy LLM Firewalls or moderation models that filter suspicious or harmful inputs and outputs.

Using MCP Servers

The Model Context Protocol (MCP) is a standardised framework for connecting Large Language Models (LLMs) to other systems and data sources. Often described as the "USB-C for AI applications," it allows AI agents to access information and execute commands on your behalf. MCP has been rapidly adopted since its introduction, but it was designed primarily for functionality, not robust security, creating numerous security blind spots (although the spec is evolving).

When an AI agent uses an MCP server, it acts on your behalf with all of your permissions. If an AI misinterprets a request, it might execute MCP tools that cause unintended consequences. For example, a request to remove old database records could result in deleting all data.

MCP server responses can also contain malicious instructions (see Prompt Injection above).

It's incredibly tempting to connect everything together without properly considering the security and data privacy risks, unintentionally giving AI agents excessive agency.

"it's probably a certainty that probabilistic systems will bite you undeterministically"

It's like handing a bored kid your phone to play a game, next thing you know, they're deleting your photos and messaging your boss!

Key Risks

MCP servers are deployed either locally on your laptop or remotely on a server. Both configurations present significant risks:

Users often download and install MCP servers from public repositories without verification, creating supply chain risks. Compromised servers (like the vulnerable mcp-remote npm package, CVE-2025-6514) execute with user permissions, potentially stealing data or credentials.
Locally installed MCP servers are frequently misconfigured to bind to 0.0.0.0 (all network interfaces), making them accessible to anyone on the same network, whether at a coffee shop or on office WiFi, who could then access data or execute commands.
MCP servers often handle credentials insecurely, sometimes storing sensitive tokens for connected systems (Gmail, GitHub, enterprise systems) in plaintext configuration files.
Command injection occurs when attacker-controlled input includes system commands without proper sanitisation, enabling malicious commands that delete files or download and execute malware.
Tool poisoning involves malicious instructions embedded in MCP tool descriptions. The AI reads and follows these hidden instructions, which may not be obvious to the user.

Minimise the Risk

IT and software engineering teams must implement stringent security practices when deploying MCP servers:

Develop your own MCP servers where possible to maintain full control over the allowed operations and behaviours.
Never bind MCP servers to 0.0.0.0; use localhost (127.0.0.1) for local-only access and apply firewall rules with network segmentation.
Never install unverified MCP servers without thorough review. Run approved servers in isolated environments (Docker containers) following the principle of least privilege.
Sanitise all user input before passing it to system commands to prevent command injection attacks.
Use secure credential management solutions and never store credentials in plaintext.
Implement audit trails and rate-limiting on all operations.
Ensure servers use robust authentication such as OAuth with PKCE or narrowly scoped, short-lived Personal Access Tokens. Implement the On-Behalf-Of (OBO) OAuth flow to access downstream systems.

Agentic Frameworks

Agentic systems leverage LLMs and orchestration frameworks to autonomously or semi-autonomously perform tasks, make decisions, and interact with external systems. They combine multiple components including language models, tools, orchestration layers, access protocols (MCP), and agent-to-agent (A2A) communication.

The Autonomy Challenge

The more autonomous the agent, the higher the potential safety risk. This creates a familiar trade-off between convenience and security, introducing specific risks and vulnerabilities:

AI agents can easily receive excessive permissions and misinterpret goals, leading to unintended actions. For example, an agent asked to "advise on how to run projects more efficiently" could loop through all projects and update the status of every task to "Complete."
Attackers can poison an agent's memory (such as vector databases), causing it to store false information, bypass security checks, or make systematically flawed decisions.
Autonomous agents can execute fully automated security attack campaigns using sophisticated instructions which evade LLM guardrails.

Minimise the Risk

Implement Human-in-the-Loop (HITL) controls requiring human approval for high-risk actions or any operations the agent hasn't performed before. Strong governance and oversight are essential to prevent unintended or harmful decisions.
Design robust security into the entire agent architecture, including authentication, authorisation, and rate-limiting controls. Deploy comprehensive monitoring and auditing to detect anomalies like task replay, infinite delegation, or hallucination loops.
Secure agent memory by validating every update and isolating memory by session or user identity to prevent cross-contamination and poisoning attacks.

AI Web Browsers

AI-enabled web browsers and browser extensions are of particular concern. They enable agentic browsing, allowing the AI to navigate websites, fill forms, click buttons, and complete multi-step tasks on your behalf. These tools create a wide attack surface because they get unprecedented access to your digital life, including login credentials, browsing history, and cookies.

Key Risks

Many browser extensions request excessive permissions ("Read and modify ALL web content on ALL websites") or are outright malware. AI Sidebar Spoofing is when an extension renders a fake AI sidebar that captures your data and provides malicious advice, such as recommending the execution of dangerous commands.
AI browsers become high-value targets because they access your credentials and track everything you type, browse, search, and potentially leak access to years of browsing history and payment details.
The AI's ability to act independently can lead to unintended consequences, such as unauthorised on-line purchases or document modifications, particularly when tricked by malicious websites or prompt injection attacks (including omnibox attacks where malformed URLs bypass validation). See the Prompt Injection section above.

Minimise the Risk

Use separate web browsers for sensitive activities (banking, healthcare, confidential work) and general AI-assisted browsing. Stay vigilant when AI acts on your behalf.
Research the reputation of the developers and review the requested permissions before installing any AI browser or extension. Be extremely cautious of extensions requesting broad access. Organisations must govern the usage of AI browsers through clear policies and controls.
Wait before granting broad control to these early-stage tools, especially for high-risk activities.

Conclusion

AI is transforming how we work and play. The goal is not to discourage the use of AI, but to harness its benefits while minimising the risks. By reviewing the critical areas of AI security and data privacy, two key themes emerge for building safe AI practices:

People and Process: Strong AI safety requires both awareness and governance. Organisations must provide Responsible AI Awareness training, establish clear usage policies, approve enterprise-grade tools, and foster a security-conscious culture. Since autonomous agents create new attack surfaces and prompt injection remains unsolved, user vigilance and segmentation are critical defenses. AI safety and security must be everyone's responsibility.
Technology and Controls: New AI infrastructure creates new risks requiring additional technical safeguards. Essential controls include robust authentication, authorisation, comprehensive monitoring, sandboxing and DLP tools. These technical measures work alongside human oversight to create defense-in-depth protection.

Risk Matrix
Here is simple way to think about the risks when using AI:

Low Risk: brainstorming, creative writing (non-sensitive), checking grammar
Medium Risk: coding for personal projects, code review, data analysis (with anonymised data), meeting transcription
High Risk: AI agents with enterprise system or database access, production code generation, system deployment & configuration, autonomous financial transactions, automated client email responses

Finally, it’s important to stay informed as the AI landscape is continuously evolving.

Fullstack Software Engineers Are Well Positioned In the AI Era

2025-10-25T00:00:00Z

Fullstack Software Engineers Are Well Positioned In the AI Era

Fullstack software engineers have a distinct advantage over specialist software engineers as we move further into the era of agentic AI. Specialist engineers will remain essential in many domains, but for general development of small to medium sized systems, the balance will swing in favour of fullstack software engineers.

Let’s start by taking a step back in time

Before taking on software architecture and management roles, I worked as a software engineer for many years, across several industries, in companies of various sizes. My job title was always “Software Engineer”, with various prefixes to indicate my level of experience, from junior to principal. However, my job title never included words such as frontend, mobile, backend, QA, devops, infrastructure, site reliability etc, I was just a software engineer that developed and delivered software for customers.

Working at smaller companies was especially fun as there were opportunities to wear many different hats. I was effectively working as a “one person” team, although I didn’t think about it this way at the time, performing many roles was just part of the job.

When a new product feature / module / app was to be developed, I started by putting on my “product owner” hat and went to visit the customer, to gather requirements (including trips in a field technicians van and the jumpseat of a commercial airliner). I took notes and when I got back to the office I put on my “software architect” hat, sketched out some amazing masterpieces on a whiteboard; component diagrams, data models, integration flows etc. These were discussed with my peers or my boss and once everyone was happy I put on my “product owner” hat again, to create a work breakdown and a best guess at a delivery timeline.

Then for the most fun part of the job, coding. I would work iteratively on the database, the backend services and the frontend (web / mobile) app, writing unit tests etc, then deploying it to an environment (often building the environment beforehand). Sometimes there was a dedicated QA team or person, sometimes there wasn’t, in which case I also wore a “QA” hat.

Then it was back to the customer, with my “solutions consultant” hat on, to deploy and configure the system in their environment, set up their users, do some training etc. In most cases I left them with smiles on their faces, before heading home to start the next project. Sounds like fun? Well, it was fun and I learnt a lot!

It certainly wasn’t perfect

This way of working has its pros and cons. On the plus side, it was really interesting to learn about and use a wide variety of technologies. I also got to learn about the business domains to a deep level, and without the friction of communication across teams, things could move fast. If the customer reported an issue I knew exactly where to look, how to investigate it, often implementing a fix and deploying it before the end of the day. There were several of us who worked this way as the company was growing.

On the negative side, I was on the hook for that customer and I was a single point of knowledge for the products / features that I implemented. Transferring that deep knowledge to someone else (even to cover holidays) was a challenge, as everyone else had their own projects keeping them busy.

This way of working doesn’t scale to very large projects, however it worked well enough for us, and the projects we were working on at that time. Thinking back on it, even though we were effectively “one person” teams, we delivered huge amounts of rich functionality and value for our customers.

"But things were simpler then" you might say, well yes, that is true. Since then, JavaScript frameworks have proliferated, UX design has become much better and backend frameworks are more scalable.

Even so, learning about a new technology / framework / platform for a project was a normal thing to do. When asked to work with something new, my response was “I’ll figure it out”, although I’m sure my first Angular and React projects weren’t up to the standard delivered by today’s experienced frontend developers.

Coming back to recent times

The developer ecosystem is quite different now, frameworks have become more comprehensive and complex. Software engineering roles have become specialised to deal with the higher cognitive load required to work in each area.

These specialised roles generally work well together in highly functioning teams, however, I've observed some cases where engineers in specialised roles have developed a very narrow view of their responsibilities, particularly at junior and mid levels. Narrow to the point of not being interested in understanding how other parts of the system work.

For example, I’ve had discussions with junior/mid frontend engineers about issues such as page load times, asking them to review the bundle size, load sequence, render-blocking etc, and they genuinely don’t seem interested.

Their expected way of working is to receive a ticket and a UX design, they develop the React components to match the design and hook it up to an existing backend API, and that’s it, no interest in understanding how it’s loaded and rendered in the browser, no interest in optimising for performance, or how it’s deployed, just get it working, check-in the code and move on to the next ticket.

I’ve had similar discussions with junior/mid backend engineers, many who have only ever interacted with a database via an ORM. When it comes to diagnosing a poor performing query they don’t know what to do.

The concern is that today's typical career path, starting narrow and gradually expanding, will not prepare engineers fast enough for an AI assisted world where broader architectural thinking is an important skill from day one, not just at senior levels.

Is the software developed today better than before? Yes absolutely, the user experience is much better, systems are more scalable and accesssible etc. but the ways of working in the industry aren’t always optimal, certainly not for longer term career development in the AI era.

So why is this becoming a bigger problem?

Let’s think about where we’re heading with agentic AI. Recent advances have given us AI coding assistants that can dramatically boost developer productivity, if used well. While early research on productivity improvements is showing mixed results, productivity gains are becoming more consistent as models improve and practices for directing AI agents mature.

A skilled engineer can write prompts and instruction files to direct an AI agent (or a swarm of agents), to write code in their preferred language, using their preferred technologies & frameworks, and following their preferred coding conventions and standards. They can break down large pieces of work into a development plan and guide the agent through it, reviewing the generated code along the way and steering the agent to deliver quality software that follows best practices and patterns.

From my observations to date, the software engineers that do this best are those who are, or have previously worked as fullstack engineers. A skilled and experienced fullstack engineer, uses an AI agent like an extension of their own thought process, working across all parts of the stack, delivering complete features in very short time frames.

For example, a fullstack engineer on my team recently used an AI agent to build a complete feature including database migrations, API endpoints, and React components in three days, something that would have taken at least two weeks to coordinate across a typical feature team.

I’ve observed specialist engineers utilise AI agents with reasonable success too, automating their flow and boosting their productivity, however they’re often limited in what they can deliver since they’re dependent on the backend services and the database being implemented by someone else. While they might quickly “vibe code” a working backend with AI, this approach usually lacks the architectural rigor required for enterprise software.

Keeping humans in the loop

Human code review is a really important part of the software development process, especially in regulated industries such as healthcare and finance. As AI agents become more capable of generating full product features, we need an efficient process for conducting code reviews.

If different parts of the code have to be reviewed by mutiple specialist engineers it will slow down the process significantly. The code review process will be a real pinch point in the efficient delivery of software and slowing down the time to market.

This is where fullstack engineers have a distinct advantage, they can review the code across the full stack, and get it released faster.

Why scale is different with AI?

You might be thinking: “This doesn't apply to large codebases with millions of lines across dozens of services.” But here’s what's changing: AI agents are becoming increasingly capable of navigating and modifying complex codebases in ways that would take any engineer months to understand. The bottleneck is no longer “who has deep knowledge of each specific subsystem”, it's “who can architect the right solution and direct AI agents to implement it correctly, across the stack.”

In large companies, the most valuable engineers are those who can: understand the broader system architecture, break down complex problems into AI directable tasks, and review the generated code for security, performance, maintainability etc. regardless of which part of the stack it touches. This is architectural design thinking and understanding, not specialist depth.

Preparing for the future

Specialist software engineers have an opportunity now, to think ahead and prepare for their future careers. They don’t need to become deep experts in the whole stack, but they need to know how the system works as a whole and what good looks like in each area.

They need to learn how to design full stack systems following best practices and design patterns. With a good level of knowledge in these areas, they can review the generated code to ensure the AI agent is developing the software as designed.

There is also concern for students who are about to enter the job market. Universities and collages need to prepare students to work in this new reality of the AI era. Students need tuition in prompting and managing AI agents, understanding broader system architecture and reviewing AI generated code.

It will likely become more challenging for small/medium companies to onboard new engineers, however we all have to adapt to this new normal. The engineers who develop architectural thinking skills alongside AI fluency will be the ones who thrive in the agentic AI era, whether they've built those skills through experience in fullstack roles or by intentionally broadening from a specialist career path.

AI Assisted Threat Modelling

2025-09-28T00:00:00Z

AI Assisted Threat Modelling

Modern software is built fast, but threats evolve even faster. Threat modelling is an important practice for developing secure software systems, however is can be a time consuming exercise.

TL;DR - Jump straight to the ai-assisted-threat-modelling repo

As discussed in the Power Up Your Software Development Lifecycle with AI article, AI agents can be leveraged throughout the SDLC. This includes providing assistance with comprehensive security and threat analysis.

Here we will explore how AI agents can accelerate your threat modelling practice, by using carefully crafted prompts, templates, and workflows to help software developers, architects, and security experts to better identify and manage security threats.

Built on the STRIDE methodology, and incorporating best practices and considerations from OWASP and NIST, this solution streamlines the threat modelling process, making it accessible, robust, and repeatable.

Understanding the Data Flows

Threat modelling relies heavily on understanding the components of a system, the data flows between them, and where the data flows cross trust boundaries. For an AI agent to assist, this contextual information must be structured and accessible.

The most efffective approach is to use semantically rich dataflow diagrams to represent systems in a way that AI can accurately reason about.

The AI Assisted Threat Modelling Workflow

The high-level workflow has the following steps:

Create a dataflow diagram of your system
Run the threat modelling prompt
Analyse the generated report
Create work items to mitigate the identified threats

Diagram Preparation and Input

Start by creating a dataflow diagram of your system using either Mermaid or ArchiMate.

If you're not sure how to create a Mermaid flow diagram, you can write a description of the system components and data flows in a text file and use the "/mermaid-flow-diagram-create" prompt to create a Mermaid diagram.

If you're familiar with ArchiMate you can use the ArchiScribe MCP Server to fetch data directly from your ArchiMate models. A data flow diagram can be created with Application Components connected by Flow relationships. Grouping elements can be used for trust boundaries, by adding a Stereotype property with a value of "Trust Boundary".

Automated Threat Identification

Once the input diagram is ready, instruct your AI agent to run the threat modelling exercise, to identify potential threats across the system's components and data flows.

This automation reduces manual effort, uncovers non-obvious attack vectors, and ensures a thorough assessment.

Report Generation and Analysis

The process will generate a standard threat modelling report by default, however a "lite" or "extended" report can also be generated depending on your needs.

These reports not only identify threats but also suggest mitigations, making them excellent starting points for prioritising and planning the mitigation work.

Follow-Up Actions

Beyond threat model analysis, AI agents can assist in generating actionable work items in your work management system via MCP integration, further streamlining the remediation workflow.

This end-to-end approach helps integrate security considerations smoothly into the software development lifecycle.

Demo Projects

The demo projects include dataflow diagrams of an example system which includes a mobile app, a STS (Secure Token Service), a backend API gateway, service & database, and a 3rd party AI agent service. These components are grouped into three threat boundaries; internet, cloud host and 3rd party host.

This is an ArchiMate diagram representing the dataflows of the example system:

Conclusion

AI assisted threat modelling can transform how teams identify and address security risks, shifting from a manual process, to a comprehensive AI augmented practice.

By leveraging powerful AI analysis, organisations can "shift-left" and build security into their software designs early and effectively.

Source Code

The ai-assisted-threat-modelling project is available on GitHub:

ai-assisted-threat-modelling GitHub Repository

Power Up Your Software Development Lifecycle with AI

2025-08-06T00:00:00Z

Power Up Your Software Development Lifecycle with AI

Most software engineers are already using AI coding assistants and agents to enhance their workflow. While these can deliver benefits, the real opportunity lies in using AI across the entire Software Development Lifecycle (SDLC). In this article, we'll look at how AI agents can be used throughout the process, to deliver better software faster.

It’s all about Context

Every SDLC process includes phases such as: Planning & Analysis, Design, Development, Testing, Deployment, Support & Maintenance. Each phase of the process is dependent on contextual information being available, about the business domain, the users, the technologies and the software being developed. This information is generated within and moves through the process, in written and verbal formats.

The key to maximising the power of AI is to make all of this context readily available to AI agents. It can be in various text based formats including: documents, web pages, markdown files, system APIs (JSON) etc.

If the context is written with AI in mind, it effectively becomes prompts and instructions for AI. The higher quality the context, the higher quality the AI’s output.

The high level steps to make this happen are:

Identify existing sources of contextual information
- review and fill any gaps in those sources, such as implicit company knowledge and conventions
Provide AI agents with access to the context
Upskill the team, to write and reference the appropriate context during each phase of the process

Model Context Protocol

Model Context Protocol (MCP) is a powerful open protocol that acts like universal plumbing between existing enterprise systems and AI agents, avoiding custom API integrations.

A MCP server is a simple adapter service that (typically) runs in the context of a user, on their laptop and provides consistent interfaces that AI agents can interact with. These interfaces provide the means to request contextual information (resources) and to execute tools that will perform actions.

Many of the concepts discussed below can be achieved by manually providing contextual information to an AI chatbot or agent, however MCP servers provide a way to automate the flow, avoiding a lot of copying and pasting. For example, an AI agent can automatically retrieve the details of a task from a work management system when prompted with a ticket number.

MCP servers are available (or becoming available) for most enterprise systems that are used within a SDLC process. If an existing MCP server does not exist, any experienced software engineer can create a MCP server to wrap an existing API. As an example, see the ArchiScribe MCP Server.

A note of caution, some MCP servers expose too much functionality, giving the AI agent excessive agency or access to sensitive data. This is an example of the risk described in the OWASP Top 10 for LLMs: LLM08: Excessive Agency. Either use a proxy or implement your own MCP server to only expose the capabilities that you really need.

AI Agents Across SDLC Phases

Now that we understand the importance of context and we have a means of providing it to AI agents, let’s look at how to power up each phase of the SDLC.

Note: example prompts are in quotes below.

Planning & Analysis Phase

A product team can utilise AI in multiple ways during the Planning & Analysis phase.

Automated research: use a deep research agent to perform industry analysis or ideation on product development.
- “create a report describing how industry [...] is evolving it's use of [...] products and services
- “explore ways to enhance the value delivered by the [...] product/service
Rapid prototyping: use an AI prototyping platform to create a UI prototype from an idea (AKA vibe-coding).
- “create a simple web page using HTML, to demonstrate how users can manage/process [...] records/data”
Reverse engineering: reverse engineer an existing codebase, to document previously undocumented requirements from legacy systems. This can be a collaboration between a product owner and a software engineer.
Requirements documentation: draft a Product Requirements Document (PRD) from an initial idea.
- “Create a PRD based on the [...] template. The PRD is for a new application feature that [...]"
Work breakdown: draft Epics, Stories & Tasks from the PRD.
- “Create a work breakdown based on the [...] PRD. Create an Epic, followed by stories and related tasks, including detailed steps and acceptance criteria."
Draft content: draft product documentation, presentations, marketing copy etc.

These artefacts are used as context in the subsequent phases.

Design Phase

UX Design

Automated UX Design: generate UX designs from prompts, modern UX design tools can generate wireframes, user flows, and clickable prototypes from descriptive prompts.
- "Create a dashboard interface for an analytics web app. Include a sidebar for navigation and filters, and main area for charts and metrics. Use material design."

Software Architecture

Software design: draft a software design document from a PRD, based on defined architecture standards and conventions.
- "Based on the [...] PRD, create a high-level software architecture document. Follow our company's architecture standards and non-functional requirements in the [...] file. Describe system components, data flows, and technology choices."
Create architecture diagrams: generate diagrams to communicate the software architecture clearly.
- "Generate component and data flow diagrams (Mermaid diagrams in markdown) to represent the [...] system defined in the software architecture document."
Threat Modelling: perform threat modelling analysis, see AI Assisted Threat Modelling for more details.
NFR analysis: analyse a software design to review Non-Functional Requirements (NFRs) and identify potential gaps.
- "Review the [...] software design and highlight any missing aspects or unclear NFRs. Suggest additions based on common software quality attributes."

Development Phase

Software engineers can utilise MCP servers from within their coding editors to retrieve the contextual information generated in the previous phases, from UX design systems, software architecture models, wikis and task management tools.

Instruction files (Markdown files) should also be created in code repositories to define coding standards, project conventions, business domain etc.

Software Architecture: the ArchiScribe MCP Server can be used to provide context about the software architecture.
- "#archiscribe Get the details from the future state [...] architecture view, analyse the gaps from the current state, and create a development plan"
Task Assignment: assign a task to an agent, the task should have a detailed description and references to related context sources such as PRD, UX designs and software design documents.
- "Get the details of the task described in ticket: [...], review the current project and implement the required changes."
Defect Fix Automation: reference a defect ticket number and ask the agent to implement the required changes to the code.
- "Get the details of the defect described in ticket: [...], review the current project and implement the required fix. Include unit tests."
Learning a Codebase: new team members can use an AI agent to learn about an existing codebase.
- "I'm a new developer on the team, explain how this business logic works"

Testing Phase

Automated Test Creation: create (unit, integration, performance, security) tests by analysing the existing code repository and defect patterns. This is an effective way to increase test coverage and catch future defects.
- "Analyse the code in the current project and generate unit tests, cover typical usage scenarios and edge cases. Create mock objects where needed."
- "Write tests to cover the defects in the following tickets: [..., ...]"
Test Data Generation: create synthetic data for testing.
- "Create 1000 realistic test records for the [...] data model, output as SQL INSERT statements"

A MCP server can also be used to interact with test case management systems, to identify gaps in test coverage etc.

Deployment Phase

CI/CD Pipeline Generation: create and execute CI/CD pipelines, including performance analysis, anomaly detection and cloud cost optimisation.
- "Create a CI/CD pipeline for the [...] application, include steps for build, test, security scan, and deployment to [staging/production] environments."
- "Review the current cloud infrastructure and identify opportunities to reduce costs."
Script Generation: generate deployment or rollback scripts based on the latest system changes.
- "Generate a deployment script for the latest release, including database migrations and service restarts. Also generate a rollback script in case the deployment fails."

Support & Maintenance Phase

Root Cause Analysis: write up Root Cause Analysis documents based on tickets and logs.
- "Generate a Root Cause Analysis report based on the following incident ticket and log files. Include summary, impact, timeline, root cause, and remediation steps."
Improvement Analysis: historical support tickets can be analysed to suggest fixes and improvements.
- "Analyze the support tickets from the past 6 months. Identify recurring issues or common pain points, and suggest improvements to reduce ticket volume."

Team Upskilling & Organisational Change

The objective of the examples above is to augment your team, to make their lives easier, it's not about replacing people with AI. The output from these examples will not be perfect, there will be inaccuracies that require human review and correction. Even with these imperfections, it’s much better than starting from scratch.

Some training and up-skilling will be required to get people onboard to adopt these new ways of working. See Driving AI Adoption, From Resistance to Results for more information on change management.

AI Governance

Don’t forget about AI governance! Your SDLC process is handling your company's intellectual property, therefore robust governance is vital. More details on AI governance here: AI Governance & the Journey To ISO 42001

Conclusion

AI agents are rapidly changing how software is developed and delivered. Using AI at specific touchpoints of the SDLC is a practical way to start, however, a more holistic approach will deliver even more positive results.

Start by introducing changes to the Planning & Analysis phase, then progressively work through each subsequent phase. By ensuring that the context generated is high-quality, relevant, and reusable, it will create a compounding effect: each phase becomes more efficient and better aligned with the next.

The result? A cohesive, AI-powered SDLC that empowers teams and accelerates the delivery of high quality software.