Mark Berthelemy Consulting

Are your technology decisions creating debt?

Mon, 27 Jul 2026 00:00:00 +0000

As I talk to senior leaders about technology decisions, one of the most common topics of conversation is the long term impact of “quick fixes”.

You know the sorts of thing I mean:

Using software that someone’s purchased on their personal bank card, without going through any sort of due diligence
Setting up a customer in a way that is different to the rest of your customers so you get a sale
Using tools in non-standard ways to meet immediate needs
Allowing your internal coder to build a custom application
Bypassing the standard change process to “get it working”
Having unofficial and undocumented processes
Not upgrading the software because it’s “too difficult”
Using a spreadsheet to manage a process
Using unlicensed or unsupported software

At some point in the future, all those workarounds will, inevitably, come back to bite you. They are like a debt. The longer you leave it the more it grows, and the more impact it will have when you decide to pay it off.

The upgrade debt

Let’s take upgrading software as an example.

You’re a company with tight budgets, so you’ve picked up some open-source software to help run your business. There are many examples of great open-source software for all types of organisation - from full blown Enterprise Resource Planning, through Content Management, Customer Relationship, Project Management and Learning Management Systems.

You get someone to install it on a server, as that’s a bit too technical for your team. The software runs well, and does just most of what you need. But you add a plugin or two to make it a better fit, and perhaps an integration with your finance system. The technician sets up a backup system so you feel happy you can always recover if there’s a problem.

Over time, you receive notifications that there are upgrades available. But the software’s still working well, and the technician costs money, so you put it on the back burner.

But then you hit a point where you have to do something. Perhaps you’ve bought a new finance system and the software doesn’t work it, or your data protection officer identifies a high priority risk, or you hear about a significant vulnerability in the version you’re using. Or maybe you actually get hacked…

There are all sorts of things that might prompt an urgent upgrade. But that’s the point where the technical debt has to be paid off.

What could have been a simple process has now become a major project - often requiring changes to the underlying server software, managing multiple upgrade steps, and testing customisations at each stage. All this takes time during which the software - and potentially your business - is out of action.

Non-standard practices debt

The same is true of workarounds like non-standard ways of using software. For example, you might be using a content management system like Jekyll or WordPress. These tools are highly flexible, but they’re still designed to work best in certain ways.

So, if you decide to use “blog posts” as “pages”, or a “data file” instead of a “collection”, one day you’ll have to deal with the consequences.

As you add content, you might start creating links to it - both internally and from external places like social media.

You might create processes and systems that are based on the content using these non-standard structures.

And the more time goes on, and you add more content, the more the technical debt accrues. It becomes ever more complex to pull yourself out of that debt. It won’t be just a matter of reorganising things. You’ve also got to deal with broken links, with the pain of re-educating your users, and with your search engine rankings dropping overnight.

Custom application debt

With anyone and everyone now able to create their own applications using AI, it’s extremely tempting to build everything from scratch - bespoke, just for your organisation.

Yes, in the short term, you’ll get the application you wanted. Maybe a system to help manage your clients and their projects, or a data dashboard, or a student tracking tool.

Don’t get me wrong. In the right environment, and with the right humans in the loop, this can be a valid approach.

Without that environment and those people, all you’re doing is creating a large debt to repay in the future. The software might work on the product owner’s laptop, but does it work at scale? Does it meet accessibility and security standards? Does it talk nicely with your other systems? What happens when those systems change around it?

Just as with our other examples, you have the choice whether to deal with the debt incrementally, or in one go when you hit that point where something breaks.

Conclusion

There are no right answers in any of these scenarios. We all make the best decisions we can given the information available at the time. What we can do, though, is be more aware of the consequences of those decisions - both for the short and the long term.

The most expensive technology mistakes...

Sun, 19 Jul 2026 00:00:00 +0000

One of the biggest surprises of my consulting career is that the most expensive technology mistakes I’ve seen weren’t caused by poor procurement. They were caused by decisions that had already been made before procurement even began.

In fact, it’s often the case that procurement exposes problems that already exist.

Starting with the technology

Far too frequently, organisations focus immediately on the technology. “We need a new LMS / LXP / CRM / CMS / CSM[substitute preferred platform acronym here]”

Instead, it’s far better to start with these two questions:

What’s the problem we’re trying to solve?
What evidence tells us this is the right problem?

Technology may be the answer. But it might also be solved through focussing on people or processes - the other two components of a successful operation.

Assuming everyone agrees on the problem

Procurement documents can frequently hide unresolved disagreements within an organisation. Buying in a solution won’t solve those disagreements. It’ll probably exacerbate them.

Each group within an organisation will have different perspectives on the problem. It’s important to involve all stakeholder groups in the conversation. They will help you to gain a holistic view - which may lead you to different conclusion than if you’d just relied on your own viewpoint.

Investing time in building a shared understanding will bring benefits later.

Confusing symptoms with causes

We’ve all come across organisations that suffer from issues like low engagement, poor reporting and manual or error-prone processes.

Technology may solve part of these symptoms, but it’s important first to dig into the causes of the symptoms. For example:

Unclear processes
Governance
Culture
Capability
Lack of ownership

Once the causes are identified, then we can find solutions that will deal with the causes and reduce the symptoms.

Not understanding the current environment

Replacing, or introducing, technology can bring in more problems than it solves. Before bringing in something new, it’s important to know the environment you’re bringing it into:

What already works well?
What should be retained?
What systems already exist?
What constraints exist?
What skills already exist?

Technology doesn’t exist in a vacuum. Having an awareness of the environment will make it much more likely that you’ll choose the right technology and implement it well.

Failing to challenge assumptions

We all make assumptions, often unconsciously…

New technology will solve our problems
Everyone wants the same thing
More functionality is better
AI is the answer

By bringing these assumptions into the open - identifying them and considering how we can validate them - we reduce the risk that we’ll make the wrong decision.

Every major project should include deliberate assumption identification and testing.

Looking for answers before gathering evidence

Evidence provides the foundation on which you can make and back up your decisions. Yes, you’ll never have all the evidence. But, still it’s important to have some. Otherwise your decisions will be made on gut feel - which may work for some people, but is probably not to be recommended.

You might want to consider evidence from sources like:

Stakeholder interviews
User research
Benchmarking against similar organisations
Usage analytics
Document reviews
External good practice and standards

Good evidence improves decisions.

Going to market before defining success

I see far too many organisations setting out their requirements and interacting with the market before they’ve even considered what they’re trying to achieve. This goes back to the earlier problem definition. Once you’ve defined the problem, you can define success:

What will success look like?
How will we measure it?

Without clear success criteria, vendor comparisons become difficult.

Procurement should confirm a decision, not make it

Just like buying a house, technology procurement is a multi-stage process.

Before you start talking to the suppliers, you should have:

Defined the problem (our garden is too small)
Gathered evidence (we can’t grow the vegetables we want to grow)
Identified the options (look around at what’s available)
Defined the evaluation criteria (what does good look like?)

The procurement exercise then validates that work (obviously with the option to revisit some of the conclusions drawn as you learn more)

Conclusion

Technology projects rarely fail because procurement was poorly managed. (Although I do know that can happen…)

They often struggle because the thinking before procurement was incomplete.

Those organisations that make the best technology decisions usually spend more time understanding their situation than comparing products.

Before you start your next technology procurement, perhaps ask yourself one simple question:

Do we understand our problem as well as we’re trying to understand the market?

The answer to that question might indicate whether you’re ready to find a solution, or whether you need to do some more thinking first.

[Editor’s note: This article was structured with the aid of AI, based on original ideas provided by the author]

Skills framework starter kit

Sat, 27 Jun 2026 00:00:00 +0000

Whilst at CABI, one of my major projects was their Skills for Agriculture framework. This was an important foundational step to help the organisation and its partners assess priorities for training and development.

We built a website to hold the framework, along with links to associated courses. It was pretty complicated - especially the process to manage the connections between skills and courses.

Since then, of course, AI has come in, with two effects:

Every website now needs to have some way for the AI scrapers to read it effectively
We can now tell the AI to make changes to a website, and manage its data - making it much easier to make the connections

So, I’ve done a completely fresh build of a generic skills framework website with associated courses. This reference site is designed to be a starter pack for an individual with a modicum of technical capability, but also for organisations with more experienced development teams.

Key features:

Based on the widely used SFIA Foundation framework approach: Category > Skill > Level descriptor
Human and AI readable website
Easy to modify the data
Branding configuration file controls colours, logo and key text elements
Built in automatic glossary linking to key words or phrases
Site wide search
Automatic build and hosting on GitHub Pages
Layout and design based on Bootstrap
Built using Jekyll
Fully documented for a non-technical user
Sample prompts for your AI agent
Make your own copy and start editing

I’ve released this with an MIT license. Basically that means you can do anything you want with it, as long as you provide some sort of attribution and don’t expect any sort of warranty… 🙂

All the data is stored in user-editable markdown files, with full documentation on how to make the changes and how to brand it to your own organisation. There are even some sample prompts to help you use it to build your own framework.

I’ve also provided full step-by-step technical documentation so you can get your own copy, run it on your computer and deploy it to a live website. It does look a little daunting at first, but you only have to do the bulk of the setup once.

Visit the skills framework starter kit

What is the role for L&D in an AI-supported world?

Sun, 24 May 2026 00:00:00 +0000

The course cage

For the past 20 years, for many L&D teams, their output has been defined by creating course packages - using authoring tools like Articulate Storyline, Rise, Gomo and the rest.

Creating these course packages (usually called SCORM packages) often involves a rigorous process - interviewing subject matter experts, instructional design, multiple sign-off stages, and solid testing regimes.

The overall end result is a repository of organisational knowledge, held within the Learning Management System.

“Held” is probably the best word to use here. The Learning Management System, and the SCORM format has acted like a cage around the content. In the best cases, users might be able to share links to courses - but not to individual screens or sections within in them. With some LMSs, even this was impossible.

In most cases, you’d come across the content either because the LMS/HR system combination had assigned the course to you, or you might be browsing the course catalogue, or you might be lucky enough to enter a search term that was in the title or description of the course.

There was no way to search inside the course packages unless you were inside them in the first place. No way to get to specific, granular pieces of knowledge, and no way to get answers to questions.

Unfortunately, this has led to many of the course packages providing extremely limited value to their organisations - despite the work that’s gone into them.

In the past year this has all changed.

Breaking down the SCORM walls

The engineers behind tools like Talvi, Filtered and Thrive have uncovered ways to unpack SCORM packages, even from within the LMS, and make them even more useful.

You can now search the packages from outside of them. You can ask organisational chatbots and expect answers generated from the courses. And, in some tools, even ask for a course custom-created for your specific needs.

In my opinion, this is a transitional state, to help us get back en route.

The course as the default unit of learning was a detour leading to a dead-end.

Back to a focus on granular knowledge

Two decades ago, the organisational intranet was big news. Not just the software systems to drive it, but also the governance and skills needed to ensure effective knowledge management. At a similar time, Google launched their Search Appliance - a server that sat inside an organisation’s server cabinet and did for the organisation what Google Search was doing for the general public - making information much more easy to find.

Unfortunately the intranet became a clunky, outdated repository where PDFs went to die. Governance quickly fell by the wayside. The shiny intranet was now a dumping ground for content - with multiple versions, no clear metadata and no lifecycle management.

And the Google Search Appliance was stopped as a product 14 years after launching because a) it didn’t fit Google’s new cloud-first operating model, and b) it became increasingly difficult to handle the complex security architectures prevalent in many large organisations.

Over that time, L&D unwittingly became the well-governed repository of organisational knowledge - as long as it was bundled as a course… We had the people, processes and technology designed to turn the organisation’s knowledge into something useful.

That is still true. What’s changed now is what we mean by something useful.

Focus on the organisational knowledge and the rest can be generated at the point of need

Instead of courses, I propose that L&D changes its focus to creating granular chunks of knowledge. The building blocks from which people will get performance support and/or courses - depending on their specific needs.

Rather than giving people the finished product, we’d be giving them Lego™ blocks from which they (or their AI more likely) can create something bespoke for them, when they need it.

Refocussing L&D

These building blocks are more likely to be things like answers to frequently asked questions, policy documents, standard operating procedures, call centre scripts and product descriptions.

The tools and the outputs might change, but the processes would remain roughly the same:

Identify - What exists? What is needed? What needs updating?
Extract - Work with Subject Matter Experts to distill and document
Organise - Write clearly. Use metadata
Test - Does the granular knowledge object make sense to the people who will use it? Is it compliant?
Promote - Drive awareness so people will be aware of their need to improve their knowledge, develop skills and change behaviours
Maintain - Ensure the knowledge objects remain current and valid

With a new focus on knowledge management and granular knowledge objects, L&D would be set up for the long term.

Informal Learning Target Operating Model

Thu, 21 May 2026 00:00:00 +0000

We spend most of our money in organisations on formal learning such as training and education. But, if we’re honest, most learning actually happens informally: through curiosity, social sharing, trial and error, on-the-job experience, and mentoring.

So, if that’s where the real value is, why do we keep putting all our resources into the formal side?

What is a target operating model?

A target operating model (TOM) is a way of describing how our ideal organisation will deliver value. It usually covers three main areas: people, processes, and technology.

People

The people section typically includes descriptions of:

Organisational structure – How people are arranged and roles are defined within the organisation
Governance – The policies and people that guide decision-making and accountability
Capabilities – The skills, knowledge and behaviours required within the workforce
Culture – The shared values, beliefs, and behaviours that shape how people work together
Performance management – The methods used to set goals, measure progress, and support development
Compliance – The legal, regulatory and ethical frameworks we should work under

Processes

The processes typically describe:

Value chain – The sequence of activities that deliver value to customers or stakeholders
Standard operating procedures – Documented steps that ensure consistency and quality in routine tasks
Continuous improvement framework – Processes for regularly reviewing and enhancing how work is done
Performance metrics – The measures used to track efficiency, effectiveness, and outcomes
Compliance – The processes we should follow to adhere to laws, regulations and internal policies

Technology

In the technology section, we often include:

Applications – The software tools used to support business activities and learning
Infrastructure – The underlying hardware, networks, and platforms that enable technology use
Analytics – Systems for collecting and interpreting data to inform decisions
Security – Measures to protect data, systems, and users from threats
Compliance – The way the technology should work to meet legal, regulatory and organisational requirements.

What does this look like for informal learning?

If we apply the TOM lens to informal learning, things look a little different to how they might look for formal learning:

People

In an informal learning model, the role of Learning & Development (L&D) shifts from a focus on training to a focus on supporting the informal learning processes.

Subject Matter Experts (SMEs) become active content producers, sharing their expertise directly with colleagues.

Learning champions emerge — individuals who model positive learning behaviours, help build communities, and encourage others to share knowledge.

Communities of practice form around shared areas of expertise - providing a space for ongoing dialogue and support.

A culture of psychological safety is essential, so people feel comfortable asking questions and sharing what they know without fear of judgement.

And all of this must still operate within a framework of compliance, ensuring that behaviours remain legal and ethical.

Processes

Processes for informal learning focus on aspects such:

Capturing and curating knowledge as it emerges, rather than relying solely on formal documentation
Learning rituals, such as end-of-project reviews or “What did we learn?” sessions. These help embed continuous improvement into daily work
Mentorship frameworks to support the transfer of tacit knowledge between colleagues
Micro-recognition - small, frequent acknowledgements - can incentivise people to share what they know and to develop learning skills and behaviours
Version control and governance processes ensure that organisational knowledge remains accurate and up to date
Compliance processes make sure that all these activities remains within legal boundaries

Technology

The technology that supports informal learning needs to enable:

User-generated content hosting - making it easy for anyone to share insights or resources
Enterprise social networks - providing platforms for discussion and collaboration across teams and locations.
AI-driven search tools - to help people find relevant information quickly, often drawing on both formal documentation and informal contributions
Learning analytics - to offer insights into how knowledge is being shared and used, and how that is having an impact on performance
Knowledge management systems — including version control and governance workflows to help maintain quality and consistency
Compliance features to ensure security and data protection in particular

Next steps

Every organisation is different, so the ideas above may need to be adjusted to your context. Once you have an idea of where you’re heading, then it’s time to map out how you will get there.

Consider your current state and the key milestones, challenges and resources you’ll need to get to your target.

Then break this roadmap down into actionable steps - assigning responsibilities, setting timelines, and defining how you’ll measure progress.

Then comes the hard work of implementation. That requires clear communication, solid support for your champions, and adaptation as you learn what works best in your context.

Coding for non-coders

Tue, 19 May 2026 00:00:00 +0000

AI coding tools — GitHub Copilot, Claude, Cursor, and others — have quietly removed the biggest barrier to building software: the need to know how to code. Without any programming background, you can now describe what you want and watch a working web tool, SCORM package, or data dashboard take shape in front of you.

But writing code without developer habits is a bit like driving a car without knowing the Highway Code. You might get where you’re going. You might not.

The good news is that the habits themselves are not complicated. Here are some practices I’d recommend adopting from day one, drawn from how experienced developers work. Follow them and you will significantly reduce the risk of your AI agent breaking things, going in circles, or producing code that works today but falls apart tomorrow.

Use a development container

When you ask an AI agent to build something, it needs a consistent environment to work in — specific tools, versions, and settings that match your project. Without one, the agent might make assumptions that work on your machine but fail when you (or someone else) tries to run the project elsewhere.

A development container (or “dev container”) solves this by packaging everything the project needs into a single, portable setup. VS Code makes this straightforward with its Dev Containers extension. You define the environment once, and from that point on, the agent — and anyone else on the project — is always working in exactly the same conditions.

Think of it like a self-contained workshop. Everything is in its place. The right tools are on the bench. Nothing goes missing between sessions.

Even more importantly, a container keeps the AI agent’s operations separate from the rest of your computer. It’s like a solid barrier between the agent and all your other important stuff.

Write a specification before you write a line of code

This is the step most non-coders skip, and it is the one that causes the most trouble later.

A specification does not need to be long or formal. It just needs to answer two sets of questions clearly.

Functional requirements describe what the product must do. What are the key features? What does the user experience need to look like? What must the end result actually achieve?

Non-functional requirements describe the constraints. Does it need to be accessible? How fast should it load? What devices will people use it on? Does it need to comply with any standards?

Two more things worth nailing down before you start:

Which frameworks do you want to use? If you are building a SCORM package, do you want Bootstrap for the layout? A specific JavaScript testing framework? Specifying this upfront keeps the AI consistent and stops it reinventing the wheel halfway through.
How will it be deployed? A SCORM package has very different constraints from a standalone web page or a server-side application. The agent needs to know this from the start, not discover it at the end.

If you’re not sure about which frameworks to use, ask the AI to recommend ones that will work for your context.

Give the agent standing instructions

AI coding agents can be given persistent instructions — sometimes called “skills” or “instructions files” — that shape how they work throughout a project. Rather than repeating yourself on every prompt, you write the rules once and the agent follows them automatically.

For any project I work on, I would create instructions covering at least three areas:

Accessibility. If you are building anything for learners, it needs to meet WCAG 2.2 AA standards. Tell the agent this upfront. Give it the specific patterns to follow for the components you are using.
The chosen framework. For example, if you have chosen Bootstrap 5 for your layout, say so explicitly. Without this, the agent may start mixing in other libraries or rolling its own solutions, creating inconsistency and bloat.
Testing. Specify what tests you expect the agent to write and when. If you leave this to chance, testing tends not to happen.

Writing these instructions is a one-off investment that pays dividends every time you start a new project. The same instructions can be reused and refined over time. Again, if you’re not sure - ask the AI agent to help you write them.

Use version control from the start

If there is one developer habit I would make compulsory, it is this one.

Version control — using a tool like Git — keeps a complete history of every change made to your project. If the AI agent does something catastrophic (and it will, eventually), you can roll back to a working state. Without version control, a bad change can mean starting from scratch.

You do not need to become a Git expert. Three concepts will take you a long way:

Stage: Choose which changed files you want to include in your next save point.
Commit: Save a snapshot of the project at that moment, with a note describing what changed and why.
Branch: Create a separate copy of the project to try something new, without touching the working version. If the experiment works, merge it back. If it does not, discard it.

GitHub Desktop or the built-in Git tools in VS Code make this manageable without touching the command line.

Ask the AI to create an implementation plan

Once you have your specification, ask the agent to produce an implementation plan before it writes any code. This serves two purposes.

First, it forces the agent to think through the whole project and identify dependencies — things that need to happen before other things can happen. Second, it gives you a chance to review the approach and raise concerns before work begins. Changing direction halfway through a build is expensive, even with AI.

The plan does not need to be exhaustive. A structured list of steps, in a sensible order, is enough. What you are avoiding is the agent jumping straight to implementation, making assumptions, and then having to backtrack.

Break the plan into small chunks with a Kanban board

An implementation plan is useful. An implementation plan broken into small, completable tasks is much more useful.

The principle here is the same as in any well-run project: large, vague tasks are hard to delegate, hard to track, and easy to declare “done” before they really are. Small, specific tasks are the opposite.

I use the Kanban Bases View plugin for Obsidian to manage this. Each task from the implementation plan becomes a card, which moves through columns: To Do → In Progress → Done. It is simple, local, and doesn’t need a subscription to another service.

The key discipline is to give the agent one card at a time. Complete it, review it, commit the result, then move to the next. This keeps changes small and reviewable, and makes it much easier to identify where something went wrong if it does.

Automate your testing

One of the underappreciated advantages of AI-built code is that the agent can write the tests as well as the code itself. This is something professional developers do as a matter of course, but it is easy to skip when you are not from a development background.

There are a few levels of testing worth knowing about:

Unit tests check that individual functions or components do what they are supposed to do in isolation.
Integration tests check that different parts of the system work together correctly.
End-to-end tests simulate a real user journey through the product, from start to finish.

You do not need to write these tests yourself. Ask the agent to write them as part of each task. Then, whenever you make a change, you can run the tests and know immediately whether anything has broken. This is especially valuable when you are asking the agent to refactor or extend something that is already working.

Review the code periodically

You don’t need to understand every line of code to maintain a useful oversight of it. There are a few questions worth asking the agent periodically — perhaps at the end of each major phase — to keep the codebase healthy.

Is it modular? Good code is organised into small, focused components, each responsible for one thing. If everything is tangled together in one large file, it becomes very difficult to change one thing without accidentally breaking another.

Does it repeat itself? The principle here is “Don’t Repeat Yourself” (DRY). If the same logic or presentation code appears in multiple places, a change in requirements means updating it in multiple places — and missing one. Ask the agent to identify and consolidate any repetition.

Is presentation separated from logic? The content and layout of what users see should be kept separate from the code that makes things work. HTML or templates handle the presentation; JavaScript or other code handles the behaviour. When these are mixed together, even small changes become disproportionately risky.

None of this requires you to become a programmer. It requires you to ask the right questions and trust that a well-maintained codebase is a significant asset — and a poorly maintained one is a significant liability.

Summary

These practices will not make you a developer. But they will give you enough of a developer’s mindset to use AI coding tools responsibly, to know when something has gone wrong, and to build things that are worth building.

Atomic content and the new learning architecture

Wed, 06 May 2026 00:00:00 +0000

In the traditional model of digital learning, the course has been the default unit of learning. We have used authoring tools to create courses, which are then delivered through a learning management system (LMS) to learners.

For years, experts like Cathy Moore, Jay Cross and Charles Jennings have been advising that courses are just a tiny part of the performance picture and should often be the last resort. Checklists, job aids, and coaching are, in reality, often much more effective. But the course has remained the dominant format for Learning & Development teams. Courses are easier to conceptualise, to package, to sell and to track.

This has led to our learning platforms being full of packaged SCORM content - highly produced products that are often expensive to create and maintain.

There are now some tools that allow us to break these SCORM packages into smaller pieces of content, which can then be reused and repurposed through an AI interface. This is a step in the right direction, but it still treats the course as the starting point for learning. To me, this is a stop-gap, a transitional phase on the way to a more fundamental shift in how we think about learning content and learning architecture.

The new learning architecture

What happens when the SCORM package itself is no longer the starting point, but is just one of many types of output that people can use to help improve their performance?

Instead of starting with a course, we start with the raw materials: the policies, procedures, knowledge articles, and other documents that contain the information people need to do their jobs. These raw materials are the building blocks, the atoms, on which we can build a learning ecosystem. They can be accessed directly, or more probably via an AI agent/chatbot, using information from other systems (like the LMS) to provide context and relevance, and combined to produce different outputs - a checklist, a job aid, a coaching conversations, or even a full course.

Knowledge management is the foundation

Effective knowledge management processes become the foundation of this new learning architecture. We need to ensure that the raw materials, the atomic content items are current, accurate, and easily accessible.

To do this, we need to establish clear processes for creating, reviewing, version controlling and updating content, as well as for archiving or retiring outdated information.

Structured text files are the building blocks

Most knowledge management strategies currently are based on Word documents, PDFs or pages in a content management system. The new AI-driven learning ecosystem will rely on content that is designed for AI consumption, within the minumum of cruft (unwanted code that costs money to process) around the text.

That will probably be simple text files, often formatted (for human readability) using Markdown (see The Markdown Guide).

AI agents are the glue

AI agents and chatbots will be the glue that holds this new learning architecture together. They will be responsible for accessing the raw materials, understanding the context of the learner’s needs, and combining the relevant content to produce the desired output.

The role of the learning designer

In this new learning architecture, the role of the learning designer will shift from being a course creator to being a content curator and architect. They will need to have a deep understanding of the raw materials, as well as the needs of the learners, in order to train the agents to deliver effective learning experiences.

Summary

In this new atomic model of learning, the focus is on creating small, reusable pieces of content that can be easily combined and repurposed to create personalized learning experiences.

This approach allows for greater flexibility and adaptability in the learning process, as learners can access the specific content they need at any given time, rather than being confined to a pre-defined course structure.

References

The course is dying as the unit of learning - Dr Philippa Hardman

Do we still need elearning authoring tools?

Wed, 22 Apr 2026 00:00:00 +0000

Can your AI agent replace authoring tools like Articulate Storyline, Adobe Captivate, or iSpring?

Recently I set myself a challenge to see how far I could go in creating a SCORM package using only AI tools. I wanted to see if I could create a simple elearning module without using any traditional authoring software.

It took about 30 minutes to set up the project, set the boundaries, define the skills the agent would need and to think about what I wanted to teach through the module.

I then set the agent running. About 20 minutes later, I had a fully functional SCORM package that I could test on SCORM Cloud or any LMS. The package included a simple quiz, some interactive elements, and a friendly, accessible and responsive design. The agent itself did not have any prior knowledge of SCORM or elearning development, but it was able to learn and apply the necessary skills to create the package. I’d even asked it to create a custom design for the module, and it was able to do so without any issues.

The result

You can see the result on this demo site: https://berthelemy.github.io/html-elearning-sample/.

If you want to go behind the scenes, you can check out the Github repository where I have documented the process and shared the code. The final SCORM package is in the dist/ folder. You can try it in your own LMS or on SCORM Cloud.

The learning design is simple: I wanted to create a module to teach people the imperfect tense in French. The agent was able to understand the topic and create content that was relevant and engaging for learners. That would probably be the only thing I would suggest needed more input from me. I’d left the instructions quite open - just referring it to the topic and the CEFR standards for level A2.

One of the great benefits of this approach is that the code produced by the AI agent is clean and well-structured. It follows best practices for web development and is easy to understand and modify if needed. This is a significant advantage over some traditional authoring tools, which can produce bloated and hard-to-maintain code.

The AI agent was able to create a SCORM package that met my requirements, and it did so with minimal human intervention. So this raises the question: do we still need traditional elearning authoring tools?

Limitations

The answer is not straightforward. Yes, we can use the AI tools to build very quickly. With the right instructions and parameters, we can create a functional SCORM package in a fraction of the time it would take with traditional authoring software. However, there are still some limitations to consider.

Firstly, the AI tools are not yet perfect. They can make mistakes, and they may not always produce the exact results you want. You may need to spend some time tweaking the instructions or fixing any issues that arise.

They are like an eager and very skilled intern; needing a lot of guidance and supervision to get the job done right.

If you’re just in the business of producing a lot of content quickly, these tools on their own might be enough.

The problems come when you want to make edits yourself or involve multiple stakeholders in the review process.

Editing

For me to make changes to the content, I have two options: I can either go back to the AI agent and ask it to make the changes, or I can edit the code directly. The first option may not always yield the desired results immediately, and the second option requires some technical knowledge - even though the code is clean and well-structured.

With a traditional authoring tool, I could easily make the changes myself (assuming I have a license for the tool, have the original source files and know how to use the software).

Collaboration

If I want to involve subject matter experts, instructional designers, or other team members in the review process, it can be challenging to get their feedback on the content.

When you’re working with a team of developers, this might not be a problem, since you can use their common tools and processes (eg. version control tools, pull requests and code reviews). But if you’re working with a more diverse team, it can be difficult to get everyone on the same page.

Many of the authoring tools have built-in collaboration features that allow multiple stakeholders to review and provide feedback on the content. They hide the technical complexity and provide a user-friendly interface for working together.

Conclusion

The AI agents are remarkably capable of creating functional SCORM packages quickly and efficiently. However, they are not yet a complete replacement for traditional elearning authoring tools, especially when it comes to editing and collaboration.

In the future this may change. If we find a way to separate the content from the code, that would make it easier to make edits to the content.

And,through an interface like Bugherd’s website review tool, we could provide a way for non-technical stakeholders to submit feedback directly on the content, which (following triage) then feeds issues into the codebase which the AI agent can then address. That would make it easier to involve multiple stakeholders in the review process.

Is XCL an alternative to the LMS?

Mon, 18 Nov 2024 00:00:00 +0000

I’ve been experimenting with the new beta version of XCL from Build Capable. It’s a new tool to help organisations deliver online learning without an LMS.

It looks like it has a lot of potential…

As I say in the video clip below, I’m really quite excited about what XCL can do. It opens up new possibilities.

Here’s what is does, and what it doesn’t (yet) do:

Plus points

It allows you to turn any digital resource into a trackable learning object (with caveats - see below)
If your resource is a SCORM or xAPI package, you can extract all the data that they provide (eg. completion status, scores etc)
If you upload files into XCL, like PDF, ppt, mp4 etc, you get much richer data than if you just link out to them
It works through this process: You provide a link to the user -> User clicks the link -> User enters their name & email -> Resource opens -> Data is sent back to XCL
You can capture the data in XCL’s internal learning record store, or your own LRS.

Things to work on

Resources provided via a URL just capture whether someone has launched them
In the beta version there is no way to inform people about your privacy policy, at the point of collecting their name and email address.
It currently struggles to display and play Youtube videos
You can only keep content secure if you either use the Enterprise Version with Single Sign On (coming soon) or put the content somewhere you control (thus losing a lot of the built in tracking)
I’m not sure I completely trust the Dashboard data. It recorded two completions of a SCORM package, when I’d only done it once.
There’s no way currently to perform additional analytics on the data stored in the internal learning record store
There’s not yet a way to capture a tick/check for the user to say that they have read and understood something (essential for compliance)

Creating a large scale training programme

Sun, 10 Nov 2024 00:00:00 +0000

Creating a large-scale training programme involves bringing many components together into a coherent whole.

There’s no one, right way to approach the problem. In fact, if you try a linear approach, you’ll probably fail.

Instead, I’d recommend going for an iterative approach, that gradually gets closer to a best fit solution.

You’ll need to consider things like:

The trainees

(Let’s call them that for want of a better word)

Who are they? Where are they? What are their current capabilities? What range of capabilities do they have? What are their motivations with regard to this programme?

The commissioning organisation

What is the programme meant to achieve? What are their success measures? What do they need the trainees to be able to do by the end of the programme? What are the timelines? What’s the budget? Who are the stakeholders?

The technology

What is already available? What reports will be required? Where will the data come from for those reports? What systems do we need to operate and deliver the training programme? What technology constraints are we working under?

The delivery organisation

How do they usually operate? What processes already exist? Do we have the personnel in place to run the programme? Who do we need to recruit? Where will they come from? What skills do we need?

The training itself

Will it be face-to-face or online or both? Will it be run as a self-study, or within cohorts? How will we assess capabilities? What activities might we use to help trainees practice their new skills? What knowledge do trainees need to complete those activities? What knowledge will they need at their fingertips when on-the-job?

Initially, you’ll feel like this is an amorphous blob of jelly. Gradually things will start to coalesce and take a more defined shape. There’ll be compromises. It won’t be perfect. If you’re able to run the programme for more than a one-off, then you can make tweaks and iterate towards that perfect state.