DEV Community: ClickIT - DevOps and Software Development

Lovable or Replit? Yes.

ClickIT - DevOps and Software Development — Fri, 26 Jun 2026 18:32:03 +0000

Before we start I'm going to be honest because yes, I'm a bit biased towards Lovable. I think it's a great tool that can simplify a significant part of the job and for the little effort it requires it gives some pretty cool results.

That being said, it can only get you so far…

Let me set the stage: I had to put together a quick demo under a tight deadline. Fair to say time wasn’t on my side, but guess who was? Lovable. HUGE save.

I had a working UI, authentication flow, and something that actually looked like a product in a fraction of the time it would have taken otherwise. The presentation went well.

But then came the part where my team had to actually build on top of it and that was another story.

The moment the requirements got more specific the prompt-based workflow started showing its limits. Real backend behavior, more complex logic, things that needed to actually work rather than just look like they worked. IT. JUST. WASN’T.

Fixing one thing would break something else. Describing a bug in words and waiting to see if the next generation got it right is a whole different kind of frustration that I had never experienced in “normal” debugging.

I wasn’t solving the problem (or anything else really); I was hoping the description of the problem was accurate enough for someone else to do it.

That's when I started spending more time in Replit.

Replit feels like a development environment that has AI in it, rather than an AI that produces a development environment. You have the files, the terminal, the logs. When something breaks you look at what's actually happening and debug it the way you'd debug anything else. The AI helps, but you're not locked out of the code itself.

For workflows we find a similar situation. I see Lovable being great for getting non-technical people involved early. Think of a product manager or designer giving real feedback on a working prototype, without needing to read a single line of code.

Replit is where the engineering team actually lives. You can have multiple developers in the same files, shared terminals, debugging together all in real time (😮‍💨).

So after going back and forth on this longer than I should have, here's where I landed: most teams building real products will end up using both. Especially in the current vibe-coding/everything-AI stage we are in.

Lovable for the early stage (moving fast, validating ideas, getting something in front of people before you've committed to an architecture). Replit once the product needs to actually hold up; complex logic, real debugging, long-term maintenance.

The mistake is trying to pick one and make it work for everything. Either you prototype too slowly because you're in a full dev environment from day one, or you try to scale something past what a prompt-based workflow can handle. So please do us all a favor and stop wasting your energy and time.

We went deeper on this comparison in a recent video if you want the full breakdown. The short version is that the question isn't which platform is better. It's knowing which one fits where you are right now.

Have you hit that wall with Lovable yet, or found a way to push it further than I did? (If you say yes I might freak out, ok?)

WALK OF SHAME We used to call Database-Per-Tenant too expensive. We were wrong

ClickIT - DevOps and Software Development — Fri, 19 Jun 2026 16:07:23 +0000

For a long time, our default answer to "how should we structure tenant data?" was Schema-Per-Tenant. And that wasn’t really because the other options were bad, but one had a cost problem that was hard to argue around.

Database-Per-Tenant gives you the cleanest isolation possible. Each tenant lives in a completely separate database.

No shared resources. No WHERE tenant_id = clause you have to trust across every query your team writes for the next five years + a compliance story that actually holds up when someone from legal asks you to explain it.

Honestly, I think we knew all that. Yet, we kept steering people away from it because the bill for running hundreds of idle database instances actually hurt.

Serverless Postgres changed that. When compute scales to zero on idle databases, the cost model for Database-Per-Tenant looks very different for products where most tenants aren't active simultaneously. The thing we kept citing as “dealbreaker” now depends heavily on your usage patterns.

Now, where are the patterns today?

Shared Tables with Row-Level Security is still a pretty solid starting point for many teams.

RLS enforcement has moved down to the database engine level. An improvement over relying on application code to get it right every time if you ask me. It's the cheapest option to operate and the simplest to reason about early on.

The tradeoff is that you're sharing resources, and noisy neighbor problems become real as you grow.

Schema-Per-Tenant remains that middle path most teams land on. One database instance, separate namespaces per tenant, and the operational side of managing migrations across many schemas has gotten meaningfully less painful as tooling has matured.

If you're not under serious compliance pressure and Database-Per-Tenant feels like overkill, this still makes sense as default.

Database-Per-Tenant is worth revisiting if you dismissed it because of cost (Me, I did).

But it's worth considering if you're building in AI or HealthTech spaces, where the consequences of tenant data mixing aren't just a customer support problem.

In AI products, how you isolate tenant data has direct implications for what the model learns and from whom. In HealthTech, compliance makes strong isolation a requirement, full stop.

We covered a lot of this in a video we made about multi-tenancy; how core patterns haven’t changed while cost assumptions have.

If you’re currently on shared schemas: was that a deliberate choice, or just what came first?

Is it Time to Let Vercel Go?

ClickIT - DevOps and Software Development — Tue, 09 Jun 2026 21:23:20 +0000

The whole thing with security and Vercel got my team talking about how, while that can ring some alarms for teams, infrastructure tax is another real breaking point that's often overlooked.

There are good reasons why Vercel has become a default deployment platform for many modern web applications: great developer experience, easy deployments, and seamless integration with frameworks like Next.js. But as projects grow, some unforeseen challenges arise.

For example:

1. Compute costs are starting to hurt

Vercel is incredibly convenient, but that comes at a price. As traffic increases, serverless and edge workloads can become a significant part of your infrastructure budget.

For some teams, moving workloads directly to AWS means substantial savings while maintaining a similar development workflow.

2. You need more control over media delivery

As applications scale, caching strategies matter more.

If you're dealing with large amounts of media or highly customized delivery requirements, platform abstractions can sometimes make it harder to optimize performance exactly the way you want.

3. Compliance and security requirements are growing

Many startups don't think about private networking, granular IAM permissions, or specific compliance requirements until they have to.
And when that moment comes, managed platforms don’t always provide the level of control that enterprise environments need.

So... should you migrate?

Not necessarily.

For many teams, Vercel remains the right choice. The question isn't whether Vercel is good or bad, it's whether it still aligns with your current business, technical, and operational needs.

If you do decide to move, consider a gradual approach. Tools like SST can help preserve much of the developer experience while giving you greater control over your AWS infrastructure.

We put together a short video on it.

Thinking about leaving Vercel? I'll read you 👇🏼

ECS vs EKS in 2026 feels like a completely different conversation

ClickIT - DevOps and Software Development — Wed, 27 May 2026 21:03:38 +0000

For years, the ECS vs EKS debate was mostly about operational complexity.

People would usually simplify it to something like:

“ECS is easier”
“EKS gives you more control”
“Kubernetes is powerful but expensive to manage”

But honestly, in 2026 that framing feels outdated.

AWS has reduced a lot of the Kubernetes operational burden over the last few years. At the same time, ECS has continued getting better for teams that just want reliable container orchestration without adopting the entire Kubernetes ecosystem.

What’s interesting now is that the decision feels much more tied to platform design than to “how much DevOps pain can your team tolerate.”

If you’re building relatively stable APIs, internal services, or AWS-native workloads, ECS still feels incredibly efficient. You can move fast, keep infrastructure simpler, and avoid introducing layers of abstraction you may not actually need.

But once you start getting into highly dynamic systems — especially AI infrastructure, agentic platforms, or workloads that create thousands of ephemeral processes with custom networking requirements — Kubernetes starts becoming less of a preference and more of a capability requirement.

That’s where EKS starts making a lot more sense.

One thing we’ve been noticing recently is that more teams are asking:

“Do we actually need Kubernetes-level abstraction?”

And that’s probably the healthiest version of this conversation.

Because not every system needs Kubernetes.
But some systems become significantly harder without it.

We talked about this in a short podcast-style clip here if you want the quick version:

👉🏻 ECS vs EKS Comparison in 2026

Curious what other teams are choosing right now.

Are you still defaulting to Kubernetes for new platforms, or are you seeing more teams move back toward simpler orchestration models?

AI Coding Tools Need Better Boundaries, Not Better Prompts

ClickIT - DevOps and Software Development — Mon, 18 May 2026 16:41:48 +0000

One thing becoming increasingly obvious with AI-assisted development:

LLMs are great at generating code.
They’re not great at making architectural decisions.

A lot of teams are discovering the same pattern:

rapid prototyping feels amazing,
shipping gets faster,
but long-term maintainability starts degrading quietly in the background.

The problem usually isn’t the generated code itself.

It’s the lack of:

clear contracts,
deterministic workflows,
validation layers,
and shared engineering conventions before generation even starts.

Without those boundaries, AI tends to optimize for local correctness instead of system consistency.

That’s why workflows like Spec-Driven Development (SDD) are becoming more relevant as teams integrate AI deeper into production environments.

Instead of relying on increasingly complex prompts, SDD focuses on:

defining contracts first,
validating specs before implementation,
constraining generation scope,
and treating LLMs more like implementation engines than autonomous architects.

In practice, this tends to produce:

more predictable outputs,
cleaner collaboration between engineers,
and codebases that are actually maintainable months later.

We’ve been exploring this topic internally and recently put together a breakdown of how Spec-Driven Development can help create more reliable AI-assisted workflows in real-world engineering environments.

If the topic sounds interesting, here’s the discussion:

Stop "Vibe Coding" and Start Spec-Driven Development | Part 1

Curious how other teams here are approaching this shift:

Are you introducing stricter boundaries around AI-generated code?
Have specs become more important in your workflow?
Or are you still experimenting with prompting strategies first?

Feels like the industry is slowly moving from: “AI can generate code”

to: “How do we engineer systems around probabilistic generators?”

And that’s a much more interesting problem...

Are AI companies charging what they should?

ClickIT - DevOps and Software Development — Wed, 29 Apr 2026 18:03:30 +0000

It kind of feels like we've been getting away with something lately.

Building with AI right now is almost too easy.
You plug into an API, send a few prompts, and suddenly you've got something that feels production-ready.

But… are we actually paying what this costs?

Because it doesn't really feel like it.

A lot of what we're using today is heavily subsidized.
Infra is expensive. Models are expensive. And yet, the barrier to entry is still pretty low.

Which is great, until it isn't.

At some point, those costs have to show up somewhere.
And when they do, a lot of current products might start to feel… fragile.

Like, what happens if:

your token costs double?
rate limits get tighter?
the “best model” is no longer affordable at scale?

Not in a hypothetical way, in a real, your app depends on this kind of way.

I think this is something we're not talking about enough as developers.

We're moving fast (which is great), but sometimes it feels like we're building on top of pricing that won't exist in a year.

And that changes how you should think about things like:

caching
model selection
how often you actually need to hit the API
whether your product still works if costs go up

It's not just an optimization problem anymore, it's part of the design.

We put together a quick short about this if you want the 30-second version.

Curious how you're thinking about this.

Are you building with future costs in mind, or just trying to move fast and figure it out later? 🤔

FastAPI or Flask for AI APIs in 2026?

ClickIT - DevOps and Software Development — Fri, 24 Apr 2026 01:13:12 +0000

If you're building AI APIs in 2026, you’ve probably had to answer this at some point:

Do I go with FastAPI or Flask?

Not as a theoretical debate, but as a real decision that’s going to affect latency, scaling, and how painful things get in production.

We put together a quick breakdown based on what we’re seeing in actual projects:
👉🏻 here

From a practical standpoint, Flask still does what it's always done well. It's minimal, flexible, and easy to get running. If you're building a small service, internal tooling, or something that doesn't need to handle a lot of concurrent requests, it’s still a perfectly reasonable choice.

But AI workloads tend to stress your backend differently.

Once you're dealing with things like:

Concurrent inference requests
Streaming responses
Multiple external calls (LLMs, vector DBs, etc.)

You start to feel the limitations of a synchronous model pretty quickly.

That's where FastAPI starts to pull ahead.

Not just because it's “faster” in benchmarks, but because it aligns better with how modern AI systems behave:

Async by default
Built-in validation with type hints
Better performance under concurrent load

It removes a lot of the friction you’d otherwise have to solve manually.

Another thing we've noticed: teams rarely regret starting simple—but they do regret having to refactor their API layer once traffic or complexity increases.

So in practice, the decision often comes down to this:

If you're optimizing for simplicity → Flask is fine
If you're optimizing for scalability and concurrency → FastAPI is usually the safer bet

Also worth mentioning: not everything needs to be a full API. For some use cases (demos, internal tools), something like Streamlit can get you there faster.

Curious what others are running in production right now, are you sticking with Flask, moving to FastAPI, or using something else entirely? 🤔

Choosing Between GPT-5.4 and Claude Sonnet 4.6 in Real Workflows

ClickIT - DevOps and Software Development — Thu, 09 Apr 2026 20:47:51 +0000

Benchmarks tell one story.
Production tells another.

If you've been working with modern LLMs in real-world environments, you've probably noticed something:

The differences don't show up where you expect them to.

For about 80% of everyday tasks—React components, SQL queries, basic backend logic—GPT-5.4 and Claude Sonnet 4.6 perform almost identically.

But the remaining 20%? That's where things get interesting.

Here's a quick short video breakdown of what we've been seeing in production.

🧠 What actually changes in production?

When you move beyond demos and benchmarks, the evaluation criteria shift:

It's not just about correctness
It's about consistency, speed, cost, and workflow fit

Here's what we've observed after using both models in real workflows:

⚙️ GPT-5.4: Strong in Infrastructure & “Computer Use”

GPT-5.4 really shines when tasks involve:

Multi-step reasoning
Tool usage and orchestration
Infrastructure-related workflows
Deterministic outputs

It feels more reliable when:

You need structured outputs
You're chaining tasks together
You're building automation pipelines

Think: “system-oriented intelligence”

✍️ Claude Sonnet 4.6: Faster & More Human for Refactoring

Claude, on the other hand, stands out in:

Code refactoring
Readability improvements
Natural, human-like responses
Faster iteration cycles

It’s especially useful when:

You're polishing code
You want cleaner abstractions
You care about developer experience

Think: “developer-oriented intelligence”

💡 The Real Optimization: Don’t Choose —> Combine

One of the biggest insights we've found:

The best results don’t come from picking one model — but from designing the right workflow.

By splitting responsibilities between models, we've been able to:

Reduce token usage by 47%
Improve output quality
Speed up iteration cycles

Example workflow:

Use GPT-5.4 for:

Planning
Structure
System-level tasks

Use Claude Sonnet 4.6 for:

Refactoring
Cleanup
Humanizing outputs

This hybrid approach consistently outperforms using either model alone.

🧩 So… which one wins?

The honest answer:

It depends on what you're optimizing for.

Use Case: Infrastructure / Systems
Better Choice: GPT-5.4

Use Case: Refactoring / Readability
Better Choice: Claude Sonnet 4.6

Use Case: Cost Efficiency
Better Choice: Hybrid

Use Case: Developer Experience
Better Choice: Claude

Use Case: Automation Pipelines
Better Choice: GPT

We're entering a phase where:

The competitive advantage is no longer the model, it's how you use it.

Workflows > tools
Systems > prompts
Strategy > benchmarks

Which model is winning in your IDE this week?

Are you sticking to one, or already building hybrid workflows?

Claude Code vs OpenClaw: Memory Tricks 🧠

ClickIT - DevOps and Software Development — Thu, 02 Apr 2026 19:37:03 +0000

For a while, I thought AI memory was basically just…a smarter grep.

Search some files, grab context, send it to the model. That's it.

And to be fair, that works at the beginning. But once your agent starts doing anything even slightly complex, things get weird. It forgets what it just did, repeats mistakes, or confidently breaks something it had already fixed five minutes ago.

At some point it hits you, it's not that the model is bad, it's that the memory model is wrong.

We recorded a super short clip about this if you want the quick version.

The thing that changed how I think about this is realizing that not all “memory” should behave the same way. Most setups just dump everything into context like it's one big pool, but that's exactly what creates the problem. You end up with noisy, expensive context and an agent that still acts like it has amnesia.

What's been working better (at least for me) is thinking of memory more like two separate systems.

On one side, you have something closer to a library, your cached context. Docs, system rules, known structures…things that don't change much. This is the stuff you want pre-loaded and reused efficiently.

On the other side, there's something more like a journal. Not what the agent knows, but what it just did. The last decisions it made, the changes it applied, the mistakes it shouldn't repeat. That's the piece that actually makes the agent feel consistent over time.

Mix those two, and everything gets blurry. Separate them, and suddenly the behavior starts making more sense.

The biggest shift for me was stopping the question:

“How do I give the agent more context?”

And replacing it with:

“What should be remembered, and what should just be reloaded?”

Curious how others are handling this, especially in longer-running agents.

Are you structuring memory already, or still kind of piping everything into context and hoping for the best?

How to Improve OpenClaw 🤔

ClickIT - DevOps and Software Development — Thu, 26 Mar 2026 16:55:01 +0000

I've been playing around with AI agents lately (especially OpenClaw), and I kept running into the same issue:

They start off sharp…
and then slowly get worse.

Not broken. Just… worse.

At first I thought it was the model.
It wasn't.

The real problem: context bloat

Most agents don't fail instantly, they degrade.

Their context just keeps growing:

repeated instructions
outdated decisions
random “temporary” fixes that never get removed

At some point, the agent is technically “smarter”… but actually less useful.

It starts to feel like you're talking to someone who remembers everything, but understands less.

Something that clicked for me

I recorded a short podcast-style clip about this, just sharing ideas.

One thing that really stuck with me is that we're not really designing agents… we're designing evolving systems.

And most of us are treating them like static tools.

What actually helped

Instead of trying to “fix prompts”, we started thinking in layers:

1. Vision checks (not just prompt tweaks)
Every now and then, step back and ask:
→ is this agent still doing what it was meant to do?

Drift is real.

2. Sandbox before production
Changing an agent directly in prod feels a lot like editing code without testing.

It works… until it doesn't.

3. Curated skills > raw autonomy
Letting an agent “figure things out” sounds cool.

But in practice, giving it validated, reusable skills works way better.

Less chaos, more leverage.

The shift (at least for me)

I stopped thinking:

“How do I make this agent smarter?”

and started thinking:

“How do I keep this system from degrading over time?”

Big difference.

Curious if others here have seen the same thing, especially with long-running agents or memory-heavy setups.

How are you dealing with context bloat?

Claude Code vs OpenClaw: The AI Memory War

ClickIT - DevOps and Software Development — Mon, 23 Mar 2026 20:37:21 +0000

Why do AI agents still feel like they have the memory of a goldfish?

One minute they're refactoring complex logic, the next they've completely lost the context of what they were doing.

We kept running into this while working with AI agents in real-world environments, so we decided to break it down from a systems perspective—not just prompts, but what's actually happening under the hood.

Here’s the video if you want the full walkthrough.

The real problem isn’t prompts

A lot of devs try to fix this by writing longer prompts or adding more context.

That helps… until it doesn't.

The real issue usually comes down to how memory is handled:

What gets persisted
What gets cached
What gets discarded between interactions

If you don't design for that, your agent will always feel inconsistent.

Two different approaches: Claude Code vs OpenClaw

We looked at two very different philosophies:

Claude Code

Structured, layered memory system
Relies on a 4-level architecture
More predictable, but also more constrained

OpenClaw

Agent-driven memory (more autonomous)
Decides what to store and reuse
Feels more flexible, but comes with trade-offs

Neither is “better” universally, it depends on how much control vs autonomy you want.

Memory vs Caching

(this is where things get interesting)

One thing that gets mixed up a lot:

Memory → long-term persistence across sessions
Caching → short-term reuse for efficiency

Most production issues we’ve seen come from confusing these two.

The part people are not talking about: Security

As soon as you give agents memory, you're also increasing risk.

One example we cover is indirect prompt injection:

Malicious data gets stored as “memory”
The agent trusts it later
Behavior gets manipulated without obvious signals

This becomes especially important if your agent touches production systems.

What we’ve learned building with this

A few takeaways that have held up for us:

Memory needs boundaries, not just storage
Caching should be intentional, not automatic
More autonomy = more responsibility (and more risk)
Observability is not optional if you're going to production

We're curious how others here are approaching this.

Are you comfortable giving AI agents persistent memory in production yet?

What Are the Risks of Using OpenClaw?

ClickIT - DevOps and Software Development — Wed, 25 Feb 2026 21:18:52 +0000

With OpenAI backing OpenClaw, agentic systems are quickly moving from experiments to production.

And that’s exciting.

But it’s also where things get risky.

We're no longer just generating text. We're letting models:

Execute code
Call tools
Access APIs
Modify files
Trigger workflows

That shift, from generate to act, is where the real security conversation starts.

The core problem

An LLM giving a wrong answer is annoying.

An autonomous agent with production access making the wrong decision is a security incident.

The attack surface expands fast when your system can take actions in real environments.

So before deploying something like OpenClaw, there are three things you really shouldn’t compromise on:

1. Sandboxing
Agents should never run in unrestricted environments. Isolate execution, restrict network and filesystem access, and assume failure will happen.

2. Strict permission limits
If your agent has admin-level access “just in case,” you're setting yourself up for trouble. Apply least privilege like you would with any engineer.

3. Human-in-the-loop for high-impact actions
Deployments, financial ops, infrastructure changes, those shouldn't be fully autonomous (at least not yet).

And honestly...I'd add a fourth:

4. Observability

If something goes wrong, you need to know why. Full logs, tool traces, decision paths. No black boxes.

Agent frameworks are powerful. But autonomy without guardrails is just operational risk wearing a cool AI label.

Quick explainer here.

How much autonomy are you comfortable shipping today?