DEV Community: dhooooooh

From AI Demo to Production Budget

dhooooooh — Tue, 06 Oct 2026 15:38:50 +0000

An agent keeps spending when a task goes wrong. A failed tool call can trigger another model call; a retry adds to the bill even if the user eventually gives up. Startup credits can cover some of that expense, but relying on them requires checking what the company would actually receive and when it would have to start paying.

Before applying, I would trace the offer to the vendor's program page and read the eligibility and billing terms. I used Sourcey to find dated records and their original sources for the three examples below, then checked the vendor pages on 6 October 2026. The question is whether the published offer supports the budget being proposed.

The year-two bill

Google's AI startup offer lists up to $250,000 in first-year credits, followed by 20% coverage up to another $100,000 in year two (observed 4 August 2026). Google's benefits page confirms the amounts and specifies 100% coverage in year one. Its footnotes also say acceptance is discretionary. Google's models, including Gemini and Gemma, are covered; directly billed third-party models are excluded.

Suppose an application incurs $10,000 a month in eligible Google Cloud charges and $2,000 in model API charges billed directly by a separate provider. This is a hypothetical budget, with taxes excluded. Assume approval for the relevant benefits, enough credit remaining, and no cap reached.

Monthly budget at the same workload	Gross charges	Credit offset	Cash payment
Year one, with 100% eligible coverage	$12,000	$10,000	$2,000
Year two, with 20% eligible coverage	$12,000	$2,000	$10,000
After the applicable credits end	$12,000	$0	$12,000

The second-year offset is $10,000 multiplied by 20%. That leaves an $8,000 cloud payment plus the $2,000 external API bill. Monthly cash spending rises fivefold at exactly the same workload. A forecast built around the first-year payment would understate the second-year cash requirement by $8,000 a month.

During the pilot, I would divide total gross charges, including failed attempts, by successfully completed tasks. That gives the team a cost measure it can compare across changes to the agent. Keep the credit offset separate: a larger award can lower the cash payment while the cost of completing a task stays unchanged.

Baseten's AI Startup Program separates up to $25,000 for Dedicated Inference or Training from up to $2,500 for Model APIs (observed 1 August 2026). The program page confirms those categories. Eligible companies must have AI at the core of the product, be at Seed through Series A, be less than five years old, and have received no previous Baseten credits.

For an application using Model APIs, $2,500 is the relevant published ceiling. The page gives no basis for budgeting a transferable $27,500 pool. Moving to dedicated inference to pursue the larger amount would change the deployment plan: the team would need to test performance and utilization, then compare the unsubsidized cost. I would resolve that choice before applying, so the requested credit category matches the service the product will use.

When the application guide changes

AWS Activate Portfolio lists up to $200,000 for pre-Series B startups with an Activate Provider Org ID (observed 4 August 2026). An application note in the linked record, reviewed on 5 August, reports different ceilings on two AWS pages: $200,000 on the credits page and $100,000 in the application guide.

On 6 October, the credits page and application guide both advertised a Portfolio ceiling of $200,000. The guide still uses $100,000 in examples of specific packages and incremental awards, rather than as the overall ceiling. The older note pointed to a possible problem; checking the original pages showed that its warning was no longer current.

There is still a package to confirm. I would get the Org ID from the affiliated provider, ask which award it makes available, and use the application linked from AWS's own program page. The $200,000 ceiling alone does not establish what a particular applicant will receive.

The credit terms, updated on 24 September 2026, restrict coverage to designated eligible services, exclude taxes, and leave excess usage payable. Once an award arrives, its expiration date belongs in the forecast alongside its balance. The forecast should stop applying the offset when the award's coverage period ends, even if some balance remains.

Before committing to a production launch, I would attach the approved amount, covered services, coverage rate, and expiry to the corresponding budget lines. Unapproved credits would appear only in a separate scenario. The launch review would use the pilot's gross cost per completed task and the cash required after the promotion ends, including the full $12,000 monthly bill in the hypothetical Google example.

The Agent’s Last Mile

dhooooooh — Thu, 17 Sep 2026 18:05:15 +0000

Large language models have become remarkably capable.

With enough parameters, data, and training, they can develop abilities that are difficult to predict from smaller systems. They can write software, interpret documents, use tools, plan multi-step tasks, and adapt to changing instructions. Watching a strong agent solve a complex problem from beginning to end can feel like a qualitative leap.

The demo is impressive.

Production is different.

The difficult part is no longer proving that an agent can complete a task once. The difficult part is making sure it behaves acceptably when the context is long, the tools are unreliable, the instructions are incomplete, and nobody is watching every step.

That is the agent’s last mile.

Capability is not the same as trust

An agent can be intelligent enough to produce a useful answer without being reliable enough to control a real workflow.

This distinction is easy to miss because successful demonstrations compress uncertainty. They usually have a clear goal, a clean environment, relevant context, working tools, and a human who knows when to intervene.

Production systems rarely have those conditions.

A customer support agent may receive an incomplete request. A coding agent may inherit a repository with contradictory documentation. A research agent may collect sources that disagree with each other. An operations agent may encounter a timeout after the external system has already completed the action.

In each case, the model may still produce a fluent response. Fluency is not evidence that the underlying state is correct.

The agent can sound certain while its view of the world is incomplete.

Long context creates a new reliability problem

Long context is powerful because it allows an agent to retain more instructions, documents, conversation history, and tool results.

But more context does not automatically produce more reliable reasoning.

A long context can contain stale facts, duplicated information, conflicting instructions, low-quality retrievals, intermediate mistakes, and assumptions that were never validated. The model must decide which parts matter, which parts are authoritative, and which parts should be ignored.

That is a difficult judgment.

When the context grows, the agent may also lose track of the origin of a claim. A suggestion from an earlier step can start to look like a confirmed fact. A failed tool call can be treated as if it succeeded. A speculative interpretation can become part of the working memory and influence every later decision.

The result is not always an obvious hallucination. More often, it is a plausible continuation built on a weak assumption.

This is what makes long-context failures dangerous. They may not look like failures until the output reaches the real world.

The last mile is a systems problem

The last mile of an agent is not solved by model intelligence alone.

It includes everything around the model:

How tasks are scoped.
Which tools the agent is allowed to call.
What happens when a tool times out.
How state is stored between steps.
How outputs are validated.
When the system pauses for approval.
How errors are logged.
Whether an action can be reversed.
How a human can reconstruct what happened.

A highly capable model inside a weak system can still create unreliable outcomes.

In fact, a more capable model may increase the operational risk because people are more willing to trust it. When an agent performs well most of the time, its occasional failures become easier to overlook.

The goal is not to make the agent appear perfect. The goal is to make its failures bounded, visible, and recoverable.

Boring safeguards are still valuable

The most important production techniques are often less exciting than the model itself.

A system should verify that an action actually happened before reporting completion. If an agent creates a ticket, it should receive a confirmed ticket identifier. If it changes a file, the system should verify the file state. If it sends a request to an external service, it should distinguish between accepted, completed, failed, and unknown.

“Done” should be a state backed by evidence.

Actions should also be divided by risk. Reading information, drafting a response, changing a local setting, deleting data, and sending an external message should not all require the same level of autonomy.

Low-risk actions can run automatically. High-impact actions should require stronger validation, explicit approval, or both.

Other safeguards are equally unglamorous but important:

Use strict schemas for tool inputs and outputs.
Make operations idempotent whenever possible.
Add timeouts and bounded retries.
Save checkpoints before meaningful state changes.
Keep permissions narrow.
Separate planning from execution.
Use deterministic validators for critical conditions.
Escalate when the system cannot establish the current state.
Preserve an audit trail of decisions and tool results.

These measures do not make the model smarter. They make the surrounding system more honest about what the model knows and what it does not know.

A reliable agent needs a floor

Every production agent should have a minimum behavioral contract.

The contract does not need to promise perfect accuracy. It needs to define what the system will never quietly do.

For example:

It must not claim an action succeeded without confirmation.
It must not invent missing information to complete a workflow.
It must not silently continue after a critical tool failure.
It must not perform irreversible actions without the required approval.
It must preserve enough state for a human to recover the task.
It must clearly distinguish facts, assumptions, and estimates.
It must stop when the current state cannot be trusted.

These expectations are a reliability floor.

Without them, every team ends up relying on personal vigilance. Someone notices a strange result, someone checks the logs, someone manually fixes the state, and everyone hopes the same issue does not happen again.

That does not scale.

Human involvement should be designed, not improvised

Human oversight is sometimes presented as a temporary weakness that better models will eventually remove.

For many workflows, that is the wrong framing.

The better question is where human judgment has the highest value. A person may not need to approve every search query or formatting decision. They may need to approve a financial transfer, a production deployment, a customer-facing commitment, or a destructive change.

Good systems place human attention at the points where mistakes are expensive and difficult to reverse.

The agent should do the exploration, preparation, comparison, and repetitive work. The human should retain control over ambiguous decisions, high-impact actions, and exceptions that fall outside the system’s tested boundaries.

This is not a failure of autonomy. It is a sensible allocation of responsibility.

Production readiness means bounded risk

We should stop treating production readiness as a binary question: either an agent can be trusted completely, or it cannot be used.

Real systems are rarely built that way.

A production-ready agent may still make mistakes. The difference is that its mistakes are constrained by permissions, detected by checks, contained by boundaries, and recoverable through known procedures.

That standard is more realistic and more useful than demanding 100 percent trust.

The agent does not need to be right about everything. It needs to be reliable about what it reports, cautious about what it changes, and transparent about what remains uncertain.

The last mile is where trust is built

The emergence of new capabilities from large language models is genuinely impressive. Agents can now perform tasks that once required several specialized tools and a human coordinating every step.

But capability gets attention. Reliability earns adoption.

The last mile is the work of turning a powerful model into a dependable system. It involves conservative defaults, explicit boundaries, validation, fallbacks, observability, and clear expectations.

These safeguards may look boring beside a model that can reason across a million-token context or operate a complex application. They are still what allows that capability to enter production without making every user a full-time supervisor.

The future of agents will not be decided only by how much they can do.

It will also be decided by how safely they behave when they are wrong.

Computer Use is All You Need

dhooooooh — Thu, 17 Sep 2026 17:51:35 +0000

There is a frustrating gap between having an idea and being able to make it.

You may imagine a room, a character, a product, or an entire world. You may know how it should feel: warm, quiet, futuristic, playful, strange, or cinematic. But turning that idea into a 3D scene can require years of practice with interfaces, shortcuts, modifiers, lighting systems, materials, cameras, rendering, and file formats.

For many creators, the problem is not a lack of imagination. It is the cost of operating the tools.

This is why the recent work with GPT-6 Astra and Blender is so interesting. The important change is not simply that an AI model can generate a mesh. The important change is that the model can participate in a longer creative loop: understand an intention, operate the software, inspect the result, notice problems, and continue refining the work.

Computer use is not literally all you need. But it may be the missing bridge between an idea and its first convincing form.

The real bottleneck is tool friction

Traditional 3D workflows often force creators to learn the software before they can explore the idea.

Before building a simple room, a beginner may need to understand object creation, transforms, collections, materials, lights, cameras, render settings, and the logic of the 3D viewport. None of these skills are useless. They are part of becoming fluent with the medium. But they can delay the creative process for weeks or months.

A person with a strong design idea may give up before producing a single useful prototype.

Computer use changes the starting point. Instead of asking the creator to memorize every operation first, the AI can translate a high-level brief into a sequence of concrete actions. The creator can begin with something closer to the way they already think:

“Create a small reading pavilion surrounded by trees. Use warm timber, soft afternoon light, and a camera angle that makes the space feel calm and private.”

That sentence is not a Blender tutorial. It is an artistic direction. The model’s job is to turn that direction into a scene that can be opened, inspected, and changed.

What GPT-6 Astra demonstrates in Blender

The recent Astra and Blender workflow shows the value of combining reasoning with computer use.

A project can begin with a short description of a house or environment. The model can create an editable Blender scene, including architecture, furniture, materials, lights, and cameras. It can then work through successive versions instead of stopping after the first output.

That distinction matters.

A one-shot generation system gives you an image. An interactive computer-use workflow gives you a place to continue working.

In the official architectural visualization example, the scene evolved through several stages. The work moved from an initial pavilion to a larger floor plan, then to furnished rooms, detailed objects, warmer lighting, camera tours, and an Unreal Engine walkthrough. The model used scripts, preview renders, and visual inspection to identify issues such as awkward compositions, intersecting objects, and shading problems.

This is closer to working with a junior technical artist who can also explain the process. The creator can say:

Make the room feel more lived in.
Keep the current version as a backup.
Show me a floor plan before rebuilding the house.
Move the camera away from the blank wall.
Preserve the materials but make the lighting quieter.

The model turns those instructions into operations inside the tool.

AI as a temporary tool expert

For creators who lack software experience, this creates a powerful transition period.

The AI becomes a temporary tool expert. It can handle the first layer of technical friction while the creator develops judgment through practice.

A beginner may not know the difference between a bevel modifier and manually editing an edge. They may not know why a material looks flat, why a camera feels wrong, or why a model breaks when viewed from another angle. By working alongside the AI, they can ask those questions at the exact moment they become relevant.

The learning process becomes contextual.

Instead of studying every feature in Blender before making anything, the creator learns the features that serve the current idea. A question about a sofa can lead to lessons about shape, topology, normals, fabric, and lighting. A question about a room can introduce scale, composition, camera lenses, and spatial flow.

The tool stops being a gatekeeper and becomes part of the conversation.

The creator still makes the important decisions

This does not mean that AI eliminates the need for artistic judgment.

The model can create a plausible object, but plausibility is not the same as meaning. It can add furniture, but it does not automatically know which object carries the emotional center of a room. It can improve a render, but it cannot decide whether the scene should feel comforting or unsettling unless the creator gives it that direction.

The human still decides:

What is worth making.
What the work should communicate.
Which details matter.
When a result feels right.
Which imperfections should remain.

AI reduces the cost of trying an idea. It does not remove the responsibility of choosing one.

This is especially important in 3D work because a beautiful render can hide structural problems. Geometry may intersect. Proportions may be wrong. Materials may look convincing from one angle and fail from another. A model can inspect a scene and catch many issues, but review is still necessary. A generated visualization is not automatically a production-ready asset, an engineering document, or a finished piece of art.

From tool learning to idea expansion

The greatest benefit may be psychological.

When the cost of experimentation falls, creators become more willing to explore ideas that would previously have seemed impractical. A person who once thought, “I would need to learn Blender for six months before I could try this,” can now begin with a rough scene in an afternoon.

That first scene may be imperfect. It may even be technically messy. But it gives the idea a physical form. Once the idea exists, the creator can react to it.

Maybe the roof is too heavy. Maybe the room needs a stronger focal point. Maybe the character’s silhouette is wrong. These are useful discoveries. They are much easier to make when there is something visible to critique.

This is where AI becomes an accelerator. It compresses the distance between imagination and feedback.

Computer use is the beginning of a new creative loop

The future of creative software may not be defined by replacing interfaces with chat. It may be defined by combining conversation, direct manipulation, code, previews, and judgment in one continuous loop.

The creator describes an intention.

The AI builds a first version.

The creator reacts to what appears.

The AI changes the scene.

The creator develops a sharper eye.

The work continues.

For experienced artists, this can remove repetitive technical work and make complex experimentation faster. For beginners, it can make professional tools approachable before they have mastered every command. For people who have always had ideas but rarely had the tools to express them, the effect could be even larger.

The most important achievement is not that AI can operate Blender.

It is that more people can finally begin.

Computer use may not be all you need. But for a creator standing in front of a powerful tool they do not yet understand, it may be enough to turn an idea into a direction, a direction into a scene, and a scene into something worth pursuing.

Code Judgment in the AI Era

dhooooooh — Thu, 17 Sep 2026 17:42:06 +0000

For a long time, programming education was tied to production: learn the syntax, ship the feature, fix the bug, and move on. AI assistants are changing that loop. They can generate code, tests, configuration, and refactors in seconds.

What they do not remove is the need for engineering judgment.

In fact, the more code we can generate, the more important it becomes to evaluate code well. A fast answer is not necessarily a correct answer. A clean-looking diff can still violate an invariant, hide a security problem, create an operational burden, or solve the wrong problem entirely.

The scarce skill is moving from “Can I produce code?” to “Can I tell whether this code deserves to exist?”

That ability does not come from reading a few prompt recipes. It develops through continuous learning and reflection, and both depend on hands-on practice.

Start with the foundations

A programmer who understands data structures, control flow, state, networking, databases, and operating-system behavior has a better chance of recognizing when generated code is suspicious.

Foundational knowledge is not a museum piece that becomes irrelevant when tools improve. It is the mental model used to inspect the tool's output. Without it, evaluation becomes pattern matching: the code looks familiar, so it feels safe.

Practice is how judgment becomes concrete

The fastest way to improve code review is still to build things.

Write the small version yourself. Trace the failure. Measure the slow path. Read the logs. Change one assumption and see what breaks. Then compare your implementation with the generated alternative.

This is not an argument for refusing assistance. It is an argument for using assistance after you have enough contact with the problem to recognize its shape. Hands-on work gives you the reference points that make review meaningful.

Reflection turns experience into a reusable skill

Practice alone is not enough. Repeating the same mistake without examining it only makes the mistake familiar.

After a feature ships, ask:

What assumption did the design depend on?
Which failure mode did we not test?
What made the code easy or hard to change?
What did the review catch, and what did it miss?
Which part of the implementation would be difficult to explain six months from now?

These questions turn individual incidents into engineering knowledge. They also improve the way we prompt and supervise AI tools, because better questions produce better intermediate work.

High-level concepts still require low-level contact

Architecture, reliability, security, and maintainability are not separate from implementation. They are judgments about how implementation behaves over time.

You cannot evaluate an abstraction without understanding what it hides. You cannot assess a retry policy without thinking about duplicate effects. You cannot review a caching layer without knowing what can become stale. You cannot judge a test suite by its line count alone.

AI can suggest designs at a high level, but the engineer remains responsible for connecting those designs to real behavior.

A better division of labor

I see a useful division of labor emerging:

Let AI handle repetition, exploration, scaffolding, and alternative implementations.
Let people define constraints, choose tradeoffs, inspect evidence, and own the consequences.
Use hands-on practice to keep human judgment connected to how systems actually behave.

This is why foundational programming practice still matters, even when programmers no longer write every line by hand. The goal of practice is not to compete with a code generator on typing speed. It is to build the judgment needed to direct, challenge, and correct one.

Delivery is the visible part of software work. Understanding is what makes delivery trustworthy.

The engineers who thrive in an AI-assisted environment will not be the ones who avoid tools, nor the ones who accept every generated answer. They will be the ones who keep learning, keep building, and keep reflecting until they can recognize quality in code they did not personally write.