DEV

DEV

By DEV.coScienceTechnologyMathematics
Download on the App Store

DEV episodes

  • AI Adoption: Why the Numbers Are So Far Apart

    A single statistic can make AI feel like a done deal — nearly every organization already on board, the window to act almost closed. But a competing figure from the U.S. Census Bureau tells a starkly different story. This episode of DEV.co digs into the 64-point gap between those two headlines, drawing on DEV.co's AI adoption statistics breakdown — which cross-references the Census Bureau, Eurostat, and McKinsey on one scale — to explain why both numbers are technically correct, and why confusing them leads to bad decisions.

    Here's what the episode covers:

    • Why the numbers diverge so sharply: McKinsey surveys executives at large enterprises, where a single team using one AI tool counts as full organizational adoption. The Census Bureau samples every employer business in the U.S. — including the two-person shop and the regional firm — and asks whether AI was used in any function in the past two weeks.
    • What "real" adoption actually looks like: About one in four U.S. businesses and one in five EU enterprises are using AI by the broader, census-style measure — not the 88% figure that dominates the conversation.
    • The growth rate is the real headline: U.S. adoption jumped from 17.3% to 24.2% in a single year. The EU moved from 13.5% to 20% in the same window, and from roughly 8% just two years prior. The trajectory is steep even if the current level is far below the hype.
    • Industry variation runs deep: Information-sector firms (software, media, data services) sit at 45% adoption — nearly twice the national average. Meanwhile, mining, hospitality, and transportation cluster around 10–13%, not because they're falling behind, but because today's AI tools fit less naturally into their core workflows. Teams building AI workflow automation for those sectors face a different challenge than their counterparts in professional services.
    • Company size shapes access: U.S. firms with 250 or more employees adopt AI at nearly twice the rate of those with one to four employees. In Europe, that gap widens to more than three to one. Large organizations have dedicated evaluation and implementation capacity; smaller ones are figuring it out in the margins.
    • Adoption is not the same as impact: McKinsey's 2026 data found that only 37% of respondents could point to any measurable EBIT effect from AI — and that figure was flat year over year. Even among companies with over $5 billion in revenue, fewer than half said their deployment was scaling or fully scaled. Teams working with dedicated AI development services are increasingly focused on closing exactly this gap between experimentation and results.

      • The episode argues that the 88% figure isn't wrong — it's just describing a narrow slice of the business world as though it represents everyone. For most companies, the more relevant benchmark is the one-in-four reality, alongside a growth rate that makes the direction of travel very clear. For more context on where the data comes from, listeners should also check out the earlier DEV.co episode 83% of Developers Use AI Tools — But Only 6.6% Actually Trust Them, which examines a similar confidence gap from the developer side.

      DEV.co

      RFP.co

      6 min
    • 83% of Developers Use AI Tools — But Only 6.6% Actually Trust Them

      Widespread AI adoption among software developers is no longer a trend to watch — it's the current reality. But a sweeping Stack Overflow survey of nearly 31,000 developers reveals a striking contradiction at the heart of that reality: near-universal tool usage paired with near-zero unconditional trust. This episode of DEV.co digs into the software development statistics behind the 83% adoption and 6.6% trust figures to explain what that gap actually means for engineering teams and the profession at large.

      The episode covers a wide range of data points from the 2026 survey landscape and beyond, including:

      • The adoption-favorability flip: In 2023, optimism outpaced usage; by 2025–2026, the inverse became true — more developers use AI than feel genuinely good about it, signaling a more hard-nosed, experienced relationship with the tools.
      • How trust actually breaks down: The single largest group of developers — 48% — said they trust AI output only when they can easily verify it themselves; just 6.6% trust it completely, while 12.3% don't trust it at all.
      • Where AI earns its keep: Code generation in familiar domains (69%), debugging and refactoring (64%), and quick Q&A (59%) dominate use cases — all areas where developers can quickly judge whether the output is correct.
      • Where developers draw the line: Nearly 36% say they don't use AI for production systems and have no plans to — a posture the episode frames as rational risk management, not resistance to change.
      • The agent-driven pull request surge: GitHub data shows agent-started pull requests jumped from 17% to over 40% of all PRs between March and September 2026 — representing 110 million agent-initiated drafts in a single month, with human developers still deciding what ships.
      • Tool fragmentation over dominance: Claude Code leads at 65.5% usage, followed by GitHub Copilot at 58.7%, but 40% of developers use three to five distinct AI products weekly — the market remains pluralistic and experimental.
      • Job market outlook: U.S. Bureau of Labor Statistics data projects 10% developer job growth by 2035, more than three times the average for all occupations, with median salaries at roughly 2.7× the national median — not the picture of a profession being displaced.

        • The episode also contextualizes these findings for teams building AI-powered products — whether that means integrating AI into existing workflows or developing new custom AI applications where the same trust and verification questions arise in a production context.

        For more on a related topic, don't miss the earlier episode Private RAG Over Microsoft 365: Permissions, Delta Queries, and What Actually Ships, which explores how retrieval-augmented generation is being deployed responsibly inside enterprise environments.

        softwaredevelopmentservices.ai

        RFP.co

        5 min
      • Private RAG Over Microsoft 365: Permissions, Delta Queries, and What Actually Ships

        Enterprise teams keep hitting the same wall when grounding LLMs on SharePoint and OneDrive: a working prototype that fails the moment security asks who actually owns access to the returned content. This episode of DEV.co examines the architecture behind a permission-aware, production-grade RAG system over Microsoft 365 — drawing on the team's deep-dive article on private RAG over Microsoft 365 — and maps out exactly where complexity lives and how to handle it correctly from the start.

        The episode covers the full stack of decisions engineering teams face when moving beyond the demo, including:

        • Delta queries and change tracking: How to use the Microsoft Graph delta endpoint to incrementally sync content — additions, modifications, and deletions — without expensive nightly full recrawls.
        • Scoping Graph permissions correctly: Why Sites.Read.All is a zero-trust red flag and how Sites.Selected with explicit site allow-listing is what actually clears a security review.
        • Entra ID object IDs over UPNs: User principal names break when accounts are renamed or deprovisioned; stable object IDs are the right identity anchor for downstream permission filtering.
        • ACL-trimmed retrieval: Materializing effective ACLs as fields on each index record and filtering every query against the caller's resolved group memberships before results are returned — the step most prototypes skip, and the reason overshared files become overshared vectors. Teams building production RAG pipelines need this baked in, not bolted on.
        • Format-aware parsing: The M365 corpus is not just Word docs — spreadsheets, OneNote sections, PowerPoint files, and SharePoint page markup all require distinct parsing logic, and retrieval format support varies significantly across surfaces.
        • Choosing a retrieval surface: A practical comparison of three real options — the Copilot Retrieval API (native ACLs, zero egress), Azure AI Search with security filters (full chunking control), and a fully custom pgvector or Qdrant index (maximum control, maximum ownership) — with guidance on which fits which stage of maturity. Cybersecurity considerations are woven throughout, including the OWASP 2025 LLM Top 10's new vector and embedding weakness category covering data poisoning, embedding inversion, and cross-user context leakage.

          • For more on how ingestion pipeline decisions shape the security boundary of an AI system, the episode Why Your LLM Ingestion Pipeline Is Your Real Security Perimeter covers closely related ground and pairs well with this one.

          DEV.co

          RFP.co

          6 min
        • Why Your LLM Ingestion Pipeline Is Your Real Security Perimeter

          Security teams building LLM-powered products tend to focus on output filters and prompt guardrails — but those controls arrive too late. The document ingestion pipeline is where sensitive enterprise data is processed, classified, and embedded, and it's where most AI-related breaches actually originate. This episode of DEV.co walks through what a production-grade, security-conscious ingestion pipeline looks like from end to end, drawing on DEV.co's deep dive on securing enterprise LLM ingestion pipelines for teams building on RAG architectures.

          The episode covers each stage of the pipeline in concrete detail, with benchmarks and design decisions that go well beyond the usual high-level advice:

          • The breach numbers that make this urgent: IBM's 2026 Cost of a Data Breach report puts the average AI-related incident at $5.3 million — and 92% of those organizations lacked proper AI access controls. The 2026 OWASP LLM Top Ten confirms the pattern: sensitive information disclosure, data poisoning, and vector/embedding weaknesses all trace back to the pipeline, not the model.
          • Connectors as policy objects: Every data source — SharePoint, Confluence, Salesforce, S3, Postgres — should be treated as a declared policy boundary, not a script. Connectors must specify tenant ownership, classification rules, and re-sync cadence. Change data capture beats full re-indexing for both cost and accuracy.
          • Classification must run first: Every document gets a sensitivity label (public, internal, confidential, restricted) before chunking or embedding. That label propagates to every derived chunk and governs whether the chunk is redacted, embedded at all, or retrievable by a given role. For teams building production retrieval-augmented generation systems, skipping this step is not a shortcut — it's a liability.
          • Redaction before embedding — not after: Once sensitive text is inside a vector index, it's extremely difficult to find and purge. A 2026 benchmark of regex, spaCy NER, GLiNER, and hybrid pipelines found PII leak rates ranging from 0.04% to 0.41% depending on configuration. The winning approach is a hybrid: regex for structured identifiers, named-entity recognition for names and locations, and an LLM pass only for ambiguous chunks. Pure LLM redaction is roughly 14× slower than transformer NER and introduces its own data-egress risks.
          • Stable token replacement over deletion: When a sensitive identifier is detected, replacing it with a typed, hashed placeholder (rather than deleting it) preserves chunk length and sentence structure — both of which affect embedding quality. The mapping between token and real value lives in a separate, access-controlled vault, never in the vector store itself.
          • Access-control metadata on every vector: Chunks written to the vector store must carry tenant ID, classification label, source document ID, allowed roles, and a retention clock. Retrieval should filter by authorization before similarity search runs. On storage: pgvector with HNSW indexing hit 0.978 recall at 2.6 ms median latency on a 100K-vector benchmark — and below roughly 10 million vectors, it's a full production choice that also provides ACID compliance and row-level security in the same engine as application data.

            • For more from the show, check out the episode Claude Code vs Cursor vs Copilot: What Enterprise Teams Actually Need to Know, which looks at how development tooling choices play out at the enterprise level. Teams looking for expert help implementing secure AI infrastructure can also explore DEV.co's cybersecurity development services.

            DEV.co

            RFP.co

            6 min
          • Claude Code vs Cursor vs Copilot: What Enterprise Teams Actually Need to Know

            Choosing an AI coding assistant for a thousand-seat enterprise isn't a productivity decision — it's a compliance, cost, and risk decision first. This episode of DEV.co cuts through the marketing noise to give engineering leaders a practical framework for evaluating Claude Code, Cursor, and GitHub Copilot on the dimensions that actually determine whether a rollout succeeds or quietly blows up the budget. The full breakdown is available in the enterprise AI coding tool comparison on DEV.co.

            Here's what the episode covers:

            • True cost of ownership: Sticker prices range from $19 to $40+ per seat per month, but production agentic workloads are driving real spend to $100–$200 per active developer monthly — meaning a thousand-seat deployment can run anywhere from $228K to over $2M per year depending on plan and usage.
            • Security tiers that actually cut the shortlist: All three tools carry SOC 2 Type II, but only GitHub Copilot offers FedRAMP Moderate hosting (with a 10% model-multiplier premium), and only Claude Code Enterprise offers true VPC deployment where code never leaves the customer's network.
            • MCP as an emerging attack surface: The CurXecute vulnerability (CVE-2025-54135, CVSS 8.6) demonstrated how a poisoned MCP server can trigger silent remote code execution — a warning that any AI assistant with auto-run MCP capabilities needs the same access controls as a CI/CD service account, regardless of vendor.
            • What the productivity research actually shows: A 95-developer GitHub study found a 55% speed gain on greenfield tasks, while a separate METR trial of 16 senior open-source contributors found a 19% slowdown on real-world tickets — a gap that comes down to repo familiarity, code complexity, and review overhead.
            • Market momentum vs. mindshare: GitHub Copilot leads on total users (20M+), but a 2026 survey of ~1,000 engineers named Claude Code the most-loved tool at 46%, while JetBrains data shows Claude Code's workplace adoption doubling from 18% to 39% in the first half of 2026 alone.
            • A four-step procurement framework: Gate on compliance requirements first, run a disciplined four-week pilot (20 engineers, same repo, PR cycle time and change-failure rate as metrics), harden MCP access like a privileged service account, and plan for a multi-tool reality — about 70% of engineers already use two to four assistants simultaneously.

              • For teams building or scaling AI-powered development workflows, DEV.co's enterprise software development services and AI application development practice can help evaluate tooling strategy alongside broader architecture decisions. For more on the financial trade-offs of different AI deployment models, listen to the episode Private AI vs Proprietary AI: The Real Token Math in 2026.

              DEV.co

              RFP.co

              6 min
            • Private AI vs Proprietary AI: The Real Token Math in 2026

              Running your own AI model feels like a natural cost-cutting move — until you work through the actual numbers. This episode of DEV.co digs into the full economics of self-hosted versus hosted LLMs in 2026, grounding the conversation in real GPU benchmarks, current API pricing, and the hidden operational costs that rarely appear on a spreadsheet. The analysis is drawn from the DEV.co deep-dive on private vs. proprietary AI token math, and the conclusions are more nuanced than most teams expect.

              Here's what this episode covers:

              • The hosted baseline keeps dropping: Models like Claude Haiku 4.5 and GPT-4o mini have pushed inference costs to as low as $0.15–$1.00 per million input tokens, with batch APIs and prompt caching making the gap even harder to close.
              • What self-hosting actually costs in 2026: H100 GPU rental rates range from ~$1.50/hr on spot-market neoclouds to over $12/hr on hyperscaler on-demand tiers, with fully loaded production costs landing between $4,000–$6,000 per GPU per month once ops overhead is factored in.
              • The real break-even thresholds: Against Claude Haiku 4.5, self-hosting starts to pencil out above roughly 1–1.4 billion output tokens per month per GPU; against GPT-4o mini, the economics almost never favor self-hosting on price alone.
              • Batch APIs and prompt caching shift the goalposts: Haiku's batch pricing drops blended cost to around $1.10/million tokens, and cached input reads at $0.10/million — which effectively dismantles the economics of self-hosting prompt-heavy or repetitive workloads.
              • Four reasons price-per-token is the wrong lens: Data residency requirements, fine-tuning freedom, latency control, and vendor concentration risk are all legitimate justifications for self-hosting that don't show up in the API bill — especially for regulated industries where cybersecurity and data governance are non-negotiable.
              • Open-weight licensing and procurement risk: Llama is not truly open source, Qwen and DeepSeek carry their own terms, and Chinese-origin models now account for 89% of enterprise open-source LLM spending — making this a procurement and compliance conversation, not just a performance one. Teams building production-grade private LLM deployments need to review these terms before committing to a model.

                • The episode closes with a clear-eyed reminder: a self-hosted LLM is a full production service requiring on-call coverage, observability, driver management, abuse controls, and eval pipelines. Teams that cost it correctly treat it as part of a broader architecture — not a standalone shortcut. For more on the risks introduced when AI is embedded into production systems without proper review, listen to The Hidden Risks of 100% AI-Generated Code — and How to Audit It.

                DEV.co

                RFP.co

                6 min
              • The Hidden Risks of 100% AI-Generated Code — and How to Audit It

                When a quarter of Y Combinator's Winter 2025 batch reported codebases that were roughly 95% AI-generated, the tech press called it a productivity story. The DEV.co team reframes it as a risk-management story — one that matters to anyone acquiring, insuring, or shipping that code. This episode, based on this in-depth look at the hidden risks of AI-generated code, walks through what the data actually says about quality, security, intellectual property, and insurance exposure when human oversight is the exception rather than the rule.

                Key points covered in this episode:

                • Quality gap, by the numbers: A Sonar survey of 1,100+ professional developers found that AI co-authored pull requests average nearly 11 review issues each — roughly 1.7× the technical debt of human-only PRs — and only 48% of developers said they always verify AI output before committing.
                • Security vulnerabilities are the norm, not the exception: Veracode's 2026 GenAI Code Security Report found that about 44% of AI code generation tasks introduced a risky security flaw. Georgia Tech's Vibe Security Radar recorded a near-sixfold spike in AI-tool-attributable CVEs in just two months, and a critical command-injection flaw in GitHub Copilot (CVE-2025-53773, CVSS 7.8) demonstrated that the tools themselves aren't safe from exploitation. Teams looking to close these gaps systematically can reference DEV.co's cybersecurity development services.
                • Intellectual property is thinner than founders assume: The US Copyright Office does not protect purely AI-generated code — meaning up to 95% of an AI-heavy codebase may be unregistrable as original expression, creating real exposure in acquisition diligence and competitive disputes. License contamination from copyleft training data compounds the risk further.
                • Insurance markets have already responded: ISO introduced generative AI exclusion endorsements effective January 1, 2026. Some cyber carriers are capping AI-related claims at roughly 10% of the policy limit, and losses tied to undocumented AI-generated code outside a governance framework are now explicitly excluded by many policies.
                • A practical audit has five concrete steps: Build an attribution ledger (tool, model version, prompt summary, reviewer); run a full-codebase license contamination scan; define a human rewrite threshold in writing; map security controls to the OWASP LLM Top 10; and review ISO endorsement forms CG 40 47, CG 40 48, and CG 35 08 before renewal — not after a claim. Teams using professional QA and testing services are better positioned to maintain the review records insurers and acquirers now expect.

                  • For more on building AI-assisted products responsibly, listen to Using AI to Build a Customer Portal: The Dos and Don'ts That Actually Matter. Full episode notes and related resources are linked below.

                  DEV.co

                  RFP.co

                  6 min
                • Using AI to Build a Customer Portal: The Dos and Don'ts That Actually Matter

                  Building a customer portal with AI in the loop sounds like a productivity win — and it can be. But "using AI" actually describes two distinct problems that fail in completely different ways, and most teams treat them as one. This episode of DEV.co unpacks the dos and don'ts that separate a fast, safe portal build from one that ships a quiet security hole, drawing on the full guide on AI-assisted customer portal development that the episode is based on.

                  Here's what the episode covers:

                  • Two separate scoping problems: AI as a developer productivity tool and AI as an in-product feature for end users have different risk profiles, different cost structures, and need to be audited separately — conflating them is the first and most common mistake.
                  • Where AI coding assistance genuinely pays off: Repetitive CRUD endpoints, boilerplate forms, migration scripts, test fixtures, and OpenAPI specs from existing handlers — tasks where a senior engineer can review the diff and discard what's wrong in under a minute.
                  • Where AI assistance becomes dangerous: Authorization logic, tenant scoping in database queries, cryptography, and payment idempotency handling are all areas where plausible-looking generated code is the failure mode, not the success condition.
                  • The auth boundary decision that has to happen on day one: Tenant identity belongs in a signed token, row-level security should exist as a second line of defense at the database layer, and role-based access control should be auditor-readable — not scattered conditionals that a scaffolder quietly introduced. Broken Object Level Authorization leads the OWASP API Security Top 10 for a reason, and a portal is essentially that problem wearing a polished UI. Teams building on solid cybersecurity development practices will recognize this as foundational, not optional.
                  • Building a production LLM help panel the right way: A chatbot inside a portal is a system, not a prompt — retrieval must be scoped by authenticated tenant, every prompt and response needs to be logged with tenant and user IDs, and a defined fallback to a human queue is non-negotiable when the model is uncertain.
                  • Compliance and vendor data handling: Sending customer data to a hosted model makes the vendor's data practices part of your compliance posture. Strip identifiers before the prompt, pin the model and region, disable training on your traffic in writing, and retain logs with enough detail to make an incident resolvable. Teams building custom AI applications at the enterprise level will find this checklist directly applicable.

                    • The failure modes covered — tenant data leaking through a scoped retrieval layer, a scaffolded endpoint trusting a client-supplied identifier, a chatbot citing a document the asker never had access to — are predictable, and they're preventable when the right decisions get made before anyone writes a single prompt. For more on what large-scale AI and API work actually costs and involves, the episode What Enterprise API Integration Actually Costs in 2026 is a natural companion listen.

                    DEV.co

                    RFP.co

                    6 min
                  • What Enterprise API Integration Actually Costs in 2026

                    Enterprise API integration is one of the most consistently under-budgeted line items in modern software projects. This episode of DEV.co unpacks the numbers that actually appear in statements of work — not vendor slide decks — and explains why the gap between the first budget and the final invoice is almost never a surprise to engineers, even when it is to everyone else. The discussion draws on findings from MuleSoft's 2026 Connectivity Benchmark Report and Salt Security's 2024 State of API Security Report, alongside real-world project ranges compiled in this 2026 enterprise API integration cost breakdown.

                    The episode walks through five distinct integration types and their realistic cost bands, then identifies the five technical factors most responsible for pushing a project from the low end of a range to the high end. Here's what's covered:

                    • Simple REST integrations — documented OpenAPI spec, standard auth, a few endpoints — run $8,000 to $30,000; the baseline that most projects claim to be and few actually are.
                    • Webhook-driven integrations ($20,000–$75,000) carry a small build footprint but significant operational design cost: idempotent handlers, dead-letter queues, retry logic, and signature verification all add up fast.
                    • ERP and CRM integrations with platforms like SAP, Salesforce, or NetSuite typically land between $60,000 and $250,000, with each additional orchestrated system adding $25,000–$75,000 — and weeks of waiting for sandbox access.
                    • EDI integrations run $40,000–$180,000 per trading partner, where every partner is effectively its own subproject with its own quirks and legacy expectations.
                    • Real-time event-driven architectures (Kafka, schema registries, exactly-once semantics) start at $120,000 and can exceed $500,000 — the territory of banking, logistics, and marketplace platforms.
                    • The five cost drivers explored in depth: authentication complexity, undocumented rate limit behavior, schema drift, idempotency and event ordering, and the observability infrastructure needed to operate safely in production.

                      • The episode also covers the build-vs-buy decision in concrete terms. The iPaaS market surpassed $9 billion in 2024 and is projected to reach $17 billion by 2028, and tools like MuleSoft, Workato, Boomi, and Celigo exist precisely because connector work is repetitive. But enterprise MuleSoft contracts regularly land between $250,000 and $1 million annually once non-production environments and premium connectors are factored in — and implementation services sit on top. Teams working with enterprise software development partners or evaluating API development and integration services will find the build-vs-buy framework especially useful for year-one planning. The episode closes with a practical cost template for a mid-market company integrating one ERP, one CRM, and several SaaS tools: $350,000–$900,000 for three to six integrations including platform work. For more on production-readiness concerns in complex architectures, the episode AI Agents in Production: Approvals, Audits, and RBAC Explained covers related governance and reliability territory worth pairing with this one.

                      DEV.co

                      RFP.co

                      6 min
                    • AI Agents in Production: Approvals, Audits, and RBAC Explained

                      The promise of autonomous AI agents running finance, marketing, and operations sounds compelling — until something goes wrong and no one can prove what the agent did, who authorized it, or whether the right controls were ever in place. This episode of DEV.co cuts through the governance theory and gets into the practical architecture that separates a production-ready agent deployment from one that's quietly waiting to fail. Drawing on the full companion article on AI agents in production: approvals, audits, and RBAC, the episode gives technical teams concrete schemas and patterns they can actually ship.

                      Here's what the episode covers across three core control-plane components:

                      • Approval queues as a data model: The minimum schema every pending agent action needs — request ID, correlation ID, risk tier, reviewer options, expiration timestamp, and a null-until-decided decision field — and why stale approvals should fail closed, not execute.
                      • Action tiering and dual control: How to classify agent actions from auto-execute reads all the way up to two-approver gates for payments, credential grants, and production config changes — and why that dual-control pattern mirrors where regulators are heading for high-risk AI systems.
                      • Approval fatigue is a real threat: Research showing that human reviewers approve over 90% of prompts (not because the actions are safe) and catch only ~14% of harmful ones, compared to ~90% for an automated classifier — and what that means for how to design the human-in-the-loop layer.
                      • Immutable audit logs vs. application logs: Why these are fundamentally different stores, how hash-chained Postgres tables, Kafka-backed WORM storage, and managed cloud append-only stores all achieve tamper-detectability, and what each log entry must contain (including content hashes instead of raw sensitive values).
                      • Retention and replay requirements: How PCI DSS, HIPAA, and other regulated workloads set minimum retention windows — and why the log must support reconstructing the agent's state at decision time, not just recording the tool call.
                      • RBAC with agents as principals: A four-layer permission model covering agent roles (scoped per function), reviewer roles (with separate dual-control identities), operator roles (pause/resume/stop), and read-only auditor roles — all relevant to teams building with custom AI agent development frameworks.

                        • For teams operating in regulated industries or scaling cybersecurity-conscious infrastructure, the control plane isn't optional — it's what makes the difference between an agent that works and one you can trust. Listeners interested in adjacent security and compliance concerns in AI systems will also want to check out the episode Secure AI Agents for ERP, CRM, and Finance Systems.

                        DEV.co

                        RFP.co

                        6 min

                      About DEV

                      From the publisher's feed

                      Software and web development from the side that has to ship it and then live with it. Architecture decisions with a cost attached, scoping, technical debt, hiring and vendor selection, and the AI tooling question every engineering team is now answering whether they planned to or not.