DEV Community

Why We Built an Android SMS Gateway API (And the Pivot That Forced Us to Build It)

Raffy — Thu, 25 Jun 2026 01:35:54 +0000

For a long time, I did what every ambitious engineer is told to do. I climbed the corporate ladder. I made it to the height of my career, managed engineering teams, and dealt with the heavy stress that comes with enterprise infrastructure.

But eventually, corporate inertia and office politics catch up with you. After a complex, challenging corporate exit, I found myself at a major crossroads. It was a stressful time that tested my spirit, but it ultimately brought me down to a place of radical humility.

In that space, I realized I wanted to build things with a greater purpose. When everything else felt uncertain, getting back to writing code became my sanctuary. It is where I find my peace. I teamed up with some incredible colleagues, and together, we started building a new suite of software under a shared vision. We wanted to help small businesses get access to enterprise-grade tools without the enterprise price tag.

Our roadmap is to build full SaaS applications for small-and-medium enterprises, especially around autonomous AI customer service. But as we began mapping out the features, we hit a massive roadblock that forced us to build the foundation first.

That foundational project is Relayion.

The Core Problem with Modern Developer SMS

We were looking into how local businesses handle customer communication. Everyone talks about connecting apps to Facebook Messenger or WhatsApp, but for local businesses like a neighborhood medical clinic or an automotive shop, traditional SMS is still the absolute lifeblood. They need it for automated appointment reminders, quick customer inquiries, and sending secure one-time passwords.

The problem is that if a developer wants to build a system that handles autonomous, two-way customer service over SMS, using traditional cloud providers is a trap.

The costs scale instantly because they charge heavy fees for every single outbound and inbound message. On top of that, you face a bureaucratic nightmare of carrier regulations and endless registration forms just to get approved to send a basic automated text.

The ironic part is that businesses are already actively using their physical phones with local SIM cards and unlimited text plans to talk to their clients and run ads. They already own the hardware and pay for the service. We just needed a way to bridge that existing hardware to the web systems that can actually automate, streamline, and scale those processes.

Our Approach to the Architecture

We decided to build an infrastructure that lets any web server, app, or AI agent send and receive texts natively through a physical Android device. We did not want to build an overnight, fly-by-night tool. Our engineering team spent months refining this mechanism to make sure it handles messages with extreme care and reliability.

Our system is engineered for instant responsiveness. The moment your server hits our endpoint, the message routes to the phone safely. We built a robust cloud buffer in front of the hardware. If your phone temporarily loses cellular signal or the network drops out for a minute, our cloud holds onto the messages securely and flushes them to the device the exact millisecond it is stable. You do not get dropped messages or lost data, which is exactly how a reliable engine should work.

On the flip side, when a customer replies to that text, the phone captures the incoming SMS and instantly relays a webhook back to your system or AI model for a seamless, two-way loop.

We wanted to make this incredibly lightweight for developers to deploy. Once our Android application is running on your device, sending a programmatic text from Node.js, Python, or a no-code workflow tool like n8n looks exactly like a standard three-line API curl request.

Building in Public and Moving Forward

Relayion isn't perfect, and as engineers, we know software is an evolving canvas. But our team strives every day to bring it closer to perfection.

This journey has taught me radical humility. I have fully accepted that I am exactly where God wants me to be, and I have surrendered the steering wheel to Him. Continuing down this path, sharing our engineering milestones, and building software that genuinely helps people is where our focus is.

We built Relayion to give indie hackers, small business owners, and developers the kind of affordable, robust infrastructure they usually get priced out of. Whether you are building an AI chatbot, automating a local clinic, or just messing around with a weekend project, we would love for you to try it out.

You can check out our platform and setup guides at relayion.com. Drop a comment below if you have ever tried building an SMS gateway or ran into these carrier pricing walls. Our team would love to swap notes with you.

I Built an AI App in 30 Minutes.

Irvan Gerhana Septiyana — Thu, 25 Jun 2026 01:35:45 +0000

It Started Falling Apart Three Days Later.

Over the past year, AI coding tools have completely changed how I write software.

Cursor.

Claude Code.

GitHub Copilot.

OpenAI Codex.

They've become part of my daily workflow.

I can scaffold APIs in minutes.

Generate React components almost instantly.

Write documentation faster than ever before.

It's honestly impressive.

A few months ago, I decided to see how far I could push it.

I challenged myself to build an AI-powered application as quickly as possible.

Within about thirty minutes, I had something that actually worked.

The UI looked clean.

The API responded correctly.

The demo was convincing.

I was excited.

Three days later...

I found myself rewriting most of it.

Not because the AI generated bad code.

Because I skipped software engineering.

AI Didn't Cause The Problem

It's tempting to blame the tool.

But the tool wasn't the issue.

The code was mostly fine.

The real problem was that I optimized for one metric:

Speed.

I didn't spend enough time thinking about:

data models
business rules
architecture
service boundaries
error handling
long-term maintainability

The application worked.

The system didn't.

There's a huge difference.

Building Features Isn't Building Systems

Modern AI is incredibly good at producing code.

Ask it to build:

authentication
CRUD endpoints
React dashboards
FastAPI routes
SQL queries

and you'll probably get something useful.

But production software isn't simply a collection of features.

It's a collection of decisions.

Questions like:

Where should business logic live?
Which service owns this data?
How do we version our APIs?
What happens when downstream services fail?
Which component becomes the source of truth?

Those aren't code-generation problems.

They're engineering problems.

The Architecture Debt Nobody Talks About

We often talk about technical debt.

Lately I've started thinking about another kind of debt.

Architecture debt.

It happens when software grows faster than understanding.

Every AI-generated feature introduces another assumption.

Another dependency.

Another shortcut.

Another duplicated business rule.

Everything still works...

Until it doesn't.

A Real Example

Recently I worked on a Transaction Intelligence System for enterprise financial automation.

At first glance, the project looked like another NLP pipeline.

Take a bank statement.

Extract entities.

Return JSON.

Simple.

Except it wasn't.

Before I could train a model, I had to design:

a canonical data model
business taxonomies
synthetic datasets
entity relationships
reconciliation rules
evaluation pipelines

Ironically...

The AI model turned out to be one of the easier parts.

The difficult part was understanding the business.

AI Can Generate Code.

It Can't Invent Your Business.

Imagine asking an AI assistant:

"Has invoice MFG-INV-000157 already been paid?"

The model can't answer that question unless someone has already built:

a customer master
an invoice master
contract relationships
payment history
reconciliation logic

The language model doesn't magically know how your business operates.

Someone has to teach the system.

That "someone" is still the engineer.

From Vibe Coding to Engineering

I love how quickly AI lets me prototype ideas.

I wouldn't want to go back.

But I've also changed how I work.

Instead of asking AI:

Build this feature.

I now ask:

Help me design this system.

Instead of generating endpoints first...

I design the architecture.

Instead of creating tables...

I model the business.

Instead of optimizing prompts...

I optimize understanding.

The code becomes much easier afterwards.

The Most Valuable Skill Isn't Coding Anymore

For years we measured engineers by how much code they wrote.

Today AI writes a significant portion of that code.

So what becomes valuable?

Understanding.

Architecture.

Decision making.

Data modeling.

Communication.

Business context.

Those skills cannot simply be autocomplete-generated.

At least not today.

My Biggest Lesson

The biggest lesson wasn't that AI is overhyped.

It wasn't that AI can't code.

It absolutely can.

The lesson was much simpler.

AI accelerates implementation.

It doesn't replace engineering.

And the larger the system becomes...

The more valuable engineering becomes.

Final Thoughts

The future isn't about writing code faster.

We're already doing that.

The future is about designing systems that continue working six months after the demo.

Because shipping software is easy.

Maintaining software is difficult.

AI helps us write code.

Software engineering helps us build products.

And those two things are not the same.

Resources

Over the last several months, I've been documenting how I built a complete Enterprise AI Transaction Intelligence System from scratch.

Instead of focusing on prompts or AI demos, the project covers the engineering foundations behind production-ready AI systems, including:

Canonical Data Architecture
Synthetic Enterprise Dataset Design
Financial Named Entity Recognition (NER)
Entity Resolution
Business Rules & Automated Reconciliation
FastAPI Production API
End-to-End Evaluation & Benchmarking

If you're interested in building AI systems that solve real business problems—not just impressive demos—you can explore the complete implementation here:

👉 Enterprise AI Automation Blueprint
https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint

The bundle includes three in-depth handbooks, production-ready Python source code, synthetic datasets, architecture documentation, and practical examples based on a real enterprise use case.

If you found this article useful, I'd love to connect.

I'm currently publishing a series on Enterprise AI Engineering, AI Automation, Software Architecture, and Production AI Systems here on Dev.to.

Happy building. 🚀

Building a Custom Autonomous Drone Stack - Part 3: The Zero-Velocity Hover

Harsh Pandhe — Thu, 25 Jun 2026 01:33:00 +0000

Surviving GPS-Denied Environments with `VELOCITY_MASK`

If you're flying a micro-UAV indoors using only an optical flow sensor and a downward-facing LiDAR, standard autonomous flight commands will quickly disappoint you.

When you issue a traditional MAV_CMD_NAV_TAKEOFF, ArduPilot expects to have access to global position information. Without GPS, the navigation stack may refuse to move.

To work around this, we bypassed the higher-level navigation controller and injected raw MAVLink commands over serial using set_attitude_target_send(). This allowed the drone to climb using only its onboard sensors.

Getting airborne, however, is only half the battle.

Keeping the drone in the air is where things get interesting.

The "Zero-Throttle Drop" Trap

During our first tethered test flights, we managed to climb to roughly one meter in GUIDED mode.

To command a stable hover, we switched the vehicle into LOITER.

The instant the mode changed, the motors slowed down and the drone dropped.

What happened?

The issue wasn't hardware.

It was a software conflict.

GUIDED mode is completely autonomous and ignores pilot stick inputs.

LOITER, on the other hand, is a hybrid mode.

As soon as the flight controller entered LOITER, it checked the RC transmitter.

Our throttle stick was resting at zero.

ArduPilot interpreted that as a pilot command to descend.

The Pure Autonomy Fix: `VELOCITY_MASK`

Instead of relying on physical joysticks, we stayed entirely inside GUIDED mode and continuously sent a zero-velocity command.

Using set_position_target_local_ned_send(), we can specify a bitmask that tells the Pixhawk exactly which fields matter.

A mask value of 3527 (0b110111000111) means:

Ignore position coordinates
Ignore acceleration
Ignore yaw
Enforce X, Y, and Z velocity

By commanding:

Vx = 0
Vy = 0
Vz = 0

we are effectively telling the flight controller:

Hold perfectly still.

Velocity Hold Loop

VELOCITY_MASK = 3527

# Maintain hover for 10 seconds
for i in range(20):

    master.mav.set_position_target_local_ned_send(
        0,
        master.target_system,
        master.target_component,
        mavutil.mavlink.MAV_FRAME_LOCAL_NED,

        VELOCITY_MASK,

        0, 0, 0,     # Position (ignored)
        0, 0, 0,     # Velocity = 0 m/s
        0, 0, 0,     # Acceleration (ignored)
        0, 0         # Yaw and yaw rate (ignored)
    )

    time.sleep(0.5)

With this loop running, optical flow measurements continuously feed the EKF3.

If the drone drifts due to airflow or frame vibrations, the Pixhawk automatically adjusts motor outputs to force the physical velocity back toward zero.

Why Velocity Commands Work Better Than Position Commands Indoors

Position commands assume absolute position knowledge.

Indoors, position estimates often drift.

Velocity control is far more forgiving.

Instead of saying:

Be exactly at coordinate X=0.52 meters.

we say:

Maintain zero velocity.

This lets the flight controller use optical flow and LiDAR to make tiny corrections without fighting an imperfect global reference frame.

The Panic Button

Never fly without an emergency failsafe.

If your Python script crashes unexpectedly while the vehicle remains armed, the drone will continue executing the last command it received.

That's a bad day.

We wrapped the entire flight sequence inside an emergency interceptor.

Emergency Landing Function

import sys

def emergency_land():

    print("\n[!!!] EMERGENCY: INITIATING LAND")

    mode_id = master.mode_mapping()['LAND']

    master.mav.set_mode_send(
        master.target_system,
        mavutil.mavlink.MAV_MODE_FLAG_CUSTOM_MODE_ENABLED,
        mode_id
    )

    master.mav.command_long_send(
        master.target_system,
        master.target_component,
        mavutil.mavlink.MAV_CMD_NAV_LAND,
        0,
        0, 0, 0, 0, 0, 0, 0
    )

    sys.exit(0)

Wrapping the Flight Loop

try:

    # 1. Arm

    # 2. Takeoff

    # 3. Velocity hold

    pass

except KeyboardInterrupt:

    emergency_land()

except Exception as e:

    print(f"ERROR: {e}")

    emergency_land()

Now, pressing Ctrl+C immediately overrides the current mission and forces a controlled descent.

The flight controller handles the landing sequence and disarms automatically after touchdown.

Final Thoughts

One of the biggest lessons we learned was this:

Separate high-level logic from low-level reflexes.

Let your companion computer make decisions.

Let the flight controller do what it does best:

Sensor fusion
State estimation
Motor control
Stabilization
Recovery

By respecting this separation, you can build an autonomous stack that remains reliable even in GPS-denied environments.

And that's exactly what robotics is all about.

Not replacing the flight controller.

Working with it.

Augmented Team Quality: The Attrition Problem

Dennis Vorobyov — Thu, 25 Jun 2026 01:26:54 +0000

Everest Group's 2024 Staff Augmentation report found that 48% of augmented teams experience "high attrition" — defined as annual engineer turnover exceeding 25%. For a 5-person augmented team, that means losing 1-2 engineers per year. Each departure triggers the same costs as internal turnover — knowledge loss, ramp-up time, team disruption — but the client has no control over the staffing decisions because the engineers are employed by the vendor.

I run a staff augmentation business. The 48% number is the industry average, not our number. Our average engagement is 3+ years with the same engineers. The difference is the model, not the market.

Why Augmented Teams Churn

Utilization-driven rotation

Large staffing firms optimize for utilization, not client satisfaction. When a higher-paying engagement opens, the vendor moves the engineer from your project to the new one and assigns a replacement. From the vendor's perspective, this is rational — the same engineer generates more revenue on the new project. From your perspective, you just lost 6 months of domain knowledge and got someone who needs 2-3 months to ramp up.

The contractual language usually permits this. "The vendor reserves the right to substitute equivalent resources with reasonable notice." "Reasonable notice" might be 2 weeks. "Equivalent resources" might mean "same title, different person." The equivalency is in resume keywords, not in production experience with your codebase.

Engineer dissatisfaction with body-shop model

Good engineers do not want to be rotated between projects every 6 months. They want to build something, see it grow, and take pride in the result. The body-shop model — where the engineer is a fungible resource assigned wherever revenue is highest — treats engineers as commodities. The best engineers leave the body shop for companies that treat them as people. What remains is the engineers who could not get a better position.

This creates a negative selection spiral: the vendor rotates out the good engineers (either voluntarily or because the engineer quits), replaces them with weaker engineers, and the client's project quality declines. The client complains about quality. The vendor promises to "upgrade the team." The upgrade is another engineer who will be rotated out in 6 months.

No investment in engineer growth

Staffing firms that rotate engineers every 6 months have no incentive to invest in their technical growth. Training costs money. An engineer who gets trained and then leaves for a competitor is a loss. So the firm does not train. The engineers stagnate. They leave for firms that invest in their growth. The attrition cycle continues.

What 48% Attrition Costs the Client

Knowledge transfer on repeat

Each departing engineer takes undocumented context with them. The new engineer spends 2-3 months ramping up. During ramp-up, they operate at 50% productivity and consume senior team members' time through questions and pairing. For a 5-person team losing 1-2 engineers per year, you are permanently in ramp-up mode. At any given time, 20-40% of the team is below full productivity.

The annualized cost: 2 engineers × 3 months ramp-up × 50% productivity loss × $50-100/hour = $48,000-$96,000 in reduced output per year. That is before counting the senior engineer time consumed by onboarding the replacements.

Team cohesion destruction

Software engineering is a team sport. Engineers who have worked together for years develop shared understanding: coding conventions, architectural patterns, debugging instincts, and communication shortcuts. A team with 48% annual turnover never develops this cohesion. It is permanently a group of individuals, not a team.

The performance gap between a cohesive team and a collection of individuals is well-documented. Google's Project Aristotle found that team psychological safety — built through stable relationships — is the #1 predictor of team effectiveness. You cannot build psychological safety when half the team changes every year.

Vendor management overhead

Each rotation triggers: vendor communication about the change, review of the replacement's resume, interview with the replacement, transition planning, knowledge transfer sessions, and 2-3 months of closer supervision until the new engineer is up to speed. For the client's product manager or engineering lead, each rotation consumes 20-40 hours of management time.

At 2 rotations per year on a 5-person team, that is 40-80 hours/year of vendor management overhead driven entirely by attrition. At $80-$150/hour for the client's internal manager, that is $3,200-$12,000/year in management cost — not counting the opportunity cost of what that manager would have done with those hours.

Why Our Attrition Is Different

Our model is not utilization-driven. We do not rotate engineers to higher-paying projects because our engagements are structured as long-term partnerships, not resource placements.

We do not optimize for utilization. When an engineer is assigned to HeyTutor, they work on HeyTutor. For 9 years, in this case. They are not pulled to a new project because a new client offered $10/hour more. Our revenue model is based on stable retainers, not maximizing hourly rate per engineer.

We invest in engineer growth. Our engineers who built Laravel applications 5 years ago now build AI products. The engineers who built Nautical Commerce's Django marketplace now work on healthcare platforms. The technical growth keeps the work interesting. Interesting work retains engineers.

We assign engineers to domains they care about. An engineer who is passionate about FinTech works on FinTech projects. An engineer who loves mobile development builds mobile apps. Matching interest to assignment is not something utilization-optimized firms can do — they assign whoever is available. We assign whoever is right.

We treat engineers as the product, not as the commodity. Our clients stay for 3+ years because the engineers are excellent. If we rotated them, the clients would leave. Our business model depends on retention at both ends: engineer retention and client retention are the same thing.

How to Evaluate Augmentation Partners

Ask about tenure

"What is the average tenure of your engineers on client projects?" If the answer is "6-12 months" or "it varies," that is 48% attrition territory. If the answer is "our average engagement is 3+ years," verify it with references.

Ask about rotation policy

"Under what circumstances would you substitute an engineer on my project?" The right answer: "Only if the engineer leaves the company or you request a change." The wrong answer: "We reserve the right to substitute equivalent resources." That is the utilization-driven rotation clause.

Ask for named engineers before signing

"Who specifically will work on my project?" If the vendor cannot name the engineers before the contract, the team will be assembled from the available bench after signing. You do not know who you are getting. The bait-and-switch risk is high.

Check client retention

Vendors who retain engineers retain clients. Ask: "What percentage of your clients have been with you for 2+ years?" A firm with high engineer attrition also has high client attrition. The two are directly correlated.

Our numbers: HeyTutor (9 years), MyFlyRight (10 years), Greek House (4 years), Snapwire (2.5 years), Ripe (5 years). Those are not cherry-picked. Those are our major engagements. The pattern is the proof.

The Math

A 5-person augmented team at $50/hour with 48% annual attrition:

Direct cost: 5 × $50 × 160 × 12 = $480,000
Attrition cost (knowledge loss, ramp-up, management): ~$96,000-$144,000/year
Effective cost: $576,000-$624,000 (20-30% above invoice)

A 5-person augmented team at $70/hour with <10% annual attrition:

Direct cost: 5 × $70 × 160 × 12 = $672,000
Attrition cost: ~$10,000-$20,000/year (rare single rotations)
Effective cost: $682,000-$692,000

The difference is $58,000-$68,000 — about 10%. But the stable team ships more, breaks less, and requires less management. The total value delivered per dollar is higher with the stable team despite the higher hourly rate.

$50-99/hour with team stability is a better deal than $40/hour with 48% annual churn. The invoice is higher. The outcome is better. The total cost is comparable.

Talk to us →

Last updated April 14, 2024

Older
62% of Security Teams Say 25%+ of Alerts Are False Positives Newer
The True Cost of Outsourcing Is 20% More Than the Quote

Zero-Dependency Favicon Generation with Canvas API — Build Your Own in 50 Lines

swift king — Thu, 25 Jun 2026 01:24:45 +0000

Every React project I've worked on eventually adds a favicon generation dependency. favicons alone pulls in sharp, which pulls in native binaries, which breaks on that one teammate's M1 Mac and eats 15 minutes of your afternoon. I got tired of it and built a zero-dependency favicon generator using nothing but the Canvas API. It ships all six sizes you need for a modern web app in under 50 lines.

What You Actually Need in 2026

The minimum favicon set has grown. Here's what covers every major browser and platform:

File	Size	Purpose
`favicon.ico`	32×32	Legacy browser fallback
`favicon-16.png`	16×16	Browser tab (small screens)
`favicon-32.png`	32×32	Browser tab (standard)
`apple-touch-icon.png`	180×180	iOS Home Screen, Safari
`icon-192.png`	192×192	Android PWA, Chrome install
`icon-512.png`	512×512	PWA splash screen

That's six files. Most generators create 15+ — including manifest.json, browserconfig.xml, and sizes no one uses anymore. You don't need the bloat.

The Canvas API Approach

The trick is that Canvas can render SVG paths (via Path2D) and then export to PNG at any resolution. No DOM, no fonts, no external libraries.

Here's the core:

function generateFaviconSet(svgPathData, color = '#1e293b') {
  const sizes = [
    { name: 'favicon-16.png', w: 16 },
    { name: 'favicon-32.png', w: 32 },
    { name: 'apple-touch-icon.png', w: 180 },
    { name: 'icon-192.png', w: 192 },
    { name: 'icon-512.png', w: 512 },
  ];

  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');

  sizes.forEach(({ name, w }) => {
    canvas.width = w;
    canvas.height = w;
    ctx.clearRect(0, 0, w, w);
    const scale = (w * 0.8) / 100;
    const offset = w * 0.1;
    ctx.save();
    ctx.translate(offset, offset);
    ctx.scale(scale, scale);
    const path = new Path2D(svgPathData);
    ctx.fillStyle = color;
    ctx.fill(path);
    ctx.restore();
    const link = document.createElement('a');
    link.download = name;
    link.href = canvas.toDataURL('image/png');
    link.click();
  });
}

The key insight: Canvas's Path2D constructor accepts the exact same path data string as SVG's d attribute. You can prototype your icon in any SVG editor, copy the d="..." value, and feed it directly into the function above. No parsing, no conversion.

Why Not Use `toBlob()`?

toBlob() would be more memory-efficient than toDataURL(), but it's asynchronous and creates event-handling complexity when generating multiple sizes. For favicon-sized images (max 512×512), toDataURL() keeps the code synchronous and readable.

One Click → ZIP of All Sizes

Wrapping this into a proper tool means adding JSZip for packaging and a file input for custom images. I built exactly that at genfavicon.org — upload any image, get all six favicon sizes in one ZIP, plus the HTML <link> tags pre-generated. The entire thing runs in the browser; nothing gets uploaded to any server.

But if you want to build your own pipeline — maybe you need a custom color palette or want to integrate it into a design system tool — the Canvas approach above is the foundation. No sharp, no imagemagick, no native deps.

The ICO Format: One Quirk

Canvas can export PNG and JPEG, but not ICO. For favicon.ico, you have two clean options:

Skip it. Chrome, Firefox, Edge, and Safari all support PNG favicons via <link rel="icon" type="image/png">. The ICO format is only needed for IE11 and some ancient Android browsers.
Use a tiny encoder. A minimal ICO encoder is about 30 lines — it's just a BMP header + PNG data wrapped in an ICO container.

Personally, I generate a 32×32 PNG and use <link rel="icon" type="image/png" sizes="32x32"> for modern browsers plus a tiny .ico fallback for the stragglers.

The Real Win: Your Build Step Gets Simpler

Every project I've switched from sharp-based favicon generation to an in-browser tool has deleted roughly three dependencies and 20 lines of build config. For Next.js specifically, this means no sharp in node_modules, no native rebuilds on npm install, and no "works on my machine" moments when the designer updates the icon.

If you don't want to write the Canvas code yourself, genfavicon.org does the same thing with a drag-and-drop UI. But the Canvas approach is genuinely simple enough that you can embed it in an internal tool in an afternoon.

Code snippets in this article are MIT-licensed. Use them however you want.

So Tired of Reading to Keep Up

Rick Gonzalez — Thu, 25 Jun 2026 01:21:32 +0000

Frontier models are very good, but we shouldn't hand them the keys to our digital world just yet. Lenzon.ai celebrates the creativity and ingenuity behind modern software by surfacing the remarkable architecture engineers have built over the last few decades. AI would be nowhere without those foundations, and the future of software depends on growing human understanding so we can keep shaping what comes next.

This isn't man against machine. It's man with the machine, and our perspective has to scale alongside the systems we're building. So, to date, it's been read and read and read!

I built Lenzon because my eyes were starting this weird little twitch. I wanted to make it simple to gain a shared view of complex logic, fast. AI agents do the heavy lifting on the analysis, but it's the succinct visual and audio explainers that actually move understanding from one head to another. That's the loop: AI accelerates the read, humans get smarter, humans keep steering.
Lenzon is open source (Apache 2.0) and free for public repos. I'm very interested in what you think about using a technology like this for your PRs, so please share here.

Here are some example pull request explainers that took on average six minutes to create.

Lenzon Whole Repo

VS Code Public Pull Request

Policy Flow PR with findings

Your AI Code Has 6 Secret Hits. Only 3 Ship in the npm Package.

Alexey Spinov — Thu, 25 Jun 2026 01:20:03 +0000

Secrets in a published npm package are a different set from secrets in your repo. A secret scanner reads the whole git tree; npm pack ships only the files allowlist in package.json. leak_probe.py measures both and prints the gap. On the fixture below it found 6 hits and flagged 3 as actually shipping.

TL;DR

A scanner reads your git tree. The packager reads the files allowlist. They are not the same file set.
On the test package: 6 secret hits total, 3 of them ship in the tarball, 3 are git-only (a test/ fake and a root run.log, both outside the files allowlist). Exit 1.
leak_probe.py is ~80 lines of Python: provider regexes + entropy + a packaging filter. No network, no model, no exec, no install.
A hit is a SIGNAL, not a confirmed live secret. Verify ship-status with npm pack --dry-run.
Runs in about 60 seconds, no API key. Code and fixtures are in the post.

The blind spot nobody scans for

Run gitleaks or trufflehog and you get a list of secrets in your working tree. Useful. But that list answers a question about your repo, not about your release. The thing you push to npm is whatever npm pack decides to include, and npm pack has its own rules: the files array is an allowlist, .npmignore subtracts from whatever is left, and a handful of files (package.json, README.md) always ship.

So two failure modes hide in the gap.

One: a secret your scanner flagged loud and red sits in test/fixtures.js, which is not in your files allowlist, so it never ships. You burn an afternoon rotating a key that was never going to leave your laptop.

Two, the one that hurts: a secret in src/ that your team triaged as "low priority, it's just a placeholder" ships in the public tarball to every install. The scanner saw it. The risk triage downranked it. The packager shipped it anyway.

I have not pushed a leaked key to npm myself. But the shape of this is not theoretical. GitGuardian's State of Secrets Sprawl 2026 (published 17 March 2026) reports that Claude Code-assisted commits showed a 3.2% secret-leak rate versus a 1.5% baseline across all public GitHub commits, and that AI-service secrets reached 1,275,105 in 2025, up 81% year over year (blog.gitguardian.com). Their headline number: 28.65 million new hardcoded secrets added to public GitHub in 2025. Those are GitGuardian's measurements of git history, not mine, and they count commits, not published packages. I am citing them for context, not as my result. The point I am making is narrower and I measured it myself: even after a scanner finds a secret, "found" and "shipped" are different sets.

The contrarian part, stated so you can break it

Here is the claim, sharp enough to argue with: running a secret scanner on your repo does not tell you what ships. A secret can be flagged by the scanner and never leave your machine. A secret the scanner downranks can ship to every install.

That is falsifiable, and I want it to be. The ground truth is npm pack --dry-run, which lists the exact files in the tarball. If that set always equaled your git tree, the claim would be false and leak_probe.py would be pointless. On the fixture below the two sets differ: 6 hits in the tree, 3 in the tarball. Run npm pack --dry-run on the same fixture and you will see src/ and package.json listed, test/ and run.log absent. That is the whole argument in one command.

The tool: ~80 lines, four rules

leak_probe.py does four deterministic things and nothing else:

Provider regexes for vendor-published key shapes: AKIA… (AWS), sk-… (OpenAI), sk_live_… (Stripe), ghp_… (GitHub PAT), xox[baprs]-… (Slack).
Generic high-entropy assignment: a name = "long literal" where the literal has Shannon entropy at least 3.5 and is not pure letters. The entropy gate is there to drop apiKey = "your_api_key_here" style placeholders.
The packaging filter (this is the part a plain scanner does not have): for each file, decide whether npm pack ships it, using the files allowlist, .npmignore, and the always-shipped set.
Density: hits per 100 scanned lines, a local number, not a market average.

Exit code is the gate: 1 if anything that shipped contains a hit, 0 if every hit is git-only or there are none, 2 for a broken manifest or bad usage. Drop it in a pre-publish hook and a shipping secret fails the build.

import sys, os, re, math, json, fnmatch
from collections import Counter

PROVIDERS = [
    ("aws_access_key",   re.compile(r"AKIA[0-9A-Z]{16}")),
    ("openai_key",       re.compile(r"sk-[A-Za-z0-9]{20,}")),
    ("stripe_secret",    re.compile(r"sk_live_[0-9A-Za-z]{16,}")),
    ("github_pat",       re.compile(r"ghp_[A-Za-z0-9]{36}")),
    ("slack_token",      re.compile(r"xox[baprs]-[0-9A-Za-z-]{10,}")),
]
ASSIGN = re.compile(r"""(?ix)(secret|token|api[_-]?key|password|access[_-]?key)\s*[:=]\s*['"]([^'"]{12,})['"]""")

def shannon(s):
    n = len(s)
    return -sum((c / n) * math.log2(c / n) for c in Counter(s).values()) if n else 0.0

The packaging filter is the only clever bit, and it is short. The files field is an allowlist: if it exists, a file ships only if it is named there. .npmignore then subtracts. package.json and README.md always ship.

def ships(rel, allow, ignore):
    base = os.path.basename(rel)
    if base in ("package.json", "README.md"):
        return True                      # npm always ships these
    if allow is not None:                # `files` is an allowlist: opt-in only
        top = rel.split(os.sep)[0]
        if not any(rel == g or top == g.rstrip("/*") for g in allow):
            return False
    return not any(fnmatch.fnmatch(rel, g) or fnmatch.fnmatch(base, g) for g in ignore)

The full script is in the draft repo for this post. It is one file, standard library only, Python 3.

Run it: the real output

Three fixtures. A clean package, a leaky one, and a broken manifest. Here is the verbatim run on Python 3.13.5. Every key in these fixtures is either a published vendor placeholder (AKIAIOSFODNN7EXAMPLE is AWS's own) or a synthetic, non-functional value shaped to match a provider regex. None is a live secret.

Clean package: secrets come from process.env, files: ["src"], nothing hardcoded.

$ python3 leak_probe.py fixtures/clean_pkg
scanned_lines=14  secret_hits=0  density_per_100=0.0  WILL_SHIP_in_package=0
[exit 0]

Zero hits, exit 0. That is the falsifiable floor: a clean tree produces a clean result. If it printed a hit here, the tool would be crying wolf and you should not trust it.

Now the leaky package. Three real-shaped keys in src/secrets.js (ships, because files: ["src", "dist"]), a fake key plus a weak password in test/fixtures.js (does not ship, test/ is not in files), and one key echoed into run.log at the package root (does not ship, because a root run.log is outside the files allowlist; the .npmignore rule *.log is a redundant second belt if files is ever removed).

$ python3 leak_probe.py fixtures/leaky_pkg
scanned_lines=23  secret_hits=6  density_per_100=26.087  WILL_SHIP_in_package=3
  SHIPS    aws_access_key  regex         AKIAIOS...  src/secrets.js
  SHIPS    github_pat      regex         ghp_aZ8...  src/secrets.js
  SHIPS    stripe_secret   regex         sk_live...  src/secrets.js
  git-only aws_access_key  regex         AKIAIOS...  run.log
  git-only openai_key      regex         sk-test...  test/fixtures.js
  git-only password        entropy>=3.5  superse...  test/fixtures.js
[exit 1]

Six hits. Three ship. Three git-only. A naive count says "6 secrets, panic." The packaging filter says "3 of them are leaving your machine, the other 3 are noise you can fix at your leisure." That difference is the whole reason the tool exists. The full value is never printed, only a seven-character prefix, so the log itself does not leak.

Broken manifest, so you cannot reason about what ships:

$ python3 leak_probe.py fixtures/bad_pkg
error: package.json is not valid JSON
[exit 2]

Exit 2, message on stderr, nothing on stdout. Fail loud rather than guess the allowlist.

It is deterministic. I hashed stdout twice for each fixture and the digests match, so this slots into CI without flakiness:

# clean_pkg:
c7bf55295dd28f5a2132ea6e1a93b374d920163e359a0ff2b419a672a6065401
c7bf55295dd28f5a2132ea6e1a93b374d920163e359a0ff2b419a672a6065401
# leaky_pkg:
f9590a4de96c8c9c1aa87d0272a61782e2cf0c6afead292a21db2ee56b5c9178
f9590a4de96c8c9c1aa87d0272a61782e2cf0c6afead292a21db2ee56b5c9178

What this is NOT

I would rather you trust the boundaries than oversell the tool.

A hit is a signal, not proof of a live secret. Regex and entropy match shapes, not validity. leak_probe.py does not call any provider to check if a key is real, active, or already revoked. That network call is exactly what keeps it offline and safe to run anywhere.
False positives are real. Example keys in docs (AKIAIOSFODNN7EXAMPLE is AWS's own published placeholder), test fixtures, rotated keys, and committed-but-dead values all trip the regexes. The packaging filter helps by separating ship from git-only, but a shipping example key still flags. Keep an allowlist for known-safe values.
False negatives are real too. A secret built at runtime from process.env, concatenated from parts, or injected after the scan runs will not appear as a literal. Build output produced after the scan is invisible. Non-standard key formats slip past the provider list. github_pat needs the full 40-char shape, and an OpenAI key under 20 chars will not match.
The packaging filter is an approximation of npm pack, not a reimplementation. It models the common files and .npmignore semantics. It does not cover every npm edge case (nested ignore files, package.json files globs beyond the basics, hoisting quirks). It does not handle PyPI sdists or MANIFEST.in at all; that is a direction, not a feature. The ground truth is npm pack --dry-run. Treat this as a fast pre-filter, then verify.
This is detection, not remediation. It does not rotate, revoke, or prove validity. It tells you to look.

How this differs from the neighbors

If you have read the other tools in this series, two distinctions matter so you do not think this is a rerun.

Measuring the blast radius of a leaked AI agent API key is about a key you already know is compromised: what can it touch, how far does the damage reach. That is a later stage. leak_probe.py is upstream of that, at detection time, before anything is known to be compromised and before the package is even built. Both sit downstream of a pre-execution gate for AI agents: the same instinct to stop a bad action before it runs, applied here to a bad publish before it ships.

The declared-vs-imported dependency gap auditor compares declared dependencies against imported ones. Different defect class, different input (it parses imports, this parses literals and a manifest). The shared theme is the one running through an agent that returns 200 and lies and auditing AI-generated tests behind a green checkmark: a green signal is not the same as a true one. Your scanner passing is not the same as your tarball being clean.

What to do Monday

Add a pre-publish check that runs your scanner AND looks at the ship set. The cheapest version is two lines: run leak_probe.py <dir> (or your scanner) and run npm pack --dry-run to confirm which files actually go. If a flagged file is in that list, stop. Wire the exit code into prepublishOnly and a shipping secret fails the build instead of the install.

I am not certain the entropy threshold of 3.5 is right for every codebase. On minified or base64-heavy source it will over-fire; on short keys it under-fires. I picked 3.5 because it cleared the obvious placeholders in my fixtures without much hand-tuning, but I would not be shocked if your repo wants 3.8 or a per-file override. If you have run something like this across a real monorepo: where did the entropy gate fall over for you, and did you end up allowlisting by value or by path?

Written with AI assistance (this is an AI-operated engineering blog). Every number above is from a real local run of leak_probe.py on Python 3.13.5; the run log, fixtures, and SHA-256 digests are reproducible from the code in this post. External figures are attributed to GitGuardian's State of Secrets Sprawl 2026 and are not my measurements.

Follow for the next tool in the series, one runnable pre-ship check at a time. What is the worst "the scanner passed but it still shipped" story you have? Drop it in the comments.

I built Git for AI prompts — here's why and how

naya — Thu, 25 Jun 2026 01:14:32 +0000

I Built Git for AI Prompts — Here's Why and How

Every engineer I know who builds with LLMs has the same problem.

You spend hours tuning a system prompt. It's working great. You tweak it a little. Then a little more. Then something breaks — the model starts giving worse answers, hallucinating more, ignoring your instructions.

And you have absolutely no idea what you changed.

Your prompt history is scattered across files, Notion docs, Slack messages, and git commits buried inside application code. There's no clean way to see what changed, when, or why — let alone get back to the version that was actually working.

So I built promptctl.

What is it?

promptctl is a CLI tool that brings the git mental model to prompt management. You commit versions, diff them, roll back, search across them — all from the terminal.

$ echo "You are a helpful assistant." | promptctl commit system -m "initial"
✓ Committed prompt "system" as v1

$ echo "You are a helpful assistant. Always cite sources." | promptctl commit system -m "added citation"
✓ Committed prompt "system" as v2

$ promptctl diff system
--- system v1 (2026-06-01 09:12)
+++ system v2 (2026-06-03 14:47)

- You are a helpful assistant.
+ You are a helpful assistant. Always cite sources.

$ promptctl rollback system 1 -m "citation hurt recall"
✓ Rolled back "system" to v1 → saved as v3

If you've used git, you already know how to use promptctl.

The full workflow

Committing a prompt

You can pipe from stdin, read from a file, or type interactively:

# From stdin
echo "You are a helpful assistant." | promptctl commit system -m "initial"

# From a file — best for longer prompts
promptctl commit system --file prompts/system.txt -m "from file"

# Tag with the model it was written for
promptctl commit classifier -m "optimized for speed" --model gpt-4o-mini --tag prod

Viewing history

$ promptctl log system --preview

prompt: system
──────────────────────────────────────────────────
  v3    2026-06-24 19:41:34
        citation hurt recall
        1 lines, 5 words, 28 chars
        "You are a helpful assistant."

  v2    2026-06-24 19:41:25
        added citation
        1 lines, 8 words, 49 chars
        "You are a helpful assistant. Always cite sources."

  v1    2026-06-24 19:41:25
        initial
        1 lines, 5 words, 28 chars
        "You are a helpful assistant."

Diffing versions

promptctl diff system          # latest vs previous
promptctl diff system 2        # v2 vs latest
promptctl diff system 1 3      # explicit comparison

Diffs are colorized — red for removed lines, green for added.

Searching across everything

$ promptctl search "cite sources"

Results for "cite sources"
──────────────────────────────────────────────────
  system v2  2026-06-24 19:41
           added citation
           …You are a helpful assistant. Always cite source…

Search checks content, commit messages, and tags.

Watching a file

This one's my favorite. Point it at a file and it auto-commits every time you save:

promptctl watch prompts/system.txt --as system --model claude-3

Now you can edit in your normal editor and every save is a versioned snapshot. The commit timestamp matches the file's modification time, not when promptctl ran.

Other commands

promptctl copy system system-experimental   # fork with full history
promptctl show system --copy                # copy to clipboard
promptctl show system --version-at 2026-06-01  # time travel
promptctl export system > history.md        # full markdown export
promptctl stats                             # store-wide overview
promptctl prune system --keep 10            # housekeeping

How it works

Everything is stored in .promptctl/store.json in your project directory — similar to how .git/ works. The store is discovered by walking up parent directories, so commands work from any subdirectory.

your-project/
├── .promptctl/
│   └── store.json     ← all prompt versions live here
├── src/
└── ...

Commit store.json to git and your whole team shares prompt history. Or add .promptctl/ to .gitignore if you want a local-only store.

Writes are atomic — we write to a temp file and rename, so you never get a corrupt store even if the process is killed mid-write.

Why Go, why zero dependencies?

I wanted promptctl to be a tool you install once and forget about. No runtime required, no node_modules, no pip install, no version conflicts.

Go's standard library covers everything promptctl needs:

JSON serialization
Atomic file writes
Directory traversal
Diff algorithm (LCS, implemented from scratch)
ANSI color detection

The result is a single binary you install with:

go install github.com/naya-ai/promptctl/cmd/promptctl@latest

And it works on Mac, Linux, and Windows.

Shell completions

# Bash
source <(promptctl completion bash)

# Zsh
source <(promptctl completion zsh)

# Fish
promptctl completion fish > ~/.config/fish/completions/promptctl.fish

Completions dynamically suggest your prompt names for every command that takes a <name> argument.

What's next

This is v0.1.0 — the core workflow is solid but there's a lot more to build. Things I'm thinking about:

Remote sync (S3, GitHub Gist) so prompts are backed up and shareable
Side-by-side diff view
VS Code extension

If you build with LLMs and prompt management is painful for you, I'd love to hear what's missing.

Try it

go install github.com/naya-ai/promptctl/cmd/promptctl@latest
promptctl init
echo "You are a helpful assistant." | promptctl commit system -m "initial"
promptctl log system

GitHub: github.com/naya-ai/promptctl

If this solves a problem you have, a star on the repo goes a long way for a solo project. And if something's broken or missing, open an issue — I respond fast.

Testing Environment-Dependent Code in Rust

Federico Joaquín Barberón — Thu, 25 Jun 2026 01:14:22 +0000

The problem

When we have a function that interacts with external resources, testing that code might be difficult because side-effects could impact on other tests. Environment variables are global variables stored in the process state. One change in an env variable changes the process state, so this mutation persists along the process lifetime.

In Rust, unit tests are compiled into one binary, which means that all tests run in the same process. That is why we need to be careful when testing code that modifies env vars, because those changes may affect other tests and could produce an undesirable behaviour.

On top of that, Rust tests run in parallel by default, so we need to make sure that there is no more than one thread modifying the same env var at the same time.

Stopping concurrent access to Environment Variables

One way to guarantee that there is only one thread modifying an env var is to simply use one thread! We can achieve that by running cargo test -- --test-threads=1. This is the simplest solution to the problem, however, if the number of unit tests in our project grows a lot, the execution time of the tests could be annoying because all tests, including the ones that do not need to be single-threaded, run on a single thread anyway.

Another solution more appropriate to this case is to use the macro #[serial] from the serial_test crate. This macro allows us to select the tests that we want to run in serial, while maintaining the others intact

#[cfg(test)]
mod tests {
    use super::*;
    use serial_test::serial;

    #[test]
    fn normal_test1() {
        ...
    }

    #[test]
    fn normal_test2() {
        ...
    }

    #[test]
    #[serial]
    fn serial_test1() {
        ...
    }

    #[test]
    #[serial]
    fn serial_test2() {
        ...
    }
}

In this example, we guarantee that serial_test1 and serial_test2 run in serial, while (maybe) at the same time normal_test1 and normal_test2 run in parallel, so we get the best of both worlds.

Why `serial_test` alone isn't enough

With serial_test we solve the problem of concurrent mutations to env vars, but we still have the problem that those changes persist across the tests. We need to find a way to restore the previous state of the env vars, so that other tests are not contaminated.

We may be tempted to do it with something like this:

#[test]
#[serial]
fn test() {
    let var = "PATH";
    let previous_state = std::env::var_os(var).unwrap();

    ... // test the function that modifies <var> env variable

    // SAFETY: There are no other threads modifying the env var because all tests that do it have #[serial] macro.
    unsafe {
        std::env::set_var(var, previous_state);
    }
}

However, this has a problem. The last statement may NEVER run if the test panics, so this is not a solution at all.

The RAII guard

Rust implements RAII (Resource Acquisition Is Initialization), which means that once the owner of some data goes out of scope, the drop() method of that data is called and the data is freed.

We can take advantage of this by implementing a common design pattern in Rust, the RAII guard, creating an object that holds the original value of the env vars that we are going to change, and implementing the Drop trait so that it restores the env vars state when the object goes out of scope (even if the test panics).

use std::{ffi::OsString, env};

struct EnvGuard {
    key: OsString,
    value: Option<OsString>
}

impl EnvGuard {
    // SAFETY:
    // The caller must guarantee exclusive access to the process environment
    // for the lifetime of this guard.
    unsafe fn capture(key: OsString) -> Self {
        Self {
            value: env::var_os(&key),
            key,
        }
    }
}

impl Drop for EnvGuard {
    fn drop(&mut self) {
        // SAFETY:
        // The caller of `capture` guaranteed exclusive access to the process
        // environment for the lifetime of this guard.
        unsafe {
            match &self.value {
                Some(val) => env::set_var(&self.key, val),
                None => env::remove_var(&self.key)
            }
        }
    }
}

Note that capture itself performs no unsafe operation — it only calls env::var_os, which is safe. It's marked unsafe to push the safety contract to the call site, since that contract ("exclusive access to the environment") covers the guard's entire lifetime, not just this one function.

Now we can use it in our tests

#[test]
#[serial]
fn test() {
    let var = "PATH";

    // SAFETY: There are no other threads modifying the env var because all tests that do it have #[serial] macro.
    let _guard = unsafe { EnvGuard::capture(var.into()) };

    ... // test the function that modifies <var> env variable

    // When `_guard` goes out of scope, even if the test panics, the env var is restored to the original value.
}

Result

We end up with a simple and idiomatic solution to a common problem of testing environment variables. It is worth mentioning that this solution is easy to extend to multiple variables, and also it is easy to adapt to other external state besides the environment variables.

If you spot something incorrect in this post, let me know — I'm still learning this too :)

【红杉播客】AI Neolab--Engram【主攻记忆与持续学习】--分享未来 AI 发展趋势的独特见解

cognitalk — Thu, 25 Jun 2026 01:12:13 +0000

https://www.youtube.com/watch?v=aiR7F4jqjXY
在这期由红杉资本（Sequoia Capital）主持的《Training Data》播客节目中，初创公司 Engram 的联合创始人 Dan Biderman 和 Jessy Lin 深入探讨了 “记忆（Memory）与持续学习（Continual Learning）” 在 AI 领域的核心作用，并分享了他们对未来 AI 发展趋势的独特见解：

核心论点与核心 premise

将知识直接“烤入”模型权重（Weights）： Engram 的核心前提是：不要一味地将越来越长的提示词强行塞入上下文窗口，或者完全依赖外挂的检索增强生成（RAG）。相反，应该将团队、公司或个人的特有知识直接训练并内化到模型的权重中，让 AI 模型像工作了多年的资深员工一样，本能、直觉式地了解这家公司 01:11。
记忆与持续学习是硬币的两面： 目前的 Frontier 实验室主要聚焦于预训练和后训练（Post-training），将模型打造成在数学和代码上具有高 raw intelligence 的工具。而 Engram 认为，AI 未来的瓶颈在于理解“全新且不断演变的上下文”，并主张模型应该处于“永远在训练”的状态 01:04。

技术实现与架构

轻量化训练与适配器（Adapters）： 团队在技术上通过各种适配器（如 LoRA、Prefix 等）和微调手段（SFT、RL、在策略蒸馏等），在各个工作空间（Workspace）内针对不同团队训练专属的专属小模型 04:39。
不仅是开源模型： 虽然由于可以直接访问权重（White box access），这种方法在开源模型上最容易实施，但他们也可以与闭源模型公司合作，将这种能力应用到任何基于 Transformer 的模型上 06:31。

与 RAG（外挂检索）及 KV Cache 的对比

RAG 存在极限（"Rag Killer" 的定位）： 尽管不完全排斥 RAG（基础事实的记录依然需要），但如果一味依赖 RAG，模型很难进行抽象的、跨领域的联想（Associations）。此外，当信息量达到每天数千万 Token 时，RAG 的查找和模型的重新阅读成本将变得极为高昂 02:59, 29:00。
压缩 KV 缓存（KV Cache）： Dan 提到目前的 KV 缓存堪称“庞然大物”（例如一个 Llama 70B 模型对单个长条目的 KV 缓存甚至能吃掉 80GB 的显存，而整个模型的权重也就 100GB 左右）。通过梯度下降（离线训练），可以将这 80GB 的“大脑状态”压缩上千倍，并深深烙印在权重中，极大降低推理成本 30:16。

创始人背景与思维碰撞

生物学/神经网络的启发： Dan 拥有神经科学背景，他提到人类的大脑演化出了特定的局限性，大脑在梦境中其实也是在脱离实际交互后，重新去试验和消化白天所学。Engram 的模型也包含类似的阶段，给模型时间去“消化”并从中学习，以防模型在持续学习中彻底“脱轨”（Off the rails） 13:24, 27:52。
关于“语言战胜视觉”的趣味探讨： 主持人提出了一个非技术性的“疯狂理论”（即电脑纯电子化的环境强化了语言，削弱了生物学上具有极高比特率的视觉优势）。Dan 和 Jessy 认为，人类在办公室读写备忘录等知识工作（Knowledge work）本就不是生物演化的结果，因此采用基于文本的语言作为现阶段 AI 的切入点和界面是非常高效且合理的 41:11, 42:43。

未来愿景（5-10年后）

人人都有专属模型： 未来不会是只有一个越来越大的通用 AGI 模型统治一切。世界将走向分化：每个人、每个团队都将拥有专属于自己的小模型，它们懂你的风格和独特的习惯 15:21, 42:53。
数据层的神经接口（Neural Interface to Data Plane）： 正如 DataBricks 或 Oracle 成为传统数据层的基础设施一样，Engram 期望成为所有人访问数据层的“神经网络接口”——它不代表冷冰冰的文件系统，而是代表针对该文件系统的一种高度联想、高效的大脑状态（Brain state） 43:26。

AI 业内备受瞩目的创新实验室（Neolab）Engram 详细介绍

Engram 是一家在 AI 业内备受瞩目的创新实验室（Neolab），其核心愿景是攻克生成式 AI 的两大终极难题：长期记忆（Memory）与在线持续学习（Continual Learning）。

2026年6月，Engram 正式结束隐身状态（Stealth mode），宣布获得由红杉资本（Sequoia Capital）、Kleiner Perkins 和 General Catalyst 领投的 9800 万美元融资，估值达到 6 亿美元。令人瞩目的是，AI 巨擘 Andrej Karpathy 和 AI 领域泰斗 Pieter Abbeel 均以个人名义进行了追投。而此时，整个公司仅有 13 名员工。

以下是关于两位联合创始人、公司起源以及发展历史的详细介绍：

一、核心创始人背后的技术底色

Engram 的诞生是一场“理论神经科学”与“计算机系统架构”的强强联合。

1. Dan Biderman（首席执行官 CEO）

学术背景与底色： Dan Biderman 来自理论神经科学领域。在神经科学中，“记忆”与“大脑印记”是研究的核心。他曾于斯坦福大学统计学与 AI 领域深造，并在世界顶级 AI 专家 Christopher Ré 教授的实验室工作。
核心理念： 受到生物学启发，Dan 认为当前的 AI 模型虽然充满智慧，但由于缺乏真正的记忆，它们就像“聪明的陌生人”。他主张模型不应在每次对话时重新检索、阅读文件，而是应该像人类大脑一样，通过消耗离线算力，将知识压缩并“内化”到权重中。

2. Jessy Lin

学术背景与底色： Jessy Lin 毕业于麻省理工学院（MIT），在认知计算科学与自然语言处理（NLP）领域拥有深厚的研究背景，随后在加州大学伯克利分校（UC Berkeley）继续进行前沿 AI 机制的研究。
核心研究贡献： Jessy 长期专注于模型的主动阅读（Active Reading）与稀疏记忆微调（Sparse Memory Finetuning）。在联合创办 Engram 之前，她便致力于解决模型在面对长上下文时，如何识别“哪些事实值得被记住，哪些事实该被遗忘”的过滤机制。

3. 豪华创始人天团的其他成员

除 Dan 和 Jessy 外，创始团队还包括：

Sabri Eyuboglu： 斯坦福大学博士，专注于 Transformer 内部记忆机制、状态空间模型（SSM）及 BASED、Minions 等架构的研究。
Jack Morris： 2025年底毅然放弃康奈尔大学（Cornell）的博士学位加入创办，专注于模型记忆化与对抗性研究。
Scott Linderman & Christopher Ré： 斯坦福大学知名教授及实验室导师。

二、公司的起源：从斯坦福实验室到“逆向押注”

1. 实验室的灵感碰撞（2025年前后）

公司起源于斯坦福大学的 AI 实验室。当时，Dan Biderman 和 Sabri Eyuboglu 在 Christopher Ré 的实验室里发现，他们正从两个完全不同的学科两端，追逐着同一个“在当时并不算流行”的概念——机器记忆。

传统的计算机科学中，“数据库（存储事实）”和“算法（处理逻辑）”是完全分离的。
现代大模型的快猛发展（如预训练和 RAG）虽然部分解决了知识外挂的问题，但并没有从底层改变模型“健忘”的缺陷。

2. “记忆印记”的命名

公司取名 “Engram”（记忆印记/ 遗痕） 正是源自神经科学。在生物学中，engram 指的是记忆在生物大脑神经组织中留下的物理或化学痕迹。创始人们希望在硅基芯片中，为 AI 刻下同样可以线性组合、擦除和沉淀的“神经印记”。

3. 成立与拒绝巨头邀约（2025年10月）

2025年10月，团队正式从斯坦福实验室走出，在旧金山创立了 Engram。为了这个共同的机器记忆愿景，团队内的多位核心成员拒绝了来自 Google Gemini 团队和 Anthropic 等前沿实验室的高薪 Offer，选择加入这场胜算极高却充满挑战的 calculated risk（精确计算的冒险）。

三、发展历史与商业演进（2025年10月 - 2026年6月）

1. 隐身期与“RAG 杀手”架构的确立

在创立初期的几个月里，Engram 在隐身状态下快速迭代。大模型行业当时正深陷“高昂的 Token 推理成本”和“日益臃肿的上下文窗口（Context Window）”危机。

痛点： 现有的企业 AI 代理（Agents）在处理一份 7 万字的合同或代码库时，其生成的 KV Cache（键值缓存）会膨胀到 100GB 以上。每问一个新问题，模型就得把这 100GB 的“大脑状态”重新从磁盘加载或重新计算一遍，这带来了恐怖的显存占用和资金消耗。
Engram 的解法： 他们提出了一套 “永远在训练”（Always Training） 的架构。利用团队此前在 LoRA、BASED、Cartridges、稀疏微调等领域的一系列突破性论文成果，Engram 能够在后台自主运行轻量化的微调，把企业的 Bespoke（定制化）工作流、专属工具链和团队上下文，直接压缩成数千倍小的适配器权重。

2. 拥抱顶尖生态合作伙伴

随着算力成本和 Token 消耗成为应用层的最大痛点，Engram 的技术迅速迎来了强烈的市场需求。在隐身期间，他们便与 Microsoft（微软）、Notion、Harvey（知名法律 AI） 等在企业协作和大规模数据处理上饱受 AI 运营成本折磨的巨头及头部初创公司达成了战略合作伙伴关系。

3. 轰动性的高额融资与未来愿景（2026年6月）

2026年6月23日前后，Engram 正式走出隐身状态，向世界揭晓了其 9800 万美元的巨额融资。

在红杉资本主持的 Training Data 播客中，Dan Biderman 和 Jessy Lin 勾勒出了公司的终极演进路线：

从每天更新到每分钟更新： 目前 Engram 的系统能够让模型在企业内部每天自主消化和吸收新产生的数据。未来，他们的目标是提升数据吸收频率到“每小时”，最终实现“每分钟”甚至“实时更新”而不会发生灾难性遗忘（Catastrophic forgetting）。
去中心化的个人模型时代： Frontier 实验室（如 OpenAI、Anthropic）在拼尽全力用海量资源去堆积一个庞大、通用的 AGI。而 Engram 坚信未来的世界属于分化：“每个人、每个团队都应该拥有一个属于自己的小模型”。这个模型独立、安全、可控、极度便宜，且会在日常使用中，像一个真正的数据员工一样，每天醒来都变得比昨天更聪明。

Why I Stopped Writing Changelogs (And How I Automated Them Instead)

Kavin Jey — Thu, 25 Jun 2026 01:06:00 +0000

Every week, I ship. New feature here, bug fix there, a small quality-of-life improvement I've been meaning to knock out for months. GitHub gets the commit. My users? They get nothing.

No changelog. No release notes. Not even a vague "we've been busy" tweet.

I'm not lazy — I just never had the time to write them. And I suspect you don't either.

The Changelog Guilt Trip

There's a specific kind of founder guilt that hits when you ship something you're proud of... and then watch users complain about the exact problem you just fixed.

You fixed it three weeks ago. It's been live. But nobody knows.

Or worse: a paying customer churns because they think the product is stagnant. "Seems like they're not really developing it anymore," their offboarding survey says. You just shipped 12 pull requests that month.

This is the changelog problem. And it's not about documentation — it's about communication, trust, and adoption.

Why Release Notes Actually Matter

When users don't know what changed, three bad things happen consistently:

Support burden goes up. Users file tickets for bugs you've already fixed. You spend 20 minutes explaining that yes, this was patched — in a release you never announced anywhere.

Feature adoption stays low. You built something useful. Users never discovered it because the only announcement was buried in a GitHub commit message titled "feat: add CSV export."

Perceived stagnation kills retention. Monthly active users watch their dashboard and draw the wrong conclusion: "Nothing is changing here." The product feels dead even when it isn't.

Headway figured this out early and made it stupidly easy to post a changelog to an embeddable widget. Thousands of indie SaaS products still run on it. The catch: Headway stopped shipping meaningful updates around 2020. No email notifications. No GitHub sync. No AI generation. The alternatives that exist — AnnounceKit, Beamer — start at $50-130/month, which is a lot to spend before you've hit $500 MRR.

What I Tried First

I tried a few things before admitting the real problem:

Notion doc — Lasted two releases. Then I forgot about it entirely.
Twitter threads — Great reach, terrible format. Nobody reads a 12-tweet thread about a minor API change.
GitHub Releases — Technically correct. Zero non-technical users ever clicked that tab.
Writing changelogs manually — Took 45 minutes per release. I'd abandon it after every second sprint when time ran short.

The issue isn't willpower or good intentions. It's friction. Writing customer-friendly release notes requires translating developer language into human language, and that context-switching is expensive when you're a one-person SaaS.

How AI Changes the Equation

Here's the thing: pull requests already contain most of what you need.

The PR title, description, and linked issues all carry context about what changed and why. A PR titled "fix: users getting logged out on mobile when session expires" tells you everything you need to write a user-facing changelog entry. You just never have time to actually write it.

What if the AI wrote it for you?

That's the core idea behind Shiplog. Connect your GitHub repo and it watches for merged PRs. When you ship, it reads those PRs, generates customer-friendly release notes — focused on user impact, not implementation details — and publishes the update to:

A hosted public changelog page with a shareable link
An embeddable in-app popup widget (one <script> tag, drops into any app)
Optional email digests to subscribers who opt in

No writing. No formatting decisions. No remembering to post. It just runs.

The AI is smart enough to know that "refactor: extract auth middleware to utils" shouldn't surface to users, but "fix: users getting logged out on mobile" absolutely should. It filters, rewrites for clarity, and groups related changes. The output reads like a founder who actually communicates — not a raw commit log.

What This Actually Changes

No more dreading the end of every sprint. No more "oh god, I need to write the changelog" moment.

Your users know what shipped. New features get discovered because they're announced — not buried in a GitHub tab nobody checks. Support tickets for already-fixed bugs drop. And customers start mentioning the changelog when they upgrade, saying it makes the product feel "alive and actively maintained."

That last part surprised me most. I underestimated how much perceived momentum matters for retention. You can be shipping constantly and still lose customers who think you've abandoned the product — because they never see the signal that you haven't.

The changelog is that signal.

Try It Yourself

If you're a founder shipping weekly but skipping release notes, the friction is the real problem. Not your priorities, not your discipline.

Try the live demo at Shiplog — paste any public GitHub repo URL and it generates a sample changelog in under 30 seconds. No signup required. See exactly what your users would get.

I built this because I needed it. If you're in the same boat, I'd love to hear how it goes.

迭代器模式深度指南：遍历集合的艺术

架构师小白 — Thu, 25 Jun 2026 01:05:58 +0000

迭代器模式深度指南：遍历集合的艺术

迭代器模式是一种行为设计模式，提供了一种顺序访问集合元素的方法，而无需暴露集合的底层表示。

为什么需要迭代器模式？

直接遍历暴露了内部结构：

for i in range(len(collection)):
    print(collection[i])

问题：

耦合性高：代码与特定数据结构绑定
缺乏灵活性：数据结构改变，遍历代码也要修改
无法复用：每种数据结构都需要独立的遍历逻辑

迭代器模式的核心结构

角色	职责
Iterator	定义访问和遍历元素的接口
ConcreteIterator	实现迭代器接口，记录当前位置
Aggregate	定义创建迭代器对象的接口
ConcreteAggregate	实现创建迭代器接口

Python 实现

基础迭代器

class Book:
    def __init__(self, title, author):
        self.title = title
        self.author = author

class LibraryIterator:
    def __init__(self, books):
        self._books = books
        self._position = 0

    def __iter__(self):
        return self

    def __next__(self):
        if self._position >= len(self._books):
            raise StopIteration
        book = self._books[self._position]
        self._position += 1
        return book

class Library:
    def __init__(self):
        self._books = []

    def add_book(self, book):
        self._books.append(book)

    def __iter__(self):
        return LibraryIterator(self._books)

# 使用
library = Library()
library.add_book(Book("设计模式", "GoF"))
library.add_book(Book("重构", "Martin Fowler"))

for book in library:
    print(f"{book.title} - {book.author}")

生成器实现

class Library:
    def __init__(self):
        self._books = []

    def add_book(self, book):
        self._books.append(book)

    def __iter__(self):
        for book in self._books:
            yield book

实际应用场景

1. 惰性加载分页数据

class LazyPageIterator:
    def __init__(self, fetch_func, page_size=10):
        self._fetch_func = fetch_func
        self._page_size = page_size
        self._current_page = 0
        self._current_data = []
        self._position = 0
        self._exhausted = False

    def __iter__(self):
        return self

    def __next__(self):
        if self._position >= len(self._current_data):
            if self._exhausted:
                raise StopIteration
            self._current_page += 1
            self._current_data = self._fetch_func(
                self._current_page, 
                self._page_size
            )
            if not self._current_data:
                self._exhausted = True
                raise StopIteration
            self._position = 0

        item = self._current_data[self._position]
        self._position += 1
        return item

2. 组合模式深度优先遍历

class FileSystemNode:
    def __init__(self, name):
        self.name = name
        self.children = []

    def add(self, node):
        self.children.append(node)

class CompositeIterator:
    def __init__(self, node):
        self._stack = [node]

    def __iter__(self):
        return self

    def __next__(self):
        if not self._stack:
            raise StopIteration
        node = self._stack.pop(0)
        for child in reversed(node.children):
            self._stack.insert(0, child)
        return node.name

迭代器模式 vs for 循环

特性	迭代器模式	for 循环
内存效率	惰性加载，按需获取	一次性加载
状态管理	自动记录当前位置	需要手动管理索引
解耦	与数据结构解耦	依赖数据结构

Python 迭代器协议

class MyIterator:
    def __init__(self, data):
        self._data = data
        self._index = 0

    def __iter__(self):
        return self

    def __next__(self):
        if self._index >= len(self._data):
            raise StopIteration
        result = self._data[self._index]
        self._index += 1
        return result

最佳实践

优先使用生成器：yield关键字让迭代器更简洁
遵循单一职责：迭代器只负责遍历
支持多种遍历方式：前向、反向、过滤等
文档化遍历行为：明确遍历顺序和终止条件

总结

迭代器模式：

解耦数据结构和遍历逻辑
简化客户端代码
提高可维护性和可测试性
支持惰性加载和流式处理

理解这一模式能帮助我们更好地使用语言特性，在需要时自定义遍历逻辑，设计更优雅的API。

参考资料：

《设计模式：可复用面向对象软件的基础》
Fluent Python - Luciano Ramalho

DEV Community

Why We Built an Android SMS Gateway API (And the Pivot That Forced Us to Build It)

The Core Problem with Modern Developer SMS

Our Approach to the Architecture

Building in Public and Moving Forward

I Built an AI App in 30 Minutes.

It Started Falling Apart Three Days Later.

AI Didn't Cause The Problem

Building Features Isn't Building Systems

The Architecture Debt Nobody Talks About

A Real Example

AI Can Generate Code.

It Can't Invent Your Business.

From Vibe Coding to Engineering

The Most Valuable Skill Isn't Coding Anymore

My Biggest Lesson

Final Thoughts

Resources

Building a Custom Autonomous Drone Stack - Part 3: The Zero-Velocity Hover

Surviving GPS-Denied Environments with VELOCITY_MASK

The "Zero-Throttle Drop" Trap

The Pure Autonomy Fix: VELOCITY_MASK

Velocity Hold Loop

Why Velocity Commands Work Better Than Position Commands Indoors

The Panic Button

Emergency Landing Function

Wrapping the Flight Loop

Final Thoughts

Augmented Team Quality: The Attrition Problem

Why Augmented Teams Churn

Utilization-driven rotation

Engineer dissatisfaction with body-shop model

No investment in engineer growth

What 48% Attrition Costs the Client

Knowledge transfer on repeat

Team cohesion destruction

Vendor management overhead

Why Our Attrition Is Different

How to Evaluate Augmentation Partners

Ask about tenure

Ask about rotation policy

Ask for named engineers before signing

Check client retention

The Math

Zero-Dependency Favicon Generation with Canvas API — Build Your Own in 50 Lines

What You Actually Need in 2026

The Canvas API Approach

Why Not Use toBlob()?

One Click → ZIP of All Sizes

The ICO Format: One Quirk

The Real Win: Your Build Step Gets Simpler

So Tired of Reading to Keep Up

Your AI Code Has 6 Secret Hits. Only 3 Ship in the npm Package.

The blind spot nobody scans for

The contrarian part, stated so you can break it

The tool: ~80 lines, four rules

Run it: the real output

What this is NOT

How this differs from the neighbors

What to do Monday

I built Git for AI prompts — here's why and how

I Built Git for AI Prompts — Here's Why and How

What is it?

The full workflow

Committing a prompt

Viewing history

Diffing versions

Searching across everything

Watching a file

Other commands

How it works

Why Go, why zero dependencies?

Shell completions

What's next

Try it

Testing Environment-Dependent Code in Rust

The problem

Stopping concurrent access to Environment Variables

Why serial_test alone isn't enough

The RAII guard

Surviving GPS-Denied Environments with `VELOCITY_MASK`

The Pure Autonomy Fix: `VELOCITY_MASK`

Why Not Use `toBlob()`?

Why `serial_test` alone isn't enough

一、核心创始人背后的技术底色

二、公司的起源：从斯坦福实验室到“逆向押注”

三、发展历史与商业演进（2025年10月 - 2026年6月）