I have been developing a penetration-testing platform called Canvas for years. Calling myself a developer would be generous. I am a penetration tester who learned enough Python, JavaScript and databases to try to turn an idea into software. For three or four years, I worked on Canvas whenever client work allowed it. That was part of the problem. Pentesting pays the bills, so Canvas got whatever time remained: a quiet weekend, a few days between projects, occasionally a longer gap. Then another project would arrive and Canvas would stop. When I returned weeks or months later, I often needed the better part of a week just to remember where I was. Why had I structured that module this way? What was I planning to do next? Why had I rejected the alternative approach? Which pieces were unfinished, and which apparently strange decisions had actually been deliberate? After several years of this, I had produced fewer than 3,000 lines of Python and JavaScript.
Lines of code are, of course, a terrible measure of software quality. But in this case they tell you something about velocity. A tiny fraction of the functionality I imagined existed. What did exist was buggy. Progress was painfully slow. The problem was not that I didn’t know what I wanted Canvas to do. I knew that very well. The problem was execution.
Then execution got cheap
Today, Canvas contains more than 160,000 lines of code and has become almost unrecognizable compared with that early version. Again, the 160,000 number is not important because more code means better software. It doesn’t. What matters is what became possible.
Canvas now integrates with multiple security scanners. It integrates with Burp Suite, the de facto working environment for much of web application penetration testing. It orchestrates testing workflows, stores and processes findings and evidence, supports increasingly sophisticated automation, and is evolving toward AI-assisted analysis of captured application traffic. Some of those integrations would have been effectively impossible for me to build before AI. Not theoretically impossible. I could perhaps have spent years learning everything necessary, or hired developers to do it. But practically impossible.
And AI has not merely made me faster at writing software. It has made small fragments of time useful. Consider a Sunday morning. My family is still asleep. I have perhaps two hours.
In the old world, that was barely enough time to reopen the project, stare at my own code, work out where I had left things and reconstruct the mental model I had lost since the previous development session. By the time I was productive, the morning was over.
Today, I can sit down with a coffee and ask the AI where we left off. It can remind me what was on the development agenda, what problems were unresolved, which architectural choices were still pending and what we had previously discussed about them. I can challenge those choices. We can explore two or three alternatives. I make the decision. Then the AI starts implementing it while I go and have breakfast with my family. A year ago, that workflow would have sounded ridiculous to me.
AI has not merely supplied programming labor. It has created something resembling cognitive continuity for a project I can only work on intermittently. That has changed what my limited time is worth.
The bottleneck moved
The most important change is not that I can produce more code. It is that writing the code is increasingly no longer the difficult part. Recently, I wanted Canvas to stop depending entirely on scanners running inside virtual machines on my own virtualization infra. Why should scanner capacity be tied to the machines I happen to own?
Canvas can now deploy scanner workloads to cloud infrastructure when needed. That change took roughly an hour to implement. Think about what happened there. The difficult question was no longer:
- Can I build this?
The important questions became:
- Should scanner execution be local, remote or hybrid?
- How should jobs be distributed?
- What happens when capacity expands dynamically?
- How do I keep costs under control?
- How should scanner instances authenticate?
- What happens when one disappears halfway through a job?
- What information is allowed to leave the core environment?
- How much of this complexity is actually useful to the pentester?
Those are architecture, security, scalability and product questions. The implementation cost of changing the system had collapsed so dramatically that the value moved somewhere else. It also changes the development process itself. Traditional software development often follows a waterfall model: make the major architectural and product decisions up front, then implement against them because changing direction later is expensive. When implementation becomes cheap, an iterative approach becomes much more practical. You can build a version, use it, discover what is wrong and change the design without treating every revision as a crisis. The same thing happens with Canvas’s AI architecture.
Capturing traffic from Burp, moving it through a central queue, sanitizing it, sending selected material to different AI models, retaining useful results and associating them with findings is a substantial engineering problem.
AI can help build all of that. But it cannot relieve me of the important decisions.
- Should session cookies ever leave the environment?
- What about Authorization headers?
- API keys?
- Credentials?
- Which information should be permanently retained?
- Should a client be allowed to restrict processing to a local model?
- When can an external open-source model be used?
- When, if ever, should a frontier model receive client data?
- Where does automated analysis stop and human review begin?
Generating the plumbing is becoming cheap. Deciding what the plumbing is allowed to do is not.
This connects directly with something I have argued in my previous articles about AI: when execution becomes cheap, judgment becomes relatively more valuable. Canvas let me watch that happen in front of me.
AI made “being wrong” cheaper
There is another consequence I did not anticipate. I can afford to change my mind. Traditional software development makes bad early decisions expensive. Once enough code depends on an architecture, rewriting it becomes painful.
Developers quite reasonably resist requests such as:
I’ve been thinking about this for a few weeks. I don’t like how this entire module works anymore. Can we redesign it?
Ask for enough large refactors and I suspect your developer may eventually board a plane, locate you personally and slap you. I would probably deserve it.
With AI, however, my development style has become radically more iterative.
- Build it.
- Use it.
- Discover what is wrong.
- Change the model.
- Refactor.
- Try again.
- Sometimes rewrite a surprisingly large part of it.
The important consequence is not merely that implementation became cheaper. Being wrong became cheaper. That matters enormously.
If implementation is expensive, you spend a great deal of effort trying to make the correct decision before building. If experimentation is cheap, you can often learn more by building, observing and correcting. AI therefore does not merely accelerate an existing software-development process. It can change the optimal process itself.
What about actual software developers?
This is where the argument becomes uncomfortable.
I have worked with developers who asked me extremely basic security questions.
What is XSS?
That does not mean they were bad people or even necessarily bad developers. Security simply wasn’t part of their expertise.
I have also worked with developers who challenged me on extraordinarily subtle security questions: browser-specific behavior, CORS exploitation conditions, authentication mechanics and edge cases deep enough that we could spend considerable time debating whether a theoretical attack was actually exploitable under a particular browser and application architecture.
Those two people may have the same job title. They are not providing the same value. This is why I do not believe the useful distinction is going to be developer versus non-developer.
Experienced software engineers can bring architecture, system design, security knowledge, reliability engineering, scalability experience, debugging ability and years of accumulated judgment. AI making code generation cheaper can make those abilities more valuable, not less. But another part of software development looks far more exposed: converting sufficiently well-defined requirements into code. For a very long time, those two activities were bundled together. We needed developers to make technical decisions because we also needed developers to type the software into existence. AI is beginning to separate them. And that leads to an uncomfortable thought:
Perhaps software development is too important to remain constrained by the economics of software developers.
That sentence sounds anti-developer. It is not. It is a distinction between the interests of a profession and the purpose of an activity.
The purpose of software development is not to create software-development jobs. It is to create useful software.
Those objectives have historically aligned because developers were the scarce resource required to create software. They may not always align. And that creates a broader question. When a technology allows society to produce much more of something useful with much less human execution, should the goal be to preserve the old production model? Or should the goal be to capture the productivity gain while managing the human cost of transition? That question is not unique to software. It is simply arriving there now.
The software that never got built
This is where I think the consequences could be much larger than the current argument about programming jobs suggests. Canvas is useful to me. But would Canvas ever have justified hiring a team of experienced software engineers for several years? Probably not. So without AI, the realistic alternatives were not:
Canvas built by me versus Canvas built by employed software developers.
The more likely alternatives were:
Canvas built with AI versus Canvas never really existing.
There must be millions of potential applications in that category. Specialist tools for small professions. Internal applications for companies. Scientific utilities. Small-business automation. One-off integration systems. Software designed around the workflow of fifty people rather than fifty million. Tools created by accountants, doctors, engineers, lawyers, auditors and security professionals who deeply understand a problem but could never economically justify a development team.
For decades, we have rationed software because software was expensive to create.
A company may identify twenty useful automation opportunities and build three.
A small business may identify ten and build none.
A specialist may know exactly what software their profession needs and never get beyond an Excel spreadsheet.
AI potentially unlocks this enormous long tail.
And that may matter far more than whether the next version of some benchmark says one model is a better programmer than another.
Good enough
I have noticed something else while developing Canvas. I increasingly do not need the world’s best AI model for every development task. Open models have improved enormously. Models such as GLM have handled substantial development and redesign work for me. Cursor’s Auto mode now handles tasks I would not have trusted it with less than a year ago. Economic disruption does not require AI to become a flawless replacement for the world’s best software engineer. It merely needs enough models to cross the good enough threshold.
Good enough to understand the existing system, to implement a feature, to refactor, to integrate two systems, to fix its mistakes.
Once implementation intelligence becomes sufficiently competent, abundant and inexpensive, the economics change even if exceptional human engineers remain better. The important threshold may not be perfection. It may simply be sufficiency.
Abundance creates its own problems
None of this means AI automatically produces good software. Quite the opposite. If producing code becomes nearly effortless, producing enormous quantities of bad code also becomes nearly effortless. At 160,000 lines, Canvas contains far more code than I could realistically inspect line by line. That creates new responsibilities.
- Architecture matters more.
- Automated testing matters more.
- Security review matters more.
- Dependency management matters more.
- Logging and observability matter more.
- Source control and disciplined change management matter more.
AI can eliminate an implementation bottleneck and create a governance bottleneck almost immediately. This is another reason experienced engineers are not suddenly irrelevant. Cheap execution increases the leverage of good technical judgment – and also increases the damage that poor judgment can cause. The objective cannot be to generate the maximum amount of software. It has to be to generate the maximum amount of useful, maintainable and secure software.
I never needed to become a great programmer
For years, I thought the problem with Canvas was that I needed to become better at programming. In retrospect, that may have been the wrong problem. My real contribution to Canvas was never Python syntax. It was knowing what information a tester needs, how assessments evolve, how evidence relates to findings, where automation helps, where it becomes dangerous, which security decisions matter and which features look impressive but add little practical value.
Programming was the translation layer between that knowledge and a working product. And that translation layer was extraordinarily expensive. Now all of a sudden, it is becoming cheap.
This is the same shift I have been exploring in my other writing about AI. As execution becomes abundant, human value does not simply disappear. It moves.
- From producing the output to deciding what the output should be.
- From implementing the design to challenging the design.
- From following the process to understanding why the process exists.
- From asking Can we build this? to asking Should we?
For decades, we have rationed software because coding was expensive. We may be entering an era in which we no longer have to. If that happens, the scarce resource will no longer be our ability to build things. It will be our ability to decide what deserves to be built.