Peter Naur argued in his famous essay Programming as Theory Building that documentation alone cannot fully capture or preserve the complete mental model behind a program.
However, AI works differently from humans in that much more of its working context has to be made explicit. Because of that, there may be some fundamentally different way for AI to maintain or reconstruct a program’s overall model.
But then, how do you keep the theory in your own mind enough to steer the agents to extend the program? I've been asking around, and different people seem to have different ways, colored by the way they work.
I think it largely depends on individual workflows, and there is no single right answer. Software is at once deeply personal, inherently collaborative, and heavily shaped by communication dynamics.
Naur argued that when a team disbands, the program dies. But in an era where the primary maintainer is no longer human, but an AI agent, how should we approach this?
My take is that we will lean heavily on concepts like Algebraic Data Types (ADTs) and state machines—making state definitions something humans can readily track through explicit specifications—while modularizing boundaries so that humans only need to retain the interfaces.
In other words, rather than keeping low-level implementation details in our heads, systems will be structured around high-level interfaces, data flows, core capabilities, and first-class functions.
Of course, the prevailing assumption today is still that humans must grasp the underlying implementation to work effectively. There are trade-offs to both models, and the optimal balance will naturally vary across different workflows.
Ultimately, the core issue is this: when something goes wrong within the AI's internal implementation, will we actually be able to steer it? And as you know, even ADTs must eventually change when business requirements shift. I haven't thought deeply about how to handle that yet, either.
It's an open question that neither experienced programmers like yourself nor less experienced ones like me have the definitive answer to. Software is heavily dependent on highly personal contexts. My answers and experiences won't neatly apply to your context, and vice versa.
My guess is that we might eventually need an entirely new programming language. What would that language look like? I have no idea. IDEs might also shift away from traditional text blocks toward a UI-based, flowchart-like approach. I imagine a system somewhat like n8n, where we can visualize and track the workflows and code blocks generated by the AI.
I recently did a few "vibe coding" projects with AI. It churned out 50,000 to 60,000 lines of code in an instant, and I couldn't keep up. To cope, I built a tool to visualize and track the code's dependencies. It worked out much better than I expected.
The caveat, of course, is that with tools like Unreal Blueprints or n8n, the visual dependency graph eventually explodes as the program grows, turning the UI itself into a bottleneck. Perhaps the solution will be that programs up to a certain size are abstracted into single nodes, which can then be clicked to expand and reveal the underlying implementation details.
jdw64 · · focus · HN ↗
However, AI works differently from humans in that much more of its working context has to be made explicit. Because of that, there may be some fundamentally different way for AI to maintain or reconstruct a program’s overall model.
iamwil · · focus · HN ↗
jdw64 · · focus · HN ↗
Naur argued that when a team disbands, the program dies. But in an era where the primary maintainer is no longer human, but an AI agent, how should we approach this?
My take is that we will lean heavily on concepts like Algebraic Data Types (ADTs) and state machines—making state definitions something humans can readily track through explicit specifications—while modularizing boundaries so that humans only need to retain the interfaces.
In other words, rather than keeping low-level implementation details in our heads, systems will be structured around high-level interfaces, data flows, core capabilities, and first-class functions.
Of course, the prevailing assumption today is still that humans must grasp the underlying implementation to work effectively. There are trade-offs to both models, and the optimal balance will naturally vary across different workflows.
Ultimately, the core issue is this: when something goes wrong within the AI's internal implementation, will we actually be able to steer it? And as you know, even ADTs must eventually change when business requirements shift. I haven't thought deeply about how to handle that yet, either.
It's an open question that neither experienced programmers like yourself nor less experienced ones like me have the definitive answer to. Software is heavily dependent on highly personal contexts. My answers and experiences won't neatly apply to your context, and vice versa.
My guess is that we might eventually need an entirely new programming language. What would that language look like? I have no idea. IDEs might also shift away from traditional text blocks toward a UI-based, flowchart-like approach. I imagine a system somewhat like n8n, where we can visualize and track the workflows and code blocks generated by the AI.
I recently did a few "vibe coding" projects with AI. It churned out 50,000 to 60,000 lines of code in an instant, and I couldn't keep up. To cope, I built a tool to visualize and track the code's dependencies. It worked out much better than I expected.
The caveat, of course, is that with tools like Unreal Blueprints or n8n, the visual dependency graph eventually explodes as the program grows, turning the UI itself into a bottleneck. Perhaps the solution will be that programs up to a certain size are abstracted into single nodes, which can then be clicked to expand and reveal the underlying implementation details.
nottorp · · focus · HN ↗
LLMs don't retrain, it's too expensive atm.