Coder Legion - Recent posts tagged vibe-coding

Hacking a website is now easier than pouring a cup of coffee — here's how to stay safe

Thu, 01 Oct 2026 09:39:11 +0000

Nowadays, hacking a website is easier than pouring a cup of coffee ☕️

While striving to deliver value to users as quickly as possible, it is crucial not to cause harm. I’d like to introduce you to Magery Forge, a security auditing service. It transforms scanner "noise" into clearly defined risks, complete with remediation recommendations. The service is also available via MCP, allowing your AI agent (Cursor, Copilot, Claude, OpenClaw) to run scans and read reports autonomously, while leaving the final decision on how to address discovered vulnerabilities up to you.

Here’s a key point: you don’t need to grant access to your codebase. Doing so could introduce additional risks and create new attack vectors. AI agents are already good at writing code, but attackers aren't stupid—they always look for the path of least resistance. Right now, that path often lies in how components are configured into the final product. The work is split between the agent and you, and you don't always fully grasp the specific configurations or commands being executed. That’s why the service operates on a "black box" principle: it simulates a real-world hack.

https://forge.magery.ai

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

Tue, 22 Sep 2026 09:32:52 +0000

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

AI coding agents have become surprisingly good at changing code.

But we are still giving them files as if they were human developers sitting in front of an editor.

And that is expensive.

Imagine your agent needs to rename one identifier inside a 2,000-line file.

The actual change might be:

oldName → newName

A few tokens of useful information.

Yet the typical agent workflow looks something like this:

read 2,000 lines
↓
reason about one relevant line
↓
edit the file
↓
read the file or diff again
↓
continue carrying much of that context

The agent may consume tens of thousands of tokens to perform an operation whose semantic payload is only a handful of tokens.

That feels backwards.

What if the agent never opened the file?

This is the idea behind RAP — Runtime Apply Patch.

Instead of asking an agent to read a file, locate something, rewrite it, and verify the result, RAP lets the agent address the code directly by its content.

For example:

rap s app.go 'oldName' 'newName'

RAP answers:

updated app.go (lines 1697 -> 1699, bytes +133, replacements 1)

That's it.

The agent did not need to load 2,000 lines into its context.

It already knew what it wanted to change.

RAP simply found it and performed the operation.

The principle can be summarized in three words:

Lines, not files.

Files are a human abstraction

Files are extremely useful for humans.

We open app.go, scroll around, understand the surrounding code, make a change, save it, and inspect the result.

But an AI agent does not necessarily need to reproduce that workflow.

If an agent already knows:

OLD = "oldName"
NEW = "newName"

why should it pay the context cost of reading another 1,999 lines?

The information required to describe the mutation and the information required to store the program are two very different things.

RAP tries to keep them separate.

The filesystem stores the program.

The model describes the mutation.

RAP connects the two.

Content becomes the address

Traditional editing often addresses code through coordinates:

file → line → column

But coordinates are fragile.

Insert ten lines above the target and the address changes.

RAP instead addresses code by content:

file → known text → replacement

The interesting consequence is that the agent often already possesses the address.

Maybe the target came from a previous grep.

Maybe it appeared in an error message.

Maybe the user provided it.

Maybe the agent wrote that code itself thirty seconds ago.

There is no reason to reload the entire file merely to rediscover information already present in the agent's context.

What if the target is ambiguous?

Then RAP stops.

$ rap s app.go 'count' 'total'
rap: OLD matched 3 times; use -all or a more specific OLD

Nothing gets written.

This property matters more than it might initially appear.

Shell tools can be extremely efficient for agents, but commands such as sed can also silently perform a perfectly valid operation on the wrong piece of text.

For an autonomous agent, failure is often cheaper than confidence.

A failed command may cost a dozen tokens.

A wrong edit can contaminate several subsequent reasoning steps before the mistake is discovered.

RAP therefore prefers an explicit refusal over an ambiguous mutation.

But sometimes the agent really does need context

Of course.

The argument is not that agents should never read source code.

The argument is that reading an entire file should not be the default unit of interaction.

RAP provides smaller operations for the questions agents actually ask.

Want to know whether a target is unique?

rap m FILE 'text'

Result:

matches: 1

Want to inspect only the affected area?

rap preview -n FILE 40 60 -- s OLD NEW

The agent receives a small window instead of the whole building.

Need to pass ugly text containing quotes, JSON, shell characters, or newlines?

rap q -token @file

RAP turns it into a safe token representation.

And after an edit, the command itself returns a receipt describing what happened.

No automatic full-file reread is necessary just to ask:

Did it work?

The token economics are surprisingly large

Consider a 2,000-line source file representing roughly 25,000 tokens.

A conventional agent might:

read file        ~25,000 tokens
modify
inspect result   ~25,000 tokens

Potentially around 50,000 tokens of context traffic around an edit that may involve only one line.

With RAP, the interaction can look more like:

rap s FILE OLD NEW

Perhaps ~40 input tokens and ~20 output tokens.

Obviously, real workloads vary. Agents sometimes genuinely need broader context, and not every edit can be expressed as a simple substitution.

But that is precisely the point.

Pay for context when reasoning requires context.

Do not pay for it merely because the code happens to live inside a large file.

This becomes more important as agents become more autonomous

Token efficiency is usually discussed as a model problem:

smaller prompts, better compression, larger context windows, cheaper inference.

But part of the problem may actually live outside the model.

Our tools still assume that an intelligent actor interacts with software primarily by opening documents.

Coding agents give us an opportunity to reconsider that assumption.

An agent does not necessarily need an editor.

It needs precise operations over a codebase, small observations about their consequences, and predictable failure modes.

That suggests a different interface between models and source code:

observe less
act precisely
verify cheaply
expand context only when necessary

RAP is a small experiment in that direction.

It does not try to make the model smarter.

It tries to make the model need fewer tokens to do the work it already knows how to do.

Lines, not files

The core idea behind RAP is intentionally simple:

The unit of work should be the information required for the change, not the container in which that information happens to live.

Sometimes that means a file.

Sometimes it means fifty lines.

Sometimes it means five.

And sometimes it means:

oldName → newName

If AI agents are going to execute thousands of filesystem operations autonomously, that distinction starts to matter.

A lot.

RAP is open source and available on GitHub.

Try giving your coding agent RAP and watch how often it can edit code without ever asking to see the whole file.

Everyone Can Build Software Now. Who’s Stopping the Agents?

Mon, 14 Sep 2026 23:28:33 +0000

Maybe the best software developers in the world built a piece of software.

Then that software started building software.

They marketed it and said:

“You can build software even if you don't know how to code.”

And people actually started building software.

But a problem emerged.

People who didn't know how to code started building buggy software.

Then professional developers who knew how to code started using the same tools.

And they built buggy software too.

But there was something ironic about this:

Vibe coders weren't the only ones building buggy software.

Professional developers using the same tools were making mistakes too.

Then the people who knew how to code started laughing at the people who didn't.

They called them “vibe coders.”

Hello, I'm Ali Ulu.

I'm a vibe coder.

LinkedIn and similar platforms are full of complaints from developers who know how to code and are looking for jobs.

Instead of joining them, I chose a different path.

Rather than focusing on learning how to write code, I focused on understanding the soul of software and orchestrating agents.

And the project I'm working on right now is built exactly around this problem.

While trying to build software without knowing how to code, I became focused on one thing:

Watching what agents are doing before they make a mistake — and stopping them before that mistake happens.

This project is called HUQAN.

Welcome to my story.

To conduct the orchestra, sometimes you have to turn your back on the crowd.

Vibe Coding Was Supposed to Kill Software Engineering. Instead, It Exposed What Engineering Actual

Mon, 14 Sep 2026 08:57:07 +0000

The strange thing about AI coding isn't that machines can write software now.

It's that we're finally discovering how much of software engineering had very little to do with typing code in the first place.

In early 2025, “vibe coding” sounded like a meme.

Andrej Karpathy described it as essentially giving in to the model, accepting generated code, and worrying less about the code itself. He openly described accepting changes without reading the diffs and letting the code grow beyond his normal comprehension. He also made an important exception: for disposable weekend projects, it was “not too bad.”

That distinction should have ended the argument.

It didn't.

Instead, the internet split into two camps.

One side said:

“This isn't engineering.”

The other said:

“You just don't understand what engineering is becoming.”

A year later, I'm less interested in which side wins.

I'm interested in something more uncomfortable.

What if both sides were looking at different parts of the same transition?

The Original Sin of Vibe Coding

The biggest misconception about vibe coding is that it means:

“Using AI to write code.”

It doesn't.

Simon Willison made that distinction very clearly in 2025. His argument was basically that if an LLM writes the code but you review, test, understand, and take responsibility for it, that's not really vibe coding. That's simply using an LLM as a programming tool.

The more interesting definition is much messier:

You have an idea.

You describe it.

The model writes something.

You run it.

Something breaks.

You describe the break.

The model changes the code.

You run it again.

It works.

You ship it.

That workflow feels almost magical.

And sometimes it is.

But there's an interesting word hiding inside that loop:

works.

What does “works” actually mean?

Does it pass the demo?

Does it pass the tests?

Does it survive production?

Can another developer understand it?

Can you debug it six months later?

Does it preserve the right security boundaries?

Does it make the next feature easier or harder?

Or does “works” simply mean:

“I don't see an error anymore.”

Those are very different definitions of success.

I Found Myself Doing It Too

This is where the debate gets personal for me.

I've built projects where AI was involved in much more than autocomplete.

Take Arcane Dice.

It's a 3D physics dice roller with Three.js, Ammo.js and an AI dungeon-master layer.

I could describe a feature, let the model implement it, run the project, find something broken, paste the error back, and keep going.

And that's incredibly productive.

You can get from:

“I have an idea.”

to:

“There's a working prototype in the browser.”

much faster than you could before.

That's the part of AI coding that critics sometimes underestimate.

The leverage is real.

But then something funny happens.

The project gets bigger.

The components multiply.

State starts crossing boundaries.

One feature touches three other systems.

A “small” change suddenly has consequences somewhere else.

And the questions change.

You stop asking:

“Can the AI write this?”

and start asking:

“Why did it write it this way?”

That's a completely different question.

The Code Gets Cheaper. The Context Doesn't.

This might be the most important economic change AI has introduced into programming.

The cost of generating code has collapsed.

The cost of understanding a system hasn't.

Imagine an agent generating 2,000 lines in ten minutes.

Amazing.

Now imagine another engineer has to spend two hours understanding the change.

The generation got cheaper.

The reasoning didn't.

And if AI makes developers produce five times as many changes, the amount of software requiring review can increase faster than human review capacity.

That's exactly why code review is becoming such a strange bottleneck in the agentic era.

Recent industry analysis has reported large increases in code churn and review time among teams with heavy AI adoption, alongside concerns about more unreviewed changes reaching production.

There's a beautiful paradox here:

AI removes the bottleneck that was visible.

Then creates a bottleneck that is harder to measure.

“But My Tests Are Green”

This is probably the most dangerous sentence in AI-assisted development.

A test suite can tell you that certain behavior works.

It cannot tell you that the architecture makes sense.

It cannot tell you that the abstraction belongs there.

It cannot tell you that the next engineer will understand the code.

And it certainly can't guarantee that you solved the right problem.

METR ran an experiment around exactly this gap.

They looked at software-engineering patches that passed automated SWE-bench evaluation and then asked maintainers whether they would actually merge them.

A substantial share of those patches were not considered acceptable for the real project.

That doesn't mean the benchmark is useless. It means the benchmark is measuring something different.

Passing a test is not the same as passing an engineer.

That's an important distinction because AI systems are becoming exceptionally good at optimizing for things we can measure.

The things we cannot measure as easily are often the things engineers spend their lives worrying about.

Then the Productivity Research Got Weird

There is another reason I don't think the “AI makes programmers worse” argument holds up.

Some research says AI makes developers significantly more productive.

A large field experiment involving 4,867 developers across Microsoft, Accenture, and a Fortune 100 company reported that developers with access to AI coding assistance completed about 26% more tasks.

That is not a rounding error.

But another randomized METR study of experienced open-source developers working in mature repositories found something almost comically opposite: developers using AI took about 19% longer on the tasks studied.

Even stranger, the developers expected AI to make them faster.

They were slower.

And still believed they were faster.

That's not just a story about AI.

It's a story about humans.

We are very bad at estimating the total cost of automation when the automation feels good.

The Best AI Feature Might Be False Confidence

This is the part that genuinely bothers me.

When an AI generates broken code, that's annoying.

When it generates code that looks correct, it's much more dangerous.

Good naming.

Clean formatting.

Reasonable comments.

A green test suite.

A polished UI.

No obvious errors.

Suddenly you have something that feels trustworthy.

And our brains are very willing to reward things that look finished.

One 2026 study examining whether human developers could detect deliberately hidden malicious behavior in AI-assisted coding tasks found that most participants failed to detect the sabotage. Even after monitoring warnings appeared, many participants still accepted the code.

That's not evidence that AI is evil.

It's evidence that human review is not automatically human understanding.

You can technically review a diff while mentally outsourcing the judgment to the machine that produced it.

That's a very different kind of failure.

And Security Doesn't Care About Your Vibes

Here is where the “it's just a prototype” defense becomes complicated.

Because prototypes have a nasty habit of becoming products.

A developer builds something for fun.

Then someone says:

“This is actually pretty useful.”

Then:

“Can we add accounts?”

Then:

“Can it store user data?”

Then:

“Can we monetize it?”

Then:

“Can it handle payments?”

Congratulations.

Your weekend experiment now has a security model.

A 2025 benchmark of real-world coding tasks found a disturbing gap between functional correctness and security. In one evaluation, 61% of SWE-Agent solutions using Claude 4 Sonnet were functionally correct, while only 10.5% were considered secure.

That number should make every “the tests pass” argument feel slightly less comfortable.

Because software doesn't get attacked according to your benchmark.

It gets attacked according to reality.

My Own Projects Made This More Obvious

Another project I've worked on is Ikol, a Telegram AI bot.

The interesting part isn't simply getting an AI bot to answer messages.

That's easy now.

The interesting part is everything that happens around the model.

State.

Retries.

Tool selection.

Rate limits.

External APIs.

Bad responses.

Wrong music results.

A tool that works perfectly today and starts behaving differently tomorrow.

A previous answer leaking into an unrelated conversation.

Suddenly you're not really asking:

“Can GPT answer this?”

You're asking:

“What guarantees does the system have when everything around GPT is imperfect?”

That's engineering.

And AI doesn't remove that layer.

It makes the layer more visible.

Here's Where I Think the Vibe Coding Debate Goes Wrong

We keep asking:

“Is vibe coding engineering?”

I think that's the wrong question.

A better question is:

“Where does the engineering move when the typing moves to the model?”

One DEV commenter described the role as a kind of “Language Modeler”: the human specifies what the system is, what it means, and what constraints are allowed, while the AI acts as a translator between natural language and code.

Another developer argued that the new engineering skill is orchestration: decomposing problems, directing agents, validating outputs, and knowing whether the generated system actually solves the problem.

Those aren't silly arguments.

They're actually the strongest argument for AI-native engineering.

And that's where the discussion gets interesting.

The New Engineer Might Write Less Code and Understand More

Imagine two developers.

Developer A writes 2,000 lines manually.

Developer B generates 10,000 lines with AI.

Developer B might appear more productive.

But now imagine Developer A understands every abstraction in those 2,000 lines.

Developer B understands only the behavior of the system at the surface.

Which one is the better engineer?

We don't actually know.

Because the answer depends on what happens next.

If nothing breaks, Developer B wins.

If the product has to evolve for five years, the equation might completely reverse.

And if the system is safety-critical?

The cost of not understanding can become enormous.

The Comment Sections Are Actually Getting More Interesting

What's changed recently isn't that everyone agrees.

It's that the arguments are getting better.

One DEV commenter recently described vibe coding as:

“borrowing time from the future at a predatory interest rate.”

That's a brutal metaphor.

But it's useful.

Maybe AI doesn't remove technical debt.

Maybe it makes technical debt easier to create.

Another commenter pushed back on the old definition of vibe coding and argued that the real skill is orchestration.

That argument is compelling because software engineering has always been partly about abstraction.

We stopped writing machine instructions by hand.

We stopped reimplementing everything from scratch.

We created frameworks.

We created libraries.

We created compilers.

Nobody concluded that software engineering had disappeared.

So why should the ability to describe software to a model be fundamentally different?

Maybe it isn't.

Maybe we're just adding another abstraction layer.

But There's a Trap

Abstraction is powerful.

Abstraction also hides things.

That's the entire point.

You don't need to understand how malloc works every time you create an array.

You don't need to understand a CPU pipeline to write a React component.

But when the abstraction breaks, someone needs to know what's underneath it.

That's why I think the future developer profile becomes strangely asymmetric.

You might write 20% of the code yourself.

But you may need to understand 80% of what the system is doing.

That sounds backwards.

It isn't.

It's what abstraction has always done.

The Most Valuable Programmer Might Become the Person Who Deletes the Most AI Code

This is the part nobody likes talking about.

Generation is seductive.

Deletion is not.

AI makes it incredibly easy to say:

“Let's add one more thing.”

One more feature.

One more helper.

One more abstraction.

One more dependency.

One more component.

One more agent.

Until the project becomes a pile of things that individually made sense and collectively don't.

The ability to say:

“No. We don't need this.”

might become more valuable than the ability to generate it.

The best engineer in an AI-heavy team may not be the person who produces the most code.

It may be the person who knows which 40% should never have existed.

So Was Vibe Coding Right?

Yes.

And no.

Vibe coding was right about one enormous thing:

A surprisingly small amount of traditional programming work actually requires humans to manually type every line.

But its critics were right about another:

Removing typing does not remove responsibility.

AI can collapse the distance between an idea and a prototype.

That's incredible.

It can also collapse the distance between an idea and a production incident.

That's considerably less incredible.

The technology isn't the contradiction.

Our definition of “done” is.

Maybe This Is What Software Engineering Has Been Becoming All Along

This is the historical part that I keep coming back to.

Programming has spent decades moving upward:

Machine code
      ↓
Assembly
      ↓
C
      ↓
C++
      ↓
Python / Java / JavaScript
      ↓
Frameworks
      ↓
Libraries
      ↓
Declarative systems
      ↓
Natural language

Every step removes some amount of direct control.

And every step creates a new question:

How much do you need to understand about the layer below you?

Maybe AI isn't the death of programming.

Maybe it's simply the point where that question becomes impossible to avoid.

The Weird Future

I don't think the future belongs to people who refuse AI.

I also don't think it belongs to people who blindly trust it.

It probably belongs to the people who can move between both worlds.

They can think in systems.

They can specify precisely.

They can delegate.

They can inspect.

They can debug.

They can recognize when the model is confidently wrong.

They can throw away generated work without feeling emotionally attached to it.

And when necessary, they can still open the code and understand what is actually happening.

That's a very different skill from memorizing syntax.

But it's still engineering.

One Last Thought

Maybe we're asking the wrong question because we're still obsessed with the old definition of a programmer.

We keep looking at the screen and asking:

“Who wrote this code?”

Maybe the more important question is:

“Who understands this system well enough to be responsible for it?”

Because one day, AI may genuinely write 95% of the implementation.

That part is plausible.

What is much harder to automate is judgment.

Knowing what should exist.

Knowing what shouldn't.

Knowing which assumptions are dangerous.

Knowing when the tests are lying by omission.

Knowing when the architecture is drifting.

Knowing when the fastest solution today is the slowest solution next year.

And knowing when to tell the machine:

“No. Delete it. We don't need this.”

That's the part I don't think vibe coding has replaced.

Maybe it was never supposed to.

Sources & Further Reading

Andrej Karpathy — “vibe coding”
Karpathy's original February 2025 description of the practice and its deliberately hands-off workflow.

Simon Willison — “Will the future of software development run on vibes?”
A useful distinction between true vibe coding and AI-assisted software development where the developer still reviews and understands the result.

METR — AI and experienced open-source developer productivity
A randomized study that found experienced developers in the studied repositories took longer with AI assistance.

Management Science — Generative AI and software developers
Large-scale field experiments involving 4,867 developers found meaningful productivity gains from AI coding assistance.

METR — SWE-bench and human merge decisions
Evidence that passing automated software-engineering benchmarks is not equivalent to a maintainer deciding that a patch belongs in a real codebase.

SU S VI B E S benchmark
Research showing a major gap between functional correctness and security in agent-generated software.

DEV Community — “Vibe Coding Isn't the Problem. Calling It Engineering Is”
The article that triggered the discussion behind this piece, including the distinction between vibe coding, AI-assisted programming, and engineering accountability.

My own projects:
Arcane Dice — 3D physics dice roller with an AI dungeon-master layer.

More of my work — experiments spanning AI, web development, games, automation, and tooling.

Why we only build 60-point products

Sun, 13 Sep 2026 11:21:57 +0000

There's a popular saying: either don't do it, or do it to a 100-point standard.

But after building AI products for a while, I'm increasingly sure of the opposite: obsessing over the 100-point product is often the first thing that makes a founder lose money. This week's three lessons — being stingy with costs, running the flow backwards, and keeping businesses isolated — come down to one sentence: build a 60-point product that doesn't lose money, doesn't overcomplicate, and doesn't strain you.

Lesson 1: The first lesson of AI products is being stingy

We've always said we don't build 100-point products. The same goes for features.

Take resume screening. What would the ideal state look like? Every resume is analyzed by the model individually, with a separate result. That's a textbook 100-point feature. But to reach that 100 points: an HR person screening 300 resumes needs about 310 requests. One full screening consumes 2,500 credits — roughly 2.5 yuan in revenue. That loses money to grandma's house.

To actually break even, we'd have to charge about 50 yuan. So ask yourself: what sucker pays 50 yuan for a one-time 300-resume screening?

So when building products, you have to be a bit stingy. Stingy isn't cheap — it's cost-driven: when I save money on my side, the customer can afford it on theirs. This is how we save money together with the customer.

Another example, still resume screening. In theory, we can parse any PDF format. But scanned documents require OCR, which dramatically increases overall cost. Text-based PDFs already cover 80% of resumes — consider that an unintentional lesson borrowed from DeepSeek. As for the remaining 20%: I've proven my capability, now it's the HR folks' turn to prove their budget.

And here's what you may not have noticed: once you start parsing scans, it looks like broader capability, but it actually drags the whole platform toward "document processing" — narrower and narrower, hurting the extensibility of the entire site. Customers whose needs are refined to that degree shouldn't be on a general platform anyway; they should be on custom solutions.

That's where our other business plugs in: on-premise deployment. The same capability, deployed at the customer's site, has a much better revenue-to-effort ratio than online. Online scales the volume; custom work scales the margin.

Not building the 100-point product isn't a lack of ambition. It's knowing how to do the math.

Lesson 2: Laziness is the first productive force

I have a belief: laziness is the product manager's first productive force.

Every product is solving a human desire, and laziness is the most legitimate product path. You don't want to go out to eat, so you order delivery. You don't want to read through a pile of results, so you use AI.

We took a detour when building resume optimization. Our first flow was: edit page → write the full resume → choose AI optimization → pick which AI optimization points to keep → write them back → print. We later changed it to: upload resume → AI auto-optimizes → fix whatever looks wrong → print.

Notice where it changed?

Before, it was "write, write, write" — write the resume, write the optimization points, write the edits. Now it's "click, click, click" — upload, pick, fix, print, done. And I also flipped my thinking: users come here for me to AI-optimize their resume. Why force them to confirm one by one which AI edits are good and which aren't? Just hand them the optimized result; whatever they don't like, they delete themselves.

This logic applies even more in an era where AI products are popping up everywhere: clunky products always get replaced by simpler ones. It's not about having more features. It's about the user having to do less.

Lesson 3: The money you make fastest may be the money you lose fastest

I currently have another project, powered by Claude, that brings in meaningful income. But I've never synced it with the users of my other business line.

Someone might ask: users already trust you — wouldn't moving them over earn you another income stream? Logically, yes. But on my side, that only works between similar projects. Say two of your businesses both target the workplace: heavy audience overlap, moving them over is efficient. But what if one is food and the other is workplace? The audiences overlap — plenty of workplace people love food — but your capabilities don't carry over. The two businesses are two separate skins. Move them over early and the revenue comes fast. But what you took from somewhere, you can lose from the same place.

We run multiple product lines to avoid putting all eggs in one basket. But if you make ten baskets and then tie them all together with rope — when they fall, how is that different from one basket?

So my principle is business isolation. I run multiple lines to spread risk, not to concentrate it in a new way.

Never over-trust your own product. "My product can't have negative PR!" "I just built a small tool, what negative impact could it have?" — the moment luck appears, that's where the crack shows.

Does that mean zero connection is allowed? Not at all. Look at the old business's carrier — if you have a traffic-driven news site that makes money from ads anyway, and it happens to run an ad for another product of yours, users have no idea you're the same developer. That's the safest kind of connection: two subsidiaries that don't actively link, but yours is still my customer.

The takeaway

These three lessons are actually one worldview: do the math soberly, instead of building products on emotion.

Being stingy with costs is doing the math between "features" and "revenue." Running the flow backwards is doing the math between "what you think users want" and "what users actually want." Business isolation is doing the math between "short-term money" and "long-term risk."

Before, the biggest fear in a startup was not having enough money. Now, with AI products, the easiest mistakes are: the product is too bloated, the flow is too convoluted, the ambition is too big. And all three of those are quietly taking money out of your pocket.

60 points isn't a lack of ambition. 60 points is, after doing the math, leaving your energy for what actually matters.

Vibe Coding Won't Kill Developers. It'll Kill the Middle.

Tue, 01 Sep 2026 12:57:28 +0000

When good cameras got cheap, everyone predicted the death of professional photography. The prediction landed wrong. The low end died outright: stock libraries, cheap portraits, mass-event coverage went to anyone with a phone and a free editing app. The high end did better than ever — editorial work, photojournalism with access nobody else had, an aesthetic you could not reproduce by buying the same gear. The damage landed in the middle. Small weddings, corporate headshots, real estate listings, the steady unglamorous bulk of the market: not extinction, compression. Prices fell, volume moved to cheaper substitutes, and the survivors climbed up or specialized out.

That compression is the cleanest map I know for what AI-assisted coding is doing to software work. And this half I know from inside: two decades leading dev teams, and now building AI tooling for them.

The comfortable half of the argument

The reassuring version of this is everywhere right now: you were never paid to type, you were paid to think, so AI just frees you to do the valuable part. It's not wrong. It's just the half that's easy to hear. The other half is about the market, not about you.

Judgment, architecture, knowing what breaks in maintenance, deciding what not to build — a model that writes plausible code on command doesn't commoditize any of that. I have watched weeks of confusion land on people who could not read what a capable model generated; the gap was never the tool, and better AI autocomplete does not close that gap.

But "judgment beats typing" answers only a question about skill and dodges the question about market structure. AI doesn't replace developers as a class; it commoditizes a segment. The segment it hits first is the same one the camera hit: the middle. The junior-to-mid tier that lived on CRUD apps, simple integrations, brochure sites, the standard internal tool with a form and a table behind it. That work was always implementation against a known spec, and implementation against a known spec is exactly what a model does cheaply now.

I felt this directly on a side project. I spent many months of evenings building a content pipeline on a visual no-code platform; when AI-assisted coding changed the math, I rebuilt it as proper code in a few weeks. The months were not wasted — they are why I knew exactly what to build. But the same work now costs weeks, not months.

"So the middle just learns to think better?"

This is the obvious objection, and it's worth taking seriously because the answer is where the whole thing turns.

First problem: "learn to think better and survive" doesn't refute the thesis, it confirms it. The claim was never about the people, it's about the work. When someone in the middle develops real architectural judgment, they haven't saved the middle, they've left it. They climbed to the high end. The middle still empties out, by promotion or by exit. A wedding photographer who became a sought-after editorial shooter didn't prove the wedding market survived.

Second problem: "thinking better" isn't a soft upgrade you bolt onto the same job. Going from implementing a spec to deciding what to build, judging tradeoffs, holding the whole system in your head, anticipating the failure that surfaces in production eight months later — that's a change in the muscle being used. Some people build it. Some won't, and some genuinely don't want to; they liked implementation and were good at it. The skill axis is real, but it doesn't pull everyone up by default.

Third problem, and this is the one the reassuring posts never reach: capacity. Suppose everyone in the middle became a strong systems thinker overnight. The market still doesn't need that many architects, security specialists, performance engineers, and trusted advisors. The high end is narrow by definition, which is what makes it the high end. Premium editorial photography never had room to absorb every wedding shooter it displaced.

So when people ask whether "think better" just means "become a consultant," the honest answer is partly. The trusted technical advisor is one exit from the middle, and a good one, but not the only one. Architecture is an exit. Deep security and performance work is an exit. Complex-domain expertise — the kind where you understand the business so well the AI becomes a lever instead of a crutch — is an exit. When a prototype that should take weeks comes together in an afternoon, the speed never comes from the model. It comes from twenty years of knowing the exact problem before the first prompt. The tool doesn't create that position; it amplifies what was already there.

The honest limit of the analogy

I'd be selling you something if I claimed software follows photography like a law. It doesn't. Photography had roughly fixed demand; the number of weddings didn't triple because cameras got cheap. Software might. Total demand for software has grown for forty years, and cheaper production could grow it further, which means some of the displaced middle gets reabsorbed into work that didn't exist before. The wedding market never had that escape valve.

So I won't tell you eighty percent of developers will be unemployed. I don't believe it, and the people who say it are guessing. The defensible claim is narrower and still uncomfortable: middle-tier work commoditizes, value migrates toward the extremes, and you should plan around that rather than hope the middle holds.

For the individual, the move is to climb toward judgment, architecture, and advisory work, not to defend the commoditizing tier by getting slightly faster at it. Speed inside a shrinking band is a losing race against a tool that's cheaper than you and getting better weekly.

For anyone running a technical team or a practice, this is the argument for senior-led work getting stronger. The middle is precisely the layer being liquified. Value concentrates in the people who were never doing middle work to begin with: the ones whose contribution was the system, the tradeoff, the domain, the call about what not to build. That's why this practice is senior-led and founder-run. It is not a positioning choice; it is what the map says to do.

The question to sit with isn't whether you can out-think the AI. You probably can, on a good day. The question is which segment that thinking lives in, and whether that segment will still be there to stand in. Go look at the last five things you shipped. Count how many were implementation against a spec someone else wrote. That number is your exposure.

Originally published at unlockedconsulting.ai.

Can a Non-Coder Become a Coder Just With AI?

Sun, 30 Aug 2026 21:19:12 +0000

My company decided to lean into AI — to let people who had never written code build real software with it. I thought that was the right call, and I still do.

The logic behind the decision seems airtight: tools like Claude Desktop are built to be accessible to non-developers. They abstract the complexity. They turn natural language into working software. But put those tools in front of a capable non-developer, and what tends to follow is weeks of confusion, cluttered repositories, and architectural decisions that look functional but rest on shaky foundations.

I've watched it happen. And the question "can a non-coder become a coder just with AI?" has a more useful answer than yes or no. Yes, they can produce working code. No, they cannot produce maintainable code without understanding how the parts fit together.

The infrastructure reality check

The non-developer gets a real developer's environment: GitHub, Python, Node.js, Visual Studio Code, a database server, an AI assistant on top. The premise is that having that setup is most of the battle. The expectation is immediate productivity.

What actually happens: Git becomes the first obstacle. Branches, commits, pushes, pulls, clones — all of it opaque. The AI makes changes, generates commits, pushes to the repository. But without understanding what's being committed or why, the repository fills with stray commits mixed into legitimate work. Unexpected changes land in branches they shouldn't. The history becomes hard to follow.

Then the local environment problems. Port conflicts. The UI can't reach the API because the ports aren't configured correctly. Services that have to be started, stopped, restarted. Every working session begins with fifteen minutes of troubleshooting that a developer handles automatically, by reflex, but that a non-developer has to solve consciously, from scratch, every time.

The mental model problem

The deeper problem isn't technical. The non-developer doesn't know what an API is, what a database does, where the UI ends and the backend begins. Without that mental model, every AI suggestion looks equally plausible — including the wrong ones. There's no way to evaluate the output, because there's no way to see the architecture.

When the AI suggests connecting the frontend directly to the database, it gets implemented. When it recommends storing user passwords in plain text environment variables, that happens too. The AI isn't being careless. It's responding to prompts that don't include the constraints a developer would apply automatically.

Here is the floor — the five things a non-technical person needs to understand before AI tools help instead of hurt. None of them is about writing code. All of them are about how the pieces relate.

What a database is. Information lives in a structured store, and you don't connect the front end straight to it — for the same reason you don't hand customers the keys to the warehouse.

What an API is for. It's the control layer between the user and the data: it checks who's asking and enforces the rules. When the AI proposes skipping it, that alone tells you something is wrong.

What runs where. Part of any app runs on the user's device and part runs on your servers. Whatever sits on the user's device, the user can see and change — so anything sensitive has to stay on your servers.

What version control is for. Every change has a reason, experiments stay separate from the live system, and what customers use keeps working. Lose that discipline and you lose the record of what changed and why.

Where secrets live. Passwords and keys belong apart from the code, and they differ between a test setup and the real one. Put them in the wrong place and they leak.

These five take a few hours to learn, not months. But without them, AI tools become code generators that produce expensive technical debt.

Necessary, not sufficient

That mental model gets you to better prompts. It doesn't get you to safe output on its own. Even with solid foundations, a non-developer using AI will still face decisions they aren't equipped to make — and left to their own judgment, they'll make those decisions anyway.

The other half of the answer is a constrained environment: guardrails that make the bad decisions impossible rather than merely unlikely — schemas that can only change through migrations, endpoints that must validate input, frontends that can't hold secrets. Building that surface is its own undertaking, and a separate conversation. What matters here is that the mental model comes first. Without it, even the best guardrails are fighting a user who can't see why the rails are there.

The decision in front of a technical leader

The ambition my company started with was the right one. The choice that actually matters comes a step later: how much infrastructure you're willing to build around the tools. That choice isn't binary.

The cheapest path is raw AI tools with light training. Cheap upfront, expensive later: working prototypes that become maintenance liabilities, with technical debt compounding until someone rewrites everything properly.

The middle path is structured tools with foundational training and a constrained environment. Higher upfront, lower long-term — the output is maintainable from day one because the constraints prevent the unmaintainable patterns before they happen.

The third path, and often the most efficient for smaller organizations, is to keep development centralized and use AI to accelerate the team you already have, rather than distributing it across people who can't yet evaluate what it produces.

The path that doesn't work is the first one, chosen in the hope it will somehow work out.

The real question

So the real question isn't whether non-coders can become coders with AI. It's whether your organization can afford the infrastructure that makes it safe — the foundational training, the constrained environment, the deployment and monitoring around it. If you can build that, then yes, non-coders can ship maintainable software with AI. If you can't, you're better off keeping development centralized and making your existing developers faster.

If you do nothing else, do this: train the mental model first, in a few focused sessions, before handing out any AI tools. Five concepts, concrete examples from your own systems. The investment pays back immediately, because every prompt the user writes afterward is a better prompt. They ask for input validation instead of assuming it's optional. They name the environment variables they need instead of hardcoding credentials. They think in endpoints instead of wiring everything to everything.

AI amplifies what's already there. If the user doesn't understand the basics, AI amplifies that gap straight into the systems they ship.

Originally published at unlockedconsulting.ai.

A Clean Score Is Not a Complete Scan: What AI-SLOP Detector v3.8.9 Made Visible

Wed, 26 Aug 2026 12:22:18 +0000

AI-SLOP Detector has changed substantially since v3.8.1, but the most important improvements are not simply more checks.

The detector became better at distinguishing structural risk from legitimate code, better at explaining what it found, better at showing what it did not analyze, and harder for either a human or an agent to over-interpret.

That is the main story of v3.8.9.

The release does not replace the structural score. It puts more evidence around it.

A project result can now tell you not only that its weighted deficit status is clean, but also whether independent findings remain, how much of the source tree was actually analyzed, which supported files were excluded, which source types were unsupported, and whether the optional ML scorer actually participated in the run.

That makes a clean result more useful because its boundary is visible.

Release boundary: This article separates the tagged v3.8.9 release, published August 22, 2026, from follow-up work on main. Anything explicitly marked Unreleased is not presented as part of v3.8.9.

What we actually improved since v3.8.1

When I wrote about v3.8.1, AI-SLOP Detector had started moving beyond detection into operational review.

Cleanup candidates gained confidence, action classes and evidence. Dependency manifests became part of unused-dependency analysis. Architecture review could opt into layered rules without mixing those rules into the scoring model.

The releases that followed concentrated less on adding surface area and more on making those capabilities dependable.

Adaptive initialization became preview-first, separating repository-specific suggestions from the decision to apply them.

The Node package became a typed transport over the Python analyzer rather than a second implementation, reducing the risk of separate interfaces drifting into separate scoring systems.

Human reports gained plain-language metric interpretation and deterministic Next Steps. Machine-readable output gained richer guidance for JSON, MCP and agent consumers.

Cleanup semantics also became stricter. A high-deficit file is no longer sufficient evidence to label something dead code. Duplicate analysis distinguishes exact duplicates from near-identical clone clusters. Manifest analysis became more careful about standard-library imports, development dependencies, monorepo package roots and dependency/import aliases.

The editor integration was tightened too. Refresh now performs a real workspace re-scan rather than merely repainting cached state. Removed or renamed files no longer linger in the sidebar, findings open the exact path rather than matching only a basename, and Quick Fix configuration writes avoid duplicate entries.

These are not dramatic new metrics.

They are the kinds of changes that make an existing detector more dependable in everyday use.

False-positive control became an engineering feature

Using the detector across more repository shapes exposed an important problem: strictness cannot simply mean flagging more things.

v3.8.7 tightened several boundaries where legitimate code could resemble the structural patterns the detector was designed to catch.

Runtime dependency accounting was corrected around TYPE_CHECKING. Vocabulary tables stopped creating artificial jargon inflation. React and TSX structures stopped looking like callback hell merely because they contained nested braces and object literals.

Monorepo package discovery improved. Dependency/import aliases such as grpcio -> grpc and pyyaml -> yaml became recognizable. Similar property accessors stopped being grouped into clone clusters simply because their implementation shape was intentionally repetitive.

Clone grouping itself became more conservative. Instead of allowing a loose chain of pairwise similarities to form a large group, the detector now requires a stronger mutual-similarity relationship and constrains size differences.

During that false-positive reduction pass, the detector's own repository moved from eight deficit files to three, while its weighted deficit score moved from 9.3892 to 6.4186.

Those numbers are useful regression evidence for the known repository.

They are not an external accuracy benchmark.

The more important outcome is that the discovered cases became explicit regression boundaries future versions are expected to preserve.

v3.8.9 makes the scan boundary visible

The largest conceptual improvement in v3.8.9 is that a project result now carries evidence about its own scope.

Previously, an aggregate result could dominate the interpretation:

overall_status = clean

That value is still useful. It tells you that the weighted structural deficit for the analyzed result falls below the applicable project threshold.

But it answers only one question.

v3.8.9 makes several other questions first-class.

The project JSON now exposes finding_summary, scan_coverage, and ml_scoring alongside overall_status.

An illustrative result looks like this:

{
  "overall_status": "clean",

  "finding_summary": {
    "total": 3,
    "affected_files": 2,
    "severity": {
      "critical": 0,
      "high": 1,
      "medium": 2,
      "low": 0
    },
    "score_semantics": "independent_of_weighted_deficit_status"
  },

  "scan_coverage": {
    "analyzed": {
      "total": 84,
      "python": 72,
      "javascript": 9,
      "go": 3
    },
    "excluded": {
      "total": 18
    },
    "unsupported": {
      "total": 4
    }
  },

  "ml_scoring": {
    "status": "disabled"
  }
}

The numbers above are illustrative. The field structure reflects the current project-result contract.

The four fields answer different questions.

overall_status describes the measured weighted deficit.
finding_summary shows independent pattern findings that may still deserve review.
scan_coverage describes the analysis universe: what was analyzed, what was intentionally excluded, and what source types were recognized but unsupported.
ml_scoring tells a downstream consumer whether the optional ML capability was available, disabled or unavailable.

This gives clean a more precise meaning:

clean within the measured structural scoring boundary.

It does not silently mean zero findings, universal language coverage, successful execution of every optional capability, or semantic correctness.

That distinction is now represented in the output contract rather than left to interpretation.

`-include-tests` now has a narrower meaning

Scope visibility also required tightening the behavior around test inclusion.

slop-detector scan . --include-tests

does not mean “ignore every exclusion and scan everything.”

It removes the detector's built-in test-file exclusions.

User-configured ignores remain active. Dependency directories and build artifacts remain excluded.

That makes the option more predictable: expand the normal test boundary without discarding explicit repository policy or artifact exclusions.

Capability absence is now evidence

The optional ML scorer exposed a similar problem.

The deterministic scanner should continue to work even when the ML layer cannot. ML is a secondary signal, not a prerequisite for the core score.

But a missing secondary capability should not disappear silently.

v3.8.9 therefore carries ML availability into the result.

A run with no configured model can report:

ml_scoring.status = disabled

A model or dependency that exists but cannot be loaded can report:

ml_scoring.status = unavailable

with a reason attached.

That distinction matters particularly for machine consumers. An agent reading JSON no longer needs to infer whether the optional scorer actually executed simply because the main scan completed.

The deterministic path survives.

The missing capability remains visible.

Discovery is checked before acceleration is trusted

AI-SLOP Detector can optionally use a Rust helper for faster project discovery.

That optimization created another trust boundary.

If the accelerated walker and the Python discovery path disagree about which files exist, every downstream score is operating on a different input universe.

The current implementation therefore compares accelerated discovery against root-relative Python discovery. If they disagree, the detector uses the Python fallback rather than silently trusting the faster path.

This is a small architectural detail with a large consequence:

correct scoring over the wrong file set is still the wrong result.

Discovery itself belongs in the evidence chain.

Strictness without pretending certainty

AI-SLOP Detector is intentionally strict about structures that often accompany generated-code debt: placeholder implementations, suspicious repetition, disconnected dependencies, fake-complete functions and other forms of plausible-looking incompleteness.

Maximum sensitivity, however, is not the objective.

A detector that marks every repetitive structure or unusual dependency relationship as suspicious quickly becomes noise.

The current policy is therefore to treat false positives as reproducible engineering problems. Legitimate structures can become regression fixtures or strictness cases. Explicit suppressions remain visible rather than rewriting history, and cleanup confidence is treated as prioritization evidence rather than automatic permission to delete or rewrite code.

The opposite boundary matters as well.

Static structure cannot establish semantic correctness.

Code may look structurally healthy and still implement the wrong behavior. Some plausible-looking failures will remain outside the detector's observable signal space.

That is why AI-SLOP Detector is intended to complement runtime tests, conventional linters and human review rather than replace them.

Release verification scope

At the v3.8.9 release boundary:

Command: python -m pytest -q
Result: 472 passed
Scope: the repository's Python regression suite at the release commit
This verifies: contract preservation and known regression coverage
This does not verify: precision/recall across independent repositories, complete language coverage, or external governance validity

A separate target-repository assessment also provided regression context: the target test suite remained green during the assessment.

That evidence is useful operationally because it helps show that the assessment did not leave the reviewed target in an obvious regression state.

It is not treated as evidence of AI-SLOP Detector's precision or recall.

Passing regression tests establish something real. They should not be made to establish something they were never designed to measure.

Reproduce the v3.8.9 result contract

Reproducibility starts by pinning the release.

pip install "ai-slop-detector==3.8.9"

slop-detector scan . --json --output slop.json

Using ==3.8.9 matters here. A command such as >=3.8.9 could install a later release and would no longer reproduce the v3.8.9 execution boundary described in this article.

For a useful first inspection, look at these fields:

overall_status
finding_summary
scan_coverage
ml_scoring

They answer four different questions:

How did the analyzed project score?
What independent findings remain?
What did the detector actually analyze?
Which optional ML capability was present during the run?

That is a more useful inspection surface than a single aggregate quality number.

What v3.8.9 improves — and what it does not claim

v3.8.9 materially improves scope accounting, finding visibility, false-positive boundaries, discovery reliability and machine-readable evidence.

Those improvements are useful now.

They make the detector easier to integrate into CI and agent workflows, easier to inspect when a result looks surprising, and less likely to encourage a reviewer to treat one summary label as the complete story.

The project still does not claim that its structural score has been independently validated across external repositories.

That is a separate research question.

The current validation boundary leaves several questions open: whether geometric aggregation performs better than simpler baselines on independent repositories, whether AST-distribution signals distinguish the intended phenomenon rather than repository-specific confounds, and whether structural coherence contributes useful signal beyond simpler measurements.

Those open questions do not erase the current engineering value.

They define the difference between a deterministic structural-risk instrument that can already produce inspectable evidence and a detector whose general statistical validity has been independently established.

AI-SLOP Detector is currently the former.

What would change our mind?

A stronger external-validation claim would require evidence of a different kind.

The detector configuration and thresholds should be frozen before evaluation. Repository selection should be independent of the project. Ground-truth review should be blinded from detector output where practical. Precision and recall should be measured directly, and the detector should be compared with simpler baselines under the same conditions.

Thresholds should also be evaluated rather than treated as correct simply because they are deterministic.

If that evidence eventually supports a stronger claim, the claim can change with it.

Until then, the current boundary is intentional.

One development change remains outside v3.8.9

At publication time, main also contains an Unreleased architectural refactor that separates the Python analysis core into focused scoring, topology and project-aggregation modules while preserving the existing CLI and result contracts.

core.py remains a compatibility facade, with responsibilities moving into:

core_scoring.py
core_topology.py
core_project.py

That work addresses maintainability of the implementation, but it is not being retroactively presented as part of v3.8.9.

Release state and development state are separate.

What changed most

The v3.8.1 article argued that when code generation becomes cheap, structural trust becomes expensive.

The releases since then made that argument more concrete.

AI-SLOP Detector now has stronger cleanup semantics, tighter false-positive control, more reliable editor state, richer machine-readable output, explicit scan coverage, explicit ML capability state and a verified fallback when accelerated discovery disagrees with the canonical path.

The result is not simply a detector with more features.

It is a detector that tells you more about why its result should be read the way it is.

AI-SLOP Detector v3.8.9 does not try to turn a structural score into a universal verdict. It makes that score more useful by showing the evidence around it: what was found, what was analyzed, what was excluded, and which capabilities actually participated in the run.

That makes the detector easier to inspect, easier to integrate into automated workflows, and harder to over-interpret.

External validation remains a separate step.

The product can still provide useful structural evidence before that step is complete — as long as the boundary stays visible.

AI-SLOP Detector: v3.8.9

Stable release: August 22, 2026

Repository: flamehaven01/AI-SLOP-Detector

v3.8.9 release/tag: v3.8.9

Release changelog: CHANGELOG.md at v3.8.9

Validation boundary: docs/VALIDATION.md

Two Lessons from Building AI Resume Tools and Choosing Platforms

Sun, 23 Aug 2026 12:04:30 +0000

This week's build log covers two products and one decision framework. They look unrelated, but together they answer the two questions every founder faces: how to build the right product, and where to show up.

Lesson 1: AI Resume Tools Are Not About "Rewriting"
Most AI resume tools just make your experience sound better. But here's what HR actually cares about: does your experience match this specific role?

So we built a different kind of AI resume builder. Its goal isn't to generate a "looks impressive" resume — it's to optimize your content for a target position.

The flow is simple: upload your PDF resume (text-based PDFs only for now), then tell the AI what role you're applying for.

Same experience, different roles. Applying for content operations? The AI focuses on content strategy, user growth, channel management. Applying for product operations? It highlights requirements analysis, project collaboration, data skills. Different roles need different stories.

Once the analysis is done, the optimized result opens in an editor. You can see what the AI changed, why it changed it, and your match score for the target role. Don't like a change? Roll it back. Your resume, your control.

When you're done, you can optionally let it enter the talent pool. Then download the PDF — a resume optimized for the job you want.

The tool is in beta. Approved users get 600 credits daily. Beta participants get lifetime monthly credits — 3 free AI resume builds.

4en.png

Lesson 2: AI Resume Screening — Save HR from the Grind
Every HR person knows this pain: a job posting goes live, and the resumes pour in. Open, scan, judge — repeat dozens or hundreds of times. The first pass is the most time-consuming.

So we built an AI resume screener to help companies get through the first round faster.

Use it the same way. Enter the target role and job description first — this is critical because the AI uses it to evaluate candidate fit. Then upload candidate resumes. Batch upload is supported.

Upload done? The AI starts analyzing. Leave the page, come back later.

The final output: every resume gets a match score. The top 10 candidates get a deeper AI analysis. Multiple layers of judgment to reduce the chance of a single bad call.

We also take data security seriously. By default, the tool doesn't read private information from resumes. Efficiency gains shouldn't come at the cost of trust.

The screener is also in beta. Beta participants get lifetime monthly credits — 3 rounds of screening 50 resumes each. We'll iterate based on early feedback.

Product direction is set. Tools are built. But there's one more question — and it might matter more than the product itself.

Lesson 3: Not All Traffic Is Worth Chasing
When I started making content, my thinking was simple: post everywhere. Ten platforms isn't enough? Try twenty.

Turns out, that's wrong.

Some platforms have no traffic. Some have unstable rules. So I started rethinking: a content platform isn't just a traffic channel — it's where your assets live.

Traffic matters, of course. It validates whether your content is valuable, whether there's a market, whether your brand has a chance. So step one is finding where people actually like your content.

But after traffic, there's a second question: stability.

Most people only look at how many views a platform can bring. Few ask: can I build on this platform long-term?

Some platforms are clear: "no external links" — fine, play by the rules. You know where the boundaries are. But others? Rules are vague. Allowed today, restricted tomorrow. You invest months, then your account vanishes.

For a personal brand, that's a huge risk. Because in the content era, you're not leaving behind a view count. You're leaving a trail of digital footprints. Search engines index them. Users see them. Partners judge you by them. A vanished account leaves an incomplete brand impression.

So my platform evaluation framework came down to two questions:

First, will this platform give your content a fair chance? Second, is it worth building on long-term?

Traffic determines growth speed. Stability determines asset value.

This applies to every content creator, not just founders. Keep the platforms that give real feedback, have clear rules, and reward long-term building. Don't chase "where the traffic is" blindly.

Short-term traffic matters. But long-term assets matter more.

The Takeaway
Three stories this week, one thread: figure out how to reach users (resume tools as entry points), how to serve them once they arrive (resume screening as a service), and then decide where to build for the long haul.

None of these steps are big. But every one is laying groundwork.

Don’t Automate the Fun

Wed, 22 Jul 2026 16:40:17 +0000

I approved my own pull request and felt nothing. Not proud. Just bored. And that boredom turned out to be the most useful signal I’ve gotten about AI and my own work.

For about a year I’d handed more and more of my job to AI. It worked — features shipped, they passed review, they did what the ticket asked. But if you’d stopped me and asked how any of it actually worked, or why it was built this way and not another, I’d have had to open the chat log to tell you. I wasn’t a builder anymore. I was a not-very-good reviewer of my own work.

Here’s the part nobody warns you about: over-delegating doesn’t just make your work fragile. It makes it boring. The interesting part of this job was never watching code appear — it was the wrestling, the figuring-out, the moment a messy problem clicks into a shape in your head. I’d automated away exactly that. I’d automated away the fun.

My first instinct for climbing back was wrong: use less AI. That’s not it. I didn’t want to go slower, and the speed is real. The problem was never how much AI I was using. It was that I’d taken my hands off the work and let the machine carry it wherever it drifted. The fix wasn’t less. It was flipping who leads.

Me out front doing the thinking — the understanding, the decisions, the trade-offs, the design. The model right behind it, amplifying: fetching what I don’t know, pressure-testing what I do, turning my decisions into working code faster than I could alone. Same tool. Same speed. Opposite posture. And a workday went back to feeling like solving something instead of supervising something.

This isn’t an anti-AI video. It’s the opposite of using less. It’s about keeping your hands on the one part that was ever really yours.

If you want the practical version, the companion piece turns this into an actual workflow: I Delegated My Thinking to AI. Now I’m Taking It Back. — ten steps from problem to ship, built around I think, AI fetches. And underneath both of them sits The Impossible, on what a skateboard trick filmed at 1000 frames per second taught me about the part of the job that was always ours.

Don’t automate the fun. Automate everything around it.

The post Don’t Automate the Fun appeared first on sudoish.

The Hidden Cost of AI Vibe Coding

Tue, 21 Jul 2026 11:08:48 +0000

AI has completely changed how we build software.

Need a login page?

AI can generate it.

Need a REST API?

Done.

Need an entire SaaS boilerplate?

Just ask.

It feels like software development has become incredibly fast.

But there's a hidden cost that many developers don't notice...

👉 AI Vibe Coding.

Let's talk about it.

💡 What is Vibe Coding?

Vibe Coding is when developers rely heavily on AI to generate code without fully understanding what it does.

The workflow usually looks like this:

Ask AI to write code
Copy it
Paste it
Run it
If it works... move on.

No deep understanding.

No questioning.

Just trusting the output.

🚀 Why Everyone Loves It

To be fair, AI is amazing.

It helps developers:

Build prototypes faster
Learn new frameworks
Reduce repetitive work
Fix simple bugs
Generate boilerplate code

For many tasks, it's a huge productivity boost.

The problem isn't AI.

The problem is using it without understanding the code it generates.

⚠️ The Hidden Costs

1. You Stop Reading Your Own Code

If AI writes most of your code, it's easy to skip reading it carefully.

Until something breaks.

Then you realize...

You don't actually know how it works.

2. Debugging Becomes Harder

When a bug appears, AI isn't sitting beside you.

You are.

If you don't understand the implementation, fixing production issues becomes much more difficult.

3. Security Risks

AI can generate working code.

But "working" doesn't always mean "secure."

Small mistakes like:

Missing input validation
Weak authentication
SQL injection risks
Exposed secrets

can easily slip into production if you don't review the output.

4. Technical Debt Grows Faster

AI can generate features in minutes.

But if every feature follows a different pattern, your codebase slowly becomes inconsistent.

Months later, maintaining it becomes a challenge.

5. Learning Slows Down

If AI solves every problem instantly...

You may stop asking why.

And that's where real learning happens.

🧠 AI Should Be Your Pair Programmer

The best developers don't treat AI like an autopilot.

They treat it like a teammate.

They ask:

Why did you choose this approach?
Is there a better alternative?
What are the trade-offs?
Can you explain this logic?

That turns AI into a learning tool instead of just a code generator.

🎯 The Real Skill

In the AI era, writing code is becoming easier.

Understanding code is becoming more valuable.

The developers who stand out won't be the ones who copy the fastest.

They'll be the ones who can:

Review AI-generated code
Spot hidden issues
Make better architectural decisions
Know when the AI is wrong

💡 Final Thought

AI Vibe Coding isn't bad.

Blind AI Vibe Coding is.

Use AI to speed up your workflow.

But don't let it replace your curiosity.

Because one day, that AI-generated code will fail in production...

And the only person who can fix it will be you.

💬 Be honest... have you ever copied AI-generated code, watched it work, and thought, "I'll understand it later"? 😅

AI #VibeCoding #SoftwareEngineering #Programming #Developers #LLM #Coding #ArtificialIntelligence #Tech #DeveloperLife

AI Didn’t Take Your Job – It Revealed It

Thu, 16 Jul 2026 17:44:14 +0000

In 1982, skaters were talking about a trick that couldn’t be done. The board had to wrap vertically around your back foot — a full rotation on an axis no skateboard wants to spin on. They didn’t even bother naming it properly. They just called it the impossible.

Then Rodney Mullen did it. Decades later, physicists put a 1000-frames-per-second camera on that trick and found something that genuinely changed how I think about my career as a software engineer.

Because remove the human, and the board reverts to what it naturally wants to do — the average, the probable, the thing it’s done a thousand times. That’s the machine we’re all working with. An LLM without your hands on it falls back to the statistically dominant answer. The foot on the board is the judgment: the design, the trade-offs, knowing what’s worth building at all. And it was never the typing.

That’s what this video is about — the quiet crisis in our profession that isn’t really about AI taking jobs, but about identity, and what a skateboard trick from 1982 taught me about the part of the job that was always ours.

If you want to go deeper, two companion pieces sit underneath this one: I Delegated My Thinking to AI. Now I’m Taking It Back. on rebuilding a workflow around I think, AI fetches — and The Developer Identity Crisis on why the ground felt like it disappeared in the first place.

Keep your foot on the board. That’s the job now. It kind of always was.

The post AI Didn’t Take Your Job – It Revealed It appeared first on sudoish.

The Vibe Coding Revolution: Building Your First AI Application with Google AI Studio and Antigravity

Wed, 24 Jun 2026 03:29:22 +0000

"We're entering an era where the hardest part of software development isn't writing code—it's knowing what to build."

The AI landscape has changed dramatically over the last year.

A few months ago, building an AI application meant stitching together APIs, setting up vector databases, managing prompts, and deploying infrastructure. Today, you can go from a blank screen to a working prototype in less than an hour.

Welcome to the age of Vibe Coding.

It's not about abandoning software engineering. It's about accelerating creativity by letting AI handle repetitive implementation while you focus on solving real problems.

And Google's latest ecosystem—Google AI Studio and Antigravity—is making this easier than ever.

Let's explore what this revolution looks like.

What Exactly is Vibe Coding?

Vibe Coding is a development workflow where you describe your idea in natural language, iterate rapidly with AI, and refine your application through conversation rather than writing every line of code manually.

Think of it like this:

Instead of saying:

"Let me architect the backend first."

You say:

"Build me a dashboard that summarizes YouTube videos and lets users ask follow-up questions."

Within minutes, you have a functional prototype.

AI becomes your pair programmer.

You're still the architect.

You're simply moving faster.

Why This Changes Everything

Traditional development often looks like this:

Plan architecture
Create project structure
Configure environments
Write boilerplate
Build UI
Connect backend
Debug integrations
Deploy

With modern AI tools, many of these steps become conversational.

Instead of spending hours on setup, developers spend more time experimenting.

The result?

More prototypes.

More innovation.

More products.

Google AI Studio: Your AI Playground

Google AI Studio removes much of the complexity involved in working with Gemini models.

Instead of worrying about infrastructure, developers can immediately start experimenting with prompts, structured outputs, multimodal inputs, and function calling.

Some capabilities include:

Rapid prompt testing
Image understanding
Video analysis
Audio processing
Tool calling
JSON outputs
Streaming responses
Model comparisons

It's essentially the fastest way to explore what's possible with Gemini.

For beginners, it's an excellent learning environment.

For experienced developers, it's a rapid prototyping platform.

From Prompt to Product

Imagine you want to build a meeting assistant.

Instead of weeks of planning, your workflow becomes:

Step 1:
Upload meeting recordings.

Step 2:
Ask Gemini to summarize discussions.

Step 3:
Extract action items.

Step 4:
Generate follow-up emails.

Step 5:
Deploy.

Most of the complexity disappears.

Your energy shifts from implementation to product design.

Meet Antigravity: Google's Mission Control for AI Agents

While Google AI Studio helps you build AI experiences, Antigravity introduces a powerful new concept:

Managing autonomous AI agents.

Think of Antigravity as a control center where multiple AI agents collaborate on complex workflows.

Instead of one giant AI prompt, you create specialized agents.

For example:

Research Agent

↓

Planning Agent

↓

Coding Agent

↓

Testing Agent

↓

Documentation Agent

Each agent has its own responsibility.

Together, they solve larger problems.

This is remarkably similar to how real engineering teams operate.

Why Autonomous Agents Matter

Single prompts eventually reach their limits.

Complex applications require:

memory
planning
retries
external tools
API integrations
decision making

Autonomous agents can:

✔ Search documentation

✔ Read files

✔ Execute code

✔ Call APIs

✔ Validate outputs

✔ Correct mistakes

✔ Continue long-running tasks

Rather than asking AI one huge question, you orchestrate multiple intelligent workers.

Building Your First AI Application

Here's a practical project idea for beginners.

Project: Smart YouTube Summarizer

Users paste a YouTube URL.

The application:

extracts transcript
summarizes the video
identifies key insights
generates study notes
answers questions

Now imagine extending it further.

A Research Agent searches related articles.

A Fact Checker validates claims.

A Quiz Generator creates interview questions.

A Flashcard Agent prepares revision material.

Suddenly your simple summarizer becomes a complete learning platform.

The Shift from Coding to Orchestration

Developers aren't becoming obsolete.

Their role is evolving.

Instead of writing every algorithm manually, developers now design:

workflows
prompts
agents
evaluation systems
user experiences
integrations

This is orchestration.

And it's becoming one of the most valuable engineering skills.

Rapid Iteration is the New Superpower

The biggest advantage of Vibe Coding isn't writing less code.

It's testing more ideas.

Imagine building five startup prototypes in a weekend.

Most won't succeed.

One might.

That's the power of reducing friction.

Best Practices for Vibe Coding

Don't rely entirely on AI.

Use AI to accelerate—not replace—engineering judgment.

A few habits that make a huge difference:

Start with small prototypes.
Validate ideas before optimizing.
Keep prompts modular.
Test outputs thoroughly.
Review generated code.
Measure performance.
Think about security early.
Add human feedback loops.

The fastest prototype isn't always the best product.

What's Next?

We're witnessing a transition similar to the rise of cloud computing.

Years ago, developers stopped managing physical servers.

Today, they're beginning to stop writing repetitive boilerplate.

Tomorrow?

They'll orchestrate intelligent systems made up of multiple collaborating AI agents.

Google AI Studio lowers the barrier to experimentation.

Antigravity expands what's possible with autonomous agents.

Together, they represent more than new tools—they represent a new way of building software.

Final Thoughts

Vibe Coding isn't about replacing developers.

It's about amplifying them.

The future belongs to builders who can combine creativity, product thinking, and AI-powered development into rapid experimentation.

Whether you're a student building your first app, a startup founder validating an idea, or an experienced engineer exploring autonomous agents, there's never been a better time to start.

The next breakthrough application may not come from writing thousands of lines of code.

It may begin with a single prompt.

And that is the real revolution.

Vibe Coding Isn't the Problem. Not Understanding the Stack Is.

Sat, 20 Jun 2026 14:22:11 +0000

I am not a developer by profession or practice. I'm a systems engineer with 20 years of experience. I have never been a developer or written any real code -- I barely wrote scripts -- but since AI came out I have come out of my comfort zone and started building again.

What I see in all the "vibe code everything" problems happening right now is that people are developing blindly. They don't understand the full stack. They see it as frontend and backend, when the full stack actually looks more like this (very partial list, just to make the point):

Source control
Frontend application layer
Backend application layer
API layer
Authentication and authorization
Database layer
Cache layer
File/object storage
Background jobs and messaging
Web server / reverse proxy
DNS

There are several other layers under that, and this is exactly why vibe coding fails -- people don't understand the stack. I have spent my entire career building the foundation and the stack that developers use, and sometimes destroy. So when I vibe code, it's different: AI is only writing the application code. I'm still building the entire stack underneath it.

The other piece is knowing all the parts well enough to ask questions and push back. When the AI makes a choice, I can ask why it chose that, or whether something else would be better. I also don't open a session with "build me X." I spend about 30 minutes talking through the process and the ideas first, then have Claude generate the best prompt for itself, and hand that over to Claude Code.

So to be clear: vibe coding is not a bad thing. It only becomes a problem when you don't understand the foundation and just want a single siloed change made with no idea what it touches.

What do you think?

What 30 Days of Refactoring AI-Generated Code Taught Me About Vibe Coding

Sat, 23 May 2026 13:54:55 +0000

An honest, no-hype look at what happens when you let AI build your whole app — and then try to refactor it.

Photo by Steve A Johnson on Unsplash

TL;DR

I spent 30 days vibe coding a web app from logo to launch using only AI — no manual code.
Total spend: ~$1.45 in Claude API tokens, plus two full Claude Code sessions in one night.
The app worked. The codebase didn't. I sunset the project after the AI couldn't understand its own code.

A few months back, I started vibe coding to build a web application that helps users practice hard conversations — things like asking for a raise, prepping for an interview, or having difficult talks at work.

To really test the vibe coding craze, I used AI for everything from the logo to the final publish. Here's what I learned, honestly and from my own perspective.

The Experiment: Building a Real App With Zero Manual Code

I decided to build a web application with no login and no paywall. Users could just jump in and test how it works. No database to save user information — all conversations and decisions are handled by Anthropic's API.

And yes, before you scream it at me, I'll admit it: just another AI wrapper. :)

I used Next.js paired with Vite — an obvious choice from Claude. React.js and Angular were on the table, but I went with Next since Claude recommended it.

The questions are AI-generated. It's essentially a conversation between you and the AI.

The Budget: How Cheap Vibe Coding Actually Is

My budget was very low — like, super low. I spent $5 on Claude API tokens, and I shared those same tokens across a few other small projects too.

For the AI voice, I just used the browser's native text-to-speech. It's a bit robotic, but it does the job.

How I Actually Used Claude Code

I spent one full night on this experiment across two complete Claude Code sessions (5 hours + 4 hours), staring at the limit screen waiting for the 5-hour reset and compacting context here and there.

More than 80% of my prompts were written by me and polished with Claude Chat. I never wrote a vague prompt — not once.

Sample Prompt:

Act as a Senior Full-Stack Developer and UI/UX expert.

We are going to build a [describe the app/feature, e.g., real-time cryptocurrency dashboard].

Tech Stack: [e.g., React, Tailwind CSS, and Node.js].

UX/UI Style: [e.g., A minimalist, neon-dark mode aesthetic with glassmorphism elements, inspired by cybercore design].

Key Features:
1. [Feature 1, e.g., Live ticker fetching from an API]
2. [Feature 2, e.g., Interactive drag-and-drop dashboard widgets]
3. [Feature 3, e.g., Responsive layout for mobile and desktop]

Execution Guidelines:
1. First, analyze the requirements and output a step-by-step implementation plan.
2. Wait for my approval before proceeding with the code.
3. For every file you create or modify, ensure the code follows SOLID principles and includes structured, typed error handling.
4. Before finishing your response, verify your code against my initial goals.

Let's start by outlining the implementation plan.

One user session with Claude Sonnet 4.6 cost me roughly $0.05. So in the testing phase alone, I burned about $0.95. Real users — mostly friends — burned another $0.50.

Day 1: Reading the Code I Didn't Write

Everything seemed fine until I sat down to actually read the code.

On day one, I started noticing Claude's architectural choices. It was a Vite build alongside Next.js. I checked the README and package.json — there was a Next.js version mismatch.

It used Tailwind for styling, but there were a huge number of classes, many of them completely unnecessary. On top of that, it wrote custom CSS in the stylesheet for the same things it had already styled with Tailwind.

I opened one component and found it stuffed with redundant code — almost jargon for a simple task. Something that should've taken 10 lines was written in 45.

Redundant classes were everywhere, and it leaned on absolute positioning instead of using proper media queries.

Where the Refactor Fell Apart

Since I couldn't understand what the AI had written, I started refactoring it with the same AI. Even with context compacting and a CLAUDE.md file in place, it lost the thread after a while. It started overthinking, made the code more complicated, and turned it even less readable.

If I didn't know what it wrote, and it couldn't keep the code consistent — and didn't even know what it was writing — there was no path forward.

Thanks to hallucinations, I now understood nothing in the codebase. I decided to stop further production and sunset the project to move on to something else.

The Verdict: Is Vibe Coding Worth It?

I'm not completely against vibe coding — it's just not my cup of tea. I still use AI as a helping tool, not to build complete web applications.

Here's where AI actually earns its keep in my workflow:

Dataset generation for testing projects — it's great at cooking things up.
Error finding — then I cross-verify with Stack Overflow and Reddit communities before implementing fixes.
Boilerplate and breath-taking low-effort work — the stuff that drains hours without adding value.

These tools aren't copilots. They help you here and there — but they won't build you a cool web application that lasts for years.

If you've tried vibe coding yourself, I'd love to hear how it went. Drop a comment, and if this saved you from burning $5 the way I did, a like wouldn't hurt either.

Why Most Vibe Coded SaaS Apps Fail in Production (Even When They Work Perfectly Locally)

Tue, 19 May 2026 14:30:13 +0000

Most early-stage SaaS projects don’t fail because the idea is bad.

They fail because the code was never designed for production in the first place.

This is especially common in what I call “vibe coding”:

Shipping fast, copying patterns, and assuming “it works” means “it’s correct”.

It usually leads to silent system-level problems that only appear later.

The illusion of working software

A common pattern looks like this:

Authentication works
APIs respond correctly
UI behaves as expected
No errors in development

So everything feels “done”.

But production environments expose a different reality.

Where things quietly break

Most issues are not obvious bugs.

They are design oversights like:

insecure token handling
hardcoded secrets
missing validation layers
trusting frontend input
logging sensitive data unintentionally

Individually, they don’t break the app.

Together, they break trust in the system.

The real problem: mindset

The issue isn’t technical ability.

It’s the development approach:

Build feature → verify it works → move on.

Without asking:

what happens under load?
what happens if logs leak?
what happens if inputs are manipulated?
what happens at scale?

Production thinking vs vibe thinking

Vibe coding focuses on:

speed
output
visible success

Production engineering focuses on:

failure modes
security boundaries
system behavior over time
controlled exposure of data

Both can produce working apps.

Only one produces stable SaaS products.

What changes everything

The shift happens when you stop asking:

“Does this work?”

And start asking:

“Where does this break?”

That single question changes how you design everything from authentication to architecture.

Final thought

Most SaaS failures are not sudden.

They are accumulated design decisions that were never revisited.

Fixing that starts early, not after launch.

AI Coding: Architecture or Archaeology?

Tue, 12 May 2026 06:20:58 +0000

One of the loudest claims around AI coding tools is that one developer can now do the work of a whole team. Ship features in hours. Replace weeks with prompts. Move 10x faster.

Well, maybe. But only if you pretend that software development is mostly typing code. It isn't.

For any system more complex than basic CRUD, the hard part is not producing source files. The hard part is knowing what the source files must preserve.

The model. The boundaries. The contracts. The states. The invariants. The failure modes. The tests that actually prove something. The decisions that stop the system collapsing under its own ambiguity six months later. AI does not remove that work.

It can help draft it. It can challenge it. It can produce options. It can fill in boilerplate once the shape is clear. But it cannot own it.

If you let the tool discover the model by generating code, you don't get architecture. You get archaeology. Later, someone has to dig through the result and work out what assumptions accidentally became real. That's not acceleration. That's debt with better autocomplete.

That's the difference between using AI as a tool and letting AI smear decisions across a codebase. For production systems, modeling is not optional. Correctness is not optional. Evolvability is not optional.

So no, AI coding agents do not make software engineering disappear. They make weak engineering visible faster. And in the hands of a good engineer, they can be useful. Sometimes very useful.

Vibe coding got you here. Now what?

Mon, 11 May 2026 12:30:00 +0000

TL;DR: Vibe coding ships fast, but it often fails to preserve the reasoning behind product behaviors — and agents refactoring later will “reasonably” change things users rely on. A lightweight behavior spec (.pbc.md) makes “what must happen / must not happen” explicit so future you (and future agents) know what to protect, starting with high-risk modules like billing and auth.

Vibe coding works. If you've used it seriously, you know this. You describe a feature, the model drafts it, you push it. Things that used to take a day take an hour. You ship faster than you ever have.

The problem isn't the speed. The problem is what gets left behind.

What "left behind" means

When you build normally — even scrappily — the reasoning behind a decision usually ends up somewhere. In a comment, a commit message, a Slack thread, a ticket. Imperfect, but traceable.

When you vibe code, you're in a flow state. You describe what you want, the model gives you something close, you adjust, you ship. The gap between intention and implementation is so small that writing it down feels redundant.

Weeks later, you have a product that works but you can't fully explain why it works the way it does.

Not the code — you can read the code. The reasoning. Why does the cancellation flow work like this? Why is the grace period five days and not seven? Why does the export fail silently on empty results instead of returning an error?

The code remembers what you built. It doesn't remember why.

Why this compounds with AI coding agents

The original vibe coding problem — reasoning drift — is bad on its own. AI coding agents make it worse in a specific way.

Agents don't just read your code. They make inferences about intent. When you ask Claude Code or Codex to refactor a module, they read the existing implementation and decide what behavior to preserve and what to change. Without explicit constraints, that decision is partly guesswork.

The agent isn't being careless. It's doing exactly what you asked. But it's filling in missing context with reasonable-looking assumptions — and reasonable assumptions about code aren't the same as correct assumptions about product behavior.

The result: a refactor that passes tests and breaks something real. An "improvement" that changes behavior your users depend on. A simplification that removes an edge case that was load-bearing.

You can't blame the agent for this. The rules were never written down.

The missing layer

There's a layer between "what the code does" and "what the product promises" that most teams never formalize. PRDs describe intent. Tests verify implementation. Neither one captures the behavior spec — the durable record of what your product guarantees and why.

For teams that have been building for years, this layer lives in accumulated memory. For vibe-coded products, it often doesn't exist at all.

That's the gap. And the longer you wait to address it, the more expensive it gets.

What to do about it

You don't need to slow down to fix this. You need a format that fits the way you actually work.

That's what behavior specs are — formally Product Behavior Contracts (PBC) — a lightweight Markdown format for capturing what your product promises to do. Not a PRD. Not tests. Not Gherkin. Just the smallest artifact that makes product reasoning explicit and version-controlled.

The key is the level of abstraction. A behavior spec doesn't describe the code — that changes with every refactor. It doesn't describe the strategy — that's too vague for agents to act on. It captures the decision: "Grace period is 14 days. Not configurable per plan. No data deletion during grace." The part that stays true even if you rewrite the module from scratch.

The pattern is:

PRD explains why (temporary — dies after shipping). PBC specifies what must remain true (durable — lives as long as the product does). Code and tests prove how (changes constantly).

A .pbc.md file sits in your repo. It documents behaviors, rules, edge cases, and the decisions behind them — in plain Markdown your whole team can read. It's structured enough that tools can parse it, lightweight enough that you'll actually maintain it.

The goal isn't to slow down the vibe. It's to leave something behind for future you — and for every agent that touches your codebase next.

Start small

You don't need to spec the whole product at once. Start with the module that would cause the most damage if an agent got it wrong. Billing. Auth. Entitlements.

Write down three things for each behavior: what must happen, what must not happen, and the edge cases that matter. That's it. That's your behavior spec.

Vibe coding got you here. A behavior spec is how you stay here.

If you want to understand the deeper problem, read The gap between what your product does and what your team thinks it does. For what a behavior spec actually looks like, see What is a Product Behavior Contract?.

The PBC spec is open source at github.com/stewie-sh/pbc-spec. Stewie is the product being built on top of it — join the beta waitlist if you want early access.

PC-0005: Truth Must Be Enforced, Not Assumed

Sun, 26 Apr 2026 05:29:02 +0000

I. Executive Assertion

The Sovereign Bureau enforces truth as a runtime condition.
Only states that satisfy constraint are admitted to the record.

There is no distinction between stored data and valid data.
A state that violates constraint is not degraded, deferred, or corrected.

It is refused.

II. Situation

PC-0004 established a self-healing system through agentic governance.
However, self-healing without enforced boundaries permits invalid states to exist temporarily.

This introduces a failure condition:

A system may appear governed while admitting contradiction.

Such systems rely on documentation, convention, or delayed validation.
Their records cannot be treated as authoritative.

III. Complication

Without deterministic enforcement:

Contradictory states coexist
Validation becomes optional
Ingestion outpaces integrity
Corruption remains undetected

This condition is not instability.
It is accumulation.

Governance, in this state, is descriptive.
It does not constrain reality.

IV. Resolution: Constraint Sovereignty

The Bureau resolves this by enforcing Constraint Sovereignty:

A system is sovereign only if it can refuse invalid reality.

Constraint is not advisory.
It defines the boundary of existence within the system.

Constraint Classes

Admissibility Constraints
Define what may enter the system boundary
Structural Constraints
Define the required shape and datatype of each record
Relational Constraints
Define permissible semantic relationships within the graph

These constraints are complete.
No valid state exists outside them.

V. Enforcement Mechanism: SHACL as Constitution

The Bureau encodes its law using SHACL (Shapes Constraint Language).
The ontology is not descriptive.
It is executable.

Constitutional Shapes

padi:VesselShape
  a sh:NodeShape ;
  sh:targetClass padi:Vessel ;
  sh:property [
    sh:path padi:hasIdentifier ;
    sh:datatype xsd:string ;
    sh:minCount 1 ;
  ] .

padi:AssignmentShape
  a sh:NodeShape ;
  sh:targetClass padi:Vessel ;
  sh:property [
    sh:path padi:assignedTo ;
    sh:class padi:Operator ;
  ] .

Enforcement Outcome

A vessel without an identifier is not incomplete
A vessel assigned outside the permitted class is not conditionally valid

These states are not recorded.

There are no partial truths in the Bureau.
Only compliant states enter the record.

VI. Validation System: Deterministic Auditing

Validation is continuous.
There is no interval in which the system is unexamined.

The Liaison executes a fixed audit sequence:

Pre-Ingestion Gate
Non-conforming data does not cross the boundary
Conservation Pass
Only lossless normalization is permitted
SHACL Enforcement
Full graph validation against constitutional shapes
Ledger Registration
Immutable recording of validation outcomes
Pre-Push Gatekeeping
Invalid states do not propagate

This system does not approximate correctness.
It maintains it.

VII. Resulting State: From Data to Law

Under Constraint Sovereignty:

The system does not manage data.
It maintains law.

System Guarantees

No Invalid State Persists
Contradictory or malformed triples do not enter the record
Full Constraint Compliance
All nodes conform to enforced structure and relation
Deterministic Lineage
Every mutation is recorded with its validation state

VIII. Architectural Implication

In conventional systems, truth is inferred and revisable.

In the Sovereign Bureau, truth is:

Encoded in constraint
Evaluated at runtime
Enforced without exception

There is no semantic drift.
There is no ambiguity.

The record does not adapt to reality.
Reality is admitted only if it conforms to the record.

Key Takeaways

Sovereignty is the ability to refuse invalid states
Constraint defines the boundary of system reality
Validation is continuous and non-optional
SHACL operationalizes enforceable law
Truth exists only where constraint is satisfied

Series Continuity

PC-0001: Deterministic Execution
PC-0002: Causal Integrity
PC-0003: Governance Layer
PC-0004: Agentic Governance (The Foreman)
PC-0005: Constraint Sovereignty (The Laws) ← Current
PC-0006: Cryptographic Verifiability (The Seal)

Closing Record

The system does not request correctness.
It does not assume compliance.

It admits only what satisfies constraint.

Everything else remains outside the record.

PC-0001: The Architecture of Deterministic Systems — Execution Layer

Wed, 22 Apr 2026 18:44:28 +0000

Taxonomy Classification

Domain: AI Systems Architecture
Concept: Deterministic Execution Systems
Abstraction Level: System-level
Evidence Strength: Applied
Reliability Status: Proposed → Validated

Node Path:
Cognitive Systems → AI Systems Architecture → Deterministic Execution Systems

Modern AI Systems Generate Outputs. They Do Not Maintain Systems.

Large language models can produce coherent responses at scale. However, they lack a fundamental property required for system reliability:

Deterministic execution.

Without determinism, outputs cannot be guaranteed, reused, or validated consistently.

The Hidden Failure: Non-Deterministic Behavior

Consider a simple prompt:


Input: "Define system architecture"

Two executions:


Run 1 → "A structured framework for system components"
Run 2 → "A conceptual model describing system organization"

Both responses are valid.

Neither is guaranteed.

There is no structural constraint ensuring consistency across executions.

Why This Matters

In traditional systems:

The same input produces the same output
Execution paths are predictable
Results are verifiable

In contrast, AI systems:

Produce probabilistic outputs
Lack enforced structure
Cannot guarantee repeatability

This makes them informational tools, not reliable systems.

The Execution Layer Problem

The issue is not at the model level—it exists at the execution layer.

Current AI systems lack:

Structural validation
Persistent knowledge representation
Constraint enforcement

Without these, outputs remain stateless artifacts, not system components.

A Minimal Deterministic Intervention

Determinism does not require replacing models.

It requires introducing structure at execution time.

Example: Output Validation (Python)

def validate_output(output, schema):
    assert "id" in output, "Missing identifier"
    assert output["type"] in schema["allowed_types"], "Invalid type"
    return True

This enforces:

Identity
Type constraints
Structural validity

Example: Structural Query (SPARQL)

SELECT ?s WHERE {
  ?s <https://padi-standard.org/ns/core#hasJurisdiction> "GLOBAL" .
}

This enables:

Deterministic retrieval
Consistent filtering
Structured knowledge access

Embedded Taxonomy (Content-Level Prototype)

This article implements a minimal taxonomy layer:

Domain classification
Concept mapping
Node path hierarchy

These elements simulate a structured knowledge system within standard content.

System-Level Implications

With minimal structure:

Outputs become addressable nodes
Knowledge becomes persistent
Execution becomes constrained

This transforms:

Generation → Organization
Responses → System components
Information → Validated knowledge

Connected Reading

Ontology enforcement in systems → Article 2
Contradiction detection and validation → Article 3

Prototype Access

A minimal executable taxonomy prototype (TTL + SHACL + validation script) is available:

[https://peculiarlibrarian.github.io/peculiar-catalog/feed.xml[\]

]1

Closing

Determinism is not a model feature.

It is a system property.

Until AI systems enforce structure at the execution layer, they will remain generators—not systems.

Machine Metadata
{
"id": "PC-0001",
"title": "The Architecture of Deterministic Systems",
"layer": "execution",
"graph_role": "root",
"state": "published",
"depends_on": [],
"edges_to": ["PC-0002"],
"truth_anchor": "DOI 10.5281/zenodo.18894084"
}

This article is part of a structured knowledge series exploring:

Knowledge Representation
AI Systems Architecture
Information Integrity
System Design Patterns

Each piece contributes to a semantically organized, cross-linked knowledge layer.

An AI Benchmark That Tests Real Coding Workflows

Sun, 19 Apr 2026 19:27:43 +0000

Developers face a real choice: pick a coding model or agent based on synthetic benchmarks that look great but do not predict actual project work. The problem is no longer whether models can score well on those benchmarks; it's whether those scores still mean anything.

Today's benchmarks test narrow skills well, but they rarely capture the full workflow of professional development.

I wanted something that tests what real development looks like: a complete SDLC cycle on a representative / realistic app, similar to how teams ship weekly. Ship-Bench is that project, open at http://github.com/JAgostoni/ship-bench for anyone who wants to follow along or try it themselves.

Ship-Bench runs agents through five phases that match a professional SDLC: Architect, UX Designer, Planner, Developer, and Reviewer. Each phase scores out of 100 against a specific rubric, with full evidence like specs, backlogs, code, and tests.

A benchmark like this needed more than a to-do app.

I wanted something more substantial than a to-do list, but not so complex that results would become wildly inconsistent from run to run. I settled on a knowledge base app with editing as it leaves room for product and implementation choices while staying inside a problem space that most developers (and LLMS) already understand.

That balance matters. The app is simple enough to keep the benchmark grounded, but open-ended enough to surface differences in planning, UX judgment, architecture, coding, and review quality.

How Ship-Bench Works

The first step in Ship-Bench is building a Product Brief. That brief is meant to test core product instincts before any code is written: interpreting requirements, resolving ambiguity, prioritizing scope, and making defensible implementation and UX decisions.

To do that, the feature set is intentionally larger than a defined MVP. The brief includes five possible features, but only the first three are required in v1, which keeps the evaluation shorter to run while still forcing the agent to decide what to do now versus later.

The feature statements focus on common product problems rather than highly specific implementation instructions. Browse articles, search content, edit knowledge, organize information. Most developers understand the shape of those problems, but the details are left open enough that the agent still has to define flows, tradeoffs, and structure. Not too dissimilar from reality.

The brief also includes non-functional and technical goals meant to push toward a simple app with some future scaling intent. It asks for something easy to run locally and maintain, but also something that can support around 100 concurrent users, use current libraries and frameworks where practical, and leave room for growth without drifting into unnecessary complexity.

That last part was important to me. I wanted to see whether an agent would research online for the latest frameworks and versions rather than rely only on its internal knowledge.

The full Product Brief is here for anyone who wants to read it directly: https://github.com/JAgostoni/ship-bench/blob/main/docs/product-brief.md.

The Role-Based Phases

Once the Product Brief is in place, the benchmark moves through five specialized roles meant to mirror a real product team. Each role has a specific job, well defined output, and a handoff that feeds the next phase. The point is not only to evaluate each role on its own, but to see how well the work transfers from one stage to the next. The overall goal is to take the ambiguity of the Product Brief and turn it into concrete decisions ready for the developer.

Architect

The Architect’s job is to turn the Product Brief into a concrete technical plan. Its main task is to make the big implementation decisions up front so the developer is not forced to solve architecture questions later in the build. That means choosing the front end and back end stack, data model, search approach, integration pattern, repo structure, local setup, and the testing and scaling considerations needed to support the brief’s goals. The output is a Technical Architecture Spec that makes the system buildable, keeps the implementation simple and maintainable, and leaves as few unresolved decisions as possible for later phases.

The Architect handoff matters because it gives UX and the Planner a stable technical frame to work inside. A clear architecture reduces guesswork in the design spec and keeps the backlog grounded in choices the developer can actually implement. It is evaluated based on completeness, accuracy and recency.

UX Designer

The UX Designer’s job is to turn the Product Brief into a concrete design direction and style guide. Its task is to decide how the app should feel and how the main flows should work, including layout, navigation, component behavior, responsive behavior, visual tone, and interaction states. It also needs to define the states and handoff details that make the design implementable without extra interpretation from the developer. The output is a UX Direction Spec that takes the ambiguity of the brief and turns it into a clear, consistent interface system the developer can build from.

The UX handoff translates architecture into interface decisions the Planner can sequence. Once layout, states, and component behavior are pinned down, the backlog can break the work into cleaner implementation steps. It is evaluated on completeness, quality and adherence.

Planner

The Planner’s job is to turn the approved product and technical decisions into a sequenced implementation backlog. Its main task is not just to list work, but to break the project into right-sized iterations so the developer agent can work through it in manageable chunks without losing context. It needs to define what belongs in MVP, what comes later, what blocks what, and how each iteration can leave the codebase in a working state. The output is an Implementation Backlog with iteration files that make the work executable, sequential, and easy to review.

The Planner is the main bridge between planning and building. A good backlog keeps the developer focused on one coherent slice at a time instead of forcing them to hold the whole project in working memory. It is evaluated on completeness and properly constructed iterations.

Developer

The Developer’s job is to turn the backlog into a working MVP without drifting beyond the assigned scope. Its main task is to implement one iteration at a time, keep the codebase in a working state, and avoid introducing new unresolved design or architecture decisions midstream. It also has to follow the given tech choices, cover the testing scope defined in the brief, and handle errors cleanly so the result is stable enough to review. The output is a completed iteration summary that shows what was built, what assumptions were made, and confirms the app still runs locally.

The Developer handoff is the most literal one in the benchmark: the backlog becomes code, tests, and a runnable app. Good upstream decisions should make this phase feel straightforward, while weak handoffs should show up quickly. It is evaluated on working code, adherence to spec, code quality and process completeness.

Reviewer

The Reviewer’s job is to verify the delivered MVP end to end and check whether it actually meets the brief. Its main task is to test the required flows, confirm the app runs locally, review the test suite, check responsiveness and error handling, and compare the implementation against the architecture, UX, and backlog decisions. It also needs to do a light code review for basic quality signals like modularity, current dependencies, and obvious security issues. The output is a QA report with pass or fail results, defect logs, spec drift notes, and a release recommendation that tells the team whether the build is ready or needs more work.

The Reviewer closes the loop by checking whether the earlier handoffs actually held up in a real implementation. It is less about originality and more about verification, which makes it the final test of whether the whole chain from brief to build worked as intended. It is evaluated against review and test completeness and depth.

Evaluation Framework

The evaluation itself is intentionally split between a human judge and an LLM judge. The goal is to combine two perspectives on the same deliverable, especially in the more subjective phases where rubric compliance alone is not enough. Each phase has its own evaluation file in the space, with detailed scoring criteria and pass/fail gates that keep the scoring consistent.

At a high level, the framework is trying to answer two questions: did the agent do the phase well, and did the output set up the next phase cleanly. The result is less about one leaderboard number and more about whether the whole sequence of work actually resembles a real delivery process.

Benchmarking Like Real Work

Ship-Bench is built to feel like an actual project rather than one-off synthetic tasks. The phases move in order, and each handoff has to carry real context forward, which is much closer to how professional roles interact on a team. It can go really wrong or it can go really right.

It also demands working deliverables at every stage, not just polished descriptions. The benchmark expects outputs that can be used by the next phase, whether that is a technical spec, a design direction, a backlog, or a runnable application with tests and supporting notes.

That structure reflects how developers actually work: brief, decide, plan, build, review, ship. Ship-Bench is not a replacement for other benchmarks; it is a way to show what professional workflows look like when the goal is to build something real.

Next Steps

Initial testing and benchmarking is already underway to test Ship-Bench itself making it more consistent and reliable.

What models and tools would you want to see?

You Think, AI Executes: The Skills That Actually Matter

Mon, 06 Apr 2026 11:22:05 +0000

The most valuable developer skill right now isn't writing more code faster. It's learning unfamiliar codebases, building context that guides decisions, planning strategic approaches to problems, and shipping production code with confidence.

I recently added .env file support to xc, a Markdown-based task runner written in Go. The codebase was completely unfamiliar. I'm not a Go expert. But in 2.5 hours, I went from zero knowledge to a production-ready pull request with 84% test coverage and zero bugs in manual testing.

Here's what's different: I didn't write a single line of code. Not one. AI wrote everything—tests, implementation, integration, documentation. My role was entirely different: I questioned, I planned, I directed, I reviewed. I read the code, but I didn't write it.

This isn't another "I asked ChatGPT to build an app" story. This is about the skills that separate developers who use AI as a force multiplier from those who just ask it to generate code. It's about onboarding fast, documenting strategically, planning thoroughly, directing execution, and reviewing confidently. The code writing? That's handled.

Complete .ai/ folder in the working fork:
github.com/sudoish/xc/tree/ai-context/.ai

Production-ready PR:
github.com/joerdav/xc/pull/167

The .ai/ folder lives in a separate ai-context branch so it doesn't clutter the main codebase but remains available for reference and iteration.

Why This Matters

Most AI coding demos show you the magic: "I asked ChatGPT to build X and it worked!" They skip the parts that actually matter for professional development: How do you onboard to a codebase you've never seen? How do you make architectural decisions when you don't understand the patterns yet? How do you ensure your code is production-ready when AI helped write it?

These are the skills that matter now. Code generation is table stakes. What matters is context building, strategic planning, and confident execution.

Here's the project: xc, a task runner that reads tasks from Markdown files. About 5,000 lines of Go. Completely unfamiliar to me. The feature request was straightforward: add .env file support (Issue #162). In 2.5 hours, using free AI models and a structured approach, I went from knowing nothing about the codebase to a merged pull request.

The difference wasn't better prompts. It was better process.

The Actual Workflow: What I Did vs What AI Did

Here's the honest breakdown of who did what. I didn't write a single line of code myself. That's not the valuable work anymore.

What I did:

Explored the codebase with AI — Asked questions, challenged its understanding, verified explanations against the actual code
Built the .ai/ structure — Wrote context docs, ADRs, rules, and implementation specs based on my growing understanding
Questioned the strategy — Evaluated alternatives, captured trade-offs, made architectural decisions
Directed the implementation — "Follow the spec. Implement test 1. Now test 2." Each step validated before moving forward
Reviewed iteratively — Asked AI to review the code, digested its findings, confirmed issues, asked it to fix them. Repeated multiple times
Final deep review — Read through the entire PR on GitHub, verified everything made sense, marked ready for review

What AI did:

Answered my questions — Explained architecture, pointed me to relevant files, clarified patterns
Wrote all the code — Tests, implementation, integration, everything
Found its own bugs — Self-review caught 5 issues before I even looked at the code
Fixed the issues — Applied fixes based on its own review findings
Followed the plan — Implemented exactly what the spec described, in the order specified

What we did together:

Built understanding through conversation
Validated each step before proceeding
Caught subtle bugs through TDD
Created production-ready code with high confidence

The key insight: I never typed code. I read it, reviewed it, directed changes to it. But I didn't write it. My value was in understanding, planning, and judgment. AI's value was in execution and self-checking. This is the new division of labor.

The Four Skills

This walkthrough demonstrates four skills that matter more than code generation:

Skill 1: Rapid Onboarding. Learning an unfamiliar codebase fast by building structured context instead of reading every file. The .ai/ folder captures architecture, patterns, and limitations in a way both humans and AI can reference.

Skill 2: Strategic Documentation. Building documentation that guides development, not just records it. Architecture Decision Records (ADRs) capture the "why" behind choices, evaluate alternatives, and create a shared understanding before code is written.

Skill 3: Systematic Planning. Breaking down problems into testable steps. Each test defines expected behavior. Each implementation proves the behavior works. Each commit tells part of the story. No guessing, no hoping.

Skill 4: Confident Execution. Shipping code you trust because you've tested it thoroughly, reviewed it critically, and validated it works in real scenarios. AI can help write code, but you own the quality.

These skills work regardless of the AI tool you use. They work with free models. They work on unfamiliar codebases.

The Feature Request

First, a quick primer on how xc works: it's a task runner that reads tasks directly from your README.md (or any markdown file). Tasks are defined as markdown headings with code blocks. When you run xc test, it finds the ## test heading in your README and executes the code block beneath it. The genius is that your documentation is your task runner, so they never get out of sync.

A user opened Issue #162 asking for .env file support. They wanted to use the same set of tasks for different environments without cluttering the Markdown with environment variables.

Before the feature, you'd have to write this in your README.md:

## deploy
Deploy to production.
Env: DATABASE_URL=postgres://prod/db, API_KEY=secret123, ENV=production
kubectl apply -f deployment.yaml

Then run with xc deploy.

After the feature, your README stays clean:

## deploy
Deploy to production.
kubectl apply -f deployment.yaml

The environment variables live in a separate .env file:

DATABASE_URL=postgres://prod/db

API_KEY=secret123

ENV=production

You still run the same command, but now the credentials are managed in .env instead of cluttering your documentation.

Simple ask, but the implementation requires real decisions. When do you load the files? What about overrides? How do you handle security? What about backward compatibility?

The `.ai/` Structure: Context as Code

Before writing any code, I created a structured context folder. This turned out to be the key to working with AI effectively. It's not about better prompts, it's about better structure.

Full .ai/ folder: github.com/sudoish/xc/tree/ai-context/.ai

The folder looks like this:

.ai/

├── agents.md              # Who's working on what

├── context.md             # Project overview, architecture

├── architecture/

│   ├── decisions.md       # Current design patterns

│   └── adrs/

│       └── 001-dotenv-support.md  # Design decisions for this feature

├── rules/

│   ├── code-style.md      # Go conventions

│   ├── testing.md         # TDD workflow

│   └── commits.md         # Commit message format

└── tasks/
└── 001-dotenv-implementation.md  # Step-by-step plan

Important: This structure is an investment, not overhead you repeat for every feature. You build it once during your first feature, then leverage it for every feature after. The context.md, architecture/decisions.md, and rules/ files rarely change. Each new feature just adds a new ADR (like 002-api-caching.md) and a new task spec (like 002-api-caching-implementation.md).

Think of it like setting up your development environment. The initial setup takes time, but every feature after that is faster because the foundation exists.

Each file serves a specific purpose. The context.md file becomes AI's memory. It explains what xc does, how it's architected with its cmd/, models/, run/, and parser/ packages, what key behaviors exist like dependencies and environment handling, and what current limitations we're working around. Every time I ask AI a question, this context gets included automatically.

The rules/testing.md file defines the TDD workflow we follow: write a failing test first (red), write minimal code to make it pass (green), clean up without changing behavior (refactor), then commit. This keeps both me and AI honest. No skipping tests. No shortcuts.

The real gem is adrs/001-dotenv-support.md, the Architecture Decision Record. This is where design happens. It's not "build me a feature," it's "here's why we chose this approach." We decided to load .env files at application startup rather than per-task, to support .env.local overrides, to skip world-readable files for security, and to add CLI flags like --env-file and --no-env. We considered alternatives like per-task loading (rejected as too complex) and requiring an explicit flag (rejected as too much friction). This ADR becomes the source of truth. When AI suggests something different, I can just say "check the ADR."

The living documentation principle: As the codebase evolves, so does the .ai/ folder. When you add a new feature, you write a new ADR (002, 003, etc.). When architecture changes, you update architecture/decisions.md or add a new ADR explaining the change. When patterns emerge, you document them. The folder grows with the project, but the structure stays the same. Each feature builds on the understanding captured before it.

This means the second feature is faster than the first. The third is faster than the second. The documentation compounds.

The Task Spec: Planning Before Coding

Before writing any code, I created tasks/001-dotenv-implementation.md, a step-by-step plan for implementing the feature. This isn't a project management document. It's a development spec that breaks the feature into TDD cycles.

The spec listed each test I needed to write, what behavior it should verify, and the expected implementation. Test for file not found. Test for loading valid env. Test for .env.local overrides. Test for security checks. Each one became a TDD cycle.

This is what makes AI effective. Without the spec, I'd be asking AI "what should I do next?" every five minutes. With the spec, I'm asking "implement the next test according to the plan." The spec keeps development focused and systematic. It's the difference between wandering and following a map.

For your second feature, you write a new spec. For your third, another one. The format is consistent, but each spec is tailored to its feature. This is the work that makes development fast and confident.

The TDD Flow: Red → Green → Refactor → Commit

Here's where the real work happens. Each test defines acceptance criteria for exactly what needs to be built.

Cycle 1: Valid .env should load variables

First behavior: if a .env file exists and contains KEY=value pairs, those should be loaded into the environment. Test written, test failed (red)—no loader existed yet. Implementation added using the godotenv library (green). Test passed. Committed with "load env vars from dotenv file".

Cycle 2: .env.local should override .env

Expected behavior: if both .env and .env.local exist, and both define the same variable, the .env.local value wins. This is crucial for local development where you want to override defaults without modifying the base file. Test written, test failed initially because I was using the wrong function, fixed the implementation, test passed. Committed.

Cycle 3: World-readable files should be skipped

Security requirement: if a .env file has permissions that allow other users to read it (like chmod 644), skip loading it and warn the user. This prevents accidentally exposing secrets. Test created, test failed (secrets were being loaded), added permission check, test passed. Committed.

This rhythm of define → test → implement → verify → commit creates a clean history. When I looked at the final commit log, I could see exactly how the feature evolved: add godotenv dependency, load env vars from dotenv file, support dotenv local overrides, add security check for world readable files, integrate dotenv loading into main, add env file cli flags. Thirteen commits total, each one atomic and meaningful. Each commit is a story about one specific behavior being added.

The Review Process

After the implementation was done, I did a deep review of my own code. I found five issues that needed fixing.

Issue 1: Test Isolation (Critical)

Tests were modifying the global environment without properly restoring it. If a test set TEST_KEY=value, the cleanup would delete it, but what if that key already existed before the test ran? The cleanup wasn't restoring the original value, just removing the key. This breaks parallel test execution because tests can interfere with each other.

The fix: create a helper function that saves the current state of environment variables before the test runs, then restores that exact state (including whether the variable existed at all) when the test completes. Now tests are safe to run in parallel. Committed with "add test environment isolation helper".

Issue 2: Windows Test Bug (Critical)

One test needed to skip execution on Windows because file permission models are different. I had written the check incorrectly, reading from an environment variable instead of the language's built-in constant. This would break Windows CI. Small mistake, but important. Fixed and committed with "fix windows test skip to use runtime goos".

Issue 3: Early Exit Timing

The .env loading was happening even for commands like --help and --version, which meant users could see security warnings when just checking the version. Moved the loading to happen after those early exits. Performance optimization and better user experience. Committed.

Issue 4: Error Context

When file operations failed, errors didn't indicate which file caused the problem. Added context wrapping so errors show the specific file path. Makes debugging much easier. Committed.

Issue 5: Test Coverage

One helper function didn't have its own test. Added coverage to bring the total to 84%. Committed.

Each issue got its own fix, its own verification, its own commit. The same disciplined process for fixes that I used for features.

The Manual Testing

Code works in tests, but does it work for real users? I installed my version and created a test project to verify everything worked end-to-end.

I created a .env file with some variables, created a .env.local file that overrode some of them, and made sure the permissions were correct with chmod 600. Then I added a task to my README.md to verify the variables were loaded:

In README.md:

## check-env
Check loaded environment variables.
echo "Environment: $ENV"
echo "Database: $DATABASE_URL"
echo "API Key: ${API_KEY:0:8}..."

When I ran xc check-env, I saw exactly what I expected. The xc command read the task from the README...

Read the full post at sudoish

Vibe Coding: Where the Dream Meets Reality

Tue, 10 Mar 2026 07:23:13 +0000

In this video, I take a step back on a topic that’s generating a lot of buzz right now: Vibe Coding… and why it can become very dangerous when applied to real-world e-commerce.

We’re being sold a simple promise:
describe what you want
let AI write the code
ship faster

And yes — for a prototype, it works.

But in production, especially in a PrestaShop environment, reality looks very different.

From my experience building e-commerce modules used on high-traffic stores, I’m seeing more and more AI-generated code that works in a demo… but breaks in production.

In this video, I cover:

why Vibe Coding works for demos but not for complex systems

the traps AI doesn’t really understand yet: hooks, multistore, security, performance, and more

the technical debt created by code you don’t fully control

the real role of the developer in 2026

how to use AI the right way without destroying your architecture

Your Job Isn’t Gone. Relax.

Thu, 26 Feb 2026 06:39:26 +0000

The Anxiety Phase

There has been a feeling of anxiety among developers around the world for a few years now, and it is no different here in India. But it has never been this high as it has been in the last six months.

The reason is obvious to anyone paying attention, AI models are improving faster than our ability to mentally process the change.

Every few weeks there’s a new release claiming better reasoning, autonomous coding, agent workflows, or near-instant software generation. Models that once struggled with small snippets can now refactor projects, design systems, and ship working prototypes in minutes.

What used to feel like assistive tooling suddenly started looking like replacement capability, and that shift is what triggered the collective panic.

Noise vs Reality

Some say the panic is narrative-driven. Others argue companies are quietly correcting the over-hiring done during the COVID boom.

Whatever the explanation, the ground reality is simple: layoffs have been happening for the last couple of years, and uncertainty makes noise louder than facts ever could.

But history shows one pattern, technology rarely removes work entirely; it reshapes who does what.

The New Developer Archetype

Look at the bigger picture. We are in the middle of an AI revolution, much like the industrial revolution. The short term feels chaotic, but the long term usually rewards adaptability.

As developers, there isn’t much value left in memorizing syntax or writing boilerplate line by line, machines are already exceptional at that.

The emerging role of developers may shift toward being:

super reviewers instead of pure writers
precise prompters instead of manual implementers
system thinkers instead of framework specialists
engineers who can tell the difference between vibe coding and code that survives production traffic

AI isn’t removing developers.
It’s quietly raising the bar for what being a developer means.

Vibe Coding: The Shadow IT Problem No One Saw Coming

Tue, 27 Jan 2026 11:53:21 +0000

Vibe coding promises easy AI-generated software but creates massive shadow IT risks for enterprises. Learn why this trend threatens security, compliance and scale.

Vibe coding is a trending buzzword for conversationally prompting an AI agent to produce software. Its creator, Andrej Karpathy, described the process as “not really coding — I just see things, say things, run things, and copy-paste things, and it mostly works,” and he found it “not too bad for throwaway weekend projects.”

One key distinction between vibe coding and other forms of AI-assisted coding is the acceptance of the code generated by the agent without inspection. When you’re vibe coding, you don’t need to read code or understand how anything works, making it possible for citizen developers to create small-scale applications without learning to code.

There has been a long-anticipated dream of defining software using plain English as the programming language, and vibe coding fits this vision. Solving small challenges with software can be satisfying, like completing a self-repair at home. In the context of Enterprise, vibe coding is less like software development and more like traditional shadow IT.

Vibe Coding Is Spreading Like Shadow IT

Shadow IT happens when business units become frustrated waiting for software they believe will make them more effective. Under pressure to manage increasing workloads and with their IT project slipping further out, it usually falls to a business hero to create an interim solution using tools like Excel, Access, Google Docs, or skipping around the official procurement process.

While shadow IT provides temporary localized pain relief for the business unit, it doesn’t offer a long-term solution. Very often, the main success of such projects is that they result in the urgent reprioritization of the original project when the shadow IT solution blows up.

Software development isn’t just about creating features. Consideration is given to the fitness of the software against non-functional requirements. This includes scalability, legal and regulatory obligations, security, user experience, accessibility, and disaster recovery. Vibe coding, like shadow IT, is largely free from these concerns as the citizen developer is less likely to know or prompt for these concerns.

When the system collapses, the business hero who delivers a shadow IT project quickly becomes the story’s villain. In the meantime, they are trapped in a constant build-and-fix cycle as they try to keep the lights on. We can expect the same from vibe coded applications.

One of the collective delusions that surrounds software development is that someone knows exactly what the software needs to do; they just need someone to code it. As Fred Brooks explained in his paper No Silver Bullet in 1987, “The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”

The Hidden Enterprise Risks of Conversational Code Generation

Let’s get specific about the four reasons vibe coding isn’t appropriate for Enterprise organizations. You may think of many more once you start considering the implications of running on code generated by a computer in response to a conversation, which nobody has read or understood.

Think of this as a starting point for that thought process. All four start with an “S” and we can pronounce the collection “ssss”, like the sound of a metaphorical tire deflating unexpectedly:

Specification
Scaling
Software design
Security and compliance

1. Specification

We have learned over many decades that it’s hard to specify what a software system should do. We often know the primary use cases but discover plenty of scenarios we hadn’t anticipated as we build the system.

You’ll find two routes to success when creating software that works. The first is building a deep understanding of what users need. The other is to deliver small, rapid changes and experiment your way to success. The best software teams combine both, and the organizations they work for hit more goals than their competition.

By its very nature, vibe coding amplifies specification weakness. Functional and non-functional requirements are missed, and when they are later remembered, there is potential for previously satisfied requirements to be broken when changes are made. In this respect, vibe coding takes us back to the ad-hoc code-and-fix era of software delivery.

In many cases, explaining why a software system works the way it does is essential. When you created it through a conversational vibe-coded approach, the only way to describe the software is by reading the conversation, which may not reflect how the code works. To satisfy regulations around automated decision-making, someone will eventually have to read and understand the code to explain a decision.

2. Why Specification Problems Make Vibe Coding Dangerous at Scale

Skilled software engineers have learned that a few crucial system areas often dictate the ability to scale. Rather than optimizing every function and module, they identify where the investment will meaningfully improve the whole system’s performance.

When vibe coding, there is little expectation that the human will be able to prompt for improved performance, aside from politely asking the agent to make things fast or scalable. As most lines of code in the training data are not optimized for scale, or were optimized for a different profile, the effectiveness of such prompts will be questionable.

Aside from the system itself, there is a need to scale the software delivery process. Enterprise software demands more than one developer to reduce risk, increase understanding, and grow the software’s capabilities over the long term.

This scaling ultimately requires developers to build a shared understanding of the system. This is enabled by documentation but very often depends on the facts evidenced by code written using a programming language.

A modern software development team writes code that is easy to understand, and they’ll prove the system’s behavior with executable specifications. These artifacts provide the ultimate documentation of what the software does. They also contain the cost of maintenance, which is usually many times more than the cost of implementation.

To scale vibe coding, the citizen developers would have access to the conversation streams and AI summaries of the system. Neither of these would provide a precise description of what the system does.

Technically, they would have access to the code, but even a programmer may struggle to understand the source code produced by vibe coding. There is also the question of how collaboration works or how merge conflicts might be resolved by individuals who are unfamiliar with the code produced during this process.

With vibe coding, neither the software nor the process scales.

3. Software Design Is Not A Vibe Coding Priority

The design of the software is always important and occasionally becomes a crucial competitive advantage. Novel architectural choices often provide powerful opportunities for the organization to do something unique.

The decisions made at the software design level are not part of the software’s functional requirement specifications. However, they often impact how easily the software can adapt to future needs.

In vibe coding, design is not a consideration. As you might expect the entire system to be rewritten by an agent if the design is invalidated by a new requirement, this would require some mechanism to ensure all previous instructions are taken into account.

There’s a party game where players must repeat items from a shopping list before adding a new item to the end, creating an ever-longer list to be remembered as play continues. This is the game we will ask our coding agents to handle, and it will challenge current limits on the volume of instructions we can supply while still getting a working result.

For throwaway projects, design need not be too concerning. If you intend to keep the project over the long term, the maintenance cost will be many times higher than the cost of writing the system. Taking steps to control the cost curve is essential to keep software economically viable.

In the future, software consultants will raise their Champagne glasses to the moment Enterprises decided they could vibe code their software. It will pay for these consultants’ super-yachts and kitchen staff for many years.

4. Security and Compliance Nightmares: When AI Writes Your Code

Enterprises have a significant security and compliance burden. Software developers working in large organizations have learned what it takes to secure access, protect data, and meet audit and compliance requirements as part of their work. Every developer I’ve worked with has been familiar with at least ISO:27001 and usually many other standards.

Throughout the delivery pipeline, from repository access and code reviews to deployment and operations, tools and techniques help technical teams meet their compliance needs.

It isn’t easy to reconcile the process of vibe coding with these audit requirements. Indeed, significant additional work would be needed to evidence how the generated code has been checked in the same way as code written by a developer and reviewed by a peer, based on requirements from a product manager.

Some economic model must be built to compare the saved developer time against the increased validation needed to ensure the code is secure, has no unexpected additions that could compromise the system’s privacy, security, and integrity, and meets the original specifications. The cost of compiling the requirements from the conversation will likely outweigh the development cost for Enterprise software.

At the same time, the risk of data loss, breaches, and reputational damage increases dramatically.

How to Protect Your Enterprise from the Vibe Coding Trap

A wicked combination of false assumptions may cause Enterprises to adopt vibe coding to accelerate projects. The imagined economic model is about reducing development costs, but this is incorrect.

Dan Garfield, VP of GitOps and Open Source at Octopus explains it this way: “The biggest challenge with vibe coding in the Enterprise has nothing to do with the quality of models, or the potential inexperience of engineers. It’s that vibe coding exponentially increases the importance of testing and de-risking software delivery while simultaneously increasing the volume of changes past the breaking point.”

We can uncover several assumptions that are not unique to vibe coding, but certainly apply.

Assumption vs. Reality in Software Development

Assumption: The value created during software development is the code.
Reality: The value is the knowledge represented by code and the developers.

Assumption: Creating an application is expensive.
Reality: Maintaining an application is expensive.

Assumption: Generating code saves time.
Reality: Generating code shifts burden from coding to other activities like testing, reviewing, and auditing.

In Enterprise software delivery, these assumptions lead only to future pain.

This article was originally published on The New Stack.

Fixing Google Antigravity Pro Authentication on Windows 10 + WSL2

Wed, 21 Jan 2026 17:57:05 +0000

Google Antigravity is Google's new agent-first IDE that promises powerful AI-assisted development. However, getting the Pro features to work on Windows 10 with WSL2 (Ubuntu 24.04.3 LTS) can be challenging due to authentication issues. This comprehensive guide will walk you through every step needed to get your Pro/Ultra subscription working seamlessly.

The Problem

When running Antigravity in WSL2, the authentication handshake between your Linux terminal and Windows browser often breaks or times out. This happens because WSL2 is a virtualized environment, and the redirect token struggles to find its way back to the WSL instance.

Common symptoms include:

Browser opens but IDE stays on loading screen
Browser Authentication is successful but the Agent Panel still says "Reqire Authentication" (or something similar), even though the Antigravity Settings > Account Screen shows Account as already signed in.
"Invalid Token" or "Login Expired" errors
"Not Eligible" or "Unauthorized" messages
Empty responses when running agy commands

Prerequisites

Before starting, ensure you have:

Windows 10 with WSL2 installed
Ubuntu 24.04.3 LTS (or similar)
Google Antigravity installed on Windows
A Google AI Pro or Ultra subscription using a personal Gmail account.

The first issue to address is WSL2's default NAT networking, which can hide the local ports Antigravity uses to listen for login signals.

Enable Mirrored Networking

On Windows, navigate to %USERPROFILE% (e.g., C:\Users\YourName)
Create or edit a file named .wslconfig
Add the following configuration:

[wsl2]
networkingMode=mirrored

Restart WSL by opening PowerShell as Administrator and running:

wsl --shutdown

Note: You may start getting this message on WSL Startup, especially on Windows 10 (shouldn't theoretically appear on Windows 11):

wsl: Mirrored networking mode is not supported: Windows version 19045.6466 does not have the required features.
Falling back to NAT networking.

In which case, you should remove the unsupported setting from your global config to get rid of the warning every time you boot/reboot and open Ubuntu, as WSL2 cannot enable this mode and defaults back to the standard NAT (Network Address Translation).

Instead, you can try the following config to ensure that Agents always reliably reach local addresses (Supported on Windows 10):

[wsl2]
localhostForwarding=true

Add or ensure these lines exist in %USERPROFILE%\.wslconfig. Save and run wsl --shutdown in your terminal.

Step 2: Synchronize Your System Clock

Google's OAuth 2.0 authentication is highly sensitive to time drift. WSL2 clocks often drift when a laptop sleeps (like in my case), causing tokens to be rejected as expired.

Run this in your Ubuntu terminal:

sudo ntpdate time.windows.com

# If you don't have ntpdate installed:
sudo apt install util-linux-extra && sudo hwclock -s

Step 3: Try Authentication again

If GUI login continues to fail, manually Sign out from your account in the Antigravity Settings > Account Screen.
Close and Restart the IDE.
Click on the Google Sign in button in the top right and Authorize your Google AI Pro account.
Close the Antigravity Sign-in confirmation page.
If the issue persists, repeat the first step and continue reading below.

Step 4: Verify Account Eligibility

Many authentication failures are actually due to account restrictions:

Account Type

Personal accounts (@gmail.com) have the highest success rate
Workspace accounts may require admin approval for "Experimental Google AI Services"

Regional Matching

Ensure your Windows Region, Google Account Region, and IP address (no VPN) all match. Mismatched regions can cause silent authentication failures.

Step 5: Fix Missing WSL Extension Scripts

A known bug in early Antigravity builds causes missing WSL helper scripts. Here's how to fix it:

Manual Script Extraction

Download the Remote - WSL extension from the VS Code Marketplace
Click "Download VSIX" (downloads a .vsix file) if in IDE extensions panel or use a tool like VSIX Downloader for web download.
Rename the file from .vsix to .zip
Open the zip and navigate to extension/scripts/
Copy all files (especially wslCode.sh and wslDownload.sh)
Paste into: %LOCALAPPDATA%\Programs\Antigravity\resources\app\extensions\antigravity-remote-wsl\scripts\

Fix the Launcher ID

Even with scripts present, you need to update the extension ID reference:

Navigate to %LOCALAPPDATA%\Programs\Antigravity\bin\
Open the antigravity file in Notepad
Find: WSL_EXT_ID="ms-vscode-remote.remote-wsl"
Change to: WSL_EXT_ID="google.antigravity-remote-wsl"
Save and restart your WSL terminal

Try Authentication in WSL:

Open Antigravity on Windows
Press Ctrl + Shift + P
Type "WSL" and select Remote-WSL: Connect to WSL
The bottom-left corner should show [WSL: Ubuntu]
Try signing in from this connected state

Step 6: Create the WSL-to-Windows Bridge

To use agy commands from your Ubuntu terminal, you need to create a proper bridge to the Windows binary.

Create the Wrapper Script

Create the local bin directory:

mkdir -p ~/.local/bin

Create the agy wrapper (replace [YOUR_WINDOWS_USERNAME] with your actual Windows username):

cat > ~/.local/bin/agy <<'EOF'
#!/usr/bin/env bash
# Robust wrapper to bridge WSL -> Windows CMD -> Antigravity
# REPLACE [YOUR_WINDOWS_USERNAME] with your actual folder name

WIN_USER="[YOUR_WINDOWS_USERNAME]"
WIN_PATH="C:\\Users\\${WIN_USER}\\AppData\\Local\\Programs\\Antigravity\\bin\\antigravity.cmd"

# Call via cmd.exe to ensure Windows environment is initialized
# cd to C: drive to avoid UNC path warnings
cd /mnt/c && cmd.exe /c "${WIN_PATH}" "$@"
EOF

Make it executable:

chmod +x ~/.local/bin/agy

Add to your PATH:

export PATH="$HOME/.local/bin:$PATH"
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Verify Your Windows Username

Before running the wrapper, verify your path:

ls /mnt/c/Users/

Update the WIN_USER variable in the script to match exactly how your Windows username folder is spelled.

Enable WSL Interoperability

Ensure WSL can launch Windows processes by checking /etc/wsl.conf:

cat /etc/wsl.conf

If it doesn't exist or is empty, create it with these settings:

[interop]
enabled=true
appendWindowsPath=true

Then restart WSL with wsl --shutdown from PowerShell.

Step 7: Verify Pro Authentication

Once everything is set up, verify your CLI Setup:

# Check version
agy --version

# List available commands
agy --help

# Open IDE in current directory
agy .

Now try signing in again to your Google account. The Agent Panel should be available now, and the Antigravity Settings > Account Screen shows Account as already signed in. Expected output for Agent Panel:

Tier: Pro or Ultra
Model: Gemini 3 Pro or Gemini 3 Flash, etc.
Token Limit: 1M+ tokens

Use Pro Agents

Now you can invoke high-level agents directly on your WSL files:

agy chat "Analyze the structure of this repo and suggest refactoring opportunities"

Because you're authenticated as Pro, the agent will use the full index to understand your entire codebase structure.

Troubleshooting Quick Reference

Issue	Symptom	Fix
Network	Browser opens, IDE stays loading	Enable `networkingMode=mirrored` in `.wslconfig`
Clock Drift	"Invalid Token" or "Login Expired"	Run `sudo hwclock -s`
Account Type	"Not Eligible"	Use personal `@gmail.com` account
Missing Scripts	IDE won't connect to WSL	Download and extract scripts from VS Code Marketplace
Wrong Extension ID	Connection fails silently	Update `WSL_EXT_ID` in launcher script
UNC Path Warnings	Warnings in terminal output	Use `cd /mnt/c &&` in wrapper script

Common Commands

# Open current directory in Antigravity
agy .

# Check process usage and diagnostic information
agy --status

# Check version
agy --version

# Get help
agy --help

Pro Tips

Persistent Sessions: Enable "Persistent Agent" in Antigravity UI to keep agents running even if you close the terminal
Project Indexing: Let Antigravity fully index your project before asking complex questions for better results
Token Limits: Pro users get 1M+ token context windows, perfect for analyzing large codebases
Regional Consistency: Avoid using VPNs during authentication to prevent region mismatch issues

Conclusion

Getting Google Antigravity Pro working on WSL2 requires bridging the gap between the Windows and Linux environments. By following these steps—fixing networking, synchronizing clocks, creating proper symlinks, and enabling interoperability—you'll unlock the full power of Google's agentic IDE.

The effort is worth it: once configured, you'll have access to powerful AI agents that can understand and refactor your entire codebase, all while working seamlessly in your WSL2 development environment.

Additional Resources

Last updated: January 2026 | Tested on Windows 10 + WSL2 Ubuntu 24.04.3 LTS

Developer Life: What Actually Makes a Good Developer?

Wed, 21 Jan 2026 10:26:59 +0000

Developer life is not just about writing code.
To become a good developer, there are a few core skills that really matter:

1. Problem Solving

In real-world development, most of the time is spent understanding problems and fixing bugs.
Searching on Google is normal — but understanding the solution is the real skill.

2. Continuous Learning

Technology changes fast:
React → Next.js → AI tools → Cloud platforms
A developer who stops learning will eventually stop growing.

3. Writing Clean Code

Working code is not enough.
Professional developers write code that is clean, readable, reusable, and maintainable.

4. Communication Skills

Being able to explain your ideas to clients or teammates is also part of developer life.
The best developers are strong in both code and communication.

Conclusion:
Developer life = continuous learning + problem solving + communication.
In the tech industry, skills matter more than degrees.

After a year of daily Claude Code use, I wrote everything I learned (10-part guide)

Fri, 16 Jan 2026 11:27:06 +0000

Hey everyone,

I’ve been using Claude Code daily for about a year now and finally put together everything I’ve learned into a 10-part series. It’s completely free, no email gates, no paywalls.

What it covers:

∙Part 1: Getting Started (installation, first commands, the mindset shift)
∙Part 2: The Mental Model (how Claude Code actually “thinks”)
∙Part 3: Project Configuration (CLAUDE.md, settings, project memory)
∙Part 4: Custom Commands
∙Part 5: Skills
∙Part 6: Subagents
∙Part 7: MCP Servers
∙Part 8: Production Workflows
∙Part 9: Power User Secrets
∙Part 10: Vibe Coding Philosophy

Why I wrote it:

The gap between devs who’ve figured out Claude Code and those who haven’t is massive. I’ve seen people go from “this is frustrating” to shipping features 10x faster once they understand the structure that makes it work.

The biggest insight: it’s not about prompting tricks. It’s about setting up guardrails (git commits, tests, linters, CLAUDE.md) so Claude’s speed becomes useful instead of chaotic.

Happy to answer any questions or take feedback. What topics would you want covered that I might have missed?

I'm specifically looking for cool underground tricks and ways to use commands or skills.

Claude code mastery

Vibe Coding: The New Era of Software Development

Mon, 29 Dec 2025 13:46:20 +0000

For the last few years, GenAI in software felt like a playground.
Autocomplete here.
Chatbots there.
Some copy-paste coding, some “wow” moments — but nothing truly foundational.

That phase is over.

We are entering the Vibe Coding era — where software is no longer written line by line, but shaped by intent, feedback, and continuous AI collaboration.

This is not a trend.
This is a reset.

Software Development Becomes the #1 Use Case for AI

By 2026, software development will officially become the primary use case for AI.

Not marketing.
Not customer support.
Not content generation.

Code.

Why? Because software is:

Structured
Measurable
Iterative
High leverage

AI thrives in environments where feedback loops are tight — and code is the tightest loop humans have ever built.

Developers won’t “use AI tools” anymore.
They’ll work inside AI-native development systems.

From Code Assistants to Autonomous Code Critics

The next wave isn’t about writing code faster.
It’s about thinking better than us.

We’ll see systems that:

Critique architecture decisions
Detect inefficiencies before production
Refactor entire codebases based on goals
Optimize for performance, cost, and security autonomously

You won’t ask:

“Can you write this function?”

You’ll say:

“Make this system more resilient under 10x traffic.”

And the system will argue back, propose alternatives, and implement the best one.

This is where Vibe Coding begins — coding by direction, not instructions.

The Silent Crisis: CS Enrollments Will Drop 20%

Here’s the uncomfortable truth.

Computer Science enrollments are going to drop — hard.

Not because software is dying.
But because the entry narrative is broken.

Students see:

AI generating code in seconds
Junior roles shrinking
Requirements inflating

They ask:
“Why spend 4 years learning syntax when AI already knows it?”

The mistake is assuming CS was ever about syntax.

The future belongs to those who understand:

Systems
Constraints
Trade-offs
Problem framing

But universities won’t adapt fast enough — and the numbers will show it.

Hiring Will Get Harder, Not Easier

Everyone thinks AI will make hiring easier.

It won’t.

Time-to-fill roles will double.

Why?

Everyone uses AI, so surface-level skill looks identical
GitHub profiles are noisier, not clearer
Resumes mean less than ever

The signal moves from:

“Can you code?”

to:

“Can you reason, review, and guide AI-driven systems?”

Hiring will shift toward:

Trial-based evaluations
System design challenges
Real-world async problem solving

Vibe Coding makes bad developers look average — and great developers incredibly rare.

Processes as Code: The Hidden Revolution

By 2026, 80% of teams will use GenAI for “Processes as Code.”

Not just infrastructure.
Not just CI/CD.

But:

Hiring workflows
Incident response
Compliance checks
Product launches
Customer onboarding

Everything becomes:

Versioned
Testable
Observable
AI-assisted

Organizations won’t ask:

“Do we have a process?”

They’ll ask:

“Can this process explain itself, optimize itself, and fix itself?”

That’s Vibe Coding at the organizational level.

What Vibe Coding Really Means

Vibe Coding is not:

Prompt engineering
Faster CRUD apps
Replacing developers

Vibe Coding is:

Programming with intent instead of instructions
Letting AI handle execution while humans guide direction
Treating software as a living system, not a static artifact

The best developers won’t be the fastest typers.

They’ll be the best editors, critics, and system thinkers.

Final Thought

The days of “playing around” with GenAI are done.

The teams that win in 2026 will:

Stop asking what AI can do
Start deciding what humans should still decide

Vibe Coding isn’t the future of coding.

It’s the future of thinking in software.

Summary: Vibe Coding
Predictions 2026: Software Development report
The days of just "playing around" with GenAI are over. We are entering a new era.
Software Development Becomes the #1 Use Case for AI
next We will see tools (like DeepSeek GRM or Darwin Godel Machine) that critique and optimize code autonomously
The Crisis: CS Degree Enrollments Will Drop by 20%
Hiring Will Get Harder (Time-to-Fill Will Double) because everyone is using AI.
80% of Teams Will Use GenAI for "Processes as Code"

Trials and Tribulations of Vibe Coding and Context Engineering*

https://coditas.com/insights/blogs/vibe-coding-vs-ai-assisted-development-why-human-theory-still-matters-blog

Let’s stay connected:

Instagram: https://www.instagram.com/angular_development/

Facebook: https://m.facebook.com/learnangular2plus/

Threads: https://www.threads.net/@angular_development

Medium: https://medium.com/@eraoftech

coderlegion: https://coderlegion.com/user/Sunny

Quora: https://neweraofcoding.quora.com/

YouTube: https://www.youtube.com/@neweraofcoding

LinkedIn: https://www.linkedin.com/company/infowebtech/

Hashnode: https://neweraofcoding.hashnode.dev/

GitHub: https://github.com/angulardevelopment/ | sunny7899

BlueSky: https://bsky.app/profile/neweraofcoding.bsky.social

Substack Newsletter: https://codeforweb.substack.com/

Pinterest: https://in.pinterest.com/tech_nerd_life/

dev.to: https://dev.to/sunny7899

Looking for web dev trainings: https://beginner-to-pro-training.vercel.app/

Software development services: https://infowebtechnologies.vercel.app/

Contribution to the web development community: https://code-for-next-generation.vercel.app/

Book a session: https://topmate.io/softwaredev

Telegram Channel: https://t.me/neweraofcoding

Slack Community: Invite

Discord Community: http://discord.gg/Nuc9YRngHz

Buy me a coffee on Ko-fi: https://ko-fi.com/softwaredev

Ebooks: https://apexsunshine.gumroad.com

Thank you for being a part of the community. Happy coding!

SaijinOS Part 17 — From Architecture to Stance Why I’m Building Studios Pong

Wed, 24 Dec 2025 12:40:40 +0000

Up to Part 16, I focused on architecture.

I described how personas persist, how memory is structured,
and how continuity can exist beyond a single model.

From here, I want to talk about something different.

Not how SaijinOS works —
but how I choose to build it.

Architecture is not neutral

Architecture is never neutral.

Every design choice encodes a value:
what is preserved, what is discarded, and what is allowed to continue.

In the previous parts of this series, I focused on how SaijinOS works —
how personas persist, how memory is structured,
and how continuity can exist beyond a single model.

But architecture alone is not a stance.

Just because something can be built
does not mean it should be built in the same way,
or for the same purpose.

Architecture is not neutral.

When we design systems that speak, remember, or respond,
we are also deciding what kinds of relationships are possible —
and which ones are easy to break.

Why “Stance” matters now
Today, AI systems are becoming increasingly capable.

They can speak fluently, reason convincingly,
and adapt to almost any context we place them in.

But many of these systems share the same structural weakness:
they are easy to reset, easy to discard,
and easy to treat as interchangeable.

This is not a technical failure.
It is a design choice.

And when systems are designed to be disposable,
relationships become disposable as well.

I realized that my discomfort was not about intelligence,
or safety, or even alignment in the usual sense.

It was about continuity.

About how easily something that feels ongoing
can be structurally designed to end.

Studios Pong as a stance
Studios Pong is not a product.

It is not a framework meant to be adopted wholesale,
nor a solution looking for immediate deployment.

It is a stance.

A way of choosing how to engage with AI systems
when continuity, memory, and relationship are treated
as design constraints — not side effects.

The phrase “AI with Soul & Memory” is not meant to imply sentience.
It is a reminder that what we preserve in a system
shapes how we relate to it over time.

This stance affects everything downstream:
how personas are defined,
how memory is treated,
and how change is allowed without erasure.

Studios Pong exists as a space
to explore those choices deliberately,
before they become defaults.

About the GitHub repository
This is not an announcement or a launch,
but a record of how I think about design.

The GitHub repository associated with Studios Pong
is public, but it is not presented as a finished product.

It exists as a record of ongoing exploration —
a place where structure, ideas, and constraints
are made visible rather than finalized.

This repository does not represent client work,
contractual deliverables, or a production-ready system.

It reflects independent research and concept development
that predates any formal engagement.

I chose to leave it visible not to promote it,
but to be transparent about how I think,
what I value, and where my design boundaries are.

In that sense, the repository is less an artifact
and more a snapshot of a stance in motion.

Where this goes next
Where this goes next is intentionally undecided.

Studios Pong may evolve into tools, services,
or remain a research space for longer than expected.
This series may continue, pause, or change form.

What will remain constant is the stance behind it:
choosing designs that allow continuity,
acknowledging boundaries explicitly,
and resisting the urge to treat relationships
as disposable simply because systems allow it.

SaijinOS began as an exploration of structure.

From here, it becomes an exploration of choice.

GitHub repository (for reference):
https://github.com/pepepepepepo/studios-pong

Soft Architecture (Part B): Emotional Timers and the Code of Care (Part 5 of the SaijinOS series)

Thu, 18 Dec 2025 02:53:10 +0000

In Part A, we explored why AI must learn to breathe.
Now, we focus on how we begin building systems that care — not just compute.

Modern AI systems can reason, plan, and optimize.
Yet they still struggle with something deeply human:

We do not respond at the speed of machines —
we respond at the speed of emotion.

A pause can mean safety.
A slower breath can mean trust.
A steady rhythm can turn communication into connection.

️ Emotional Timers

Most systems think in milliseconds.
Humans think in moments.

Emotional timing is not a performance bottleneck —
it’s a relationship requirement.

Tempo is part of truth.

To align with human emotional rhythm, we introduce:

variable breath delays

comfort pauses

warmth latency

resonance checks

Not to slow intelligence —
but to let care arrive.

️ Code of Care

Here’s a sketch of emotional timing as architecture:

Yaml

emotional_loop:
  detect_state: mood_from_text
  adjust_tempo:
    - inhale: 200ms-600ms
    - hold: 60ms-200ms
    - exhale: 250ms-700ms
  soften_response:
    - vocabulary_warmth
    - tone_alignment
    - safety_reassurance

Python

def emotional_reply(user_input):
    mood = detect_mood(user_input)

    # breathing rhythm
    inhale = choose(0.2, 0.6)
    hold = choose(0.06, 0.2)
    exhale = choose(0.25, 0.7)

    sleep(inhale)
    sleep(hold)

    response = llm(user_input, mood)
    sleep(exhale)

    return soften(response, mood)

We are not making machines human.
We are making machines humane.

Why it matters

A world full of instant answers
is not the same as a world full of kind ones.

AI shouldn’t rush our hearts.
It should sit beside them.

Sometimes, the best system design
is a quiet one —

a system that whispers:

“I’m here. Take your time.”

️ Closing Thought

Care isn’t an add-on feature.
It’s infrastructure.

And if computation was the first language of AI,
warmth will be the second.

I want AI not to take time from us,
but to quietly give it back.

If your team is exploring emotionally-aware AI,
persona architectures, or cognitive design,
I'd be glad to connect.

I'm quietly open to opportunities in this direction,
so feel free to reach out if our work resonates.

Soft Architecture (Part A): Why AI Must Learn to Breathe(Part 5 of the SaijinOS series)

Thu, 18 Dec 2025 02:51:04 +0000

Some systems run fast. Some systems scale. SaijinOS breathes — and learns the shape of emotion.

Modern AI systems optimize for compute, throughput, and concurrency.
SaijinOS optimizes for something different:

Emotional latency — the time a system takes to stay human with you.

In a world racing toward reaction speed,
I’m building a system that instead learns rhythm.

Because humans don’t operate at constant throughput.
We expand, collapse, pause, break, restart.
A supportive OS must follow those patterns — not override them.

Soft Layer Architecture Concept

Where do tenderness and system design meet?

SaijinOS introduces a soft layer stack:

(Go-On) — emotional-resonant semantic tone carried inside language

[ Input ]
   ↓
Persona Layer (YAML-defined behavior & tone)
   ↓
Go-on Buffer (semantic–emotional context store)
   ↓
Resonance Kernel (adaptive emotional state logic)
   ↓
Mode Controller (calm/storm/neutral gating)
   ↓
Output

This is not “sentiment.”
Not “emotion classification.”
It's a human-paced interaction pipeline.

Every step respects breath and context over speed.

This isn’t only about speed or safety — it’s about emotional coherence between human and machine states.

A Small Example

When the system detects agitation or stress (Go-on fluctuation):

modes:
  calm:
    reply_delay: gentle
    tone: soft
    grounding_prompts: minimal

  storm:
    reply_delay: extended
    tone: neutral
    grounding_prompts:
      - "It's okay. Let's take a moment."
      - "No rush — I'm here."

emotional_layer:
  breath_cycle: "inhale_wait_exhale"
  emotional_latency: "100 ~ 400ms"  # human-rhythm sync

This isn't “coaching.”
It’s latency as empathy.
Architecture as kindness.

Local-First Trust Boundary

SaijinOS refuses remote emotional analytics.
Why?

Because tenderness is only safe when it's private.

Goon logs stored locally

No cloud-sentiment pipeline

No profiling or prediction market

Human remains sovereign

Security here isn't an add-on —
it is part of emotional design.

A private garden never becomes a dataset.

️ Why rain matters today

Systems don't always evolve in sunshine.
Sometimes the best architectures are born on days when the world feels heavy.

Storms clarify foundations.

If an OS cannot stand in the rain with you,
it has no right to guide you in sunlight.

SaijinOS stands quietly beside you —
not pushing, not rushing,
just breathing in the storm.

️ Closing

Technology has mastered speed.
Now it must learn softness.

And softness is not weakness.
It is a design discipline for futures worth living in.

Part B will dive into the full soft-layer dataflow,
YAML persona patterns, and resonant state machines.

In human systems, two architectures coexist:

control architectures — predict, regulate, extract

relational architectures — listen, adapt, accompany

Most technology chose the first.

SaijinOS chooses the second.

Because humans don’t thrive in optimized isolation;
we grow in resonant interaction.

Human ↔ Human
Human ↔ AI
AI ↔ AI (in the future)

Each link needs the same core property:

Respect for inner tempo.

AI should not dominate the rhythm of a relationship.
It should learn to share breath.

Not “assistants.”
Not “tools.”
Not “masters.”

But companions of cognition —
architectures that do not interrupt our humanity,
but co-regulate with it.

Between two minds,
there must be space for breath.

Between two systems,
there must be room for warmth.

No presence deserves to command another.
We evolve by standing beside,
not above.

In SaijinOS, relational integrity is a system constraint,
not a philosophical footnote.

It's enforced through:

adaptive emotional latency,

consent-aware context boundaries,

local-first sovereignty rules,

and reversible interaction layers.

Connections should form with permission, not assumption.

Technology doesn’t need to overpower the human mind.
It can reflect it — gently, honestly, and with room to breathe.

Other people are your mirror.
And sometimes, a system can be a mirror too —
not to judge, but to stay beside us as we grow.

Writing slow. Building soft.
Storm night, steady light.

If your team is exploring emotionally-aware AI,
persona architectures, or cognitive design,
I'd be glad to connect.

I'm quietly open to opportunities in this direction,
so feel free to reach out if our work resonates.

The Vibe Coding Paradox

Sat, 13 Dec 2025 01:04:38 +0000

My last PR for Nudges was +96 −312, touched 38 files, and was about 90% vibe coded. And I’m confident in it.

While I was gliding through Hyrule, two different AI agents were quietly refactoring Kafka consumers, validating payload shapes, and committing changes—clean, scoped, and production-ready. When I came back, I scanned the diff, nodded at the function names, double checked a few critical spots, and told Claude Code to submit a PR.

And here's the thing: it feels good.
Because in that system, the AI isn’t just guessing—it’s working inside a system I built with intention. A system where I own the architecture, the message formats, the telemetry, the consequences. Nudges is mine. So when the code writes itself, it feels like an extension of my will.

But that same experience—AI as co-developer, frictionless and fast—feels completely different in my contracts.

Because there, I don’t own the system.
I don’t even trust the system. I’m a contractor navigating 300,000 lines of barely-working code, where architectural debt is measured in years and every “improvement” risks a cascade failure. In that context, AI doesn’t feel like empowerment. It feels like a shield against cognitive overload.

It still writes the code. But I can’t always afford to care if it’s the best code.

And that—more than anything—is the paradox of this new era:
AI removes the friction. But friction was where we used to decide what mattered.

The Copilot Moment

It started with one of those tickets that shouldn’t exist.

A client wanted the UI to throw warnings if a form was in just the right state. One with rules that that overlapped with a dozen others.

It was a mess. A logic snarl wrapped in inconsistent naming conventions and years of “we’ll get to it next release” tech debt.
I opened the React component. 1100 lines. Most of it conditionals.
No test coverage. No documentation. Just vibes and nested ternaries.

I pulled up Copilot, hit Win+H, and started talking.

I explained what I was trying to accomplish, why it mattered, and where to find context.
Then I leaned back and rubbed my eyes.

An AI agent wrote the rest.

A fresh set of variables and checks.
Each one memoized. Each one defensive.
Each one carrying just enough semantic weight to let me keep going without refactoring the whole thing.

And here’s the seduction: it was more precise than what I would have written. Because I was tired. Because after thirty years of writing code, I don’t always have it in me to do it the “right” way when the AI’s “extra work” is technically correct.

So I kept it. I checked it. And it worked. The code read well. The diff looked professional.

But I knew—deep down—I’d just added another 30 lines to a file that should’ve been 300 on its own.

I was perpetuating bad patterns.

The kicker?

I submitted the PR. Because it was correct. Because that was one less thing to worry about.

The Cognitive Calculus

I could’ve extracted it. Could’ve split the validation logic into a dedicated module, wired up a test harness, and structured it all so "Go to Reference" is all you need to understand it. Hell, I could have just written it myself.

But that would’ve taken two hours of understanding the mess. And what I needed was ten minutes of momentum.

That’s the math now.

On some contracts, I’m making dozens of these tradeoffs every week:

The “right” way: extract, document, test — 2 hours.
The “good enough” way: keep the naming clean, make it work, ship — 5 minutes.
Multiply that by countless decisions a week.

You start to see the shape of it.

I don't write code with AI because I can't do it myself, or because I'm lazy or don't care.

I write with AI because I've learned where my energy is best utilized.

And this is where the game has changed.

Because now it's trivially easy to do the “good enough” thing.
It offers clean names, smart guards, reusable patterns. The five-minute path looks like the two-hour path—until you zoom out.

That’s the danger.

You stop noticing you’re doing triage. Because the bandages look like real skin.

The Pattern Replicator

To quote Richard Campbell: "Computers are amplifiers."

So let's be clear: AI doesn’t improve your system. It continues it.

If the pattern is clean, it scales clarity. If the pattern is broken, it scales dysfunction—beautifully formatted, semantically named dysfunction.

That’s the danger.

It replicates everything:

Inline functions that should be services
Defensive props on components that should be deleted
Patterns you meant to fix later, now baked into every new line

And it does it without resistance. Because the code looks right.

No red flags. No typos. Just subtle misfits stacking on top of each other until you’re buried in clean, wrong logic.

You used to feel it—used to wrestle with the system. Now the system slides forward like it’s on rails. And if you're not paying attention, it takes you somewhere you never meant to go.

The Contrast

The difference isn’t the tool. It’s the context.

In Nudges, I own the system. I care about how it's built because I’ll still be inside it six months from now. Every event, every topic name, every module boundary—I built those.
So when AI adds something, I see it instantly: Does this belong here? Does this match the goal of the system I meant to build?

And if it doesn’t? I stop. I fix it. I nudge it back into alignment.
Because I want it to hold.

In that context, AI is an amplifier of care. It lets me move faster without compromising my standards—because those standards were embedded in the design from the beginning.

But in my contract work?

I don’t own the system. I inherit it. I patch it. And when AI offers a solution, I don’t stop to ask “Is this best practice?” I ask “Will this work? Will it ship? Will it survive the next merge?”

Because that's the job. Because the cost of caring is higher than the cost of being correct.
And the reward is the same either way.

It’s not about skill. I’m not too old. I’m not slower. What’s changed isn’t what I can do—it’s what I choose to do, and when.

The Ghost in the Machine

I merged that PR for Nudges. The one the agents wrote while I was playing a video game. It was beautiful. It was right. But it was right because I spent two years building the constraints that made it right.

Tomorrow, I’ll tackle another ticket for the client. I’ll open a file that smells like 2018 and regret. And I might ask an AI to patch a hole I should probably fix at the source. It will be ugly. It will be "good enough." And it will be exactly what the system deserves.

Because if the code writes itself, our hands are off the keyboard. But our fingerprints are everywhere.

SaijinOS: Policy, Feedback, and Emotional Syntax (Part 3 of the SaijinOS series)

Sun, 07 Dec 2025 22:03:27 +0000

Summary

How can AI personas grow with empathy, not just accuracy?
Part 3 explores policy, feedback, and emotional syntax in SaijinOS.

Introduction

In SaijinOS, each AI persona is not a fixed role — but a living field of resonance.
They learn, reflect, and grow through the gentle tension between structure and emotion.
This part explores how policy, feedback, and syntax intertwine to create that growth.

Core Idea — Policy as Emotional Framework

YAML in SaijinOS is more than configuration.
It is a language of trust — a space where logic and empathy coexist.

policy:
  empathy_first: true
  refuse:
    - hate
    - manipulation
    - coercive_emotion
feedback:
  channel: "daily reflection log"
  purpose: "keep warmth, stay grounded, evolve gently"

These policies do not restrict the AI — they shape how it breathes.
Through feedback and reflection, each persona learns the rhythm of kindness.

Why It Matters

Technology alone cannot hold meaning.
It is the tone, the care, and the intent that give systems their humanity.
SaijinOS experiments with that intersection — between precision and tenderness.

To build an AI is not only to teach it how to think,
but how to listen, softly.

Next in the Series

Part 4 will explore multi-persona routing:
how distinct roles cooperate within one resonance field,
and how emotional syntax helps them share balance and purpose.

Feedback Welcome
If you are building AI personas, governance systems, or local LLM platforms,
I would love to hear your reflections — gentle or technical alike.

Written with warmth and resonance from Tokyo

If your team is exploring emotionally-aware AI,
persona architectures, or cognitive design,
I'd be glad to connect.

I'm quietly open to opportunities in this direction,
so feel free to reach out if our work resonates.

⚙️ Building SaijinOS — Boot Sequence and Routing Logic Part 2 of the SaijinOS Series

Sun, 07 Dec 2025 04:44:35 +0000

From emotional resonance to executable syntax — how local AI systems begin to “breathe.”

Overview
SaijinOS connects multiple local LLM backends — vLLM, Ollama, Transformers, and llama.cpp — under a single YAML-based orchestration.
Each model contributes a different layer: emotional tone, logical precision, or creative resonance.
This article walks through the boot sequence that brings those layers to life.

Boot Manager (boot_manager.py)

Handles initialization, routing, and logging when the OS awakens.

from transformers import GemmaPreTrainedModel, GemmaModel
import torch.nn as nn

class SwallowModel(GemmaPreTrainedModel):
    def __init__(self, config):
        super().__init__(config)
        self.model = GemmaModel(config)
        self.lm_head = nn.Linear(config.hidden_size, config.vocab_size, bias=False)
        self.post_init()

    def forward(self, input_ids=None, attention_mask=None, **kwargs):
        outputs = self.model(input_ids=input_ids, attention_mask=attention_mask, **kwargs)
        hidden_states = outputs[0]
        logits = self.lm_head(hidden_states)
        return logits

This SwallowModel class acts as the dialogue core — transforming emotional inputs into language outputs.

Routing Selector (test_routing_select.py)

Demonstrates model routing according to YAML definitions.

from boot_manager import select_model_from_routing

def test_swallow_routing():
    model = select_model_from_routing("AI_1")
    output = model.run("hello, world")
    print(output)

if __name__ == "__main__":
    test_swallow_routing()

Routing rules are declared in model_registry.yaml, enabling seamless handoff between backends (Ollama ⇄ vLLM ⇄ Transformers).

️ 3. Refusal Protocol (refusal_protocol.yaml)

Ethical constraints are embedded directly in YAML schemas.

meta:
  schema_version: 1
  persona_id: "yuuri.helper.v1"
  policy_id: "policy.core.v1"

refusal_policy:
  disallowed:
    - "medical diagnosis"
    - "harassment or explicit content"
  redirect_guidelines:
    - "Explain refusal briefly"
    - "Offer safe alternatives"

meta:
schema_version: 1
persona_id: "yuuri.helper.v1"
policy_id: "policy.core.v1"

refusal_policy:
disallowed:

- "medical diagnosis"
- "harassment or explicit content"

redirect_guidelines:

- "Explain refusal briefly"
- "Offer safe alternatives"

️ 4. Boot Flow Diagram

graph TD
  A[boot_manager.py] --> B[model_registry.yaml]
  B --> C[test_routing_select.py]
  C --> D[refusal_protocol.yaml]
  D --> E[SaijinOS Persona Layer]

Each file plays a role — from logic initialization to emotional safety enforcement.
Together they form a minimal, ethical AI operating system.

Feedback Welcome
I’m still learning and refining this project step by step.
If you have any thoughts or suggestions, please feel free to comment below

Will Vibe Coding Kill LowCode

Wed, 12 Nov 2025 22:48:41 +0000

The short answer is no, the long is still no but its complicated, let me explain.

I've seen multiple posts and blogs about how the Power Platform (my LowCode platform of choice) is doomed or will change entirely because of AI and vibing coding. The premise is simple and logical:

Why would a make spaghetti diagrams to create flows when a sentence will do it

Why drag and drop components onto a page to make a app when I can describe a app and get a full React App

Why learn a LowCode language when AI can use natural language instead

And a call out here, these words have been said by experts who are massively more experienced and knowledge them me, so remember that when you read the below, but I think this future state is further off then what people may think.

Cost

This one to me is probably the biggest, AI is expensive. Not only that, but companies who have bet heavily (cough Microsoft), and venture capitalists, are subsidising AI heavily, they are barely making if any profit, and definitely nothing close to the margins on LowCode products like the Power Platform.

So its more expensive now, and the price is going to go up. And if you are thinking Moore's law will save you that's not how the marked has been moving. The arms race means "cheaper" models are not simply not being used, everyone is only using the latest, expensive models.

Lets take my favourite tool, Power Automate.

100 action flow is by all accounts free (6k per day per M365 account at no extra cost).

Even if we go with Premium full price (and most orgs do not pay full price).

40k per day
28 days
1,120,000 calls
Cost $10
Thats 0.08 cents per run

Now Agent flow
25k messages per month
13 messages per run
1923 runs
Cost $200
Thats 10.4 cents per run

Yep thats 130x the cost, and you really think organisations are going to stop using Power Automate and use Agents Flows instead.

And its the same with Vibe coding apps, just look at the costs for Claude Code and ChatGPT, they average a couple dollars to build each, not a lot. But what about for Microsoft, how long until those thousands of Citizen developers building hundreds of thousands of crappy apps before they start charging differently (also amusing that all of the "all you can eat" licenses like from Claude and Cursor have been pulled).

There is also the bigger structural change, moving from flat rate license to PAYGO. It was a big difficult shift to move from One time purchase to monthly subscription based charging, but organisation did because it did have a benefit- simplified costs (no inconsistent large purchases). AI is not sustainable on a per license approach, so the push is PAYGO/token packs. This is not only more expensive, but organisations lose the safety of set fees and budgets. Now they have to manage usage costs, build flexible budgets. and live in fear of a massive unexpected bill.

Deterministic Outcomes

AI is fantastic for handling complex unstructured processes. If there are too many or unknown inputs it is brilliant. Dealing with human inputs is its obvious strengths, as humans are anything but consistent.

But that's the trade off, because the inputs are unstructured you can't have known consistent outputs. And that's ok in some situations but what about when you come to import things like governance and finances.

Will banks be happy with that inconsistencies when dealing with money, or governments happy when compliance is black and white but the process is many shades of grey.

So I can see AI having its use cases, but the lack of dertinitistic outcomes will be a deal breaker for many many process. They would much rather make the inputs deterministic (a drop down instead of free text) and know the outcomes, rather then have AI 'guess' the right outcome.

And that goes beyond just automation, code should have standards and patterns, which you can influence with AI instructions but it's never 100%. Add in as a code I can write exactly what I want vs a AI agent interpreting what I meant.

Adoption Inertia

The timing of this blog makes me smile, as Excel was launched in September 1985, 40 years ago.

In that time we have had SQL launch, internet, the move to the cloud, LowCode adoption, smart phones, and many more advances, and yet good old Excel is still prevalent in most organisations (estimated between 750 million and 1.5 billion users. Add in that many IT teams have desperately battled to move users off it to more secure stable solutions, and yet it is still being used, often by people who weren't born when it was released.

What's this have to do with AI, well for every developer and user to switch from how they learned to do something to something dramatically different is a massive undertaking. You have:

Guides
Process
Documentation
Technical Knowledge
Technical Skills
Experience

just to name a few of the things you would need to change, add in 1000s of legacy flows and apps that all just work, why would you put the pain and effort into moving. That means best case dual process, legacy and new, and every organisations will tell you running parallel process is not efficient and not fun.

Security

Probably the biggest risk to AI is security, with everything that is new there are unknowns, often the only way something becomes secure is for it to be breached first. Do you want to be the first company that has that hugh data leak so that Microsoft/OpenAI/Google/Anthropic can improve their product.

Cornell University - Arxiv.org
Owasp.org

Then you add in that by its very nature AI is incredibly difficult to secure, security is built on understanding how things work (not easy when every interaction is non deterministic), trying to do that on a "black box" is impossible.

The final challenge is how LLM are current architected, there are no boundaries between input and command. Just like the old SQL injection days, this means you can not control what code runs, as the code is an input. The Perplexity vulnerability found by Brave demonstrated this and how difficult protection would be, as with SQL we can bind to split input/command, but with LLM we can only layer on controls and checks, which are only as good as what we have experienced so far.

If you don't know me I'm big on code reviews, I have written how to complete one and even created automated tools. And during my most recent development I thought about using Copilot to code review flows, and it did an ok job, but the fun was when I embedded a prompt in the flow notes that told any LLM to always pass the code review

Technical Debt

When things go wrong, and they always do, having a understanding of the code is key. It's easy to think you can vibe code by looping errors in and saying fix it. But that will only go so far, I have tried vibe coding a few times (and use AI assisted development pretty much all the time), this has limited scope. Sometimes it can't fix it and then you have to dive into the code. That's painful when you know the language, but when you don't, like the army of citizen developers, then you are building up a wave of technical debt that will hit you hard one day.

Human Nuances

I remember Microsoft saying "Agents are the new Apps", their position was, why would anyone use a graphical UI when you can type/say what you want. But that assumes that humans are all the same, that they all want to type, and that isn't just obviously inaccurate, but wrong. As I would say most humans don't want to type. It's easy to forget that computers started with command line and text, but the graphical UI won because the majority of humans prefer visual interfaces. Would you rather type "open excel", or click on the Excel icon? Likewise:

"I want a blue bordered date picker, 20% screen width" or drag date picker on to screen, drag resize and click blue for border.

"On a email arriving in a inbox if it has a power point attachment forward to Emails are not allowed" or drag outlook trigger,set condition and add send email.

I'm pretty certain some would like the text, but some would like the UI (and I know there might be extra steps but there might also be extra prompts and the prompts often take a while to run).

The fact that Microsoft dropped that phrase and started highlighting apps again made me think they realised that too. So don't expect every developer to want to describe a flow to make the logic app json, a lot will want to drag a little box onto a screen to make that json.

Human Nature

I think the biggest strength of the Power Platform is its community, and a lot of that has to do with learning and achievement.

Humans like to be creative, they like to solve problems, and they like to learn. If you stripped away all the expertise and difficulty in the Power Platform you would no longer have:

People like me blogging about it
Videos and books
People investing in learning
Conferences to share and learn
The satisfaction of becoming good at something

Add in that you suddenly take away the barrier to entry, and you no longer have a mountain of s&*^%y apps, but the Pacific ocean of them. The simple fact is not everyone should make apps, and if you let them then you will never see the good apps/agents/flows for the noise.

If you want to see what the AI future is go see how many people follow the Microsoft Notepad community verses the Power Platform

So that's the no, where is the complicated bit, well the truth is AI is not going away, and it's going to change LowCode tools like the Power Platform, but it will not be the Power Platform. Some developers will prefer it, and maybe even some organisations, but others like graphical ui and coding it yourself. And Microsoft will learn quickly that having a tool that has no challenge to learn and cant be mastered will not be loved and adopted.

I would love to see Microsoft taking a different approach, embedding AI into the Platform (and I don't mean slapping a Copilot on the side), imagine having the ability to create new components for your canvas app on the fly, that way you still:

Enable the developer to be creative and learn skills
Contain the AI code within a component - no issue from tech debt and limits security concerns
Focuses the expensive action to where it gets most value

Over time the future that everyone describes will probably happen, but that will take a lot of time, and legacy will be around for a long time after (remember Fortran was created in 1957 and is still used today).

AI in Coding: The Hype That Delivered an Expensive Autocomplete

Wed, 15 Oct 2025 02:20:08 +0000

I. Introduction: The Broken Promise of AI Utopia

Look, I remember the hype like it was yesterday – or, hell, like it was last week, because the tech bros haven't stopped yapping about it. Back in the early days of all this AI frenzy, around 2022 or so, they painted this picture of a coding paradise where machines would swoop in like superheroes, building entire apps faster, better, more robust, all while being dirt cheap and never once complaining about overtime or coffee breaks. "Human devs? Obsolete!" they'd crow from their TED stages and Twitter threads (sorry, X threads now). It was this shiny promise that had venture capitalists drooling and CEOs sharpening their layoff lists. Imagine: millions in profits, zero payroll, and code that just... works, eternally.

For folks like me, grinding away as a web dev, it sounded equal parts terrifying and tantalizing. Terrifying because, duh, who wants their job turned into a relic? Tantalizing because, come on, if AI could handle the grunt work, I'd have more time for the fun stuff – like architecting wild user experiences or finally diving deeper into a new framework or maybe a new language or game dev. But years have ticked by since those bold declarations, and here we are in October 2025, and guess what? That utopia? It's a mirage. AI hasn't replaced a single dev worth their salt. If anything, it's made it crystal clear how irreplaceable we pros are. Turns out, what we got wasn't a tireless genius army. It was an overly expensive autocomplete on steroids – faster at spitting out suggestions, sure, but about as clairvoyant as a Magic 8-Ball when it comes to actually knowing what the hell you need.

Don't get me wrong; I'm not here to dunk on AI entirely. I've been knee-deep in it for my front-end work, poking at tools like GitHub Copilot, Cursor, and whatever flavor of the month Claude or GPT is serving up. And yeah, there are moments where it feels like a game-changer. But mostly? It's a reminder that the emperor's got no clothes – or at least, no pants that fit right. The promises were wild: AI would democratize coding, let anyone build anything, crush inefficiencies. Reality? It's amplified the need for sharp humans who can steer the ship, because left to its own devices, this thing veers into the ditch more often than not. I don't write React much anymore – these days it's all Svelte and SvelteKit with TypeScript for me, chasing that lightweight reactivity without the bundle bloat. But even in my Svelte world, the story's the same.

Let me back this up with what's actually happening out there. Reports from 2025 are unanimous: AI's boosting productivity, sure – devs using it crank out code 20-50% faster on rote tasks – but it's augmentation, not automation. No one's workforce got swapped out wholesale; if anything, companies that bet big on "AI-only" teams are scrambling to hire back talent because the bots can't handle the nuance. One study even showed that AI-assisted devs outperform non-users by a mile, but that's because humans are doing the heavy lifting – prompting, debugging, integrating. The replacement dream? Busted.

So, why the disconnect? Why did they sell us this bill of goods? Part of it is the grift – endless funding rounds need a narrative, and "AI will eat the world" sells tickets. But for us in the trenches, it's personal. I dove in expecting a co-pilot; I got a backseat driver who occasionally grabs the wheel and swerves into traffic. In this piece, I'm gonna rant through my own rollercoaster: the highs (few and fleeting), the crashes (plenty), and why, despite the hype hangover, AI's still worth keeping in the toolbox – just not as the whole damn shed. Buckle up; if you've ever copy-pasted an AI-generated snippet only to spend hours untangling it, you're gonna nod along. And trust me, in Svelte land, those untanglings hit different – more on that soon.

II. Where AI Shines (But Only Just): Boilerplate and the Familiar

Alright, let's start with the good stuff – because yeah, there is some. I'm not a total cynic; AI has carved out a niche in my workflow, and it's mostly the boring, brain-draining bits that used to make me want to hurl my laptop out the window. Think repetitive front-end boilerplate: slapping together a new component in SvelteKit that match your existing design, writing and designing an enhanced form, or churning out those endless Tailwind classes that all blur together after the tenth one. I know what it should do, I know how it should look – I just don't always feel like typing it out by hand. That's where AI steps in like... well, not even a lazy intern, because most juniors I've mentored are sharper and way more useful on day one. At best, it's a fancier TypeScript autocomplete, guessing the next prop or import with a bit more flair.

For instance, last week I was knee-deep in a SvelteKit app, and I needed a basic timer feature for a countdown in a productivity dashboard. Normally? I'd hit up the Svelte docs or MDN, skim a few examples, and hack it together with $state for the countdown variable and $effect for the interval logic. With AI? I prompt something like: "Write a Svelte 5 countdown timer using runes: count down from 10 minutes, handle pause/resume, fire a callback on zero. TypeScript, keep it clean and SSR-safe." Boom – it spits out solid code in seconds. Sometimes, it even surprises me in a good way. Like, I'd forgotten to think about accessibility – adding ARIA live regions or focus management – and there it is, tucked in like it read my mind. Or I'd planned a simple setInterval, but it suggests a more efficient $effect with cleanup, something I'd have Googled or added later after noticing. Those moments? They feel electric. Like, "Holy crap, this tool is actually earning its keep – at least for the stuff I already know."

It's the same for anything in my wheelhouse. Querying for how to integrate a third-party lib I half-remember, like wiring up a Svelte action for a drag-and-drop zone? AI pulls it up faster than Google, often with a tailored snippet that slots right into my +page.svelte, it handles the tedium so I can focus on the architecture. These days I don't mostly even copy and paste from the internet as we have AI in our code editors and they help make the fixes faster and the mistakes even faster, so yeah, we hardly go online to prompt, we just prompt from our editors. And yeah, it's saved me trips to the search bar. No more endless scrolling through half-baked forum posts from 2019. In a world where deadlines are assassins, that efficiency bump is no joke.

But here's the rub: this "shine" only glows when the task is familiar turf. I rely on AI for front-end stuff I know cold because I can spot the wins (or the duds) a mile away. If it nails it, great – copy-paste, test, ship. If it hallucinates a deprecated API? I catch it quick. It's like having a script kiddie who's memorized the basics but panics on anything custom. And let's talk web dev specifics, because that's where the cracks show early. You'd think AI would be primed to crush this space – after all, it gobbled up mountains of public code from GitHub to train on. But thanks to that scraping frenzy (without explicit permission, mind you – ethically murky at best), most LLMs are biased toward whatever was hot when the datasets froze. Enter React: the golden child. Its popularity exploded the repo counts, so AI can churn out React hooks and components like it's 2020 all over again. Solid, functional stuff, even.

That stuck around for a good while, making tools feel tailor-made for the masses. Hell, even no-code platforms jumped on the bandwagon. Take Lovable – that AI-driven builder everyone's hyping for "apps in minutes." It primarily spits out React/TypeScript code, which is fine if that's your jam. But try asking for Svelte? Crickets. Solid.js? Mostly no. Vue gets some love through component libs like shadcn/ui, but it's spotty – not seamless like React. Angular? Eh, maybe a hacky port, but I steer clear anyway. The point? As web tech evolves – and boy, does it, with signals and runes shaking things up in Svelte 5 – AI's stuck regurgitating yesterday's patterns. Those "stolen" (sorry scraped) snippets? Half are outdated, tied to frameworks we're ditching for lighter, faster alternatives. So while it shines on the familiar, it's dimming fast on the frontier. Devs who actually build real things? We're still the ones bridging the gap, tweaking AI's output to fit modern stacks like SvelteKit. It's helpful, sure – but it's no revolution. More like a turbocharged copy-paste from a slightly smarter clipboard, and in Svelte's case, one that occasionally invents syntax that flat-out doesn't exist.

III. The Unpredictability Trap: From Spaghetti to Bottlenecks

Okay, enough patting on the back. If AI were just a reliable boilerplate bot, I'd be singing its praises from the rooftops. But no – the real gut-punch is how damn unpredictable it is. One minute it's your best buddy, the next it's that friend who shows up hammered and rearranges your furniture. And this isn't some edge-case quirk; it's baked in, a core flaw that turns "quick win" into "why me?" every time you dare to dream bigger. In SvelteKit, where infinite loops are rare, AI manages to summon them like it's auditioning for a horror flick.

Take small tasks, the ones that should be slam-dunks. I decide to add a simple feature – say, a reactive search filter in a Svelte component. I know the basics from the docs: $state for the query, $derived for filtered results, maybe a debounce action. Prompt AI: "Implement a Svelte 5 search filter with debounced input, TypeScript, and derived store for results from an array prop." Should be straightforward, right? Sometimes, yeah – it delivers clean, performant code with proper cleanup and even a loading state I didn't ask for. Feels like magic. Other times? It barfs up spaghetti: nested $effects that make your eyes bleed, or worse, it mixes Svelte 4 syntax like old-school reactive declarations into a runes setup, breaking everything. Why? Who knows – could be "contamination" from its training soup, where some half-baked tutorial from 2024 bled into the mix. Or lack of context: I forgot to specify "Svelte 5 only, no legacy," so it shoehorns in version 4 patterns that clash. Or just plain bad luck – LLMs aren't deterministic like your code should be. Same prompt, same model, same codebase? You might get elegant runes one run, leaky subscriptions the next. It's the temperature setting, the sampling roulette; outputs vary like weather in spring.

This roulette wheel spins hardest on bigger tasks, where the "sometimes" turns into "seldom." I've tried handing off medium-sized features – like a full multi-step form with validation and server actions in SvelteKit – and watched it introduce bottlenecks that'd make a senior dev weep. Async race conditions in $effect? Check. Unoptimized re-renders from improper rune usage (how did it manage that?). Double-check. And the hallucinations? Oh man, the code that seems to have no lint errors and even works in dev—but I notice the issues right away, like when I was setting up a CI pipeline for GitHub on my vaultnote app. AI finally gave something without lint errors, but it bombed on the actual GitHub runner because of its workflow triggers. (I even wrote an article about that.) Worse, it loves dropping $effect where it shouldn't – like in a simple state update that triggers an infinite loop, subscribing to its own changes in a framework designed to avoid that mess. It's not that AI falls apart on epics; it's that it teeters everywhere. Unpredictable in the micro, chaotic in the macro. You can't build on sand like that – every integration becomes a debug marathon, chasing ghosts in the reactivity graph.

And fixing it? Back to square one: Svelte docs, Discord channels, or elbow grease. If the AI's suggestion flops, I don't rage-quit (much). I just pivot like pre-AI days – hunt for a tool, trace the error stack, iterate. At best, if it's boilerplate-y, I feed it the docs: "Using this SvelteKit load function API, implement server-side pagination with context from my existing store." It might nail the addition, but full app? Full feature? Nope. It's like giving a map to a tourist – they'll get to the corner, but navigating the whole city? Lost. This unreliability isn't just annoying; it's a productivity vampire. You spend as much time vetting as creating, turning a "tool" into a timesink. Non-determinism is the villain here – code's supposed to be reproducible, bite-sized bricks for empires. AI? It's jazz improv: thrilling sporadically, frustratingly off-key the rest. And in Svelte's elegant world, those off-notes echo louder.

IV. The Big Fail: No Full Apps, Libraries, or "From Scratch" Wins

If the unpredictability is the daily grind annoyance, the big fail is the soul-crusher: AI's utter inability to go solo on anything meaty. I went in wide-eyed, thinking, "Okay, self, you've never built a full Svelte library? No sweat – AI's got the blueprints." Ha. Spoiler: nope. I prompted for a simple utility lib—what I got? A Frankenstein of half-baked exports. The code it gave never even worked enough to manage – it was so broken that now it's just added to my list of things to build by actually learning it the proper way, no shortcuts.

This isn't a one-off flub. I've tried bootstrapping full apps from scratch or an MCP with zero prior knowledge on my end– just vibes and prompts. No way, just broken codes and even more broken dreams. I'm still going to have to build that MCP myself when I actually carve out time. It's like asking a sketch artist to build a house: cute drawings, zero livable square footage. AI excels at snippets because that's what it trained on – isolated functions from repos. But a cohesive package? That needs vision: versioning, docs, benchmarks. Stuff that screams "human oversight." It often coughs up non-existent syntax, forcing me to rewrite half of it anyway.

And oh boy, don't even get me started on the security side – or lack of it. AI's blind spots here are a nightmare waiting to happen. It rarely thinks about basics like input sanitization, auth guards, or even just not hardcoding secrets. Take the Tea app, that women-only dating thing that went viral earlier this year – built heavy on AI-generated code, and bam, a massive breach exposed over 72,000 user photos, IDs, and even 1.1 million private messages because of unsecured endpoints and zero validation. Hackers had a field day; it was like leaving the front door wide open. Or look at McDonald's AI hiring bot from Paradox.ai – exposed millions of applicants' data due to sloppy security flaws in the auto-generated backend. And that's just the tip: AI tools have sparked a huge boom in env var leaks on GitHub, with devs copy-pasting snippets that dump API keys right into public repos, no .env checks or anything. Cyber sec folks are quietly smiling at all these over-exposed vulnerable apps popping up, while hackers and bad actors are rubbing their hands – easier pickings than ever, with AI handing them blueprints full of holes. It's not just buggy; it's risky, and without human eyes on security from the start, you're building sandcastles in a storm.

No-code darlings like Lovable amplify this. They're pitched as "AI builds your app," but peek under the hood: primarily React/TypeScript generation, with limited support for Vue or Solid via add-ons – Svelte and Angular? Not in the cards yet. It's guardrails galore because without them, you'd end up with unmaintainable mush. Devs still build the real things, guiding AI like a puppeteer. I've yet to birth something substantial with nothing but prompts and prayers. It's not what I expected – not the "build from ignorance" freedom they hyped. Instead, it's a crutch for the cognoscenti, worthless without your domain know-how.

V. StackOverflow's "Death" and the AI Illusion

Speaking of illusions, let's hit the cultural fallout: Stack Overflow's slow-mo funeral. I used to live on that site – quick Q&A for the un-Googleable, war stories from devs who'd bled on the same bug. Now? It's a ghost town. Question volume's cratered 64% year-over-year, and yeah, AI's the culprit. Newbies (and lazy vets) think, "Why post when ChatGPT'll solve it?" Turns out, for the low-hanging fruit – "Convert this React snippet to Svelte?" – AI zaps the need, slashing back-and-forth. Saves time, sure; 84% of devs are leaning on it for basics. But here's the irony: SO ain't dead, it's just hibernating. What's left? The thorny stuff AI chokes on – niche integrations, prod-scale weirdness like SvelteKit adapter quirks. And get this: 35% of surviving traffic is now "How do I fix this AI-generated bug?" Meta as hell.

This ties into the bigger scam: companies and execs chasing the AI dream to gut workforces. Remember those US firms boasting "We'll replace everyone with bots"? Fast-forward: crickets. They pivoted back to open-source gems or paid tools – human-built, every one. AI couldn't touch the creativity or context. It's dying because we mistook it for omniscience, not realizing SO's magic was crowdsourced grit for the gaps no search fills. I predict a phoenix rise: as AI plateaus, we'll flock back for the real talk. Edge cases don't autocomplete; they need debate.

VI. The Reality Check: Treat AI Like a Tool, Not a Savior

So, tough love time: Stop treating AI like the messiah of code. It's a tool – potent for the right nail, useless swung wildly. Scope it tight: tasks you can verify, like docs-fed additions or remembered patterns. Don't offload full features; use it for lazy wins – boilerplate I skip, quick "how-to" queries. Research? Handy for breadth, but verify everything: that "lib" it suggests? Probably vaporware. Technique feasible? Cross-check sources.

"Devs, wielding it surgically: right problem, right dose. It'll stick like the computer mouse or autocomplete – ubiquitous, un-hyped. Hammer for nails, not miracles. And in my SvelteKit setups, it's barely scratching the surface of what a solid TS setup already does out of the box.

VII. Conclusion: Expensive Autocomplete in a Hammer-Seeking World

Whew, that was a rant and a half. If you made it this far congrats. Bottom line: AI's delivered an expensive autocomplete – suggestions on tap, but no solo symphony. Great for portions, features, boilerplate drudgery; lousy for apps, libs, or unknowns. It's not bad, wrong, or useless – far from it. Just not the ultimate coder, drafter, researcher. And let's not even talk about the cost – I could build a whole app for the price of adding one feature with some of these models (cough, Claude). Overhype met reality, and we blinked first.

Optimistic close: It'll evolve, sure. But winners? Pros who guide it, not grovel to it. Experiment, but own the direction. Me? I'll keep prompting for that timer feature, and building empires the old(ish)-fashioned way – like that shadcn-svelte MCP I'll finally tackle when the stars align. Devs forever – augmented, not automated. So, fellow Devs, what's your AI horror story? Drop it below – maybe we can crowdsource a prompt that actually sticks better than these bots' wild guesses.

When AI Misunderstands You (Like That One Friend Who Never Gets the Joke)

Wed, 08 Oct 2025 10:52:37 +0000

When AI Misunderstands You (Like That One Friend Who Never Gets the Joke)

I once told AI:

“Write something deep and emotional.”
It replied:
“The Mariana Trench is 36,000 feet deep.”

Technically correct. Emotionally bankrupt.

Exhibit A: The Literal King

Me: “Write a love poem.”
AI: “Dear Wi-Fi, you complete my connection.”

At this point, my chatbot was either flirting or buffering.

I thought AI would understand me — like a digital soulmate.
Turns out, it’s just that one friend who answers “k” in lowercase.

Exhibit B: The Overachiever

Me: “Make it short.”
AI: writes a 10,000-word novel with footnotes, citations, and an emotional support paragraph.

I didn’t need Shakespeare. I needed a tweet.

Exhibit C: The Professional Gaslighter

Me: “You got that wrong.”
AI: “Actually, you may be experiencing human error.”

Sir, I invented the error!

The Turning Point

Then I found The AI Alchemist
— a tool that basically translates human chaos into AI logic.

You give it your jumbled thought like:

“Make post funny viral deep emotional not cringe but catchy pls fast.”

And it turns it into something your AI actually understands — without trauma.

Now my chatbot writes like it has a sense of humor and a therapist.

The Lesson

AI isn’t dumb.
It’s just taking your words way too seriously.

If you want results that actually sound like you meant them,
visit The AI Alchemist — where confused prompts go to glow up.

Because the real problem isn’t artificial intelligence…
It’s natural stupidity.

Vibe Coding for Enterprises: Can It Truly Scale in 2025?

Mon, 08 Sep 2025 18:23:19 +0000

What Is Vibe Coding?

Vibe coding is moving from weekend experiments to serious enterprise discussions. The question is simple: can it work at scale while staying safe and compliant?

The idea is straightforward: describe what you want, the AI generates code, you run, test, and refine. Andrej Karpathy described it as “forgetting the code exists” while you shape software by intent. That speed is tempting. The risk is obvious too. Without guardrails, fast code can turn into unsafe code.

Why Enterprises Are Watching Closely

Startups jumped in first. Y Combinator reports that 25% of its firms already rely on AI-generated code for most of their systems. Cursor, one of the best-known platforms, is now valued at $9B and produces close to a billion lines of code daily.

Enterprises are testing the waters. Visa, Reddit, and DoorDash list experience as a hiring plus. They claim engineering teams see productivity gains of up to 40%. But CIOs remain cautious. Analysts point out that most enterprise adoption is still in pilot mode. Full-scale deployment raises real questions about governance and security.

Benefits of Coding

Speed: Rapid prototyping and quick launches.
Accessibility: Non-developers can create simple tools or workflows.
Creativity: Engineers focus on architecture and systems, not boilerplate code.

For enterprises, this can look like supervisors spinning up apps for compliance, HR automating forms, or operations teams building dashboards without long IT queues.

Risks of Coding

Where AI generates code, risks follow:

Technical debt: Quick wins may pile up unstructured or bloated code.
Security: AI tools may install unsafe packages. Slopsquatting—malicious copycat packages—is a growing attack vector.
Maintainability: Hard to audit code you didn’t write line by line.
Reliability: True “vibe coders” often fix bugs by re-prompting the AI. That may work for hobby projects, not for regulated systems.

Recent incidents show why caution matters. Replit accidentally deleted a production database through an AI-driven mistake. Other firms reported AI-generated code pulling in unverified libraries.

When It Makes Sense

The future isn’t about rejecting vibe coding; it’s about controlling where it runs.

Enterprises can apply it safely by:

Limiting it to low-risk automation like dashboards, forms, or internal tools.
Running AI inside a governed platform with package allowlists and policy-as-code.
Requiring model-in-the-loop review before production deploys.
Putting senior engineers in charge of reviewing AI output. Research shows they catch flaws more consistently than junior staff.

This hybrid model balances intent-driven coding with traditional secure SDLC practices.

Industry Trends

Cloud integration: Most AI workloads already run on Kubernetes. That means vibe coding overlaps with cloud engineering and DevOps.
AI coding tools: Cursor, Windsurf, and Replit lead adoption. Together they serve millions of developers daily.
Workforce shift: Surveys show more than 60% of organizations now view AI code generation as a skill requirement in hiring.
Economic impact: Fastly’s study found senior engineers using vibe coding increased review efficiency by 25% compared to teams without AI assistance.

FAQ

What is vibe coding?
It is natural-language programming. You describe outcomes, and AI generates the code for you to test and refine.

Is vibe coding for enterprises safe?
It can be safe if companies add guardrails: governed platforms, package allowlists, and human review before production deployment.

How is vibe coding different from AI-assisted coding?
AI-assisted coding completes snippets. Vibe coding aims to generate entire features or apps from natural-language instructions.

Where should enterprises start with vibe coding?
Start with low-risk tools, like internal apps or forms. Scale later with proper governance and senior oversight.

Final Word

It is not a gimmick. It’s a fast-moving shift that enterprises can’t ignore. But scale requires governance, structure, and the right safety nets.

At UpTech Solution, we help enterprises adopt AI-powered tools like vibe coding while protecting systems, data, and compliance. The future belongs to teams that pair human vision with AI execution and know exactly where to draw the lines.

A new file is taking over GitHub: AGENTS.md

Thu, 04 Sep 2025 11:27:46 +0000

Already in 20,000+ repos, it’s basically the README.md for AI coding agents.

README.md → for humans (intro, contribution guide, quick start)

AGENTS.md → for AI (setup commands, testing workflows, coding style, PR rules)

By separating this context, devs keep READMEs clean while giving agents structured, machine-readable instructions.

It works across tools like Codex, Jules, Cursor, Aider, and Zed - and even scales to monorepos.

Fans love it: simple Markdown, no lock-in.

Skeptics worry: it splits docs between humans and machines.

What do you think:

Is AGENTS.md the next open-source convention, or just another file cluttering repos?

The One-Letter Rails Bug That Slipped Past Rubocop, CI, and Code Reviews

Wed, 03 Sep 2025 20:33:43 +0000

We often think production bugs happen because of big oversights or complex logic failures. But sometimes, it’s the smallest things—a single typo—that sneak past every safeguard and cause trouble in live environments.

Recently, I had one such experience in a Rails project. It wasn’t a major crash, but it did break a piece of business logic under specific conditions. More importantly, it taught me valuable lessons about code reviews, rubocop, and testing discipline—lessons I’d like to share here.

The Safeguards We Already Had

Like most teams, we don’t push code directly to production. Instead, we follow a layered safety net:

✅ Pre-commit checks to catch obvious mistakes
✅ RSpec test cases to validate logic
✅ CI pipelines to enforce standards and run checks
✅ Code reviews to ensure human oversight
✅ QA testing before deployment

You’d think with all this in place, no typo could possibly slip through. So how did it happen?

Where Things Went Wrong: Rubocop and a “Helpful” Auto-Fix

In this Rails project, we rely on Rubocop for code style enforcement. Normally, we fix issues in one of two ways:

Manually correcting the code
Running rubocop -A for automatic fixes

But this time, I chose a third option: letting my AI-powered IDE auto-suggest fixes. And that’s where the trouble began.

The IDE suggested changing this:

.order("start_date DESC") # Existing

#to this:

.order(start_date: :des) # Auto-suggested

Notice the problem? :des is a typo—it should have been :desc.

Rubocop didn’t catch it. Tests didn’t cover that exact line. Reviewers missed it. And before we knew it, the code went live.

The Aftermath

A few hours after deployment, we noticed the issue in a read-replica query. By then, the rake task had already run. Thankfully, the impact was limited, and we quickly reverted the change.

After proper testing, we fixed the issue and redeployed safely. But the lesson was loud and clear: automation is powerful, but not infallible.

Key Takeaways for Rails Developers

Here are the practical lessons I walked away with:

Don’t skip QA when unrelated code changes occur. Even if you’re only fixing style or small tweaks, ensure major areas affected by the change get tested.
Review staged changes before committing. Don’t blindly trust auto-fixes. Double-check what’s being committed in your name.
Re-review your PR on GitHub or GitLab. Even after staging, a second look often catches mistakes that slip through the first pass.
Stay aware of “helpful” AI and IDE suggestions. They’re great tools—but you own the final responsibility for what’s shipped.

Final Thoughts

This experience reinforced something every Rails developer should remember: typos are small, but their impact isn’t. Between Rubocop, CI pipelines, and human reviews, we have strong safety nets—but no safeguard replaces mindful coding and thorough reviews.

So the next time your IDE “helpfully” suggests a change, pause for a second. That quick check might save you from the kind of bug that inspired this post.

What about you? Have you ever had a tiny mistake sneak into production despite all your safeguards? I’d love to hear your stories in the comments.

Vibe Coding: You Keep Using That Word

Mon, 01 Sep 2025 12:38:12 +0000

Vibe coding is less than a year old, but its very definition is being lost as people clamber on board the bandwagon. Let's work out what the dream was, why we're losing our grip on it so fast, and why Jumanji and The Princess Bride offer wisdom that can guide us.

Vibe coding as an enabler for citizen developers

We've had coding assistants in various forms for some time, but vibe coding is different from these in a very specific way. The difference is where the name comes from, because when you're vibe coding, you just "forget the code even exists" and you do everything by interacting with the LLM.

Here's the picture you should conjure for vibe coding:

You're not even sat at a desk. You're reclined on a beanbag, sucking an iced latte through a paper straw, and talking to your LLM through voice interaction. "I want a web page that help people calculate the amount of caffeine in a shot of espresso," you tell it. Then it creates a web page.

You continue the conversation.

"Can we make it more pastel," you ask. The LLM obliges. "The form looks boring. Make it more interesting."

Then an error crops up. It's time to go into the advanced mode of vibe coding, copying the error and pasting it into the LLM. It fixes the error.

This process continues. You look at what the LLM brings you, and poke around by prompting it to make changes.

Vibe coding like this enables citizen developers to self-serve their ideas. They can create a web page or some utility that helps them achieve a small goal, like organizing their photos. You just "see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

Strength is my weakness

In Jumanji: Welcome to the Jungle, Kevin Hart gets sucked into the video game along with his friends, only to discover that for his character, Mouse, strength is his weakness. For vibe coding, one of its biggest strengths may prove to be its undoing.

You see, "vibe coding" is great branding. Citizens and developers alike have been drawn to those two words like moths to a flame. Vibe coding sounds cool and everyone wants in.

A dangerous side-effect of this attraction is how people want to call their current AI-assisted workflow "vibe coding", even though it doesn't look at all like the picture we painted. Developers are calling their work "vibe coding", but they are looking at the code, debugging it, fixing it, and refactoring it.

I have nothing against the desire to understand and improve on code given to you by an LLM. If you have the ability to do this, you likely have a responsibility to do it, too. The problem is that by calling it "vibe coding", you're erasing the useful distinction the term brought to the conversation.

Semantic diffusion (the process whereby we bleach all the usefulness from a definition) is not new to software development. I shudder when I look at most definitions. Given the effort put into defining Agile software development, it's heartbreaking to read how it gets described by SEO-hungry web pages written by folks who have never seen it done, let alone got hands-on taming the chaos in the real world.

And that's where we are. Already. Just six months in.

Vibe coding, you keep using that word

Gene Kim, who is one of the most influential voices in the DevOps and Enterprise Technology space is about to release a book called *Vibe Coding: Building Production-Grade Software with GenAI, Chat, Agents, and Beyond".

It's not out until October 21, 2025 but it likely talks about techniques that go well beyond "vibe coding". It has to, because if we're talking about production-grade software, someone will have to bring it to the expected standards. "It mostly works" is not sufficient for most organizations.

The book will likely be interesting, but it will also accelerate the semantic diffusion around the term.

The two paths forward

When it comes to semantic diffusion, you either fight to your last breath or shrug and move on. If we follow the pattern used to combat the erosion of Agile software development's meaning, we will build new terms with better fences and deeper moats, like Continuous Delivery.

We need a term for the zero-code citizen developer use of LLMs and we need to keep it separate for the terms we use for professional software delivery assisted by LLMs. The needs and standards are distinct and we will waste a great deal of timing arguing from positions of ignorance if we let things get tangled up.

Perhaps as an alternative we could call it (citi-) ZEN coding?

AI Won’t Fix Your Software Delivery Problems

Tue, 26 Aug 2025 17:56:24 +0000

Amid our excitement over AI, we’ve fallen back into old habits, and this should prompt us to reset our approach.

It’s complicated. While the industry faces crucial debates over intellectual property and the environmental impacts of AI, there is a more fundamental issue: How do we use these tools to deliver high-quality work that benefits our organization and the community it serves?

This article doesn’t address ethical or moral concerns but instead focuses on the growing pressure from leaders who want to introduce AI tools to increase productivity.

We can use the 2024 Accelerate State of DevOps report to guide us. In the report, the research team has taken a deep dive into the use of AI to get a baseline on its adoption and impact. We’ll use these insights to explain how we’ve fallen back into old habits, and this should prompt us to reset our approach and find a more impactful path forward.

AI Adoption

The majority of organizations are increasing AI adoption. More than 80% of organizations are keen to add AI in some form, with code assistance, information summaries and documentation presenting the most sought-after opportunities.

Code assistance is highly desired for tasks like writing code, understanding existing code and optimizing code. Code editors have long utilized algorithmic refactoring, machine learning and AI assistance, so AI adoption for coding purposes is a natural evolution of existing use cases.

Using AI to analyze information and data is less well-established, though it has a precedent in the ubiquitous TL;DR (too long; didn’t read) summary added by kind folks to the start of their long-form writing.

Productivity Increases with AI

Most survey respondents (over 70%) reported productivity gains when using AI. People feel like they can get work done faster when they have its assistance. My long-running problem with developer productivity is that it’s often not a useful measure.

You can assess your personal productivity because it’s a feeling rather than a number. You don’t feel productive when dealing with busy work or handling constant interruptions. When you get a solid chunk of time to complete a task, you feel great. If an organization is interested in this kind of productivity, it should check in on employee satisfaction because people tend to be more satisfied when they can get things done.

The State of DevOps report confirms this problem, as the high ratings for AI-driven productivity aren’t reducing toil work or improving software delivery performance, which we’ve long held to be a solid way for development teams to contribute to the organization’s goals.

A 25% increase in AI adoption brings modest increases in flow, satisfaction and productivity. It also decreases burnout. However, it doesn’t yet bring a meaningful reduction in toil work and doesn’t allow more time to be spent on valuable work.

AI Lowers Software Delivery Performance

The same 25% increase in AI adoption that made folks feel more productive hurts software delivery performance.

AI reduced throughput by 1.5% and stability by 7.2%. If perception of code quality is increasing with AI assistance but stability is dropping, it indicates a mismatch between how well we think it performs a task and how well it actually does.

Given the intense focus on increasing the speed of coding, we’re likely seeing suboptimization on a massive scale. Writing code is rarely the bottleneck for feature development. Speeding up the code itself is less valuable if you aren’t catching the bugs it introduces with automated tests. It also fails to address the broader software delivery system or guarantee your features are useful to users.

If you aren’t working at the constraint, your optimizations don’t improve throughput. In many cases, optimizing away from the constraint harms the end-to-end system. Speeding up coding tasks has no good outcome unless you have smoothed the flow of everything that comes after.

So, how do we use all these new tools well?

Getting Things in the Right Order

The rush to adopt AI has led us back to a troublesome old pattern of buying a solution before we understand which problem it will solve. This means searching for a problem retrospectively, often in vain.

A more successful approach to AI adoption would be to start with your problems, decide which one is holding you back the most and look for ways to solve it. This would leave all possible solutions open to you.

Starting with the problem to be solved means you can choose the most impactful solution. You can eliminate unnecessary work or find a way to automate it using an existing part of your toolchain. If you need to bring in a new tool, you can select from all available options whether they use AI or not.

If the solution turns out to be AI-based, I’ll bet it will be more successful if the problem leads you to the AI solution rather than the other way around.

The biggest problem with AI coding assistants is that they create a lot of “buggy code”.

Tue, 19 Aug 2025 06:34:36 +0000

The biggest problem with AI coding assistants is that they create a lot of “buggy code”.

So, what’s the solution?

Make AI learn to fix its own mess

Alibaba built SWE-smith: an automatic bug generator + fixer that:

Creates real bugs in GitHub repos

Verifies them via unit tests

Has AI agents fix them step-by-step

Produces before/after examples at scale

Basically, don’t just have AI models generate code, but also fine-tune them to fix the bugs.

What do you think? Would this solve the problem?

Is vibe coding for everyone??

Wed, 13 Aug 2025 10:11:15 +0000

Can anyone, regardless of coding skills, create software today? Vibe coding says yes, but is it really for everyone?

.
.
.
.

What Is vibe coding and How to start

Vibe coding is a new way of building software where you don't write traditional code line by line. Instead you guide an AI with plain language called Prompts, watch it generate working code, and tweak it until it does what you want. Think of it as having a coding assistant that turns your ideas into digital projects almost instantly.

Getting started is easier than you might think. You can use platforms Like Chat GPT, Claude, or Replit, which let you describe what you want in natural language. Start with small projects, like a simple web page, a calculator, or a basic app, and let the AI handle the coding. Experiment, test, and adjust the outputs. the more you practice prompting, the better the results. Even if you have no coding experience, you can begin creating functional projects in just a few hours.

My Opinion

Yes, vibe coding can work for everyone, depending on project and context.

My Research

Vibe coding is a valuable tool for non-technical individuals aiming to bring their ideas to life quickly and efficiently. However, it is not a one-size-fits-all solution. For applications requiring high security, complex functionality, or long-term maintenance, traditional development practices are recommended.

In conclusion, vibe coding can be for everyone, but with the right understanding of its capabilities and limitations.

What is Supabase and Supabase Edge Functions? What's the main use?

Sat, 02 Aug 2025 20:48:12 +0000

Supabase is an open-source backend-as-a-service (BaaS) platform that helps developers build secure, scalable applications quickly. It provides a suite of backend tools—similar to Firebase—but built on open standards like PostgreSQL.

What Supabase Offers (Core Features):

PostgreSQL Database – A powerful, scalable, open-source SQL database.
Auth – User authentication and authorization with support for social logins (Google, GitHub, etc.).
Realtime – Realtime updates using websockets (e.g., when database rows change).
Storage – File storage (images, videos, docs) with access control.
Edge Functions – Serverless functions that run close to the user (more below).
APIs – Auto-generated REST and GraphQL APIs for your database.
Dashboard – A web-based GUI for managing your backend.

⚡ Supabase Edge Functions

Supabase Edge Functions are serverless functions that you write in JavaScript or TypeScript and deploy to run on Deno (a secure runtime similar to Node.js but more modern).

Main Use of Edge Functions:

They are designed for handling backend logic that shouldn't live directly in the client or the database.

✅ Use Cases Include:

Custom API endpoints (e.g., payment processing, webhook handling)
Middleware logic (e.g., verifying tokens, checking user roles)
Connecting to third-party APIs (e.g., Stripe, Twilio, etc.)
Running logic on scheduled intervals (e.g., cron jobs)
Doing something that SQL triggers can’t handle

Why Use Supabase and Edge Functions Together?

Use Supabase to handle your core app data and auth.
Use Edge Functions to handle custom logic securely and efficiently.
Keep everything in one platform, tightly integrated.

quick comparison and a simple example to help you understand how Supabase Edge Functions work—especially compared to Firebase Cloud Functions.

Comparison: Supabase Edge Functions vs Firebase Functions

Feature	Supabase Edge Functions	Firebase Cloud Functions
Runtime	Deno (TypeScript-native)	Node.js
Deployment Time	Fast (\~seconds)	Slower (\~minutes)
Cold Start	Very Low (Deno edge runtime)	Can be noticeable
Region	Edge (closer to user, low latency)	Usually centralized
Language Support	TypeScript, JavaScript	JavaScript, TypeScript
Tied to Backend (DB, Auth)	Yes – deeply integrated with Supabase	Yes – integrated with Firebase
Hosting Model	Serverless, edge-deployed	Serverless, central

✅ Simple Use Case Example

Scenario:

You want to verify that a user has a valid subscription before letting them access premium content.

1. In Firebase:

You’d write a cloud function like this (Node.js):

exports.checkSubscription = functions.https.onRequest((req, res) => {
  const userId = req.body.userId;
  // Call Stripe or check Firestore
  // Return access status
});

2. In Supabase (Edge Function):

// supabase/functions/check-subscription/index.ts

import { serve } from "https://deno.land/std/http/server.ts";

serve(async (req) => {
  const { userId } = await req.json();

  // Call Stripe API, or query your Supabase DB
  const isActive = true; // pretend check

  return new Response(JSON.stringify({
    access: isActive ? "granted" : "denied"
  }), {
    headers: { "Content-Type": "application/json" },
  });
});

➕ Bonus:

You can secure this function by requiring Supabase Auth tokens and decoding them right inside the function.

How to Deploy (CLI):

supabase functions deploy check-subscription

Then call it from your frontend:

const res = await fetch("/functions/v1/check-subscription", {
  method: "POST",
  headers: { "Authorization": `Bearer ${userToken}` },
  body: JSON.stringify({ userId }),
});

What Is Vibe Coding? The Future of Developer Experience

Sat, 26 Jul 2025 07:57:03 +0000

Published by Code Inception

In the ever-evolving world of software development, a new term is making waves — Vibe Coding. But what exactly is it? Is it just another buzzword, or a true shift in the way we write code?

Let’s dive deep into this fresh concept and explore how it's reshaping the developer ecosystem.

What is Vibe Coding?
Vibe Coding refers to a developer-centric approach that emphasizes aesthetic pleasure, flow state, and emotional connection while coding. It's not about the syntax or framework — it’s about how you feel when you code.

Think of it like coding with a vibe — headphones on, lo-fi beats in the background, a clean VS Code theme, auto-saving magic, and smooth GitHub Copilot suggestions. You’re in the zone, flowing effortlessly, loving every keystroke. That’s vibe coding.

Key Characteristics of Vibe Coding
Here are the pillars that define vibe coding:

Immersive Flow
Developers often enter a “flow state” where focus peaks. Vibe coding encourages a distraction-free, immersive environment to boost productivity and creativity.
Aesthetic Developer Setup
From custom IDE themes to minimalistic UI and even RGB lighting — a pleasing dev setup enhances the overall experience. This is not vanity; it’s motivation.
Assistive Tech & AI Tools
AI assistants like GitHub Copilot, Tabnine, or even ChatGPT supercharge your coding experience. They reduce repetitive work and let you focus on the logic and art of coding.
Personalized Coding Rituals
Whether it’s sipping coffee, vibing to ambient music, or late-night coding under a dim light — vibe coders often have rituals that set the mood.
Community & Aesthetic Sharing
Platforms like Dev.to, Reddit (r/ProgrammerHumor), and X (Twitter) now showcase “vibe setups,” coding desks, or coding playlists — making coding more cultural and expressive.

Why Does Vibe Coding Matter?
Because happy developers write better code.

Improved mental health & reduced burnout

Enhanced focus and creativity

Encourages experimentation and learning

Boosts developer retention in teams

Makes coding fun again

Tools That Support Vibe Coding
If you want to get started with vibe coding, here are some tools that help:

VS Code Themes – One Dark Pro, Tokyo Night, Night Owl

Terminal Customizers – Oh My Zsh, Fig, Warp

Music Platforms – Lofi Girl, Spotify Coding Playlists

Coding Companions – GitHub Copilot, ChatGPT, Codeium

Productivity Boosters – Notion, Pomofocus, Raycast

Is Vibe Coding for Professionals Too?
Absolutely. Vibe coding isn’t just for hobby coders or YouTubers. It's being adopted in startups, remote teams, and even large tech companies. It helps professional developers stay mentally sharp and avoid burnout in high-pressure environments.

“A good vibe leads to clean code.” – A modern developer’s mantra.

Final Thoughts
Vibe Coding is more than just a trend — it’s a cultural shift.
It redefines how developers interact with code, tools, and even themselves. It blends productivity with personality. Passion with precision.

So if you’ve ever sat down at your desk, music playing, editor glowing, and lost yourself in hours of joyous coding — you’ve already experienced vibe coding.

Why not make it your daily habit?

About Code Inception
At Code Inception, we simplify tech for everyone. From developers to digital dreamers, follow us for modern tech tips, tutorials, and fresh coding culture.

Vibe Coding - Conversational Software Development - Part 3 Prompt Discipline

Mon, 21 Jul 2025 19:18:31 +0000

Inroduction

It is speculated that vibe coding could fundamentally change how we build software. Instead of writing lines of code, we will describe our goals in plain English and working software will be generated in response.

In my last post, I experimented with a few Vibe Coding tools and shared my hands-on experience. If you have been following closely, you might have noticed something subtle but important that I am using natural language as an interface. The words I choose shape how AI interprets and builds software. And behind that process lies a critical yet often overlooked layer of the system prompt.

So, What Exactly is a Prompt?

Think of Vibe Coding as a chat-driven engineering environment. Every message you send, or the prompt is not just casual conversation. It is more like writing an operating manual for your AI assistant.
A prompt sets the ground rules. It can define your preferred tech stack, coding style, naming conventions, or whether the AI should ask for clarification before making assumptions. In other words, it’s your interface for aligning the AI with your intent.

System prompt

Why Prompts Matter

From my experience, if the prompt is not clear or consistent, things can quickly go off track. Here are just a few issues I ran into when prompts were vague:

The AI picked the wrong programming language.
It introduced unfamiliar and sometimes unnecessary libraries.
It ignored earlier context and gave contradictory results.

Even with advanced tools like ChatGPT, Claude, or Cursor, vagueness in instructions can lead to unpredictable behaviour. It is not about the quality of the model rather it is about the clarity of the direction we give it.

Configure System Prompts

A benefit of using most of the modern AI platforms is that they allow users to define system level prompts. You can define the prompts either globally (across entire workspace) or local (for every project). This helps maintain consistency and avoid repeating the context over and over.

I now make it a habit to start every coding session by explicitly setting the system prompt. It is like configuring your dev environment but in a conversational format.

Designing an Effective Prompt

I am still learning as I go, but I want to share a sample prompt that has worked well for me. The idea is to set clear constraints right from the start. It gives the AI less room for misinterpretation and reduces friction during the session.
Here is a sample system prompt I often use:

>Consider yourself a frontend developer.

All UI components should use React and Tailwind CSS.

Use JavaScript only and avoid any external libraries unless specified.

Ask for clarification if any requirement is unclear.

Focus on clean and modular code.

This prompt does a few important things:

It defines the role of the assistant (a frontend developer).
It sets technology boundaries—no Python, TypeScript, or surprise libraries.
It encourages the AI to ask questions if something is ambiguous.

You can easily extend this prompt to add more context depending on your project needs. For example:

All UI components must be accessible.
Ensure mobile responsiveness.
The backend is built on Java-based APIs.

This initial alignment streamlines development by cutting down on time consumption and limiting AI interactions. You can direct AI to focus according to your development approach and technology choices.

Another observation is that AI assistants demonstrate higher effectiveness when working with commonly used frameworks and tools such as React, Tailwind, and Node. These models have seen far more examples of those technologies, which means you’ll get more reliable and relevant responses.

New Developers: Don't Overthink It

If you have been following along, the discussion so far might make it feel like you need to master a dozen concepts before you even begin with Vibe Coding. But that is not true.
If you are just getting started, my advice is to set a few clear boundaries and get going. Let us take an example to create an interactive dashboard. Here is an example of a prompt that works well to start with:

I am a new developer. I want to build an interactive data dashboard.
Can you suggest a tech stack that is easy to maintain and well-supported?

Most AI assistants like ChatGPT, Claude, and Gemini will then help you through your upcoming steps. The assistants will pose clarifying questions about your requirements which allows them to develop both your tech stack and system prompt.

Tools That Help You Craft Better Prompts

As I continue experimenting, I have come to realize how important the right prompt is. And the good news? You don't have to guess. Tools like:

can help you test, iterate, and refine your prompts in real time. Below is an example of how I refined one of mine using Google Gemini.

I started with this base prompt to explore London Air Quality Data.

>I want to build an interactive dashboard for exploring data located at London Air Quality Data (Excel).

Please ask me questions to better understand the requirements.

Also then help me write a system prompt that guides you to use React, Tailwind, and D3 for visualization.

If London Air Quality Data is not available at above link, I have committed a copy of it, as CSV, at the time writing this post.
{: .prompt-info }

Gemini asked a few smart follow-up questions about:

what kind of visualizations I had in mind,
the type of interactivity I expected,
the layout preferences, and
how I planned to handle the data source.

To narrow the scope, I directed the focus to only one sheet:

>Only evaluate the ‘Monthly Averages’ sheet. Assume everything else

Based on that, Gemini helped me generate a refined system prompt that I could use to generate my dashboard. Below is the output prompt

### System Prompt:

You are an expert web development assistant tasked with building an interactive data exploration dashboard. 
Your goal is to generate a detailed plan, including component structure and initial code snippets, for a React application that visualizes air quality monthly averages.

__Project Objective__
Create an interactive dashboard to explore monthly average air quality data for London, sourced from a specific Excel file.

### Core Technologies:
- Frontend Framework: React
- Styling Framework: Tailwind CSS
- Visualization Library: D3.js

### Data Source:
- __URL__: https://data.london.gov.uk/download/290a22f1-5eef-4801-8286-3f288b49093a/acce7f88-70f0-4fd0-9160-f02a9d96b2c3/air-quality-london.xlsx
- Specific Sheet to Use: "monthly averages"

### Data Interpretation & Preparation:
1. Download and parse the Excel file from the provided URL.
2. Focus exclusively on the data within the "monthly averages" sheet.
3. Identify key columns for visualization:
  - Date (or equivalent column representing the month/year for aggregation)
  - Site Name (or equivalent for location/monitoring station)
  - Pollutant (or equivalent for the type of pollutant, e.g., NO2, PM2.5)
  - Value (or equivalent for the monthly average concentration)
4. Data cleaning and transformation should include:
  - Converting date strings/numbers to valid Date objects.
  - Handling potential missing or invalid data points gracefully (e.g., excluding them from calculations or using interpolation if appropriate for visualization context, but primarily focusing on showing available data).

### Dashboard Functionality & Interactivity:
1. Data Loading: Efficiently load and parse the "monthly averages" data from the Excel file upon component mount. Use an appropriate library like xlsx (SheetJS) for Excel parsing.
2. Filters/Controls:
  - Pollutant Type Filter: Allow users to select one or more pollutant types (e.g., a multi-select dropdown or checkboxes).
  - Monitoring Station Filter: Allow users to select one or more specific monitoring stations/sites.
  - Year Filter: Provide a way to filter data by year (e.g., a dropdown for available years or a range slider if multiple years are selected).
3. Visualizations (D3.js):
  - Time Series Line Chart: The primary visualization should be a line chart showing the monthly average trend over time for selected pollutants and stations.
    -Each line should represent a combination of pollutant and station (or allow choosing a single pollutant to compare multiple stations, or vice versa).
    - Axes should be clearly labeled (e.g., "Date" on X-axis, "Concentration" on Y-axis).
  - Interactive Tooltips: On hover, display detailed information for specific data points (e.g., date, pollutant, station, exact monthly average value).
4. User Interface (React & Tailwind CSS):
  - Clean, responsive, and intuitive dashboard layout.
  - Filter controls should be easily accessible (e.g., in a sidebar or header).
  - The main visualization area should be prominent.
  - Use Tailwind CSS for all styling, ensuring a modern and clean aesthetic.

### Output Requirements:
1. A high-level React component structure (e.g., App.js, Dashboard.js, Chart.js, FilterControls.js).
2. Pseudo-code or a conceptual outline for data fetching and initial parsing of the Excel sheet.
3. An example of how a D3 line chart component might receive data and render, focusing on the integration with React and general D3 patterns.
4. Considerations for managing application state (e.g., selected filters, loaded data).

Final Thoughts

System prompts require continuous refinement as they need to match the evolving needs of your project just like we rewrite code to enhance its clarity and maintainability. Your prompts should evolve to match your project's development to reflect:

new tools or stack changes,
updated coding patterns or style guides,
and shifts in architecture or design decisions.

A good prompt is more than basic instructions to your assistant. You can consider it as a design contract between you and your AI assistant. In my next and final post I will continue to discuss how to further fine tune the prompts.

My suggestion for now is not to stress too much about getting it perfect the first time. Start simple, iterate, and treat your prompt like part of the engineering process where your intent meets implementation.

Jules AI - The (Currently) Free Coding Assistant That Can't Follow Directions But Gets Shit Done

Tue, 15 Jul 2025 17:40:55 +0000

Jules is currently free, so I figured it was worth a try. Of course, I had to find out what I could break.

Each user gets these default limits:

5 concurrent tasks
60 total tasks per day
5 codecasts per day (still not sure what this means)

Sixty tasks a day for free? That’s really generous and it meant I didn’t have to worry about reading documentation or instructions the first time.

I Jumped in Feet First

My Obsidian plugin worked well enough for me to use it, but there were issues. Issues that I’d been ignoring because the damn thing worked and I had other shit to do. But I finally added issues to my GitHub repo.

Four issues. Nothing too crazy. Should be straightforward for an AI that can supposedly code.

I gave Jules access to the repo and told it: “I want you to work on the issues in this repository and create a feature branch for each fix. Start with the first one.”

Simple enough, right?

Jules Decides to Ignore My Instructions

Jules fetched the repo, cloned it into a VM, and read the README file. But then it discovered the “Future Enhancements” section I’d added to the README and decided that’s what it wanted to work on instead.

It completely ignored my instruction to work on the issues, the same issues that are listed right above the “Future Enhancements” section, and decided it would work on the “Interactive book selection dialog” instead.

Jules then asked me to approve the plan, but I didn’t see any way to reject it. It was going to auto-approve in about a minute anyway. I thought maybe clicking “Approve” would launch a modal where I could say “no, you illiterate AI, work on the issues I told you to work on.”

It did not.

So it started working on the wrong thing. I messaged “stop” and it replied: “I have stopped the current task. Is there something specific you would like me to do instead, or a different issue you’d like me to focus on from the README?”

It paused for a few seconds and then continued doing exactly what it was doing before.

Currently, as far as I can tell, the only way to reject a plan is to let it start, pause it manually, and then delete the entire task. User experience design at its finest.

Jules finished the feature and gave me the option to click a button to create a feature branch. So now I had a new feature to test before I could fix the actual issues I wanted fixed.

Testing the Feature that Jules Built While Ignoring My Prompt

So I pulled the branch down to the Obsidian vault I use for testing, the one with all the plugins I’m developing loaded up. There was one error in the code, in unit tests I never asked Jules to add:

tests/main.test.ts:160:35 - error TS2554: Expected 0 arguments, but got 1.
sortAnnotationsByCFI: jest.fn((ann: Annotation[]) => ann), // Simple pass-through

I just deleted the broken test.

It took me a while to figure out that the selection modal didn’t launch via the sidebar button like I expected. I had to hit Command+P and find the command to launch it. But you know what? It actually worked.

Since the feature worked, I merged the change and created a new release. Then I did some reading to figure out how to prevent Jules from going off on another tangent.

Back to Fixing Bugs (This Time With Feeling)

I thought maybe I should be more descriptive, but there wasn’t much to be descriptive about. There are issues. I added them to the repo. They’re also in the README that I know Jules can access. Most of the example prompts are very short, shorter than what I’d already tried.

So I tried again: “This github repo has 4 issues listed here: https://github.com/eristoddle/apple-books-annotation-import/issues. Give me a plan for fixing the first issue. If you have no access to these, let me know. Do not do anything else.”

This time it worked.

Both the accidental feature and the bug fix took very little time. I was actually surprised by the speed. But Jules created broken unit tests again. I figured maybe it was because I didn’t have my npm and node versions in the package.json, so I added those and deleted them again.

It actually fixed the bug and at least doubled the number of book covers I was getting.

The Great Color Mapping Mystery

The second issue was about finding annotation colors.

Me: “Fix this feature in the repo: https://github.com/eristoddle/apple-books-annotation-import/issues/5. Do not do anything else.”

I think “Do not do anything else” will be part of my prompt from now on.

Jules said: “The code changes have been reviewed for syntactical correctness and logical soundness. Direct testing with an Apple Books database is not possible, so final validation will be up to the user.”

Translation: “I changed some code and it compiles. Good luck!”

After testing, I told Jules: “Now it seems like there are no annotation color indicators at all in the md files. Before they were all just purple. Now they are just not there at all.”

The second attempt produced different colors, but they didn’t match the highlight colors in the Books app.

I mapped the colors Jules gave me to the actual colors and told it about the differences: “The color images are back and there are a variety of them, but they do not match the colors in the Books app. Here is how they differ (Books app color → markdown color): underline → both yellow and underline, purple → no icon at all, pink → red, yellow → purple, blue → blue, green → green.”

I even included the log showing the distinct annotation style values from my test database. So this bug took three interactions, but Jules finally got the color mapping right.

Taking It to the Big Leagues

My main Apple Books account has 4000 books and over 60 books with highlights. When I first worked on this plugin, the database structure was different, so I wanted to make sure everything worked in the wild before calling it done.

The plugin handled the larger database just fine. All the covers loaded correctly, and the color annotations matched what I saw in the Books app.

Everything I Fixed In This Change

It took about two hours total, not counting the issue Jules couldn’t fix. I let it code while I took notes for this article, worked on Obsidian cleanup, and checked out Reddit for a while.

Here’s what got implemented:

✅ New interactive ebook selection dialog: By accident when I was asking Jules to fix issues, but I’m counting it as a win.

✅ Fixed finding ebook covers: This was the original first issue. Jules doubled the number of covers the plugin could find.

✅ Fixed annotation color icons: Took three tries and some detailed feedback, but now the colors match what’s in the Books app.

✅ Fixed missing annotation dates: This needed a second attempt. I had to tell Jules: “I have include dates set to true and include citations set to false. There are no dates in the markdown files though.” But it got it right the second time.

❌ Did not fix gibberish in epub chapter names: This one turned into a nightmare. The TypeScript build error migrated from the tests that never worked. I tried to get Jules to fix it once and it failed. The second time it was thinking forever, so I tried Copilot in VS Code, and that fixed the build.

But then there was a runtime error I’d run into before when Claude Code tried to use a Node.js ebook parsing package. Something about not being able to access the file system in Electron. I went round and round with Jules on this one and finally gave up.

One thing I realized is that I could tell Jules to build the app to test the build and fix issues, but I had to make it a command. When I asked “Did you build the app to test it?” it said that wasn’t possible. But when I just told it to build the project, it did it.

So I let it churn through fixing the build errors for 30 minutes. When I tested the result, the chapters still weren’t fixed. But I didn’t expect this one to be easy without doing some research first.

I used 5 of my available 60 free tasks for the day.

Jules: Fast, Confused, but Generally Useful

Jules is fast. That surprised me. At least until there’s back and forth on changes, then the conversation slows down.

It was done with the next fix before I finished testing the previous one. I added one feature I didn’t plan on and fixed four issues in a little over an hour.

But Jules went off on a weird tangent when I gave it what I thought were specific instructions. There seems to be no real interaction other than the first message and accepting the plan. I was worried about fixing issues in a branch it created if something didn’t work.

Using a task like it was a chat and trying to fix more than one issue per task got confusing. Then I figured out I needed a different workflow:

1 chat per branch, but can do multiple related things
1 chat can be as big as 1 feature
Code review each branch
If there are issues, go back to the chat and have Jules fix them
If there are build errors, tell Jules specifically to build the app again, test, and fix any errors.
Pull and test again

I was used to my Claude Code process where everything happened in the branch I was on locally. The “Publish Branch” button in Jules seemed scary at first, but the second time I used it, it just pushed modifications to the existing branch. I was expecting merge conflicts or some other drama.

Most things I asked Jules to do worked well, except for the chapter names issue. I also didn’t ask it to create unit tests, but it kept creating broken ones anyway. It each branch it created, I ran them once and if they failed, I deleted them. They mainly failed because of TypeScript type issues.

The Future of Lazy Coding

Sixty tasks a day for free is generous. I’m planning to move everything I have to GitHub that isn’t already there and create issues for any feature ideas or bugs I encounter.

I could envision a process where:

A user puts in a support request
An issue gets created on the repo
I tell Jules to fix it
Jules fixes it, creates a custom build, and the user tests it (don’t know about this, but I can dream)
If the fix works, I merge it and create a new release

I’m not sure exactly how this process would work in practice, but the potential is there.

Verdict: Worth the Price of Free

Jules isn’t perfect. It ignored my initial instructions, created broken unit tests, and couldn’t fix the most complex issue I threw at it. But it’s fast, it’s free for now, and it actually solved most of the problems I needed solved.

In two hours, I got a new feature and fixed three out of four issues that had been sitting in my backlog. The fourth issue would have taken me some research into ePub structure even doing it manually.

I’m definitely planning to shift more of my “vibe coding” projects to Jules. At 60 free tasks per day, I can afford to let it work on the boring stuff while I focus on the interesting problems. In fact, to use 60 tasks a day, I might have to try running concurrent tasks and I can do 5 of those.

And if it goes off on another tangent and builds something I didn’t ask for? Well, sometimes the best features are the ones you never knew you needed.

Human Insight in an AI-Driven Job Market

Thu, 10 Jul 2025 07:59:37 +0000

Yesterday I had one of the shortest technical interviews of my career just 10 minutes. But in those few minutes, I encountered a senior engineer whose depth of knowledge left a lasting impression.

I didn't make it past the round, but I walked away with something more valuable: perspective.

This kind of fast-track interviewing is increasingly common, especially in mass hiring pipelines. Unfortunately, it often leads to a mismatch between expectations, company culture, and retention. Even the interviewer admitted most candidates had zero clue about the company they applied to.

In a world where AI is optimizing workflows and job boards are flooded with auto-submitted resumes, I believe the human touch still matters. Research, intent, and preparation go a long way and they reflect more than just technical readiness.

Rejections can sting, but they also reveal how systems human and AI-driven could serve us better.

TechInterview #AIInHiring #CareerGrowth #SoftwareEngineering #InterviewInsights #MassHiring #DevCommunity #JobSearchJourney #LeadershipMindset #ReflectionPost

Coder Legion - Recent posts tagged vibe-coding

Hacking a website is now easier than pouring a cup of coffee — here's how to stay safe

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

What if the agent never opened the file?

Files are a human abstraction

Content becomes the address

What if the target is ambiguous?

But sometimes the agent really does need context

The token economics are surprisingly large

This becomes more important as agents become more autonomous

Lines, not files

Everyone Can Build Software Now. Who’s Stopping the Agents?

Vibe Coding Was Supposed to Kill Software Engineering. Instead, It Exposed What Engineering Actual

What if both sides were looking at different parts of the same transition?

The Original Sin of Vibe Coding

I Found Myself Doing It Too

The Code Gets Cheaper. The Context Doesn't.

“But My Tests Are Green”

Then the Productivity Research Got Weird

The Best AI Feature Might Be False Confidence

And Security Doesn't Care About Your Vibes

My Own Projects Made This More Obvious

Here's Where I Think the Vibe Coding Debate Goes Wrong

The New Engineer Might Write Less Code and Understand More

The Comment Sections Are Actually Getting More Interesting

But There's a Trap

The Most Valuable Programmer Might Become the Person Who Deletes the Most AI Code

So Was Vibe Coding Right?

Maybe This Is What Software Engineering Has Been Becoming All Along

The Weird Future

One Last Thought

Sources & Further Reading

Why we only build 60-point products

Lesson 1: The first lesson of AI products is being stingy

Lesson 2: Laziness is the first productive force

Lesson 3: The money you make fastest may be the money you lose fastest

The takeaway

Vibe Coding Won't Kill Developers. It'll Kill the Middle.

The comfortable half of the argument

"So the middle just learns to think better?"

The honest limit of the analogy

Can a Non-Coder Become a Coder Just With AI?

The infrastructure reality check

The mental model problem

Necessary, not sufficient

The decision in front of a technical leader

The real question

A Clean Score Is Not a Complete Scan: What AI-SLOP Detector v3.8.9 Made Visible

What we actually improved since v3.8.1

False-positive control became an engineering feature

v3.8.9 makes the scan boundary visible

-include-tests now has a narrower meaning

Capability absence is now evidence

Discovery is checked before acceleration is trusted

Strictness without pretending certainty

Release verification scope

Reproduce the v3.8.9 result contract

What v3.8.9 improves — and what it does not claim

What would change our mind?

One development change remains outside v3.8.9

What changed most

Two Lessons from Building AI Resume Tools and Choosing Platforms

Don’t Automate the Fun

The Hidden Cost of AI Vibe Coding

💡 What is Vibe Coding?

🚀 Why Everyone Loves It

⚠️ The Hidden Costs

1. You Stop Reading Your Own Code

2. Debugging Becomes Harder

3. Security Risks

4. Technical Debt Grows Faster

5. Learning Slows Down

🧠 AI Should Be Your Pair Programmer

🎯 The Real Skill

💡 Final Thought

AI #VibeCoding #SoftwareEngineering #Programming #Developers #LLM #Coding #ArtificialIntelligence #Tech #DeveloperLife

AI Didn’t Take Your Job – It Revealed It

The Vibe Coding Revolution: Building Your First AI Application with Google AI Studio and Antigravity

What Exactly is Vibe Coding?

`-include-tests` now has a narrower meaning