A reflex we need to let go of
Every time someone writes about vibecoding, AI-generated code, or non-technical people building apps, the same reaction surfaces: "Sure, but then it has to go to IT." The code needs to be refactored. Secured. Deployed. Monitored. A CI/CD pipeline set up. Documentation written. And so on.
It's a reflex. A professional habit born from decades in which making software simply worked that way. But that reflex no longer holds.
"Then it goes to IT…" — an overstated argument
1. AI makes mistakes today. Far fewer tomorrow.
Yes, AI-generated code contains bugs — sometimes hallucinations, sometimes subtle logic errors, and sometimes outright glaring mistakes. That's a valid criticism. But it's a snapshot, not a structural argument.
Anyone who said in 2012 that self-driving cars would never be safe was right at the time. Anyone saying that today is looking at the current point on the curve rather than the curve itself.
AI improves continuously. The code quality of AI models has advanced spectacularly over two years. The argument "AI makes mistakes, so IT must take over" evaporates as that margin of error shrinks.
2. Not every app needs enterprise-grade security
The IT department thinks in terms of banking systems, medical records, and government infrastructure. But most software being built today is nothing of the sort.
A few examples of apps where security isn't a critical factor:
- An internal dashboard tracking weekly coffee consumption
- An onboarding app helping new employees discover the company
- A simple webshop for a local bakery
- A prototype to test a product idea with thirty users
- An internal FAQ chatbot for onboarding new staff
None of these apps require a three-week security audit or a penetration test. They require a working product built quickly.
3. Deployment and infrastructure are already solved
Platforms have taken over the entire infrastructure layer. You push code, they deploy. Automatically. With rollbacks, logging, and scalability built in. Databases, authentication, scaling — these have become products, not specialisms.
4. Maintenance becomes a prompt
In the classic model, maintenance is a permanent cost: fixing bugs, updating dependencies, adding features. That requires a developer who knows and guards the codebase.
In an AI-driven model, maintenance is a different kind of conversation.
- "The button stopped working after the last update." → Describe the problem, AI locates and fixes it.
- "We want to add an export function." → Describe what you want, AI builds it.
- "There's a new API version from our supplier." → Paste in the documentation, AI updates the integration.
Maintenance is no longer a separate discipline. The threshold for making a change drops to near zero. Maintenance used to be one of the strongest arguments for permanent teams. That argument disappears.
5. Time-to-market beats almost everything
An app that goes live in three days and solves 80% of the problem is, in most cases, worth more than an app that goes live in three months and solves the problem perfectly.
The classic IT cycle was built for an era in which software was scarce and expensive. In an era of AI coding, software is abundant and cheap. The bottleneck shifts from making to experimenting.
6. Value shifts to other domains
When AI writes the code and maintenance becomes a prompt, real value shifts to everything surrounding the code: ideation, analysis, user testing, support, marketing, documentation, planning. Human skills. Domain knowledge. Empathy. Things where traditional IT departments have historically added little value.
A new model: Human Assisted Coding (HAC) — do it yourself with AI when you can, bring someone in when needed
Human Assisted Coding — HAC for short (we do love acronyms in IT) — is where a small team sits down and lets AI write the code. Where needed, the help of an IT expert is brought in on a temporary basis.
Not a permanent department of dozens of ICT specialists who need to weigh in on everything, but targeted expertise at the right moment:
- A code review after the first version
- A security audit when the app processes sensitive data
- A pentest before going live with a more sensitive app
- A marketer who sharpens the positioning
- A lawyer who reviews the terms of service
- A tax advisor when the business model gets complex
This is how lawyers and accountants have worked for years. You bring in expertise when you need it, not as permanent headcount out of habit.
What's interesting is that this model also largely defuses the security criticism. Platforms offering infrastructure today increasingly enforce good security practices at the architecture level — not as a checklist, but as the only way to build. User management, payments, API keys: they flow through the right channels or they simply don't work. The foundational layer is covered without needing to bring an expert in-house.
What remains for the expert is the edge case: the app that genuinely processes sensitive data, the payment flow that needs thorough testing, the legal dimension that requires domain knowledge. These are real situations, but they don't justify a permanent IT department. They justify a targeted engagement.
One system for the full picture
The logical next step is an environment that brings all of this together. Not ten separate tools for infrastructure, documentation, support, planning, and expert matching — but one system from which you both build and manage, and from which you find the right expert when you need one.
That's the direction DotBots Boutique is working toward: infrastructure and security as a platform, combined with support for the surrounding processes that increasingly determine value, and matching with technical and non-technical profiles when you want to go further than what you can do on your own.
Not as a replacement for expertise, but as the environment that determines when you truly need that expertise — and makes it easy to find.
Conclusion
The next phase of software development won't be won by the organisation with the largest IT department. It will be won by the organisation that turns ideas into working products the fastest, that learns from users the fastest, and that brings in the right expertise at the right moment — deliberately, not out of habit.
Do it yourself when you can. Bring someone in when you need to.
That sounds simple. But it requires a different way of thinking about how organisations build, manage, and support software. That shift is underway. The only question is how quickly your organisation wants to move with it.
Last updated: 2026-05-29 11:35