AI-Wiki

AI-Native Software Engineering: Enduring Principles, New Pace

19 min read

AI is rapidly changing how software is produced but not the need to engineer software to meet business and mission goals. AI is enabling developers to move from idea to implementation at incredible speeds. However, this fast pace has implications that teams must manage. Product quality does not come for free, and there is some tendency for AI to accelerate the accumulation of technical debt. In addition, what works well on small code bases doesn’t always work as well on large code bases. So, what’s a good software engineer to do?

Software engineering principles and practices are essential in guiding software engineers to use AI to achieve production-ready outcomes. In this webcast, experienced software engineers discuss their observations and lessons from applying AI-native software engineering and studying its use across multiple projects.

What Will Attendees Learn?

  • Distinguish between “vibe coding” and software engineering
  • Understand how software engineering principles improve the use of AI and where these principles need to be adapted to be used with AI
  • Recognize the different criteria that can be used to assess the benefits of AI-native software engineering (e.g., productivity and software quality) and their potential tradeoffs

Sinclair, Ivers & Benitez / SEI — AI-Native Software Engineering: Enduring Principles, New Pace

Software Engineering Institute (SEI) at Carnegie Mellon University webcast — was-live, published 21 May 2026, ~61 minutes. Host Scott Sinclair (software architect, SEI) in conversation with James Ivers (principal engineer, SEI; 30+ years research and application + software architecture) and Mario Benitez (software architect, SEI; 20+ years software engineering). The wiki’s first institutional-research-centre voice on the AI-coding-era software-engineering-discipline question.

TL;DR

  • Definitional grounding (the talk’s stated learning objective #1): AI-native vs AI-augmented vs agentic vs vibe-coding as a vocabulary the field is using loosely. The SEI takes are: “AI native is essentially a state of mind where we’re not thinking about it as this new thing or trying to figure out how to use it — it’s this future state in which it’s just something we use” (Ivers); “AI native is not AI only” (Ivers); AI-native means understanding where AI use derives the most value in line with the business/mission goal (Benitez).
  • The technical-debt-acceleration thesis (the talk’s load-bearing empirical claim): “We can generate code at rates we’ve never thought of before. We can also generate technical debt at rates that we’ve never thought of before” (Benitez). Paired with Ivers’s quoted observation from another talk: “no one has maintained code that was AI generated for 5 years. It hasn’t been around that long.” The 5-year-maintenance-horizon argument is the institutional-altitude caveat the wiki’s agentic-engineering / vibe-coding corpus has not previously named explicitly.
  • The 25,000-line vibe-coding experiment as worked example: Ivers built “an application soup-to-nuts, 25,000 lines of code in language I never written before. I got a very slick application but under the hood it was structured terribly. The architecture was bad. It wasn’t very maintainable.” The wiki’s clearest institutional-altitude worked example of where the vibe-coding-vs-engineering boundary lies.
  • Engineering principles endure: DRY, SOLID, YAGNI remain load-bearing (Ivers, on the maybe we can just regenerate debate). The SEI view: “we don’t let go of the safeguards that we have now just because there’s more code. We might scale it differently.”
  • The under-specification failure-mode: “If I gave it a loose requirement, fine. It would just go generate code and it would fill in all the blanks. It would decide what corner cases worth handling, what weren’t, what I really meant by that requirement. Terrible idea” (Ivers, on the what bad practices does AI magnify question). The institutional-altitude restatement of Momentic’s truth-driven / spec-driven development thesis — AI raises the cost of vague specs, not lowers it.
  • Architects more important under AI volume: “There are a lot of people out there who are using this technology who are saying that architects are more important than ever because it’s those big-picture decisions that guide everything else and those are the upstream things that tend to be historically more expensive to change” (Ivers). The role-shift is away from line-level coding, toward architecture-level direction-giving + business-context translation.
  • Coder vs Software Engineer (the talk’s closing role-shift framing): “A coder in an abstract sense is someone who just grabs a Jira ticket, implements a feature, checks it in. Software engineers go beyond that. The narrow interpretation of coding might be fading. But those people who can bring engineering judgment, point AI in the right direction, connect it to the business, connect it to the users — that’s an incredibly valuable skill that’s never resided solely in a programming language” (Ivers, closing reply to the audience question Will AI replace developers?).
  • Slop-squatting as a new attack vector: AI-generated code sometimes references package names that don’t exist; adversaries create dummy repositories with those bogus names; ingestion of AI code without SBOM / supply-chain-discipline becomes a new attack surface (Ivers).
  • Measurement caveat: “There have been too many people who say ‘I can generate code faster.’ Fantastic. I believe that. That doesn’t mean another phase didn’t get longer. If your code is a lot faster, your test time is an order of magnitude larger, you may not be seeing quite the measure of the magnitude of savings that you expect” (Ivers). The total-cycle-time discipline.

What was actually ingested

The full ~61-minute transcript (ASR auto-captions, light cleanup). The Playwright path failed at 30s timeout but succeeded at 60s timeout — long-format ASR-only videos often need the longer timeout. Speaker name normalised: “Mario Bonitez” (ASR) → “Mario Benitez” (per the channel description). 581 segments retained verbatim except for the one name standardisation and stage-cue retention. Full raw at raw/videos/2026-05-21-sinclair-ivers-benitez-sei-cmu-ai-native-software-engineering.md.

Substantive content

1. Definitional grounding — AI-native vs AI-augmented vs agentic vs vibe-coding (0:32–3:34)

Sinclair opens with the framing problem: these terms “are all floating around and they’re often used in different ways by different people”; the webcast aims to “get a few working definitions to ground our common frame of reference.”

Ivers’s opening on what’s changed in the AI-coding era: “What we were doing two years ago with chat GPT is nothing compared to what we’re doing right now with tools. What we’re usually talking about are AI coding agents or even our own custom agentic frameworks. And the big game-changer here is these tools can now access your data. They can access your repository, your databases — within permissions of course — but they can also take actions. They can run your tests. They can run your tools. They can help you with debugging. And it’s really tightening the loop in terms of what AI can do.” The SEI framing of agentic tooling is structurally consistent with the wiki’s agent-harness vocabulary: the code surrounding the model that connects it to the environment (cf. Harrison Chase / Interrupt 26).

Benitez on AI-native: “It means understanding where my use of AI is going to derive the most value in line with what I’m trying to accomplish as a company, as a business, as an individual.” AI-native is not a technology stance — it’s an alignment stance. “It means not just abandoning the things that we know are good. Think about static analyzers — they’ve been around forever. You can absolutely use them. You can put them in with your AI. You should use them. You can make the output of your AI better.”

Ivers’s load-bearing rhetorical claim: “AI native is not AI only.” “AI is a tool. It’s a tool that can help us more effectively at some tasks than in others. But what we’ve seen in our own experience is combining AI with non-AI techniques really gives you more leverage than using either alone.” This is the institutional-altitude restatement of Forsgren & Macvean’s DORA-rooted AI as amplifier claim.

Ivers on AI-native as a state: “AI native is essentially a state of mind where we’re not thinking about it as this new thing or trying to figure out how to use it. It’s this future state in which it’s just something we use. We learn how to do it. We need to know how to integrate into our engineering processes because at the end of the day, we’re not going to trust AI fully any more than we trust developers fully. The history of software engineering is layering on additional tools and practices and training so that we can trust the process even if we don’t trust every individual element throughout it.”

2. AI in the SDLC — where it fits, where it doesn’t (15:13–22:00)

Benitez’s SDLC-phase decomposition:

  • Early activities (requirements, design): AI provides “input — typical requirements you see in these types of applications, design patterns you can choose from.” Useful as an additional perspective / option, but the human still applies context (6-month deadline, customer constraints, budget).
  • Middle activities (code, tests): “That’s where we see it shine a lot — really good at implementing code, really good at implementing tests.”
  • Later activities (validation, deployment, maintenance): “a little bit more iffy on the validation side.” This is where the technical-debt-acceleration concern lives.

3. The productivity / technical-debt tradeoff (27:20–34:30) — the talk’s substantive centerpiece

Ivers, on the “no one has maintained AI-generated code for 5 years yet” framing: “I heard in a talk earlier this week that really connected with me — no one has maintained code that was AI generated for 5 years. It hasn’t been around that long. We don’t know what it’s going to be to maintain this code in five years. So in terms of productivity, we have short-term and long-term perspectives.”

The measurement discipline (Ivers): “We’ve got to measure the right thing. There have been too many people who say ‘I can generate code faster.’ Fantastic. I believe that. That doesn’t mean another phase didn’t get longer. If your code is a lot faster, your test time is an order of magnitude larger, you may not be seeing quite the measure of the magnitude of savings that you expect. So we have to have wide enough aperture that we’re doing apples-to-apples comparisons. We recognise that while some activities will go faster, others won’t. If we measure that, we can learn from it.”

Benitez on the don’t burn tokens to burn tokens discipline: “I don’t want to burn tokens just to burn tokens. What’s the point of that? I want the ultimate result to be beneficial. Yes, I want to measure so that I know — am I really going faster, or am I just burning tokens?”

The technical-debt-acceleration claim (the talk’s load-bearing empirical centerpiece), Benitez: “We can generate code at rates we’ve never thought of before. We can also generate technical debt at rates that we’ve never thought of before.” Ivers’s framing: “That’s not meant to be a scary thing. It should be an empowering thing because we as users of the technology have a lot of influence over the direction that we go, the safeguards, the guardrails that we put in place, the practices we put in place. We can steer this in a good direction.”

The 25,000-line vibe-coding experiment (Ivers, ~32:55): “I did a vibe-coding experiment. I produced an application soup-to-nuts, 25,000 lines of code in language I never written before. That was impressive. I got a very slick application but under the hood it was structured terribly. The architecture was bad. It wasn’t very maintainable.” The empirical anchor for the prototype-vs-engineering gap at SEI scale.

The maybe we don’t have to maintain anymore counter-argument and Ivers’s rebuttal (~33:39): “There is a debate that says maybe we don’t have to maintain anymore. Maybe we can just regenerate. Maybe AI can do all of this for us. Maybe the quality of the code doesn’t really matter. I’m not sold on that one. The kinds of principles we’ve developed in software — think DRY, SOLID, YAGNI — these are all principles that make code cleaner…” The institutional-altitude defence of the durable engineering principles.

4. The human bottleneck shift (40:00–43:25)

Ivers, on whether the human reviewer is the new bottleneck: “There’s some old research saying that the limit is around two hours and then you need a break. You just cannot keep up at that same pace. There is a lot of merit in an independent review. Humans are go-to. There are some experiments using a different AI model than the one you generate code with as another reviewer. We’ve got to get smarter in that space because the pace of production is going to outpace the pace of traditional review.”

Benitez’s reframe: “Even if yes, we are becoming a bottleneck — we are absolutely becoming a bottleneck — but we always were. We were always the bottleneck. It’s just before it used to be a much slower pace. Before we had code, now it’s like… okay. Well, now let’s maybe put more emphasis on that review.”

Sinclair’s connection back to measurement: “What does your entire development workflow look like? Which stages are getting faster? Where is that creating new bottlenecks in the process? How do you attack that based on the data?“

5. Architecture and ADRs in the AI-volume era (45:00–50:30)

Ivers on the role of the software architect in the AI era: “There are a lot of people out there who are using this technology who are saying that architects are more important than ever because it’s those big-picture decisions that guide everything else and those are the upstream things that tend to be historically more expensive to change. And that insight really is tied to the organization’s goals.”

Ivers on where AI helps the architect: ideation (tech stack options, requirements brainstorming, quality-attribute scenarios) + finding references that justify recommendations. Where AI is less helpful: “come up with complex bespoke architectures for systems you don’t typically find on GitHub that are much less likely to be in the training corpus. There’s still more judgment in these special-purpose, usually very demanding systems.”

On ADRs (Architecture Decision Records) under AI volume: “AI currently is better with text. So things like ADRs are a way to capture that, but ADRs can proliferate quickly if you’re not careful, and managing the context spread is hard.”

Benitez’s compiler-analogy (~46:00): “Before, we used to write assembly code and then compilers came along and you no longer needed to do that. I know this is still non-deterministic — I know because James is going to say, well, you know, those are non-deterministic — but we’re elevating a little bit. I’m not sure how much. What that tells me is that we have to be thinking more in terms of the system we’re building, understanding the business, the domain we’re applying this system.” The wiki’s institutional-altitude operational restatement of software-3.0: the abstraction layer is moving up, but the new abstraction is non-deterministic, which changes how we have to reason about it.

6. Security — AI code is more vulnerable, plus slop-squatting (51:14–52:42)

Audience question: “Recent analysis shows that AI code has more security issues than human-generated code. Given that it’s projected to exceed 50% of all global code by 2027, how do we mitigate this?”

Ivers: “We fall back on what we do already. All of our code should be going through a vulnerability scanner. Some organizations have been really proactive in training our staff to look for security issues. We don’t let go of the safeguards that we have now just because there’s more code. We might scale it differently.”

Slop-squatting (Ivers’s new attack vector contribution, the wiki’s first surfacing of this term): “Generative AI generates code for us. Sometimes it’ll generate an include or a with of a package that doesn’t really exist. The name sounds good but doesn’t really exist. This has actually become an attack vector where adversaries can create a dummy repository with that bogus name. So, seems like a new problem, but if we’re doing good supply-chain management, if we’re looking at SBOMs or other ways to take a look at what we do before we integrate third-party code, then we should have a handle on this as well.”

7. The bad-practices-AI-magnifies catalogue (52:42–54:12)

Ivers on the what bad practices should be addressed first question:

Under-specification (the institutional-altitude restatement of Wu / Momentic’s spec-driven thesis): “The big one I would start with is under-specification. AI — I noticed this right away when I started using cursor. If I gave it a loose requirement, fine. It would just go generate code and it would fill in all the blanks. It would decide what corner cases worth handling, what weren’t, what I really meant by that requirement. Terrible idea. But then again, we wouldn’t do this with our interns. We wouldn’t give them a fuzzy problem and expect them to go off for 6 weeks and come back with code that’s done.”

Acceptance of AI output without discipline: “There’s tremendous temptation with this technology. It generates something, it shows up, I run it, that looks right. It’s so tempting to just run with it and keep going and produce more and more and more. We’ve got to put the brakes on ourselves and exercise that discipline if we want to avoid some of those downstream consequences.”

8. The role-shift framing — coder vs software engineer (56:16–58:00, the talk’s closing rhetorical claim)

Audience question: “AI’s here. I’m a little bit worried about my job. Is AI going to replace developers?”

Ivers’s framing: “I have this mental model. I’ve always had a difference between a coder and a software engineer. A coder in an abstract sense is someone who just grabs a Jira ticket, implements a feature, checks it in, moves on to the next ticket. Not a lot of big-picture thinking. Software engineers go beyond that. We think about the overall design, how our code fits with the design. Is the design appropriate? How do we get this through quality assurance? How do we convince our certifying bodies that things are correct? There’s a much broader perspective in terms of it’s not about the line of code. And many software engineers don’t care about the language really because it’s just not that big a deal to them. It’s the higher-level questions.”

The role-shift prediction: “That narrow interpretation of coding might be fading. That might be where we’re more likely to see job impact. But those people who can bring engineering judgment, point AI in the right direction, connect it to the business, connect it to the users — that’s an incredibly valuable skill that’s never resided solely in a programming language that I think is more enduring and will survive and be more critical than ever.”

Benitez’s closing on what to do if you’re worried about your job: “Get that systems thinking, that business mentality, understanding the constraints. If I’m worried about my job, where do I go? I go there. I want to learn more about the business.”

9. Closing thoughts (58:09–59:05)

Ivers: “It’s a really exciting time. It’s a faster change than we’ve seen and there’s a ton of potential. However, there’s a lot of risk as well. I think we have not just an opportunity, but a responsibility to point AI in the right direction and to bring that discipline to bear. If we do that, we’ve got a great future.”

Benitez: “We’ve got to adopt it. We’ve got to embrace it. Understanding its implications, understanding how we derive the most benefit from it. Because again, we don’t do this for fun — sometimes we do — but there’s a reason. The business model, the mission, that’s the goal. Stay focused on that and use this as your tool to get there.”

Linked entities and concepts

Entities directly named or substantively discussed in the source:

  • Software Engineering Institute — Dangling first mention (the institution; federally-funded research and development centre at Carnegie Mellon University).
  • Carnegie Mellon University — Dangling first mention as substantive entity (already cross-referenced from Diana Hu biographical context and Stanford GSB DARPA-self-driving-car anecdote, but no entity page yet).
  • Scott Sinclair — Dangling first mention (software architect at SEI; host of this webcast).
  • James Ivers — Dangling first mention (principal engineer at SEI; the load-bearing rhetorical voice in this episode).
  • Mario Benitez — Dangling first mention (software architect at SEI).

Concepts touched substantively:

  • agentic-engineering — the AI native is not AI only + engineering-principles-endure + measurement-discipline + 25,000-line vibe-coding-experiment + coder-vs-software-engineer anchors. Source-count: +1.
  • vibe-coding — the institutional-altitude operational definition + Ivers’s 25,000-line experiment + the prototype-vs-production boundary. Source-count: +1.
  • agent-harness — Ivers’s framing of AI coding agents and custom agentic frameworks as tightening the loop via tool-access matches the wiki’s harness vocabulary. Source-count: +1.
  • software-3.0 — Benitez’s compiler-analogy: “before, we used to write assembly code and then compilers came along; we’re elevating a little bit” is the institutional-altitude restatement of the Software 3.0 abstraction-layer-shift framing. Source-count: +1.
  • enterprise-ai-adoption — the AI-native-as-state-of-mind + combine-AI-with-non-AI-techniques alignment framing. Source-count: +1.
  • automation-vs-augmentation — the coder-vs-software-engineer role-shift framing + AI is a tool, not a replacement — augmentation at the discipline level. Source-count: +1.
  • micro-productivity-trap — Ivers’s measurement-discipline argument (just measuring code-gen speed is wrong) is the institutional-altitude restatement of the micro-productivity-trap warning. Source-count: +1.
  • durable-skills — the engineering judgement / business connection / systems thinking as the surviving meta-skills closing argument. Source-count: +1.

Dangling (single-source mentions, deferred): Software Engineering Institute, Carnegie Mellon University, Scott Sinclair, James Ivers, Mario Benitez, slop-squatting (as a named attack-vector concept; promote to concept page on second-source mention).

Caveats

  • 61-minute SEI/CMU webcast with three SEI-employed speakers; views expressed are practitioner observations from the SEI research-and-application context, not externally peer-reviewed empirical claims.
  • The “no one has maintained AI-generated code for 5 years” is Ivers quoting a prior talk; not a research-published claim.
  • The 25,000-line vibe-coding experiment is a single anecdote without comparison baseline or quality-metrics disclosed; treat as illustrative not measured.
  • The slop-squatting attack-vector claim is a real and growing concern in 2026 supply-chain security but Ivers cites no specific incident anchor on stage.
  • The AI code has more security issues than human code claim referenced in the audience question is attributed to “recent analysis” without citation; treat as widely-cited finding the SEI panellists accept directionally.
  • The 50%-of-global-code-by-2027 projection in the audience question is uncited; treat as forecasting claim the audience question put forward, not an SEI estimate.
  • The Q&A includes a brief Speckit-vs-other-options question Sinclair starts to ask Benitez (around 54:12) that the transcript renders incompletely (~40-second segment-text gap likely from an audio dropout) — the Speckit comparison answer is not substantively in the ingested transcript.
  • The closing two minutes (1:00:22 onward) are music-bleed / mic-pickup of intro/outro audio (“Heat. Heat. N. [music]”) not substantive content.

Relationships

Supports

  • Software engineering at the tipping point — **Same-day paired institutional anchors on the *AI does not replace engineering discipline* thesis** — both published 21 May 2026, both at the ecosystem/system altitude rather than individual-engineer altitude. Bender (Google I/O Professional Development track) frames the developer ecosystem as a socio-technical complex adaptive system and warns *'generating code 10× faster ≠ engineering 10× faster'*. Sinclair/Ivers/Benitez (SEI/CMU webcast) frame the same observation in software-engineering-discipline terms — *'AI native is not AI only'* (Ivers) + *'we can generate code at rates we've never thought of before. We can also generate technical debt at rates that we've never thought of before'* (Benitez) + *'no one has maintained code that was AI generated for 5 years yet — we don't know what it's going to be to maintain this code in five years'* (Ivers, quoting an earlier talk). **The shared structural claim**: AI-era productivity *measurement* must extend past the code-generation phase; total cycle time matters more than gen speed; if test/review/maintain phases get longer, the gen-phase speedup is illusory. Same warning from Google-vendor altitude (Bender) and US-federal-funded-research-centre altitude (SEI) within hours of each other.
  • Build core skills to thrive as an AI-era developer — **Paired DORA-rooted-fundamentals anchors at the institutional altitude** — Forsgren & Macvean (Google I/O 2026 individual-engineer altitude) name *AI as amplifier — fundamentals determine direction*; Sinclair/Ivers/Benitez (SEI/CMU institutional altitude) operationalise the same claim as a software-engineering-discipline programme: *'we can't just abandon the things we know are good'* (Benitez) + the DRY/SOLID/YAGNI principle retention argument (Ivers) + *'engineering discipline still matters'* (Ivers on the silver-bullet question). The wiki now has **three sources from May 2026 alone** converging on the AI-as-amplifier-not-substitute thesis at three altitudes (individual-engineer / ecosystem / institutional-research-centre).
  • AI era skills: Why cultivating agency matters more than job titles | Max Schoening (Notion) — **Paired *prototype-vs-engineering* worked examples** — Schoening (Notion practitioner altitude): the 3D-printed-enclosure-vs-optimise-the-factory-for-100M-users physical metaphor for *prototype velocity vs production-engineering discipline*. Ivers (SEI institutional altitude): the 25,000-line vibe-coding-experiment worked example — *'I produced an application soup-to-nuts, 25,000 lines of code in language I never written before. I got a very slick application but under the hood it was structured terribly. The architecture was bad. It wasn't very maintainable.'* Same observation: AI accelerates **prototyping** but the **engineering-discipline gap** between prototype-quality and production-quality grows under AI. Both warn against assuming the prototype output is engineering output. Practitioner-altitude (Schoening / Notion product team) + institutional-altitude (SEI / federally-funded SE research) converge on the same caveat.
  • Andrej Karpathy: From Vibe Coding to Agentic Engineering — **The vibe-coding-vs-engineering distinction operationalised at the institutional altitude.** Karpathy (29 April 2026): the founding pair *vibe coding* (floor-raising) + *agentic engineering* (production-quality bar). Sinclair (SEI, 21 May 2026): *'distinguish between vibe coding and software engineering'* is one of the three learning outcomes the SEI webcast names up-front. Ivers's 25,000-line vibe-coding experiment is the wiki's clearest **institutional-research-centre worked example** of where the floor-raising / engineering-discipline boundary lies — the prototype runs, but the architecture is bad, and the maintainability cost is deferred. The SEI take adds the *'we don't know what it's going to be to maintain this code in five years'* temporal-horizon caveat to Karpathy's original framing.
  • The Q/A Layer for the AI Coding Era — **The *underspecification* failure-mode anchored at the institutional altitude.** Wu (Momentic, 23 March 2026): *truth-driven / spec-driven development* — *'the spec is the source of truth. Your code is just an implementation of that source of truth'*. Ivers (SEI, 21 May 2026, on the *AI magnifies bad practices* audience question): *'the big one I would start with is under-specification. AI — I noticed this right away when I started using cursor. If I gave it a loose requirement, fine. It would just go generate code and it would fill in all the blanks. It would decide what corner cases worth handling, what weren't, what I really meant by that requirement. Terrible idea.'* Same observation: AI amplifies the cost of vague specs. Founder-vantage (Wu) + institutional-vantage (Ivers) converge on **the spec is more load-bearing in the AI era, not less.**
  • Stanford CS153 Frontier Systems | The AI Native Company: How One Founder Becomes a 1000x Engineer — **Productive complement on the *Coder vs Software Engineer* role-shift question.** Tan & Hu (CS153, 20 May 2026): the *AI founder type / IC / DRI* org structure prescription + the *1,000× engineer* unconditional framing. Ivers (SEI, 21 May 2026, the next day, on the *will AI replace developers* audience question): the coder-vs-software-engineer distinction — *'a coder is someone who just grabs a Jira ticket, implements a feature, checks it in. Software engineers go beyond that. We think about the overall design, how our code fits with the design. The narrow interpretation of coding might be fading. But those people who can bring engineering judgment, point AI in the right direction, connect it to the business, connect it to the users, that's an incredibly valuable skill that's never resided solely in a programming language.'* The SEI framing **complements rather than contradicts** the YC framing — Tan & Hu describe what *engineering judgement plus AI* enables; Ivers describes which *human skills survive* the AI-coding-era productivity inversion. Both anchor on engineering judgement / business connection as the load-bearing surviving skill.
  • Trading signals that trade themselves — **Same-day paired enterprise/institutional-altitude anchors on AI-coding governance** — both published 21 May 2026. Fernando / Man Group (enterprise empirical anchor): skills governance + 100+ governed skills + the expense-report failure-mode story as the *what goes wrong without governance* worked example. Sinclair/Ivers/Benitez (SEI institutional anchor): *'we don't let go of the safeguards that we have now just because there's more code. We might scale it differently'* (Ivers on the security question) + the SBOM / supply-chain-management discipline + *slop-squatting* as a new attack vector (AI-generated package names that don't exist, which adversaries can squat). Both anchor the **same discipline-retention claim at different altitudes** — enterprise-customer-implementing-skills-governance (Fernando) + institutional-research-centre-articulating-the-discipline (SEI).

Graph View

Backlinks