What Maritime Tragedies Can Teach Software Engineers About Ownership in the Age of AI

Working is not the same as understood, and cheap is not the same as low total cost

There is a familiar kind of cheap boat listing that looks almost reasonable at first glance. The hull floats, the engine may even be new, the cabin has cushions, the windows still exist, and the photographs do not immediately scream disaster. The price feels low enough to invite imagination. A few weekends of work, a little sanding, some rebedding, maybe a few fittings replaced, and suddenly the buyer starts seeing a future instead of a project.

Then the inspection brain wakes up and ruins the dream, as it was apparently designed to do.

A stained bulkhead is not just a stained bulkhead if it participates in the load path. A damaged window is not just cosmetic if it must hold against green water after a knockdown. A chainplate that looks acceptable in protected water may deserve suspicion offshore. The boat may cross the Sound without complaint and still be the wrong vessel for the North Sea, the Pacific, or any place where the weather stops being polite.

That distinction matters because a boat that floats is not necessarily a seaworthy boat. Floating is the minimum. The expensive question is whether the boat can preserve its structure when reality loads it from the wrong direction.

The same distinction applies to AI-generated production code.

A generated system can compile, run, demo, and pass ordinary checks while still carrying structural uncertainty. It can look complete because the visible shape exists. The form renders. The button clicks. The API responds. The test suite is green. The first user journey works. Yet the load path may still be unknown. The fatigue may be hidden. The prior repair may have been made without understanding the structure it touched.

That is the cheap boat problem in software. The artifact looks close enough to invite optimism, but the remaining uncertainty is not evenly distributed. It clusters around the places where failure is most expensive.

Four photographs, four kinds of suspicion

Take four ordinary interior photographs from a used sailboat listing. They are not a survey, and they cannot prove the condition of the boat. They are enough, however, to show how quickly a cheap-looking project becomes an inspection problem.

Image one shows a bulkhead area with visible staining or discoloration. If the boat has a separate compression post that carries mast load, the damage may be partly cosmetic. If that bulkhead participates in mast support, chainplate load, or structural stiffness, the same stain becomes a reason for deeper inspection. Moisture does not merely make wood ugly. It can weaken a panel, hide delamination, soften fasteners, and obscure the path that rig loads take into the hull.

Image two shows cabinetry and liner surfaces that appear aged, with interior trim and ventilation details that may be harmless or may suggest broader deferred maintenance. On older boats, a single suspicious area rarely lives alone. Water travels, owners patch, trim hides fasteners, and visible damage often marks only the place where the problem became photographable.

Image three shows a portlight or window area that appears damaged or poorly finished. A buyer may call this cosmetic because the boat still floats and the window still exists. The actual job may involve removing trim, rebedding the portlight, checking the surrounding core or plywood, sanding, refinishing, and proving that the opening will hold under load, spray, vibration, and movement. Offshore, a window is not decoration. It is part of the boundary between a cabin and the sea.

Image four shows deck or bulkhead hardware near a fire extinguisher and an interior fitting, with fasteners and surrounding surfaces that invite questions. A small detail near a chainplate, deck penetration, or structural attachment can represent a much larger uncertainty. If water has traveled down a fastener, the visible stain may be the end of a longer story. The point is not that this specific photograph proves structural failure. The point is that the cheap boat has now purchased an inspection obligation.

That is how the economics change. The buyer does not merely buy a boat. The buyer buys uncertainty, and uncertainty has a labor cost.

The inspection trap

A cheap boat often appears cheap because the visible remaining work looks manageable. Sand the trim. Rebed the window. Replace the cushion. Clean the bilge. Tighten the hardware. If the boat only needs visible work, the project may be rational.

The problem begins when visible work is connected to invisible structure.

A bulkhead stain may require a moisture meter, probing, fastener inspection, and understanding of the rig load path. A suspect window may require removal, core inspection, rebedding, and a leak test. A chainplate area may require disassembly, dye penetrant testing, replacement hardware, backing plate inspection, and careful assessment of surrounding wood or laminate. A keel concern may require hauling, survey, torque checks, laminate inspection, and examination of the internal grid or matrix.

Inspection is not free. Scaffolding is not free. Access is not free. Specialist judgment is not free. Every new suspicion turns the apparent bargain into a project management problem.

At some point, the buyer must ask a brutal question. Would it have been cheaper to buy a smaller, better-maintained boat at market price instead of buying a larger, cheaper boat with hidden structural doubt?

Software teams eventually face the same question. Would it be better to manually ship a smaller SaaS product, a smaller app, fewer features, less magic, less uncertainty, and a more conservative architecture? Would a narrower system with clearer ownership be safer, cheaper, and more valuable than a larger AI-generated system whose hidden structural doubt now requires ongoing inspection?

That question is not romantic. It is often correct.

The vibe-coded boat

AI-assisted coding can produce the software equivalent of a cheap boat that floats. The shape appears quickly. A working interface emerges. A refactor touches ten years of cruft. A new service compiles. A browser extension loads. A CRUD app works through the happy path. Management sees the artifact and assumes the expensive part has been compressed.

That assumption is dangerous because the generated code may have preserved surface behavior while weakening invisible structure.

The hidden risk is not always a bug. A bug is often too visible to be the worst problem. A bug crashes, throws, leaks, or fails a test. The more dangerous failure is a weakened invariant that still passes ordinary checks. A session boundary becomes less coherent. A retry path becomes less safe. A permission rule gets duplicated in three places. A privacy guard disappears during a rewrite. A migration preserves the visible schema while changing the meaning of an old field.

That kind of failure resembles a keel bolt that still looks attached from the cabin sole. It may hold during normal use. It may even hold for years. Then the system is loaded from a direction nobody tested, and the prior damage becomes the event.

This is why the phrase “works on my box” is not merely a joke. In production systems, it is an admission that the test environment is not the sea.

The expensive one percent

The last one percent of engineering is not one percent of the typing. It is the part where the system must preserve meaning under adverse conditions.

A boat that is ninety-nine percent ready may still be unfit for offshore passage if the remaining one percent includes keel attachment, chainplates, through-hulls, steering, rigging, watertight integrity, or structural bulkheads. Those are not decorative details. They are load-bearing boundaries.

Software has similar boundaries. Authentication, sessions, payments, authorization, audit trails, migrations, retry semantics, data deletion, privacy controls, accessibility compliance, and incident recovery are not ordinary features. They are the places where a system becomes accountable.

AI is often strong at producing the first visible ninety percent. It can scaffold, translate, draft, convert, summarize, refactor, and fill boilerplate with impressive speed. The remaining verification burden is different. It requires knowing which constraints matter, where those constraints live, and how they fail under stress.

That is why the economics can invert. If AI reduces production cost by ninety percent but increases inspection, verification, and repair work by several hundred percent, the project may become more expensive while still looking faster in the early screenshots.

The cheap boat did not become expensive because sanding costs too much. It became expensive because nobody can safely price the hidden damage without inspection.

Load paths and ownership paths

A boat has load paths. The mast compresses downward. The rig pulls sideways. The chainplates transfer force into the hull. The keel resists overturning forces. Bulkheads, tabbing, frames, floors, bolts, backing plates, and laminates distribute stress. A cosmetic repair that ignores those paths may make the boat look better while preserving the danger.

Software has ownership paths. A session concern belongs somewhere. A permission decision belongs somewhere. A payment invariant belongs somewhere. A privacy guarantee belongs somewhere. A retry rule belongs somewhere. When those responsibilities are spread across local patches, the system may work while becoming harder to reason about.

Good architecture reduces the number of places where a concern can hide. It centralizes responsibility, limits degrees of freedom, and turns invisible assumptions into explicit boundaries. That is why the architectural insight is often more valuable than the code itself.

The bottleneck is not typing the session manager. The bottleneck is seeing that session semantics must be centralized behind one boundary. Once that is understood, the implementation may be straightforward. Without that insight, an AI agent can spend many iterations patching local symptoms while increasing the number of places future failures can breed.

Local patches can look productive. Consolidation looks slower because it requires stopping, naming the invariant, and reducing the system. That reduction is often the work.

Why adding more inspection does not always rescue the bargain

A common answer to AI risk is to add more review, more tests, more agents, more scanners, more policies, and more evaluation loops. That answer sounds reasonable because inspection is necessary. It becomes less convincing when inspection is treated as free.

Boat buyers understand this quickly. A suspicious boat can be surveyed. A survey can lead to moisture testing. Moisture testing can lead to disassembly. Disassembly can lead to repairs. Repairs can reveal previous repairs. Every step improves knowledge, but every step also spends money.

Software teams face the same inspection trap. A large AI-generated refactor can be reviewed. The review can lead to tests. The tests can lead to property checks. The property checks can lead to a custom harness. The harness can reveal that the team never had a formal model of the behavior it was trying to preserve. At that point, the harness becomes the real engineering product.

If a team has the budget to specify, verify, migrate, canary, observe, and audit a high-risk AI-generated rewrite, it may also have the budget to perform the refactor sequentially with experienced engineers. The AI may still help with repetitive work, but it has not removed the central cost. It has moved the cost into proof.

That move can still be rational when the verification surface is cheap. It becomes dangerous when the verification surface is semantic, cross-system, and expensive.

Ambition defines acceptable risk

The answer depends on ambition. A boat intended for a small man-made freshwater lake does not need the same inspection standard as a boat intended to cross the Pacific. A boat that daysails on protected water does not carry the same duty as a vessel crossing the Bering Sea. A private owner accepting personal risk is not in the same category as a commercial operator charging passengers.

The decision is a function of mission, exposure, passengers, weather, legal duty, and consequence of failure. A cheap project boat may be perfectly rational for experimentation, local cruising, or rehabilitation as a hobby. The same boat may be reckless if advertised as offshore-ready passenger transport. The hull did not change. The mission changed.

Software should be judged the same way. A personal app hosted on an AI app builder may be acceptable if the blast radius is personal. If the app breaks, the owner suffers the inconvenience. If the data leaks, the owner likely absorbs the consequence. If the project never evolves beyond a private workflow, then a higher level of uncertainty may be tolerable.

A paid SaaS product is different. A public platform is different. A system handling customer data, payments, healthcare records, financial workflows, identity, children, regulated activity, or critical infrastructure belongs in another category entirely. If the ambition is to build the next Walmart, Amazon, Stripe, or public infrastructure layer, the tolerance for uncertainty changes. That category was always expensive because reducing the last fraction of risk is expensive.

The last 0.001 percent matters because large systems multiply small errors. A slightly different shade of green may affect a tiny fraction of conversion, but a tiny fraction of a billion-dollar revenue stream is still meaningful money. A missing ARIA label may look minor on a personal site, but it can become accessibility exposure at scale. A weak privacy boundary may be tolerable in a toy, but it becomes legal, financial, and reputational risk in a public product.

At scale, software must satisfy multiple constraints, multiple stakeholders, multiple regulators, and sometimes multiple legal regimes. That is a vast amount of context. Large language models can help surface overlooked possibilities, but they do not carry the responsibility for the decision. They are not on the boat with the crew. They do not lose the job when the outage happens. They do not have a mortgage. They do not have dependents. They do not face the customer, the regulator, the investor, or the incident review.

This is why aggressive layoffs at large companies are troubling. A large company cutting experienced engineers while mandating more AI-generated work resembles a cruise ship deciding to sail with fewer engineers, fewer mechanics, and fewer medical crew because those people look expensive on the operating ledger. The ship may still leave the dock. It may even complete ordinary voyages. The question is what happens when something goes wrong outside the happy path.

A smaller crew can be rational on a smaller boat with a smaller mission. It becomes reckless when the vessel, passengers, route, and consequence of failure all grow. That is the distinction many AI mandates appear to flatten. They treat local productivity gains from bounded tasks as evidence that the organization can reduce the people responsible for hidden structure.

The better question is not whether AI can help build software. It can. The better question is whether the chosen mission can tolerate AI-shaped uncertainty without proportionally increasing inspection, ownership, and accountability.

Cheeki Rafiki and hidden structural history

The loss of Cheeki Rafiki is a severe maritime example of hidden structural history becoming fatal. The yacht capsized and inverted after its keel detached in the North Atlantic. The official investigation concluded that previous groundings and later repairs may have weakened the keel attachment structure, and that deteriorated keel bolts may also have contributed. The important lesson is not that every damaged boat is doomed. The lesson is that prior damage, hidden load paths, and offshore conditions can combine in ways that normal use does not reveal.

A boat can sail, race, motor, and appear serviceable before a hidden structural weakness becomes catastrophic under worsening conditions. Protected water does not prove offshore readiness. Prior use does not prove future margin. A hull that floats does not prove the keel will remain attached under transverse loading in bad seas.

Software teams should resist cheap analogies that turn tragedy into decoration. The sober parallel is about hidden history and load-bearing uncertainty. In software, hidden history lives in old decisions, undocumented production incidents, patched behavior, compatibility obligations, abandoned assumptions, and scar tissue known only to people who have been there long enough to remember why the weird branch exists.

When AI-generated code modifies those systems without preserving that history, it can reduce visible cruft while also removing the ugly structures that carried real load.

OceanGate and systems that remember stress

Cheeki Rafiki shows how hidden structural history can become fatal when a vessel meets the wrong loading condition. OceanGate's Titan adds another lesson that software teams should study without turning the tragedy into a slogan. Titan's carbon fiber pressure hull did not fail on its first outing. It made dives. It returned from dives. It produced operational history that could be mistaken for confidence.

That history is exactly the failure mode. A structure can pass earlier use and still accumulate damage. Carbon fiber composites do not behave like simple metal pressure vessels, and repeated pressure cycles can create internal damage that is not obvious from successful prior operation. The NTSB later reported that Titan likely sustained delamination damage after surfacing from dive 80, and that it still completed later dives to Titanic depth before the final implosion. That fact should make every engineer uncomfortable in a productive way.

The prior dives also explain why confidence can grow inside a failing system. Dozens of successful dives on an innovative pressure hull are not nothing, especially when the design appears cheaper, lighter, and more entrepreneurial than conventional alternatives. Success creates evidence, but it can also create complacency. The same operational history that reassures a team can hide the fact that the structure has changed underneath them.

OceanGate also offers a human lesson, not merely a materials lesson. The Coast Guard report criticized the company's safety culture, and David Lochridge, who raised concerns about Titan's safety, was fired after documenting those concerns. Other industry experts warned Stockton Rush that the approach risked serious consequences. In organizational terms, the naysayers were not useless friction. They were part of the inspection system.

If Titan were software, it would have looked like a system with green tests, successful deployments, and reassuring prior runs. The previous dives were real data, but they were not proof of indefinite safety. The hull had memory. Stress changed the structure. The system after dive 80 was not the same system that began dive 80, even if it looked similar enough to proceed.

Software has memory too. It develops fatigue through requirement changes, partial migrations, slowly changing dimensions, framework upgrades, emergency patches, abandoned feature flags, race conditions, duplicated logic, and competing sources of truth. Two teams can carry different parts of the same responsibility without anyone noticing until an incident forces the hidden coupling into view. None of this requires AI. Human organizations already create structural fatigue with impressive consistency, because apparently entropy needed middle management.

AI can make the fatigue problem harder to price. A model can refactor quickly, generate plausible tests, and produce a coherent-looking replacement before the team has reconstructed the old load path. It can remove cruft that was merely ugly, but it can also remove cruft that carried history. It can simplify code that looked redundant because the model did not understand the incident, customer, browser, regulator, migration, or outage that made the redundancy necessary.

This is where the Titan lesson becomes relevant to agentic software development. The question is not whether the system worked yesterday. The question is what stress yesterday placed into the structure. The question is whether the current team understands that history well enough to change the system safely today.

A successful dive is not the same as a verified pressure vessel. A green test suite is not the same as a verified production system. A working deployment is not the same as an understood load path. When margins get thinner, missions get more ambitious, and inspection capacity gets cut, prior success can become a dangerous form of evidence. It tells the team that the vessel once survived. It does not prove what the vessel has become.

That is the grounding software needs. AI should not be used to accelerate changes faster than the organization can understand the fatigue it already carries. If the inspectors have been reduced, the mission has expanded, and the system is being pushed into deeper water, faster generation is not automatically progress. It may be a way of arriving at the failure condition sooner.

Mandated AI and engineered failure

Mandated AI use can set engineers up to fail when it treats generated output as inherently closer to done. Engineers may be asked to captain compromised systems with invisible scars while being told to move faster than before. They inherit code they did not write, constraints the model did not preserve, and verification burdens that management did not price.

The stakes are usually not physical life and death, but the economic risk is not imaginary. A critical infrastructure outage can damage public trust. A payment bug can create financial loss. A privacy failure can create legal exposure. A security issue can become an incident. A paid SaaS product can lose customers. An engineer can lose a job when they are made responsible for a system they were not given enough time to understand.

That is why mandated AI can backfire. It creates speed pressure while increasing the need for inspection. It can reduce the visible cost of coding while increasing the hidden cost of ownership. It can make leaders think they got a smoking deal when they actually bought a larger inspection problem.

The problem is not AI adoption. The problem is AI adoption without inspection economics.

The boat that sank may be safer

A boat that sinks at the dock tells the truth immediately. A boat that floats with hidden structural damage can be more dangerous because it invites confidence before the load path has been proven.

A program that fails to compile tells the truth immediately. A system that compiles, demos, and passes shallow tests while carrying weakened invariants is more dangerous because it invites deployment.

Bugs are not always the thing that kills the system. A bug can be seen, reproduced, fixed, and tested. The deeper risk is the microfracture under the skin, the internally damaged bolt, the degraded tabbing, the softened bulkhead, the session boundary that looks intact but is no longer singular, the retry path that appears reliable until a partial failure arrives after commit but before acknowledgment.

Production software fails when hidden structural weakness meets adverse conditions. That is why the expensive part is not merely getting code to run. The expensive part is understanding what the code must continue to mean when conditions change.

What wide-eyed AI adoption should look like

Wide-eyed AI adoption does not mean rejection. AI is useful, and in some engineering tasks it is extraordinary. It writes UFW rules, bash helpers, scaffolds, summaries, boilerplate, and straightforward CRUD flows with enough speed to justify its place. It compresses search, syntax, and shape. It is especially valuable when verification is cheap and feedback is immediate.

Start with the mission

The first question should be about the voyage. A lake boat, a coastal cruiser, an offshore passage boat, and a commercial passenger vessel do not share the same acceptable risk profile. Software has the same distinction. A personal tool, an internal dashboard, a paid SaaS product, a regulated workflow, and public infrastructure do not deserve the same tolerance for uncertainty.

AI adoption should begin by naming the mission, the blast radius, the users, the regulatory surface, and the consequence of failure. A team cannot responsibly decide how much AI-generated uncertainty to accept until it knows what kind of water the system must cross.

Use AI where verification is cheap

Use AI to explore, draft, list, translate, scaffold, summarize, and generate candidate implementations. Use it where dropped constraints are cheap to detect and cheap to repair. Use it when the output can be checked through a compiler, a shell command, a narrow test, a visible UI, or a reversible workflow.

This is the domain where AI provides honest leverage. It shortens the path from question to candidate answer. It reduces the cost of trying ideas. It turns many formerly annoying tasks into fast, inspectable drafts.

Do not delegate load-bearing semantics

Do not use AI as the owner of load-bearing semantics. Do not let it independently rewrite auth, payments, session models, permission systems, privacy boundaries, critical migrations, or distributed state unless the invariants are explicit, testable, and enforced by independent mechanisms. Do not treat a passing demo as proof of seaworthiness.

The stronger the consequence of failure, the more the system needs human understanding before AI-generated code is accepted. The model can propose a plank. It cannot certify the hull.

Write the load path before generating code

A practical AI coding workflow should begin with constraints rather than code. The team should write down what must never happen. It should define ownership boundaries. It should identify the load-bearing paths through the system before asking AI to generate or modify them.

In a boat, this means understanding where mast compression, rig tension, keel loads, and hull stresses travel. In software, this means understanding where identity, authorization, payment state, privacy guarantees, and recovery obligations travel. The generated code should serve that map rather than replace it.

Turn understanding into guardrails

Once the team understands the boundary, it should make that understanding harder to violate. Regression tests should protect accepted behavior. Static guards should prevent forbidden imports or direct access. Runtime assertions should catch impossible states. Canaries, logs, and rollback paths should exist before high-risk changes reach ordinary users.

These mechanisms do not replace understanding. They preserve and distribute it. They make the system more legible to the next engineer who must carry responsibility for it.

Price inspection honestly

AI can make the first artifact appear cheap, but inspection remains part of the purchase price. If the team must add reviewers, test harnesses, security audits, migration checks, observability, and incident playbooks to make an AI-generated change safe, those costs belong in the AI ledger. They are not separate overhead. They are the cost of turning generated output into owned software.

A cheap boat is only a deal when the buyer can afford the survey, the repair, the haul-out, and the responsibility. AI-generated code is only a deal when the organization can afford the inspection, the verification, the ownership, and the future maintenance.

Keep responsibility embodied

The final decision must remain with people who understand the system well enough to answer for it. AI can help inspect a concern, draft a patch, or surface a risk. It cannot be the party that owes the duty of care. It cannot be the person who explains the incident to customers, regulators, passengers, or families.

That is why responsible AI adoption should increase understanding rather than obscure it. When AI clarifies the load path, it can strengthen engineering. When AI hides uncertainty behind a fast-looking artifact, it turns responsibility into theater.

Conclusion

The cheap boat is not always a bad buy. Some people enjoy rehabilitation, and some owners have the skills, tools, time, and tolerance for hidden work. Some projects become beautiful because someone was willing to take on uncertainty that the market discounted.

The same is true for AI-generated code. Some generated artifacts are useful, some prototypes become products, and some accelerations are real. AI can make the first shape cheap enough to attempt, and that can create real opportunity when the mission is small, the blast radius is bounded, and the owner understands what kind of water the system must cross.

The mistake is not buying the project. The mistake is pretending the project is already seaworthy.

Cheeki Rafiki shows how hidden structural history can become fatal when prior damage meets offshore load. Titan shows how prior success can breed confidence while a structure accumulates fatigue. In both cases, the lesson is not that innovation is forbidden or that every unconventional vessel must fail. The lesson is that a working vessel is not the same as an understood vessel, and successful prior operation is not the same as preserved margin.

This is the part software teams must take seriously. A green test suite, a successful deployment, or a convincing AI-generated refactor can create the same kind of confidence. The system worked yesterday, so the next change feels safer than it is. The app passed the tests, so the structural uncertainty feels resolved. The model produced a cleaner-looking architecture, so the old ugliness begins to look unnecessary.

That confidence can become complacency when dissent is treated as obstruction. OceanGate's failure was not only a story about carbon fiber under pressure. It was also a story about warnings, inspection, oversight, and people who tried to say that the margin was not there. Engineers, scientists, inspectors, and experienced operators are often poor teachers compared with experience and time, except that experience sometimes charges tuition in lives.

Software usually does not charge that price directly, but the responsibility remains real. A failed payment system, a privacy breach, a medical workflow error, a broken identity boundary, or a public infrastructure outage can harm people who never consented to participate in the experiment. That is why responsibility cannot be laundered through a model, a mandate, or a fast-looking artifact.

Writing code that works is not the finish line. In many systems, it is closer to proving the boat floats at the dock. The real question is whether the structure still holds when the load path changes, the weather turns, the mission expands, and nobody has time to rediscover why the old ugly repair was there.

AI-assisted engineering should be embraced with open eyes. Use it where it promotes understanding, reduces search cost, exposes risks, and helps teams express the rules they already own. Be wary when it obscures understanding, hides uncertainty, creates more surface area, or lets leaders think they got a smoking deal while assigning the inspection bill to the remaining engineers.

The minimum standard is not whether the artifact works. The minimum standard is whether someone understands it well enough to own it. That is where engineering begins.

References

National Transportation Safety Board. “Hull Failure and Implosion of Submersible Titan.” Marine Investigation Report MIR-25-36, October 2, 2025.

United States Coast Guard Marine Board of Investigation. “Implosion of the Submersible TITAN.” Marine Board of Investigation Report, August 2025.

Associated Press. “NTSB engineer says carbon fiber hull from Titan submersible showed signs of flaws.” September 25, 2024.

Marine Accident Investigation Branch. “Keel detachment and capsize of sailing yacht Cheeki Rafiki with loss of 4 lives.” GOV.UK, Accident Investigation Report 8/2015.

Marine Accident Investigation Branch. “MAIB investigation report 8-2015: Cheeki Rafiki.” GOV.UK PDF report, 2015.

Marine Accident Investigation Branch. “Cheeki Rafiki Safety Flyer.” GOV.UK PDF flyer, 2015.

Google Cloud DORA. “Accelerate State of DevOps Report 2024.” DORA Research Program.

Google Cloud Blog. “Highlights from the 10th DORA report.” October 22, 2024.

METR. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” July 2025.

Becker, Joel, Nate Rush, Elizabeth Barnes, and David Rein. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” arXiv, 2025.

Perry, Neil, Megha Srivastava, Deepak Kumar, and Dan Boneh. “Do Users Write More Insecure Code with AI Assistants?” arXiv, 2022.

National Institute of Standards and Technology. “Secure Software Development Framework.” NIST Special Publication 800-218.

Gartner. “Gartner Says Autonomous Business and Artificial Intelligence Layoffs May Create Budget Room, but Do Not Deliver Returns.” Press release, May 5, 2026.