Tag Archives: engineering

So I Tried Vibe Coding

Vibe coding is real…and you can do it yourself for free. Since I’m on the Google platform, I used Google Gemini to guide me through the steps.

Specification

I started informally:

Online analysis of the chief biometric news from the last seven days, sorted into finger, face, iris, voice, DNA, and other.

Google then formalized a Product Requirements Prompt for Build Mode for Gemini AI Studio (which I had never used before). It made all the UI choices, which I didn’t change (although I haven’t used green on black since the DOS days).

PRODUCT REQUIREMENTS PROMPT (PRP): “BIOMETRIC PULSE 2026”

1. VISION & VIBE

You are building “Biometric Pulse 2026,” a high-frequency, automated data dashboard and visualization tool.

The Vibe: Minimalist, data-dense, dark mode (matrix-green and stark white accents), 1980s retro-futurist ‘terminal’ aesthetic. High information density with zero clutter. The app must feel intelligent, real-time, and analytical.

2. FUNCTIONAL SPECIFICATIONS

The application is a full-stack automated news and regulation analyzer. It must perform the following tasks without user input:

Phase 1: Data Ingestion (Automation)

  1. Source Strategy: Use a hybrid approach:
    • Google Search API (Real-time): Schedule a request every 4 hours for the query "biometrics industry news" OR "facial recognition technology" OR "iris scanning update" OR "voice biometrics market" OR "DNA border control policy" OR "biometric regulation". (Grounding is required).
    • Web Scraper (Targeted): Target specific domain feeds for deeper insights (e.g., BiometricUpdate.com, SecurityInfoWatch, specialized legal/regulatory feeds). If you cannot build the scraper, mock this data with realistic data from the last 7 days.
  2. Date Filtering: Automatically filter all results to only include data from the last 7 calendar days (using the current date dynamically).

Phase 2: AI Classification & Analysis

  1. Categorization: Use Gemini 3 Flash to analyze the title/snippet of every news item and classify it into one or more of these 6 buckets:
    • finger
    • face
    • iris
    • voice
    • dna
    • other (Regulation, Business Mergers, Multi-modal)
  2. Contextual Tagging: Assign secondary sentiment/type tags (e.g., [Surveillance], [Privacy Win], [Market Growth], [New Tech]).

3. UI/UX REQUIREMENTS (THE DASHBOARD)

The main view is a single-page, real-time updated dashboard.

Component A: The Pulse Feed (Primary View)

  • A vertically scrolling list of news items.
  • Items must be chronologically sorted (newest first).
  • Card Design: Every card must have:
    1. A clear category icon/tag (e.g., [ 👤 FACE ] in bright green).
    2. An automated, one-sentence summary (using Gemini).
    3. The primary source link, relative date (“2 days ago”).
    4. Sentiment analysis tags.

Component B: Filter Terminal (Left Sidebar)

  • A stack of minimalist buttons for the 6 primary categories.
  • Show the live “count” of articles found in the last week next to each (e.g., [ 👤 FACE (14) ], [ 🧬 DNA (3) ]).
  • Clicking a category filters the Pulse Feed instantly.

Component C: “The Weakly Pulse” Chart (Right Sidebar)

  • A stacked bar chart visualization.
  • X-Axis: The 6 modalities (Face, Finger, etc.).
  • Y-Axis: Number of news events reported this week.
  • Color Code: The bars should show sentiment (e.g., red for surveillance/privacy concern; green for innovation/market growth).

4. TECHNICAL ARCHITECTURE & STACK

  • Model: Gemini 3 Flash (required for continuous analysis and low latency).
  • Integration: Google AI Studio Build Mode.
  • Runtime: Node.js (Vite server for the frontend).
  • Package Needs: react-query (or simple useEffect for data fetching), chart.js (for the weekly pulse chart), and a minimalist CSS framework or Tailwind (but customized to the dark terminal look).
  • Deployment: Pre-configure for One-Click deployment to Google Cloud Run.

Use

So there it is. I went into Google AI Studio and used Build to build the thing, and without publishing it, I ended up with something that looked like this.

Biometric Pulse 2026, as of the afternoon of March 2, 2026.

It certainly has the retro user interface…but if you look carefully at the data, there isn’t any. I don’t know if I have to wait four hours for the data to auto-refresh, or if I actually have to publish it to have it generate data. Or buy tokens or something.

But if I can get this to actually work, I’ll have proven that you can easily specify simple tasks using modern tools.

But as I noted in my earlier post, I can’t maintain the code.

Yeah, I wrote this…sorta.

If I play with this more I’ll provide an update.

But you can save yourself the heartache and just ask someone like Silicon Tech Solutions to code your app. They know what they’re doing.

Is Vibe Coding Real?

It’s as real as…well, AI-powered content marketing.

SaaStr is a champion of vibe coding, with demonstrated results.

“We’ve built 12+ AI-powered apps on SaaStr.ai…”

These aren’t prototypes, but production apps used 800,000 times.

But before you apply your domain knowledge and create a vibe coded app, recognize this teeny tiny caveat.

“But here’s what almost nobody in the “I built a SaaS in 4 hours” content wave is telling you:

“I maintain these apps every single day. Every. Single. Day.”

Which means that you have to know how to…well, code. To evolve the code base without breaking other parts of it.

And if you don’t have the skills to MAINTAIN a code base, perhaps you should outsource your software development to humans who CAN maintain it. And who can apply technological rigor to every iteration of the product.

Such as Silicon Tech Solutions. For further information on the services they offer, check Bredemarket’s Silicon Tech Solutions page.

Go Forward. Move Ahead.

(Wildebeest bridge picture via Imagen 3)

A few of you know the particulars of this story about avoiding long-term risk for short-term gains. But the particulars aren’t critically important to most readers.

The business risk of new markets

One time a company wanted to enter a new market. This new market would completely change the way the company did business, both from a technological perspective and from a business perspective.

While the technological challenges were daunting, as usual the business challenges were even more so.

The biggest risk to the company was that the new market operated on a different revenue model, one in which revenue was deferred.

  • In the company’s current market, revenue started at contract signature.
  • But in the new market, the company would have to wait over a year and a half after the contract was signed before it received a dime of revenue.

In a publicly traded company, or even a privately held one, the powers that be are reluctant to undertake an initiative where they won’t get any revenue for 18 months.

“The quarter ends in less than 8 weeks. We want revenue NOW!”

So the company hemmed and hawed about entering the new market, scared of the financial risk. Finally it told its prospect that they’d enter the new market…if the prospect would make an immediate down payment. The prospect was not pleased and went with the company’s competitor instead. And the competitor continued to dominate this market.

For a time.

A few years later, the original company decided to accept the financial risk and, in the words of Devo, “go forward” and “move ahead.” And luckily for the company, it wasn’t too late. The company successfully entered the new market and became a dominant force.

Quarterly gains via risk aversion

We see this today, where a number of companies are struggling to survive. They do the prudent thing, letting go of the employees who don’t provide immediate revenue and concentrating on those who do. The engineers who can code something NOW! The salespeople who can get contract signatures NOW!

This isn’t necessarily the wrong thing to do. If your firm is about to close its doors, you have to do whatever you can to keep the business operating.

But what after that?

Continue to act in a reactive way, chasing the next short term deal?

Good luck.

Should engineers rule the world?

TL;DR – No, but.

But for the rest of you who want to consider the question for a couple of minutes…

Life is messy. It’s easy to look around and find examples of ways in which people do things incorrectly. “If only people did things rationally,” you might think to yourself, “these problems would be avoided.” So some desire rational solutions, such as those that could be provided if engineers ruled the world.

Engineers conferring on prototype design, 1954. By Bundesarchiv, Bild 183-23805-1665 / CC-BY-SA 3.0, CC BY-SA 3.0 de, https://commons.wikimedia.org/w/index.php?curid=5349654

In 2016, Global Construction Review asked the question “Should engineers rule the world?” But before I look at the possible answers to that question, let me share a couple of anecdotal stories.

Years and years ago, I worked for company that prided itself on being run by engineers, and having an engineering mindset. For this company, that meant that it exerted great effort to design technically superior solutions. Since I am not an engineer, I was therefore able to observe from the sidelines as the company designed and (after some time) released a product that was a technical marvel. There was only one problem: the product was so expensive that no one would buy it.

That same company had designed another technically superior product, but this one was priced reasonably enough that people throughout the world would buy it…except in the United States. There were established competitors in the United States, and it would take a great effort to displace them. From my vantage point in the US, I asked the product people an apparently simple question: why should US customers choose our company’s product rather than the competitors’ products? Apparently my question “did not compute” with the product people, because I never got an answer to my question. I guess they expected the US customers to be dazzled by our product’s obvious superiority or something.

Now that I’ve gotten those two anecdotal stories out of the way, let’s return to Global Construction Review’s question: “Should engineers rule the world?” The article begins by citing an example in which application of engineering principles at the outset could have prevented a catastrophe later on.

Take the Syrian civil war, for instance. In a paper published last year in the Proceedings of the National Academy of Sciences, Colin P. Kelley and co-authors proposed that a record-breaking drought in northeastern Syria between 2007 and 2010 caused the sudden migration of 1.5 million poor farmers into cities, setting the scene for the widespread unrest that erupted into outright revolt in early 2011.

The thinking, of course, is that if the drought had been minimized or averted through the timely application of scientific principles, the migration would not have happened, and the resulting unrest would not have happened.

So the question about engineers ruling the world was posed to several thinkers, beginning with Tim Chapman, described as the leader of an infrastructure group. Chapman began by observing that politicians concentrate too much on the short term, while some others concentrate too much on the long term.

Engineers are able to bridge this gap. A world run by engineers would be more planned, more strategic, more organised.

But Chapman wasn’t willing to hand the engineers the keys to everything. While he wanted them at the table, he noticed one drawback that engineers need to overcome.

But engineers also need to change, too, if they are to sell their answers to a sceptical world. They need to be better story-tellers who bring society along with them, rather than trying to impose solutions.

Some of the other people interviewed in the article echoed the thought that engineers should be at the table, but no one was willing to let them be the sole arbiters of what is best.

Oddly enough, or perhaps not so oddly, there was one word that I was unable to find in the article.

That word was “listen.”

It’s fine for engineers to be able to tell the story of why a solution should be adopted, but it’s also necessary for engineers to be able to listen to the people who may or may not benefit from the solution. Perhaps the proposed solution is too expensive (see my first anecdotal example), or perhaps existing solutions are perfectly fine (see my second anecdotal example). Or perhaps the solution goes against a group’s most important cultural values; while foreigners are often baffled by Americans’ resistance to government dictates, the fact remains that American history has influenced us to resist such dictates.

So while engineers should be heard, they shouldn’t rule the world.

Marketers should rule the world.

Am I right?