When AI Makes Features Cheap, Judgment Matters More

With AI code generation, simply saying yes to new feature requests is much easier, almost too easy!

Someone asks for one more option in a workflow, a slightly different path for a group of customers, or a new setting. A developer can use AI to get a plausible pull request together very quickly. While this is useful, it is also where the problem can start.

The question is no longer just, “Can we build this?” More and more, the important question is, “Should we build this at all?”

A quick feature is not a cheap feature

Before AI, a small feature request came with some built-in friction and speed bumps. Someone had to understand the request, work through the behavior, write the code, and think about what could go wrong (edge cases!). That did not guarantee a good product decision, but it did force some thought before the feature existed.

Now it is easier to skip ahead, a request can turn into seemingly working code before the team has agreed on the problem it is trying to solve.

Consider a common request: a customer wants one more option in an existing workflow. On the surface, it may sound simple: Add a setting, show another button, or route certain users through a slightly different process. AI can help create the UI, API changes, tests, and documentation faster than before.

But that is only the first cost.

Someone still needs to ask:

• Which customers actually need this option?

• Does it make the normal workflow harder to understand?

• What happens when it conflicts with another setting or an unusual customer state?

• Who supports it when a customer is confused?

• What happens when the business rule changes six months from now?

• Is this a real product capability, or a one-off workaround that should be handled another way?

• How much technical debt is this adding to our platform?

Those questions do not go away because the code was quick to generate. In some ways, they become easier to ignore. When implementation feels cheap, a feature can start to feel inevitable.

Reviewing the code is not the same as thinking through the feature

There is another issue with AI-generated code: it can be harder to review than to write.

When you write code yourself, you are usually thinking through scenarios as you go. You know which assumptions you made, which edge cases you still need to handle, and what business rule you were trying to represent.

When you review code written by someone else, you are proof-checking their reasoning. With AI, the code may look clean and complete, but there is no real reasoning to inspect. It can do exactly what was requested and still represent the wrong business rule.

A green test suite is useful. A code review is useful. Neither one, by itself, tells you whether the feature should exist or whether the business expectation was correct in the first place.

This matters most when a change affects money, eligibility, compliance, or a commitment to a customer. Those business scenarios need to be clear before the code starts moving quickly. Someone needs to own the decision, not just approve the pull request.

Part of the job is knowing when not to build

Being a good engineer or consultant is not just about finding a way to build what someone asks for. It is also about helping them decide when not to build it.

Sometimes the better answer is a simpler operational process. Sometimes an existing workflow needs to be improved instead of adding another configuration option. Sometimes the right thing to do is learn more about the customer problem before committing it to the codebase.

That is not being resistant or slowing things down. It is how you keep a product from becoming a collection of exceptions that nobody fully understands.

Every feature adds something that users need to learn, support teams need to explain, engineers need to test, and future changes need to account for. One small option may be fine. Enough small options become a system that is difficult to explain and risky to change.

That is technical debt, even if every pull request looked reasonable when it was merged.

Use the speed to make better decisions

This is not an argument to avoid AI or turn every small change into a long process. AI is great for well-understood and thought-out work. It can remove repetitive effort and help move a good idea forward much faster.

But we should not confuse a fast implementation with a good product decision.

As code gets cheaper to generate, judgment becomes more valuable. The teams that use AI well will not be the ones that add the most features. They will be the ones that use the extra speed to build the right things and are comfortable leaving the wrong things out.

In the year of our lord 2026, it is still a little wild how quickly a new application turns into a shopping cart full of infrastructure.

A database, obviously. Then a search cluster, because searching is hard. A queue, because background work is hard. Redis, because speed. An analytics warehouse, because charts. A vector database, because it is 2026 and apparently every application needs to have a thoughtful conversation with its own invoices.

Before anyone has used the product, the architecture diagram looks like a cloud-vendor scavenger hunt.

Just use Postgres.

More precisely: start with Postgres, and make every additional system earn its way into the application. Not with “we may need this at scale,” but with a concrete requirement the database cannot meet.

This is not the argument that Postgres is secretly every kind of database. It is not. It is the argument that operational complexity is real, and a mature relational database can cover an almost rude amount of early and middle-stage application work.

Every box comes with chores

A new service is never just one more friendly logo on the diagram. It is another deployment, backup policy, access model, alert, upgrade path, incident mode, and bill. It is another thing to explain to the next engineer who joins the team.

The entertaining part begins when data has to exist in more than one place. The application writes a record to Postgres. A worker copies it to the search index. Another process invalidates a cache. Somebody notices the analytics event is missing. Now the team has a distributed-systems problem, which is a very sophisticated way to say “we are trying to keep our copies from disagreeing.”

That can absolutely be worthwhile. It is just not free because the managed-service setup wizard was pleasant.

Postgres lets a team postpone much of that ceremony. It gives you transactions, indexes, full-text search, structured queries, and support for semi-structured data in one well-understood place. That leaves more time to find out whether anyone wants the product.

The boring default has range

Most applications start with related records that need to be correct: users, accounts, permissions, orders, messages, audit logs, tasks. A relational database is not a compromise for that workload. It is the obvious tool.

It also has more room than people sometimes remember:

• Search: Built-in full-text search may be plenty when users need to find things in your application, rather than search the internet with all the relevance expectations that implies.
• Flexible attributes: JSONB is useful when a few fields genuinely vary, while the facts the application relies on stay in columns with types and constraints.
• Background work: A table-backed job queue can be a practical answer for modest asynchronous work, especially when creating the job must be atomic with a database update.
• Reporting: Indexes, aggregates, and materialized views can answer a surprising number of product and operational questions before a separate analytics pipeline becomes necessary.
• Retrieval features: Vector extensions can make a small semantic-search or retrieval feature easier to prototype beside the records it is retrieving.

None of this means dedicated tools are fake. It means “could Postgres handle the first honest version?” is a much better question than “which six services should we provision before lunch?”

“We might need it later” is not a requirement

There is a familiar performance of technical seriousness where a team rejects the simple design because it might not survive the eventual day it has 100 million users, a global event stream, and a full-time platform group.

Maybe! That would be a great problem to have. It would also be useful to know whether the product needs 100 users first.

A specialized system should have a job description:

• A dedicated search engine makes sense when relevance requires sophisticated ranking or faceting, indexing load is hurting the primary database, or search must be available independently of transactional traffic.
• A message broker makes sense when workloads need durable fan-out, replay semantics, very high throughput, or consumers that scale independently.
• A cache makes sense when the database cannot meet a known latency or read-volume target at an acceptable cost.
• A warehouse makes sense when analytical queries should not compete with transactional work, or when the organization needs durable historical analysis across many systems.

Those are requirements. “We saw a conference talk” is a mood.

One system does not mean one terrible system

Using Postgres for more than the obvious tables is not permission to put every fact in one 400-column table called “data” and call it flexibility.

The fundamentals still matter, perhaps more so when one system is carrying a meaningful share of the application:

1. Model stable facts explicitly. Use types, foreign keys, and constraints where integrity matters. Use flexible fields deliberately, not to avoid deciding what data means.
2. Measure real queries. A slow query is a reason to inspect indexes and query plans before it is a reason to buy a different database.
3. Make background work observable. A table-backed queue still needs retries, failure handling, and a clear answer for what happens when a worker disappears at 2:00 AM.
4. Know the escape route. When a specialized service becomes necessary, decide what is authoritative, how data is copied, how correctness is checked, and what happens when synchronization falls behind.

The goal is not to prove that Postgres can be forced into every workload. Congratulations, nobody gets a medal for that. The goal is to avoid paying for distributed complexity until it pays you back.

AI can help with the code. It cannot un-move the data.

In 2026, Codex and Claude can do useful work on technical debt. They can help trace a legacy code path, draft a refactor, write tests, or turn an unpleasant migration plan into a less unpleasant set of pull requests. That is genuinely useful.

They cannot make a bad datastore decision disappear.

Once production data lives at meaningful scale in the wrong place, the hard part is rarely producing the migration script. It is moving data without losing it, corrupting it, leaking it, duplicating it, or letting two systems quietly disagree while the migration is in progress. Then there are backfills, validation, cutover, rollback, client compatibility, and the small matter of keeping the application available while all of this happens.

An AI assistant can help reason about those steps. It cannot turn a risky data migration into a harmless autocomplete exercise. The more systems that become authoritative for some slice of the product, the more expensive the eventual exit tends to be.

That is another reason to start simple. Choosing Postgres does not guarantee you will never migrate data; products change. It does mean you should not create a migration project merely because an early architecture diagram needed more logos.

Make complexity pay rent

Some applications need specialized infrastructure on day one. A search product with sophisticated relevance requirements is not going to bluff its way through with a basic text index. A high-volume eventing platform should not pretend a table queue is its final form. A real-time analytics product may have needs that are plainly not OLTP.

Fine. Use the right tool.

But most teams should be able to state the specific benefit they are buying: a reliability property, a measured performance target, or a product capability that the simpler design cannot deliver. If they cannot, the new box is probably architecture cosplay.

Postgres is not everything. It is just a very capable foundation that can let a team ship, learn, and defer irreversible decisions until there is evidence behind them.

That is less glamorous than a diagram with twelve logos. It is also often how you end up with an application instead of a collection of services that is very prepared to support one.

This post was sparked by Raphael Bauer’s “PostgreSQL for Everything”. His essay goes deeper on the capabilities that make the “start here” argument possible.

I’ve been seeing a lot of people and projects trying to use AI for everything, even if it’s not really needed, even for “Generate a random password”. Sure it can do it, I guess, but is it really the right use case for it? Sometimes people are going overboard in their use of AI just so they can say “it’s AI enabled!”.

Drawing the line between a good use of AI and when another tool, simple function, or a different approach is better can be difficult since it has such broad capabilities. I’ve started to try to come up with some general rules to follow. When you need something that is very predictable, i.e. business rules, validation, record keeping, etc., generally AI isn’t going to be the best fit. On the other hand, AI is great for when you need to deal with messy inputs from an email, PDF, image, handwriting, slightly varying formats, etc.

That is not a limitation of AI. It is what makes a good implementation work. The goal is not to turn every step into an AI decision. It is to give AI the part of the problem where ambiguity is real and use other tools where the organization needs a repeatable answer.

A couple of recent projects we’ve had can highlight this distinction.

Check processing: use AI to read the check, not run the process

Consider a check-processing application that accepts uploaded images and prepares records for an accounting or fundraising platform.

Checks are a good use case for AI. They come in different formats, handwriting can be hard to read, and important information may be in different places depending on the check. AI can identify a likely payer or donor, pull out the amount and check number, read a memo line, and return structured candidate data.

That removes a lot of manual entry. It turns a document into a useful starting point.

But recognizing the document is not the same thing as deciding what should happen next. The application still needs deterministic software to validate required fields and expected formats, check whether the check was already processed, match the payer against known records, apply account or fund mappings, and determine whether the item needs review.

Only after those checks pass should the workflow submit a record to the downstream platform. It should retain the original image, the extracted values, any corrections, and a record of what was submitted.

In this case, AI is the right tool for interpretation. A rules-based workflow is the right tool for deciding whether the interpretation is ready to become a trusted record.

Purchase-order intake: use AI to handle variation, not enforce the contract

Purchase orders have the same shape. They often arrive by email or as PDFs, and every customer has their own template. Line items, pricing, shipping details, purchase-order numbers, and customer information may all be presented differently.

AI can turn those inconsistent documents into a draft order. It can identify the likely customer, extract line items, quantities, and prices, and point out fields where it is uncertain.

That is exactly the type of variation AI is useful for. It saves someone from manually typing information from a PDF into an ERP or order-management system.

But the AI should not be responsible for enforcing the rules around the order. Deterministic software should validate that the customer exists, the SKUs are real, quantities are valid, and the price matches the customer’s contract or approved price list. It can verify that the purchase-order number has not already been used, make sure required shipping and billing information is present, and route exceptions to the right person.

Once those rules pass, the application can create the order in the ERP. If they do not pass, the system should say why it stopped and what needs to happen next.

AI helps make the document usable. The rest of the application makes the order trustworthy.

Choosing the boundary is part of the implementation

The mistake isn’t using AI, it is treating AI as the whole application because it can produce an answer that looks structured.

A good implementation gives each tool a job it is suited for:

• AI interprets ambiguity. It reads documents, extracts likely data, classifies inputs, and identifies uncertainty.
• Deterministic software verifies facts. It checks business rules, required fields, duplicates, permissions, mappings, and known reference data.
• Workflow software coordinates action. It routes exceptions, requests approvals, submits to the correct downstream system, and keeps an audit trail.

That division makes the system easier to operate too. AI output can change when a model, prompt, or document format changes. Business rules may change, but they should be explicit, testable, and owned by the people responsible for the process.

When an extracted amount is wrong, someone should be able to tell whether the problem came from the document, the AI output, a validation rule, or a mapping. When a downstream system receives a record, someone should be able to explain why it was submitted.

Those details are not exciting demo features, but they are what make a workflow usable in a real organization.

Start with the problem, not the model

When evaluating an AI workflow, start by asking where the uncertainty is.

If the problem is understanding an email, PDF, image, or conversation, AI may be the right tool. If the problem is enforcing a policy, validating a known fact, selecting a system of record, or creating an auditable action, conventional software is often the better tool.

The best AI implementations are not built around the idea that the model should do everything. They are built around the idea that a workflow can use many tools well. AI handles the ambiguous part. The rest of the application provides the boundaries that make its output useful.

Long story short, choose the right tool for the part of the problem you are trying to solve versus treating everything like a nail that you hammer on with AI.

A lot of small applications are getting built right now. Someone has a frustrating, repetitive problem, perhaps they need to clean up a report, move information from one system to another, or give customers a simpler way to complete a task. They use AI, a low-code tool, or just write a little code, and in a surprisingly short amount of time they have something useful. Then people start using it every day.

That is a huge win! The application proved that there is a real problem worth solving, which is often the hardest thing to figure out before building a larger project. The trouble is that once people depend on it, it has quietly stopped being just a quick experiment, even if it is still deployed like one.

Maybe it started as an internal tool that only a few people used, but now it is how a team gets a report out every week. Maybe it is a customer-facing feature that got enough use to become part of the product. Either way, when it stops working, someone notices pretty quickly, and the business usually has to work around it until it is fixed.

The app works until it doesn’t

This is a familiar situation. One person builds something useful and they know all the details: where it runs, how to deploy it, which API key it needs, and what to do when it gets weird input. Nobody else really has to think about it because the app has worked so far, and there are always other things to work on.

Then a dependency updates, an integration changes, or a user does something the original builder did not expect. The app might start throwing an error, or it might do something worse and quietly give the wrong answer. The person who built it could be on vacation, busy with a different project, or no longer at the company. Now a tool that people rely on has no clear owner and no obvious way for someone else to figure out what went wrong.

The original builder did not do anything wrong. Getting a useful version into people’s hands quickly is usually the right move, especially when nobody knows yet whether the idea will be valuable. However, proving that an idea works and operating an application that other people depend on are two different things, and they require a different level of support.

The small things are usually the big things

Most teams do not decide that error handling, monitoring, or security reviews are unimportant. They simply have not needed them yet, or they have been focused on getting the useful part of the application in front of people. When five people use a tool, it is easy to hear about a problem and fix it directly. When fifty people use it, or when customers use it outside of business hours, those shortcuts start to become real problems.

For example, what happens when an integration fails halfway through a process? If the app has already updated one system but has not updated the next system, can someone tell what happened and safely retry it, or do they have to start manually checking records to figure out what needs to be fixed? There may not be one right answer, but it is worth thinking through before the first time it fails in a way that affects the business.

Some other common things we see are:

• An error happens, but the user gets an unhelpful message and there is no log that explains what actually failed.
• Nobody knows whether the application is healthy until someone says it is broken in Slack.
• Deploying a change means following a series of manual steps that live in one person’s head.
• API keys and other credentials are stored wherever was convenient when the application was first built.
• The application has its own username and password, even though everyone already signs in through the company’s identity provider.
• It handles company or customer information, but nobody has taken the time to review who can see it, where the information goes, or how long it is kept.
• No one besides the original builder knows how the pieces fit together or how to get the application back up after a problem.

None of these things are especially exciting or sexy to build, but they are the things that make a useful application either dependable or stressful to rely on. They are also usually much easier to address while the person who built the app is still around and the application is otherwise working well.

It does not mean starting over

The answer is not to take a working application away from the people using it and disappear for six months to rewrite it. Usually the application already has the most important thing: a real use case, people who can explain what matters, and an understanding of where it actually helps the business. Starting from that point is much better than starting from a blank page and guessing.

A better approach is to look at what is there, understand how it is being used, fix the biggest risks first, and add the support the application needs as it grows. The questions are fairly straightforward, but the answers tend to point to the work that matters most:

• Where does it run, and how does a change get from code to users?
• What happens when one of its services or integrations fails?
• Can the team see errors, usage, and the health of the application without guessing?
• Who has access to the application, its data, and its credentials?
• Can it use the company’s existing login and access controls rather than adding another account for everyone to manage?
• Could someone besides the original builder understand it, make a change, and respond to an issue?

Giving a useful app the support it needs

A production application does not need to be complicated, and not every small tool needs the same amount of process as a large customer-facing system. It does need a few basics that match the importance of the job it is doing.

A repeatable deployment process means changes can be reviewed, tested, and released in a predictable way instead of requiring a set of commands someone hopes they remember correctly. It also gives the team a reasonable way to roll back a bad change when one inevitably gets through.

Good error handling and visibility means useful errors for users, logs that explain what happened, and enough metrics, monitoring, and alerting to notice a problem before it turns into a long Slack thread. This is not about collecting every possible number; it is about being able to answer the basic question of whether the application is working and why it is not when it fails.

Security should fit how the company already works. That includes being deliberate about secrets, permissions, and data flows, as well as reviewing who should have access to the application. For an internal tool, using the company’s existing identity provider often avoids one more username and password for employees to manage, and makes it easier to remove access when somebody changes roles or leaves.

Finally, the application needs some documentation and shared ownership. A short overview of how the pieces fit together, a runbook for common problems, and more than one person who can work on it go a long way. The person who first built the application should not have to be the permanent support team just because they had the initiative to solve a problem.

If AI is part of the application, there are a few additional questions around testing prompt or model changes, handling unusual input, and deciding when a person should review an output. Those are important questions, but they sit alongside the same operational basics that every useful application needs.

Make the app more dependable while it is going well

The best time to make an application more supportable is when it is working and people are getting value from it. There is less pressure, the original builder can explain why the application works the way it does, and the team can make improvements without disrupting the workflow it supports.

This is the type of work Setfive can help with: understanding the application that exists today, stabilizing the areas most likely to cause trouble, reviewing security and access, putting appropriate infrastructure and monitoring in place, and making sure the business is not dependent on one person. The goal is not to turn every small application into a huge project. It is to make sure the useful thing stays useful as more people start relying on it.

A while ago, a brochure website was a meaningful software project. Somebody needed to lay out the pages, create navigation, make a contact form work, and get it all deployed. Website builders did not make a good website automatic, but they made that particular layer of work cheap enough that it stopped being the main thing most companies paid for.

Something similar is happening to CRUD applications.

A competent engineer with current tools can get surprisingly far, surprisingly quickly: a schema, basic APIs, forms, table views, search, permissions, validation, an admin screen, and a handful of ordinary integrations. LLMs help produce that code faster and make the usual implementation details less expensive to iterate on.

That is real progress. It is also easy to draw the wrong conclusion from it.

The fact that it is getting easier to build a system of record does not mean the business problem is solved. It means the database-shaped part of the problem is less scarce.

The valuable question was rarely just “where do we put the records?” It was “what should we do next, who needs to do it, and how do we know it worked?”

From recording work to improving work

CRUD is still necessary. Organizations need a place to record customers, jobs, invoices, inventory, cases, and the rest of the nouns that make up their work. They need people to be able to find and correct those records.

But a record is not an outcome.

A useful distinction is between a system of record and a system of action. The first stores what happened. The second helps decide what deserves attention, coordinates action across people and systems, and learns from the result.

System of record	System of action
Stores customers, jobs, invoices, and cases	Prioritizes work and moves it forward
Lets people enter, search, and update data	Coordinates people, systems, and exceptions
Reports what happened	Forecasts, recommends, and optimizes what to do next
Uses broadly reusable patterns	Encodes domain-specific constraints and tradeoffs

The CRUD layer is often part of a system of action. It is just not usually the part that makes the system valuable.

The floor is moving to workflow

Take a customer-success tool. The commodity version has accounts, contacts, renewal dates, health-score fields, notes, and tasks. That is useful, and it is also a familiar application shape.

The harder version combines product usage, unresolved support issues, contract terms, champion turnover, and outcomes from similar accounts to answer a more useful question: which accounts need attention this week, and what action is most likely to change the outcome?

Then it needs to make that action practical. Perhaps a support issue needs escalation, a CSM needs a meeting, sales needs to be involved before a renewal date, and the team needs a shared view of what happened next. The value is not a nicer account page. It is reducing the chance that an important customer falls through the cracks.

This pattern appears everywhere. Field-service software can store work orders, technicians, addresses, and status updates. The differentiated work is scheduling and re-scheduling against technician skills, promised windows, parts availability, geography, overtime rules, uncertain job duration, and emergency calls. A credible schedule at 8:00 AM is not enough if the system cannot respond when a job takes twice as long as expected at 10:30.

That is workflow orchestration: the messy part involving handoffs, timing, exceptions, policy, and people. It is not glamorous, but it is where a lot of operational software earns its keep.

Not everything valuable is an LLM

LLMs are part of this shift, but “CRUD to AI” is too narrow a description.

LLMs are particularly useful when a workflow begins with unstructured information: an email, a document, a call transcript, an image, or a request written in normal language. They can help extract information, classify incoming work, summarize context, or give a person a natural-language interface to a system.

Other valuable systems may have no LLM in the critical path at all. They may use a rules engine, a forecast, a statistical process-control chart, a constraint solver, a simulation, or a carefully constructed report. Many systems will combine several of these approaches.

The common thread is not the model. The software does more than preserve a record of work. It helps make a better decision, execute it, and learn from the outcome.

Analytics turns data into a question worth answering

Consider revenue operations. A CRM stores leads, opportunities, stages, activity, and quotas. The useful analysis is often above that layer: pipeline coverage by segment, conversion rates between stages, typical cycle times, and the difference between a healthy-looking pipeline and one that is unlikely to close in time.

Those views support real decisions. Is a territory short on coverage? Is a segment converting differently? Does the organization need more sales capacity, a different territory design, or a different target? The implementation might be straightforward cohort analysis or a forecast based on historical data. It does not need to be generative AI to be valuable.

Product analytics has a similar trap. A dashboard can show that activation or retention moved. An experiment, with a clear metric and a credible comparison group, helps answer whether a product change caused the movement. That difference matters when deciding what to ship to everyone.

The system of record supplies the events. The analytical layer makes them useful for a decision.

Optimization makes tradeoffs explicit

Some of the highest-value software is not about generating text or predicting a label. It is about choosing among competing, constrained options.

A logistics application might store shipments, vehicles, drivers, stops, service windows, and delivery status. The difficult work is assigning loads and planning routes while respecting vehicle capacity, driver-hours rules, pickup timing, delivery promises, and cost. This is an optimization problem. There may be no chat interface and no LLM involved.

Inventory is another familiar example. A basic app can show that stock is low. A more useful system estimates demand and lead-time uncertainty, accounts for storage limits and the differing cost of stockouts, and recommends what to order, from whom, and when. It makes the tradeoff visible instead of leaving a person to infer it from a table of quantities.

Workforce scheduling has the same shape. Employee records, certifications, availability, and shifts are CRUD. Building a workable schedule means balancing coverage, labor rules, preferences, fairness, qualifications, and overtime. The value is a schedule that an operation can actually run.

Operations research, forecasting, and constraint solving have been doing this work for a long time. Cheaper application development does not replace them. It makes it more feasible to spend effort on the part that changes the outcome.

Reliable execution is part of the product

A recommendation that cannot be acted on is just another dashboard.

Useful systems need to connect to the places where work happens, create or route the next task, explain why an item was prioritized, and handle cases that do not fit the normal path. They need audit trails where the decision matters. They need safe fallbacks and a clear way for a person to take over.

This is especially important when an LLM is involved. A model can help read an invoice, summarize a case, or classify an incoming request. It should not turn uncertainty into an invisible decision. The system needs confidence thresholds, validation, exception queues, permissions, and a way to correct mistakes. Those are not incidental implementation details. They are what make automation usable in a real operation.

The same is true for non-AI logic. A routing optimizer needs to expose the constraints it used. A forecast needs to show when its assumptions no longer resemble reality. An approval workflow needs a path for the unusual case. Dependability is not separate from the product; it is part of the value proposition.

Start with the bottleneck, not the screen

For builders, the practical implication is simple: start with the recurring decision or bottleneck.

Ask what people are repeatedly deciding, what information they have to assemble to decide it, which constraints they are balancing, and what happens after they make the call. Then work backward to the data, integrations, analysis, and interface required.

That approach may still produce a CRUD application. Most useful systems need records. But the record pages become infrastructure for a more specific outcome: fewer missed renewals, better route utilization, more disciplined purchasing, faster resolution, or a decision that used to require several people and a spreadsheet.

LLMs have made the CRUD shell cheaper to produce. That should be good news. It lets teams spend more of their attention on the work that has always been difficult: understanding an operation well enough to remove delays, make tradeoffs explicit, and reliably move work forward.