AI and no-code tools removed the code, not the thinking behind it

The mission

I designed and delivered the first two days of The Future Lab, an AI and no-code leadership bootcamp run by IJSchool in partnership with LSE Generate. Four days in total. My two came first, and they had one job: take a room of non-technical professionals from AI literacy to a working, shareable MVP. LSE Generate would then carry those MVPs through business model, validation, storytelling and a jury pitch.

The premise was simple to state and hard to execute. Non-technical founders are already shipping products with AI and no-code tools. The leaders who will matter over the next decade can direct AI themselves, and understand enough to know when the output is wrong. Two days, three tools, zero lines of code.

Here is the shape of the two days.

Who was in the room

Six people. Managers and founders working in health, fintech, fashion and government. Business and scientific backgrounds. Mostly corporate employees, a few founders. Not a developer among them.

The projects they built on day two were their own, drawn from their working lives rather than invented for the exercise. Three of them:

• A project management tool that escalates risks to the project owner automatically.
• A clinical support tool that analyses and cross-checks patient records so doctors can treat more efficiently.
• A platform to coach Malawian students through career decisions.

These are not toy problems, and that shaped everything about how the two days went.

Choosing the tools was the first design decision

Before any of the teaching was designed, there was a choice to make about what they would build with. The two days were fixed. The tools were not.

I could have picked a pure prompting tool. Describe your app in a sentence, watch it appear. Faster to a result, and considerably more impressive in the room.

I chose Softr and Airtable instead, because they force you to build the database yourself.

That is slower. It is also the entire point. A prompting tool hands you a product. It does not hand you an understanding of why the product works, and it leaves you helpless the moment something breaks. These were managers and founders who would go back to their organisations and have to defend, extend and question what they had built. They needed the thinking, not the artefact.

The second decision was less obvious. Softr has its own built-in database, which borrows Airtable's design closely enough that we could have skipped Airtable altogether and saved several hours.

I kept it anyway. Airtable is used across a large number of companies, and a participant who leaves knowing only Softr has learned a product. A participant who leaves knowing Airtable has learned something they will meet again on Monday, in a colleague's workspace, in a tool their team already runs. Teaching the dependency-free version would have been cleaner for the bootcamp and less useful for their careers.

Two days imposes its own pedagogy

A short format is not a long format compressed. It is a different design problem, and it comes with constraints that decide the shape of everything else.

Attention is the scarce resource, not time

An adult in a classroom can absorb roughly twenty minutes of new abstraction before the returns collapse. That is not a claim about motivation. These were curious, senior people who wanted to be there. It is a claim about working memory, which fills up regardless of how badly you want it not to.

So no block of theory ran long. Each module opened with me building the thing live, on the practice case, while they watched. Then they built the same step themselves. Watch, then do, in the same hour, on the same object. The theory was never delivered as theory. It arrived as an explanation of something they were about to attempt.

Nothing can be taught twice, so everything must be reused

With two days, there is no room for revision. There is no second pass, no recap week, no homework that consolidates what Tuesday covered.

The answer was to make every exercise produce an artefact that the next exercise needs. The persona sheet written in the morning is what you consult when you name a button in the afternoon. The five-step flow decides which tables you are allowed to build. The prompt card governs every request you make of the model for the rest of the bootcamp.

This is not tidiness. It is what makes revision unnecessary. You cannot forget the persona, because you cannot proceed without it. The curriculum revisits itself, and the participant never notices they are revising.

Constraints must be brutal, because judgement takes years

An experienced product manager knows when a flow needs six steps and when it needs three. That judgement is built over years, and it cannot be transmitted in two days.

So it was replaced with rules. Five steps maximum. Three tables. One persona. If a field cannot be traced back to a step in the user flow, delete it. These rules are cruder than real judgement and occasionally produce a worse answer than an expert would give.

They also produce a working MVP by Thursday, which real judgement, absent, would not. A rule is what you give someone before they have the instinct that would let them break it.

The room teaches, if you let it

Six people from health, fintech, fashion and government sitting in the same room is a resource, and a short format cannot afford to waste it.

Several exercises ran in pairs. You wrote a persona, then read someone else's and told them whether the person felt real. You ran a market analysis, then compared it to a neighbour's in a different sector. This catches errors faster than I could catch them alone, and it catches a particular error I cannot catch at all: the persona that is secretly a description of yourself. A stranger spots that in ten seconds. The trainer, who does not know you, never spots it.

How the two days were designed

Day one was a guided build. I built one product live in front of them, end to end: a campaign-management tool for Léa, a fictional 32-year-old agency owner drowning in scattered spreadsheets. They watched each step, then rebuilt it themselves on a case they had chosen: something they liked, something they wanted to try.

Deliberately, that case was not their real MVP. Day one was for exploring the tools and the method without the jury in the back of anyone's mind. Learning a relational database while your competition entry depends on getting it right is a poor way to learn a relational database. Every exercise still fed directly into what they would do the next day, because the method was the thing being learned, and the method transfers.

AI fundamentals, then a persona sheet. A five-step critical user flow, then a prompt card. An Airtable backend, then a Softr interface. Landing page and GDPR register last.

Day two was where their own project arrived. Same pipeline, this time on the thing they actually cared about, alone, against the clock. I moved into what I called hotline mode: circulating, unblocking, keeping people moving.

Three rules held the whole thing together

1. Every exercise produces an artefact, not a note. Even in practice, you finish with something concrete: a persona sheet, a flow, a live URL.
2. AI outputs are first drafts. You are the editor. The model proposes, you decide.
3. The landing page comes last. You can only promise what the product actually delivers, and you do not know that until it exists.

The steepest part was not the AI

Prompting clicked quickly. Give people a structure like Role, Context, Constraints, Format and they have it within one exercise, because it maps onto how they already brief a colleague.

Softr clicked too. Drag, drop, connect, publish.

The database was where the day slowed down.

Tables, fields, linked records, dependencies. What is an entity, what is an attribute, what belongs where, what relates to what. Relational modelling is a genuinely difficult abstraction, and no-code platforms quietly assume you arrive already holding it. They are honest about removing the code. They are silent about the fact that the hardest thinking in software was never the code.

This is a demanding skill in its own right, one that computer science students spend a term on, and these were people meeting it for the first time on a Tuesday morning while also learning three tools and a prompting framework. They handled it well. It was simply the steepest thing in the room, and it was steepest for everyone.

It is also worth saying that this difficulty was chosen. A prompting tool would have carried them past it without a pause, and they would have finished the day with a working app and no idea what sat underneath it. The wall was the curriculum.

What I did about it

I did not redesign anything mid-course. The programme was built for exactly this constraint and it held. But in the room, when someone stalled on their schema, the intervention was always the same three moves.

Look at the screen

Not from across the room. Up close, at what is actually there. A schema problem cannot be diagnosed from a description of it, because the description is usually the problem. People tell you what they meant to build. The screen tells you what they built.

Ask, do not tell

What does step three of your flow actually need to know? Where does that piece of information live? If you delete this field, does anything break? The alignment rule from day one was: trace every table and every field back to a step in your user flow, and if you cannot, it does not belong in your MVP. Most schema problems dissolve when you apply it honestly.

Send them to the model, but only once they can articulate the need

An LLM will design an Airtable schema in seconds. It will also over-engineer it, because it optimises for completeness rather than for what your demo needs on Thursday. The prompt only works if you already know what you are asking for. Which means the thinking has to happen first, and the tool comes second.

That third move is the whole lesson of the bootcamp compressed into one interaction. AI raises the return on thinking clearly. The thinking still has to happen.

What was actually hard: time

Two days is brutal for this. Absorb the theory, apply it to a real project, and produce something a jury can look at. Day one they learn. Day two they build, alone, against the clock.

The pressure was the point, and it also cost something. Scope discipline is easy to teach and hard to hold when you are tired and the deadline is at 17:15. The five-step rule and the lean schema exist to give people something to hold onto under time pressure, and they did their job.

But I will say plainly: what came out of day two was a rough MVP, not a product. It was never going to be more than that. Foundations and an introduction, which is exactly what the handover required.

The handover

Because LSE Generate owned business model, validation and pitch on days three and four, I had to be ruthless about how much business content I kept. Market research, persona, value proposition: enough to make the product decisions defensible, and no more. Everything else was theirs.

Designing a programme that ends in a handover is a different discipline from designing one that ends in a conclusion. You are building toward a clean interface with someone else's work, which means knowing precisely what you are responsible for and, more importantly, what you are not.

What I took away