AI Code Generated Software Development: Who Makes the Final Call?

When AI Writes 80% of the Code, What Does the Engineer Do?

AI Context: Why One Boolean Wasn&#8217;t Enough

Elasticity: Can AI Make Uruguay More Competitive?

What happens when AI code generated software can build a feature across your backend, frontend, payments, tests, and integrations?



You might expect a simple answer: the team ships faster.



But the more interesting question is what happens to engineering work when implementation becomes much easier.



A recent feature gives us a useful example. It was a prepaid gift system built into a Rails API. A customer could pay through Stripe, receive a unique gift code, and send it to someone else. The recipient could redeem it for premium access or queue the gift until their existing access expired.



The feature also included scheduled emails, PDF gift cards, admin tooling, mobile and web interfaces, analytics, CRM synchronization, and integration with an external entitlement service.



It was not a small feature. And AI code generated agents were fully involved heavily in building it.



<h2 class="wp-block-heading">The stack was doing a lot of work</h2>



The backend was built with Ruby on Rails 7.2, PostgreSQL, Stripe, Sidekiq, Prawn, Pundit and RSpec.



The system also integrated with RevenueCat for entitlements and Mailchimp for contact and subscription synchronization. On the development side, the team used Claude Code with repository-specific instructions and skills, Figma and Notion MCP integrations, and GitHub Copilot review feedback.



That combination matters.



A payment webhook is not just an API endpoint. It can create a record, trigger asynchronous work, generate a PDF, send an email, update analytics, and eventually grant access through another system.



The interesting engineering problems therefore live between technologies.



Stripe has its own lifecycle. Rails has its transaction and locking model. PostgreSQL has its constraints. Sidekiq has its job semantics. RevenueCat has its entitlement model. The mobile app has its own expectations for what a successful response looks like.



AI can work with each of these pieces.



The hard part is deciding how they should behave together.



<h2 class="wp-block-heading">The AI code generated could build the first version</h2>



The available evidence shows substantial AI code generated implementation.



One engineer authored 9 of the feature&#8217;s 20 PRs and 32 of its 76 gift-related commits. For that portion, the transcripts consistently show AI drafting code and tests.



That gives us evidence that at least roughly 40% of the work units were AI-drafted, while the total AI contribution across the entire feature remains unknown because the other engineer&#8217;s AI sessions weren&#8217;t available.



And the AI was not just autocomplete.



It generated backend services and controllers, redemption flows, entitlement logic, validation endpoints, admin interfaces, mobile screens, and tests.



It also investigated documentation, reviewed code, produced backend-to-frontend contracts, and explored alternative implementations.



So what did the engineers actually do?



A lot of deciding.



<h2 class="wp-block-heading">Payment is a good example</h2>



The AI initially designed the gift to exist before payment was confirmed. The engineer rejected it. Instead, the final implementation passed the gift information through Stripe metadata and created the gift only after payment was confirmed.



That sounds like a relatively small implementation detail. It isn’t. It changes the system’s definition of reality. A gift shouldn’t exist as a valid purchased gift just because someone started checkout. It should exist because payment happened.



The AI could implement either model. The engineer had to decide which model the business could trust.



<h2 class="wp-block-heading">Then came idempotency</h2>



Payment systems have another uncomfortable property: events can happen more than once. The implementation used PostgreSQL partial unique indexes and application-level handling to make payment fulfillment idempotent. Redemption also introduced locking, while read-only validation was deliberately kept lock-free.



These decisions look very technical but ultimately reflect system behavior under failure. The AI proposed refactors around locking, and the engineer rejected some of them. In one case, the engineer explicitly changed the approach to lock once at the appropriate point instead of checking repeatedly. For queued gifts, the engineer also decided that redemption should return already_redeemed rather than letting the frontend interpret the situation as a successful redemption.



The code was being generated quickly. Humans were still negotiating the semantics.



<h2 class="wp-block-heading">AI can find bugs too</h2>



This wasn&#8217;t a story about humans constantly correcting an incompetent machine.



The interaction went both ways.



AI identified a problem with premium-access gating and suggested using has_premium_access?.



It identified a race condition in the redemption flow.



It questioned assumptions around gift validity.



It also caught problems in the engineer&#8217;s merge resolution.



At the same time, the AI produced incorrect or misleading findings.



It incorrectly questioned whether scheduled workers were actually scheduled. It misunderstood a webhook issue before the engineer pushed it for further investigation. During an edit, it generated a delivered gift code again, which the engineer caught.



There were also cases where repository rules were applied literally, even though they didn&#8217;t reflect how the application actually worked.



That is a much more interesting model of AI code-generated development than “AI writes code, human reviews it.”



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="213" src="https://blog.effectussoftware.com/wp-content/uploads/2026/10/AI-can-find-bugs-too-1024x213.png" alt="AI proposes → human challenges → AI investigates → human decides → AI implements → human tests reality." class="wp-image-4924" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/10/AI-can-find-bugs-too-1024x213.png 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/AI-can-find-bugs-too-300x62.png 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/AI-can-find-bugs-too-764x159.png 764w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/AI-can-find-bugs-too-1536x320.png 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/AI-can-find-bugs-too.png 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



<h2 class="wp-block-heading">The device changed the architecture</h2>



One of the clearest examples came from the mobile experience.



The AI initially reasoned that full navigation screens made sense for the redemption flow. The engineer challenged that and moved toward modals.



Then the actual device provided new information.



Nested modals caused a freeze.



The architecture changed again, this time based on observed device behavior rather than reasoning inside the coding environment. The team moved back toward screens and redesigned part of the flow.



This is an important boundary for AI code generated development.



The model can reason about a mobile interface.



It cannot substitute for the device.



The engineer supplied evidence that existed only outside the code-generation loop: screenshots, production errors, device behavior, design details, and knowledge of how the existing product actually works.



<h2 class="wp-block-heading">The AI also wanted to build more</h2>



Another recurring pattern was over-engineering. The AI proposed additional services, abstractions, and refactors. Some were useful. Others were rejected or reverted because they did not fit the existing architecture. The engineer repeatedly cut unnecessary componentization and refactoring in the admin UI to keep it consistent with the existing promo-code screens.



A technically elegant abstraction is not automatically a good product decision. Sometimes the best architectural decision is to not introduce another abstraction. That is particularly relevant when AI makes implementation cheap. When writing another service class costs almost nothing, the constraint is no longer the cost of writing it. The constraint becomes whether the system should have one.



<h2 class="wp-block-heading">The API contract was also a human decision</h2>



The unified promo and gift-code validator is another good example.



The AI proposed a unified endpoint.



The engineers then made the important product and API decisions around it.



The endpoint returns a consistent 200 response containing validity, type, and machine-readable reason codes. Gift redemption requires authentication, while shared validation does not. The reason codes were designed as codes rather than English messages so the frontend could support internationalization later.



Those decisions are easy to underestimate.



A developer can ask an <a href="https://www.reddit.com/r/ExperiencedDevs/comments/1tvofrw/ai_has_becoming_so_good_that_its_better_than_most/" target="_blank" rel="noopener">AI</a>:



“Build a validation endpoint.”



The harder question is:



“What exactly should the frontend be allowed to assume when this endpoint responds?”



That question belongs to the system, not to the endpoint.



<h2 class="wp-block-heading">Fourteen days, twenty PRs, and a lot of decisions</h2>



The <a href="https://www.effectussoftware.com/case-studies">feature</a> took about 14 working days, or 18 calendar days.



Around 20 PRs were involved, covering roughly 21 gift service classes, eight migrations, and approximately 248 test examples. The implementation was merged into the integration branch, although the available evidence does not show a production release.



The evidence supports at least ~42% of work units being AI-drafted, but it doesn&#8217;t provide a precise percentage for the entire feature.



The evidence clearly shows the nature of the interaction.



The AI generated substantial amounts of implementation.



Humans repeatedly changed the architecture, narrowed the scope, rejected approaches, supplied missing context, tested on real devices, and decided what the system should mean.



<h2 class="wp-block-heading">The new bottleneck may not be writing code</h2>



This is where AI code generated development gets interesting.



If generating another controller, service, test, component, or migration becomes dramatically cheaper, the scarce resource starts moving somewhere else.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="682" src="https://blog.effectussoftware.com/wp-content/uploads/2026/10/The-new-bottleneck-may-not-be-writing-code-1024x682.png" alt="The new bottleneck may not be writing code" class="wp-image-4921" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/10/The-new-bottleneck-may-not-be-writing-code-1024x682.png 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/The-new-bottleneck-may-not-be-writing-code-300x200.png 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/The-new-bottleneck-may-not-be-writing-code-1536x1023.png 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/The-new-bottleneck-may-not-be-writing-code-767x511.png 767w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/The-new-bottleneck-may-not-be-writing-code.png 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



They are questions of product knowledge, architecture, system behavior, risk, and context.



AI can participate in all of them. It can propose alternatives, find inconsistencies, challenge assumptions, and write the implementation.



But someone still has to decide which reality the software should implement.



And as implementation becomes increasingly elastic, that decision layer may become one of the most important engineering capabilities a team can develop.

AI code generation&#8230; should it be 100%? A PDF bug can look like a typography problem. Until you add another language. Then it becomes an architecture problem.



In this case, longer translated copy was being clipped because an existing PDF generator relied on fixed-height pages and rasterized the output. The immediate temptation might have been to adjust fonts, page heights, or spacing. Instead, the team replaced the rendering pipeline.



The new implementation moved from html2pdf.js to a declarative, typed model rendered with @react-pdf/renderer, with automatic pagination and vector output. It also introduced a shared core for three report types, an SVG-to-React-PDF code generator, and a runtime feature flag controlling the migration.



And there is another interesting number attached to this feature:



AI-assisted implementation: approximately 80%.



With an important caveat: that is a low-confidence estimate, based on the structure and scale of the implementation rather than direct keystroke or session evidence. It does not mean 80% of the code was generated by AI and accepted unchanged. The available evidence shows substantial human steering and rework.



So what does an engineer do when AI can produce most of the implementation? Quite a lot.



<h2 class="wp-block-heading">First, you have to know what problem you&#8217;re actually solving</h2>



The original problem was not “build a new PDF renderer.”



It was localized content being clipped.



That distinction matters.



The engineer identified that fixed-height raster pages were fundamentally poorly suited to variable-length translated content. The replacement therefore used automatic pagination and vector text rather than trying to make the old approach tolerate more languages.



That is the first decision in the entire feature.



And it happens before the AI has much to implement.



AI code generation can propose a new renderer.



It cannot discover from the code alone that the product should stop treating page height as a fixed constraint.



<h2 class="wp-block-heading">The new stack was a deliberate change in architecture</h2>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="213" src="https://blog.effectussoftware.com/wp-content/uploads/2026/10/When-AI-Writes-80-of-the-Code-What-Does-the-Engineer-Do_-1024x213.png" alt="The new stack was a deliberate change in architecture" class="wp-image-4927" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/10/When-AI-Writes-80-of-the-Code-What-Does-the-Engineer-Do_-1024x213.png 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/When-AI-Writes-80-of-the-Code-What-Does-the-Engineer-Do_-300x62.png 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/When-AI-Writes-80-of-the-Code-What-Does-the-Engineer-Do_-764x159.png 764w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/When-AI-Writes-80-of-the-Code-What-Does-the-Engineer-Do_-1536x320.png 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/When-AI-Writes-80-of-the-Code-What-Does-the-Engineer-Do_.png 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



@react-pdf/renderer became responsible for PDF layout and rendering. TypeScript defined the typed content models. i18next handled language-specific catalogs. SVGO processed SVG artwork before a custom generator converted it into React-PDF components. d3 supplied chart geometry, and Vitest covered the model builders, rendering behavior, and code-generation drift.



A patched dependency sits in the middle of it.



fontkit 2.0.4 had a glyph-cache problem that could affect line breaks when a second document was rendered in the same session. The team patched it in the repository and added a regression test.



That is a very modern frontend stack problem.



The application isn&#8217;t just “React.”



It is a chain of specialized libraries, each with its own assumptions about fonts, SVGs, layout, localization, rendering, and browser behavior.



The engineering challenge is making those assumptions agree.



<h2 class="wp-block-heading">AI code generation can build the vertical slice</h2>



The first implementation was substantial.



One commit introduced a complete vertical slice across the model, components, fonts, feature flag, and tests. The feature eventually involved roughly 263 files and around 18,000 added lines, although generated modules and SVG assets inflate those numbers.



<a href="https://www.reddit.com/r/ExperiencedDevs/comments/1tvofrw/ai_has_becoming_so_good_that_its_better_than_most/" target="_blank" rel="noopener">AI</a> code generation work was especially strong in code generation.



It produced report model builders, block renderers, the report-agnostic core, chart components, and the SVG code-generation tooling. The implementation added around 40 new PDF component files.



It also generated substantial testing.



Approximately 651 lines were added across six test files, covering model builders, rendering smoke tests, page numbering, inline markup parsing, and the SVG code-generation drift test.



That is where the 80% estimate becomes interesting.



AI code generation was not simply triggering isolated functions.



It was producing coherent chunks of architecture.



<h2 class="wp-block-heading">But the first implementation was not the final architecture</h2>



One of the better decisions came after the first report worked. The team did not design the perfect abstraction for all three reports upfront. They built Report A, then extracted the report-agnostic core, then let Reports B and C reuse it.



That sequencing matters. When AI code generation makes abstraction cheap, it is tempting to generalize everything immediately. But you can also use implementation to discover the abstraction. Build one real case, find what is genuinely shared, and extract it only then.



The result was a common page/section/block model with report-specific pieces sitting on top of a shared rendering core. 



<h2 class="wp-block-heading">Then the weird bugs arrive</h2>



The most interesting bugs were not necessarily the ones you would predict from the architecture diagram.



Rendering a second PDF in the same session caused line breaks to shift.



We traced the root cause to a glyph cache issue in fontkit, where cached glyph information didn&#8217;t carry the necessary code-point information. The team patched the dependency and added a regression test.



There were also issues around textkit hyphenation, Safari and Firefox blob URL timing, and SVG rendering constraints.



This is where AI code generation development becomes less like “generate code” and more like iterative engineering with a very fast implementation partner.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="213" src="https://blog.effectussoftware.com/wp-content/uploads/2026/10/Then-the-weird-bugs-arrive-1024x213.png" alt="Then the weird bugs arrive" class="wp-image-4934" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/10/Then-the-weird-bugs-arrive-1024x213.png 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Then-the-weird-bugs-arrive-300x62.png 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Then-the-weird-bugs-arrive-764x159.png 764w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Then-the-weird-bugs-arrive-1536x320.png 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Then-the-weird-bugs-arrive.png 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



The machine can participate in every step.



But the loop&#8217;s quality depends on someone recognizing which evidence matters.



<h2 class="wp-block-heading">One of the best decisions was to fix the data, not the translator</h2>



At one point, the <a href="https://www.effectussoftware.com/case-studies">implementation</a> considered normalizing whitespace in the translation layer.



The engineer redirected that approach.



Instead of teaching the translator to compensate for problematic content, the engineer removed hard line breaks from the translation catalogs themselves.



That fixed the underlying data instead of adding another piece of translation-specific logic.



This is exactly the kind of decision that can disappear when we talk about AI-assisted coding only in terms of productivity.



The AI code generation can produce the normalization function.



The harder question is whether the normalization function should exist.



<h2 class="wp-block-heading">“Looks good” was enough</h2>



There was another deliberate boundary. The new PDFs didn’t need to preserve the same page count as the legacy PDFs. They needed to look good.



That sounds obvious, but pixel-for-pixel parity can become a massive constraint when replacing a rendering engine. The team explicitly accepted different page counts rather than turning the migration into a search for perfect legacy reproduction. That is not a technical limitation. It is a product decision, and it removes an entire category of unnecessary engineering work.



<h2 class="wp-block-heading">The feature flag was not just deployment plumbing</h2>



The new renderer sat behind a runtime flag.



That flag mattered because the backend permanently stores the first uploaded PDF. If a new rendering path produces a bad document, simply switching the UI back doesn&#8217;t necessarily undo what&#8217;s already been stored.



The team therefore kept a kill switch and chose to fail closed rather than silently falling back to the old renderer when required inputs were missing.



Again, the implementation is straightforward.



The reasoning is not.



The system&#8217;s risk profile depends on what happens after the PDF is generated.



That information sits outside the rendering function itself.



<h2 class="wp-block-heading">The designer is part of the technical system too</h2>



The SVG pipeline introduced another constraint.



Artwork had to be exported in a format the PDF renderer could reliably handle, including outlined text and supported SVG structures. Unsupported features such as certain text, filters and masks were configured to fail rather than silently produce incorrect output.



A custom SVG-to-React-PDF generator was added, along with a drift test comparing generated output against the source SVG.



This is another good example of why “tech stack” is bigger than the package.json.



The stack includes the handoff between design tools and code, the format designers export, the assumptions the renderer makes about SVG, and the tests that ensure those assumptions don&#8217;t quietly drift.



<h2 class="wp-block-heading">So what does the engineer actually do?</h2>



The feature took about three calendar days.



The available evidence estimates roughly 80% AI code generation implementation, with a 70–90% range and low confidence. The team consisted of two engineers and one designer.



But the human contribution was not simply the remaining 20% of typing.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="776" src="https://blog.effectussoftware.com/wp-content/uploads/2026/10/Humans-decided-1024x776.png" alt="So what does the engineer actually do?" class="wp-image-4929" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/10/Humans-decided-1024x776.png 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Humans-decided-300x227.png 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Humans-decided-767x581.png 767w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Humans-decided-1536x1164.png 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Humans-decided.png 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



These decisions shaped what the AI was actually building.



<h2 class="wp-block-heading">The interesting number isn&#8217;t 80%</h2>



The 80% figure is useful. AI code generation shouldn&#8217;t reach higher levels. It tells us something about how much implementation capacity AI can provide to a small team.



But it doesn&#8217;t tell us how much engineering was automated.



A more interesting observation is that&nbsp;AI-assisted implementation and human engineering are not interchangeable. AI can generate a large amount of technically coherent work.



Humans still decide which problems are worth solving, which constraints matter, which risks are acceptable, what belongs in scope, what to generalize, and what to leave deliberately unfinished.



In this case, AI code generation replaced an entire PDF rendering pipeline in about three days. But the engineering work didn&#8217;t reduce to writing less code; it shifted toward directing more of it.



And perhaps that is the more important change AI code generation is bringing to software development.



When implementation becomes abundant, judgment becomes part of the architecture.

AI-assisted software development can help trace this: A boolean is rarely just a boolean once it crosses the stack. 



In one recent product feature, a document used to have a single isMainManual flag. That flag answered two completely different questions: should this document be used as context for the AI, and should the user be able to see it?



That worked while there was only one “main manual.” It became a problem as soon as products needed multiple documents with different purposes.



The solution was not simply adding more documents. It was separating two concepts that had been coupled together: useForAI and isVisibleToUser.



<h2 class="wp-block-heading">The product decision became a technical decision</h2>



Consider a product with three documents:



<ul class="wp-block-list">
<li>A public user manual</li>



<li>A warranty document</li>



<li>An internal troubleshooting guide</li>
</ul>



The <a href="https://www.reddit.com/r/ExperiencedDevs/comments/1tvofrw/ai_has_becoming_so_good_that_its_better_than_most/" target="_blank" rel="noopener">AI</a> might need the troubleshooting guide and the manual to answer questions accurately. But the end user may only need access to the manual and warranty.



The old model could not express that.



The new model can:



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="429" src="https://blog.effectussoftware.com/wp-content/uploads/2026/10/Why-Small-Experiments-Create-Bigger-Opportunities-1-1024x429.png" alt="The product decision became a technical decision" class="wp-image-4933" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/10/Why-Small-Experiments-Create-Bigger-Opportunities-1-1024x429.png 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Why-Small-Experiments-Create-Bigger-Opportunities-1-300x126.png 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Why-Small-Experiments-Create-Bigger-Opportunities-1-768x322.png 768w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Why-Small-Experiments-Create-Bigger-Opportunities-1-1536x644.png 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/10/Why-Small-Experiments-Create-Bigger-Opportunities-1.png 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



That distinction sounds obvious when written this way. But implementing it meant changing much more than a database column.



The backend schema had to change. Existing data had to be migrated. The API contract had to evolve. The code selecting documents for the LLM had to change. The frontend needed two controls instead of one. The public product page needed a different document-selection experience.



The system also had to remain compatible with existing clients throughout. So&#8230; AI-assisted software development, yes or no?



<h2 class="wp-block-heading">The tech stack tells the story</h2>



This is where the feature gets interesting from an engineering perspective.



The backend used Node.js, Express, Prisma, and PostgreSQL. Prisma handled the schema and migrations, including two hand-written SQL migrations for the transition.



The AI layer used the OpenAI Node SDK in Azure OpenAI mode, with pdf-parse extracting text from PDFs before assembling the selected documents into the LLM prompt.



On the frontend, the feature touched TypeScript, Next.js, React, TanStack Query, and Radix UI. The admin interface gained two document toggles, while the public product experience gained a document picker when multiple documents were visible.



That stack is worth looking at as a system, not a list of technologies.



A change to a boolean in PostgreSQL eventually changes what gets extracted from a PDF, what gets concatenated into an LLM prompt, what the API exposes, what React renders, and what a user can select.



That is the real cost of coupling concepts together.



<h2 class="wp-block-heading">Migration is where the old model meets reality</h2>



Changing the data model was not just a matter of renaming isMainManual.



The implementation used an expand-and-contract approach.



First, we added the new useForAI and isVisibleToUser fields. Existing isMainManual = true records were backfilled into useForAI = true. Only then did we remove the old column.



An important engineering principle is hiding here: changing the model and migrating the meaning of existing data are two different problems.



The new schema tells you what the system should look like.



The backfill tells you what the old system meant.



Those are not always the same question.



In this case, the migration preserved the old AI behavior for existing main manuals, while the new model established a more explicit relationship between documents and AI context. It was still AI-assisted software development.



<h2 class="wp-block-heading">The AI behavior changed too</h2>



The most interesting part of the change may actually be inside the AI layer.



Previously, if a product had no main manual, the AI could fall back to using all documents.



After the change, it includes only documents explicitly marked useForAI. If there are none, the prompt says:



“No manuals available.”



That is more than a refactor. It changes the AI system&#8217;s semantics.



It also creates a new consideration that becomes increasingly important as AI applications grow: context is part of the product architecture.



Which documents the model can access is not merely an implementation detail. It affects relevance, token consumption, response quality, and potentially what information reaches the model in the first place.



The implementation currently concatenates all AI-enabled documents into the prompt without a size cap, so adding more AI-enabled documents can also increase prompt size and token usage. Whether that trade-off was explicitly considered is not documented in the available evidence.



<h2 class="wp-block-heading">Then there is the API</h2>



The old isMainManual field was removed from the public response, but mainManual was retained as null so older clients would not crash.



That is a small compatibility decision with a very practical consequence.



A backend can evolve without forcing every consumer to upgrade at exactly the same moment.



The public document list was also filtered server-side using isVisibleToUser, rather than relying on the client to hide documents.



This is another example of how a seemingly simple product distinction becomes an architectural boundary: visibility is enforced where data leaves the system, not just where the UI renders it.



<h2 class="wp-block-heading">The frontend had to reflect the new mental model</h2>



The admin interface changed from updating a document immediately when a toggle was changed to queueing document changes and flushing them when the product was saved.



That introduced a different consistency trade-off: document updates are sent before the product update and are not wrapped in a single transaction. If the product save fails, those document changes can remain applied.



The model also changed for users.



If there is one visible document, it opens directly. If there are several, the interface presents a picker built against the design prototype.



The UI is therefore not simply exposing the database model. It is expressing the product decision that multiple documents can now coexist for different audiences.



<h2 class="wp-block-heading">Where AI fits in is actually unknown</h2>



This is an important part of the case.



There is no direct evidence that AI was used to implement this particular feature. The work happened in May 2026, while the available local AI session logs begin in September. No AI co-author trailers or feature-specific session records exist.



So assigning an AI-assisted software development percentage to this feature would mean inventing evidence that does not exist.



What is documented is human review. The backend and frontend PRs were each approved by another engineer.



That makes this case useful for a different reason.



It shows that the interesting question is not always “How much of the code did AI write?”



Sometimes the better question is:



“What decisions had to be made to make the code mean the right thing?”



<h2 class="wp-block-heading">The part AI cannot infer from the codebase</h2>



The repository can show us that two flags exist.



It cannot, by itself, tell us why a warranty document should be visible but excluded from AI context, or why an internal troubleshooting guide should work the other way around.



Those decisions depend on the actual content, the users, the product, and the consequences of exposing or withholding information.



The same applies to the migration.



The code can tell us that former main manuals became AI-enabled documents. It cannot tell us whether that was the right interpretation of every existing product.



The implementation also introduced an invariant requiring every product to have at least one AI document, but that invariant is enforced at the product level and can still be broken through certain individual document endpoints. That is not simply a coding detail. It is an architectural trade-off about where the system should enforce its rules.



<h2 class="wp-block-heading">The bigger engineering lesson</h2>



The feature took about one working day to author and three calendar days to merge both backend and frontend. The result removed the one-document limitation and separated AI context from user visibility.



But the interesting part is not the speed.



It is what the speed depended on.



A small change in product semantics propagated through PostgreSQL, Prisma, Express, the OpenAI SDK, PDF parsing, Next.js, React, TanStack Query, and Radix UI.



That is what modern software development increasingly looks like.



AI-assisted software development can help generate, refactor, explain, and connect pieces of that stack. But the hard part is often deciding what those pieces should mean together.



In this <a href="https://www.effectussoftware.com/case-studies">case</a>, the key architectural move was not adding AI.



It was deciding exactly what AI should be allowed to see. Not all about AI-assisted software development. Diving deep into AI-assisted software development.

<h2 class="wp-block-heading">How AI, public policy, and accumulated capabilities could change Uruguay&#8217;s position in the US software market</h2>



Uruguay&#8217;s software industry is strange.



The country has a population of around 3.5 million people, yet its technology sector generated US$3.681 billion in revenue in 2024. Around 63% of that revenue came from exports, with the United States as its main destination. Uruguay is now the second-largest software exporter per capita in Latin America.



That means Uruguay&#8217;s software advantage has never been about scale. It has been about productive capacity.



The interesting question now is whether artificial intelligence can increase that capacity without requiring Uruguay to grow its software developer population at the same rate. If it can, AI could do something particularly important for a small economy:



increase the amount of economic value it can produce with the capabilities it already has.



But that outcome is not automatic.



<h2 class="wp-block-heading">The development problem is not just having more resources</h2>



For a long time, people often discussed economic development in terms of accumulation.



<ul class="wp-block-list">
<li>More capital.</li>



<li>More workers.</li>



<li>More infrastructure.</li>



<li>More education.</li>



<li>More technology.</li>
</ul>



But modern development economics introduced a more complex idea: what matters is not only how many resources an economy possesses, but&nbsp;what it can do with them.



This is particularly visible in the work of Ricardo Hausmann and colleagues on productive capabilities and the Product Space. Countries do not become more sophisticated simply by accumulating more inputs. They develop capabilities that allow them to move into increasingly complex products and services.



That distinction matters enormously for AI. AI gives almost every company access to additional productive capacity. It does not give every company the same capability to turn that capacity into value.



<h2 class="wp-block-heading">Uruguay already has a capability advantage</h2>



Uruguay is not starting from zero.



Its software industry has spent decades accumulating capabilities around engineering, export services, product development, international collaboration, and technology infrastructure.



The results show up in the numbers.



In 2024, <a href="https://www.trade.gov/country-commercial-guides/uruguay-digital-economy" target="_blank" rel="noopener">Uruguay&#8217;s ICT</a> sector generated US$2.323 billion in exports, representing 63% of total sector sales. Seventy-six percent of companies reported having international clients, and the United States was the sector&#8217;s principal destination.



This changes the AI question. Uruguay does not necessarily need to become a country with more developers than its competitors. It needs to become a country where each unit of software talent can generate more sophisticated and valuable output.



That is an elasticity question.



<h2 class="wp-block-heading">AI can increase capacity without increasing population</h2>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="670" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/Imagine-two-software-economies_-1024x670.jpg" alt="AI can increase capacity without increasing population" class="wp-image-4743" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/Imagine-two-software-economies_-1024x670.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Imagine-two-software-economies_-300x196.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Imagine-two-software-economies_-767x502.jpg 767w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Imagine-two-software-economies_-1536x1005.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Imagine-two-software-economies_.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



The question becomes:



How much additional economic value can an economy generate from each additional unit of AI-enabled capacity?



<h2 class="wp-block-heading">But technology alone does not create development</h2>



This is where economic history gives us an important warning. Technology does not automatically translate into economic development.



The Solow growth tradition showed that technological progress changes the productivity of capital and labor, while endogenous growth theory, associated with economists such as Paul Romer, emphasized the importance of knowledge, ideas, and human capital in generating sustained growth.



But technology needs complementary capabilities:



<ul class="wp-block-list">
<li>People need to know how to use it.</li>



<li>Organizations need to redesign processes around it.</li>



<li>Markets need to reward new forms of production.</li>



<li>Institutions need to adapt.</li>



<li>And businesses need access to customers willing to pay for the resulting value.</li>
</ul>



AI is no different. Giving a software company access to an AI model is not equivalent to giving that company a competitive advantage.



The advantage comes from the interaction between AI and everything else the company already knows how to do.



<h2 class="wp-block-heading">This is where public policy matters</h2>



Uruguay&#8217;s National AI Strategy 2024-2030 is interesting precisely because it does not frame AI simply as a technology-adoption program.



Its objectives include governance, national capabilities and sustainable development. The capabilities axis explicitly includes talent and digital skills, infrastructure, data protection and cybersecurity. The development axis positions AI as a potential driver of economic growth, private-sector competitiveness, digital transformation, research and innovation.



That is important. A country trying to benefit from AI doesn&#8217;t just need companies using AI. It needs an ecosystem that can&nbsp;absorb AI. This brings us back to the first two articles in this series. At the organizational level, we asked:



How much AI-enabled capacity can a company absorb?



<ul class="wp-block-list">
<li>At the individual level, we asked:</li>
</ul>



How much AI-generated work can a developer cognitively absorb?



<ul class="wp-block-list">
<li>Now we can ask the economic version:</li>
</ul>



How much AI-enabled capacity can an economy convert into international value?



<h2 class="wp-block-heading">The elasticity of an economy</h2>



Suppose Uruguay suddenly gives every software developer access to powerful AI tools. The country&#8217;s theoretical software capacity increases. But that does not mean exports automatically increase by the same proportion. The additional capacity might instead create new bottlenecks.



Companies may struggle to find international customers. Product management may become the constraint. Senior technical leadership may become scarce. Quality assurance may lag behind development speed. Companies may produce more software but not more valuable software. Or they may use AI simply to deliver existing services more cheaply, without moving into more sophisticated activities. In that scenario, AI increases capacity without sufficiently increasing economic value.



Elasticity falls. The alternative is more interesting.



<ul class="wp-block-list">
<li>What if AI allows Uruguayan companies to move from staff augmentation toward higher-value product development?</li>



<li>What if small teams can compete for projects that previously required much larger engineering organizations?</li>



<li>What if existing export relationships become channels for selling AI-enabled products and services?</li>



<li>What if AI helps local companies enter more complex parts of the global software value chain?</li>
</ul>



Now the country is not merely producing software faster. It is increasing the complexity of what it can produce and export. That is a development story.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="976" height="1024" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-elasticity-of-an-economy-976x1024.jpg" alt="The elasticity of an economy" class="wp-image-4742" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-elasticity-of-an-economy-976x1024.jpg 976w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-elasticity-of-an-economy-286x300.jpg 286w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-elasticity-of-an-economy-768x805.jpg 768w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-elasticity-of-an-economy-1465x1536.jpg 1465w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-elasticity-of-an-economy.jpg 1600w" sizes="auto, (max-width: 976px) 100vw, 976px" /></figure>



<h2 class="wp-block-heading">From cost advantage to capability advantage</h2>



This distinction matters for Uruguay&#8217;s relationship with the United States.



Nearshore software has traditionally offered US companies advantages around geography, time zones, talent, and cost.



AI changes the competitive equation. If AI makes software production cheaper everywhere, cost becomes a weaker differentiator. The strategic advantage has to move somewhere else:



<ul class="wp-block-list">
<li>Capabilities.</li>



<li>Domain knowledge.</li>



<li>Product thinking.</li>



<li>Engineering quality.</li>



<li>Trust.</li>



<li>Communication.</li>



<li>Speed of experimentation.</li>



<li>The ability to integrate AI into complex organizations.</li>
</ul>



In other words, AI can make basic software capacity less scarce while making sophisticated capabilities more valuable.



For Uruguay, that could be an opportunity.



The country already has an export-oriented technology sector with deep exposure to international markets. Its next advantage may come from increasing the value generated by that existing capability rather than simply producing more of the same.



<h2 class="wp-block-heading">Policy can move the elasticity curve</h2>



This is perhaps the most important implication. Public policy cannot manufacture a successful software company. It cannot guarantee a US contract. But it can influence the conditions under which additional technological capacity becomes productive. Uruguay&#8217;s AI strategy explicitly seeks to build national capabilities, strengthen infrastructure and skills, promote innovation, and improve private-sector competitiveness.



That means policy can potentially affect the slope of the elasticity curve.&nbsp;



<ul class="wp-block-list">
<li>Better talent increases absorption capacity.</li>



<li>Better infrastructure increases technical capacity.</li>



<li>Better data increases AI capability.</li>



<li>Clearer governance reduces uncertainty.</li>



<li>Research and innovation increase the possibility of moving into new products and services.</li>



<li>International connections increase the market available for the resulting capabilities.</li>
</ul>



None of these guarantees growth. Together, however, they can change the conditions under which AI generates economic value.



<h2 class="wp-block-heading">The small-country paradox</h2>



There is an interesting paradox here. Large economies have an obvious advantage in AI: more capital, more companies, more researchers, and larger domestic markets. Small economies cannot compete with that scale directly. But they may move faster.



A small ecosystem can coordinate policy, academia, companies and talent more tightly.



Uruguay&#8217;s own AI strategy was developed through a participatory process involving public institutions, private organizations, academia, civil society and other stakeholders.



That kind of coordination becomes more valuable when technological change is fast. The opportunity for a small economy is therefore not necessarily to have more AI. It is to have less friction between AI and the capabilities already present in the economy.



<h2 class="wp-block-heading">And this brings us back to the Elasticity Curve</h2>



Across this series, we have looked at three different constraints.



First, the organization. Adding AI-enabled capacity eventually reaches a point where more output creates more complexity than value.



Second, the developer. AI can accelerate production faster than human attention, judgment, and understanding can absorb that acceleration.



Third, the economy. A country can increase technological capacity without necessarily increasing the economic value generated from that capacity.



The same principle appears at all three levels.



Capacity is not value.



What matters is the relationship between them. And that relationship can be measured.



<h2 class="wp-block-heading">The Effectus AI Elasticity Formula</h2>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="981" height="1024" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Effectus-AI-Elasticity-Formula-981x1024.jpg" alt="The Effectus AI Elasticity Formula" class="wp-image-4738" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Effectus-AI-Elasticity-Formula-981x1024.jpg 981w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Effectus-AI-Elasticity-Formula-287x300.jpg 287w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Effectus-AI-Elasticity-Formula-767x801.jpg 767w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Effectus-AI-Elasticity-Formula-1472x1536.jpg 1472w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Effectus-AI-Elasticity-Formula.jpg 1600w" sizes="auto, (max-width: 981px) 100vw, 981px" /></figure>



<h2 class="wp-block-heading">The real AI advantage</h2>



This changes the question companies should be asking.



Not:



How much AI can we deploy?



Not even:



How much faster can our developers work?



But:



Where is our AI elasticity highest?



<ul class="wp-block-list">
<li>That question leads to better decisions.</li>



<li>Where should AI replace repetitive work?</li>



<li>Where should it augment expert judgment?</li>



<li>Where should humans remain firmly in control?</li>



<li>Where should we add more AI capacity?</li>



<li>Where should we stop?</li>
</ul>



And, perhaps most importantly:



What capabilities do we need to build to move the elasticity point?



That is the difference between adopting AI and developing an AI strategy. For a developer, it means learning how to direct and evaluate AI. For a company, it means redesigning workflows around the new capacity. For an economy, it means building the capabilities, institutions, and international connections that allow AI to translate into higher-value production.&nbsp;



The countries, companies, and teams that understand this will not necessarily be the ones with the most AI. They will be the ones that can extract the most value from the next unit of AI capacity.



That is AI elasticity.



<h2 class="wp-block-heading">Uruguay as a Destination for AI-Driven Talent and Investment </h2>



What is happening in Uruguay is a useful real-world example of the opportunity created by AI-driven elasticity. 



Praxis, a technology community focused on a post-AI future, recently selected Uruguay for a planned city-scale development within Colonia, announcing plans to mobilize up to <a href="https://www.nytimes.com/2026/09/22/world/americas/praxis-uruguay-colonia-tech-utopia.html" target="_blank" rel="noopener">$1 billion in investment</a> over the next three years. 



Beyond the project itself, the signal is important: as AI changes where knowledge, capital and highly skilled talent can create value, countries with a strong technology base, institutional stability and access to global markets can become magnets for new forms of technological activity. Uruguay is increasingly positioning itself not only as a place where software can be built, but as a place where the people, companies and ideas shaping the next phase of the AI economy can converge.

AI makes software companies faster. That&#8217;s becoming hard to dispute. Developers can generate code, write tests, explain unfamiliar systems, prototype ideas, and troubleshoot problems in minutes that once required hours.



So the natural question is:



How much faster can a developer become?



Two times faster? Five times? Ten times? The question sounds like a measurement problem. But it may actually be a cognitive one.



Because software development has never been limited only by how quickly a human can type code. It is also limited by how quickly a human can understand a problem, make decisions, evaluate alternatives, recognize mistakes, and maintain a coherent mental model of the system.



AI can accelerate production dramatically, but it cannot make human attention infinite: this creates a second dimension of the AI Elasticity Curve.



<h2 class="wp-block-heading">The problem with measuring productivity in hours</h2>



Suppose a developer spends eight hours building a feature. An AI coding assistant helps reduce the implementation work to two hours. It is tempting to say that AI made the developer four times more productive.



But what happened to the other six hours?



Perhaps they disappeared. Perhaps they were spent reviewing the generated code, testing edge cases, checking assumptions, comparing alternatives, fixing subtle errors, or understanding what the AI actually produced. Or perhaps the developer used the additional time to explore three other approaches to the same problem.



This distinction matters.



Time saved does not necessarily translate into productive capacity gained.



Economic thought has addressed versions of this problem before. Productivity generally concerns the relationship between inputs and outputs, not simply how quickly one activity can be performed.



AI complicates that relationship because it can dramatically reduce the time required for certain tasks while also increasing the number of tasks, possibilities, and decisions available. 



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="250" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-problem-with-measuring-productivity-in-hours-1024x250.jpg" alt="The clock moves faster, but the mind does not." class="wp-image-4718" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-problem-with-measuring-productivity-in-hours-1024x250.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-problem-with-measuring-productivity-in-hours-300x73.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-problem-with-measuring-productivity-in-hours-765x187.jpg 765w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-problem-with-measuring-productivity-in-hours-1536x375.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-problem-with-measuring-productivity-in-hours.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



<h2 class="wp-block-heading">AI changes the shape of the work</h2>



Consider a developer working without AI. They might spend four hours implementing a solution and one hour reviewing it.



With AI, the implementation might take one hour. But now the developer has five possible approaches instead of one. The codebase contains more generated components. There are more assumptions to verify. More edge cases to consider.



The developer may still spend an hour reviewing. The difference is that the developer now has much more output to evaluate. AI has increased production velocity. It has not necessarily increased cognitive velocity by the same amount.



This is where <a href="https://link.springer.com/chapter/10.1007/978-1-349-20568-4_5" target="_blank" rel="noopener">Herbert Simon&#8217;s concept of bounded rationality</a> becomes relevant.



Simon argued that human decision-making is constrained by limited information, limited cognitive processing capacity, and limited time. Humans therefore do not optimize every decision. They operate within the boundaries of what they can actually process.



<a href="https://www.effectussoftware.com/ai-software-development-services">Generative AI</a> changes the first part of that equation dramatically.



It can produce more information. More alternatives. More explanations. More code. More possible solutions. But the human constraints remain. This creates an asymmetry:



AI can expand the possibility space faster than humans can evaluate it.



<h2 class="wp-block-heading">The developer&#8217;s mind as a bottleneck</h2>



This is not an argument against AI. Quite the opposite. The most valuable use of AI may come from understanding where the human bottleneck actually sits.



A developer does not need to personally produce every line of code, but they do need to understand enough of the system to decide whether the code should exist. They need to know what problem they are solving. They need to distinguish an elegant solution from an unnecessary one. They need to recognize when an apparently correct implementation violates an important assumption. They need to understand the consequences of a technical decision months later.



Those are not simply production tasks. They are judgment tasks. And judgment has a different relationship with time.



<h2 class="wp-block-heading">Can AI make a developer ten times faster?</h2>



Imagine AI makes every implementation task ten times faster; that doesn&#8217;t mean the developer becomes ten times faster at everything.



The developer still has to:



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="412" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/Can-AI-make-a-developer-ten-times-faster_-1024x412.jpg" alt="Can AI make a developer ten times faster?" class="wp-image-4716" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/Can-AI-make-a-developer-ten-times-faster_-1024x412.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Can-AI-make-a-developer-ten-times-faster_-300x121.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Can-AI-make-a-developer-ten-times-faster_-768x309.jpg 768w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Can-AI-make-a-developer-ten-times-faster_-1536x618.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/Can-AI-make-a-developer-ten-times-faster_.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



This creates a fundamental asymmetry.



The faster AI becomes at generation, the more important human evaluation becomes.



The bottleneck moves from production to judgment.



<h2 class="wp-block-heading">From time saved to cognitive load</h2>



This is why traditional productivity metrics can become misleading.



Imagine two teams:



<ul class="wp-block-list">
<li>Team A uses AI to reduce a task from eight hours to two.</li>



<li>Team B uses AI to reduce the same task from eight hours to two, but then uses the remaining six hours to investigate architecture, run experiments, and improve the product.</li>
</ul>



Both teams achieved the same apparent productivity gain, but their outcomes are completely different: the difference isn&#8217;t AI adoption.



It is what the organization does with the capacity AI creates.



This is the same problem we encountered in the first article. Additional capacity only creates value when the surrounding system can absorb it. At the individual level, the surrounding system is partly the human mind, which gives us a second form of elasticity.



<h3 class="wp-block-heading">Cognitive Elasticity</h3>



We can think of it as the relationship between additional AI-enabled capacity and the quality of human decision-making.



At first, AI can increase cognitive leverage.



<ul class="wp-block-list">
<li>It removes repetitive work.</li>



<li>It retrieves information.</li>



<li>It generates alternatives.</li>



<li>It gives developers more time to think about higher-value problems.</li>
</ul>



But eventually, the extra output can overwhelm the person responsible for evaluating it. At that point, the marginal benefit declines.



And beyond a certain point, more AI assistance can actually make the work worse. Not because the AI necessarily becomes less capable. Because the human system becomes overloaded.



<h2 class="wp-block-heading">The paradox of faster development</h2>



This creates a strange paradox.&nbsp;



The faster we make software production, the more important slowing down in the right places may become.



<ul class="wp-block-list">
<li>If writing code takes minutes, understanding whether the code should be written becomes relatively more important.</li>



<li>If prototyping becomes almost free, deciding which prototypes deserve attention becomes more valuable.</li>



<li>If AI can generate ten solutions, selecting the right one becomes the scarce activity.</li>



<li>If implementation becomes abundant, judgment becomes scarce.</li>
</ul>



This is why the AI transformation of software development cannot be measured only in lines of code, tickets completed, or hours saved. The scarce resource is moving.



When production becomes cheaper, judgment becomes more valuable.



<h2 class="wp-block-heading">The speed limit is not the keyboard</h2>



The real speed limit of software development may therefore have very little to do with typing speed. It may be the rate at which a developer can maintain a sufficiently accurate mental model of a complex system while making good decisions.



That rate is not constant. It depends on experience, context, complexity, attention, and the quality of the tools surrounding the developer.



This is also where human capital becomes important. Technology does not eliminate the value of expertise. In some environments, it can increase it.



An experienced developer may use AI effectively because they can quickly recognize bad assumptions, ask better questions, constrain the solution space, and evaluate trade-offs.



A less experienced developer may generate the same amount of code but have a harder time determining whether that code is actually good.



The difference is not simply technical skill. It is the ability to direct and evaluate additional capacity. AI therefore does not necessarily flatten the value of expertise. It can change where expertise matters.



<h2 class="wp-block-heading">The new productivity question</h2>



For decades, software organizations asked:



How long does this take to build?



AI encourages a new question:



How much useful work can we do with the same amount of human attention?



That is a much harder metric, because human attention cannot be scaled in the same way as compute. You can add:



<ul class="wp-block-list">
<li>Another model.</li>



<li>Another agent.</li>



<li>Another coding assistant.</li>



<li>Another automated workflow.</li>
</ul>



You cannot simply add another unit of human judgment to the same developer.



This is the point where our original Elasticity Curve becomes more interesting. The curve is not only about how much capacity an organization can absorb. It is also about how much AI-generated capacity a human can convert into quality.



<h2 class="wp-block-heading">From developer elasticity to business elasticity</h2>



This gives us the second piece of the framework. In Blog 1, we asked what happens when AI-enabled production capacity grows faster than an organization can absorb.



Now we can ask a more precise question:



What happens when AI-generated possibilities grow faster than a developer can evaluate them?



The answer is not to use less AI. It is to understand where AI should increase human leverage and where it begins to create cognitive overhead.



The objective is not maximum acceleration. It is Productive Acceleration.



That distinction will become increasingly important as AI moves from assistants that generate code to agents that can independently plan, execute, and iterate across entire development workflows. Because once AI can operate with much greater autonomy, the question changes again.



The scarce resource is no longer simply developer time. It becomes the organization&#8217;s ability to direct, supervise, and convert AI capacity into economic value. That takes us to the final piece of the series. Because if an individual developer can become more productive, and a software company can reorganize around that productivity, there is a larger question:



What happens when an entire country&#8217;s software industry gains that additional capacity?



<ul class="wp-block-list">
<li>Can AI increase not only developers&#8217; productivity, but an economy&#8217;s competitive elasticity?</li>



<li>And can a country like Uruguay turn that additional capacity into more sophisticated software exports, stronger capabilities, and more business with the United States?</li>
</ul>



That is where AI elasticity moves from the developer&#8217;s mind to the economy.

The Speed Limit of the Developer&#8217;s Mind: AI, Time, and Cognitive Elasticity

For decades, software companies had a simple answer to a simple problem: if you need to build more, add more developers. More developers meant more capacity. More capacity meant more features, more products, and, at least in theory, more growth.



Generative AI has changed that equation.



A developer with AI can write, test, debug, document, and explore software at a pace that would have been difficult to imagine a few years ago. Google&#8217;s <a href="https://dora.dev/research/2025/" target="_blank" rel="noopener">2025 DORA research</a> found that 90% of surveyed technology professionals were already using AI in their work, with more than 80% reporting productivity improvements.



But a problem hides inside that productivity story.



What happens when a company can produce more software than it can effectively absorb?



That is where AI elasticity begins.



<h2 class="wp-block-heading">The Malthusian problem, without the famine</h2>



Thomas Malthus is usually remembered for a prediction that did not survive the Industrial Revolution: population could grow faster than the resources needed to sustain it.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="634" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Malthusian-problem-without-the-famine-1024x634.jpg" alt="The Malthusian problem, without the famine" class="wp-image-4723" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Malthusian-problem-without-the-famine-1024x634.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Malthusian-problem-without-the-famine-300x186.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Malthusian-problem-without-the-famine-768x475.jpg 768w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Malthusian-problem-without-the-famine-1536x950.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Malthusian-problem-without-the-famine.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



The more interesting part of the Malthusian argument is the constraint itself.



A system can increase its capacity and still fail to generate proportional improvements in outcomes. Eventually, something limits the return on additional inputs.



Economic development eventually escaped this trap through technological progress, capital accumulation, human capital, and institutional change. Technology did not simply add more resources to the existing system. It changed what the system could do.



AI creates a similar question for software organizations: the constraint is no longer necessarily how much code developers can produce. It may be how much code, information, decisions, and possibilities the organization can absorb.



<h2 class="wp-block-heading">AI changes the bottleneck</h2>



Let&#8217;s think together… 



<ul class="wp-block-list">
<li>Consider a five-person engineering team.
<ul class="wp-block-list">
<li>Without AI, the team may have enough capacity to explore three approaches to a new product feature.</li>



<li>With AI, they might explore fifteen.</li>
</ul>
</li>
</ul>



At first, this looks like pure gain, doesn&#8217;t it? More alternatives. More experimentation. More speed. But fifteen alternatives also mean fifteen things to evaluate:



<ul class="wp-block-list">
<li>More generated code means more code to review.</li>



<li>More prototypes mean more decisions.</li>



<li>More decisions mean more opportunities for disagreement, context switching, and bad choices.</li>
</ul>



The constraint has moved.



This is already visible in research on AI-assisted development. A 2026 longitudinal study of professional software engineers found that developers spent less time on many development tasks, while their work shifted toward verifying, evaluating, and correcting AI output. The researchers describe this emerging category as:



→ supervisory engineering work.



Another 2026 study found that developers using AI achieved substantially higher task completeness, but also showed a 12.5% decline in their ability to answer technical questions about the code they had produced.



The pattern is important.



AI can remove a production bottleneck while creating an absorption bottleneck.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="634" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/AI-changes-the-bottleneck-1024x634.jpg" alt="The paradox of acceleration in ai-assisted development" class="wp-image-4724" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/AI-changes-the-bottleneck-1024x634.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/AI-changes-the-bottleneck-300x186.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/AI-changes-the-bottleneck-768x475.jpg 768w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/AI-changes-the-bottleneck-1536x950.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/AI-changes-the-bottleneck.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



<h2 class="wp-block-heading">More capacity does not automatically mean more value</h2>



This is where the conventional definition of developer productivity becomes inadequate. If productivity means the amount of code produced per hour, AI looks extraordinary. If productivity means business value created per unit of capacity, the equation becomes much harder.



A recent <a href="https://dl.acm.org/doi/10.1145/3803437.3806710" target="_blank" rel="noopener">ACM study</a> found that frequent GenAI users reported faster task completion and greater output, but those gains came with increased code-review burden and persistent cognitive effort spent verifying AI-generated work.



This creates a distinction that businesses need to take seriously:



Output is not the same as value.



A team can generate more code and ship more pull requests while simultaneously increasing technical debt, review costs, and system complexity. At some point, the additional capacity stops producing proportional returns. That is diminishing elasticity.



<h2 class="wp-block-heading">The Elasticity Curve</h2>



We can express the basic idea simply:



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="212" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-1-1024x212.jpg" alt="Elasticity = ΔQuality / ΔCapacity" class="wp-image-4725" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-1-1024x212.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-1-300x62.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-1-764x158.jpg 764w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-1-1536x318.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-1.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



At the beginning of AI adoption, increasing capacity can produce significant improvements. A developer moves faster. A team can experiment more. A product can reach users sooner.



But the curve does not continue upward indefinitely.



As capacity increases, the organization encounters new constraints. Review. Architecture. Product decisions. Security. Coordination. Human attention.



Eventually, additional AI-enabled capacity produces little additional quality.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="496" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-2-1024x496.jpg" alt="This is the AI Elasticity Point." class="wp-image-4726" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-2-1024x496.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-2-1536x744.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-2-768x372.jpg 768w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-2-300x145.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/The-Elasticity-Curve-2.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



The system starts paying for capacity it cannot use.



<h2 class="wp-block-heading">But should you stop at the elasticity point?</h2>



No.



This is where the Malthus analogy becomes more useful. A constraint doesn&#8217;t necessarily mean growth has to stop. It can mean that the system needs to change.



The Industrial Revolution did not solve the Malthusian constraint by simply producing more of the same. It changed the relationship between technology, labor, capital, and output.



AI may require the same kind of organizational transition. If developers can produce five times more code, the answer may not be to ask them to produce less.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="874" src="https://blog.effectussoftware.com/wp-content/uploads/2026/09/But-should-you-stop-at-the-elasticity-point_-1024x874.jpg" alt="It may be to redesign the development system around that new capacity." class="wp-image-4728" srcset="https://blog.effectussoftware.com/wp-content/uploads/2026/09/But-should-you-stop-at-the-elasticity-point_-1024x874.jpg 1024w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/But-should-you-stop-at-the-elasticity-point_-300x256.jpg 300w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/But-should-you-stop-at-the-elasticity-point_-768x655.jpg 768w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/But-should-you-stop-at-the-elasticity-point_-1536x1310.jpg 1536w, https://blog.effectussoftware.com/wp-content/uploads/2026/09/But-should-you-stop-at-the-elasticity-point_.jpg 1600w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



The objective is not to stay below the elasticity point. The objective is to move it.



<h2 class="wp-block-heading">The innovation opportunity</h2>



This creates an interesting paradox. The point where additional AI capacity starts generating diminishing returns can also become the starting point for innovation.



Why?



Because the constraint tells you something about the system. If developers are spending too much time reviewing AI-generated code, perhaps code review itself needs to be redesigned.



If product teams cannot evaluate how many ideas engineers can generate, perhaps product discovery needs to move faster.



If architecture becomes the bottleneck, perhaps AI should reason about architecture rather than simply generate implementation.



The organization discovers that its old operating model was designed for a different level of productive capacity. That is not necessarily a problem. It can be a signal.



The elasticity point tells you where the old system stops working.



Innovation begins when you redesign the system around the new capacity.



<h2 class="wp-block-heading">From productivity to capability</h2>



This distinction also mirrors a broader lesson from economic development.



Development is not simply about accumulating more inputs. It is about building the capabilities that let those inputs generate increasingly sophisticated output.



The same principle applies to AI adoption. A company that adds AI tools to an unchanged development process may get an initial productivity boost and then encounter diminishing returns.



A company that changes its processes, skills, and organizational structures around AI can potentially shift the entire curve. This is the difference between AI adoption and <a href="https://www.effectussoftware.com/ai-software-development-services">AI transformation</a>.



One increases capacity. The other increases the organization&#8217;s ability to convert capacity into value.



<h2 class="wp-block-heading">The question businesses should be asking</h2>



The AI conversation is still dominated by questions like:



<ul class="wp-block-list">
<li>How many developers can AI replace?</li>



<li>How much faster can we code?</li>



<li>How many AI tools should our team use?</li>
</ul>



Those are useful questions, but they miss the deeper one.



How much AI-enabled capacity can our organization productively absorb?



That is the beginning of AI elasticity. Because AI&#8217;s value depends on what happens to quality when you add it. And that relationship is not fixed.



It depends on the developer, the team, the product, the organization, and the systems surrounding them.



The most advanced companies are therefore not necessarily the ones using the most AI.



They will be the ones that understand where additional AI creates leverage, where it creates friction, and what they need to change when the curve starts bending.



That is the problem we will explore next. Because if AI can accelerate software production, there is another scarce resource we need to understand:



the developer&#8217;s ability to absorb that acceleration.



<ul class="wp-block-list">
<li>Can AI make a developer ten times faster?</li>



<li>And if it can, can a human mind actually operate at ten times the speed?</li>
</ul>



That question takes us from organizational elasticity to cognitive elasticity.

Knowledge grows when shared

All blog posts

Knowledge grows when shared

All blog posts

Hit subscribe to stay in the loop!

Hit subscribe
to
stay in the loop!