Posted by: Sotiris Filippidis
15 June 2026
AI-assisted development is already here, and it's already gaining ground. (Take a note, I said "AI-assisted", not "AI").
A few years ago, building even a relatively straightforward website or web application could easily require weeks, sometimes months, of work. Planning, setup, database structure, UI, admin area, integrations, deployment, debugging, all the usual stuff.
Today, a developer can sit down with an AI tool, describe what they want, iterate quickly, fix a few things, connect a few pieces, and suddenly something exists.
Not just a mockup or a static HTML page.
A working application.
And if you are a developer, an agency owner, a project manager, or anyone who makes a living from building websites and web applications, it is very difficult not to feel at least a little uncomfortable.
Because the obvious question is:
If this can now be done so much faster, what exactly are we here for?
The uncomfortable truth
We need to be honest: A lot of work that used to take a long time will not be an obstacle now.
Basic CRUD functionality, simple admin screens, landing pages, forms, search pages, listing pages, API integrations, data imports, simple dashboards, simple front-end interactions - these are all becoming dramatically faster to produce.
And yes, some things that agencies used to estimate as “a few weeks of development” may soon look suspiciously like “a few good prompts and some review”.
That is not a comfortable sentence to write. But pretending otherwise would be worse.
AI is changing the economics of implementation work. It is reducing the value of merely typing code. It is making boilerplate cheaper. It is making first versions faster. It is making prototypes feel like magic.
So, if your value as a developer is only that you can turn requirements into code, then yes, your value is under pressure.
But that is not the whole story.
Takeaway
Some implementation work is becoming faster, cheaper, and less defensible as “weeks of development.” Developers whose value is only writing code will feel the pressure most.
A website that works is not always a website that survives
There is a big difference between something that works today and something that can be trusted tomorrow.
A quickly generated website may look impressive. It may even be genuinely impressive.
But a production-grade digital platform is not just a collection of pages, forms, filters, and buttons.
It needs reliable data.
It needs to handle bad data.
It needs performance.
It needs monitoring.
It needs SEO.
It needs error handling.
It needs security.
It needs accessibility.
It needs legal checks.
It needs privacy compliance.
It needs deployment processes.
It needs maintainability.
Most importantly, it needs someone who understands what can go wrong.
That is where the discussion becomes more interesting.Because the future is probably not “AI replaces developers”.
The future is more likely:
AI replaces a certain kind of development work, and forces developers to become much better at the rest.
Takeaway
A working prototype is not the same as a reliable production system. Long-term success depends on performance, security, maintainability, compliance, and knowing what can go wrong.
The job is moving up the value chain
For years, many clients saw development as “building pages”.
They would ask:
- “Can you build this page?”
- “Can you add this form?”
- “Can you create this integration?”
- “Can you make this look like the design?”
That work still exists, but it is becoming easier to accelerate.
The more important questions now are different:
- “Should this be built this way?”
- “What happens when the data is wrong?”
- “How does this scale?”
- “How easy will this be to change in two years?”
- “How will editors manage it?”
- “How do we avoid creating a content model that becomes impossible to maintain?”
- “How do we upgrade this later?”
- “How do we know the AI-generated code is safe?”
- “How do we debug it when it fails in production?”
- “How do we avoid turning a fast prototype into a long-term liability?”
These are not junior questions.These are engineering, architecture, product, governance, and delivery questions.
And they matter even more now, because AI can produce a lot of code very quickly.
Fast code production is useful. Fast production of the wrong code is dangerous.
Takeaway
The developer’s role is shifting from simply building requested features to making better architectural, product, and delivery decisions. Fast code is useful only when it is the right code.
Vibe coding is not a delivery methodology
There is nothing wrong with vibe coding - at least when it's used where it should be used: It can be extremely powerful for prototypes, internal tools, experiments, proof-of-concepts, and early product exploration.
It removes friction. It gives people momentum. It allows ideas to become visible very quickly.
But vibe coding is not the same as professional delivery.
Professional delivery means making decisions that still make sense after launch.
- It means knowing when to say no.
- It means documenting the important parts.
- It means having deployment processes.
- It means security.
- It means maintainability.
- It means understanding the client’s business context.
- It also means responsibility.
When a website breaks, the client does not want to hear that “the AI generated that part”.
They want someone to fix it.
Takeaway
Vibe coding is great for prototypes and experiments, but it is not enough for professional delivery. Real projects need responsibility, testing, documentation, security, and long-term thinking.
What this means for agencies
The old agency model was often based on effort: “this will take X days.”, “this feature will take Y hours.”, “this implementation will take Z weeks.”
That model will become harder to defend when clients see what AI-assisted developers can create in very short timeframes.
The answer is not to deny that things are faster. The answer is to change what we sell.
We should not sell typing. We should sell judgment.
We should sell architecture, reliability, delivery confidence, business understanding, maintainability, security, integrations, editor experience, and long-term support.
This is especially true in CMS work.
A simple brochure website is one thing. A complex CMS implementation is another.
A serious CMS project is not just a visual layer. It includes content modelling, permissions, workflows, integrations, multilingual structure, media handling, caching, redirects, SEO, accessibility, deployment, editor training, and future upgrade paths.
AI can help with many of those things.
But it cannot magically know the right trade-offs for a specific organisation unless someone experienced is guiding it.
Takeaway
Agencies must start selling judgment, reliability, architecture, and delivery confidence. AI makes execution faster, but it also makes expert guidance more important.
What this means for Umbraco work
In the Umbraco world, this distinction is very important.
A small website can be built quickly in many platforms. Sometimes the CMS does not even matter that much.
But Umbraco tends to show its real value when the project is more demanding: custom content structures, integrations, multilingual requirements, editorial flexibility, complex permissions, long-term maintainability, and .NET-based extensibility.
That does not go away because AI exists. Actually, AI may make Umbraco work more interesting.
Why?
Because if implementation gets faster, then the quality of the decisions around implementation becomes more visible.
- A poor content model will still hurt.
- A bad integration will still fail.
- A messy architecture will still become expensive.
- An upgrade-hostile implementation will still create pain later.
- A site without a proper deployment process will still create risk.
- A client with editors who cannot understand the back office will still be unhappy.
AI does not remove these problems.
In some cases, it can create them faster.
Takeaway
AI does not remove the need for strong Umbraco architecture, content modelling, integrations, editor experience, and upgrade planning. In complex CMS projects, poor decisions can now be created faster too.
Internal platforms matter more now
One way agencies can respond is by building stronger internal foundations.
Reusable packages. Starter kits. Deployment templates. Testing patterns. Audit checklists. Content modelling standards. Security checklists. Performance baselines. Documentation habits.
This is where internal tooling becomes more valuable, not less.
If AI gives everyone speed, then the differentiator becomes controlled speed.
At DotSee, this is how we increasingly think about our work. We do not want to start every project from an empty folder, and we do not want to blindly accept AI-generated output either.
The goal is not “move fast and hope”.
The goal is “move faster because we already know what usually goes wrong”.
That is a very different thing.
Takeaway
Reusable foundations, packages, checklists, standards, and deployment patterns help agencies move faster without losing control. The advantage is not speed alone, but controlled speed.
Developers are not becoming useless
Developers are not becoming useless, but the definition of a good developer is changing.
A good developer will need to be able to:
-
describe problems clearly
-
guide AI tools effectively
-
review generated code critically
-
understand architecture
-
understand security implications
-
write tests
-
debug unfamiliar code
-
make trade-offs
-
communicate with non-technical stakeholders
-
think about maintainability
-
understand the business reason behind a feature
In other words, the job becomes less about producing lines of code and more about producing reliable outcomes.
That is not necessarily bad. But it is different, and it will be uncomfortable for people who built their identity around manual implementation speed.
Takeaway
Good developers will still matter, but their value will come from guiding AI, reviewing critically, understanding systems, making trade-offs, and delivering reliable outcomes.
Clients will need education too
Clients will also need to understand the difference between a fast prototype and a dependable production system.
A quickly generated build can be a great start. It can validate an idea, reveal hidden requirements, help stakeholders react to something real instead of discussing abstract specifications.
But it should not automatically be confused with a finished product.
The same way a quick building sketch is not the same as a safe, permitted, engineered building, a quickly generated website is not automatically a stable digital asset.
The skill is knowing the difference.
Takeaway
Clients must understand the difference between a quick prototype and a dependable production system. Sometimes the fast version is enough, but sometimes it creates risk that must be managed.
So, what are we going to become?
We are going to become less like factory workers and more like engineers, which is our role anyway. We won't be merely implementing requests, but we we will be the ones who shape, validate, protect, and improve digital systems.
Some developers will fight this. Some agencies will pretend nothing has changed. Some clients will learn difficult lessons by launching cheap AI-generated systems that become expensive later.
But the direction is clear.
AI-assisted development is here. The question is not whether we should use it, but whether we can use it responsibly, professionally, and in a way that creates better outcomes for clients.
Because in the end, clients do not really buy just code.
They buy confidence, reduced risk, and, most importantly, they buy someone who can take responsibility.
And that may be the most important answer to the original fear.
Although websites and applications can now be built faster than ever, developers will not disappear.
But developers who only build what they are told, exactly as they are told, without understanding why, may have a very difficult future.
Takeaway
Developers will become less like code typists and more like engineers, editors, advisors, and risk reducers. Clients do not really buy code; they buy confidence, responsibility, and working systems.
