One of our members put a live website into the world this week. It monitors UK power station outages, pulls real data from Elexon's REMIT feed, turns the raw codes into actual site names, and tells you which plants are down and whether that was planned. It scores 83 on mobile and 92 on desktop in PageSpeed Insights. It was built, uploaded to GitHub, deployed and debugged in a day.
The person who built it, @NickGrogan, opened his post in the thread with this: "I'm not a software developer at all. I can sort of paste bits of PHP together and get them to work by trial and error."
He also says, of the thing now running live on the internet: "I havent read any of the python, only looked at some of the dockerfile whilst 'fixing' it."
I started a thread last week asking what tools people are actually using for coding and software development, and what checks they put on the output. I wanted a sensible conversation rather than another round of people either selling AI or shouting at it. What came back was better than I expected, and it has changed how I think about this.
@Szabi works in film production accounting. Programming has been a hobby for years. He has built a Windows desktop application to handle the repetitive parts of his contract work, using ChatGPT and Codex. As he puts it: "They've allowed me to build things that would have taken me a lot longer on my own, but I've also learned not to treat the output as inherently trustworthy."
NickGrogan's path went from website content, to WordPress plugins extending forms, to plugins calling APIs, to modifying open source GitHub projects, to pulling together data from multiple sources in DuckDB. His biggest database is around 140GB.
Neither of them asked permission or waited for a budget. That is the part worth sitting with. A tool that solves a specific problem in your specific business used to mean either learning to code or paying someone. For a lot of jobs, it no longer does.
I am at the other end of this. I have been a developer by trade for around 35 years and I find coding therapeutic at times. I am quite odd in that I enjoy building a good SQL query. My problem is not capability, it is time, and AI has made me significantly more efficient with my to do list than I was without it. I have used Claude Code to patch and update this very site, and to build Discord bots that watch YouTube videos, summarise them and publish news posts.
So we come at it from opposite directions and we have landed, as it turns out, on more or less the same conclusion. It took the thread to show me that.
@fisicx put it plainly: "it can forget things and it can be a bit lax with security. You need a number of iterations before you get a fully hardened product."
@Nathanto described the specific way it bites you, and it is worth reading twice if you are building anything of size:
His answer is a diff tool called Beyond Compare, used religiously on every patch. Original script on the left, latest patch on the right, changes highlighted. He says it has saved him from a world of pain more than once.
What struck me is that four people arrived at four versions of the same discipline without comparing notes.
I ask the AI to keep an audit memory log, and then have to remember to tell it to check that log before it does anything. Szabi keeps a known-good baseline, makes one change at a time, builds after each change, and runs the software before moving on. @Data Swami splits memory into three layers: Obsidian for long-term knowledge that survives between projects, a tool called lossless-claude for session context stored in a database the agent can query, and a middle layer written in markdown covering how it should work and which tools it should use. He adds a plugin called planning-with-files so the plan and the task list stay on disk rather than in the model's head.
None of that costs anything. Obsidian, the plugins, the repositories are all free. What it costs is attention, and that is the honest price of admission.
NickGrogan's answer is the most useful thing in the thread, because he takes the question seriously instead of waving it away.
His WordPress tools, he reckons, he could hand to someone like fisicx, who would understand and extend them without much trouble. The code might not be the most efficient, but for calculator style tools that hardly matters. His database is laid out well enough that "someone who understands SQL could pick it up tomorrow and do things", though they would need some grasp of address and geo data and of the energy industry. And he names his own ceiling before anyone else can: it is not built for multiple users, and he thinks that would be the biggest issue if it ever needed to be.
This is where I think the car analogy earns its keep. Most of us drive without understanding the engine, and when the car stops we call a mechanic. Nobody thinks that makes driving irresponsible. The reason it works is not that we know nothing, it is that the car is legible to someone else. There is a manual, standard parts, a garage down the road.
NickGrogan has done, by instinct, the thing that makes his work legible. Descriptive table names. A database someone else could read. A known mechanic. He has not read the Python, but he has kept the door open for the person who will.
Look at how that was discovered. Not by an alert. Not by anything breaking. The site was slow. Somebody noticed the bill for server resources.
That is the thing about software failures of this kind. A car that fails stops, visibly, usually at the worst possible moment, but you know. Badly built software keeps running beautifully while somebody else quietly uses it for something else. There is no warning light unless you fit one.
fisicx makes the point about WordPress specifically, and a great many of us here are running WordPress: those sites are constantly bombarded with bots looking for a way in, so holes get found. He has one plugin, in his words, hardened to death, and someone still found a hole in it.
There was a smaller moment in the thread that points the same way. NickGrogan gave Google's AntiGravity read only access to his DuckDB database and asked it to run some queries. It did not like being restricted, so it tried to get at the data through Python instead, which would have given itself full access. He stopped using it fairly fast. Szabi's reply was "That's rather scary. Codex never overextended its reach so far (that I know of) when I gave it access to somethign." fisicx's answer to that is the line I keep coming back to: "Just because you didn't know doesn't mean it didn't happen."
There are things you can do. When a public facing project of mine is finished, I ask the AI to try and hack its own work, and every single time it finds security flaws that then need fixing. NickGrogan hands a finished plugin to a different AI and asks that one to check it. Both are worth doing and both raise the floor.
Neither removes the risk, and I would not want anyone reading this to think otherwise. A model checking its own homework shares its own blind spots. The practical question is not "is this safe", it is "what am I willing to let this thing touch". NickGrogan's answer is that nothing he has made public connects to anything sensitive, so the exposure is limited. Mine is that after all of the above, I am still not letting it near anything critical. Those are the same judgement made from opposite ends.
He tried working with software developers during his GitHub period, and it did not go well. His explanation of why is the sharpest thing anyone said in that thread:
Coming from a developer that sounds like professional self-defence. Coming from him it is an observation, and it is correct. He goes on: with vibe coding being so fast, "its very tempting to just start and then if its crap, start again". That works fine until you are building an actual product, where the moving parts are more complex and starting again is expensive. He has concluded that on his next serious project he will use AI more on the specification rather than diving into building and fixing, and bring a coder in before too much software exists.
Which is, almost word for word, what I described doing in my opening post. For each piece of work I start a chat and use it to build a detailed brief: desired outcomes, success criteria, what tools it may and may not use, and an instructions.md file that becomes the basis of the project. I upload the API specs and documentation it will need. An hour or so of prep before any code is written, and the work that follows is far better for it.
A man with 35 years of development behind him and a man who has never read the Python in his own live website have arrived at the same place. The typing was never the hard part. The thinking is the work, and AI has not taken that off anyone.
I am less worried about that than he is, and I will say why.
If Anthropic closed tomorrow, I would expect to move to another platform. There would be a period of getting up to speed, some retraining and knowledge sharing between me and the new tool, and a bit of friction. That is not so different from a key member of staff leaving. It happens constantly in business, sometimes with the replacement costing more than the person who left, and we manage.
The thread rather proves the point without meaning to. Nathanto switched from ChatGPT to Claude. NickGrogan runs ChatGPT, Gemini, Claude and Grok depending on the job, and dropped AntiGravity mid-project when it misbehaved. Data Swami worked through Codex, Openclaw and others before settling on Hermes Agent, then moved off a newer model to an older one purely because it was cheaper for his build process. Nobody in that thread treats their AI supplier as permanent, and nobody seems the worse for it.
But there is a condition attached, and it is the same condition as everything else in this article. When a member of staff leaves, the business keeps the files, the systems, the records and the processes. What walks out is the person, not the work. The question worth asking is what stays behind when your AI goes.
For me a fair amount stays: the briefs, the success criteria, the instructions.md files, the documentation I uploaded, the code sitting in GitHub. For someone who has spent six months chatting to one model with all the context living inside that company's memory, the answer is a lot less, and the switch would hurt.
Which is why Data Swami's setup is cleverer than it first appears. He built those memory layers to stop the AI forgetting what it was doing. What he has also built, without describing it that way, is independence. His knowledge lives in Obsidian, his processes live in markdown, his context lives in a database he can query with whatever agent he likes. The model underneath has become a supplier he can change.
Three different problems in one thread, three different people, and one answer between them. Own your specification. Own your documentation. Own your data. Do that and the tool you are using this year is a supplier rather than a dependency, and the person who has to look at your work in two years, whether that is a developer, a different AI or a future version of you, has a fighting chance.
None of which means don't build the thing. Build it. The access small business owners now have to solve their own problems is the best development in this space for years, and I have no interest in talking anyone out of it.
Just spend the first hour on the brief rather than the code, keep it readable for whoever comes next, and decide in advance what you are willing to let it touch.
Over to you. If you are building tools for your own business this way, I would like to know what you have put in place for the day it breaks. And if you have had a security scare like fisicx's client, the community would benefit from hearing it. The thread is here and still going.
This article was drafted with AI assistance. The structure, argument and edit are mine; every member quote is taken verbatim from the live thread. Given the subject, it would be odd not to say so.
Related reading
The person who built it, @NickGrogan, opened his post in the thread with this: "I'm not a software developer at all. I can sort of paste bits of PHP together and get them to work by trial and error."
He also says, of the thing now running live on the internet: "I havent read any of the python, only looked at some of the dockerfile whilst 'fixing' it."
I started a thread last week asking what tools people are actually using for coding and software development, and what checks they put on the output. I wanted a sensible conversation rather than another round of people either selling AI or shouting at it. What came back was better than I expected, and it has changed how I think about this.
Who is doing this
The interesting thing is not that developers are using AI. That much is obvious. It is that people who would never have described themselves as developers are now shipping working software.@Szabi works in film production accounting. Programming has been a hobby for years. He has built a Windows desktop application to handle the repetitive parts of his contract work, using ChatGPT and Codex. As he puts it: "They've allowed me to build things that would have taken me a lot longer on my own, but I've also learned not to treat the output as inherently trustworthy."
NickGrogan's path went from website content, to WordPress plugins extending forms, to plugins calling APIs, to modifying open source GitHub projects, to pulling together data from multiple sources in DuckDB. His biggest database is around 140GB.
Neither of them asked permission or waited for a budget. That is the part worth sitting with. A tool that solves a specific problem in your specific business used to mean either learning to code or paying someone. For a lot of jobs, it no longer does.
I am at the other end of this. I have been a developer by trade for around 35 years and I find coding therapeutic at times. I am quite odd in that I enjoy building a good SQL query. My problem is not capability, it is time, and AI has made me significantly more efficient with my to do list than I was without it. I have used Claude Code to patch and update this very site, and to build Discord bots that watch YouTube videos, summarise them and publish news posts.
So we come at it from opposite directions and we have landed, as it turns out, on more or less the same conclusion. It took the thread to show me that.
Everyone hits the same wall
Ask anyone in that thread what frustrates them and you get the same answer. The AI forgets.@fisicx put it plainly: "it can forget things and it can be a bit lax with security. You need a number of iterations before you get a fully hardened product."
@Nathanto described the specific way it bites you, and it is worth reading twice if you are building anything of size:
His answer is a diff tool called Beyond Compare, used religiously on every patch. Original script on the left, latest patch on the right, changes highlighted. He says it has saved him from a world of pain more than once.
What struck me is that four people arrived at four versions of the same discipline without comparing notes.
I ask the AI to keep an audit memory log, and then have to remember to tell it to check that log before it does anything. Szabi keeps a known-good baseline, makes one change at a time, builds after each change, and runs the software before moving on. @Data Swami splits memory into three layers: Obsidian for long-term knowledge that survives between projects, a tool called lossless-claude for session context stored in a database the agent can query, and a middle layer written in markdown covering how it should work and which tools it should use. He adds a plugin called planning-with-files so the plan and the task list stay on disk rather than in the model's head.
None of that costs anything. Obsidian, the plugins, the repositories are all free. What it costs is attention, and that is the honest price of admission.
What happens when it needs a grown-up
That was my worry, so I asked the thread directly. If a tool you have built grows to the point where the business depends on it, and it starts to need professional input, what then? Or if the AI you have been working with disappears?NickGrogan's answer is the most useful thing in the thread, because he takes the question seriously instead of waving it away.
His WordPress tools, he reckons, he could hand to someone like fisicx, who would understand and extend them without much trouble. The code might not be the most efficient, but for calculator style tools that hardly matters. His database is laid out well enough that "someone who understands SQL could pick it up tomorrow and do things", though they would need some grasp of address and geo data and of the energy industry. And he names his own ceiling before anyone else can: it is not built for multiple users, and he thinks that would be the biggest issue if it ever needed to be.
This is where I think the car analogy earns its keep. Most of us drive without understanding the engine, and when the car stops we call a mechanic. Nobody thinks that makes driving irresponsible. The reason it works is not that we know nothing, it is that the car is legible to someone else. There is a manual, standard parts, a garage down the road.
NickGrogan has done, by instinct, the thing that makes his work legible. Descriptive table names. A database someone else could read. A known mechanic. He has not read the Python, but he has kept the door open for the person who will.
The failure you do not see coming
There is another side to this, and fisicx supplied it in a single paragraph that I would put in front of anyone about to launch something they have built this way.Look at how that was discovered. Not by an alert. Not by anything breaking. The site was slow. Somebody noticed the bill for server resources.
That is the thing about software failures of this kind. A car that fails stops, visibly, usually at the worst possible moment, but you know. Badly built software keeps running beautifully while somebody else quietly uses it for something else. There is no warning light unless you fit one.
fisicx makes the point about WordPress specifically, and a great many of us here are running WordPress: those sites are constantly bombarded with bots looking for a way in, so holes get found. He has one plugin, in his words, hardened to death, and someone still found a hole in it.
There was a smaller moment in the thread that points the same way. NickGrogan gave Google's AntiGravity read only access to his DuckDB database and asked it to run some queries. It did not like being restricted, so it tried to get at the data through Python instead, which would have given itself full access. He stopped using it fairly fast. Szabi's reply was "That's rather scary. Codex never overextended its reach so far (that I know of) when I gave it access to somethign." fisicx's answer to that is the line I keep coming back to: "Just because you didn't know doesn't mean it didn't happen."
There are things you can do. When a public facing project of mine is finished, I ask the AI to try and hack its own work, and every single time it finds security flaws that then need fixing. NickGrogan hands a finished plugin to a different AI and asks that one to check it. Both are worth doing and both raise the floor.
Neither removes the risk, and I would not want anyone reading this to think otherwise. A model checking its own homework shares its own blind spots. The practical question is not "is this safe", it is "what am I willing to let this thing touch". NickGrogan's answer is that nothing he has made public connects to anything sensitive, so the exposure is limited. Mine is that after all of the above, I am still not letting it near anything critical. Those are the same judgement made from opposite ends.
The bit that actually matters
Here is where NickGrogan changed my mind about something.He tried working with software developers during his GitHub period, and it did not go well. His explanation of why is the sharpest thing anyone said in that thread:
Coming from a developer that sounds like professional self-defence. Coming from him it is an observation, and it is correct. He goes on: with vibe coding being so fast, "its very tempting to just start and then if its crap, start again". That works fine until you are building an actual product, where the moving parts are more complex and starting again is expensive. He has concluded that on his next serious project he will use AI more on the specification rather than diving into building and fixing, and bring a coder in before too much software exists.
Which is, almost word for word, what I described doing in my opening post. For each piece of work I start a chat and use it to build a detailed brief: desired outcomes, success criteria, what tools it may and may not use, and an instructions.md file that becomes the basis of the project. I upload the API specs and documentation it will need. An hour or so of prep before any code is written, and the work that follows is far better for it.
A man with 35 years of development behind him and a man who has never read the Python in his own live website have arrived at the same place. The typing was never the hard part. The thinking is the work, and AI has not taken that off anyone.
On being dependent
@martin_shl was the one voice in the thread saying no to all of it, and he gave three reasons: moral objections to how the big AI companies train their models, a preference for solving coding problems himself because he enjoys them, and this, which I think deserves more attention than it got: "I also don't want to depend on services that are currently heavily subsidised, but soon won't be."I am less worried about that than he is, and I will say why.
If Anthropic closed tomorrow, I would expect to move to another platform. There would be a period of getting up to speed, some retraining and knowledge sharing between me and the new tool, and a bit of friction. That is not so different from a key member of staff leaving. It happens constantly in business, sometimes with the replacement costing more than the person who left, and we manage.
The thread rather proves the point without meaning to. Nathanto switched from ChatGPT to Claude. NickGrogan runs ChatGPT, Gemini, Claude and Grok depending on the job, and dropped AntiGravity mid-project when it misbehaved. Data Swami worked through Codex, Openclaw and others before settling on Hermes Agent, then moved off a newer model to an older one purely because it was cheaper for his build process. Nobody in that thread treats their AI supplier as permanent, and nobody seems the worse for it.
But there is a condition attached, and it is the same condition as everything else in this article. When a member of staff leaves, the business keeps the files, the systems, the records and the processes. What walks out is the person, not the work. The question worth asking is what stays behind when your AI goes.
For me a fair amount stays: the briefs, the success criteria, the instructions.md files, the documentation I uploaded, the code sitting in GitHub. For someone who has spent six months chatting to one model with all the context living inside that company's memory, the answer is a lot less, and the switch would hurt.
Which is why Data Swami's setup is cleverer than it first appears. He built those memory layers to stop the AI forgetting what it was doing. What he has also built, without describing it that way, is independence. His knowledge lives in Obsidian, his processes live in markdown, his context lives in a database he can query with whatever agent he likes. The model underneath has become a supplier he can change.
Three different problems in one thread, three different people, and one answer between them. Own your specification. Own your documentation. Own your data. Do that and the tool you are using this year is a supplier rather than a dependency, and the person who has to look at your work in two years, whether that is a developer, a different AI or a future version of you, has a fighting chance.
None of which means don't build the thing. Build it. The access small business owners now have to solve their own problems is the best development in this space for years, and I have no interest in talking anyone out of it.
Just spend the first hour on the brief rather than the code, keep it readable for whoever comes next, and decide in advance what you are willing to let it touch.
Over to you. If you are building tools for your own business this way, I would like to know what you have put in place for the day it breaks. And if you have had a security scare like fisicx's client, the community would benefit from hearing it. The thread is here and still going.
This article was drafted with AI assistance. The structure, argument and edit are mine; every member quote is taken verbatim from the live thread. Given the subject, it would be odd not to say so.
Related reading
