Sue's blog

The proofs are in the pudding

2026-07-20T00:00:00Z

I’ve been making myself describe the project I’m working on so that I can get input on some design decisions. I stumbled on a timely LinkedIn post about how Claude Code works. It touches on static analysis, something I’m having to learn a wee bit about for my project. The post is focused on claims of machine understanding – I’m not particularly interested in those kinds of conversation as I don’t see the value. However the detail might speak to the limitations of LLMs in practice, which I do care about because it affects the power of this technology to undermine labour. But I digress.

Seeing the wood and the trees

In my project, I need to make a series of trade-offs in processing the content of a codebase. The project is aimed at helping people understand how a software system works, using a combination of direct analysis and language model queries. It’s something I’ve wanted to build for a long time, but the arrival of LLMs makes it more feasible, and makes a more comprehensive solution possible with minimal investment – not by generating code, but by integrating language models programmatically to support user understanding.

I'm building this because what concerns me most about LLMs is the reduction in code comprehension we're watching unfold. More software in the world and fewer people who understand it is a prospect that alarms me, because understanding how systems work enables us to influence them.

A very weird database query

Deciding where to insert the LLM call, what information to pass it – and therefore what to carry out before querying it – is turning out to be the bulk of the work. I’m doing a bit of static analysis in the application itself, passing the output of that to the model, then doing more processing on the response. Defining the bounds of the functionality I author in the app means specifying the interface with the model. I'm having to think about which signifiers in a codebase are most informative.

I could keep building more and more processing into the analysis to improve the quality of the info I send the model, but there’s a point at which it’s not worth the additional coding or execution resources. What I’m after is a first pass at some information that I’m going to build into further anlaysis, and update as more information becomes available. There is no one correct answer to the query, and no real benchmark or baseline to check it against.

I need to strike a balance between the robustness of deterministic processing on the static / dynamic analysis with the unreliable but semantically helpful language model input. The LLM is helping in two ways:

Identifying key location candidates based on pattern matching from so many codebases in the training data

Providing natural language explanations of the code points

That'll do prompt

In software we often face this tension between robustness and effort (both human and machine). Platforms that are successful don’t win because they prioritise an exhaustive solution, they win primarily on account of what they enable people to do – by solving a real problem and presenting an interface people can use. Many of the products that have achieved mass adoption hide unsophisticated, inefficient implementations under the hood, but they’re available and usable.

Criticism of AI platform implementation is academic as long as the results are good enough in practice, in context. It doesn't really matter how many research papers prove something isn't what it's claimed to be, what matters is what plays out in practice – these insights can inform that, but they don't change outcomes when more powerful dynamics are at play.

I'm highly sceptical about LLMs being able to generate anything of signficiant complexity without engineering knowhow, but there are places where a guess based on training data is good enough to complete a task.

What level of fidelity is good enough depends entirely on context. None of us are paying attention to all possible implementation details. Even if we’re not using LLMs, we’re mostly writing in high level programming languages, using dependencies and APIs to abstract away the detail we’ve decided not to pay attention to. Making solid judgements about what level of detail is suited to a particular task is the trick.

You can see a teeny tiny preview of some early progress on my project over at randan.dev.

What comes after view source?

2026-07-02T00:00:00Z

This week during the inaugural Write Through It we got onto the subject of View Source. Kin reflected on what the loss of this pathway means for opportunity and the web over on his blog, which got me thinking about it once again.

View Source was the ability to right-click on a web page and see its source code. It was a learning path many used to acquire developer skills. Its usefulness had already been compromised by changes in the way we build websites. First, processing shifted to the server side, rather than the client where those browser tools could provide illumination. Then, as front-end embraced generated static site frameworks, what the browser could see became the much more complicated scripted output of a build tool.

The ghost of view source still haunts us

Glitch tried to keep the spirit of View Source alive by exposing the functionality that powered websites using those server and generated front-end frameworks, but of course the web continued to grow in complexity.

A while back we got a smart telly in our house, which has an Android operating system running the apps for streaming services and the like. I had the fun challenge of trying to explain to my partner that he was interacting with the TV operating system and not the Netflix app one day as he was trying to search for a movie. I asked myself how I knew, and the only tangible signs I could point to were subtle UI indicators. It occurred to me that the experience of not being able to orient yourself in a technological context is getting increasingly common.

I might have called this platform cultivated context ambiguity over on mastodon lol.

The road was paved with APIs

For a long time I worked in and around APIs. My goal was helping people understand how we combine these lego block components into a cohesive user experience. APIs and dependency ecosystems paved the way to the web we find ourselves with today. They are also a huge part of what makes AI agents able to be a thing.

These forms of abstraction have enabled automation that powered creative uses of data and processing on an incredible scale. As we watched this happen, we also saw it getting harder to understand how our systems worked, and harder to maintain reliability. Entire specialties in software grew out of the need to support all of this.

On top of the complexity-induced confusion, we’ve also witnessed a significant amount of intentional obfuscation. From platforms hiding their underlying algorithms, to gatekeeping developer culture promoting over-engineered implementations – making it increasingly challenging for new people to enter the field.

AI and obfuscation

What stresses me out the most about LLM code generation is exactly this. I don’t think the average developer would choose to deploy a solution they did not understand, but the economic conditions make it inevitable. We’ve leapt headlong into a situation where systems are in operation having had little to no inspection of their implementation. For the companies selling this tooling and those investing in them, the prospect of undermining labour makes the loss of comprehension a feature and not a bug.

Since I started in tech, my career has been shaped by a compulsion to force the machines to illuminate themselves to human beings, often using interfaces that were extremely not designed to support that. As it happens language models are quite helpful for this. I’m working on tooling to aid codebase comprehension, not necessarily on a line by line basis, but at a different level of fidelity – I think that's necessary given the mountain of code we’re drowning in. It might not be View Source, but hopefully it’ll be something.

Being intentional about friction

2026-06-01T00:00:00Z

This time last year I was building paths for folk migrating apps away from Glitch. We were approaching the shutdown date and I needed alternatives for the Fastly onboarding projects I'd used as the foundation of the learning program I was leading – and that I’d candidly been hoping to integrate enough into product onboarding that the company would be persuaded to keep Glitch around. I also had a more personal need to figure out alternatives, as I'd relied on Glitch for teaching much longer than I'd been employed to work on it.

It's four years since Glitch was acquired by Fastly and therefore four years since I went to work there – I left last week. This isn't a dunk on my former employer, nor is it one of those our-incredible-journey things, just some reflections on what I learned during this particular part of mine, as I step into the next bit.

Why I needed a replacement

We’re finding out more than ever that removing friction doesn’t necessarily empower people when it comes to learning. One of the best things about Glitch was that it seemed to remove exactly the right kinds of friction, focusing the learner on the parts of making websites that resonated most with them. No dev environment setup or deployment barriers, just jumping straight into the functionality you wanted to craft.

It was a phenomenal asset for onboarding developers with a tool or framework. That’s what I used it for at a few different startups including Postman, and why I was able to embed it in various Fastly enablement processes. It let you get straight to the part where you figure out how to interact with a particular dev product, and form the mental models to do so effectively, in Fastly’s case integrating edge computing into your site.

None of this invalidates wanting to spin up a website with no intention of learning about the implementation, there's a reason WordPress has remained so popular for so long. Being able to choose which details are worth paying attention to is the trick.

Many platforms have taken inspiration from Glitch – building in the browser is much more common now, so is remixing from a template (a pattern hugely popularised by Scratch). In order to preserve some semblance of the easy flow I’d been able to create in Glitch, I built custom dev container configurations to create a kind-of-sort-of similar flow in GitHub Codespaces. It helped me not completely abandon the approach, but suffice it to say it wasn’t Glitch. It’s basically the VS Code editor in the browser, so the experience is overwhelming for new developers and there’s a pretty severe limit to how effectively you can mitigate that.

What has changed

The advent of LLMs and changes to the web itself make what Glitch was, in practical terms at least, no longer sensible. Letting anyone spin up a live website in seconds was both expensive from an infrastructure perspective and incredibly prone to abuse, and that was before AI agents. There were also abstractions that didn’t age quite so well. Not having to think about deployment was a blessing right up until it became a curse. The git rewind feature fared similarly. Starting from a small set of app templates seems quaint when you can use a prompt to generate anything you like – although there were advantages to that, and I suspect they partially explain why LLMs are not enabling creation the way some expected them to.

What we still need

As anyone familiar with creative tooling will tell you, starting from a blank slate isn’t always ideal when it comes to stimulating users. A blank chat box is no different. That's why learning platforms like Scratch focus so heavily on the remix pathway. What happens after you generate your starter project has a huge influence on whether or not you continue. What is in there really matters.

Removing barriers that kill momentum – without disadvantaging the learner later – is a balancing act that needs continually revisited.

I recently tried exporting a simple website from a vibe coding platform and found it a frustrating dead end, with zero in-project guidance and mystifying implementation choices. There was no feasible path forward that involved touching this code. Contrast that with the Glitch Hello apps – they were painstakingly designed to act as jumping off points for people learning a new framework. The preview, code comments, and project docs were all curated to guide the learner through first steps that set them up to keep going. You know, the kind of material LLMs are trained on.

The claim is that we don't need those jumping off points anymore, but without them, how will anyone learn to swim?

Anil described Glitch as a "yes code" platform, distinct from "no code" where the user was encouraged not to even look at the code generated. I think it’s safe to say that most LLM products aimed at people without prior experience fall firmly into the no code camp. There’s an assumption that no one needs to know about code anymore, I think that’s a mistake. We still need people to understand code in order to understand how systems built in software work, and to shape them reliably. So where are the "yes code" LLM platforms?

We need software building experiences that design friction with intention, being deliberate about what is abstracted away and what is left in the learner's path. What is exposed should be the details that equip the learner with whatever understanding serves their goals (or their organisation's). Balancing short and long term goals is, as always, where we find tension we'll want to manage effectively – if we're to leave the experience empowered, rather than dependent on automations we don't fully understand.

What doors have opened?

People who are being empowered through building with LLMs are overwhelmingly doing it in conjunction with support from others – being able to initialise a project only takes you so far. Claims that LLMs democratise access to the opportunities that come from making software are popular, but in reality that involves a lot more than generating code from a natural language prompt.

I believe LLMs give us a host of new paths for people learning to make software, but not through a chat window that separates you from coworkers and peers. We could do a lot more to build tooling around LLMs that would better support learning. Might be an idea to pay attention to the pedagogy eh.

I'm available for consulting work now btw.

Which direction is forward?

2026-05-19T00:00:00Z

There’s a role that appears to be exploding in popularity in AI adjacent companies right now: the Forward Deployed Engineer. Since I first heard about LLM assisted coding, aside from the very real enabling potential, I’ve worried that the outcome would be a future where fewer people understood how critical systems worked. I believe some of what we’re seeing with these jobs is a reflection of that.

Software companies have long had engineering roles embedded in the sales cycle. Sales engineers might build demos and proofs of concept pre-sales. Solutions engineers and architects set up bespoke configurations or integrations of a product for specific customers. Field engineers might support client implementations in their environments. Now we have these “forward deployed” engineers.

The role name comes from Palantir and is borrowed from military language (shoutout to @tante for informing me of this).

FDEs are the latest chapter in tech industry manipulation of the procurement and compliance process for contracting with large organisations such as government / public sector bodies. AI appears to be fueling the adoption of this pattern in software companies that would historically have practiced product-led growth. This post is an exploration of what's changing from the perspective of building in that kind of environment.

Services vs scale

If you’ve worked at a SaaS (Software as a Service) company, you’ll likely be aware that conflict often arises in deciding what to build. In theory product management leads the decision, in collaboration with engineering, with input from sales / customer engagement. In practice it’s usually more complicated.

When your product is software, integrating it into a customer’s system can involve building additional software to support the integration. This is something a solutions engineer might do. If your solutions folk are constantly building the same stuff to get your product in place for customers, it might make sense to incorporate what they’re building into the product itself. That way the same solution benefits your other customers, making it easier (and cheaper) to onboard new customers.

The golden rule for SaaS companies was to build for scale. If you depend too heavily on professional services (what those solutions engineers do), growing your customer base means hiring more and more people to service it. The more you can automate by supporting common customer use cases through the product itself, the more easily you can scale to support a steeper growth trajectory.

What is the product anyway

So far so good, but what one customer needs might not actually be what others need, in fact there can be many reasons not to incorporate a solution into your core product. This is where product management comes in. PMs determine what to include in the roadmap, what the future of the product should be – in doing that they define the bounds of the product, where its edges are. What falls within its bounds is the software you commit to making available at scale, and maintaining over the longer term.

Product managers liaise with engineering and other teams to determine what is feasible and in the interests of the company’s overall plan. With these constraints in mind, the short and long term goals of the company theoretically determine whether or not those customer integrations become part of the product itself.

When we build this way, it becomes important for a significant portion of the people who work at a company to understand something about what the product does, in order to carry out their own duties. Internal communication about the product therefore becomes a priority.

Who's driving the bus

When those sales-situated engineering roles are clearly defined, it creates a dialogue with customers that makes the product more likely to be successful. In practice it often creates pressure on the relationships between teams. If a customer is a big enough deal for the company, their input can effectively hijack the product process and force prioritisation that benefits them, more than it does your future as the vendor.

Compensation structures are part of this story too. Where product engineers are typically paid in salary and perhaps bonuses / stock, engineers who work in sales are paid partly in commission. The incentivisation difference creates divergent views of what success looks like.

Sometimes these teams are effectively disconnected from the product process, deploying whatever specific customers need – your software ends up a hundred different things to a hundred different customers, and congrats, you've accidentally become a dev shop instead of a product company. Shifting control away from product management can also reduce visibility into what is actually being delivered.

It used to be that the lack of scalability curbed dependence on this kind of service-based delivery, certainly for startups if not large incumbent corporations – but there's a belief that AI removes that constraint. Whether that's realistic or not, there’s a push to get this tech embedded inside organisations by any means necessary, so that the need to demonstrate value – and justify the inevitable price hikes that follow deep subsidisation – become redundant, leaving behind implementations that are problematic to remove.

Who's being escorted out of the room

The rise of these roles is accompanied by an increasing trend in AI-excused layoffs, citing “flattening” management structures as the goal. Companies are laying off middle managers, many of them in product, and telling an unconvincing tale that AI is automating what they did.

If this was about building products to better suit real world use cases, I don't believe we'd be using these distinct job titles, or getting rid of managers en masse.

Developers often hate on management, but the role being sidelined has wider consequences. Part of what product managers do is make intention legible to the company. They frame a product in terms of vision and value, helping teams around the company to understand what is getting built. By putting customer-embedded engineers in a position to decide what gets built instead, employees lose both visibility into what they are shipping, and opportunities to influence it collectively.

Reducing worker understanding of what is being built is a long established labour-crushing tactic. Losing the ability to understand what your company is shipping means losing paths through which we might mitigate the harms our software causes.

An added bonus for companies using AI-generated solutions: employees working directly with customers enjoy leverage that makes them problematic to remove, but if the solution a customer relationship depends on isn't even understood by the engineer who built it, that problem goes away too.

Finding leverage

Couple all of this with the deployment of LLMs to generate code in a way that obfuscates understanding of it, and you can see where we’re headed. A world where it's harder to understand systems that affect us. This is why I’m focusing on helping people to understand codebases, and building tooling for that purpose. LLMs can actually aid that understanding – they are being weaponised with clear intention to undermine it.

The primary push for LLM code generation is part of an attempt at deskilling software engineers, but I don't believe it will work. I think it's based on a misunderstanding of what LLMs can do, and what software engineering is. More code in the world is going to mean leverage for people who can understand and change it, we should be ready to take advantage of that.

Pedagogy is the way

2026-05-11T00:00:00Z

It’s three years since I first wrote about AI assisted coding. You can still read that post on the Glitch blog: Software development isn't writing syntax

A lot has happened since then, but as I said in a weirdly popular LinkedIn post recently, my beliefs have proven pretty resilient – tl;dr:

LLMs make it easier to avoid learning, but also create new opportunities to learn.
LLMs enable more people to make simple apps, but complex systems still require developer skills.
Acquiring developer skills still involves learning to code.
LLMs open new entry paths for acquiring dev skills, especially with support from existing developers.
The productivity gains of LLM coding are exaggerated, and reduced or reversed with overreliance.
LLM code generation is not very useful on niche or novel problems.

Of course things can still change, and I remain open to reassessing my views, but I believe the consistency in my position is more than a coincidence – these were educated guesses based on years of being immersed in coding pedagogy and the dynamics of software teams. To be frank, as daft as it may sound, I feel like everything I’ve learned over the last 30 years in the workplace has led to this understanding.

What is a skill worth?

I learned software development in my late twenties, on a course I took in an attempt to escape a decade of low paid jobs. It turned out I was quite good at writing code, but it infuriated me that it had taken so long to find that out. I wanted more people to access the shift in economic opportunity I’d had. So I focused on developer education, first by teaching on the course I’d taken, then in industry for developer platforms.

Specialising in education stopped me getting too attached to specific technologies. I don’t identify with ways of making software, I'm more interested in which skills will help people be successful. I lamented how much harder new frameworks made it for folk to learn how to build the web, but if those skills were what employers wanted, I had to embrace teaching them.

It made me approach technologies non-judgementally. For me they are mostly a means to an end, the end being the income and influence the life of a working software engineer affords you. That doesn't mean I ignore the harms technologies can cause, of which there are many – it's a trade-off that responsible advocacy requires continually revisiting.

None of this is to say I don’t respect the craft and creativity in coding, but the stakes are a little different when acquiring a skill might help someone lift their entire family out of poverty.

Who gets to benefit?

I’ve railed against the privilege and gatekeeping in software engineering, but having worked to get more people into these jobs, I can’t root against software engineers either, or rejoice in them being disenfranchised by what's happening. I tried to help a wider representation of people to become part of that cohort, so I can’t be against that cohort now. As it happens, I think AI is going to create more demand for software engineers, not less, once employers stop pretending it makes them surplus to requirements.

Learn about learning, seriously

Of course the tech industry never took education seriously, even through the era of developer relations. I’ve beaten my head against the wall trying to get companies to see the impact of education on the business metrics they care about. I content myself with the memory of leaders who took it on board and cultivated learning practices within their own teams. I saw more culture change than I probably should have expected.

Now we arrive at a place where the ability to generate code poses a threat to developer jobs and identities. The last few years have been characterised by ludicrous predictions about whole categories of work being rendered obsolete. As many of us have learned the hard way, organisational change takes a wee bit longer than that. It’s been extraordinarily hard to have sensible conversations about any of this because it’s been sold in such bad faith.

But what I’ve learned about learning seems to be steering me well, and you can also learn it. There is a wealth of publicly shared knowledge on the subject. I never tire of pointing folk at the phenomenal work the Raspberry Pi Foundation do with coding pedagogy.

Choosing what to learn

I strongly believe that communities and organisations will set themselves up not only to survive what comes next, but to thrive, if they can embrace the culture and practice of learning. There are so many ways to create better outcomes in your own environment just by supporting shared learning.

The teaching standards on my software development course were actually really good, but at that time there was a complacency about the dreadful drop-out rates on CS courses, as if it was an unavoidable natural disaster. We know a lot more now than we did then about how people learn coding skills. LLMs also give us more freedom to choose what and when we learn. If we want this technology to empower rather than exploit, we could reframe it as enabling us to choose what is worth learning in the interests of our shared goals.

I ended my first post on this subject with a prompt:

As it becomes harder to say what is and isn’t software development, maybe it becomes more interesting to ask other questions. For example, what does a tool enable people to do, what are the opportunities, and what are the risks of harm?

It's been distressing to see some of the risks of harm become real in the time since I posted this. I think engaging with the question might be more valuable than ever.

🚌 If your organisation needs help embracing the power of pedagogy, give me a shout.

On convenience and understanding

2026-05-07T00:00:00Z

"There is some compulsion in software where automation breeds more automation and we accidentally leap over the phase where it was actually optimal for both usefulness and understanding." Me, on mastodon the other day

Being able to generate code is forcing us to figure out when it’s a good idea to actually write it.

Recently I’ve found myself making a few small static websites, and I’ve come face to face with this choice, although not regarding LLMs. The last decade or so saw the growth of generated static site frameworks. These let you create websites without hand coding every bit of HTML. They’re handy for reusing layouts in your pages, and giving you a single point of change if you decide to redesign your site. However, it’s a lot harder to understand what’s going on under the hood, and harder to set up than what we did before – write HTML in a text editor and upload the files to a server.

A few years back I decided to brush up on my frontend skills, having been focused on server side development for several years. During that time, generated static site frameworks had exploded. I discovered I had to set up a dev environment, and go through a build and deploy process, just to get a simple website online. I was like wtf are we doing here. It had become a lot harder to teach people how to get started making websites.

To automate, or not

Naturally I am biased, but Glitch did a great job of keeping the door open to new developers by abstracting some of this away. Setting up dev environments is understanding I frankly wish I'd never had to develop. It's not relevant to the goals I care about – usually those relate to the content and functionality of a site I'm working on. I want to comprehend the logic in the code that gets deployed to the web, not so interested in deployment pipelines and the like. Having used Glitch to teach people who'd never written code before, I can say the balance of automation and understanding was a pretty good match for what they cared about.

As I approached making those simple websites recently, I realised it would be handy to be able to reuse layouts, but certainly didn’t need the power of a full static site framework. So I decided to write some small scripts to use templating libraries, so that I could generate my pages locally and just dump them online. It felt like I was seeking some lost stage of automation we skipped over but that was optimal for my purposes, before our automations obfuscated the bejesus out of everything.

When you learn how to automate making things with code, it can become a habit you jump to instinctively. We automate one thing and immediately leap to automating more and more of the same process. But each automation comes at the cost of understanding. Too often we’ve taken things far enough to sacrifice understanding in ways that created new problems – for learners, for teams, even for ourselves when we looked back at projects we’d previously worked on.

We're here again

Choosing when and how to leverage LLMs to generate code is subject to the same balancing act. This automation gives us the opportunity to opt out of understanding that is not relevant to our goals. But how do we know when it is worth prioritising understanding? Well it’s difficult to make that call in the moment, because typically we find out we’ve got it wrong later. For that reason I’d recommend a regular practice of revisiting your comprehension of the projects you work on. If you feel you’re losing your sense of wtf is going on in a way that is relevant to your goals, take a step back and course correct.

How should we teach software development now?

2026-04-30T00:00:00Z

Yesterday I posted on LinkedIn about realising I've been thinking and writing about AI-assisted coding for three years now, and that overwhelmingly I still stand by the positions I've taken. My first public post on the subject was in May 2023, so I'm going to revisit it on the same day this year. But for now, since the discussion touched on what we should be teaching on software engineering courses, it prompted me to jot down my current thinking, still very much WIP but here you go.

⚠️ Note that this is squarely focused on courses where the goal is to learn the skills in being a working software developer. Many other courses involve writing code as a technique in service of some other goal – strategies will vary enormously there, as the potential to lean more heavily on LLMs to generate code increases on small scale, low complexity apps. The skills I'm focused on here are for preparing to work on the kind of complex systems teams of software engineers collaborate on.

I thoroughly recommend restricting reliance on LLMs when teaching programming fundamentals. It's unrealistic to expect to eliminate it, but as far as possible I'd get students up to speed with the basics the "old fashioned" way, by writing their code manually.
I would also look to the humanities, where educators are using LLMs to generate content, then having the students engage in critical thinking about the output. Raspberry Pi Foundation have shared resources for similar, covering topics like anthropomorphism.

These first two are essentially focused on harm reduction regarding the negative consequences of LLMs being available. That's unfortunate but necessary at this stage.

Explore using LLMs to aid activities such as debugging and code comprehension. We're going to need a heavier focus on code reading skills when lots more code is being generated, and I'm cautiously optimistic we'll see the rise of better tooling to support these practices. Similarly, with the explosion in outages and incidents, I have to assume performance and security topics are going to be more central to the working life of a developer.
I think there's tremendous potential to use LLMs to generate practice exercises dynamically. Mostly I see anecdotal accounts of people doing this, but again I'm hopeful we'll have dedicated tooling to enable it. Having an LLM generate a broken project the learner has to fix is an idea I'd like to experiment with.
In terms of developing with LLMs, this is where I'm more hesitant. I'm thinking writing specifications, LLM scaffolding etc (the many and varied markdown files involved in effective deployment of this stuff). I would tend to treat this as an advanced topic, second to e.g. learning a foundation in programming with one or two existing languages. It might seem frustrating to not be leveraging recent technology straight away, but I storngly believe an upfront investment in these foundational skills will pay off in the long run. It's also difficult to establish good practice for building this way as it's so recent, and the volatility of the platforms makes these skills incredibly hard to pin down with any reliability.

In industry settings, the overarching advice I'd give is to build a culture of learning in your organisation. That is of course not a trivial task, but a good start would be encouraging tactics like peer learning, pair programming, and mentorship – these are going to be more valuable and essential than ever.

I am a broken record on this but Raspberry Pi Foundation publish phenomenal resources on teaching programming in the context of AI:

AI pedagogy quick reads
Experience AI
The Hello World magazine which has tons of example lessons

I am extremely interested in hearing other perspectives on teaching with this stuff!

Automation is a trade-off

2026-04-28T00:00:00Z

This post was originally published on dev.to.

A couple of years ago I wrote a post about abstractions. I’m revisiting it here with AI-assisted coding in mind, because I see similar issues arising. LLMs make it easier than ever to generate code, but when we look at what happens next, the picture becomes a little bit less clear.

When you build an abstraction or automation intended for use by other people, you make a decision about what is valuable for them to know about, and what isn’t. In programming this is extraordinarily hard. Often we accidentally hide information it turns out the user needs or wants to know about. And it can change over time, because in software, context has a huge influence over how and what we build.

The world of APIs grew from the power of being able to import code written by others – we were able to focus on the unique aspects of our own problems / solutions. But choosing to use a dependency has consequences we didn’t always take seriously. It’s a trade-off I wish we were having more explicit conversations about with AI.

⚠️ I should note that I don’t view LLM prompts as programming abstractions but as code generation automations, for reasons I’ve been exploring in recent talks.

Progressive Disclosure?

One approach to managing the trade-off is to provide a kind of escape hatch where you can see and configure the underlying implementation if you want, or ignore it if you don’t need to know what’s going on under there.

Here’s where I get skeptical about vibe coding platforms positioning themselves as empowering. I won’t name the company, but I recently tried generating a simple static website from a service aimed at people without prior coding skills. I exported the app to VS Code. The implementation was ludicrously over-engineered, with a ton of TypeScript files and zero documentation. Not a code comment, not a README, nothing. The output was effectively obfuscated. Even as an experienced developer I would have had an extremely hard time working with this codebase.

Perhaps you’re wondering if this is an edge case, assuming these codebases don’t need to be worked on directly. I pay close attention to accounts from people using these services and that's not what I'm finding. Overwhelmingly they get you to a prototype, but in order to take your app to the next level you do need to engage with the code. Even the platforms themselves have subtly shifted their messaging to reflect this.

The interface is not the LLM

The platforms I'm referring to here are a little different from e.g. using an assistant or agent in your IDE. The underlying prompts and LLM scaffolding are partly or wholly hidden from the user. They could easily instruct the model to prefer human-readable implementations and provide ample documentation – to produce programs that are optimized for the user to learn from, and that act as a foundation to build on. That would be empowering.

Here’s another awkward piece of the puzzle. In order to ask the model for such an enabling starting point, you already need to know something about how software is built. So that precludes anyone without prior development experience.

Let’s talk about the trade-offs

Here are some considerations I think are valuable when it comes to either designing or using an automation for code generation:

What details are being hidden from the user?
What decisions are being made about the implementation?
- Are the decisions accidental or deliberate, what is driving them?
How can these decisions be changed?

Importantly:

What might the user need to know later that they don’t know now?

Taking a moment to answer these questions might help us make better choices about the abstractions we build, and those we choose to adopt.

What does empowerment look like?

Sometimes I imagine a platform like Glitch, but that generates apps from a prompt, while prioritizing ease of extension and subsequent learning – what the Glitch Hello apps were meticulously designed to do. Such a thing is absolutely feasible, at least technically. But the reality is that software company decisions are determined by economic dynamics. They are incentivized to prioritize engagement over enablement – in many cases what this looks like is platform lock-in.

I do see people being enabled to build software using LLMs, usually with the support of other human beings in their workplaces or communities. There is tremendous potential for opening the gateway to developer skills with this technology, but it won’t happen by accident, and we should scrutinize claims of empowerment that don’t check out when we scratch the surface.

What does accountability look like?

There’s a parallel problem even professional developers are experiencing, as AI-generated code is harder to work with, increasing the maintenance burden over time. Using LLMs to generate code is reducing our ability to build strong mental models of our codebases. Again, I don’t believe this has to be the case, we could use these automations while still preserving agency and understanding.

For working developers, the question of accountability plays a huge role here. When things go wrong, who is held responsible, and what are the consequences? Understanding what you’re committing to a codebase has implications I don’t believe we’ve fully reckoned with yet.

We can shape this

As we begin to discover the longer term consequences of using LLMs to generate code, I would love to see more honest conversations about what is truly involved in enabling people over both the short and long term. Because we can build for that if we want to.

What to do about developer skills

2026-04-24T00:00:00Z

I've been giving talks about developer learning and AI-assisted coding pretty regularly over the last couple of months. Doing this is helping me clarify my own thoughts and better position me to advise others, based on what I've learned about software engineering and pedagogy over the years. This week I had the pleasure of speaking at Haggis Ruby in Glasgow, with a community I wasn't part of but who could not have been more welcoming and open to what I was saying. ❤️

It was lovely and very weird to be at a dev event with a mix of folk from various places in Glasgow. I'm so used to that being an experience I have away from home that it felt odd in a good way. I love Glasgow a lot so it makes me extremely happy to see so many more people experiencing the city these days, and in many cases choosing to stay. A mere ten minute train ride to get to the event was nice too.

Here's my deck: Developer skills worth learning when AI can write code

There is no one answer to this

Here's the thing, I'm sure there are consultancy firms sending folk into workplaces all over the world right now and giving them identical advice on what they need to do to get ready for this new world of AI writing code. Yeah, I don't think that's how this works. Aside from the fact that anyone claiming to know with certainty what is going to happen is either delusional or lying, approaching this strategically can really only be done in context. It's something we're all going to need to figure out collectively.

Can we start being sensible about this yet?

At the start of my talk I show this daft slide and wait for a few moments, watching how people react. I've had a bit of variation lol, but when I follow it up with "I'm not sure how much time you spend on LinkedIn" people typically laugh and let out a small sigh of relief.

My hope is that as the dust settles and we see more of the fallout from the initial waves of adoption (and frequently overreliance) on LLMs to generate code, we'll be able to find the space to start having more constructive conversations about the real utility and impact of this tooling. Perhaps I am an optimist after all.

OK maybe there is one answer

I lied, I think there is one answer I'd give to people asking what to do about developer skills right now. Create the conditions for shared learning within your organisation. Yeah it's a bit abstract, but I strongly believe that the companies and communities who can cultivate peer learning will set themselves up to succeed with this new way of making software.

I have a lot more to think and say about this, and shall do that right here on this blog, which you can subscribe to via the RSS feed.

When is a tool the right tool for the job?

2026-03-27T00:00:00Z

This week I spent time with a group of leaders in research software engineering at a workshop on the implications of using LLMs in their work. I gave a short lightning talk and shared a position paper representing my current thinking on AI assisted coding.

My position

Here's the position paper I shared prior to the workshop:

I specialise in creating learning experiences to help people acquire developer skills. I’ve mostly worked in software industry settings, such as developer community platforms that enable people to make web apps. My perspective on AI-assisted coding is very mixed. On the one hand I can’t deny the enabling potential of a technology that helps people build software solutions without engineering skills, and on the other I’m concerned about a loss of understanding around software implementation, together with a decreasing investment in those skills.

I’m not an expert in research engineering at all, so my perspective is entirely based on what I’m seeing in industry. The panic around jobs potentially being made obsolete is making it incredibly difficult for us to take the time necessary to explore the true potential and limitations of this new technology. There is undeniable utility here, but the costs for adoption are still largely unknown, in terms of individual and organisational success over the long term.

What preoccupies me most as an educator is the “comprehension debt” or “cognitive debt” that appears to accompany AI-assisted coding. We’re seeing a widening gap between entry level and experienced software engineers. It’s not clear how we’ll create paths for those early in their careers to acquire the skills experienced developers are using to get the most effective use from LLMs, and that they acquired the “old fashioned” way, by writing code.

There’s a parallel gap at the systems level, as we lose the ability to build solid mental models of the systems we’re using LLMs to generate. In software worked on collaboratively by teams, this is a more significant problem, as the source code exists, not just to provide instructions for a computer, but also acts as a shared human-readable representation of the system, a place where we come together to reason about how it works – the code performs a function natural language is not suited to.

When it comes to comprehension, we’ll need to learn how to decide when LLMs are the right tool for the job, and when they aren’t. This will be determined by what level of fidelity about a system is the optimal one to work at, in order to meet individual and shared goals – balancing those over the short and long term is going to be both challenging and essential.

My lightning talk deck is available here too

The workshop

I have to say it was a luxury to be in a room with people who are thinking deeply about AI code generation and how we can prepare for its impact. I've found very few spaces where I can have these conversations and begin to grapple with the detail of this new automation, both in terms of opportunities and risks of harm.

It was also fanstastic to be able to sit at a table of educators who are on the front line teaching people the skills they believe will serve their individual and shared goals – that is not an easy task, especially right now!

The tension I keep coming back to is that language models could enable programming learning, but the platform interaction patterns are not optimised for it – if anything they're designed to avoid learning, as they're funded on the belief that AI removes the need for human beings to do certain categories of software work. I do believe this will change, as incidents continue to rise, organisations will discover the need for their teams to understand codebases with a new urgency.

I learned a ton this week, I have a ludicrous number of tabs open in my browser for reading lol. I left the experience more motivated than ever to experiment with ways to enable learning in this new way of making software.