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.

I, like I imagine most people on here, dream about making money while I sleep. And not the boring “market goes up” money, but something sexier: uncapped alpha because you figured something out that no one else has.

With that idea rattling around my brain, I listened to an Odd Lots episode about a group of traders consistently winning in Kalshi prediction markets.

Naturally, since “coding is solved,” I had to give building a Kalshi bot a shot.

Tl;dr: I traded around $500 and ended up about even.

That is not a tragedy. It is just a much more useful result than the version where I tell you I had an AI build a money printer over a weekend.

Picking a market

Kalshi has a lot of markets. I wanted something with good public data and a quick resolution cycle, mostly because I did not want to wait months to find out whether my very sophisticated robot had learned anything.

Weather fit pretty well. There is plenty of publicly available weather data, and the markets settle quickly enough to get feedback. So down the rabbit hole Codex and I went, building a bot to trade weather events.

The initial setup was honestly pretty impressive. Codex got the plumbing in place fast: risk controls, backtesting tools, and a slick dashboard. The kind of stuff that used to be enough work to make a small experiment feel like a real project before you even had a hypothesis worth testing.

Now it was a real project. Which meant it was time to find a real strategy.

The part nobody can code for you

This is where I got stuck, with Codex looking at me with lost-puppy eyes.

We tried a few things:

• ML models to predict price movement
• a market-making strategy in backtests
• fast-following momentum trades

All of them managed to make approximately $0.

This is an important distinction that is easy to lose when the tooling is this good. Building the system and finding the edge are different problems.

The system needs data collection, order handling, position limits, monitoring, a way to replay decisions, and enough guardrails that a bad assumption does not become an expensive bad assumption. Codex was enormously helpful with that work. It makes it much easier to turn an idea into something you can actually test.

But an edge is the thing that makes the test worth running. It is a reason to believe your estimate is better than the market’s after accounting for fees, execution, timing, and everyone else who has access to the same obvious public data. “Use the weather forecast” is not really an edge when the people setting prices and trading against you can also use the weather forecast.

Backtests are very polite

The backtests were useful, but they also have a way of being polite. A strategy can look reasonable until you remember that historical data does not necessarily capture the price you could have traded at, how quickly the market moved, or whether the market had enough liquidity when you wanted it.

And then there is the more basic problem: a model that predicts something about the weather is not automatically a model that predicts a market price. The trade only works if the model finds information the price has not already absorbed, or if it identifies a repeatable way the market is mispricing that information.

I did not find that.

Trading about $500 and ending roughly flat is a small sample, not a statement about Kalshi, weather markets, or prediction markets in general. It was enough, though, to kill the idea that the hard part was connecting some APIs and writing a model.

Codex gives you leverage, not special sauce

I came away more convinced that Codex and friends give you enormous leverage if you “know what you’re doing”™.

They can get you from blank screen to a functioning experiment very quickly. They can help build the boring but necessary pieces that make it safe to test a hypothesis. They can make it cheaper to be wrong.

What they cannot reliably do is hand you the special sauce: an insight that is not already obvious, already priced in, or possibly sitting somewhere in the training data. You still need to decide what is worth measuring, why the market might be wrong, and what would prove you wrong.

That may sound less exciting than an autonomous trading bot. But it is probably the actual opportunity. If it is suddenly cheap to build and test an idea, then the bottleneck moves back to having a good idea.

Next up: time to try designing my own peptide with Codex.

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 big thing happened the other week: Anthropic helped launch a $1.5 billion AI services company. OpenAI is also deploying enterprise agents with its own team and selected systems integrators.

$1.5 billion is not chump change. These companies are thinking about where the market is going, and they have realized that a capable model is not the only thing that matters. The implementation around the model is equally important.

Ode with Anthropic was announced in July as a standalone AI services firm. A week later, OpenAI introduced Presence, an enterprise deployment model that starts with a specific workflow and includes system access, policies, approvals, testing, and ongoing support.

While massive companies may be able to work directly with OpenAI or Anthropic, or at least afford to, most of us do not have that luxury. What is clear is that getting an impressive demo or proof of concept is not the hard part. The hard part is taking it to the next step, where the complex edge cases, data, users, and exceptions show up.

Small choices can turn into bigger problems

We were brought into an AI project where a fairly simple decision became a bigger problem later: the application was not locked to a specific model and release version.

At first, the AI application looked fine. It produced structured output and the rest of the automation could use it. As the provider changed the model’s behavior over time, the format changed and it began classifying some inputs differently than it had when the application was originally built. The output still looked reasonable to a person, but the rest of the automation relied on those expected formats and classifications, so it became unreliable.

This is easy to miss because the AI still appears to work. The problem only shows up when another system expects the output to be consistent, and there is no test in place to catch the change before it becomes an issue.

A model should be treated like any other production dependency. Pin the model and version where possible, keep a set of real test cases, test changes before they go live, and have a plan for upgrades. It is not exciting work, but it keeps a useful application from becoming unreliable over time.

A demo is not a workflow

We have seen the same thing with agents. An agent can look great in a demo because it can answer questions, summarize documents, or draft an action. Once it is used in a real business process, though, it needs to know where the right data lives, what to do when data is missing, when it should ask a person for help, who can approve an action, and what needs to be recorded later.

If that work is not planned ahead of time, the agent usually does one of two things. It takes actions it should not take, or it hands so much back to people that it does not save much time. In both cases, the model may be fine. The larger workflow was not thought through.

Building an AI agent is not the same as building a working process. The agent needs clear boundaries, the right access, a way to handle exceptions, and someone responsible for it when the process changes.

What good implementation looks like

A good implementation partner does more than connect a model to an API and call it innovation. They should help a company decide which workflow is worth changing, where the right data is, what the system is allowed to do, when people need to step in, and how to tell if the work is actually improving the process.

They should also be asking what happens when the model changes, the company changes a policy, or the data and workflow change. Those are normal parts of operating a business, and the AI application needs to keep up with them.

Sometimes an LLM is the right tool. Other times, ordinary software, better data integration, or a rules-based process makes more sense. Someone who has worked on these projects should know the difference.

AI makes it much faster to go from an idea to something that works, and that is valuable. But the problems with a weak workflow, bad permissions, unreliable output, or missing monitoring often do not show up until after the demo works. That is why implementation experience matters.

If an AI initiative is stuck between an impressive demo and something useful in production, do not assume it needs a bigger model or another tool. It may need a clearer workflow and people who know where these systems tend to fail.

HIPAA-compliant LLM access really is not that hard.

I came to this conclusion after going fairly far down the wrong path.

It started with Kimi K3 and GLM-5.2. These open-weight models are getting close enough to proprietary frontier models that they need to be taken seriously.

My first thought was that healthcare companies could run models like these themselves and keep patient data inside their own environment.

That is an appealing idea. No protected health information sent to a model API. No dependence on a third-party inference service. A company controls the hardware, the model weights, the network, and the logs.

Then I looked at the hardware.

These are not small models. Kimi K3 has 2.8 trillion parameters, and the vLLM project describes an eight-NVIDIA-B300 deployment as its easiest way to run the model. GLM-5.2 has 753 billion parameters; NVIDIA’s current quantized release targets Blackwell hardware and supports runtimes such as vLLM and SGLang.

The exact footprint depends on the precision, context length, concurrency, and serving stack. That is the point. An organization considering this path needs to budget for more than a GPU server: high-speed GPU interconnects, storage for weights and logs, redundant infrastructure, monitoring, patching, model serving, and someone who can operate all of it. For serious production traffic, that can become a large infrastructure project quickly.

That does not make local inference impossible. For the right workload, volume, and organization, it may be a reasonable choice.

But it makes “we should run our own frontier model because HIPAA” a much more expensive sentence.

The local-model path has more than one vendor

The next option is a GPU cloud. Some providers will sign a business associate agreement (BAA), which is a necessary part of handling protected health information with a service provider.

But the details matter.

A BAA may cover specific compute, storage, and logging services rather than everything the vendor offers. The organization still needs to understand where prompts, responses, embeddings, backups, traces, and support data go. “The GPU is covered” is not the same as “the whole system is covered.”

That is real diligence, but it is also not unique to open models.

Then there is the more obvious question: what about the clouds most healthcare companies already use?

AWS lists Amazon Bedrock as HIPAA eligible. Microsoft offers a BAA for in-scope Azure services, and its Azure AI Foundry documentation describes its HIPAA compliance offering. Google supports HIPAA workloads through Vertex AI.

So a healthcare company can already get managed access to capable models from AWS, Microsoft, or Google without buying a GPU rack or operating an open-weight model.

The model is available. The work is deciding what to do with it.

HIPAA is a system property

A BAA does not make an application safe by itself. Neither does a local GPU server.

The company still needs appropriate access controls, encryption, audit logging, retention rules, and an architecture that keeps PHI inside covered services. It needs to know which users can ask which questions, which records the system can retrieve for them, and whether sensitive data is leaking into an observability tool or a debugging log.

Those are not optional details around the LLM. They are the system.

A useful healthcare assistant also needs to be more than a chat box pointed at a model. An end user should see an authenticated application that retrieves only the records they are allowed to access, shows where an answer came from, and makes it easy to correct or escalate an uncertain result.

Take prior authorization. An LLM could help assemble information from a patient record into a draft packet. That may save a person time. But somebody still needs to decide what information is relevant, validate that the draft is correct, submit it through the appropriate channel, and handle the exception when the case does not fit the usual pattern.

The same is true for chart summarization, intake, coding support, patient-message triage, and internal policy search. The question is not just whether a model can produce a plausible answer. It is whether the workflow makes a person faster without making a mistake harder to catch.

Start with the workflow

I suspect plenty of healthcare companies are treating HIPAA as the blocker when the larger issue is that they have not identified a narrow enough problem worth solving.

“Give our staff an LLM” is not a workflow.

“Help the prior-authorization team find the relevant clinical history, draft a packet, and flag missing information for review” is much closer. It gives the team something to evaluate: time saved, completeness, error rate, review burden, and the cases where the system should stop and ask for help.

Once that workflow is clear, the infrastructure decision becomes more practical.

A managed model service may be the right answer if it fits the company’s covered environment and the team wants to focus on the application. A locally hosted open model may be the right answer when the organization has unusually strict control requirements, enough sustained volume to justify the infrastructure, or a reason to operate the model as a core capability.

Neither option removes the need for careful design. Both can be part of a HIPAA-compliant system. Both can also be used carelessly.

The LLM is not really the hard part.

The hard part is picking a useful workflow, connecting the right data, evaluating the output, and deciding where a human needs to remain involved.

What healthcare workflow would you be comfortable giving an LLM access to today?