DEV Community: ClickIT - DevOps and Software Development

Do I still need to learn Python? Oh, really?

ClickIT - DevOps and Software Development — Thu, 03 Sep 2026 21:56:47 +0000

Allow me to put my thinking hat on…

I’ve recently been seeing many young engineers wondering whether the basics are still… well basic. At least in the fundamental sense.

Now that AI has provided many tools and changed our approach to software development, how much does Python actually benefit me? Should I even bother learning it?

I have my own thoughts on the matter, but I’ll give you a second or 2 to think it through.

…ready?

My immediate answer is YES! OF COURSE YOU SHOULD!!!

But after some thought, I kinda get where they are coming from. With a new technology appearing every day, it almost seems like keeping up is more important than covering the (sorry for this) retro knowledge.

Still, as I blasphemously said, old, basic knowledge, is still knowledge. Python and all those languages/tools/technologies are the building blocks of every newly released technology.

They are what is going to save you whenever the AI inevitably makes a mistake (or even breaks), and, more importantly, they are what will help you build even better, more useful projects.

Did I miss anything? What do you think? Have you seen similar discussions and how do you approach them?

I recently got into this controversy 😮 with a friend of mine, here’s our convo.

Ok, but who’s loop engineering?

ClickIT - DevOps and Software Development — Fri, 28 Aug 2026 18:47:40 +0000

And is that done consciously? Or is it just a new name on an old trick? 🧐

Please excuse my wandering self, but, from what I can tell, loop engineering is the practice of building a system that runs an AI agent repeatedly until a task is complete.

No human in the middle, just the loop doing its thing (looping around ☆ω☆) until it's baked and ready.

Also from what I’ve seen, the results depend entirely on what you point it at.

Some have tried it, hit a wall, and gone back to just staying involved themselves. Agents drifting off-task and costs creeping… sounds like a valid reason to walk away.

But others seem to get real use out of it, mostly on specific and repeatable tasks. Routine alerts, scheduled checks, the overnight supervision nobody wants to do manually. That kind of thing.

The pattern seems pretty consistent: loops work when the task is narrow and well-defined. Give it something too broad or ambiguous and it'll probably wander.

We put out a short video on this recently if you want a more concrete look at where it tends to hold up.

Anywhooo 🤷🏽‍♀️… what's your take on all these new "engineerings"? Feels like a new one drops every few weeks. I'll try to reflect a bit more on this for next week.

See you around!

If you saw the harness engineering bill, would you still pay for it?

ClickIT - DevOps and Software Development — Fri, 21 Aug 2026 21:06:16 +0000

I do. Harness engineering is more expensive, but let me walk you through my thought process.

When you put an AI agent to work on something real, there's a whole system underneath that decides what it's allowed to touch, what information it actually has access to, and how you confirm the work is done before calling it done.

That system is the harness.

Building one takes time, and yes, it costs more than just letting the agent run.

But, and let me hold your hand when I say this, I strongly believe that an agent without a harness isn't working cheaper, only unsupervised.

I recently read a test where two agents were given the same task.
The first one ran solo, no real structure around it. Finished in 20 minutes and cost about $9. It looked done, but hello, hello, there was a bug in it that only showed up if someone actually read through the code * _ *

The second had a proper harness. A planner, a builder, a checker. It took 6 hours and cost about $200. More than 20 times the cost, but it actually worked.

So, the first run didn't save money, it just made the mistakes harder to see.

A bug that makes it to production, a rollback, the hour someone spends reconstructing what the agent did and why. The bill shows up eventually.

Harness engineering is really just the same instinct you already apply to shipping software, except the thing you're managing is an agent.

The elements are roughly what you'd expect: what the agent can do without asking, what context it has access to, how it holds state across steps, and how you actually verify the output before anything gets marked complete.

We have a recent video on this that even walks through a basic permissions example in Claude Code if you want to see what the smallest version of a harness looks like in practice.

That’s my take on the whole harness engineering debacle, what’s yours? Am I just burning budget?

How are you guys using Replit?

ClickIT - DevOps and Software Development — Wed, 05 Aug 2026 22:14:03 +0000

Genuinely asking. Because I've had my fair share of frustrating failure moments with it. But after MUCH trial and error (and then some more), I’ve found some things that actually work for me:

I’ve stopped skipping the planning phase.

Beginner's mistake. I thought stopping to plan every. single. idea. was slowing me down and boy was I wrong. Design Mode and Plan Mode exist for a reason and using them in the right order actually saves time.

Design Mode is great for fast prototyping, getting a feel for the UI before anything is wired up. Plan Mode is where you structure the project before the agent starts building.

The temptation of skipping straight to generating, is usually where things start going sideways. Taking a few extra minutes in Plan Mode means the agent has something solid to work from instead of improvising.

The Verifier Agent is NOT optional.

We listen and we don’t judge, ok? I was ignoring it.

Turns out that when it asks for feedback, it's actually checking your code and looking for things you might have missed. I caught a few issues that I probably wouldn't have found on my own hehe 🫠.

Lite Mode for small changes.

The little lightning bolt thingy. If you're making a minor adjustment, switch to Lite Mode first and it runs a lighter model. Faster and cheaper. No reason to use full capacity for a one-line fix.

Nothing groundbreaking really, but adding these to my workflow has changed my opinion and view on Replit. I’ve also put out a short video recently with some other little pro tips if you want to give it a look.

Any Replit habits that took you a while to figure out? Do you even use Replit?

Turns out I wasn’t using Claude Skills at all. NICE!

ClickIT - DevOps and Software Development — Mon, 13 Jul 2026 15:57:55 +0000

Am I late to the Claude Skills Party? Probably. But I’ll say something anyway.

I think many are using it wrong, or at least I know I was.

A Skill is a job description, not a request. It lives in a reusable folder built around a SKILL.md file that Claude loads when it's relevant to the task. A prompt disappears when the session ends. A Skill doesn't. You build it once and stop re-explaining the same context every time you sit down to work.

In other words Prompt ≠ Skill. That should be clear from the get go.

The thing is, I didn’t really get it until our release process lol.

Versioning, changelogs, deployment checks. Every new session I'd walk Claude through the same sequence because it had enough specific steps that I couldn't assume it would handle things the way we do internally. But that was taking more energy than what it was saving. Not an ideal situation.

** In comes Skills ** That's exactly the kind of workflow they exist for. Define the role, set the constraints, specify the output, and never walk through it manually again.

I would say though, just a heads up: more Skills doesn’t mean better results. In fact, overloading my setup ended up hurting my performance. So learn from my mistakes and tread lightly.

We put together a short video on this if you want to see a full breakdown.

What was your entry point into Skills? I went with the release process but part of me thinks there's a much more obvious starting point I completely missed. Prove me right?

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? 🤔