The Impossible Journey To Get Apple Developer Accounts

Rust in the Vibe Coding Era

AI Automation vs Zapier Automation: Where AI Actually Helps

<p>Apple charges $100 a year for an Apple Developer account. That is annoying, but understandable. That friction probably keeps some low quality accounts and apps out of the app store. What is EVEN MORE frustrating though is not even being able to give Apple that $100 dollars.</p>
<h2>A Broad Issue</h2>
<p>We have several clients that are trying to launch iOS apps that we built. We have been helping them create (at least trying to help) Apple Developer accounts for their organizations.</p>
<p>They don&#39;t want to create accounts with their personal iClouds for obvious reasons. These are businesses with business emails and they want to keep things separate. One client even tried to use their personal iCloud but they were not able to create an organization developer account.</p>
<p>First, we tried to set them up new Apple accounts with their business emails. After going through the signing flow, verifying their email, and then trying to verify their phone number, they land on a cryptic message: &quot;Your account cannot be created at this time&quot;. No explanation, no way to move forward, no next action.</p>
<h2>Apple Business WTF?</h2>
<p>After some googling, we found one suggestion was to create an Apple Business account so that employees can have dedicated users under the business. We set one up for one of the clients and have been waiting for 11 business days to get it approved. The dashboard helpfully says it will be approved in 5 days. Lies.</p>
<h2>Apple Support Circus</h2>
<p>For both clients, we have parallel support threads going. We keep getting transferred to other departments, which means scheduling calls for the next day. Often, the calls get scheduled in the wrong timezone, which is delightful. There is no clear path to get this dealt with through their support pages or channels.</p>
<h2>Not Just Us</h2>
<p>When you Google for this problem, there are many Apple threads and Reddit posts detailing people with the same issues. Some workarounds include using their mom&#39;s phone number instead, going to a cafe and using their internet to fill out the form from a different IP, and trying to contact support. This seems to be a broad issue and it is insane that it seems to be unaddressed by Apple for at least the last year.</p>
<h2>Please Let Us Give You $100, Apple</h2>
<p>At the time of publishing this article, we are 2 weeks into trying to get accounts for 2 clients and still can&#39;t get in. This is frustrating us and this is frustrating our clients. It&#39;s baffling that a company that used to be so user-centric has created a early-2000&#39;s-Microsoft-like monstrosity of impenetrable bureaucracy. If anyone has any other ideas or works at Apple and can throw us a bone, please let me know: matt AT dioko.ai</p>

A firsthand look at the frustrating, support-heavy process of trying to create Apple Developer accounts for client iOS app launches.

Apple, please take our money. This side quest was not in the launch plan.

Jordan Sullivan

Co-Founder

<p>AI has changed the way software gets written.</p>
<p>A lot of teams are now using AI to generate first drafts of features, explore unfamiliar frameworks, scaffold systems, write tests, refactor code, and move faster through the boring parts of implementation. Some people call this “vibe coding.” The phrase is a little unserious, but the underlying shift is real: developers are increasingly steering, reviewing, correcting, and integrating code instead of typing every line by hand.</p>
<p>That creates a new question for engineering teams:</p>
<p>What languages and platforms work best when AI is part of the development process?</p>
<p>The answer is not just about which language an AI model can write most easily. The better question is which language helps generated code stay understandable after it lands. Agentic development works best when the system itself encourages clear boundaries, explicit contracts, narrow interfaces, and code that can be reviewed without reconstructing a pile of hidden assumptions.</p>
<p>For us, Rust has been one of the strongest answers so far.</p>
<h2><strong>Promising Results</strong></h2>
<p>At Dioko, we have been using Rust across native app development, cross-platform app development, and backend development. We did not come into this as long-time Rust experts. We had strong engineering fundamentals, but not a deep production Rust background. We have been learning it by building with it, reading, testing, refactoring, and using AI as a development accelerator.</p>
<p><strong>So far, the results have been extremely encouraging.</strong></p>
<p>Rust has given us a rare combination: high performance, strong correctness guarantees, great portability, a modern package ecosystem, and a type system that makes AI-generated code much easier to validate, constrain, and improve.</p>
<p>More importantly, Rust pushes both humans and AI agents toward stronger architectural boundaries. That may be the single most important thing for keeping agentic code manageable, readable, and clean.</p>
<h2><strong>Rust gives AI a better surface area to work with</strong></h2>
<p>One of the biggest problems with AI-generated code is not whether it can produce something plausible. It usually can.</p>
<p>The harder problem is knowing whether the generated code is actually right.</p>
<p>In dynamic languages, a lot of mistakes hide until runtime. Wrong shapes, missing fields, bad assumptions, nil errors, invalid states, forgotten edge cases, and weak boundaries can all survive the first generation pass. You may not find them until a test hits the exact case, or worse, until production does.</p>
<p>Rust changes that dynamic.</p>
<p>Rust’s type system, ownership model, exhaustive pattern matching, and compiler checks create a much tighter feedback loop. AI can generate code, but the compiler immediately acts as a rigorous reviewer. It does not care that the code looks reasonable. It cares whether lifetimes, ownership, borrowing, types, traits, match arms, and error handling are actually coherent.</p>
<p>That matters enormously when working with AI.</p>
<p>The compiler becomes part of the development workflow in a stronger way. You can ask AI to write or refactor something, run the compiler, feed the errors back into the loop, and converge toward code that is not merely syntactically valid, but structurally aligned with the program.</p>
<p>This does not replace human understanding. It raises the quality floor.</p>
<h2><strong>Rust makes boundaries harder to ignore</strong></h2>
<p>The most important thing Rust gives an AI-assisted workflow may not be speed, memory safety, or even compiler feedback in isolation.</p>
<p>It may be boundaries.</p>
<p>AI-generated code has a tendency to sprawl when the surrounding system lets it. Responsibilities blur. Data gets passed around too loosely. Optional states leak into places that should not know about them. Shared mutable state appears because it was the easiest path to a plausible answer. Interfaces grow wider than they need to be.</p>
<p>Rust fights that drift at the language level.</p>
<p>Ownership forces you to decide where data lives. Borrowing forces you to decide how access works. Traits force you to name capabilities. Enums force you to model states explicitly. Modules, visibility rules, and type boundaries make it harder to smear responsibility across the codebase without being noticed.</p>
<p>That does not mean Rust automatically produces good architecture. It means the path of least resistance is often closer to good architecture than it would be in a looser environment. The developer still has to make design decisions, but Rust keeps pulling those decisions into the open.</p>
<p>That is extremely valuable when agents are writing or modifying code. The system gives the agent less room to quietly improvise around unclear ownership, unclear state, and unclear module edges. Generated code has to fit through the boundaries that already exist, or the mismatch becomes visible quickly.</p>
<h2><strong>Strong types are self-documenting architecture</strong></h2>
<p>Rust’s type system is not just about catching bugs. It also makes code easier to reason about.</p>
<p>A well-modeled Rust system tells you a lot just by looking at the types. What is optional? What can fail? What state transitions are allowed? What data owns what? What can be shared across threads? What can cross an API boundary? What is impossible by construction?</p>
<p>That is valuable for humans. It is also valuable for AI.</p>
<p>When the codebase has strong types, clear enums, explicit error types, trait boundaries, and narrow data models, AI has more context embedded directly in the code. The code becomes less dependent on tribal knowledge, comments, or external documentation. The shape of the program carries more of its own meaning.</p>
<p>For an agency, that is a big deal.</p>
<p>We often need to move across projects quickly. We need to understand a system, extend it safely, and avoid creating fragile code that only works because one developer remembers every implicit assumption. Rust rewards making assumptions explicit. That makes it easier for both humans and AI agents to work inside the system without accidentally violating its invariants.</p>
<h2><strong>Runtime guarantees matter more when generation gets faster</strong></h2>
<p>AI lets teams produce code faster. That is useful, but it also increases the risk of producing more broken code faster.</p>
<p>This is where Rust’s runtime model is especially appealing.</p>
<p>Rust gives you memory safety without a garbage collector. It gives you strong concurrency guarantees. It makes many categories of bugs harder or impossible to express. It forces you to deal with failure paths instead of casually ignoring them. It makes shared mutable state something you have to justify, not something you accidentally create.</p>
<p>These are not academic benefits.</p>
<p>They matter when building native applications. They matter when building cross-platform libraries. They matter when building backends where performance, latency, resource usage, and reliability are all part of the product experience.</p>
<p>When AI is generating or modifying code, runtime guarantees become even more important. The faster the implementation loop gets, the more you want the language and compiler to constrain the possible damage.</p>
<p>Rust does that unusually well.</p>
<h2><strong>Rust is fast enough to change product decisions</strong></h2>
<p>Performance is not always the bottleneck. Plenty of products do not need maximum speed.</p>
<p>But performance still changes what you can comfortably build.</p>
<p>Rust is fast. Not “fast enough if you scale horizontally and cache aggressively.” Actually fast. It is suitable for native code, CLIs, servers, media processing, file processing, sync engines, local-first applications, embedded-adjacent work, and performance-sensitive backend systems.</p>
<p>That creates optionality.</p>
<p>You can write a core engine once and expose it to multiple platforms. You can move work client-side without dragging in a heavy runtime. You can build local-first features that feel instant. You can process data efficiently without defaulting to a large cloud bill. You can deploy small binaries with predictable resource usage.</p>
<p>For our work, this has been one of the most exciting parts.</p>
<p>Rust is not just a backend language. It can be the core of a product architecture. You can use it for native app internals, shared cross-platform business logic, backend services, workers, tools, and performance-critical modules. That flexibility is exactly the kind of leverage small senior teams need.</p>
<h2><strong>The ecosystem is mature enough now</strong></h2>
<p>A few years ago, the knock on Rust was that it was powerful but inconvenient. Great language, rough ecosystem.</p>
<p>That critique is less true now.</p>
<p>Rust now has a solid ecosystem for web services, command-line tools, serialization, async runtimes, database access, native integrations, cross-platform application logic, testing, observability, and deployment. Not every part of the ecosystem is as mature as the equivalent JavaScript, Python, Java, or Go world, but the foundation is strong enough for real production work.</p>
<p>You can build serious systems with Rust today.</p>
<p>The tooling is also refreshingly direct. Cargo is excellent. Dependency management is straightforward. Formatting and linting are standardized. Builds are reproducible enough to feel sane. Deployment can be as simple as shipping a binary or containerizing a small service.</p>
<p>There is less ceremony than many people expect.</p>
<p>That simplicity pairs well with AI-assisted development. The fewer custom build steps, hidden framework conventions, and fragile runtime assumptions a stack has, the easier it is to keep AI-generated work grounded.</p>
<h2><strong>Rust works well for cross-platform development</strong></h2>
<p>One of the more interesting uses of Rust is as a shared core across platforms.</p>
<p>Instead of rewriting the same logic for iOS, Android, desktop, and backend environments, Rust can often sit underneath the platform-specific UI layer. The UI can remain native or framework-specific, while Rust handles the logic that benefits from correctness, portability, and performance.</p>
<p>That can include things like:</p>
<ul><li>Local data models</li><li>Sync engines</li><li>File processing</li><li>Licensing systems</li><li>State machines</li><li>Audio or media processing</li><li>Cryptographic workflows</li><li>Business logic shared across clients and servers</li><li>Offline-first application logic</li></ul>
<p>This is especially useful when building native or semi-native applications where the UI needs to feel platform-appropriate, but the core logic should be consistent everywhere.</p>
<p>AI makes this approach more accessible. It can help generate FFI bindings, scaffold platform interfaces, explain compiler errors, and translate architectural intent into Rust modules. But Rust keeps the boundaries strict enough that the generated code has to earn its way into the system.</p>
<h2><strong>Rust is not a substitute for understanding the code</strong></h2>
<p>This is the part that matters most.</p>
<p>We do not think the future of software is developers blindly accepting generated code.</p>
<p>That might work for prototypes. It might work for throwaway internal tools. It might even work for early experiments where the cost of being wrong is low. But for real products, someone still needs to understand the system.</p>
<p>AI can generate code. It can explain code. It can refactor code. It can propose architectures. It can write tests. But it does not own the consequences.</p>
<p>The engineering team does.</p>
<p>That is why Rust has been such a good fit for us. It supports an AI-accelerated workflow without encouraging a careless one. It lets us move faster while still forcing us to confront the structure of the program. If a boundary is unclear, Rust makes us sharpen it. If something is wrong, the compiler often tells us. If a state is invalid, we can model it out of existence. If an error can happen, the code has to decide what to do with it.</p>
<p>Rust does not remove the need for discipline. It rewards discipline.</p>
<h2><strong>The learning curve is real, but manageable</strong></h2>
<p>Rust has a reputation for being difficult. That reputation is not completely unfair.</p>
<p>The ownership model takes time. Lifetimes can be confusing. Async Rust has sharp edges. Some libraries are less mature than their equivalents in older ecosystems. You will occasionally fight the compiler, especially early on.</p>
<p>But our experience has been that the learning curve is more acceptable now than it used to be, especially with AI assistance.</p>
<p>AI is very useful for explaining compiler errors, suggesting more idiomatic patterns, comparing design options, and helping translate a concept from another language into Rust. The key is not to accept everything it writes. The key is to use it as an interactive tutor and implementation partner.</p>
<p>That has made Rust feel much more approachable.</p>
<p>We are still learning. We are still self-educating. We are still developing taste around what belongs in Rust, what should stay in a higher-level language, and where the complexity tradeoff is worth it.</p>
<p>But the direction is clear: Rust is giving us capabilities we want more of.</p>
<h2><strong>More teams should consider Rust</strong></h2>
<p>Rust is not the right tool for every project.</p>
<p>If you are building a simple CRUD app, a marketing site, or an admin dashboard, Rust may not be the highest-leverage choice. If your team is already extremely productive in another stack and performance or correctness constraints are modest, switching languages for trend reasons would be a mistake.</p>
<p>But for many modern products, Rust deserves more serious consideration.</p>
<p>Especially when the product involves native functionality, cross-platform logic, performance-sensitive systems, local-first architecture, reliability-critical workflows, or long-term maintainability, Rust can be an excellent foundation.</p>
<p>And in the AI-assisted development era, its advantages become even more relevant.</p>
<p>The type system documents intent. The compiler catches structural mistakes. The ownership model pushes stronger boundaries. The runtime model eliminates entire classes of bugs. The performance profile opens up product options. The deployment model stays relatively simple. The ecosystem is now broad enough for real work.</p>
<p>That combination is rare.</p>
<p>For us, Rust has become one of the most exciting tools in the current software landscape. Not because it lets us stop thinking, but because it helps us think more clearly. Not because AI can magically write perfect Rust, but because Rust gives AI-generated code a much stricter and better-bounded environment to operate within.</p>
<p>That is exactly what we want from a modern engineering stack.</p>
<p>Fast iteration is good. Fast iteration with guardrails is much better.</p>
<p>Rust gives us both.</p>

Rust in the vibe coding era: why Rust’s boundaries, type system, runtime guarantees, speed, and portability make it a powerful fit for AI-assisted native, cross-platform, and backend development.

Alec Dibble

Advisor

<p>Zapier-style automation and AI automation solve different problems.</p>
<p>Traditional automation is great when the work follows a predictable rule:</p>
<ul><li>When a form is submitted, create a CRM record</li><li>When a deal closes, send a Slack notification</li><li>When a file lands in a folder, copy it somewhere else</li><li>When a status changes, send an email</li></ul>
<p>AI helps when the workflow is less structured:</p>
<ul><li>An email needs to be classified</li><li>A PDF needs fields extracted</li><li>A support thread needs a summary</li><li>A CRM record needs enrichment</li><li>A knowledge base needs to answer a question</li><li>A request needs human review because confidence is low</li></ul>
<p>The best systems often use both.</p>
<h2>Traditional automation is best for clear triggers and rules</h2>
<p>If the trigger, condition, and action are obvious, use traditional automation.</p>
<p>Examples:</p>
<ul><li>Sync a lead from a form to a CRM</li><li>Notify a channel when a ticket is tagged urgent</li><li>Move a file after approval</li><li>Create a task when a field changes</li></ul>
<p>These workflows do not need a model. They need clean rules, stable APIs, and reliable system behavior.</p>
<p>Adding AI to this type of work can make the system slower, more expensive, and harder to debug.</p>
<h2>AI automation helps when the input is messy</h2>
<p>AI becomes useful when the workflow has unstructured inputs.</p>
<p>Examples:</p>
<ul><li>A customer writes a long support email with unclear intent</li><li>A vendor sends a PDF with fields in different places</li><li>A client uploads mixed financial documents</li><li>A prospect submits a form with incomplete company details</li><li>An employee asks a question that requires searching SOPs</li></ul>
<p>These inputs are hard to handle with simple rules because the structure changes every time.</p>
<p>That is why <a href="/services/ai-features-workflows">document intake automation</a> and <a href="/services/ai-features-workflows">support triage automation</a> are common AI workflow candidates.</p>
<h2>AI automation needs review design</h2>
<p>Traditional automation is usually binary. A rule matches or it does not.</p>
<p>AI automation has confidence, ambiguity, and failure modes.</p>
<p>That means the workflow needs:</p>
<ul><li>Confidence thresholds</li><li>Review queues</li><li>Exception routing</li><li>Source references</li><li>Human approvals</li><li>Logging and feedback</li><li>A way to track corrections</li></ul>
<p>Without those controls, AI automation becomes a hidden decision-maker. That is where risk grows.</p>
<h2>The strongest pattern is AI plus deterministic automation</h2>
<p>The practical architecture often looks like this:</p>
<ol><li>Traditional automation detects the trigger.</li><li>AI classifies, summarizes, extracts, drafts, or recommends.</li><li>Rules decide whether the result can proceed or needs review.</li><li>Humans handle exceptions and sensitive decisions.</li><li>Traditional automation updates systems of record.</li></ol>
<p>For example, a support triage workflow might use AI to classify a ticket and draft a response, while deterministic rules route high-priority billing issues to a human queue.</p>
<h2>Use AI when the workflow needs judgment support</h2>
<p>AI is useful when a person currently spends time interpreting messy context.</p>
<p>Examples:</p>
<ul><li>&quot;What type of request is this?&quot;</li><li>&quot;What information is missing?&quot;</li><li>&quot;Which customer does this belong to?&quot;</li><li>&quot;What is the short summary?&quot;</li><li>&quot;Which policy applies?&quot;</li><li>&quot;What should the reviewer look at first?&quot;</li></ul>
<p>These are not pure rules. They are judgment-support steps. AI can make them faster, especially when a human remains responsible for the final decision.</p>
<h2>Use traditional automation when reliability matters more than interpretation</h2>
<p>If the workflow only needs to move data from one place to another, keep it deterministic.</p>
<p>Examples:</p>
<ul><li>Record creation</li><li>Status updates</li><li>Notifications</li><li>Scheduled reports</li><li>File movement</li><li>Basic field syncs</li></ul>
<p>These steps should usually be stable, inspectable, and easy to retry.</p>
<h2>When this matters</h2>
<p>This matters when a team says, &quot;Could we just do this in Zapier?&quot;</p>
<p>Sometimes the answer is yes. That is good. Use the simple tool.</p>
<p>But when the workflow includes messy language, documents, summaries, search, classification, confidence, and human review, the team needs a broader <a href="/services/ai-features-workflows">AI workflow automation</a> design.</p>
<p>The point is not AI instead of automation. The point is using AI only where interpretation creates leverage, then using deterministic automation to move the work safely.</p>

Traditional automation handles predictable rules. AI automation helps when workflows include messy language, documents, classification, summaries, and human review.

Matthew Berger

<p>The first AI workflow should not be the most impressive idea in the room.</p>
<p>It should be the workflow where the team can learn quickly, reduce real pain, and keep risk under control.</p>
<p>That is why Dioko starts many engagements with an <a href="/services/technical-rescue-audits">AI Business Audit</a>. The audit is not meant to find every possible AI idea. It is meant to find the first one worth building.</p>
<h2>Start with repeated work, not novelty</h2>
<p>AI automation is strongest when the workflow repeats often enough to justify design, integration, and review.</p>
<p>Good candidates usually include:</p>
<ul><li>Document intake</li><li>Support triage</li><li>CRM enrichment</li><li>Internal knowledge lookup</li><li>Reporting cleanup</li><li>Customer handoff summaries</li><li>Checklist and exception routing</li></ul>
<p>Bad first candidates often look exciting but happen rarely, have unclear ownership, or require too much judgment too soon.</p>
<h2>Score volume and pain together</h2>
<p>High-volume work is not always high-value work. High-pain work is not always frequent enough to automate.</p>
<p>The first workflow should have both.</p>
<p>Ask:</p>
<ul><li>How many times does this happen each week?</li><li>How long does each cycle take?</li><li>How much rework does it create?</li><li>What delays does it cause downstream?</li><li>Who is interrupted by the workflow?</li><li>What customer or revenue impact follows from slow handling?</li></ul>
<p>A workflow with moderate volume and severe handoff pain may beat a high-volume task that is already handled cleanly.</p>
<h2>Prefer messy language over simple rules</h2>
<p>If the workflow is already deterministic, a traditional automation tool may be enough.</p>
<p>AI becomes more useful when the work includes:</p>
<ul><li>Emails written in different formats</li><li>PDFs and attachments</li><li>Support messages with unclear intent</li><li>Incomplete CRM records</li><li>Long threads that need summarization</li><li>Policies or SOPs that need retrieval</li><li>Classification with exceptions</li></ul>
<p>That is why <a href="/services/ai-features-workflows">document intake automation</a>, <a href="/services/ai-features-workflows">support triage automation</a>, and <a href="/services/ai-features-workflows">CRM enrichment automation</a> are strong early candidates.</p>
<h2>Check data and system readiness</h2>
<p>The first workflow should not require perfect data, but it does need enough usable context.</p>
<p>Look for:</p>
<ul><li>Source systems the team can access</li><li>Examples of past work</li><li>Clear required fields</li><li>A known destination system</li><li>Permission boundaries</li><li>A person who owns review</li><li>A way to measure output quality</li></ul>
<p>If the data lives across docs, tickets, PDFs, and SOPs, the first project may be a <a href="/services/ai-features-workflows">knowledge base AI search</a> or RAG build before deeper automation.</p>
<h2>Keep humans in the loop early</h2>
<p>The first version should usually assist, route, draft, summarize, or recommend. It should not silently make risky decisions.</p>
<p>Human review is useful for:</p>
<ul><li>Low-confidence outputs</li><li>Customer-sensitive responses</li><li>Financial or legal decisions</li><li>Data overwrites</li><li>Exceptions</li><li>New categories the system has not seen before</li></ul>
<p>This is not a weakness. It is how teams learn where automation is safe.</p>
<h2>Avoid workflows with unclear ownership</h2>
<p>AI projects fail when nobody owns the workflow.</p>
<p>Before choosing a first automation, identify:</p>
<ul><li>The team that owns the work</li><li>The person who approves the workflow design</li><li>The reviewer who will handle exceptions</li><li>The system of record</li><li>The metric that proves the workflow improved</li></ul>
<p>If ownership is unclear, fix that before building.</p>
<h2>Choose a workflow with a clean first version</h2>
<p>The first project should have a small useful version.</p>
<p>For example:</p>
<ul><li>Classify inbound documents and create a reviewer queue</li><li>Summarize support tickets and suggest routing</li><li>Enrich only missing CRM fields for one segment</li><li>Search one approved knowledge base with citations</li><li>Draft internal handoff notes for one team</li></ul>
<p>That first version should prove value without needing to solve every adjacent workflow.</p>
<h2>When this matters</h2>
<p>This matters when leadership wants AI momentum but the team does not know where to start.</p>
<p>The right first workflow creates confidence. It gives the team a real system, real feedback, and a clearer expansion path.</p>
<p>The wrong first workflow creates skepticism. It burns time on an impressive demo that does not survive contact with operations.</p>
<p>Dioko&#39;s <a href="/services/ai-features-workflows">AI workflow automation service</a> is built to find and ship the practical first version before expanding.</p>

How to Choose the First Workflow to Automate with AI

Choose the first AI automation workflow by volume, pain, clarity, data readiness, review controls, and operational risk.

<p>An AI business audit should not be a brainstorm session with a prettier deck.</p>
<p>The useful version answers a harder question: <strong>which workflow is worth changing first, and what should the team avoid building?</strong></p>
<p>That matters because many companies already have AI ideas. They have a support idea, a reporting idea, a document idea, a CRM idea, and a few &quot;we should have a copilot&quot; ideas. The audit is valuable when it turns that pile into a ranked implementation path.</p>
<p>For Dioko, the audit is the first step in the <a href="/services">Audit, Build, Harden process</a>. It should connect directly to a practical <a href="/services/ai-features-workflows">AI workflow automation</a> or production hardening path.</p>
<h2>1. Clear buyer and workflow scope</h2>
<p>Start by naming the team, the workflow, and the reason the work matters.</p>
<p>Good audit inputs include:</p>
<ul><li>Which team owns the workflow</li><li>How work arrives</li><li>Which tools are involved</li><li>What handoffs slow the team down</li><li>Where rework or errors happen</li><li>Which decisions need human review</li><li>What volume or urgency makes the problem worth solving</li></ul>
<p>Without this scope, the audit turns into generic AI strategy. With it, the team can compare opportunities against real work.</p>
<h2>2. Current-state workflow map</h2>
<p>The audit should show how the work actually moves today.</p>
<p>That means mapping triggers, systems, owners, handoffs, review points, exception paths, and outputs. The goal is not documentation for its own sake. The goal is to find where AI could reduce friction without creating a fragile hidden process.</p>
<p>For example, a document intake workflow might include:</p>
<ul><li>Email or form submission</li><li>Attachment review</li><li>Required field extraction</li><li>Missing information checks</li><li>Routing to the right team</li><li>Reviewer approval</li><li>CRM or ticket update</li></ul>
<p>That workflow could become a <a href="/services/ai-features-workflows">document intake automation</a> project, but only if the audit shows enough volume, clarity, and review control.</p>
<h2>3. Opportunity list with specific use cases</h2>
<p>The audit should produce specific opportunities, not vague categories like &quot;use AI for operations.&quot;</p>
<p>Useful opportunities sound more like:</p>
<ul><li>Classify inbound support requests and route exceptions</li><li>Extract fields from intake documents and create reviewer queues</li><li>Enrich CRM records before account handoff</li><li>Summarize long customer threads for support agents</li><li>Search internal SOPs with permission-aware answers</li><li>Draft month-end checklist notes for accounting staff</li></ul>
<p>Each opportunity should include the workflow, user, input, output, system dependencies, and owner.</p>
<h2>4. ROI, complexity, and risk scoring</h2>
<p>Every opportunity should be scored. The scoring does not need fake precision, but it should make tradeoffs visible.</p>
<p>Useful scoring categories include:</p>
<ul><li>Workflow volume</li><li>Time saved per cycle</li><li>Error or rework cost</li><li>Revenue or customer impact</li><li>Implementation complexity</li><li>Data and system readiness</li><li>Security or compliance risk</li><li>Need for human review</li><li>Adoption difficulty</li></ul>
<p>The best first project is rarely the flashiest AI idea. It is usually the workflow with enough volume, a clear owner, available data, visible pain, and manageable downside.</p>
<h2>5. Data and system readiness review</h2>
<p>An AI project can fail because the model is weak. More often, it fails because the workflow has poor data, unclear ownership, or brittle integrations.</p>
<p>The audit should identify:</p>
<ul><li>Where the data lives</li><li>Whether the data is structured enough</li><li>Which APIs or exports are available</li><li>Which permissions matter</li><li>Which fields or documents are unreliable</li><li>Which system should be the source of truth</li><li>How updates should be reviewed or logged</li></ul>
<p>This is especially important for <a href="/services/ai-features-workflows">RAG consulting and knowledge systems</a>, where source quality, metadata, permissions, and freshness decide whether users trust the answers.</p>
<h2>6. Build, do-not-build, and wait recommendations</h2>
<p>A strong audit should say no.</p>
<p>Not every workflow should be automated. Some need process cleanup first. Some need better data ownership. Some are too low-volume to justify a build. Some are too risky for the current review model.</p>
<p>The final roadmap should separate:</p>
<ul><li>Build now</li><li>Pilot with constraints</li><li>Prepare the data first</li><li>Redesign the process first</li><li>Do not build</li></ul>
<p>This is where the audit protects the team from expensive AI theater.</p>
<h2>7. Fixed-scope implementation path</h2>
<p>The audit should end with a practical next step.</p>
<p>That next step might be:</p>
<ul><li>A scoped workflow automation build</li><li>A focused RAG or internal search project</li><li>A product AI feature build</li><li>Reliability and eval work for an existing prototype</li><li>Security review before launch</li></ul>
<p>The recommendation should include the first version, required inputs, integration path, human review points, success metrics, and production risks.</p>
<h2>When this matters</h2>
<p>An AI business audit matters when the team has manual workflows, scattered AI ideas, and no defensible sequence. It matters even more when leadership wants AI progress but the operators know the process is messy.</p>
<p>The right audit does not promise transformation in the abstract. It gives the team a ranked roadmap and a practical decision: what to build, what to ignore, and what to harden before it becomes operational debt.</p>
<p>Dioko&#39;s <a href="/services/technical-rescue-audits">AI Business Audit</a> is built around that decision.</p>

What an AI Business Audit Should Include

A practical AI business audit should rank opportunities, score ROI and complexity, map workflows, review readiness, and decide what to build or ignore.

<p>The demo is usually the easy part.</p>
<p>The demo has a clean input, a cooperative user, a narrow prompt, and no operational consequences.</p>
<p>The production workflow has messy inputs, edge cases, permissions, frustrated users, latency, cost, retries, missing data, and people who need the system to be right often enough to trust it.</p>
<p>That gap is where many AI automation projects fail.</p>
<h2>Failure mode 1: The workflow owner is unclear</h2>
<p>AI automation is not only a technical system. It changes how work moves.</p>
<p>If nobody owns the workflow, nobody owns the exceptions, feedback, review rules, or quality improvements.</p>
<p>Before launch, the team should know:</p>
<ul><li>Who owns the workflow</li><li>Who approves changes</li><li>Who reviews exceptions</li><li>Who monitors quality</li><li>Who decides whether the system expands</li></ul>
<p>If those answers are missing, the project is not ready for production.</p>
<h2>Failure mode 2: The system automates too much too soon</h2>
<p>Early AI workflows should usually assist before they act.</p>
<p>Good first versions often:</p>
<ul><li>Classify requests</li><li>Summarize context</li><li>Draft responses</li><li>Extract fields</li><li>Recommend routing</li><li>Flag missing information</li></ul>
<p>Risk grows when the first version silently overwrites data, sends customer-facing responses, or makes high-impact decisions without review.</p>
<p>The better pattern is controlled automation with human review where confidence or risk requires it.</p>
<h2>Failure mode 3: The data source is not trustworthy</h2>
<p>AI systems inherit the quality of the sources around them.</p>
<p>If the documents are stale, CRM fields are inconsistent, SOPs conflict, or tickets are missing context, the workflow will produce unreliable output.</p>
<p>This is especially important for <a href="/services/ai-features-workflows">RAG consulting and knowledge systems</a>. Retrieval quality depends on source ownership, metadata, permissions, freshness, and evaluation. A chatbot over bad content is still bad content.</p>
<h2>Failure mode 4: There are no evaluation cases</h2>
<p>Teams often judge AI quality from a handful of examples.</p>
<p>That is not enough.</p>
<p>Production AI needs representative cases that test:</p>
<ul><li>Common requests</li><li>Edge cases</li><li>Missing data</li><li>Ambiguous language</li><li>Policy boundaries</li><li>Refusal behavior</li><li>Cost and latency</li><li>Escalation rules</li></ul>
<p>This is the core of <a href="/services/technical-rescue-audits">AI evals and reliability consulting</a>. Without evals, the team is guessing.</p>
<h2>Failure mode 5: Integrations are treated as an afterthought</h2>
<p>AI output is only useful if it lands in the right place.</p>
<p>The project needs to define:</p>
<ul><li>What system receives the result</li><li>Whether the result is a draft or final update</li><li>What gets logged</li><li>What happens on failure</li><li>How retries work</li><li>How users inspect or correct the output</li></ul>
<p>Many demos stop at the model response. Real workflow automation starts when that response has to move through systems safely.</p>
<h2>Failure mode 6: The team does not monitor production behavior</h2>
<p>After launch, the team should watch more than usage.</p>
<p>Useful signals include:</p>
<ul><li>Reviewer edits</li><li>Exception volume</li><li>Rejected outputs</li><li>Reassignments</li><li>Latency</li><li>Cost</li><li>User feedback</li><li>Missed categories</li><li>Escalation frequency</li></ul>
<p>These signals tell the team where to tune, where to add guardrails, and where not to expand yet.</p>
<h2>Failure mode 7: Security and permissions are vague</h2>
<p>AI workflows often touch sensitive data.</p>
<p>Questions to answer before launch:</p>
<ul><li>Who can access which sources?</li><li>Can the model see private customer data?</li><li>Can outputs reveal restricted information?</li><li>Are secrets and API keys handled safely?</li><li>Are tool actions permissioned?</li><li>Are logs safe to retain?</li></ul>
<p>If the app shipped quickly, a focused <a href="/services/technical-rescue-audits">AI app security audit</a> can catch risks before customers or internal users depend on it.</p>
<h2>When this matters</h2>
<p>This matters when a prototype looks promising and the team is tempted to push it into real operations.</p>
<p>The right next step is not always a larger build. Sometimes it is hardening: evals, observability, review paths, permissions, fallback behavior, and security checks.</p>
<p>Dioko uses the <a href="/services">Audit, Build, Harden process</a> to keep AI projects from stalling after the demo. The work is not complete when the model responds. It is complete when the workflow can be operated, measured, trusted, and improved.</p>

What Makes an AI Automation Project Fail After the Demo

AI automation projects fail after the demo when they ignore workflow ownership, review paths, data readiness, evaluation, reliability, and production support.

<h2>Video Killed The Radio Star</h2>
<p>For years, the CMS was treated as essential web infrastructure.</p>
<p>If a business wanted to update website copy, publish blog posts, manage landing pages, or give non-developers control over content, the default answer was usually the same: use a content management system. That led to massive adoption of platforms like WordPress, Drupal, and Contentful.</p>
<p>But AI is changing the assumptions that made CMS platforms so valuable in the first place.</p>
<p>The old reason for using a CMS was simple: most people could not safely edit a website in code. Now they increasingly can, through AI agents. And once that happens, much of the CMS starts to look less like infrastructure and more like overhead.</p>
<h2><strong>What is a CMS?</strong></h2>
<p>A CMS, or content management system, is software that allows people to create, edit, organize, and publish website content without directly modifying the site’s codebase.</p>
<p>Common examples include WordPress, Drupal, and Contentful. Some CMS platforms are traditional all-in-one systems. Others are headless and API-driven. That architectural difference matters in implementation, but not much in the broader argument here.</p>
<p>At a high level, all CMS platforms exist to solve the same problem: separating content editing from the code that renders the website.</p>
<p>That used to be extremely useful. Now, in many cases, it is just another layer to maintain.</p>
<h2><strong>AI is replacing the “change the copy” use case</strong></h2>
<p>A large percentage of CMS usage comes down to one basic job: changing content.</p>
<p>A team wants to update a homepage headline, revise product page copy, swap a CTA, edit metadata, publish a case study, or tweak an about page without asking a developer to make the change manually. Historically, that is exactly what a CMS was for. But AI agents are now capable of handling this workflow directly.</p>
<p>A marketer or founder can tell an AI system:</p>
<ul><li>“Rewrite the hero section to focus on speed and implementation clarity.”</li></ul>
<p><strong>Or:</strong></p>
<ul><li>“Update the pricing page to sound more premium and reduce vague agency language.”</li></ul>
<p>The AI can make the change in the actual codebase, often with enough context to preserve tone, layout, and structure.</p>
<p>That is the real disruption.</p>
<p>The CMS was not just a content tool. It was an access tool. It existed because non-programmers needed a safe interface for editing sites. AI is quickly becoming that interface. Once non-technical users can direct changes through AI instead of through a CMS dashboard, a lot of CMS-related complexity stops making sense.</p>
<h2><strong>Website content no longer needs a CMS to be editable</strong></h2>
<p>The strongest historical argument for a CMS was that code was inaccessible. That argument weakens significantly once AI can operate as an intermediary between the user and the codebase.</p>
<p>Instead of training team members on a CMS, configuring fields, maintaining integrations, and dealing with preview limitations, many teams can now work from intent:</p>
<ul><li>“Add a testimonial section under the hero.”</li><li>“Change the homepage language to target B2B SaaS founders.”</li><li>“Update all service pages to align with the new positioning.”</li></ul>
<p>That does not eliminate the need for review. It does eliminate much of the need for a CMS to serve as the editing surface.</p>
<p>This is the uncomfortable truth for many content platforms: AI agents are becoming better at translating business intent into site changes than CMS interfaces are.</p>
<h2><strong>Blog posts can live directly in the codebase</strong></h2>
<p>Blog publishing is another area where the CMS is losing its advantage. Many companies still use a CMS mostly because they have a blog. But blog content is one of the easiest things to move out of a CMS entirely.</p>
<p>Markdown works. MDX works. Static site generators work. Frontmatter works. Flat files in a repository work. For many modern websites, blog posts do not need a database-backed publishing platform. They just need structured content files and a build pipeline.</p>
<p>This approach is often faster, cheaper, easier to version, and much more AI-friendly.</p>
<p>An AI agent can draft a post, revise it for tone, optimize headings, add metadata, structure internal links, and save it directly as Markdown in the repo. The entire workflow becomes simpler because the content lives closer to the rendering logic.</p>
<p>If your CMS is mainly acting as a blog editor, that is increasingly hard to justify.</p>
<h2><strong>CMS platforms are often standing in for a database and admin dashboard</strong></h2>
<p>Not all CMS usage is just about copy or blog posts.</p>
<p>Many companies also use CMS platforms to manage structured objects, reusable content blocks, complex page layouts, directories, resource libraries, location pages, product-like entries, or other semi-structured business data.</p>
<p>In practice, the CMS often becomes a substitute for two things:</p>
<ul><li>a database</li></ul>
<p><strong>and</strong></p>
<ul><li>an admin dashboard</li></ul>
<p>That was historically a practical shortcut. Building internal tools used to require enough engineering effort that teams tolerated the awkward fit of a CMS instead.</p>
<p>AI changes that tradeoff.</p>
<p>AI is now extremely fast at generating custom admin dashboards, CRUD interfaces, validation flows, internal tooling, and business-specific management systems. What once required a dedicated internal tools effort can now be scaffolded and implemented much more quickly.</p>
<p>That weakens another major reason to use a CMS.</p>
<p>If a CMS is mostly functioning as a generic object editor with some publishing features, AI makes it much easier to replace that system with something purpose-built.</p>
<h2><strong>AI works better with code-first websites than CMS-powered websites</strong></h2>
<p>This is one of the most important points, and one many teams miss.</p>
<p>AI performs better when it has context.</p>
<p>Code-first websites give AI exactly that.</p>
<p>When content, components, data structures, and rendering logic are all visible inside the codebase, AI can inspect the system more holistically. It can see how content is used, how components are structured, how pages are assembled, and what effect a change is likely to have.</p>
<p>CMS-powered sites often split that context apart.</p>
<p>The content model may live in one platform. The frontend components live somewhere else. The rendering logic is detached from the editing interface. Relationships are often implicit rather than obvious. Preview environments may be partial or unreliable.</p>
<p>That fragmentation makes AI-assisted editing harder.</p>
<p>The AI may see the frontend but not the actual content driving it. Or it may see the CMS schema without enough UI context to understand what the resulting page should look like.</p>
<p>This is where code-first architecture wins.</p>
<p>When the source of truth is close to the implementation, AI can reason better, edit faster, and make more reliable changes.</p>
<p>If you want AI to be genuinely useful in website iteration, design changes, content updates, and structural edits, reducing architectural indirection matters.</p>
<p>CMS platforms often increase that indirection.</p>
<h2><strong>Why code-first web development fits the AI era better</strong></h2>
<p>Code-first websites are not automatically better in every situation. But they are often a better fit for how modern teams will actually work with AI.</p>
<p>A code-first setup makes it easier to:</p>
<ul><li>update content directly</li><li>keep rendering logic and content close together</li><li>version everything cleanly in Git</li><li>let AI agents understand page structure</li><li>generate or modify admin tooling as needed</li><li>reduce vendor dependency and integration overhead</li><li>move faster on design, content, and experimentation</li></ul>
<p>The CMS was designed for a world where editing content without touching code was the main bottleneck.</p>
<p>Now the bottleneck is shifting.</p>
<p>The question is no longer, “How do we keep non-technical users out of the codebase?” It is increasingly, “How do we give AI enough context to make high-quality changes quickly?”</p>
<p>Those are not the same problem.</p>
<h2><strong>Will AI completely replace CMS platforms?</strong></h2>
<p>Not immediately.</p>
<p>Many organizations will continue using CMS platforms for years. Large teams still care about permissions, workflows, governance, localization, editorial approval chains, legal review, and the comfort of established systems. There are absolutely environments where a CMS will remain the preferred choice.</p>
<p>But that should not obscure the broader trend.</p>
<p>For smaller teams, startups, design-forward agencies, and fast-moving companies, the default assumption that every website needs a CMS is becoming much harder to defend. In many cases, the CMS is no longer solving a core problem. It is preserving an old workflow that AI has started to dissolve.</p>
<h2><strong>Final thoughts: AI will not kill every CMS, but it will kill the default</strong></h2>
<p>AI will not wipe out WordPress, Drupal, Contentful, or every other CMS overnight. But AI is attacking the reasons these platforms became standard.</p>
<ul><li>If copy can be changed by AI agents, you need less editorial overhead.</li><li>If blog posts can live in Markdown, you need less publishing infrastructure.</li><li>If admin dashboards can be generated quickly, you need less CMS-driven object management.</li><li>If AI edits code-first sites more effectively, you need less architectural separation between content and implementation.</li></ul>
<p>That does not mean no one will use a CMS. It means the burden of proof is shifting. In the age of AI, the real question is no longer whether you can use a CMS. It is whether the CMS is actually helping you move faster.</p>
<p>For a growing number of teams, it is not.</p>
<h2>Related Dioko resources</h2>
<p>If this argument is relevant because your team wants a code-first AI editing or operations workflow, start with Dioko&#39;s <a href="/services/technical-rescue-audits">AI Business Audit</a>. For implementation work around internal tooling, content workflows, or operational handoffs, see <a href="/services/ai-features-workflows">AI workflow automation</a> and <a href="/services/integrations-automation">AI platform integrations</a>.</p>

Image showing a CMS representation going into the shredder

Is AI The End of the CMS Systems?

AI is changing website content management. Learn why AI agents, Markdown, code-first websites, and custom admin dashboards are making traditional CMS platforms less necessary.

<h2><strong>Skills vs MCP Servers: Why the Default Architecture Is Changing</strong></h2>
<p>For a while, MCP servers looked like the obvious future of AI tool use.</p>
<p>The pitch was compelling: expose tools through a standard interface, keep them available to the model, and let the agent decide what to call. In theory, that creates a clean, extensible architecture.</p>
<p>In practice, it often creates a context problem.</p>
<p>Many MCP server setups assume that tool definitions, schemas, and related instructions should stay available in the model’s context at all times. That works in some environments, but in many real-world agent systems it is inefficient. You end up paying a constant context cost for capabilities that are only used occasionally.</p>
<p>That is where skills are changing the design pattern.</p>
<p>Skills let you keep capability definitions lightweight by default and load deeper logic only when needed. In many cases, that makes them a better packaging unit than an always-present MCP interface.</p>
<p>So no, skills did not literally kill MCP servers. But they did weaken the case for keeping every tool surface mounted all the time.</p>
<h2><strong>What Is the Problem With Always-On MCP Servers?</strong></h2>
<p>The core issue is not MCP itself. The issue is <strong>always-on availability inside the active prompt or working context</strong>.</p>
<p>When a model has to carry a large tool surface at all times, several problems show up:</p>
<ul><li>More tokens are spent on tool descriptions instead of the actual task</li></ul>
<ul><li>The model has more options to evaluate, even when most are irrelevant</li></ul>
<ul><li>Tool selection gets noisier</li></ul>
<ul><li>Prompt focus degrades</li></ul>
<ul><li>Context windows get consumed by infrastructure instead of reasoning</li></ul>
<p>This becomes especially noticeable when one MCP server exposes many functions, resources, or conventions but only a small subset is relevant in any given interaction.</p>
<p>That is bad context economics.</p>
<p>If a capability is only needed in 5% of cases, keeping its full interface always present is usually the wrong default.</p>
<h2><strong>Why Skills Are Often Better Than Full MCP Context</strong></h2>
<p>A skill is a lighter abstraction at the point where it matters most: the default context.</p>
<p>Instead of loading a full server interface up front, a skill can contain:</p>
<ul><li>a compact description of what it does</li></ul>
<ul><li>metadata about when it should be used</li></ul>
<ul><li>a script, workflow, or invocation template</li></ul>
<ul><li>optional MCP instructions or server-specific context</li></ul>
<ul><li>logic for loading deeper resources only when activated</li></ul>
<p>That means the model only carries the small routing layer most of the time. The heavier instructions, schemas, or tool surfaces only appear when the system decides they are relevant.</p>
<p>For many AI agent workflows, that is the better tradeoff.</p>
<p>You usually do not need a full CRM tool interface loaded during a generic planning conversation. You do not need a data migration tool mounted in context during brainstorming. You do not need invoice reconciliation capabilities sitting inside the active prompt unless the task clearly points there.</p>
<p>In those cases, skills are simply the cleaner abstraction.</p>
<h2><strong>MCP Servers Solved a Real Problem</strong></h2>
<p>It would be a mistake to overcorrect and pretend MCP servers were a bad idea.</p>
<p>They solved important problems:</p>
<ul><li>standardized tool access</li></ul>
<ul><li>cleaner external system integration</li></ul>
<ul><li>a structured interface for agents to interact with capabilities</li></ul>
<ul><li>a better alternative to ad hoc wrappers and prompt hacks</li></ul>
<p>Those benefits still matter.</p>
<p>But many teams blurred two separate concerns: <strong>tool connectivity</strong> and <strong>prompt residency</strong>.</p>
<p>MCP is a transport and interface pattern. It does not automatically follow that every exposed capability should remain permanently loaded in the model’s context.</p>
<p>That distinction is where skills start to win.</p>
<p>A skill can sit above the tooling layer and act as a compact trigger. The MCP server can still exist underneath, but it no longer has to live in the model’s face all the time.</p>
<h2><strong>How Skills Reduce Context Bloat in AI Agents</strong></h2>
<p>The strongest case for skills is simple: they let you compress the long tail of rarely used capabilities.</p>
<p>Most agent systems do not use all tools evenly. A few tools are used constantly. Many others are situational.</p>
<p>That means the right architecture is not “keep everything equally available.” It is closer to:</p>
<ol><li>Keep the default context lean</li></ol>
<ol><li>Expose a registry of lightweight skills</li></ol>
<ol><li>Activate the right skill when the task warrants it</li></ol>
<ol><li>Load deeper MCP-backed instructions only on demand</li></ol>
<p>This design reduces context bloat while preserving access to powerful external systems.</p>
<p>That is why skills feel increasingly like the right default for production agents.</p>
<h2><strong>Why On-Demand Skill Loading Works Better</strong></h2>
<p>There are three practical reasons this model tends to perform better.</p>
<h3><strong>1\. Most tool usage is sparse</strong></h3>
<p>Many agent tools are episodic, not continuous. They matter only for specific task patterns. Loading them only when needed is more efficient than treating them as always-active prompt residents.</p>
<h3><strong>2\. Skill routing is improving</strong></h3>
<p>Agent frameworks are getting better at deciding which capability to use. Some use planners, classifiers, retrieval layers, or compact registries. Others rely on model-driven routing over small metadata summaries.</p>
<p>As routing improves, the need for always-loaded tool context gets weaker.</p>
<h3><strong>3\. Smaller active context usually produces cleaner behavior</strong></h3>
<p>Less irrelevant prompt material usually means better focus. The model sees fewer distracting options, the relevant instructions are more legible, and tool calls become more intentional.</p>
<p>That often leads to:</p>
<ul><li>fewer unnecessary tool invocations</li></ul>
<ul><li>better skill selection</li></ul>
<ul><li>better workflow adherence</li></ul>
<ul><li>more usable room in context for actual reasoning</li></ul>
<h2><strong>Skills vs MCP Servers: A Better Mental Model</strong></h2>
<p>A useful way to think about this is:</p>
<ul><li><strong>MCP servers are infrastructure</strong></li></ul>
<ul><li><strong>Skills are activation interfaces</strong></li></ul>
<p>The MCP server gives the system capability. The skill determines when that capability should become active.</p>
<p>That distinction matters.</p>
<p>Many teams originally treated direct tool exposure as both the plumbing and the UX layer for the model. But those are different design problems. Backend connectivity should not automatically dictate what sits in the prompt at all times.</p>
<p>Skills separate those layers more cleanly.</p>
<h2><strong>When MCP Servers Still Make Sense</strong></h2>
<p>There are still real cases where direct MCP exposure remains the right choice.</p>
<p>For example:</p>
<ul><li>IDE-style environments with constant file, diff, and code operations</li></ul>
<ul><li>highly interactive systems where many tools are used repeatedly</li></ul>
<ul><li>environments where dynamic discovery matters</li></ul>
<ul><li>workflows where chaining across tools is continuous rather than occasional</li></ul>
<ul><li>systems where on-demand loading would introduce more friction than value</li></ul>
<p>In those cases, keeping tools closer to the model may still be worth the context cost.</p>
<p>But that set of use cases is narrower than people first assumed.</p>
<p>A lot of early agent systems adopted the maximal pattern by default. That made sense when the ecosystem was still exploring tool standards. It makes less sense once you recognize how much waste comes from permanently loading rarely used capabilities.</p>
<h2><strong>Are Skills Replacing MCP Servers?</strong></h2>
<p>Not exactly.</p>
<p>Skills are not replacing MCP servers so much as <strong>reframing their role</strong>.</p>
<p>Instead of being the thing the model constantly stares at, MCP increasingly becomes the implementation layer behind a smarter routing system. The skill becomes the lighter-weight abstraction the model sees first.</p>
<p>That is the real shift.</p>
<p>The architecture is moving away from “everything mounted all the time” and toward “load the right capability at the right moment.”</p>
<h2><strong>The Future of AI Agent Tooling Is Probably Layered</strong></h2>
<p>The most practical architecture for many agent systems now looks something like this:</p>
<ul><li>a lean default prompt</li></ul>
<ul><li>a lightweight skill registry</li></ul>
<ul><li>a routing layer that decides what to activate</li></ul>
<ul><li>deeper tool or MCP-backed capability loaded on demand</li></ul>
<p>That structure is usually easier to reason about, cheaper in context, and often more robust in practice.</p>
<p>It also matches how real work happens. Most tasks do not require every tool at once. They require the right tool when the problem becomes specific enough.</p>
<h2><strong>Conclusion: Skills Didn’t Kill MCP Servers, But They Did Change the Default</strong></h2>
<p>Skills did not make MCP obsolete.</p>
<p>What they did do is expose a design mistake: many systems were treating full tool availability as the default, even when the task pattern did not justify it.</p>
<p>For a large class of AI agent applications, skills are the better packaging unit. They reduce context overhead, improve focus, and let you defer heavy tool instructions until they are actually relevant.</p>
<p>MCP servers still matter. But in many systems, they increasingly look like plumbing rather than the main abstraction.</p>
<p>That is why the title is only half joking.</p>
<p>Skills killed MCP servers, kind of.</p>
<h2><strong>FAQ</strong></h2>
<h3><strong>What is the difference between a skill and an MCP server?</strong></h3>
<p>An MCP server exposes capabilities through a structured interface. A skill is a lighter activation layer that tells the system when and how to use a capability, often loading deeper MCP context only when needed.</p>
<h3><strong>Why are always-on MCP servers a problem?</strong></h3>
<p>They can consume too much context, introduce noise, and make tool selection less efficient when many capabilities are only used occasionally.</p>
<h3><strong>Are MCP servers still useful?</strong></h3>
<p>Yes. They are still useful for highly interactive or tool-dense environments where many capabilities are used continuously.</p>
<h3><strong>Why are skills becoming more important?</strong></h3>
<p>Because they let agent systems keep default context lean while still accessing powerful tools on demand. As routing improves, this becomes a stronger default pattern.</p>
<h2>Related Dioko resources</h2>
<p>If you are designing agent tools around real company workflows, Dioko&#39;s <a href="/services/ai-features-workflows">AI workflow automation</a> service covers the system design, integration, review, and operating controls. For knowledge-heavy agents, see <a href="/services/ai-features-workflows">RAG consulting and AI search</a> and <a href="/services/ai-features-workflows">internal AI copilots</a>.</p>

Image showing an agent skills folder and an X through MCP

Skills Killed MCP Servers, Kind Of

MCP servers are still useful, but always-on tool context is often wasteful. Here’s why skills, on-demand loading, and better routing are becoming the better default for many AI agent architectures.

<p>Some of the smartest engineers I know remain convinced that large-language-model (LLM) tools are a passing craze. I sympathize: tech hype cycles are exhausting. Yet after months of building real software with agents such as Cursor, Devin-style workflows, and Claude Code, I’m convinced these systems are already the second-most consequential advance of my career—behind only the Internet itself.</p>
<h2><strong>What “Modern” LLM Development Looks Like</strong></h2>
<p>If your only experience is pasting prompts into ChatGPT and copying fragile snippets, you’re missing the point. Today’s serious practitioners let agents</p>
<ul><li>crawl entire repositories,</li><li>open PRs, run tests, and iterate automatically, and</li><li>call arbitrary CLI tools you wire up.</li></ul>
<p>In practice an agent behaves like a tireless junior engineer who never forgets a command-line flag and never stops at 6 p.m.</p>
<h2><strong>The Upside in Plain Terms</strong></h2>
<ol><li>Tedious code writes itself. Dependency scaffolding, rote boilerplate, and test refactors disappear, freeing you to focus on architecture and product thinking.</li><li>Google once, not twenty times. An LLM looks up obscure API calls faster than you can type “Stack Overflow.”</li><li>Momentum on tap. Agents hand you a project in the “it almost runs” state—exactly where the fun starts.</li></ol>
<p>You still review every diff, but the floor now starts at “competent” rather than “blank file.”</p>
<h2><strong>Constructive Answers to Common Objections</strong></h2>
<ul><li>“I won’t understand the generated code.” You own the merge button. Spend five minutes massaging style, just as you would with a human PR.</li><li>“Hallucinations make this dangerous.” Agents compile, test, and loop until the build passes. Errors feed back into the prompt; nonsense rarely survives.</li><li>“It’s still mediocre.” Mediocre is fine for glue code. Raising the minimum quality bar while you polish the critical paths is a net win.</li><li>“This ruins the craft.” Buy the dining table, hand-carve the heirloom workbench. Professional software is about solving problems, not perfect dovetails everywhere.</li><li>“Jobs will vanish.” Automation has always shifted roles—from databases to CI pipelines. The best defense is embracing the new leverage early.</li></ul>
<h2><strong>A Better Framing</strong></h2>
<p>Think of LLM tools as pouring concrete for you: they lay a flat, fast foundation so you can design the building. They do not replace judgment, taste, or accountability, and they certainly do not grant production access on their own. But they do remove friction that historically killed side projects and slowed features.</p>
<p>Just as open-source libraries eliminated weeks of plumbing code, AI assistants wipe out another layer of drudgery. The ceiling for brilliance might not rise overnight, but the floor—where most of our time is spent—jumps dramatically.</p>
<h2><strong>Where to Go from Here</strong></h2>
<ul><li>Wire up an agent to your real repo. Give it strict tests and linters, then ask for a small feature.</li><li>Treat it like an intern. Review, coach, and iterate. Measure the delta in shipped value, not line count.</li><li>Stay pragmatic. Skip the AGI debates and focus on whether today’s tools save you an hour you can reinvest elsewhere.</li></ul>
<p>Something real is happening. Having a career in tech is all about staying relevant and it&#39;s worth your future to take AI seriously.</p>
<h2>Related Dioko resources</h2>
<p>If AI coding has created a prototype that now needs production discipline, see Dioko&#39;s <a href="/services/technical-rescue-audits">AI app security audit</a> and <a href="/services/technical-rescue-audits">AI evals and reliability consulting</a>. If the goal is to apply AI to a real business workflow instead of a side project, start with an <a href="/services/technical-rescue-audits">AI Business Audit</a>.</p>

Why AI Coding Deserves Your Attention

AI sometimes seems all hype but agent advances in the last six months can put you behind the pack if you don't start caring soon.

Practical notes on web systems

Writing that supports project decisions