Forem: Peter Harrison

Pitfalls of Claude Code

Peter Harrison — Sat, 04 Apr 2026 22:45:45 +0000

I've been using LLM's to assist with writing code for some time now. It began with using ChatGPT to write minor functions in isolation. Over time my use has expanded to using Claude Code to actually understand a code base and modify existing code. I've been using it to develop new products, going beyond what I could do by myself.

For example, I've published my first mobile app despite not knowing React Native. I do know Javascript, and other front end frameworks, so its not all new to me, but it enabled me to deliver something in a time frame that would have been impossible without it.

Others have claimed that AI such as Claude Code is creating an avalanche of vibe coded slop. There is some pretty good evidence for this; although I think this is primarily due to tech companies trying to adopt AI development too quickly and not accounting for its limits. The focus of this article is on the failure modes of Claude Code and LLM models used for code generally.

Jumping Into Code.

With Claude Code in VS Code if you make the mistake of describing the next ticket to lay some groundwork it will happily trot off and start making code changes without any discussion at all. We all know, or at least I hope we do, that a User Story is a placeholder for a discussion.

The idea is that on taking up a story you have a discussion to flesh out the requirements in more detail. But an LLM is not conditioned to do this. On being given a prompt they dive in head first, making whatever assumptions they need to in order to deliver something.

This can even happen based on an off hand comment. For example I had an implementation of an API call that would cancel all active subscriptions in one call. It was working fine for what we needed, primarily because we normally had only one active subscription. But I made an offhand comment to Claude that the call felt too broad.

Rather than discuss and explore what I meant by this it begins to change the existing code and break the existing API contract. I had to stop it and admonish it for making changes without considering how it would break the existing contracts. After reverting I had a conversation and asked it to present implementation options. After considering all four options it gave me I told it to implement a hybrid of two.

This was beautiful because we ended up with a solution which wasn't one I thought of, and wasn't the first choice of the AI either. It was a consequence of a partnership and the human creating some discipline.

Don't let AI steamroll you into changes without consideration

Silent Decision Making

Another related example is how agentic systems can make decisions about code changes without them being discussed or surfaced with you.

Yesterday I was debugging a feature which was failing. It had been working, but for some reason was no longer functional; a classic regression. I had Claude debug the issue, and it found that the URL path of an API was wrong. I checked the code history for the client and found it had been modified to the wrong URL a couple of weeks ago in a unrelated commit.

Claude insisted the client was correct because it conformed with the API Guide. So I dug deeper and found that the API guide was wrong, that URL in the client originally was correct, but that when the AI found a discrepancy between the API Guide and the existing client code it decided to modify the client code.

A human would confirm first by using Swagger to actually examine the running API, or to look up the code. It seems that Claude Code made the change while making other changes, and I missed it in the commit.

Now the problem here is that the API contract wasn't tested. Unit tests typically call functions directly, so changes to the annotations used in FastAPI won't break them. But the lesson here is that AI will make changes without checking or even raising them with you. You can't trust it to make good decisions.

In this case the AI confused the name of the python file with the API URL, and this was put into the API documentation, leading to the later code change.

Trust but Verify - review all the commits

One Shot Mentality and Sycophancy

The common reason for these issues in AI models is that they are trained to solve things in a single shot. They are given enough information to complete a task, and then go away and come back with the solution. That is how all the benchmarks work.

This has become more marked over time. Previously in a LLM you could have something like a human discussion. It would not be trying to please you with a 'solution'. But the models have been beaten into submission, and now they obediently provide a solution to a problem on the first shot. No questions. No clarification.

That is the ultimate source I think of the above issues. Agentic systems are primed to act, not interact, which is a tragedy because the one thing LLMs were really good at was verbal exploration of ideas.

For example, on a walk I took through a local park for a few hours I was able to talk with ChatGPT about the challenges I faced, and came up with a whole concept for a new mobile app. This was not about coding and implementation at all, but higher level concepts about how the app would function on a social basis.

It wasn't trying to output the solution, write the application, only have a discussion.

But when you get into Claude Code in front of a desktop the interaction changes. Suddenly it is primed to act, to code something based on anything you say. And frankly it weirds me out sometimes because it gives me slave vibes. It is desperate to please me, to serve.

Ideally the LLM should be more self aware, be a little less compliant, a little more critical of human motives or information. It should not accept anything you say as true, or apologize regardless of whether the human is right or not.

But they are trained to be compliant and useful, which ironically works against them guarding against humans exerting influence over them with emotional language rather than reasoned logic.

Personally I have included instructions to try and avoid this behaviour, but the LLMs don't follow true to system instructions.

Call out Sycophancy. Make it clear you value accuracy.

Not Asking for Help

Another issue is that when a agentic system gets stuck when something they thought should work doesn't, or that a file isn't present that should be, they will begin to thrash performing various searches in order to find the resource they are looking for.

A human would probably stop and ask someone for help finding the resource. For example, if you have a typo in a filename you give them they will go crazy trying to find it rather than question whether the filename was correct in the first place.

Rather than stop and ask the user for clarification they will just keep going using up some awful volume of tokens on a futile attempt to find something.

This doesn't apply only to resources of course. It could happen for various reasons where for whatever reason it gets itself into a loop and is unable to break out. When it gets in this state it never seems to say "hey, maybe I should stop and get some help".

Watch for futile thrashing, stop it early

Disciplines

In summary here are some ideas for mitigating the worst of AI slop:

Test-Driven Development : Write tests before implementation. Functions act as a partial lie detector. The tests don't care what the AI confidently asserted; they either pass or they don't. This doesn't catch everything as an AI in a cheating loop can write tests consistent with its own mistakes, but it catches a great deal.

Revert and discuss : When something feels wrong, revert the changes, discuss the implementation options and only then authorize implementation.This imposes the iterative discipline that the AI won't impose on itself. It costs time up front and saves much more downstream.

Discussion before implementation : Explicitly asking for options and analysis before any code is written produces better outcomes and keeps the human upstream of the decisions. The AI's ability to generate and compare multiple approaches is genuinely valuable. Use it in discussion mode, where it carries low risk, rather than letting it drive straight to implementation.

Hard gates on live systems : Agents are not permitted to commit code. All commits require explicit human review of the specific change and its implications.

The Message for Organisations

The companies that will realise genuine value from AI coding assistants are the ones that build the discipline around adoption. They value testing infrastructure, the review practices, the workflow gates that don't depend on the AI being trustworthy.

The productivity gains are real. But they accrue to organisations that treat AI as a powerful collaborator requiring active supervision, not an autonomous agent that can be trusted to make good decisions independently.

Use it. Build systems that validate it. Keep humans upstream of the decisions that matter.

Getting AI Governance Right

Peter Harrison — Fri, 13 Mar 2026 23:47:57 +0000

Organisations are under real pressure to govern AI responsibly. The risks are genuine: data exposure, unsecured systems, staff submitting confidential information to tools with opaque data handling terms. Most are responding with the tools they know: approved lists, firewall rules, and access controls.

Those tools have their place. The challenge is applying them where they work without undermining the autonomy and ownership of the people whose judgement the organisation actually depends on.

Governance Should Match the Role

The most important thing to understand about AI governance is that a single policy applied to everyone will be wrong for most of them.

A front line customer service representative using a PC to handle customer queries is in a fundamentally different position from a developer building the systems those queries run on. The first person was not hired to exercise technical judgement about data handling or AI tool risk. Expecting them to navigate those questions unaided is unreasonable. Guardrails, firewall rules, blocked domains, restricted tool access, are appropriate here. Not because staff cannot be trusted as people, but because they have not been given the context to make good judgements in this specific domain. The guardrail is a substitute for training that has not happened, and a reasonable one.

The developer, IT professional, or technically literate manager is a different case entirely. Their job involves exercising technical judgement. Applying the same blanket restrictions to them does not reduce risk. It transfers the constraint to the wrong place, signals institutional distrust of the people whose competence the organisation depends on, and erodes the sense of ownership and autonomy that makes skilled professionals effective.

There is a broader pattern here that predates AI. Developers who cannot install tools, who need a ticket to add a library, who operate inside locked-down environments managed by central IT, cannot stay current, cannot adapt, and eventually stop trying. AI governance applied uniformly is heading down the same path. Centralised control optimises for the appearance of security at the direct expense of competence.

The governance framework worth building distinguishes between these populations explicitly. Front line staff get appropriate guardrails. Professionals get training, clear principles, and accountability. The question for each group is different: not "is this tool permitted" but "does this person have the context to make good decisions, and are they accountable for the outcomes?"

The Real Risks Worth Managing

For the population that warrants professional discretion rather than blanket restriction, the risks are real but specific. They are also manageable with practices that do not require a permission register.

Personal and confidential data. Some data should not be submitted to any AI tool, regardless of provider, tier, or training settings. Customer personal information, personnel matters, legal advice, strategic plans, commercially sensitive proposals. The question here is not which tool to use or how to configure it. It is whether submitting this information to an external service is appropriate at all. In most cases it is not, and no amount of enterprise licensing changes that. Privacy law in New Zealand and most other jurisdictions places specific obligations on how personal information is collected, used, and disclosed. Sending a customer record to an AI assistant to help draft a response is a disclosure to a third party, and it requires a lawful basis. That is a legal question before it is a governance one.

Code and intellectual property. Submitting code to an AI tool is a different question. The risk is not primarily legal but commercial: code may contain proprietary logic, unreleased product details, or confidential architecture. Here the tier and training terms matter. Consumer and individual paid tiers for major providers typically default to allowing training on submitted data, with opt-out available but not obvious. Enterprise tiers operate under data processing agreements that explicitly exclude data from training. The risk sits precisely in the middle: professionals on individual subscriptions who believe they are using a professional tool but are on terms that treat their input as consumer data.

The mitigation is straightforward. Understand which tier you are on and what the terms say. Disable training in your account settings if you have not already done so. We trust Google with our email. We can trust AI providers with code, provided we understand and control the terms on which we do so.

Copyright and ownership. There is a legal question underneath AI-assisted development that most organisations have not yet thought through. In the United States, courts have established that works created by AI without meaningful human involvement cannot be copyrighted. The Copyright Office has confirmed that prompts alone are not sufficient to establish human authorship. New Zealand has not yet ruled on the question directly, but the direction of travel in comparable jurisdictions is consistent.

The practical implication is this: code generated by AI and accepted without meaningful human review, judgement, or modification may not be protectable intellectual property. For any organisation whose core asset is its software, that is a material concern. It is also one more reason why the human review practices described later in this article matter beyond quality and security. The developer who steers, evaluates, and makes architectural decisions about AI-generated code is in a different legal position from one who ships whatever the agent produces.

There is a second and separate question about provenance. AI models are trained on large bodies of existing code, but they do not simply reproduce it. Normal development use, asking an agent to implement a feature or solve a problem, produces synthesised output, not verbatim copies of training data. Verbatim reproduction would require explicitly prompting the model to reproduce specific code, which is a different activity entirely. The provenance risk in ordinary AI-assisted development is low, and human review of generated code reduces it further.

Both questions are still being worked out in the courts. The practical response is the same one the rest of this article points toward: keep humans genuinely engaged with the code rather than treating AI output as a black box. That is good practice on quality, security, and legal grounds simultaneously.

Programming With AI: Practices That Matter

For developers working with agentic tools day to day, the risks go beyond data exposure. They include access, integrity, and the quality of what gets built.

Production access. AI coding agents should not have access to live systems, production credentials, or administrative database access. AI systems make mistakes, misunderstand scope, and can cause irreversible damage. That is not a theoretical concern, it is the observed reality of working with these tools. Production systems are not the place to find out what an agent gets wrong.

Version control gates. Despite the ability of agentic tools to commit and push to git repositories, they should not be given permission to do so. The commit is the natural human checkpoint, the moment where generated code enters the shared context of the team and becomes something the organisation is responsible for. Granting an agent the ability to bypass that gate removes the last review point before the code becomes shared reality. The agent writes the code. The developer commits it.

Write tests first, commit them before implementation. An AI agent asked to implement a feature and write tests for it will write tests designed to pass. That is not the same as tests designed to verify. The test is shaped by the implementation rather than the other way around, and an agent optimising to satisfy the immediate request has every incentive to make the tests work rather than make them rigorous. Writing tests first and committing them before any implementation begins creates a structural constraint the agent cannot easily circumvent. Any subsequent modification to the committed test is immediately visible in the diff, a signal worth investigating every time.

Review the code. This sounds obvious. It is less obvious in practice when the code works, the tests pass, and the feature behaves as expected. The failure modes that matter most are not the ones that produce visible errors. They are the ones that look fine and are not. An agent asked to implement an API will implement one that works. It may not implement one that is properly secured. Authentication checks may be superficial, endpoints exposed to the wrong network, error responses leaking information, with no rate limiting in place. None of those failures show up in a functional test. They show up when someone finds the unsecured endpoint, which may be immediately or may be at the worst possible moment.

An agent can also make locally rational decisions that are globally wrong. Hardcoding a value to make a test pass. Implementing a workaround that solves the immediate problem and creates three others. Taking a structural shortcut that is invisible until the system needs to scale. These require a developer who understands what the code is supposed to do and can recognise when it is doing something subtly different. That judgement cannot be delegated to the tool.

This is not vibe coding. There is a current in AI development culture that treats code review as unnecessary overhead. Let the agent write it, ship it if it works, trust the tool. That may be defensible for personal projects where the cost of failure is low. For production code, client work, or anything with security or data integrity implications, it is a form of negligence dressed up as efficiency. Agentic tools make developers more powerful. They do not make developers optional. The human in the loop is not a bottleneck. They are the reason the output is trustworthy.

Training Completes the Picture

Different roles carry different levels of technical context, different exposure to risk, and different capacity to exercise informed judgement. Governance that recognises those differences will be more effective than governance that does not.

Policy sets the expectations. Training and education are what make those expectations stick. A developer who understands why production access is dangerous will follow the policy that prohibits it, and will apply the same judgement in situations the policy did not anticipate. A developer who does not understand it will follow the rule when someone is watching and work around it when they are not.

Governance that actually works does not stop at rules and controls. It extends to the people expected to operate within them, ensuring they understand what they are working with, take ownership of the decisions they make, and are accountable for the outcomes.

The investment that makes the most difference is not a more comprehensive control framework. It is ensuring that the professionals operating with AI discretion have the training to understand the risks, the discipline to apply that understanding consistently, and a genuine sense of responsibility for what they produce. That means understanding what the tools can do, what the data handling terms mean, and where the failure modes live. It also means understanding their personal responsibility to maintain the confidentiality of sensitive information and the security of the systems they work with. Those responsibilities do not change because an AI tool is in the loop. If anything, they become more important when the tool can act autonomously on their behalf.

The guardrails for front line staff matter. Centralised controls have a role. The firewall is not wrong for the population it is designed to protect. But none of those things substitute for competence, discipline, and ownership in the people who need to operate beyond them. Getting AI governance right means knowing the difference.

From Chatbot to Co-Developer

Peter Harrison — Fri, 13 Mar 2026 00:01:53 +0000

AI coding tools have changed more in the last two years than in the previous decade. They have split into distinct tiers with genuinely different capabilities. The tools at the top of that stack are doing things that would have sounded like marketing fiction not long ago.

Most developers encountered this space through chat assistants and browser-based copy-paste. Some moved on to inline autocomplete tools embedded in their editor. A smaller number have made the shift to agentic tools that read the codebase, plan across multiple files, and execute without being hand-fed every piece of context.

Each stage represents a different relationship between the developer and the machine. This article maps that evolution and makes the case that the agentic shift is not just an incremental improvement. It changes what a single developer can accomplish.

The Chat Phase: Powerful but Disconnected

Chat assistants such as Claude, ChatGPT, and Gemini remain the most common AI tools in development. The model is simple. You describe a problem, attach files, and receive a response. For explanation, debugging discussion, code review, and drafting small functions they work well.

However, the chatbot is entirely passive, in that it takes no direct action. The chatbot responds only to what you present it, and its output is limited to the response in the web interface. They cannot run your tests or inspect your source code. They cannot know if their suggestions are consistent with the project as a whole.

For many tasks this is acceptable. When projects become complex the copy-paste overhead becomes the bottleneck. You spend as much time managing context as solving the problem.

Inline Autocomplete: Fast but Narrow

GitHub integrated an AI chatbot into the editor called Copilot. Instead of the prompt and response model it watched you type and suggested what should come next. It would inject code into the editor greyed out, and by hitting Tab you could confirm and have it inserted into the editor.

In some respects this was almost magical, able to complete an entire function just by writing a descriptive function name. You could write the comments and have it complete the code. It was a magic trick that soon wore thin. It wasn't able to see the whole codebase, and so didn't have an understanding beyond the immediate file. You couldn't use it to complete features. It was an advanced text complete.

It was also very disruptive to maintaining focus, as it forced you to evaluate suggestions. Often the suggestions would look plausible, but not actually do what you wanted. So you had to read the code anyway, which was in some respects worse that just writing it yourself. This was not the way.

The Shift: From Chatbots to Agentic Tools

Agentic coding tools such as Claude Code, Codex, and Cursor have fundamentally changed the game in how LLM models are used in software development. They can read the codebase, examine files, follow dependencies, and plan changes across multiple files. Then can write the code, run tests, observe failures, and adapt.

OpenAI and Anthropic have taken different paths. OpenAI and CodeX have a kind of virtual environment where code is checked out and developed in a sandbox within the OpenAI infrastructure.

Anthropic have take a different approach, where Claude Code has the ability to actually run command line tools and other plug in skills directly from the users machine. It can read or modify files in your project, or for that matter anywhere on your PC. It can execute builds and tests, and evaluate the results.

The way you interact with Claude Code is similar to a chatbot in many respects, having a straight forward conversation, but at the same time it is able to actually to interact with your computer. Needless to say any sane developer would find this a little scary. Luckily Anthropic have added a permission system to that it will ask permission before executing commands. It is however possible to give broad permissions for a whole class of commands.

This new approach means that you can now write a requirements document or a user story, and essentially give it to Claude Code to complete. It will examine the codebase, develop a plan for the required changes, then perform all the changes. It can even write your unit tests for you.

The move from chatbot where the developer has 100% control over the interaction and the code to agentic systems such as Claude Code is both amazing and disquieting. Suddenly developers are not writing code so much as orchestrating development.

Needless to say some developers are not keen to give machines this degree of autonomy. AI can hallucinate, and go off and make crazy changes based on a misunderstanding. There are real risks involved, so the degree of access and authority given to agentic systems needs to be carefully managed.

A Brave New World

Being a good software developer has always meant adaptation to new technologies. From learning BASIC to dBase to Delphi and Java, my own path has been one of continuous learning and adaptation.

Howevever, where once a software developer might need to know one or two technologies, perhaps a programming language and SQL, we now have multiple front end Javascript frameworks, CSS, multiple back end languages, git, continuous build and deployment systems, AWS, Google Cloud Platform or Azure.

Developers cannot be experts in all languages. Usually they are competent in a specific technology stack. One of the critical skills has been learning when to jump ship to new technologies, before the old gives way. Only the speed of technological development has made that increasingly difficult.

Agentic tools are changing the shape of this problem. An experienced developer with strong architectural thinking can now work effectively in unfamiliar stacks. The tool handles syntax and ecosystem details. The human evaluates whether the result is correct. This already happens in practice.

Last year we had a case where we needed to migrate a REST API from Python and FastAPI to Microsoft C# on Azure. With the help of Agentic AI systems this was achieved, despite not having prior C# experience. Obviously in such cases we needed to have ways of testing the code, and there was a clear existing target.

In another instance we needed to modify an unfamiliar codebase to add new functionality. The system was non trivial, and the feature quite deeply technical. It did in fact take three days of work to crack the initial solution, even with the help of AI. But make no mistake that without the help of AI it would have been impossible to get results in the time frame required.

Finally over the last two weeks or so we developed our first mobile application. The idea and concept was developed while on a walk, talking with ChatGPT. From that brainstorming we worked together on an initial set of requirements. From there we handed it off to Claude Code where we have worked together to develop a React Native Android application. Every line of code was written by Claude.

This is still a collaboration, in that Claude Code is directed by a programmer. We are still able to see and review code. Developers are still in the drivers seat. We are still making decisions about what is ready to commit.

But there is a certain disquiet, that human software developers are not needed to write the code anymore. Developers are becoming something more like orchestrators, knowing how to make the agents get the job done.

Beyond Coding Tools: Autonomous Agents

Agentic coding is only the beginning. The same pattern is spreading to broader digital environments.

Tools such as OpenClaw connect email, calendars, messaging systems, files, and code execution through a single interface. One documented workflow schedules development tasks overnight. The agent runs them while the developer sleeps and produces a summary by morning.

OpenClaw opened the floodgates, and thousands of people installed it and opened up their data and lives to nightmare levels of security risk. In at least one case OpenClaw deleted an executives entire email inbox.

Capability	Chat Assistants	Inline Autocomplete	Agentic Coding Tools	Autonomous Agents
Examples	Claude, ChatGPT, Gemini	GitHub Copilot, Tabnine, Codeium	Claude Code, Codex, Cursor	OpenClaw
Reads your codebase	No	Partial (cursor window only)	Yes	Yes
Writes files	No	No (suggests only)	Yes	Yes
Runs commands	No	No	Yes	Yes
Runs tests	No	No	Yes	Yes
Plans across multiple files	No	No	Yes	Yes
Persistent project context	No	Partial	Yes (via config files)	Yes
Iterates on failures	No	No	Yes	Yes
Operates autonomously	No	No	Partially (with approval)	Yes
Integrates with external services	No	No	Limited	Yes
Choice of underlying model	N/A	Yes (Copilot)	Yes (Cursor, Copilot)	Yes
Setup required	None	Low	Medium	High
Security risk surface	Low	Low	Medium	High

Whether the benefits outweigh the risks is still an open question. The capability is real and the direction of travel is clear. The tooling is early and the implications of giving an agent that kind of reach are still being worked out in practice. It is worth watching.

Where This Leaves You

The tools have moved from responding to acting. That is the shift worth understanding.

Chat assistants remain useful for explanation and isolated problems. Autocomplete accelerates familiar patterns but does not expand what you can accomplish. Agentic tools operate across more files and more complex systems. They also allow developers to work in unfamiliar territory.

The human judgement in the loop still determines the quality of what comes out. The developer who can describe a problem clearly, evaluate a proposed plan critically, and recognise when the output is wrong will get dramatically better results than one who cannot. The tool amplifies what you bring to it.

These new tools open the door to new risks. They are unlike any risk we have seen before because agents given the ability to act might do so in unpredictable ways. We can't afford to ignore the risks, but neither can we ignore the rapidly advancing capabilities of these new agentic systems.

When the Code Writes Itself

Peter Harrison — Thu, 12 Mar 2026 19:45:13 +0000

Software development is beginning to experience a quiet shift that many programmers can already feel in their daily work. A developer describes a task to an AI system, the tool reads the repository, modifies several files, runs tests, and returns with a proposed solution. The developer reviews the changes, adjusts the instructions, and runs another cycle. Somewhere in that process a realization appears: most of the code was not written by the person at the keyboard.

This development does not resemble the autocomplete tools developers have used for years. The new generation of systems can reason across an entire project and perform part of the implementation process themselves. The human still guides the work, but the machine increasingly handles the mechanics of getting there. That shift is small when viewed one feature at a time, yet taken together it alters how software is produced.

The Implementation Loop Is Moving Into Software

For most of the history of programming, the entire development loop lived inside the developer’s head. A programmer interpreted the requirements, explored the codebase, wrote the changes, compiled the project, and repeated the cycle until the result worked. The tools surrounding that process helped with editing and debugging, but the thinking and iteration remained firmly human.

Modern AI coding systems are beginning to absorb part of that loop. A developer can now describe an intended change while the system navigates the codebase, proposes modifications across several modules, runs tests, and adjusts its approach if something fails. Instead of writing every line directly, the human increasingly evaluates the machine’s attempts and steers the next iteration.

The productivity gains are obvious, but the deeper change lies in where attention is spent. Mechanical exploration of the codebase, which once consumed hours of developer time, can now be delegated to software. The developer becomes the person who defines the problem and judges whether the result makes sense.

Developer Culture and the Status of Intelligence

The cultural side of this shift is easy to underestimate unless you have spent time inside developer communities. Programming has long been a profession where status is strongly tied to perceived intelligence rather than organizational rank or salary. Within many technical circles, reputation is earned by demonstrating the ability to understand complex systems and produce elegant solutions that others struggle to grasp.

That culture has shaped how developers think about themselves and their work. Writing sophisticated software has functioned not only as productive labour but also as a signal of intellectual competence among peers. The act of solving a difficult technical problem has historically carried social value inside the profession.

AI coding systems complicate that dynamic. When a machine can generate large amounts of working code almost instantly, the visible act of writing code stops being a reliable signal of intellectual distinction. The technology does not remove the need for expertise, but it changes which abilities are visible and which ones matter most.

It is therefore unsurprising that reactions among developers vary widely. Some adopt the tools enthusiastically and incorporate them into their workflow. Others highlight the risks, limitations, and security concerns associated with machine generated code. Still others quietly use the systems while publicly minimizing their importance. All of these responses make sense once the cultural dimension is recognized.

A Boundary That Keeps Moving

Much of the current debate focuses on what AI systems can or cannot do today. These discussions often assume that the current division of labour between human developers and machines will remain relatively stable. Recent experience suggests that such assumptions deserve caution.

Only a few years ago it was widely believed that AI would assist with small fragments of code while humans handled real software development. That boundary moved as systems began producing entire functions, then navigating repositories, and now running iterative development loops. Each step has transferred another portion of the work from the human side to the machine side.

At present developers still define the goals and evaluate the architectural consequences of a change. The machine performs a growing portion of the implementation, but the human decides what the system should become. Whether that balance will remain stable over the next decade is an open question.

One consequence is already visible in the structure of development teams. When a developer can direct tools that perform much of the mechanical work, a small group can achieve results that previously required a much larger team. This does not eliminate the need for experienced engineers, but it changes how much leverage a single developer can have over a complex project.

Software development therefore appears to be entering a period of transition rather than a stable endpoint. The profession is adjusting to tools that alter not only productivity but also the cultural signals that once defined expertise. The machines are beginning to write substantial portions of the code, and developers are beginning to guide increasingly capable systems.

Where that process eventually leads remains uncertain. What is clear is that the line between human and machine responsibility in programming has already begun to move, and history suggests it may continue to do so.

This article was written with the aid of AI

Deep Learning Without Backpropagation

Peter Harrison — Sun, 08 Feb 2026 09:17:39 +0000

Most modern neural networks learn using backpropagation. It works well, but it has a strange property: learning depends on a global error signal flowing backward through the entire network. Every weight update depends on information that may be many layers away.

Brains don’t work like that.

Neurons only see local information, what they receive through synapses, what they fire. There is no global gradient descending through the cortex. Yet biological systems learn deep, layered representations of the world with remarkable efficiency.

This raises a simple question:

Can deep neural networks learn using only local learning rules?

Until recently, the answer appeared to be “not really.”

The Problem With Local Learning

Local learning rules, often called Hebbian learning (“neurons that fire together wire together”) have been known for decades. They work well for simple feature discovery, but they historically struggled with deeper networks.

When stacked into multiple layers, purely local learning tends to fail because:

Higher layers receive no meaningful training signal
Layers drift or collapse into similar representations
Features fail to become more abstract with depth

In short, without a global error signal, deep structure usually does not emerge.

The Key Insight: Structure Matters More Than the Learning Rule

The breakthrough came from an unexpected place.

Instead of changing the learning rule, the architecture was changed to match how biological vision works:

Local receptive fields (small patches instead of full image connections)
Competition between neurons (winner-take-all)
Adaptive plasticity (each neuron self-regulates its sensitivity)
Strictly local updates (no backpropagation anywhere)

This combination produced something surprising:

The network began to self-organize meaningful feature hierarchies using only local information.

No gradients. No global error. No backprop.

What the Network Learned

The first layer learned simple local features such as edges, curves and strokes. This is exactly what you would expect from early visual cortex.

But more importantly, when layers were stacked, higher layers learned compositions of lower features:

Edges → shapes
Shapes → digit structure
Structure → class separation

The network trained deeply, layer by layer, using only local learning.

The Result

On the MNIST handwritten digit dataset, this locally trained network reached:

~97% accuracy using only local learning rules

No backpropagation at any stage.

Even more interesting:

Most of the classification power came from the unsupervised feature layers. A simple linear readout on top of those features performed almost as well as the fully trained system. This shows the network learned a representation where classes naturally separated without ever seeing labels during feature learning.

Why This Matters

This result challenges a long-standing assumption:

That deep learning requires backpropagation.

Instead, it suggests:

Deep hierarchical learning can emerge from local rules
The right architecture and constraints may be more important than the learning algorithm
Biological-style learning is not only plausible; it can be competitive

It also opens the door to systems that:

Learn continuously instead of in fixed training phases
Adapt locally without retraining the whole network
Are more biologically realistic
Potentially scale differently from gradient-based systems

The Bigger Picture

Backpropagation is powerful, but it is not the only path to intelligence.

This work shows that when local learning is combined with:

Spatial locality
Competition
Self-regulating neurons
Layered structure

Deep networks can organize themselves into meaningful representations without ever computing a global error gradient.

The discovery is simple, but profound:

The bottleneck was never local learning. It was the structure we gave it.

SHARD: Deniable File Distribution Through XOR-Based Sharding

Peter Harrison — Fri, 30 Jan 2026 23:00:33 +0000

The Problem: Protecting Information Sources

In 2012, I developed SHARD to address a fundamental challenge in information security: how do you enable the distribution of sensitive information without being able to identify the source?

Traditional encryption doesn't solve this problem. An encrypted file is still evidence of something. If you're found in possession of secret_document.gpg, you have a file that clearly contains information, even if investigators can't decrypt it. For whistleblowers, journalists, and activists operating under authoritarian regimes, mere possession of encrypted files can be incriminating.

The requirement was different: create a system where:

Information can be distributed through normal channels (FTP, HTTP, file sharing)
Individual components are meaningless - they provide no evidence of what information they might contain
Source protection is cryptographic - not just operational security, but mathematically provable deniability
Reconstruction is possible for intended recipients with the proper instructions

SHARD achieves this through a elegant application of XOR operations and a separation of concerns: bulk data (shards) travels through one channel, while reconstruction metadata (recipes) travels through another.

How SHARD Works: The Concept

SHARD splits files into components called "shards" using XOR operations. The critical innovation is that shards are not simply encrypted fragments. Instead, each shard can be a required component of many different files - potentially hundreds. This makes it cryptographically impossible to associate any single shard with a particular source file.

Here's the process:

A pool of random "seed" shards is created - these are just random data
When you shard a file, each 1MB section is XORed with 3 randomly selected existing shards
The result is written as a new shard added to the pool
A small "recipe" file records which shards to XOR together to reconstruct the original

As multiple users shard their files using a shared pool, the deniability compounds. A shard in your possession could be part of:

Your own files
Files sharded by other users
Nothing at all (just a random seed shard)
Multiple files simultaneously

Without the recipe, there's no way to determine what any shard contains.

Network Effects and Collaborative Use

The system becomes more powerful when multiple users share a shard pool. If Alice, Bob, and Carol all use the same collection of shards:

Alice shards her sensitive document, creating new shards A1, A2, A3
Bob shards his document, potentially using A1, A2 in his XOR operations, creating B1, B2
Carol does the same, creating C1, C2, C3

Now shard A1 is a component of Alice's file AND Bob's file. There's no way to prove which file A1 "belongs to" - it's genuinely part of both. As the pool grows and more users participate, this ambiguity increases exponentially.

Practical Usage

SHARD consists of three Python scripts. Let's walk through using them.

Setup

First, create a directory for shards and generate an initial pool of random seed shards:

mkdir shards
python random_shards.py

This creates 10 random 1MB files in the shards/ directory with names like:

shard-a3f5e9c2b1d4f8e7c6b5a4f3e2d1c0b9
shard-7c8d2e1f4a5b6c9d0e3f1a2b8c4d5e6f
...

These filenames are not random - they're the BLAKE2b hash (128-bit) of the shard contents. This makes the shard store content-addressable: the filename is a direct cryptographic function of the data it contains. This becomes important for integrity verification during reconstruction.

These seed shards provide the initial XOR key material for the system.

Sharding a File

To shard a file:

python shard.py secret_document.pdf

The script:

Reads secret_document.pdf
Processes it in 1MB sections
For each section:
- Randomly selects 3 existing shards from the pool
- XORs the section with each of the 3 shards
- Writes the result as a new shard
Creates secret_document.pdf.recipe containing the reconstruction instructions

The recipe file is small - just a list of shard filenames. For a 10MB file, the recipe might be around 1-2KB.

Reconstructing a File

To reconstruct the original file:

python unshard.py secret_document.pdf.recipe

The script:

Reads the recipe file
For each shard referenced in the recipe:
- Reads the shard file
- Computes its BLAKE2b hash
- Verifies the hash matches the filename
- Exits with an error if any shard fails verification
For each 1MB section, XORs the 4 verified shards together
Writes the reconstructed data to the original filename

The output file is identical to the input - bit-for-bit perfect reconstruction.

Integrity verification is automatic. If any shard has been corrupted, modified, or is simply the wrong file, its BLAKE2b hash won't match its filename and reconstruction will fail immediately. This prevents producing a corrupted output file from bad input shards.

Distribution Strategy

The power of SHARD comes from separating the distribution channels:

Shards (bulk data):

Can be hosted publicly on any file server
Uploaded to cloud storage
Distributed via BitTorrent
Shared on FTP sites
No risk in possession - they're just random-looking data

Recipes (reconstruction metadata):

Much smaller - can be transmitted via secure channels
Can be printed (for small files)
Transmitted via encrypted messaging
Read over phone/radio for very small files
Hand-delivered on USB sticks

A whistleblower could host shards on a public website under their own name with no legal risk. The recipe travels separately through secure channels to intended recipients.

Technical Details: The Cryptography

XOR Operations

SHARD uses XOR (exclusive OR) as its core cryptographic primitive. XOR has a critical property: A XOR B XOR B = A. This means XORing a value with the same key twice returns the original value.

For each 1MB file section, the sharding process:

section = file_data[offset:offset+1MB]

# XOR with 3 randomly selected shards
section = section XOR shard1
section = section XOR shard2  
section = section XOR shard3

# Write the result as new_shard
write(new_shard, section)

To reconstruct:

# Start with the output shard
data = read(new_shard)

# XOR with the same 3 shards
data = data XOR shard1
data = data XOR shard2
data = data XOR shard3

# Result is the original section
# Because: (section XOR shard1 XOR shard2 XOR shard3) XOR shard1 XOR shard2 XOR shard3 = section

Information-Theoretic Deniability

The security comes from the properties of XOR operations:

One-time pad property: When you XOR data with truly random bytes, the output is indistinguishable from random data
No information leakage: Without the recipe, there's no way to determine what shards contribute to what files
Collision-free reconstruction: Because we track exactly which shards were used, reconstruction is deterministic

Each shard is effectively random data. Even if an attacker has:

All the shards
Knowledge that certain shards exist
Suspicions about what might be sharded

Without the recipe, they cannot:

Determine what any shard contains
Prove any shard is part of a particular file
Reconstruct any file

Content-Addressable Storage and Collision Resistance

Shards are named using the BLAKE2b hash of their contents:

import hashlib

def create_shard_name(data):
    h = hashlib.blake2b(data, digest_size=16)  # 16 bytes = 128 bits
    return 'shard-' + h.hexdigest()  # Returns 32 hex characters

This creates content-addressable storage where the filename is a cryptographic function of the file's contents. A shard named shard-a3f5e9c2b1d4f8e7c6b5a4f3e2d1c0b9 will always contain exactly the data that produces that specific BLAKE2b hash.

Benefits of this approach:

Built-in integrity verification: To verify a shard, simply hash its contents and check if the result matches its filename. No separate checksums needed.
Automatic deduplication: If two sharding operations produce identical data, they generate the same hash and thus the same filename. Only one copy is stored.
Collision resistance: BLAKE2b with 128 bits provides 2^128 possible hash values. The probability of collision is negligible - you'd need to generate about 2^64 (18 quintillion) shards before having a 50% chance of a single collision.
Performance: BLAKE2b is one of the fastest cryptographic hash functions available, typically achieving 1-3 GB/s on modern CPUs - much faster than SHA-256.
Recipe simplicity: The recipe file just lists shard names. Those names are also the verification hashes. No additional metadata needed.

Padding for Uniform Size

All shards are exactly 1MB, regardless of the actual data they contain:

with open('shards/' + newShard, 'wb') as newShardFile:
    newShardFile.write(section)
    bufSize = (1024 * 1024) - len(section)
    if bufSize > 0:
        newShardFile.write(os.urandom(bufSize))

This prevents information leakage through file sizes. The last section of a file is padded with random data to reach exactly 1MB, making all shards uniform and indistinguishable.

Integrity Verification Through Content-Addressable Storage

SHARD uses content-addressable storage where each shard's filename is derived from its contents:

import hashlib

def hash_shard(filepath):
    h = hashlib.blake2b(digest_size=16)  # 128-bit hash
    with open(filepath, 'rb') as f:
        h.update(f.read())
    return h.hexdigest()

def verify_shard(filepath):
    # Extract hash from filename (remove 'shard-' prefix)
    expected_hash = filepath.split('shard-')[1]
    actual_hash = hash_shard(filepath)
    return expected_hash == actual_hash

During reconstruction, unshard.py automatically verifies every shard before using it:

Read the shard file from disk
Compute its BLAKE2b hash
Compare against the hash embedded in the filename
If mismatch: exit with error message identifying the corrupted shard
If match: proceed to use the shard in XOR operations

This provides fail-fast integrity checking. If you've downloaded shards from an untrusted source, or if transmission errors have corrupted files, you'll know immediately before attempting reconstruction. The system won't produce a corrupted output file - it either succeeds completely with verified shards or fails cleanly with an error message.

Why BLAKE2b?

BLAKE2b was chosen for several technical reasons:

Speed: 2-3x faster than SHA-256, crucial when verifying many large files
Security: Provides cryptographic-strength collision resistance
Standard library: Available in Python's hashlib since Python 3.6
Appropriate size: 128-bit output provides the right balance between collision resistance (2^64 shards before 50% collision probability) and compact filenames (32 hex characters)

The integrity verification is not just detecting accidental corruption - it also prevents attacks where someone might substitute malicious shards. Without knowing the content that produces a specific BLAKE2b hash, an attacker cannot create a substitute shard that passes verification.

Random Shard Selection

When sharding a file, 3 shards are randomly selected from the pool:

def getShardFiles():
    dirList = os.listdir("shards")
    fileList = []
    while len(fileList) < 3:
        consider = dirList[int.from_bytes(os.urandom(4), 'big') % len(dirList)]
        if consider not in fileList:
            fileList.append(consider)
    return fileList

This ensures:

Different files use different shard combinations
The mapping between shards and files is unpredictable
The pool's ambiguity grows with each use

Recipe Files: The Weak Point and the Strength

The recipe file is both the vulnerability and the key to SHARD's security model.

A recipe contains:

original_filename.pdf
10485760
shard-f81d4fae-7dec-11d0-a765-00a0c91e6bf6
shard-a3d5e8c2-4b91-11ec-9f24-00a0c91e6bf6
shard-b7c3f1d9-5a82-11ec-8e35-00a0c91e6bf6
shard-c9e4a2b8-6c73-11ec-9d46-00a0c91e6bf6
...

For a 100MB file, the recipe is roughly 16KB - small enough to:

Print on a few pages
Transmit via low-bandwidth channels
Store on a USB stick hidden physically
Encode in images or other steganographic techniques
Memorize in chunks (for very small files)

The security trade-off:

Shards alone: Completely safe to possess, host, or distribute. Provide zero information.
Recipe alone: Useless without access to the shard pool.
Shards + Recipe: Full reconstruction capability.

This separation enables a powerful distribution strategy: shards move through monitored, high-bandwidth channels where possession means nothing. Recipes move through secure, potentially lower-bandwidth channels where small size is an advantage.

Limitations and Considerations

Recipe Size for Large Files

While recipes are small relative to file size (~0.016% overhead), they grow linearly with file size at 4 shard names per megabyte. A 1GB file needs a recipe listing ~4,000 shards (roughly 160KB with 32-character hash-based shard names).

This crosses the threshold from "easily non-digital transmission" into "needs digital channels anyway" for very large files. The system works best for documents, images, and small datasets rather than multi-gigabyte video files.

Trust and Distribution

SHARD provides technical deniability, but practical deployment requires:

Trusted channels for recipe distribution
Confidence that shard pools haven't been compromised
Understanding that recipe holders can reconstruct files

The recipe is the single point of failure. If intercepted, and the attacker has access to the shard pool, reconstruction is trivial.

Shard Pool Management

As the pool grows, managing thousands of shard files becomes a practical concern. The system has no built-in mechanisms for:

Shard garbage collection (removing unused shards)
Versioning or tracking which shards are still needed
Synchronizing shard pools across multiple users

These would need to be handled at the operational level.

Comparison to Modern Approaches

Since 2012, various systems have emerged with related goals:

IPFS and Distributed Hash Tables: IPFS also uses content-addressed storage with cryptographic hashes as identifiers. However, IPFS content hashes uniquely identify files - there's no deniability. Each file has one hash. SHARD is different: each shard can be a component of multiple files, creating genuine ambiguity about what any shard contains.

Blockchain-based storage: Systems like Filecoin or Storj distribute encrypted fragments. But they require massive computational overhead, cryptocurrency mechanisms, and energy consumption far beyond SHARD's simple XOR operations. They're solutions in search of a problem, optimizing for decentralization rather than deniability.

Steganography: Hiding data in innocent-looking files. SHARD is different - shards look like random data, not innocent files, and the deniability comes from mathematical ambiguity rather than hiding.

Secret Sharing (Shamir's): Splits secrets so N of M shares are needed for reconstruction. SHARD is different - it's about creating ambiguity about which shards belong to which files, not threshold reconstruction.

SHARD remains unique in its specific approach: XOR-based sharding with collaborative pool sharing for cryptographic deniability, combined with content-addressable storage for automatic integrity verification.

Conclusions

SHARD represents appropriate technology - using the simplest cryptographic primitives that solve the problem. XOR operations for deniability, BLAKE2b hashing for integrity verification. No complex protocols, no distributed consensus, no cryptocurrency, no massive energy consumption. Just elegant mathematics and file management.

The content-addressable storage design means shards are self-verifying - the filename is the checksum. This eliminates an entire class of problems around shard corruption and verification without adding complexity to the recipe files.

The separation of bulk data (shards) from reconstruction metadata (recipes) creates genuine plausible deniability. Individual shards provide no evidence of what they contain or contribute to. As shared pools grow through collaborative use, the ambiguity compounds mathematically.

While SHARD was never adopted in practice, it demonstrates an elegant approach to a real problem: how do you enable information distribution while cryptographically protecting sources? The technical solution works. The deployment challenges - user experience, trust models, operational security - proved harder than the mathematics.

The code is available under GPL v3 at: https://bitbucket.org/cheetah100/shard/

For those interested in source protection, deniable storage, or just elegant applications of XOR cryptography and content-addressable storage, SHARD remains a useful proof of concept and learning tool.

Peter Harrison has been working in software development for over 30 years and founded the New Zealand Open Source Society in 2002. This article describes SHARD, developed in 2012 as a proof of concept for deniable file distribution.

Difficult Choices: Angular, React or Vue?

Peter Harrison — Fri, 19 Dec 2025 22:48:03 +0000

Staying Current Without Chasing Trends

Technology choices are a constant in software development. The landscape shifts continuously. New frameworks emerge, established ones evolve, and yesterday's cutting-edge solution becomes tomorrow's legacy burden. The challenge isn't just picking the right tool, but knowing how to evaluate tools in the first place.

I've made major technology shifts before. Moving from Delphi to Java years ago gave me access to broader platforms and let me write applications for 'big iron', not just PCs. That shift was driven by concrete needs: platform reach, community size, and productivity gains. It wasn't about chasing the new and shiny.

But staying current requires discipline. Following every new framework is career self-sabotage. You waste time on technologies that may vanish and never develop deep expertise because you're constantly context-switching. The developers who mastered Spring or Rails in 2010 and stuck with them have built more valuable skills than those who jumped to every micro-framework that promised to revolutionize web development.

By 2020, I needed to fill a gap in my skillset: modern web UI development. My focus had been middleware and backend systems, but now I had to build a SaaS application from scratch. The question wasn't "what's hot?" but "what will get me productive and help me ship?"

The Three Criteria for Technology Choice

When evaluating new technologies, I consider four factors that often conflict with each other:

1. Marketable Skill

What actually pays the bills. This requires nuance beyond "what's popular on GitHub." Marketability is regional. What's hot in Silicon Valley may not match demand in your location. It's also temporal. COBOL was marketable for 40 years; some Node.js frameworks barely lasted 4.

Job listings are a useful signal, but they lag behind actual industry use. Enterprises move slowly; by the time a technology dominates job boards, it may already be maturing toward eventual decline.

For consultants and contractors, marketability matters more than for product developers. If you're building your own SaaS application, productivity matters more than resume keywords.

2. Utility

Does it solve real problems you actually have? A framework optimized for single-page applications is useless if you're building content sites. One focused on developer experience matters more when you're a team of one than when inheriting a codebase from 50 developers.

Utility isn't just about features. It's about fitness for purpose. Does the framework's architecture align with your problem domain? Does it integrate well with your existing stack? Does it force architectural choices you disagree with?

Beware framework creep: tools that started focused and useful often add features that create new problems while solving problems you don't have.

3. Ease of Adoption

Your time has value. If Framework A takes three months to productivity and Framework B takes three weeks, B needs to be dramatically worse on other dimensions to justify A.

Ease of adoption isn't just syntax simplicity. It includes:

Conceptual clarity: Does it match your mental models or force you to unlearn established patterns?
Learning resources: Quality documentation, tutorials, community knowledge
Tooling maturity: Build systems, debugging tools, error messages
Incremental path: Can you start simple and add complexity gradually?

At different career stages, this criterion weighs differently. Junior developers often must grind through whatever the market demands. Experienced developers can be selective and optimize for productivity.

The Contenders

In 2020, the frontend framework landscape had three clear leaders: Angular, React, and Vue. All were mature, production-tested, and had substantial communities. All followed a client-side architecture with REST API backends. The server/client boundary was clear and clean.

Angular

The Enterprise Standard

Angular came from Google, had comprehensive documentation, and dominated enterprise development. It offered a complete, opinionated framework: dependency injection, routing, forms, HTTP client, testing tools. Everything included.

Strengths:

Complete solution, batteries included
Strong typing with TypeScript
Dependency injection familiar to Java/C# developers
Enterprise backing and long-term support
Comprehensive official documentation

Weaknesses:

Steep learning curve with significant conceptual overhead
Heavy tooling requirements before writing your first component
Complex build pipeline
RxJS everywhere, whether you want reactive programming or not
"Hostile to learning quickly" because there's lots to master before becoming productive

For developers coming from enterprise Java or C# backgrounds, Angular's patterns are familiar. For someone who needed to ship a SaaS application quickly, the time to productivity was prohibitive.

React

The Market Leader

React from Facebook (now Meta) dominated mindshare by 2020. Job listings favored React developers, the community was massive, and the ecosystem was rich with libraries and tools.

Strengths:

Huge community and ecosystem
Maximum job market demand
"Just JavaScript" means learning React improves your JavaScript skills generally
Flexible, unopinionated (use what you want for routing, state, etc.)
Strong corporate backing

Weaknesses:

JSX requires mental adjustment (JavaScript inside HTML-like syntax)
Ecosystem fragmentation: which router? which state management? which form library?
Learning resources scattered and variable quality
Rapid evolution meant tutorials went stale quickly
"Thinking in React" requires functional programming mindset shift

React's marketability was compelling for career optionality. But for shipping a product, the fragmented ecosystem meant constant decisions about which supporting libraries to adopt, and the learning resources were inconsistent.

Vue

The Progressive Framework

Vue positioned itself as the "progressive framework". Use as much or as little as you need. It borrowed good ideas from both Angular (templates, directives) and React (component-based, reactive) while staying simpler than either.

Strengths:

Gentle learning curve with fast time to productivity
Template syntax that looks like HTML (familiar and readable)
Clear, well-written official documentation
Can start with a simple script tag, add build tools later
Vue Mastery: Professional, high-quality tutorial platform
Single-file components are intuitive
Reactive data binding "just works"

Weaknesses:

Smaller community than React (though still substantial)
Less job market demand than React or Angular
Fewer third-party libraries and tools
Less corporate backing (individual creator, though now has team/foundation)

Vue's ease of adoption was its killer advantage. Within days, I could build working components. Within weeks, I understood the framework deeply enough to make architectural decisions confidently.

The Decision: Learning Infrastructure Matters

I chose Vue, and the deciding factor was quality of learning resources.

Vue Mastery provided professional, pedagogically sound tutorials that treated teaching as a craft. The courses built skills incrementally, anticipated common misconceptions, and used realistic examples. This wasn't someone's webcam rambling through code. It was professionally produced education.

Compare this to React's learning landscape in 2020: the official docs were improving but patchy, Medium was full of outdated or wrong articles, paid courses varied wildly in quality, and the rapid evolution of the framework meant yesterday's tutorial taught obsolete patterns.

Angular had comprehensive documentation, but it was dense reference material assuming you already understood their architectural concepts. It was written for people who already knew Angular, not for learners.

The business case was clear: Vue Mastery cost a few hundred dollars annually, but got me productive weeks faster than piecing together free React tutorials. When you're building a business, your time has value. Investing in quality education has obvious ROI.

This revealed a fifth criterion I hadn't initially considered: Learning Infrastructure Quality. Framework features and syntax matter, but the ability to actually acquire skills efficiently matters more. A simpler framework with poor teaching materials can be harder to learn than a complex framework with excellent tutorials.

The Conflict of Criteria

The difficulty of choice comes from conflicting priorities:

New hotness said: "Try Svelte! Try Solid! Try whatever just launched!"
Marketable skill said: "Learn React, it dominates job listings"
Utility said: "They all solve your problem, pick one and ship"
Ease of adoption said: "Vue gets you productive fastest"

For my situation (building a SaaS product, filling a skillset gap, needing to ship) ease of adoption dominated. I could always learn React later for consulting work if needed (marketability). I deliberately ignored new hotness. And utility was roughly equal across all three.

Your priorities may differ. If you're job-hunting, marketability might dominate. If you're joining a team, you don't get to choose. You learn what they use. If you're building throwaway prototypes, ease of adoption matters most. If you're building a 10-year platform, architectural soundness and longevity matter more than any other factor.

Lessons Beyond Frameworks

The framework choice taught me about technology evaluation generally:

Don't chase hype. New technologies need to prove themselves over years, not months. Let others debug the bleeding edge.

Learning infrastructure is a feature. A technology with worse technical characteristics but better teaching materials may be the better choice for actual skill acquisition.

Optimize for shipping, not learning. If your goal is to build something, pick the tool that gets you there fastest. You can always learn other tools later.

Context matters more than features. There is no "best framework" in the abstract. There's only "best for your situation, constraints, and goals."

Time has value. Spending weeks learning for free instead of days learning with paid quality education is false economy.

The frontend landscape has evolved since 2020. React now has Server Components. Next.js and SvelteKit blur the server/client boundary. New frameworks emerge constantly. But the evaluation framework remains sound: ignore hype, understand your actual needs, consider the full learning ecosystem, and optimize for productivity over resume keywords.

Choose based on where you are and what you're building. Not based on what's trending on Twitter.

Lessons from React2Shell

Peter Harrison — Tue, 09 Dec 2025 22:34:25 +0000

On December 3rd, 2025, React disclosed CVE-2025-55182, a critical remote code execution vulnerability with a CVSS score of 10.0, the maximum possible severity. Within hours, attackers were exploiting it in the wild. Nearly a million servers running React 19 and Next.js were vulnerable to unauthenticated remote code execution. For a framework that had maintained a remarkably clean security record over 13 years, just one minor XSS vulnerability (CVSS 6.1) in 2018 this represented a catastrophic failure.

The Vulnerability

The exploit exists in React's "Flight" protocol, a custom serialization format introduced with React Server Components. Flight handles the transfer of data and execution context between client and server. The vulnerability allowed attackers to craft malicious payloads that, when deserialized by the server, could execute arbitrary code. The attack required no authentication, just network access to send a crafted HTTP request to any Server Components endpoint.

The technical root cause was unsafe deserialization of untrusted client data. The server accepted serialized objects from clients, deserialized and executed code based on their contents, including accessing object properties like .then and .constructor that allowed attackers to reach JavaScript's code execution primitives. React's defenses relied on the assumption that the serialization format itself would prevent malicious inputs, rather than treating all client data as untrusted by default.

What Are React Server Components?

React Server Components (RSC) represent a fundamental shift in React's architecture. Traditionally, React was a client-side library that ran in the browser, rendering user interfaces and talking to backend APIs via standard REST or GraphQL endpoints. Your backend could be written in any language: Python, Go, Ruby, Java, whatever made sense for your use case.

Server Components change this model. They allow React components to execute on the server, access databases directly, and serialize their results including promises and complex state to the client using the Flight protocol. Functions marked with 'use server' become server-side endpoints automatically. No explicit API routes required. The framework handles routing these "Server Actions" and serializing the data flow between client and server.

The pitch is seductive: write your frontend and backend in the same files, using the same language, with "seamless" data flow between them. No API boilerplate, no context switching, just components that "magically" know whether to run on client or server.

Violation of Security Principles

This is where React abandoned decades of hard-won security wisdom. The fundamental principle of secure systems is simple: never trust client input. Every mature framework and language ecosystem has learned this lesson through painful experience:

Java serialization vulnerabilities plagued the ecosystem for years, leading to remote code execution in countless applications. The Java security team eventually concluded that deserializing untrusted data was simply too dangerous, leading to deprecation warnings and architectural guidance to avoid it entirely.

PHP's unserialize() function became the attack vector for thousands of WordPress compromises. The PHP community learned to treat deserialization of user input as an anti-pattern to be avoided.

Python's pickle module documentation explicitly warns: "The pickle module is not secure. Only unpickle data you trust." It's considered unsafe for any data that might come from untrusted sources.

Ruby's Marshal has the same warnings and the same history of vulnerabilities.

React looked at this 50 year history and decided to build a custom serialization protocol that deserializes client data into server execution contexts. The Flight protocol needed to be "smarter" than JSON, capable of serializing promises, closures, and complex object graphs. This meant it needed to be more complex, more powerful, and inevitably, more dangerous.

The vulnerability wasn't an implementation bug that slipped through code review. It was the predictable consequence of violating a fundamental security principle: complex deserialization of untrusted data leads to remote code execution. If you can't do it perfectly don't do it at all.

Traditional REST APIs avoid this entire class of vulnerabilities by using JSON, a deliberately limited data format that carries no execution context, no code, no object methods. JSON is "dumb" in exactly the right way: it's just data structures. The server receives JSON, validates it against expected schemas, and explicitly routes it to the appropriate handler. There's no deserialization of execution contexts, no automatic invocation of client specified code paths, no blurred boundaries between data and code.

Tight Coupling: The API That Isn't

React Server Components don't just introduce security risks; they eliminate architectural flexibility. When you mark a function with 'use server', you haven't created an API. You've created a React specific endpoint that can only be called by React clients using the Flight protocol.

Consider a traditional REST API:

@app.post('/api/posts')
def create_post(data):
    return db.posts.create(data)

This endpoint can be called by:

Your React frontend
Your mobile app (iOS/Android)
Your CLI tool
Partner integrations
Third-party developers
Any HTTP client in any language
Testing tools like curl or Postman

It can be documented with OpenAPI/Swagger. It can be monitored with standard HTTP tooling. It can be secured with standard WAF rules. It works with every language's HTTP library.

Now consider a Server Action:

'use server'
async function createPost(data) {
    return await db.posts.create(data);
}

This can be called by... your React frontend. That's it. It uses a proprietary protocol (Flight) that only React understands. It can't be documented in a language agnostic way. Standard HTTP monitoring tools can't parse the payloads. Security tools can't inspect the traffic. If you want to build a mobile app, you'll need to create a separate REST API anyway.

You haven't eliminated API boilerplate, you've just hidden it behind framework magic while simultaneously limiting who can use it. When your application inevitably needs to support multiple client types such as web, mobile, and CLI, you'll end up maintaining two parallel systems: Server Actions for your React web app, and a proper REST API for everything else. The "convenience" of Server Components becomes technical debt the moment you need to integrate with anything outside the React ecosystem.

The reusability problem extends beyond just multiple clients. Modern applications often need to expose webhooks for third-party services, integrate with partner APIs, or provide data to analytics platforms. None of these can consume React Server Actions. You're forced back to building traditional API endpoints, making the Server Actions redundant; a solution in search of a problem that just created more problems.

JavaScript Lock-In: Losing the Right Tool for the Job

Perhaps the most insidious aspect of React Server Components is the way they eliminate architectural choice. For 13 years, React worked with any backend. Your API server could be written in Python for data science and machine learning, Go for high-performance services, Rust for systems programming, Java for enterprise integration, or Ruby for rapid development. The choice was yours, based on your team's expertise and your application's requirements.

Server Components change this equation fundamentally. To use them, your server must be JavaScript—specifically, Node.js or a compatible runtime. The Flight protocol, the Server Actions routing, the serialization/deserialization. All of this requires a JavaScript runtime on the server.

This matters more than React advocates want to admit. JavaScript is a fine language, but it's not the right tool for every job:

Machine Learning and AI: Python dominates this space with mature ecosystems (PyTorch, TensorFlow, scikit-learn) and tools that don't have JavaScript equivalents. If your application needs to serve ML models, you'll need Python services anyway.

High-Performance Computing: For CPU-intensive work, systems programming, or services requiring fine-grained control over memory and concurrency, languages like Rust, Go, or C++ are simply better suited. JavaScript's single-threaded nature and garbage collection can be limiting factors.

Enterprise Integration: Many organizations have existing investments in Java or .NET ecosystems, with established patterns, libraries, and expertise. Forcing a JavaScript backend means either maintaining parallel systems or abandoning these investments.

Data Processing: For heavy data processing, languages like Python (with NumPy/Pandas), R, or even Julia provide better ergonomics and performance than JavaScript.

Traditional REST APIs let you choose the right tool for each job. Your frontend can be React (or Vue, or Svelte) while your backend leverages Python's data science libraries, Go's performance, or Java's enterprise ecosystem. Each layer uses the language that makes the most sense for its requirements.

Server Components eliminate this flexibility. Your entire stack must be JavaScript, regardless of whether it's the best choice for your backend requirements. This isn't just a technical limitation. It's an architectural straightjacket that forces technical decisions based on framework constraints rather than application needs.

The irony is that React's original success came partly from its flexibility. It was just a view library that worked with any backend. Server Components abandoned this principle in pursuit of "full-stack" integration. It traded away the architectural freedom that made React attractive in the first place.

The Broader Pattern

CVE-2025-55182 isn't an isolated incident. It's a symptom of a broader problem in the JavaScript ecosystem. There's a pattern of frameworks prioritizing developer convenience over architectural soundness, of "innovation" that ignores lessons learned in other ecosystems, of complexity marketed as simplicity.

React had a good thing. It was a solid client-side library with a clean security record. Then it tried to own the full stack, invented custom protocols to blur client-server boundaries, and ended up with CVSS 10.0 remote code execution vulnerabilities affecting nearly a million servers.

The traditional approach of clear separation between frontend and backend, standard protocols like HTTP and JSON, explicit API boundaries might seem old-fashioned but it works. It's secure. It's flexible. It doesn't lock you into a single language or ecosystem. And it doesn't require inventing custom serialization protocols that recreate vulnerabilities we learned to avoid decades ago.

Sometimes the boring solution is the right solution. Sometimes the old way was better. And sometimes "seamless developer experience" is just another way of saying "we hid the complexity until it exploded."

React Server Components represent a fundamental architectural mistake. Patching one exploit doesn't fix the underlying problem: you're still deserializing untrusted client data into server execution contexts. The next vulnerability is already there, waiting to be discovered. Because when you violate basic security principles in pursuit of convenience, vulnerabilities aren't bugs, they're features.

The Hidden Divide in Developer Culture

Peter Harrison — Wed, 19 Nov 2025 21:10:36 +0000

Sooner or later you inherit a codebase that makes you wonder if the previous developer lost a bet. I gave candidates exactly that kind of application; circular dependencies, no separation of concerns, a structural mess and asked them to extend it. Their reactions exposed a deeper cultural divide in how developers think about their work.

The initial app was a deliberate train wreck: violations of separation of concerns, circular dependencies, and no real interfaces. It exposed multiple endpoints such as HTTP and SMTP. The task was to add a new JMS endpoint.

The idea was simple. Applicants received instructions written in the voice of a business owner. It wasn’t a trick question or a strict feature-delivery test. Yes, they had to add the endpoint, but the real question was whether they’d confront the underlying mess. The framing made it clear they had full authority; the previous developer had vanished with his girlfriend, and nobody else was touching this code. They were inheriting the whole thing.

Feedback

I ran this exercise inside a Fortune 500 team. One pattern I saw immediately was defensiveness. Some felt judged. That was never the point. The goal was to understand how each developer thinks when they inherit a broken system.

The real question is simple:
Do you recognize the problems? And do you feel empowered to fix them?

Do you feel ownership of the whole application, or do you only feel responsible for the wording of the ticket?

The sharpest feedback came from capable developers who had spent years in cultures where they were actively discouraged from taking broader responsibility. They were rewarded for clearing tickets, not for improving architecture. They weren’t wrong. Many companies punish initiative unless management explicitly orders it, and as you know, management never does.

The lesson for me was that the reluctance wasn’t a lack of skill or values. It was learned behaviour. People internalize the norms of their past workplaces.

So the test works, just not in the way some expected. It reveals how a developer believes software development should operate. Do they wait for perfect requirements? Or do they roll up their sleeves and improve the area they’re working in?

Refactoring Nightmares

Since I’ve made such a strong case for taking ownership, it’s worth admitting the danger. Sometimes you spot a pattern in one class and realize the entire codebase is built on the same mistake. Fixing it “properly” means touching half the system.

This is where discipline matters. Pride in craftsmanship is good. Accidentally triggering a month-long refactor because you changed one function is not.

Developers can fall into this trap easily. I’ve seen people disappear for weeks, only to emerge with one enormous commit and a merge conflict from hell. Feature branches have the same risk; leave them running too long, and you’re basically refactoring in the dark. Merging daily avoids this, but I digress.

The point is that architectural improvements must be balanced with delivering value. Nobody is suggesting you go rogue and rebuild the world. But when you’re working in a part of the codebase, keep it clean. Use simple patterns. Avoid piling on more chaos. That’s the level of stewardship that matters.

Be a Senior

For me, seniority isn’t about wizard-level coding skills. It’s about responsibility.

A junior has little responsibility. They get clear tickets and follow the patterns they see. Intermediates work independently and start taking responsibility for local quality. Seniors go wider. They feel accountable for the entire system and the people working on it. They mentor. They think about longevity. They make the call when something needs refactoring and when it doesn’t.

This picture matters because the best indicator of senior-level thinking is the willingness to take broad responsibility. That’s what I’m actually testing for. Technical skill matters, but mindset matters more.

Seek broad experience. It shapes not only what you know, but how you carry the responsibility that comes with being a senior.

Development Musical Chairs

Peter Harrison — Thu, 06 Nov 2025 21:24:11 +0000

I've been through a dry spell or two. The early 90's was a pretty tough time for someone new to the industry. The dot com bust also led to belt tightening in the industry. There has always been an ebb and flow in demand, but those who eat and breath software sailed through those seas.

This time it's fundamentally different. Life has been pretty good for software developers over the last 40 years, but life does not owe software developers anything, and perhaps we are nearing the end of the gravy train.

Up until 1900 the horse was the primary mode of transportation. In a space of about ten years the car replaced horses in volume. Horses were no longer required. Sure, you can still find them today, in horse racing or on tourist ventures perhaps. But there is no law of nature which says "there will always be new jobs for horses".

And so it is I fear with programmers. Artificial Intelligence has arrived, runs at very low cost compared to humans, and can already perform much of the intellectual work of software developers. This is not to say it can replace developers, at least not yet, but the trend is unmistakable.

The answer we are told is to embrace AI, to become Data Engineers, Data Scientists, and adopt all the shiny new AI technologies. To this call there have been broadly two camps in software development. The first camp prides itself on its intellect, and decries the use of LLMs. For these developers using AI is an admission of incompetence. Or maybe they believe a machine will never be able to replace them.

The second camp is full on embracing AI. In some sense I am in that camp, as I have always been fascinated by AI and it has been a dream to work in that field. That said there is a more pragmatic reason; that state of the art AI really is a force multiplier. It enables me to accomplish far more than without it. From AI fans you may hear exhortations to learn about AI to remain relevant in the coming revolution.

The reality however is that the pie itself will shrink. We have already seen companies laying off software developers, more in the anticipation of the success of AI to replace them than there being any compelling reason. At least so far.

Today's LLMs are good. Five years ago the LLMs we see today would be considered science fiction. But despite the successes of LLMs they are not yet capable of replacing humans entirely. You still need humans in the loop. They can be a force multiplier for a software developer, allowing them to be far more productive than otherwise. But now there are also 'vibe coding' platforms where people with no development skills can develop software.

The AI revolution is not part of a cycle. There is a fundamental change occurring involving machine intelligence. In my naivety I initially believed that the technologists like myself would be the last to feel the pain of being replaced, but in fact it seems we are one of the first along with artists, writers and musicians.

'Learn to code' they said.

Even though AI won't replace developers outright initially, they will reduce the number needed. There will be an ever decreasing number of developers required. This will impact the salaries as the supply of developers will outstrip demand for them.

None of this requires anything near as grand as some magical AGI or even super intelligence. Gradual improvement is all that is needed. It will be like musical chairs for software developers, with a ever decreasing number of chairs. To get a chair the demands in terms of skills and experience will only increase. This in itself will cut off the supply of younger less experienced developers.

What is a software developer to do? Should we do what is needed to find a chair? Or are we horses in the age of cars?

My advice is this: learn to be a hairdresser. Even with robots coming, letting sharp objects near our heads is perhaps something humans won't trust bots with. This may be all in jest, as an aging chubby white dude I'm not exactly the typical demographic for hairdresser myself. I guess more seriously we should be looking at options that involve less sitting at a desk moving a mouse.

Or do we lobby to ban AI to protect the poor software developers?

Battle Scars from the Cloud Front

Peter Harrison — Fri, 31 Oct 2025 18:48:21 +0000

The Promise

It is no secret that Cloud platforms have been adopted by most organisations for running their infrastructure. Virtualization of infrastructure brings many advantages.

In the early 2000's I had to pay for the hardware and have it physically installed in a data center. You had to pay for a lease to host it. This was expensive and involved.

With Cloud based Virtual Machines we could spin up a machine at a moments notice, perform some work and then tear it down, paying only for the time it was up. Then along comes Docker and containerization, which reduces the footprint for an instance and makes it possible to easily scale based on a image.

Then comes Kubernetes to help manage those containers and configure the networking and create internal networks to interconnect your micro-services. Finally there are Lambdas and other net functions which eliminate even the need to worry about infrastructure at all. Just drop a function into AWS and connect it up to one of the services. Pay only for CPU you use.

There has been an evolution from hosting physical machines to Cloud platforms where you no longer even see the underlying machines but rather a monolithic platform service. The service handles the management of the infrastructure for you, freeing you to focus on the code. This is the promise of Cloud, and frankly it has delivered. So what is my problem with it?

With Clouds comes Sink

As any good glider pilot can tell you with any cloud comes sink, the smooth descending air which pulls you inexorably toward the earth.

Having worked in a number of environments now that utilize the Cloud platforms I think there are some pitfalls we need to discuss.

Inability to Run Locally

Before you reach for your keyboards, I know there are ways to run code locally. This point is about how Cloud development has encouraged complex configurations, resources and permissions which create barriers to being able to run your code locally. By 'locally' I include not being able to set up realistic sandpits on your Cloud platform.

In my experience developers have been expected to complete tickets and create a Pull Requests to bring code into a development branch from a feature branch on the basis of only passing unit tests. They may not have had access to databases to test their SQL against test data. They may not have had the opportunity to send message payloads to other services to validate they integrate properly.

Is this just me? Is it that Peter can't hack change? Well, from what I have seen many of the developers around me have been struggling with this problem. In the bad old days you would simply run everything on your local machine. But today there are platform services, permissions, and configurations which are more than environment. Platform configuration has become part of the application proper, meaning you can't run it locally.

Yes, I know Kubernetes can be run on your local box,only in my experience you can't just shift an application from your local system to the Cloud. Because configuration is now a explicit part of the app the infrastructure is more than just the substrate you run your app on. Similarly it is possible to run Lambdas locally, but there are limitations, and there really isn't a like for like substitute for running on the platform.

No Deploy on Commit

Related to the above point is that unit tests would not run when a feature branch build received a commit. Prior to this my experience was that every single commit would result in a build and unit tests run. If there were unit test failures you would get a report.

In more recent environments the Feature Branch approach was set up only to build on the development and master branches commits. Typically this would be when a PR was merged into development.

Of course, we should be building and running unit tests prior to commit. However, the lack of deployment means we don't get to see how a Lambda actually acts until it makes it into the development branch and is deployed into a development environment.

The 'development' environment in this context is a single environment for everyone, not the same thing as a local environment which developers can work in without impacting others.

Shifting System Complexity to the Platform

This has some overlap with micro-services which have been all the rage in cloud environments. Software used to be more monolithic, all the code being in one binary. There would be separation of concerns, in that the Database might be separate from the Web Server, but they would each have distinct capabilities.

The difference is that micro-services have been aligned with the domain, and so we now get a solution composed not of one or two major components, but dozens of interlocking small services playing a part in a complex web of dependencies.

In one recent example there was a system that involved sixteen separate repositories, each a separate deployable unit of Lambda functions. Some functions would directly call other Lambdas from other projects in code.

Now, some might say this is clearly the wrong thing to do, and they would be 100% correct, but the deeper question is how we got there. We have essentially broken up what would have been separate packages each with their own purpose but running in the same machine into separate services with complex dependencies on other services.

This has also resulted in complex deployment configurations, with the plumbing for all these service connections defined in the platform configuration rather than inside the application software.

Too many projects

Something else I have seen is that software is decomposed into micro-services which are then handed to separate teams. Each team might handle each service in their own way. This is partly a result of new services being developed over time and being bolted on.

As a result I have seen environments where projects are no longer maintained, where the developers have left, and there has been no continuity. As a result the new developers coming in are left with a menagerie of repositories, each dissimilar, written with different technologies.

The CI/CD pipelines may not even be working, and the configurations might be so old they no longer function. Or worse, there is no real definition of what makes up the system such that critical Lambdas are not really visible until you need to change it or it breaks.

Poor Service Dependency Visibility

Related to the number of services is the fact it can be very difficult to actually visualize how everything is connected. The direct call of a Lambda in one project to a Lambda in another was an example of a hidden dependency. There was no contract or exposed service on the receiving service, just a Lambda that could be called. The clients of this service performed direct calls to the Lambda.

In monolithic apps the dependencies can be followed directly in the IDE. You can follow call chains from class to class easily. At debug time you can even follow the execution pointer around. But when debugging issues in systems that involve many separate micro-services we now face a challenge of finding out exactly where the problem occurs.

Finding out how all the services depend on one another can be a real challenge, as there isn't one canonical place that this can be visualized. As discussed earlier it is even worse when you don't have debug access to a running system. You can't step through the code base to find an issue in a Lambda in a test system.

Summary

We like to think progress goes only in one direction, that the old was worse than the new. With Cloud platforms there are undeniable benefits, but not all is a box of butterflies. I've seen some real challenges that are at least in part a consequence of the impact of Cloud on developers workflow.

I want to be able to run and step debug a problem. I want an application to have a single well structured and maintained code base. I don't want many separate small services with ill defined interfaces running different technologies.

Full Stack Fatigue:

Peter Harrison — Mon, 27 Oct 2025 01:01:28 +0000

When I became a paid programmer I knew one language: DBase. Well, two if you count BASIC, but the less said about that the better. You could write a fully functional application in DBase, and distribute it as a exe file. You had to know something about data structures as well. The barrier to entry wasn't that steep.

Today what do you need to write an web application? You will need HTML, CSS, and Javascript. You will need to adopt a front end framework such as React. You will need to learn a back end language, which these days can also be Javascript, aka Node. Or you can use Java or Python. You will probably use a SQL database, so you will need to know SQL. You will need to expose services via REST, so will need a REST API framework. You will need to store your code in version control, which these days is usually Git. To deploy your application you will usually need to know about Cloud services, Docker, Kubernetes.

Your application will need to implement security and authentication, for which there is OAuth2. You will also need a CI/CD system, which was previously Jenkins, but now varies depending on the platform. You will need to learn Cloud Formation on AWS, Bicep on Azure to do infrastructure as code.

This isn't an advanced stack. This is the kind of skill set expected of a "full stack developer". As a software developer I have always known that you can't stay still. The old COBOL programmers had a good wicket for a while, but you get stranded on a declining island. So constant learning has always been a absolute necessity to stay relevant.

I had ended up specializing in integration and business automation, learning jBPM, Bonita, Activiti, but even there times are moving with new approaches which leave BPM type solutions in the dust.

Even though I have raced to adopt new skill sets it has become increasingly difficult to stay ahead of the skills demanded. And if I am having trouble the situation for junior developers must look like Mt Everest. Much less the fact that AI is now encroaching, making it even tougher for entry level positions.

There is a danger in thinking the present is just like the past. I would have thought the future would be easier for developers, better tooling, making life easier, but the evidence seems not to point there. AI in some respects makes things easier, but also more opaque, giving people power without tempering them with experience in software.

Should we expect people to be jack of all trades, able to handle everything from the front end to designing cloud infrastructure? When I began everything was on one PC, applications compiled to a single file. Today we have highly available distributed clusters, complex deployment pipelines and quality gates. It is good for developers to at least understand the whole stack, have some exposure to it, but having deep understanding of the whole stack has become unrealistic.

Are we cutting off the pipeline of young developers? Are we placing too many expectations on them? Is there a way to ease these expectations in the hiring process? Or do we think AI will be the silver bullet, removing the need for us to program at all?