DEV Community: VastPace

AI Image Editing with Prompts: A Practical Look at EzPic

VastPace — Thu, 17 Sep 2026 08:01:55 +0000

A product photo can be perfectly usable and still look wrong on your landing page.
The background clashes with your color palette. The lighting feels too cold. You want to explore another visual direction while keeping the actual product recognizable.
These are useful tasks for evaluating a prompt-based image editor: specific changes to an image you already understand.
I’m the developer of EzPic, so this is a look at its workflow and trade-offs from the builder’s perspective. The question I want to explore is where prompt-based editing can fit into everyday creative work.
Starting with an existing image
EzPic supports both text-to-image generation and editing with a reference image.
For an existing photo, the workflow is straightforward:

Upload a JPEG, PNG, or WebP.
Describe the changes you want.
Choose an available image model and its supported settings.
Review the credit cost before generating.
Compare the result with your source image. For a first attempt, I’d keep the request narrow. A background change gives you something concrete to evaluate. For example: Replace the background with a warm, sunlit studio and a light beige surface. Keep the bottle’s shape, label, color, and camera angle unchanged. Add a soft, realistic contact shadow beneath it.

That prompt defines both the intended edit and the details that should survive it.
When reviewing the output, check those details closely. Is the label still readable? Has the product shape changed? Does the shadow make sense? A convincing overall image can still contain a small error that makes it unsuitable for publication.
Model choice and visible costs
EzPic brings Nano Banana, GPT Image, and Seedream options into one workspace. Available output settings and credit requirements vary by model.
The useful part of that arrangement is being able to make the choice alongside the image and prompt you’re working with. You can review the supported settings and the credit amount before confirming a generation.
For evaluating any image tool, I’d consider the cost of getting a usable result. A more expensive setting may be worth trying for a demanding image, but the final decision should come from inspecting the output.
It also helps to budget for a few iterations. Your first prompt may reveal that you need to be more specific about composition, lighting, or the details you want preserved.
Privacy matters for unfinished work
Draft campaign images, product photos, and unpublished designs often need to stay private.
EzPic keeps uploaded images and generated results out of public galleries. Its privacy policy describes processing and retention, including the external services involved in producing an image.
That is worth checking before uploading client work or other sensitive material, whichever image tool you use.
What does it cost to try?
At the time of writing, registered Free accounts receive 25 credits per month. A Nano Banana 2 Lite 1K generation costs 5 credits, giving you room for up to five generations at that setting.
The Pro monthly plan is $19 for 700 credits. Other models and settings can use more credits, so the number of images depends on your selections.
There is also a conditional guest trial when the sponsored queue is available. Guest results are watermarked and temporary.
The current options are listed on the pricing page.
Where I’d use it—and where I’d be careful
EzPic’s workflow is suited to exploring backgrounds, lighting, colors, and visual styles. For a developer preparing a landing page or a creator adapting an existing image, those are practical starting points.
Exact brand details deserve closer review. Text, logos, geometry, and small product features can change during generation. A request to preserve something is an instruction to the model, not a guarantee.
For work that needs precise, repeatable pixel-level adjustments, a conventional editor remains useful. Prompt-based editing can help you explore a direction, with manual editing handling the final details where necessary.
If you want to evaluate EzPic, start with one image you know well and one clearly defined change. Compare the result against your original brief before trying a more ambitious edit.
That small test will tell you much more about whether it fits your workflow than a gallery of impressive images.

The Most Shocking Night in AI: An RTX 5090 Can Now Run Opus 4.6-Level Intelligence

VastPace — Fri, 14 Aug 2026 17:06:04 +0000

Something genuinely terrifying is happening quietly.
Qwen3.8-27B is already outperforming—or coming extremely close to—Claude Opus 4.6 Max across most capabilities.
And Qwen3.8-27B has only 27 billion parameters.
The official FP8 version can run smoothly on a single RTX 5090—a consumer gaming GPU that anyone can buy.
If you have a MacBook or Mac Studio with a large amount of unified memory, running it locally is even less of a problem.
This is insane. And I’m genuinely excited.
Let me translate what this actually means:
Starting today, a small model that you can deploy on your own computer with a single gaming GPU can deliver intelligence approaching Claude Opus 4.6—the model that stood at the top of the world just six months ago.
Whether you’re writing code or using it to power OpenClaw, this level of intelligence can now live entirely on your own machine.
Why am I specifically comparing it with Opus 4.6?
Because six months ago, Claude Opus 4.6 felt almost godlike.
In VC circles, people described the arrival of Opus 4.6 as:
“The water has finally boiled.”
For many developers, Opus 4.6 marked the moment when AI coding fundamentally changed.
Before that, AI was still mostly a programming assistant that required constant direction.
You described a small task.
The model generated some code.
You ran it, checked it, fixed problems, and then told the model what to do next.
Humans still had to break down the problem and supervise almost every step.
Opus 4.6 changed that workflow.
You could give the model a complete objective, and it could understand the goal, create a plan, execute multiple steps continuously, debug problems along the way, and keep working until it delivered the final result—while still maintaining surprisingly high code quality.
Developers no longer had to watch every single step.
That was also around the point when the old style of Vibe Coding—constant back-and-forth conversations, small edits, and endless trial-and-error in tools like Cursor—started to feel like a product of the previous generation.
And interestingly, this was also when OpenClaw exploded in popularity.
Around January–February 2026, people quickly realized that if you wanted to get the most out of OpenClaw, Opus 4.6 was the model to use.
Using weaker models often felt like wasting your time.
And that was only six months ago.
Now look at where we are.
At this moment, I’m willing to call this:
The Most Shocking Night in AI
Think about it.
The level of intelligence that Opus 4.6 represented six months ago can now potentially be owned by anyone, running locally and completely offline.
No cloud API required.
No sending your data to someone else’s servers.
Just your computer.
I’m done talking.
My model has already finished downloading.
Full-precision version — suitable for cards like the RTX PRO 6000:
https://www.modelscope.cn/models/Qwen/Qwen3.8-27B
FP8 version — suitable for the RTX 5090:
https://www.modelscope.cn/models/Qwen/Qwen3.8-27B-FP8

Hello DEV: I Build Practical AI Tools, Not Just AI Demos

VastPace — Tue, 04 Aug 2026 01:38:21 +0000

Over the past few years, I have built web applications, experimented with AI models, written more prompts than I would like to admit, and learned one important lesson:

Building an AI demo is easy. Building an AI product people actually use is much harder.

Hi DEV Community. I’m VastPace, a full-stack developer and independent product builder.

This is my first post here, so I want to briefly introduce myself, explain what I’m working on, and share the topics I plan to write about.

What I Build

My main focus is building practical web products with AI.

Not another chatbot wrapper.

Not a landing page connected to an API.

I’m interested in products where AI solves a specific problem inside a complete workflow.

That usually includes:

collecting and cleaning data
designing reliable prompts
choosing the right model for the task
handling retries and failures
controlling token costs
building a usable frontend
measuring whether the feature is actually useful

The AI model is only one part of the product.

The rest is still traditional software engineering: databases, queues, authentication, caching, monitoring, deployment, user experience, and a surprising number of edge cases.

The Gap Between a Demo and a Product

A demo only needs to work once.

A product needs to work repeatedly.

When building AI-powered applications, I often run into questions such as:

What happens when the model returns invalid JSON?
How should long-running tasks be retried?
Should this feature use an LLM at all?
How can I reduce API costs without reducing quality?
Which parts should be deterministic?
How do I evaluate an answer that has no single correct result?
How do I stop users from abusing an expensive generation feature?

These problems are less exciting than posting a ten-second AI demo on social media, but they are the problems that determine whether a product survives.

I want to write more about this less glamorous part of AI development.

What I’ll Share Here

My future posts will mainly cover four areas.

1. Building AI-Powered Web Applications

I’ll share practical patterns for integrating language models into real applications, including prompt design, structured output, streaming, background jobs, retries, caching, and cost control.

2. Full-Stack Engineering

I work across the stack, so I’ll also write about APIs, databases, queues, deployment, authentication, debugging, and the infrastructure behind small SaaS products.

3. Product Experiments

As an independent developer, I’m constantly testing ideas.

Some experiments work. Many do not.

I want to document both sides: how I choose an idea, build an MVP, collect feedback, and decide whether to continue or stop.

4. Open Source and Developer Tools

I enjoy exploring open-source projects and developer tools, especially tools related to automation, data collection, AI agents, and developer productivity.

When I find something useful, I’ll try to explain not only what it does, but where it fits in a real workflow.

My Current Principle

The principle guiding most of my work is simple:

Use AI where uncertainty is useful. Use code where consistency is required.

LLMs are good at interpreting messy input, generating alternatives, summarizing information, and helping users explore unclear problems.

Traditional code is better for calculations, permissions, billing, validation, and business rules that must behave consistently.

Trying to make an LLM handle everything usually creates an unreliable and expensive system.

The best AI products are often hybrid systems: part model, part deterministic software, with clear boundaries between them.

Why I Joined DEV

There is already an overwhelming amount of AI content online.

Much of it focuses on announcements, model benchmarks, and impressive demos.

I’m more interested in the engineering decisions behind working products:

what broke
what cost too much
what users misunderstood
what looked useful but was not
what finally made the product reliable

That is what I hope to contribute here.

I’m still learning, building, and changing my mind regularly. I’ll share what works, what fails, and what I would do differently next time.

Thanks for reading my first post.

See you in the next one.