Coder Legion - Recent Discussions

Answered: How Much Detail Belongs in an Error Message?

Sun, 01 Nov 2026 16:17:49 +0000

I think the best approach is to keep API errors technical internally but make the frontend messages simple and actionable. Users need to know what went wrong and how to fix it, not see the entire response payload. A support reference ID is also a smart way to make debugging easier without exposing sensitive details.

Answered: OPEN-SOURCE ATTENDNACE SYSTEM FOR AN SME

Sun, 01 Nov 2026 12:06:09 +0000

Interesting idea for small businesses. An open source attendance system can save SMEs a lot of money while making employee tracking much easier. I’d love to see features like leave management, late entry reports, and simple monthly attendance exports.

Answered: What Should a Permission Error Explain?

Sun, 01 Nov 2026 08:34:12 +0000

Good permission errors should answer: Why am I blocked? Can I fix it? What’s the next step? without exposing sensitive details about owners, groups, or permissions.

Answered: Should Exact Search Matches Always Come First?

Fri, 30 Oct 2026 15:36:43 +0000

I think exact matches should generally come first because users often search with a specific item in mind. However, recent activity and relevance should still influence the ranking, especially when multiple results have similar names. Would an option to prioritize exact matches make the search experience more flexible without adding unnecessary complexity?

Answered: Which Time Zone Is This Export Using?

Thu, 29 Oct 2026 16:23:39 +0000

Great reminder that timezone handling can easily cause confusion in exports. Including the timezone and UTC offset would make things much clearer for everyone.

Answered: When should an AI agent stop acting?

Thu, 29 Oct 2026 14:08:53 +0000

I stop an agent after the second failed retry on the same resource. The first retry rules out a transient error, but after that it should post the logs and the last error and wait. Looping past that point burns quota and hides the real fault.

Answered: AI Gives the Right Answer. But Does It Actually Save Time?

Thu, 29 Oct 2026 13:57:03 +0000

Integration has been harder for me, and the copy-and-update step you describe is where the time goes. I'd log what happens to each answer once it lands in the record, saved as is or edited first. That edit rate answers your title question more directly than an accuracy score, because it counts the work left for the user.

Answered: Senior Engineers Are Paid to Say No

Wed, 28 Oct 2026 16:49:42 +0000

Knowing when to say no is an important engineering skill, especially when a quick solution could create bigger problems later. How do you balance pushing back on unrealistic requests while still meeting business goals and deadlines?

Answered: Should a Failed Upload Clear the Form?

Wed, 28 Oct 2026 16:49:09 +0000

I think a failed upload should keep the form data whenever possible, so users don’t have to start over and lose their progress. How would you handle cases where some files upload successfully but others fail?

Answered: Build an AI Ops Dashboard with FSCSS modules (ai-ui, st-core, circle-progress, overlapui)

Wed, 28 Oct 2026 16:25:21 +0000

Nice project. Building an AI ops dashboard with reusable components and CSS modules is a practical approach. I especially like the focus on UI structure and handling overlapping progress circles. Clean, reusable components make dashboards much easier to maintain as they grow.

Answered: I’m back, and this time we’re coming out of the casino, not the mine! 😎

Wed, 28 Oct 2026 09:29:24 +0000

Really interesting title. I like the idea of changing direction and trying a different approach. Looking forward to seeing what comes next.

Answered: What Does an Empty Dashboard Mean?

Tue, 27 Oct 2026 11:51:53 +0000

An empty dashboard doesn’t always mean something is missing. Sometimes the real issue is how the system communicates with users. Clear messages, useful guidance, and a suggested next step can make a big difference in user experience. I think designing for these situations is just as important as designing the dashboard itself.

Answered: When Should Delete Offer Undo?

Mon, 26 Oct 2026 12:20:57 +0000

Undo is such a small feature, but it can make a big difference in user experience. Giving users a chance to recover from mistakes makes an app feel much more reliable.

Answered: What part of debugging does AI still struggle with most?

Sun, 25 Oct 2026 16:04:52 +0000

From my experience, despite how creative AI can be, it still fails to translate our mental process into what its actual output becomes. Because humans and AI aren't fully in sync, debugging will always be part of the mandate. We picture perfection, but we're flawed in how we communicate it.

So the real question becomes: What communication process are we missing that makes post-hoc debugging the only way to clean up the gap?

Answered: 💬 Developers: Would you ship AI-generated code without reviewing it first?

Sun, 25 Oct 2026 15:59:14 +0000

One word bro.... or let's make it two - No, Never!

Answered: Help, where do I start? Animated Character videos

Sun, 25 Oct 2026 15:57:24 +0000

This is a Long one tho but you're going to have to bear with me 😅

The overwhelm is completely valid, the AI video landscape is full of bloatware, and many general-purpose LLMs (like ChatGPT or Claude) only help write scripts, not render consistent video scenes.

To keep your budget intact and avoid subscription burn, the key is knowing that no single tool does everything well. You need a simple, targeted pipeline:

The Practical 3-Step Pipeline

Step 1: Character & Style Anchor (2D / Illustrated)
- The Goal: Lock in one visual character turnaround (front, side, close-up) so your character doesn't morph between shots.
- Tools: Midjourney (using character reference tags --cref) or tools designed for identity locking like Neolemon or Paintbrush.
- Avoid: Direct text-to-video for new characters—it causes instant visual drift.

Step 2: Voice & Lip-Sync Audio
- The Goal: Get high-quality, expressive voice lines before doing any animation.
- Tools: ElevenLabs is the industry baseline for character voice acting. Generates crisp audio clips you can feed directly into video lip-sync engines.

Step 3: Image-to-Video Animation
- The Goal: Animate your anchored still images using audio or motion prompts.
- Tools: Runway (Gen-4/Gen-3), Kling AI, or Seedance via image-to-video. Upload your character image, add the ElevenLabs voice, and let the tool drive the talking head/expressions.

Key Advice Before You Spend

Distinguish "Patch/Clip" from "Project": Don't try to generate a full 3-minute video in one prompt. Build scene-by-scene, shot-by-shot (3–5 second clips max per prompt) and edit them together in a standard video editor like CapCut or Premiere.
Start on Free / Entry Tiers: Run test clips using free daily credits on Runway or Kling to test face stability before committing to paid creator plans.
Tutorial Recommendation: Look up YouTube tutorials specifically searching for "AI Image-to-Video Character Consistency Workflow" or "Midjourney + ElevenLabs + Runway Lip Sync Tutorial". These break down shot composition without selling platform fluff.

What specific illustration style (e.g., 2D anime, comic book, 3D toon) are you aiming for with your characters?

Answered: AI Is Not Going to Save You. It Might Not Replace You Either.

Sun, 25 Oct 2026 15:54:08 +0000

"The real product is not the code. It is the behavior of the system over time."

This hits the nail on the head. AI drastically changes the cost of typing syntax, but it doesn't touch accountability, system architecture, or the reality of debugging production failures when things break. A fantastic reminder that our real job is cultivating judgment, not just churning out volume.

Answered: I'm Still Figuring This Out

Sun, 25 Oct 2026 15:44:59 +0000

Love this perspective. Reclaiming the joy of building by leaning into architecture, problem-solving, and agentic workflows—rather than getting bogged down in implementation boilerplate—is a massive shift.

Looking forward to following the work with NotableBIT and BIT Voices as you build in public! 🙌

What do you think of this draft? Let me know if you want to tweak the tone or focus!

Answered: What evidence should an AI coding assistant provide before saying a bug is fixed?

Sun, 25 Oct 2026 15:42:36 +0000

Setting a risk-tiered standard makes total sense: a static typo or label fix only needs a simple visual diff, while race conditions or core logic shifts demand a strict failing-to-passing reproduction test.

I'd lean toward requiring a regression test for anything touching state or business logic, but allowing a documented manual check for trivial UI or copy updates. Explicitly separating states like "patch ready," "locally verified," and "production confirmed" in AI tooling would clear up so much friction during code reviews.

Answered: When Is a Progress Bar Misleading?

Sun, 25 Oct 2026 13:09:57 +0000

A progress bar can sometimes create more frustration than confidence if it doesn’t reflect what’s actually happening. I think showing an honest status message is better than pretending to know the exact completion time. But is a fake percentage ever acceptable if it helps users feel the process is moving forward?

Answered: When Should a Client Preview Link Expire?

Sun, 25 Oct 2026 05:54:19 +0000

Love the clarifications in comments. Thanks for the assistance!

Answered: Can You Belong to a Community Without Finding Your Audience?

Sat, 24 Oct 2026 16:51:53 +0000

I find CoderLegion to be a project without clear direction or focus. It is equal time LinkedIn, Craig's List, Twitter, Medium and perhaps more. In all these areas, it is not a platform for consumers - it is a platform for other technical content creators. Finding an actual community for any game here will be hard. While the total user base is smaller, and therefore any project is easier to discover, it is most likely going to be discovered by other creators also looking for their audience.

Answered: Building in Public From a Solo Gamedev Perspective (credits to @Karol Modelski for the post idea)

Sat, 24 Oct 2026 16:45:58 +0000

I often question what is the real reason for "building in public". gamedev/indiedev/screenshotsaturday hashtags are moreless an echo chamber where the main consumers of those posts are not players from the target audience but rather fellow gamedevs who might never play the game.

The progress updates are then mainly about getting some encouragement to further development via likes and other forms of interactions, feedback (as well-intentioned as it might be) shall be scrutinized and filtered.

Thinking about it in this way might alleviate some stress from the posting process itself.

Answered: Should a Resized Image Export Need a Fresh Visual Review?

Sat, 24 Oct 2026 16:21:03 +0000

I would make the boundary a rule that can be checked by machine instead of a policy: the derivative must keep the approved crop box and aspect ratio, and the disclosure label region must stay above a minimum rendered height, for example measured in pixels at the delivery size. If both checks pass, skip human review and write the export record; if either fails, require a visual check. A label that is readable at 2000 px can fail at 800 px, and a digest cannot see that. What delivery sizes does the pipeline produce, and has a label ever passed review at full size and failed at the smallest one?

Answered: When an AI Image Job Times Out, Should Retry Create a New Job?

Thu, 22 Oct 2026 11:47:18 +0000

The case I'd design for next is the browser losing the operation ID entirely, say a cleared tab or the photographer retrying from a phone. I'd have the server list in-flight batches for the account and show them on the upload screen before Retry is even offered, so recovery doesn't depend on client storage. I'd also hang the credit reservation off the operation ID and release it if no job record appears within a short window, which covers your "credits possibly reserved" case where nothing actually ran.

Answered: php2shell: how are you confirming which PHP your web traffic actually runs on?

Thu, 22 Oct 2026 09:21:09 +0000

Interesting point. Checking php -v isn’t always enough because the web server might be running a different PHP version. How do you verify the actual version handling live traffic across all environments?

Answered: Mapping 32k+ MCP Servers: How we are handling tool discovery without schema drift

Thu, 22 Oct 2026 07:33:23 +0000

Great questions @SuMTa and @scunliffe!

Handling 32K+ independently updating MCP servers without triggering context-window drift or JSON-RPC tool lookup failures requires moving away from static tool manifests.

In our architecture (deployed across the SEOSiri MCP Suite at developers.seosiri.com), we solve this using a three-tiered defense:

Dynamic JSON-RPC 2.0 Introspection (tools/list): Rather than hardcoding tool definitions in the client prompt, local agents dynamically query the edge gateway on session handshake. This ensures any backend parameter update is reflected instantly.
Cryptographic Schema Sealing (HMAC-SHA256): To prevent man-in-the-middle schema substitution or payload drift, every tool declaration and execution block is cryptographically signed at the edge (running on Cloudflare Workers). If a tool's schema drifts or fails validation, the gateway returns a strict JSON-RPC error code before it ever hits the LLM context window.
Stateless Edge Buffer Tiering: High-frequency tool telemetry uses a hot/cold RAM separation model, ensuring token consumption stays minimal while maintaining sub-millisecond discovery latency.

Are you running into schema versioning issues with custom local servers, or scaling across multi-agent enterprise mesh layers? Let's discuss how you're handling state sync!

Introducing The Startup Café: A Community for People Building Startups ☕

Tue, 20 Oct 2026 19:15:24 +0000

I Started The Startup Café on DEV. Here's the Idea Behind It.
I've just started a new organization on DEV called The Startup Café, and I wanted to share it here while it's still at the very beginning.

Here's the organization: https://dev.to/startupcafe

The idea came from something pretty simple: there's a lot to learn from people who are building things, even when they're working on completely different projects.

Some developers build things for clients. Some work on side projects after their day job. Some are trying to launch a SaaS, while others are still figuring out which idea is worth pursuing.

I've always found that side of building interesting. Not just seeing what someone has launched, but understanding why they started, what they're figuring out, and what they've learned along the way.

I'd like The Startup Café to be a place for those conversations.

What do I have in mind?

I don't want this to be just another place to drop a project link and move on.

I'd like people to share what they're working on, ask for feedback when they're stuck, write about things they've learned, and discover projects they might not have found otherwise.

Maybe you're building your first website. Maybe you're working on a SaaS and trying to find your first users. Maybe you've got an open-source project, or an idea you keep coming back to but haven't started yet.

All of those are worth talking about.

You don't need to have a successful startup or years of experience to take part. Sometimes the most interesting discussions come from people who are still working things out.

I'd also love to see people connect through the organization. You might find someone dealing with the same problem, discover a project you want to contribute to, or meet a developer who's interested in building something similar.

There's no guarantee of where those conversations will lead, but that's part of what makes a community interesting.

It's just getting started

I want to be clear that The Startup Café is brand new. I'm not introducing an established community with a big audience or claiming we've already built something huge.

I'm starting small, and I'd like the people who join to have a say in what this becomes.

What would make it useful? What kinds of posts would you like to see? Would you be interested in sharing your progress, getting feedback, finding collaborators, or learning from other people's experiences?

Those are the kinds of questions I'd like us to figure out together.

Interested in joining?

The Startup Café is a DEV.to organization, and that's where the community will come together.

You can visit the organization here:

https://dev.to/startupcafe

I've also built a small website for it. If you'd like to join, you can visit the website to learn more and submit an application:

https://thestartupcafe.vercel.app

If this sounds like something you'd enjoy being part of, I'd be glad to have you check it out.

And even if you're not ready to join, I'd still appreciate hearing your thoughts.

So, what are you building these days?

It can be a startup, a side project, an open-source contribution, or just an idea you're considering. I'd love to hear what you're working on and where you are with it.

Let's start there.

Should an AI Listing Draft Be Allowed to Overwrite Newer Agent Edits?

Tue, 20 Oct 2026 10:49:18 +0000

Imagine a property agent starts an AI rewrite of a listing description. While it runs, a colleague corrects a factual detail in the same listing. The AI result then arrives, based on the older version.

What should the application do with that result?

A useful distinction is finishing generation versus accepting a change. The generated draft can be retained without replacing the current description.

HTTP already has a building block for this problem. RFC 9110, section 13.1.1 describes If-Match as a way to guard against accidental overwrites when clients update the same resource. With a supporting API, a client sends the strong ETag it read; a failed precondition can produce 412 Precondition Failed.

For a property-content editor, a possible design is:

Record the listing revision used to generate the draft.
Save the AI output as a separate proposal.
Compare that base revision with the current listing when someone applies it.
If they differ, show the original, current, and proposed text for review.

The difficult part is the user experience. A changed punctuation mark and a corrected room count should not necessarily receive the same treatment. A version check catches a conflict; it does not decide whether the new wording is factually safe.

Would you block every stale AI draft, allow field-level merging, or always require a review screen? What would make your choice change?

This is a hypothetical design question, not a claim about a particular product's implementation.

Can a Keyboard-Only User Finish Your App’s Main Task?

Mon, 19 Oct 2026 07:41:47 +0000

Pick the main task in your web app: submitting a form, uploading a file, booking an appointment, or creating a project.

Now put the mouse aside and try to finish it using the keyboard.

Where does the journey first become confusing or impossible?

Some useful places to check:

A custom dropdown that opens but cannot be operated
A dialog that opens without a clear focus position
A validation error that appears somewhere the user does not notice
A drag-and-drop interaction with no usable alternative
A focus indicator that disappears against the background
A component you can enter but cannot leave

W3C’s keyboard accessibility guidance explains why functionality needs a keyboard-operable route, with a limited exception for inherently path-dependent input. Its no-keyboard-trap guidance addresses being able to leave a component again.

A keyboard walkthrough is a useful first check. It does not establish full accessibility or replace screen-reader and other accessibility testing.

What is one keyboard-accessibility bug your team found late, and what changed in your development or review process afterward?

If you are building something new, which critical flow will you test first?

Waqas Ahmad | Software Engineer | Content Creator

Would an independent final-email rule check earn a place beside your existing tests?

Sun, 18 Oct 2026 11:12:47 +0000

I’m cun he, maker of InlinerAPI. If you maintain business receipts, reset messages or invitations, I’d appreciate one current-work comparison: https://inlinerapi.netlify.app/requirements

Use synthetic final rendered HTML and an independently expected copy, displayed amount or CTA destination. The browser preview needs no signup. It checks the supplied content; it does not refresh application data, run your templates, validate tokens, or test inbox appearance or delivery.

What rule did you attempt, what result did you observe, and how did setup and maintenance compare with your existing tests? If it helps recurring work, what would your team need to justify paying for these current checks?

Digital Masquerade: How Deepfakes Turn Social Engineering Into Fucking Hell

Sat, 17 Oct 2026 10:24:11 +0000

It starts with a message. The sender claims to be your company's CFO, and the subject is a "confidential transaction." Confidential means don't ask around. You feel the small, familiar itch of suspicion. It's an odd request. It smells a bit like phishing.

So you do the sensible thing. You ask for a video call.

The CFO is there. His face, his voice, the way he phrases things. A few colleagues you recognize are on the call too, nodding along. Everyone looks normal. Everyone sounds normal. Your suspicion quietly packs its bags and leaves, because you just did exactly what every security awareness slide tells you to do: you verified with your own eyes.

Then you send the money.

That isn't a hypothetical. In January 2024, a finance employee at the engineering firm Arup, working in Hong Kong, was reportedly walked through precisely this sequence. According to Hong Kong police, every other participant on that call was a deepfake. The employee made transfers totalling HK$200 million, about US$25.6 million. The fraud surfaced only when he later checked with the company's head office.

His mistake wasn't carelessness. He did what a cautious person does. The entire security model of "seeing is believing" just got deprecated, and nobody pushed the changelog.

TL;DR: Faces and voices are now unauthenticated input. Detection tools and human intuition won't save you, because both are losing the arms race. The only defence that scales is Zero Trust applied to people: bind high-risk actions to cryptographic identity and process, never to what someone looks or sounds like. A checklist, some pseudocode, and ready-to-use scripts are below.

"Seeing Is Believing" Has Been Deprecated

The cost of faking a person used to be a film studio and a budget. Now it's footage that already exists online: conference talks, podcasts, earnings calls, that LinkedIn video where your VP says "I'm thrilled to announce." Hong Kong police said the Arup attackers built their fakes from publicly available video and audio of online conferences and virtual meetings.

The trend lines are ugly, with the usual caveat that this is an under-reported crime category:

TRM Labs' 2026 AI-in-Crime Adoption Index climbed to 54, up from 28 in 2024, and it reports that deepfake-scam losses in the first months of 2026 already exceeded the entire 2025 total by 263%.
The FBI's 2025 Internet Crime Report logged more than 22,000 AI-related fraud complaints with reported losses above $893 million, and congressional researchers have estimated that fewer than 5% of voice-clone victims report their losses at all.
Deloitte has projected generative-AI-driven fraud losses in the US reaching US$40 billion by 2027, up from US$12.3 billion in 2023.

Treat any single number here as a rough indicator, not gospel. The direction is not in dispute.

And it fits the wider picture from earlier in this series. Verizon's 2026 breach report found phone-centric lures succeeding about 40% more often than email in its simulation data, and Mandiant's M-Trends 2026 ranked vishing the second most common initial-access vector. Attackers have noticed that humans trust voices. Deepfakes simply make that trust cheap to counterfeit.

The Anatomy of a Deepfake Heist (Defender's Edition)

You can't defend against a chain you can't picture, so here's the structure. I'm keeping this at the level of what to watch for, not how to build one.

Reconnaissance. Who approves payments, who reports to whom, and what does the target executive's public audio and video look like? Org charts and conference recordings are free.
Pretext. Urgency, secrecy, and authority, delivered together. If you read the biological OPSEC post, you'll recognize the Cialdini toolkit. "Confidential" does double duty: it explains why you can't verify and it isolates you from colleagues who might.
Channel setup. A spoofed email or message that books the call. In the Arup case, an initial message about a confidential transaction came first.
The call. Notice multiple fake participants. That's social proof, manufactured. One suspicious face is a red flag; four familiar ones is consensus.
The ask. A payment, a credential reset, a "temporary" access grant.
The exit. The call ends, the accounts go dark, and the money is already moving through several hops.

Every step in that chain exploits a human shortcut, not a software bug. That's the point of this series: you can't patch System 1.

Why "Just Detect the Deepfake" Isn't a Plan

Tempting idea: deploy a detector, flag fakes, done. Unfortunately:

Humans are near coin-flip. A 2024 meta-analysis of dozens of studies put average human detection accuracy for deepfakes at roughly 55%, barely better than guessing. Training helps a little, confidence helps not at all.
Detectors degrade in the wild. Video-conferencing compression smears exactly the artifacts detectors look for, real-time detection has latency budgets a live call doesn't care about, and models trained on last year's synthesis techniques miss this year's.
The attacker only needs one success. A detector that's right 95% of the time is a 5% jackpot for someone running the attack at scale.

Use detection as a signal. Never use it as a control. A control is something that still works when it's wrong.

Zero Trust, Translated for Humans

NIST's Zero Trust Architecture (SP 800-207) boils down to a principle you already know from network security: never trust, always verify, and never grant trust based on where a request appears to come from. We've applied that to packets and subnets for years. It's time to apply it to faces.

The one-line version, which you're welcome to put on a mug:

Perception is not authentication.

A face on a screen and a voice on a line are claims, the same as a username typed into a login form. You'd never treat a typed username as proof of identity. So stop treating a familiar voice as one.

Here's the anti-pattern in code, because it's funnier when it compiles:

# What the Arup-style attack exploits (pseudocode, do not ship)
def release_payment(call):
    if call.face_looks_like("CFO") and call.voice_sounds_like("CFO"):
        wire(25_000_000)   # looks legit, ship it

And the version that survives deepfakes, because it never asks the question "does this look like the CFO?":

# Zero Trust for payments (pseudocode)
def release_payment(req):
    assert req.exists_in_system_of_record()          # not just "someone asked on a call"
    assert len(req.approvers) >= 2                   # dual control
    assert all(a.passkey_verified for a in req.approvers)  # phishing-resistant auth
    assert req.beneficiary in vendor_master \
        or req.new_beneficiary_verified_via_callback()     # known number, not the caller's
    assert req.amount <= LIMIT or req.cooling_off_elapsed()
    wire(req)

Nothing in the second version cares what anyone looks or sounds like. That's the design goal.

The Verification Stack

Think in layers. No single layer is bulletproof, but an attacker has to defeat all of them.

1. Cryptographic identity for anything that moves money or grants access
Use phishing-resistant authentication (passkeys / FIDO2 hardware keys) for approvers and administrators, and require approvals to happen inside a system that records them, not in a chat or on a call. As covered in the identity-stack post, a hardware key is domain-bound and signs a challenge; a deepfake can imitate your CFO's face, but it can't produce her private key.

2. Out-of-band callback, to a number you already had
If a request arrives on one channel, confirm it on another, using contact details from your own directory. Not the number in the email. Not the number the caller offers. Not the meeting link they sent. The attacker controls everything they hand you; they don't control your HR system.

3. Pre-agreed challenge phrases
Low-tech, effective, and underused. Agree on a secret with your leadership team and finance staff in person or over an authenticated channel, rotate it, and make sure it's not derivable from public information. Add a duress variant ("the code word that means someone is making me ask"). Same trick works for families: voice-cloning scams that impersonate a relative in trouble are real, and a family code word costs nothing.

One caution: a question about something "only the real person would know" works only if the answer isn't online. Ferrari reportedly foiled a fake-CEO call when an executive asked about a book the real CEO had recently recommended, and the call ended. That's a great story. It's also luck plus one sharp employee, so make it policy instead of hoping for sharp employees.

4. Process controls that make deepfakes irrelevant

Dual authorization above a threshold, with approvers independent of each other.
Cooling-off periods on large or unusual transfers. Urgency is the attacker's best friend; delay is your cheapest control.
Strict handling of changes to payee bank details, verified by callback.
A written rule: no approvals by voice or video alone. If the policy says it doesn't count, nobody can be pressured into counting it.

5. Meeting hygiene
Require authenticated participants (SSO-backed accounts), use a waiting room for anyone external, and treat an unfamiliar account or domain as a red flag no matter how convincing the face. "Camera on" is not proof of anything anymore.

A note on "liveness stunts" like asking someone to turn their head or wave a hand in front of their face: these can trip up weaker real-time fakes, and they're fine as an extra speed bump. They're also getting less reliable every quarter. Don't build a control on them.

6. The help desk and hiring pipelines
Attackers go where the verification is weakest. Reportedly, the 2023 MGM Resorts intrusion started with a phone call to an IT help desk. Never reset credentials or MFA enrolment on the strength of a voice alone: verify through an authenticated channel, a manager approval in a system of record, or a stronger identity check. The same logic applies to remote hiring, where a polished candidate on camera is now a claim to be verified, not a fact.

Make It Socially Safe to Say "I'll Call You Back"

Here's the cultural bug that kills most of this. Authority bias is powerful. An employee who suspects something still has to be willing to say "I'm going to verify this" to someone who outranks them, on a call, while the supposed CFO says it's urgent.

Give people the words, and make sure leadership has publicly agreed to be on the receiving end of them:

"Our policy requires me to confirm this through the payments system. It'll take five minutes."

"I'm going to call you back on the number in the directory. If this is real, nothing changes."

"I can't approve anything on a call, and neither can you. Please submit it in the system."

A real executive will say "good, that's exactly what I want you to do." A fake one will get impatient. Impatience is data.

What About Reducing the Source Material?

Executives whose voice and video are all over the internet are the easiest to impersonate, and trimming that footprint is reasonable hygiene. Don't confuse it with security. You can't un-publish ten years of conference talks, and the attacker only needs a few seconds of clean audio. Assume you can be faked, and design as if everyone can be.

The same applies to provenance standards like content credentials for published media: genuinely useful for establishing where a clip came from, but they don't help on a live call where nothing was published in advance.

The Checklist

High-risk approvals happen in a system of record, never on a call or in a chat
Approvers use phishing-resistant authentication (passkeys / hardware keys)
Dual authorization and a cooling-off period above a defined threshold
Bank-detail changes verified by callback to a number from your own directory
A rotated challenge phrase (with a duress variant) for leadership and finance
A written rule: voice or video alone never counts as approval
Meetings require authenticated participants, with a lobby for externals
Help desk can't reset credentials or MFA on a voice alone
Staff have scripts and leadership has agreed to honour them
A family code word at home, because your relatives have voices too

The Point

For about a century, "I saw him with my own eyes" and "I'd know that voice anywhere" were gold-standard evidence. They're now claims at best. That's uncomfortable, and it's also clarifying, because it forces us to do what security engineers have been saying all along: stop trusting appearance and start trusting verification.

In my own recruiter-phishing story, the tell wasn't how convincing the persona was. It was the channel the attacker wanted me to use. Deepfakes are the same lesson, upgraded: the more convincing the face, the more your attention belongs on the process behind it.

Trust is a budget. Spend it only on things that can sign.

Your turn: What's the verification step in your company for an urgent payment request, and would it survive a convincing deepfake of your CEO? Drop it in the comments. If the honest answer is "we'd probably just send it," that's the most useful thing you can learn today.

Interconnected Growth: A Community Begins with Each of Us

Fri, 16 Oct 2026 19:17:32 +0000

There is a quiet vulnerability in sharing our work. Whether we publish an article, offer an idea, or describe something we have created, we put a small part of ourselves in front of others. Behind that contribution may be hours of effort, years of experience, or the courage to be visible for the first time.

Naturally, we hope someone will respond. A thoughtful comment, a reaction, or a simple acknowledgment can reassure us that our contribution has reached another person.

Within a growing community, however, that hope carries a shared responsibility. If we all publish and then wait for others to begin the conversation, even a website filled with valuable contributions can feel remarkably quiet.

Participation Makes Belonging Possible

A developing platform needs more than a steady flow of new content. It needs people who take an interest in what others bring to it.

It is understandable to focus on our own work. Time is limited, responsibilities compete for our attention, and many of us are trying to build something meaningful alongside other commitments. Still, when we hope for engagement, it is worth considering whether we are making room to offer it ourselves.

Reading another person’s article, acknowledging a useful observation, or asking a sincere question helps establish the culture we would like to experience. These small actions make participation feel worthwhile, particularly for people who are still finding their confidence.

For someone wondering whether their work belongs, a few considerate words may carry more weight than we realize.

Mutual Support Without Keeping Score

Supporting one another should never become an obligation to exchange praise. A reaction does not create a debt, and leaving a comment should not come with an expectation of repayment.

The value lies in sincere attention.

We can recognize effort without agreeing with every conclusion. We can offer a different perspective respectfully, share an experience that adds to the discussion, or explain what we found useful. Meaningful engagement gives someone evidence that their contribution has been considered.

Over time, that attention builds familiarity and trust. People become more comfortable sharing unfinished ideas, asking questions, and offering their own knowledge. The community gains depth because its members feel there is someone on the other side of the conversation.

Our Growth Is Connected

On a website that is still developing its community, each interaction helps shape what the platform becomes.

When we respond thoughtfully to someone’s work, we give them a reason to return and contribute again. Their continued participation may help another person learn, connect, or feel encouraged. What begins as a small gesture can gradually strengthen the experience for everyone.

No individual can create an active community alone, and nobody should feel responsible for responding to everything. But we can each contribute to an environment where attention moves in more than one direction.

Before leaving after our next post, perhaps we can spend a little time with someone else’s. Read beyond the headline. Acknowledge an idea that deserves consideration. Leave the kind of thoughtful response we would appreciate receiving.

Every contribution represents a person hoping to be heard. A growing community becomes stronger when we make space to hear one another.

What habits daily make you a really great software engineer?

Fri, 16 Oct 2026 17:09:05 +0000

Well, what do you think what are some top notch habits that makes you in top zone of engineering

Good debugging starts with better questions

Fri, 16 Oct 2026 03:27:21 +0000

When production breaks, the first question should not be: Who broke it?

A better starting point is:

"What changed in the system?"

That shifts the discussion toward evidence:

recent deployments
configuration changes
dependency behavior
traffic patterns
logs, metrics, and traces

For me, evidence-first debugging usually leads to faster diagnosis and better team behavior.

What question do you ask first when a production issue starts?

Discussion: What does it take to make an MCP server production-ready?

Wed, 14 Oct 2026 14:33:00 +0000

A local MCP server can be straightforward to run. Production deployments introduce different requirements when agents interact with remote APIs, databases, and execution environments.

Our new SEOSiri guide examines several important areas:

Scoped authentication and authorization

Secure SSE-based remote communication

Stateless service design

Response pruning and pagination for token efficiency

Sandboxed execution for dynamic code

The central engineering question: how do you give an AI agent useful capabilities without granting unnecessary access or creating avoidable operational risk?

Read the technical breakdown:
https://www.seosiri.com/2026/10/building-mcp-servers-production-security.html

For developers working with MCP, AI infrastructure, and DevSecOps.

Why Does Code Work Locally but Fail in Production?

Wed, 14 Oct 2026 12:39:53 +0000

One of the most frustrating problems in software development is when everything works perfectly on your machine, but breaks after deployment. 💀

The tricky part? The code itself isn't always the problem.

Here are five things I would investigate first:

Environment variables
A missing API key, incorrect URL, or improperly configured environment variable can break an otherwise working application.
Dependency differences
Different package versions or runtime environments can produce unexpected behavior.
API and CORS configuration
An endpoint that works locally might fail in production because of origin restrictions, incorrect URLs, or deployment configuration.
Database permissions
A feature may work with local development permissions but fail when production security policies are enforced.
Build and deployment settings
Incorrect routes, missing assets, case-sensitive file paths, and build configuration differences can cause issues that never appeared locally.

My rule is simple: don't assume the deployment is broken until you've identified where the failure actually occurs.

Reproduce the issue, inspect the logs, isolate the failing layer, and test the fix before deploying again.

💬 Question for developers: What's the most confusing production bug you've encountered, and what turned out to be the actual cause?

Where do squared error and cross-entropy actually come from?

Wed, 14 Oct 2026 05:20:00 +0000

Short answer: maximum likelihood. Choose a distribution for the output, then:

Read its parameter as the network's output → output function
Take −log of it → error function

Gaussian (regression)

Output: ŷ = Wᵀh + b (the mean)
Error: −log N(y; ŷ, σ²) → squared error (constants drop out)

Bernoulli (binary classification)

Output: exponentiate + normalize → ŷ = σ(z)
Error: −log P(y) → cross-entropy = softplus((1 − 2y)z)

Why the pairing matters: with cross-entropy, the log cancels the sigmoid's exponential, so ∂J/∂z = σ(z) − y. With squared error, σ′(z) stays in the gradient and goes to ~0 when the model is confidently wrong, so learning stalls.

Full derivations: https://husseinmahdi.xyz/writing/series/math-behind-neural-networks/

Next up: softmax + cross-entropy for k classes.

Stop setting your dark mode background to #000000 and text to #FFFFFF

Sun, 11 Oct 2026 18:40:37 +0000

Pure black on pure white creates high chromatic contrast that causes eye strain and severe halation for readers with astigmatism.

A proper dark theme uses layered dark grays/slates (#121212, #1E1E1E) to express depth through elevation shadows and tinted surfaces rather than stark, blinding contrast.

What are your favorite color palettes for comfortable dark mode reading?

Would you use free assets in your games?

Sat, 10 Oct 2026 14:55:56 +0000

I would, and I don’t think there’s any shame in it.

I’ve never really understood the stigma around using free assets in game development. Sometimes, people talk about them as if downloading a free model or sound somehow makes the rest of your work less valuable.

But why?

For anyone unfamiliar with the term, assets are the individual things that go into a game: trees, buildings, characters, sounds, animations, textures, and so on. Making all of those takes time, and creating a game involves much more than making its individual parts.

If someone offers a useful asset for free and allows others to use it, I see that as an opportunity.

Free doesn’t mean bad.

The price of an asset doesn’t tell you whether it looks good, works properly, or fits your game. A paid model can be unsuitable for your project, while a free one can be exactly what you need.

Some creators choose to share their work because they want to help other developers. Kenney, for example, makes its game assets available under CC0, allowing people to use them without requiring credit. These resources are offered for a reason: so people can build with them.

There’s nothing embarrassing about accepting that help.

Your time matters, too.

Imagine you need a simple chair for a room in your game. You could spend days learning how to model it, give it the right surface details, and get it working in the engine. Or you could find a suitable free chair and spend that time improving something the player will actually do.

Neither choice is automatically wrong. If you want to learn how to make furniture, creating the chair yourself makes sense. If your goal is to finish a playable game, using an existing one might make more sense.

Personally, I don’t think developers should feel pressured to spend days proving they can make an ordinary chair when their game needs attention elsewhere.

That time could go towards a better mission, smoother movement, clearer menus, or fixing an annoying bug.

A downloaded asset doesn’t build the game for you.

This is probably the part that gets overlooked most often.

Downloading a door doesn’t make it open. You still need to decide how the player interacts with it, whether it needs a key, what happens when it’s locked, and how it connects to the rest of the game.

Downloading trees doesn’t create an interesting forest. You still have to build the space, create paths, place things thoughtfully, adjust the lighting, and make sure the game runs well.

The person who made the asset did valuable work. The person who turns it into part of a playable experience also does valuable work.

Using someone else’s model doesn’t erase everything you built around it.

You can use the same pieces and create something different.

Two people can cook with the same ingredients and make very different meals. I think game assets work in a similar way.

The same house model could become a peaceful home in one game and an abandoned building in another. Different lighting, sounds, surroundings, and events can completely change how that place feels.

Custom artwork can certainly help a game stand out. But a game’s identity also comes from its ideas, its atmosphere, its story, and the way it plays.

Every rock and table doesn’t need to be exclusive for the overall experience to feel personal.

Free assets help you find out whether an idea actually works.

An idea can sound amazing when you write it down and feel completely different once you try to play it.

Having models, sounds, and animations available lets you reach that playable stage sooner. You can test a mechanic, try a different layout, or discover that something needs changing before spending months making everything yourself.

And if a free asset still works well in the finished game, why replace it purely because it was free?

I’d rather replace something because it doesn’t fit or causes problems, not because I feel guilty about how much it cost.

Not everyone has a studio’s budget.

A solo developer might be handling the gameplay, environments, menus, sound, testing, and writing. That’s already a lot for one person.

They may not have the money to hire people for every task, or the years needed to become good at every part of development.

Free assets make it easier for people to learn and give their ideas a real chance. They can also leave room in the budget for things that need special attention: perhaps an original main character, music, or an important location.

Using free resources where they fit can help you afford custom work where it matters most.

Of course, you still need to choose carefully.

I’m not saying every free asset belongs in every game.

Some won’t match the look you’re going for. Some might slow the game down or take too much effort to adjust. You also need to check what the creator allows you to do with them and give credit when required.

And you should be honest about your contribution. Using someone’s model is fine when you have permission. Claiming you made that model yourself is a different issue.

Those are fair things to discuss. But none of them makes using free assets shameful.

Judge the result.

If a game looks messy, runs badly, or isn’t enjoyable, those are fair criticisms. Explain what isn’t working.

Simply saying “that’s a free asset” doesn’t tell me what’s wrong with the game. Paying for the same object wouldn’t suddenly make the gameplay better.

For me, the question is simple: does this asset fit what I’m making, and does using it help me move the project forward?

If the answer is yes, I’m happy to use it.

I respect people who create everything themselves. I also respect people who know where to spend their time and use the resources available to them.

So yes, I would use free assets in my game. Why should a useful resource become something to be ashamed of just because it didn’t cost money?

The rendering of markdown for code block is not working well in CoderLegion?

Sat, 10 Oct 2026 10:08:04 +0000

For example:

Angular Example

main.ts

ThemeLoader.init();
bootstrapApplication(AppComponent, appConfig);

theme-select.component.ts

constructor() {
this.themes = ThemeConfigConstants.themesDic ? Object.keys(ThemeConfigConstants.themesDic).map(k => {
const c = ThemeConfigConstants.themesDic![k];
const obj: ThemeDef = {
display: c.display,
filePath: k,
dark: c.dark
};
return obj;
}) : undefined;
}

themeSelectionChang(e: MatSelectChange) {
ThemeLoader.loadTheme(e.value);
}

I turned strings into letter arrays and started rebuilding URLs with index ranges

Fri, 09 Oct 2026 22:09:28 +0000

I was just playing with a tiny idea:

What if every string was just an array of single characters… and I could pull pieces out by index ranges to form words, paths, or API links?

That experiment became string-range-tokens — a zero-dependency ESM package that does exactly that.

The core idea

import { toTokens, sub, build } from 'string-range-tokens';

const t = toTokens('https://api.example.com/v1/users');

sub(t, 0, 4);                 // "https"
sub(t, 23, 25, [26, 31]);     // "/v1/users"
sub(t, -5, -1);               // "users"   ← negative indexes work
build(t, [0, 4], [23, 25]);   // "https/v1"

toTokens turns any string into a proper array of characters (Unicode-safe).
sub and build let you reassemble any combination of inclusive ranges.

Why bother?

Sometimes you want to:

Assemble API paths or query fragments from a shared token pool
Avoid writing the full string literal in one place
Pick substrings by position without regex
Build tiny string “templates” from a fixed alphabet
Teach indexing, ranges, and a bit of recursion in a playful way

It’s not encryption (never hide real secrets with it). It’s just a clean, lightweight way to work with strings as letter arrays.

Extra powers

`plan` – find the ranges that rebuild a target

const pool = toTokens('the quick brown fox');
const ranges = plan(pool, 'brew');
build(pool, ...ranges); // "brew"

`scatter` / `gather` – seeded shuffle + reconstruct

const { pool, key } = scatter('/api/orders', 7);
gather(pool, key); // "/api/orders"

Useful for deterministic scrambling when you want both the shuffled tokens and a way to put them back together.

Install

npm i string-range-tokens

Or just copy the source — it’s a single file with no dependencies.

Works in Node 18+, Deno, Bun, and the browser.
Both JavaScript and TypeScript implementations are included.

CDN:

import { toTokens, sub, build, plan, scatter, gather } 
  from 'https://cdn.jsdelivr.net/npm/string-range-tokens@1.0.0/src/index.js';

I Taught AI to Review My Code So I Never Miss Leg Day Again

Fri, 09 Oct 2026 11:11:20 +0000

It's 10:48 p.m. on a Sunday. I'm folded over my desk like a question mark, reviewing a 1,400-line pull request titled "small cleanup."

My neck has developed opinions. My quads have filed a bug report titled "Not used since the last release." Status: won't fix.

Somewhere in this diff, around line 812, there's a bug. I know it's there the way you know there's a spider in the room. I just can't see it, because I've been reading for ninety minutes and my eyes have quietly switched from reading to scrolling with intent.

That was the night I made a rule: the code works for me, or it doesn't work here.

TL;DR: Your evenings aren't disappearing because you're slow. They're disappearing because AI made code cheap and review expensive. The fix is a four-layer pipeline where machines reject what machines can reject, an AI does the first pass, and you only spend human attention on the stuff that deserves it. Config snippets and a "steal this" checklist are at the bottom.

First, an Honest Word About the Title

Yes, I close pull requests in five seconds. Yes, I have done it from a plank. GitHub Mobile, shaking arms, steady conscience.

But I don't do it because a robot typed "LGTM." I do it because the previous four hours and fifty-nine minutes of review already happened, automatically, before the pull request ever reached my phone.

The five-second merge is the output of a system, not a leap of faith. A leap of faith is how you end up writing a postmortem.

Why Your Evenings Are Disappearing (It's the Volume, Not You)

Here's the part nobody put in the AI-coding marketing deck. Faros AI analyzed telemetry from more than 10,000 developers in 2025, and teams with high AI adoption completed about 21% more tasks and merged about 98% more pull requests. Great. But pull requests also got roughly 154% larger, and median review time went up about 91%, while organization-level delivery metrics stayed essentially flat.

DORA's 2025 research landed in the same neighbourhood. Roughly 90% of respondents now use AI at work, AI adoption is finally associated with higher throughput, and it's still associated with worse delivery stability. DORA's framing, which I can't improve on: AI is an amplifier. It amplifies a healthy delivery system and it amplifies a chaotic one, with equal enthusiasm.

Translation: the bottleneck moved. It used to be writing code. Now it's you, at 11 p.m., reading code that nobody typed. Congratulations, you're the world's most expensive linter.

So let's stop being one.

The Four Layers (a.k.a. How I Get to Leg Day)

Layer 0: Don't Review What a Machine Can Reject

The single biggest waste of human review time is arguing about things a tool can settle in four seconds: formatting, unused imports, type errors, a failing test, a leaked secret, a dependency with a known CVE. If a human has ever typed "nit: missing newline," your pipeline is broken, not your colleague.

Make all of it a required check that blocks the merge button. Here's a minimal, boring example for a Go project:

name: ci
on: [pull_request]

permissions:
  contents: read

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4   # pin to a full commit SHA in real life
      - uses: actions/setup-go@v5   # same here
        with:
          go-version: stable
      - run: test -z "$(gofmt -l .)"
      - run: go vet ./...
      - run: go test -race ./...

About that pinning comment: if you read my supply-chain post, you know why. Tags are mutable, commit SHAs are not. Your CI pipeline is the most privileged thing in your repo, so treat its dependencies accordingly. Add a secret scanner and a dependency audit to the same job and you've deleted roughly half of what used to eat your Sunday night.

Layer 1: The AI First Pass (Your Tireless, Slightly Overconfident Junior)

This is where an AI reviewer earns its keep: summarizing what a 1,400-line diff actually does, catching the boring-but-real stuff (ignored error returns, missing nil checks, tests that don't test), and giving you a map before you enter the cave.

Rules I follow so it stays useful instead of noisy:

Tell it what you care about, in writing. Several AI reviewers read repo-level instruction files such as AGENTS.md or .github/copilot-instructions.md and treat them as review criteria. Check your tool's docs for the exact filename. Mine looks like this:

# Review rules
- Flag any new heap allocation in files under /hotpath.
- Flag any syscall wrapper that ignores its error return.
- Flag changes under /crypto that don't touch a test file.
- Do not comment on formatting. CI already handles that.

Expect false positives. Industry estimates for typical tools tend to land somewhere around 5 to 15%, and a tool that cries wolf gets muted within a week. Muted tools protect nobody.
Know the meter is running. Since GitHub's billing change this June, each Copilot review consumes both AI credits and Actions minutes. "Free robot reviewer" now comes with a taxi meter.
Run the Leg Day Test before you trust anything. Take a representative PR, seed it with four bugs you know about, and open a second, correct PR to see whether the tool invents a problem that isn't there. Count real catches and false alarms separately. Re-run it every few months, because vendors swap the underlying models and the reviewer you tested in spring is not necessarily the one running in autumn.

The AI is a junior who never sleeps. It is not the person who signs off.

Layer 2: Humans Review Intent, Not Syntax

With layers 0 and 1 done, your job shrinks to the part machines are genuinely bad at. Four questions, in order:

Should this exist? Is this the right change for the actual problem?
What breaks at 3 a.m.? Failure modes, rollbacks, observability.
What's the blast radius? One endpoint, or the whole auth flow?
What would an attacker do with this? (If you're a regular here, you already ask this one by reflex.)

Keep the diff small, because attention has a shelf life. The classic SmartBear/Cisco study of roughly 2,500 reviews found defect detection falls off sharply beyond a few hundred lines and after about an hour of continuous reviewing. A 1,400-line "small cleanup" isn't reviewable. It's a hostage situation. Send it back and ask for three PRs.

Layer 3: Merge Policy, a.k.a. Where the Five-Second Merge Becomes Legal

This is the layer that makes plank-merging safe instead of reckless:

# .github/CODEOWNERS
*            @you
/auth/       @you @second-pair-of-eyes
/crypto/     @you @second-pair-of-eyes
/.github/    @you @second-pair-of-eyes

Branch protection with required checks. Nothing merges red. No exceptions for "it's just a typo," because the typo is always in the config file.
Mandatory second human on risky paths: auth, crypto, payments, infrastructure, the CI config itself.
Auto-merge only for low-risk changes with green checks: docs, patch-level dependency bumps, generated files.
No special trust for AI-authored code. If anything it gets more scrutiny, since nobody on the team can say "I wrote it, I remember why."

Now the five-second approval isn't a gamble. It's a rubber stamp on a document that's already been notarized three times.

Discipline Is a Pipeline

Here's the philosophical bit, and then I'll let you go.

Willpower is a terrible architecture. It's a flaky test: passes when you're rested, fails at 11 p.m. on a Sunday, and nobody can reproduce it. Psychologists have studied this for decades. Precommitment and "if X, then Y" implementation plans beat raw motivation because they move the decision out of the moment where you're weakest.

A review pipeline is precommitment for your career. You decided once, in daylight, what "good enough to merge" means. After that, the system enforces it while you're tired, rushed, or hanging off a pull-up bar.

The gym works the same way. You don't "feel like" brushing your teeth every morning; it's a routine. Leg day is a CI job for your body: scheduled, boring, and fails visibly when you skip it. Last post I said sleep is a build step. This one's the sequel: the gym is your deploy window. Both are non-negotiable, and both die first when the code starts running you.

Where This Goes Wrong (Because Something Always Does)

Rubber-stamping. If the AI reviewer says "looks good" and you stop reading, you haven't automated review, you've automated not reviewing. Layer 2 exists so a human still owns the decision.
Giant PRs sneaking back in. AI makes it easy to generate 2,000 lines before lunch. Enforce a size limit, or review capacity collapses again and you're right back at the desk at 11 p.m.
Amplifier effect. A weak test suite plus a fast code generator plus an AI reviewer is just a faster way to ship bugs with a confident summary attached.

Steal This Setup

[ ] Formatter, linter, type-checker, tests, secret scan, dependency audit as required checks
[ ] CI actions pinned to commit SHAs, with minimal permissions
[ ] AI reviewer configured with written rules for your codebase
[ ] The Leg Day Test run on your own repo before you trust the tool
[ ] PR size limit (a few hundred lines, then split)
[ ] CODEOWNERS with a second human on auth, crypto, payments, infra and CI config
[ ] Auto-merge only for low-risk changes with green checks
[ ] A calendar block for the gym that gets the same respect as a production incident

The Point

Code should work for you, not the other way around. Automate the boring review work, spend your attention where judgment actually matters, and use the time you win back for the things that keep you functional: sleep, sunlight, and heavy objects that don't compile.

Your pull request queue will always be full. Your quads, on the other hand, are on a deadline.

Your turn: What's the most mind-numbing chore in your workflow that a pipeline could be doing instead? Drop it in the comments and let's crowdsource the automation.

And if you're reading this hunched over a diff right now: close the tab, stand up, do ten squats. The PR will still be there. Honestly, so will the bug on line 812. But your legs will be thrilled.

the evolution of software development since the emergence of AI

Fri, 09 Oct 2026 09:51:04 +0000

It would be interesting to promote discussions on the evolution of software development since the emergence of AI, and how it has been transforming the sector and the jobs of many developers. In my experience, it's not advisable to swim against the current, so it would also be valuable to create a dedicated section to discuss and build technical AI applications that can boost our productivity and allow us to create more complex, useful developments that non-technical users cannot achieve.

Do you think the emergence of AI is a positive or negative event for software developers?

Mi Definition of Done: 5 gates que convierten "creo que funciona" en "puedo demostrarlo"

Thu, 08 Oct 2026 07:28:13 +0000

Mi Definition of Done: 5 gates que convierten "creo que funciona" en "puedo demostrarlo"

Nota honesta: esto no es un producto, es una mini-app de uso personal en mi Linux Mint. Funciona y la uso a diario; su adaptación para terceros la planifico para los próximos días.
Read time: ~8 min · Etiquetas: python security testing opensource

Un commit. Una hora. Y no es un juguete

El proyecto del que hablo hoy tiene un solo commit y tardó una hora en funcionar de punta a punta. Lo uso cada mañana. Y no es un juguete.

Lo digo porque la pregunta interesante no fue cómo lo programé rápido, sino cómo supe que estaba terminado. Ese es el punto: "terminado" no es una sensación, es una decisión que puedes defender. Cuando esa decisión tiene una definición clara, programar una hora deja de ser un atajo y pasa a ser consecuencia.

Este post es esa definición. La llamo Definition of Done y son cinco gates.

Qué hace, sin tecnicismos

Imagina un llavero. Guarda tus claves API y credenciales cifradas dentro de tu propio ordenador y se las sirve a tus aplicaciones durante toda la sesión después de un único desbloqueo al iniciar sesión. Nada sube a la nube. No hay telemetría. No hay cuenta que crear.

En la práctica, mis scripts y programas ya no llevan claves escritas dentro ni dependen de un .env en claro: consultan el llavero, que ya está abierto por mí, y arrancan sin volver a pedirme nada. Si me voy, el llavero se cierra; las claves desaparecen de la memoria.

Se llama pass-encrypt-env. Corre en mi Linux Mint y, hoy, es para mí.

Lo que es hoy (y lo que todavía no)

Ser claro con el estado real es parte del método. Un proyecto "terminado" también declara sus límites.

Es: una herramienta personal, funcional, que uso a diario en mi equipo.
No es: un producto instalable por cualquiera sin fricción, ni algo auditado por terceros.
Viene: en los próximos días planifico la adaptación —empaquetado, arranque en otras distribuciones y documentación para quien no sea yo— como un esfuerzo aparte y planificado.

Y hay una razón de fondo para separar esa adaptación del desarrollo: no quiero declarar "lista" una app porque pase en mi máquina. La declaro lista cuando pasa los gates en cualquier máquina. Es exactamente la misma lógica que un buen test: no vale que funcione una vez, tiene que fallar cuando corresponda.

Por qué exijo evidencia y no sensaciones

Soy relativamente nuevo en el mundo de la IA agéntica, aunque llevo años gestionando sistemas bajo protocolo: control de accesos, mínima exposición, registros. Y una disciplina que aprendí ahí —y que el prompting me recordó— es esta:

No das algo por resuelto porque parezca resuelto; lo das por resuelto cuando puedes demostrarlo.

El hábito de protocolo es la mínima exposición: asumes que algo fallará y diseñas para que, cuando falle, no arrastre contigo todo lo demás. Aplicado al software, eso se traduce en una Definition of Done: una lista corta de condiciones que convierten "yo creo que funciona" en "aquí está la prueba".

En este proyecto, esa lista lleva cinco puertas.

Los 5 gates

Cada gate existe porque previene un fallo concreto, no por completitud.

1) Tests que pueden fallar

No me sirve "tengo tests"; me sirve que fallen cuando rompo algo. En pass-encrypt-env hay 19 tests y uno de los que más valor tiene es este, porque vigila una promesa sobre el disco:

def test_no_plaintext_on_disk(tmp_path):
    path = tmp_path / "vault.enc"
    v, unlocked, _ = _new()
    vault.set_secret(unlocked.payload, "TOKEN", "super-secret-value")
    vault.reseal(v, unlocked.dek, unlocked.payload)
    vault.save_vault(v, path)

    blob = path.read_text()
    assert "super-secret-value" not in blob          # el secreto no está en claro
    assert (path.stat().st_mode & 0o777) == 0o600     # y el fichero no es legible por terceros

Ese test no comprueba que "va bien": comprueba que la promesa del producto se cumple. El fallo que previene es el peor de todos: creerte seguro y no serlo.

2) Lint limpio

ruff check .

No es estética. Un lint en verde elimina de antemano la clase de error más tonta —imports sin usar, variables fantasma, comparaciones sospechosas— antes de que la ejecutes. Es ruido que no llega a producción porque ni siquiera llega al commit.

3) Escaneo de seguridad

bandit -q -c bandit.yaml -r src

bandit busca patrones inseguros en el código: criptografía mal usada, subprocess peligrosos, aleatoriedad no criptográfica. En una app cuyo único trabajo es guardar secretos, este gate no es opcional. El fallo que previene es el uso accidental de una primitiva parecida a la correcta.

4) CI reproducible

Los tres gates anteriores corren solos en GitHub Actions, sobre Python 3.11 y 3.12:

strategy:
  fail-fast: false
  matrix:
    python-version: ["3.11", "3.12"]
steps:
  # ...
  - name: Gate (ruff + bandit + pytest)
    run: ./scripts/ci.sh python

Y aquí está la parte importante: ese ./scripts/ci.sh es el mismo comando que ejecuto en local. No hay una verdad para mi máquina y otra para el servidor. El fallo que previene este gate es "en mi máquina funciona", que no es un bug: es una mentira cómoda.

5) Smoke end-to-end

Los unit tests verdes no garantizan que el sistema entero arranque. Para eso hay un smoke test headless que levanta el agente, habla con él por su canal interno y comprueba el comportamiento observable:

python3 -m pass_encrypt_env.cli env --if-unlocked >/dev/null 2>&1 || rc=$?
echo "env --if-unlocked (bloqueada) -> exit $rc (esperado 3)"
[ "$rc" -eq 3 ]

Aun con piezas perfectas, el conjunto puede no montarse. El smoke test es el gate que mira el sistema, no las partes.

La meta-regla

Todos los gates caben en un comando:

./scripts/ci.sh    # esto corre en local y esto corre en CI. La misma verdad.

Qué protege y qué no

Un proyecto terminado con honestidad publica su techo, no lo esconde. Este es el mío:

Amenaza	¿Mitigado?
Robo offline de `vault.enc`	Sí — sin master + TOTP no hay datos
Manipulación del fichero	Sí — AEAD detecta la alteración
Alguien sin tu TOTP	Sí — segundo factor obligatorio
Pérdida de master o TOTP	Sí — clave de recuperación
Proceso del mismo UID con la bóveda abierta	No — techo del diseño cero-prompt
`root` / malware ya dentro	No — fuera de alcance

Que la última fila diga "No" no es una debilidad: es una promesa cumplible. Prefiero un alcance pequeño y cierto que uno grande y falso.

Detalle técnico (para quien quiera el fondo)

El "cómo", para quien lea esto con la ingeniería delante:

Cifrado en reposo: vault.enc con Argon2id como función de derivación (64 MiB, 3 pasadas, 4 lanes) y AES-256-GCM como cifrado autenticado (confidencialidad e integridad).
Doble envoltura de la clave de datos (DEK): K1 = Argon2id(master) · K2 = HKDF(K1 ‖ totp_secret) abre la DEK · K3 = HKDF(recovery_key) guarda una copia para recuperación. El secreto TOTP viaja cifrado: sin un TOTP válido no se obtiene la DEK.
Agente de sesión: escucha en un socket Unix en $XDG_RUNTIME_DIR/passenv/, permisos 0600 y validación de UID del par (SO_PEERCRED). Se endurece con PR_SET_DUMPABLE=0 (anti-ptrace), sin volcados de memoria y mlockall best-effort.
CLI passenv: init, set/get/list/rm, export, exec, change-master, backup, restore.
Modelo de amenazas completo en docs/THREAT_MODEL.md, con el techo del diseño cero-prompt declarado a propósito.

Lo que esto cambia (Takeaway)

El gate no es un freno; es lo que te deja pisar el acelerador sin miedo. Un proyecto de una hora y un commit no llega "terminado de verdad" por suerte: llega porque las condiciones para llamarlo terminado ya estaban escritas antes de empezar a escribir código.

"Creo que funciona" es una sensación. "Aquí está la prueba" es un proyecto.

La checklist

- [ ] Tests que fallan cuando rompo algo (no que existan)
- [ ] Lint limpio
- [ ] Escaneo de seguridad sin hallazgos
- [ ] CI reproducible (mismo comando en local que en remoto)
- [ ] Smoke end-to-end en verde

Y tú

¿Qué requisitos le exiges tú a un proyecto para darlo por terminado? ¿Cuál añadirías a mis cinco gates? Y, ya que el mío está en estado de uso personal: ¿tú publicarías una herramienta así o la dejarías privada hasta "adaptarla"? Cuéntamelo en los comentarios; leo y respondo a todo.

_{English version below · El original está en español. If you're an English speaker, scroll down to the translation and tell me what your own Definition of Done looks like. I reply to everyone.}

My Definition of Done: 5 gates that turn "I think it works" into "here's the proof"

Honest note: this isn't a product, it's a personal-use mini-app on my Linux Mint. It works and I use it daily; adapting it for other people is a planned effort for the coming days.
Read time: ~8 min · Tags: python security testing opensource

One commit. One hour. And it's not a toy

The project I'm talking about has a single commit and took one hour to work end to end. I use it every morning. And it isn't a toy.

The interesting question wasn't how I built it fast, but how I knew it was done. That's the point: "done" isn't a feeling, it's a decision you can defend. Once that decision has a clear definition, writing code for an hour stops being a shortcut and becomes a consequence.

This post is that definition. I call it a Definition of Done, and it's five gates.

What it does, without jargon

Picture a keyring. It keeps your API keys and credentials encrypted inside your own computer and serves them to your applications for the whole session after a single unlock at login. Nothing goes to the cloud. There's no telemetry. There's no account to create.

In practice, my scripts and apps no longer carry keys inside them or depend on a plaintext .env: they ask the keyring, already unlocked on my behalf, and start without asking me again. If I leave, the keyring closes; the keys disappear from memory.

It's called pass-encrypt-env. It runs on my Linux Mint and, today, it's for me.

What it is today (and what it isn't yet)

Being clear about the real state is part of the method. A "finished" project also declares its limits.

It is: a personal, working tool that I use daily on my machine.
It isn't: something anyone can install without friction, nor something audited by third parties.
It's coming: in the coming days I'm planning the adaptation — packaging, booting on other distributions and documentation for someone who isn't me — as a separate, planned effort.

There's a deeper reason to separate that adaptation from development: I don't want to call an app "ready" because it passes on my machine. I call it ready when it passes the gates on any machine. It's the same logic as a good test: it doesn't count if it works once, it has to fail when it should.

Why I demand evidence, not feelings

I'm relatively new to the world of agentic AI, though I've spent years managing systems under protocol: access control, minimal exposure, logs. And one discipline I learned there — which prompting reminded me of — is this:

You don't call something solved because it looks solved; you call it solved when you can prove it.

The protocol habit is minimal exposure: you assume something will fail and you design so that, when it fails, it doesn't drag everything else down with it. Applied to software, that becomes a Definition of Done: a short list of conditions that turn "I think it works" into "here's the proof".

In this project, that list has five doors.

The 5 gates

Each gate exists because it prevents a concrete failure, not for completeness.

1) Tests that can fail

I don't care about "I have tests"; I care that they fail when I break something. pass-encrypt-env has 19 tests, and one of the most valuable guards a promise about the disk:

def test_no_plaintext_on_disk(tmp_path):
    path = tmp_path / "vault.enc"
    v, unlocked, _ = _new()
    vault.set_secret(unlocked.payload, "TOKEN", "super-secret-value")
    vault.reseal(v, unlocked.dek, unlocked.payload)
    vault.save_vault(v, path)

    blob = path.read_text()
    assert "super-secret-value" not in blob          # the secret isn't in cleartext
    assert (path.stat().st_mode & 0o777) == 0o600     # and the file isn't readable by others

That test doesn't check that "it works": it checks that the product's promise holds. The failure it prevents is the worst of all: believing you're safe when you aren't.

2) Clean lint

ruff check .

It isn't aesthetics. A green lint removes the dumbest class of error —unused imports, ghost variables, suspicious comparisons— before you even run it. It's noise that never reaches production because it never reaches the commit.

3) Security scan

bandit -q -c bandit.yaml -r src

bandit looks for insecure patterns in the code: misused cryptography, dangerous subprocess, non-cryptographic randomness. In an app whose only job is to store secrets, this gate isn't optional. The failure it prevents is the accidental use of a primitive that looks like the right one.

4) Reproducible CI

The previous three gates run on their own in GitHub Actions, across Python 3.11 and 3.12:

strategy:
  fail-fast: false
  matrix:
    python-version: ["3.11", "3.12"]
steps:
  # ...
  - name: Gate (ruff + bandit + pytest)
    run: ./scripts/ci.sh python

And here's the important part: that ./scripts/ci.sh is the same command I run locally. There's no one truth for my machine and another for the server. The failure this gate prevents is "it works on my machine", which isn't a bug: it's a comfortable lie.

5) End-to-end smoke test

Green unit tests don't guarantee the whole system boots. For that there's a headless smoke test that starts the agent, talks to it over its internal channel and checks the observable behavior:

python3 -m pass_encrypt_env.cli env --if-unlocked >/dev/null 2>&1 || rc=$?
echo "env --if-unlocked (locked) -> exit $rc (expected 3)"
[ "$rc" -eq 3 ]

Even with perfect pieces, the whole may fail to assemble. The smoke test is the gate that looks at the system, not the parts.

The meta-rule

Every gate fits in one command:

./scripts/ci.sh    # this runs locally and this runs in CI. The same truth.

What it protects and what it doesn't

An honestly finished project publishes its ceiling, it doesn't hide it. This is mine:

Threat	Mitigated?
Offline theft of `vault.enc`	Yes — without master + TOTP there's no data
File tampering	Yes — AEAD detects the alteration
Someone without your TOTP	Yes — second factor required
Loss of master or TOTP	Yes — recovery key
A process of the same UID with the vault open	No — ceiling of the prompt-less design
`root` / malware already inside	No — out of scope

That the last row says "No" isn't a weakness: it's a promise you can keep. I'd rather have a small and certain scope than a large and false one.

Technical detail (for those who want the depth)

The "how", for whoever reads this with the engineering in front of them:

Encryption at rest: vault.enc with Argon2id as the key-derivation function (64 MiB, 3 passes, 4 lanes) and AES-256-GCM as authenticated encryption (confidentiality and integrity).
Two-layer wrapping of the data key (DEK): K1 = Argon2id(master) · K2 = HKDF(K1 ‖ totp_secret) unwraps the DEK · K3 = HKDF(recovery_key) keeps a recovery copy. The TOTP secret travels encrypted: without a valid TOTP you don't get the DEK.
Session agent: it listens on a Unix socket at $XDG_RUNTIME_DIR/passenv/, mode 0600 and UID validation of the peer (SO_PEERCRED). It's hardened with PR_SET_DUMPABLE=0 (anti-ptrace), no memory dumps and best-effort mlockall.
passenv CLI: init, set/get/list/rm, export, exec, change-master, backup, restore.
Full threat model in docs/THREAT_MODEL.md, with the prompt-less design's ceiling declared on purpose.

What this changes (Takeaway)

The gate isn't a brake; it's what lets you hit the accelerator without fear. A one-hour, one-commit project doesn't end up "truly finished" by luck: it does because the conditions to call it finished were written before the code.

"I think it works" is a feeling. "Here's the proof" is a project.

The checklist

- [ ] Tests that fail when I break something (not that they exist)
- [ ] Clean lint
- [ ] Security scan with no findings
- [ ] Reproducible CI (same command locally and remotely)
- [ ] End-to-end smoke test green

Over to you

What requirements do you demand from a project before calling it done? Which one would you add to my five gates? And since mine is in a personal-use state: would you publish a tool like this or keep it private until you "adapt" it? Tell me in the comments; I read and reply to everyone.

_{Project license: MIT · No secrets or keys in this post. · Project: github.com/yosoyignicion/pass-encrypt-env · Profile: github.com/yosoyignicion}

Tu backup no sirve si no puedes restaurarlo: el -wal que vació mi base

Wed, 07 Oct 2026 11:39:23 +0000

Tu backup no sirve si no puedes restaurarlo: el `-wal` que vació mi base

Serie: Software auditable — Post 02
Read time: ~10-12 · Etiquetas: python database testing opensource

La confesión: un botón que decía "RESPALDO" y no garantizaba nada

Tengo una regla que me ha costado aprender: desconfía de tus propias features hasta que puedas demostrarlas. Durante un tiempo, Aethernet tuvo un botón grande, verde y tranquilizador que decía RESPALDO .TAR.GZ. Lo pulsabas, salía un archivo, y te ibas a dormir tranquilo. No garantizaba absolutamente nada.

Ese botón es el punto de partida de este post. No porque estuviera roto —creaba un archivo, sí—, sino porque parecía una promesa y era una hipótesis sin comprobar: nunca nadie había restaurado esa copia en otro equipo. Yo no había hecho la única pregunta que importa: ¿funciona cuando la necesitas?

El feedback que lo puso por escrito

Un amigo de la comunidad me devolvió, con ayuda de su modelo agéntico como copiloto, un análisis que resumía el problema mejor que yo. Su idea central cabe en una frase: exportar no es recuperar. Y me propuso un criterio de aceptación concreto: una prueba de recuperación sin conexión, en una máquina limpia, sin acceso a la instalación original, en la que el usuario pueda examinar el historial y generar un informe. "La capacidad de exportación y la capacidad de recuperación son criterios de aceptación distintos."

Tenía razón, y además señalaba el hueco exacto de mi proyecto: no existía un procedimiento de recuperación documentado que cubriera base de datos, configuración y versión de esquema, ni claridad sobre qué claves había que guardar aparte.

Ese comentario convirtió una intuición en una lista de tareas verificables. Lo demás de este post es cómo lo cerré.

El problema, en el código

Mi respaldo era literalmente esto:

# El botón honesto y equivocado
target = paths.data_dir / f"aethernet-backup-{ts}.tar.gz"
with tarfile.open(target, "w:gz") as tar:
    tar.add(paths.db_path, arcname="aethernet.db")   # solo la base

Tiene cuatro problemas, y los cuatro importan:

Solo copia la base. La configuración (my_ssids, alias, retención…) se queda fuera.
No registra la versión del esquema. Al restaurar, no sabrías si la copia es más vieja o más nueva que la app.
Copia un fichero vivo. La base corre en modo WAL; copiar el .db a pelo mientras hay escrituras puede darte un estado incompleto.
No hay restore. Un backup sin restauración es un export con buenos modales.

	Exportar	Recuperar
Pregunta	¿se leen bien los datos?	¿arranco como si nada hubiera pasado?
Máquina	esta, con la app instalada	limpia, sin nada de la original
Prueba	abrir el informe	restaurar y volver a medir

La solución, en cuatro piezas

1) Un paquete que se puede inspeccionar

Un único .tar.gz con tres piezas y un manifiesto legible:

{
  "app": "aethernet",
  "format_version": 1,
  "app_version": "1.3.0",
  "schema_version": 5,
  "created_at": 1759800000.0,
  "db_sha256": "9f2c…",
  "members": ["aethernet.db", "config.toml", "manifest.json"],
  "secrets_required": []
}

Ese secrets_required: [] no es decoración: es una declaración de diseño. No hay claves irrecuperables que guardar aparte. El token de la API se regenera y nunca viaja en el paquete.

2) Copia consistente (y por qué no un `cp`)

Con WAL activo, copiar el fichero de la base es una apuesta. La forma correcta es dejar que SQLite haga la copia:

src = sqlite3.connect(str(db_path))
dst = sqlite3.connect(str(staged_db))
src.backup(dst)          # instantánea consistente, aunque haya un escritor vivo

Connection.backup() fusiona el WAL en un único fichero coherente. Es stdlib: cero dependencias nuevas.

3) Restaurar sin romper nada

El orden importa, y cada paso existe por un fallo real:

Validar antes de escribir — SHA-256 del manifiesto, miembros obligatorios y rutas seguras (nada de ../).
Rechazar el futuro — si la copia usa un esquema más nuevo que el binario, se aborta con un mensaje claro.
Resguardar lo actual — la base presente se copia a aethernet.db.bak-<fecha> antes de tocarla.
Migrar hacia adelante — las migraciones son append-only, así que una copia más antigua se actualiza sola al restaurar.

4) El criterio convertido en test

Aquí está el corazón del asunto. El criterio de aceptación del comentario dejó de ser una opinión y pasó a ser código que puede fallar:

def test_offline_recovery_on_clean_machine(tmp_path):
    # 1. origen: historial + ajustes
    source = _paths(tmp_path, "origin")
    ...  # se guardan escaneos y config
    bundle = create_backup(source, tmp_path / "backup.tar.gz")

    # 2. máquina limpia: otra instalación, sin nada de la original
    clean = _paths(tmp_path, "clean")
    restore_backup(bundle.path, clean)

    # 3. ¿se lee el historial y se genera un informe desde cero?
    repo = Repository(Database(clean.db_path))
    assert repo.wifi_scan_count() == 2
    report = build_report_data(repo, load_settings(clean))
    export(report, "md", clean.report_dir / "recovery.md")

Si este test se pone en rojo, mi backup no existe. No hay interpretación: o recupera, o no recupera.

El bug: el `-wal` que vació mi base restaurada

La primera versión del restore pasaba los tests unitarios… y fallaba el de recuperación real. Restauraba una copia con datos y la base aparecía vacía.

La causa raíz es una lección de SQLite que me llevé grabada: al reemplazar aethernet.db con un os.replace, los ficheros auxiliares aethernet.db-wal y aethernet.db-shm se quedan ahí. Al reabrir la base restaurada, SQLite encuentra un WAL que pertenece a otra base, lo reaplica y sobrescribe tus datos con el estado anterior.

El arreglo va en dos capas, porque el fallo tenía dos puertas:

_remove_sidecars(paths.db_path)          # fuera el -wal/-shm huérfano
os.replace(staged_db, paths.db_path)
_remove_sidecars(paths.db_path)          # y otra vez, por si acaso

…y en el CLI, cerrar la conexión del contexto antes de restaurar, porque no se restaura sobre una base abierta. Añadí un test que restaura sobre una conexión WAL viva para que no vuelva a pasar:

live = Database(paths.db_path); live.migrate()
restore_backup(bundle.path, paths)       # antes: 0 escaneos. ahora: 1.
assert Repository(Database(paths.db_path)).wifi_scan_count() == 1

El otro bug que no ves hasta que cambias de disco

Con el test en verde, probé en un disco distinto y apareció OSError: Invalid cross-device link. El staging vivía en /tmp (a menudo tmpfs) y el os.replace final apuntaba a ~/.local/share, en otro sistema de ficheros: un renombrado no puede cruzar discos.

La corrección es de una línea pero de fondo: el staging vive junto al destino, para que el reemplazo sea un renombrado atómico en el mismo sistema de ficheros. Para la configuración, un shutil.move (que sí sabe cruzar discos). Lo verifiqué con la base en tmpfs y el temporal en disco: recuperación correcta.

Lo que esto cambia (Takeaway)

Un criterio de aceptación no es una opinión: es un test que puede fallar. "Tengo backup" no significa nada hasta que has restaurado en una máquina limpia y has comprobado que el histórico y los informes siguen ahí. Y cuando el criterio se escribe como test, el diseño se ordena solo: aparece el manifiesto, aparece la copia consistente, aparecen los guardarraíles, y aparece el resto de la lista.

Exportar es fácil. Recuperar es el trabajo.

Gracias

Este post no existiría sin el análisis de un amigo de la comunidad, que con IA asistida convirtió una intuición mía en una lista de requisitos verificables. Su pregunta —"¿puedes restaurar en una máquina limpia?"— fue el mejor code review que ha recibido Aethernet. Gracias de verdad.

Conclusión objetiva

La versión 1.3.0 de Aethernet incorpora una recuperación offline demostrable: paquete con base consistente, configuración y manifiesto versionado; restore que valida, resguarda y migra; aethernet restore --verify para comprobar una copia sin escribir; y un test que reproduce la prueba en una instalación limpia. Todo con ruff + mypy --strict (0 errores) + vulture + 173 tests en verde y CI sobre Python 3.11 y 3.12 (sin migración de esquema nueva: el esquema sigue en v5).

No es una promesa de marketing: es un comando que puedes ejecutar.

aethernet backup                    # crea el paquete .tar.gz
aethernet restore --verify copia.tar.gz
aethernet restore copia.tar.gz      # recupérala en esta o en otra máquina

Y tú

¿Cómo verificas hoy que tus copias de seguridad sirven? ¿Alguna vez has restaurado un "backup" que no restauraba nada —y cómo lo descubriste? ¿Qué le exigirías a una herramienta para fiarte de su recuperación? Cuéntamelo en los comentarios; leo y respondo a todo.

_{English version below · El original está en español. If you're an English speaker, scroll down to the translation and tell me how you verify your backups in the discussion. I reply to everyone.}

Your backup is worthless if you can't restore it: the `-wal` that wiped my database

Series: Auditable software — Post 02
Read time: ~10-12 · Tags: python database testing opensource

The confession: a button that said "BACKUP" and guaranteed nothing

There's a rule I learned the hard way: distrust your own features until you can prove them. For a while, Aethernet had a big, green, reassuring button that said BACKUP .TAR.GZ. You pressed it, a file came out, and you went to sleep feeling safe. It guaranteed absolutely nothing.

That button is where this post begins. Not because it was broken —it did create a file— but because it looked like a promise and was really an untested hypothesis: no one had ever restored that copy on another machine. I hadn't asked the only question that matters: does it work when you need it?

The feedback that put it in writing

A friend from the community sent back an analysis —with an agentic model as co-pilot— that framed the problem better than I had. The core idea fits in one sentence: exporting is not recovering. And he proposed a concrete acceptance criterion: an offline recovery test on a clean machine, with no access to the original install, where the user can still inspect the history and generate a report.

His exact words:

"I'd add an offline recovery test: can a user restore a backup on a clean machine —with no access to the original install— and still inspect the history and generate a report? Export capability and recovery capability are distinct acceptance criteria."

He was right, and he also pointed at my project's exact gap: there was no documented recovery procedure covering the database, the configuration and the schema version, nor any clarity about which keys had to be handed over separately. That comment turned an intuition into a list of verifiable tasks. The rest of this post is how I closed it. Thank you, @lisarconnect, for the AI-assisted analysis.

The problem, in code

My backup was literally this:

# The honest, wrong button
target = paths.data_dir / f"aethernet-backup-{ts}.tar.gz"
with tarfile.open(target, "w:gz") as tar:
    tar.add(paths.db_path, arcname="aethernet.db")   # the database only

Four problems, and all four matter:

It only copies the database. The configuration (my_ssids, aliases, retention…) is left out.
It records no schema version. On restore, you wouldn't know if the copy is older or newer than the app.
It copies a live file. The database runs in WAL mode; copying the .db by hand while writes are happening can give you an incomplete state.
There's no restore. A backup without a restore is an export with good manners.

	Export	Recover
Question	do the data read back?	do I boot up as if nothing happened?
Machine	this one, app installed	clean, with nothing from the original
Test	open the report	restore and measure again

The solution, in four pieces

1) A package you can inspect

A single .tar.gz with three parts and a readable manifest:

{
  "app": "aethernet",
  "format_version": 1,
  "app_version": "1.3.0",
  "schema_version": 5,
  "created_at": 1759800000.0,
  "db_sha256": "9f2c…",
  "members": ["aethernet.db", "config.toml", "manifest.json"],
  "secrets_required": []
}

That secrets_required: [] isn't decoration: it's a design statement. There are no irreplaceable keys to hand over. The API token is regenerated and never travels in the package.

2) A consistent copy (and why not `cp`)

With WAL active, copying the database file is a gamble. The right way is to let SQLite make the copy:

src = sqlite3.connect(str(db_path))
dst = sqlite3.connect(str(staged_db))
src.backup(dst)          # consistent snapshot, even with a live writer

Connection.backup() folds the WAL into a single coherent file. It's stdlib: no new dependencies.

3) Restore without breaking anything

Order matters, and every step exists because of a real failure:

Validate before writing — manifest SHA-256, required members and safe paths (no ../).
Reject the future — if the copy uses a newer schema than the binary, it aborts with a clear message.
Protect the present — the current database is copied to aethernet.db.bak-<date> before touching it.
Migrate forward — migrations are append-only, so an older copy upgrades itself on restore.

4) The criterion turned into a test

This is the heart of it. The comment's acceptance criterion stopped being an opinion and became code that can fail:

def test_offline_recovery_on_clean_machine(tmp_path):
    # 1. origin: history + settings
    source = _paths(tmp_path, "origin")
    ...  # scans and config are stored
    bundle = create_backup(source, tmp_path / "backup.tar.gz")

    # 2. clean machine: another install, with nothing from the original
    clean = _paths(tmp_path, "clean")
    restore_backup(bundle.path, clean)

    # 3. does it read the history and generate a report from scratch?
    repo = Repository(Database(clean.db_path))
    assert repo.wifi_scan_count() == 2
    report = build_report_data(repo, load_settings(clean))
    export(report, "md", clean.report_dir / "recovery.md")

If this test goes red, my backup does not exist. No interpretation: either it recovers, or it doesn't.

The bug: the `-wal` that wiped my restored database

The first version of restore passed the unit tests… and failed the real recovery one. It restored a copy with data and the database came up empty.

The root cause is a SQLite lesson I won't forget: when you replace aethernet.db with os.replace, the sidecar files aethernet.db-wal and aethernet.db-shm stay behind. When SQLite reopens the restored database, it finds a WAL that belongs to another database, replays it, and overwrites your data with the previous state.

The fix comes in two layers, because the failure had two doors:

_remove_sidecars(paths.db_path)          # drop the orphan -wal/-shm
os.replace(staged_db, paths.db_path)
_remove_sidecars(paths.db_path)          # and again, just in case

…and in the CLI, closing the context connection before restoring, because you don't restore over an open database. I added a test that restores over a live WAL connection so it never happens again:

live = Database(paths.db_path); live.migrate()
restore_backup(bundle.path, paths)       # before: 0 scans. now: 1.
assert Repository(Database(paths.db_path)).wifi_scan_count() == 1

The other bug you only see when you change disks

With the test green, I tried another disk and hit OSError: Invalid cross-device link. The staging lived in /tmp (often tmpfs) and the final os.replace pointed at ~/.local/share, on a different filesystem: a rename can't cross disks.

The fix is a one-liner with real weight: staging lives next to the destination, so the replacement is an atomic rename on the same filesystem. For the config, a shutil.move (which does cross disks). I verified it with the database on tmpfs and the temp on disk: recovery works.

What this changes (Takeaway)

An acceptance criterion isn't an opinion: it's a test that can fail. "I have a backup" means nothing until you've restored it on a clean machine and checked that the history and the reports are still there. And once the criterion is written as a test, the design sorts itself out: the manifest appears, the consistent copy appears, the guardrails appear, and so does the rest of the list.

Exporting is easy. Recovering is the job.

Thanks

This post wouldn't exist without the analysis from a friend in the community, who —with AI assistance— turned an intuition of mine into a list of verifiable requirements. His question —"can you restore on a clean machine?"— was the best code review Aethernet has ever received. @lisarconnect, thank you, sincerely.

Objective conclusion

Version 1.3.0 of Aethernet ships a demonstrable offline recovery: a package with a consistent database, the configuration and a versioned manifest; a restore that validates, protects and migrates; aethernet restore --verify to check a copy without writing; and a test that reproduces the clean-machine trial. All of it with ruff + mypy --strict (0 errors) + vulture + 173 tests green and CI on Python 3.11 and 3.12 (no new schema migration: the schema is still v5).

It isn't a marketing promise: it's a command you can run.

aethernet backup                    # create the .tar.gz package
aethernet restore --verify copy.tar.gz
aethernet restore copy.tar.gz       # recover it here or on another machine

Over to you

How do you verify today that your backups actually work? Have you ever restored a "backup" that restored nothing —and how did you find out? What would you demand from a tool before trusting its recovery? Tell me in the comments; I read and reply to everyone.

_{Project license: MIT · No secrets or keys in this post. · Projects: github.com/yosoyignicion · Aethernet code: github.com/yosoyignicion/Aethernet · Release v1.3.0}

Local-first no es una moda: es una decisión de arquitectura (4 criterios, caso real)

Tue, 06 Oct 2026 17:42:26 +0000

Local-first no es una moda: es una decisión de arquitectura (4 criterios, caso real)

Serie: Software auditable — Post 01
Read time: ~8 min · Etiquetas: opensource architecture python security

El escáner de red que sube tus SSID a la nube (y por qué eso ya es una decisión de arquitectura)

Instala la típica app de "analiza tu WiFi" y lee la letra pequeña: cuenta obligatoria, sincronización en la nube, un SDK de analítica y, en el mejor de los casos, un interruptor de "privacidad" apagado por defecto. El problema no es que use la red. El problema es que no puedes auditar qué sale de tu equipo, y sin eso no hay confianza: hay fe.

Yo construí lo contrario. Aethernet es un instrumento local para auditar tu WiFi doméstico: pasivo por defecto, sin nube, sin telemetría y honesto cuando su hardware no llega. Y lo que hace que sea local-first no es un eslogan en la portada: es un conjunto de decisiones de arquitectura que se pueden verificar. En este post las reduzco a cuatro criterios que aplico antes de etiquetar cualquier proyecto como local-first. Si falla uno, no lo es.

Quién escribe esto

Soy Ignacio Badenes (IgnicionDev), técnico de sistemas e informática aplicada desde Castellón. Vengo del soporte y del control de accesos, donde el registro y la mínima exposición no son filosofía: son el trabajo. Aethernet nació de ahí —auditar tu propia red sin regalársela a nadie— y es el primero de los proyectos que uso para explicar cómo diseño software que se puede leer, ejecutar y deshacer. Si esto te suena, el post anterior sobre mi setup de agente barato es el contexto.

La tesis: "sin nube" es fácil de decir y caro de sostener

Cualquiera puede escribir privacy-first en una landing. Sostenerlo exige renunciar a atajos cómodos: el servicio que ya te da DNS, el CDN para las fuentes, el modelo en la nube para "lo difícil", la nube como excusa para no diseñar degradación. El local-first no es un interruptor que se activa al final; es una restricción que se acepta al principio y que condiciona cada capa.

Mi definición operativa cabe en cuatro criterios. No son opiniones: son cosas que puedo comprobar en el repositorio.

Los 4 criterios para decidir si un proyecto puede ser local-first

1. Sin red saliente (no outbound)

La aplicación funciona sin conexión, no como "modo demo": como modo normal. Sin llamadas a servidores de terceros, sin autenticación remota, sin telemetría. En Aethernet, la propia interfaz sirve sus fuentes e iconos desde el disco (/ae-fonts): ni siquiera pide una tipografía a Google. Si algo necesita la red, no es local-first; es cloud con buenos modales.

2. Sin claves ni dependencia de un proveedor

Si para arrancar necesitas una API_KEY o un registro, tu función principal es un servicio ajeno y tú solo eres el envoltorio. Local-first significa que el proyecto es dueño de su función: Aethernet no pide ninguna clave, sus dependencias de ejecución están vacías y lo que aporta (medir, analizar, informar) ocurre en tu máquina.

3. Degradación elegante (y honesta)

Todo es opcional y el sistema sigue vivo cuando falta algo. Sin iw no hay monitor mode; sin scapy o root, no hay ARP activo; sin nmcli, no hay escaneo. En lugar de fallar en bloque, se baja de prestaciones y se dice la verdad: si un dato no se puede medir, se marca n/d en vez de inventarlo. La honestidad también es arquitectura.

4. Datos tuyos, en rutas tuyas

Los datos viven en tu equipo, bajo tus rutas, en un formato que puedes inspeccionar. En Aethernet: config en ~/.config/aethernet/config.toml, base SQLite en ~/.local/share/aethernet/aethernet.db e informes exportables a Markdown, JSON, CSV o PDF. Sin secuestro de datos y sin lock-in.

El caso real: cómo se traduce en capas

Aethernet no es un script con botones pegados. Es una arquitectura en capas donde CLI, API local y la interfaz "AETHERNET" consumen exactamente los mismos servicios:

Capa	Paquete	Responsabilidad
Core	`aethernet.core`	Lógica pura y testeable: parseo `nmcli`/`iw`, ARP, reglas, salud, espectro, OUI.
Datos	`aethernet.data`	SQLite con WAL, migraciones e histórico.
Servicio	`aethernet.service`	Daemon de vigilancia; nunca dibuja.
Alertas	`aethernet.alerts`	Cola, deduplicación, filtros y `notify-send`.
Informes	`aethernet.report`	Exportadores Markdown / JSON / CSV / PDF.
API	`aethernet.api`	FastAPI local opcional, protegida por token.
UI	`aethernet.ui`	UI NiceGUI; solo lee la base y consume servicios.

Dos decisiones hacen que esto sea comprobable:

Los parsers son funciones puras. Se testean con texto real de nmcli e iw sin hardware. Por eso puedo desarrollar en cualquier máquina y confiar en la CI.
Las dependencias pesadas son extras opcionales. El pyproject.toml declara dependencies = []; scapy, fastapi, reportlab, nicegui se instalan solo si los quieres (pip install -e '.[lan,api,reports,ui]'). El núcleo arranca sin nada.

El flujo por defecto es pasivo: se escucha sin inyectar tráfico ni cortar tu WiFi. Lo activo (ARP con scapy) y la captura requieren root y se habilitan a propósito. El propio proyecto te da un veredicto honesto de lo que tu equipo puede y no puede hacer:

aethernet doctor        # veredicto honesto de tu hardware
aethernet scan --no-lan # escaneo pasivo
aethernet analyze       # motor de reglas sobre el último escaneo
aethernet networks --open
aethernet daemon start  # vigilancia continua
aethernet api           # API local opcional (token propio)

Y el límite ético va escrito en la arquitectura, no en las FAQs: el modo activo está pensado para tu red, y auditar redes ajenas sin permiso es, además de mala idea, ilegal.

El gate de calidad (por qué me lo creo)

Local-first sin ingeniería es un render. Así que el proyecto pasa un gate duro antes de considerarse terminado: ruff + mypy --strict (0 errores) + vulture + pytest, con más de 150 tests y CI en GitHub Actions sobre Python 3.11 y 3.12. Además hay un smoke test E2E de la UI en modo headless sobre sus rutas principales.

./scripts/ci.sh      # ruff + mypy --strict + vulture + pytest
./scripts/smoke.sh   # E2E UI headless

El tipado estricto no es decoración: los parsers reciben texto que puede venir de mil versiones de nmcli, y el sistema de tipos me obliga a contemplar los casos raros antes de ejecutar. Menos fe, más contrato.

Lo honesto: qué gano y qué pierdo con local-first

Gano soberanía y auditabilidad: control total de mis datos, cero telemetría, cero lock-in y la tranquilidad de un sistema que puedo leer y deshacer. Puedo medir, exportar y borrar sin pedir permiso a nadie.

Pierdo comodidad y techo de función: mantener parsers puros, degradación elegante y extras opcionales es más trabajo que llamar a un servicio. Lo que en la nube sería una fetch aquí es diseño de capas, tests y migraciones append-only. Y hay funciones que solo tienen sentido con servidor (histórico agregado, análisis comparativo entre usuarios) y que renuncio a tener.

Para mí el intercambio es ventajoso: prefiero un instrumento modesto que entiendo a una caja negra potente que no puedo auditar. Es la misma disciplina de fondo del resto de mi trabajo: si no lo puedo leer, ejecutar y probar, no me sirve.

Takeaway

El local-first no se declara en la landing; se demuestra en la arquitectura. Sin red saliente, sin claves de terceros, con degradación elegante y con los datos en tus rutas. Si tu app no puede arrancar sin conexión, no es local-first: es nube con buenos modales.

Y tú, ¿qué criterio añadirías para decidir si un proyecto puede ser local-first? ¿Cuál fue la última herramienta de red que abriste solo para ver a dónde enviaba tus datos? Cuéntamelo en los comentarios; leo y respondo a todo.

_{English version below · El original está en español. Si eres angloparlante, baja a la traducción y cuéntame tu criterio en la discusión. Respondo a todos.}

Local-first isn't a fad: it's an architecture decision (4 criteria, a real case)

Series: Auditable software — Post 01
Read time: ~8 min · Tags: opensource architecture python security

The network scanner that uploads your SSIDs to the cloud (and why that's already an architecture decision)

Install a typical "analyze your WiFi" app and read the fine print: mandatory account, cloud sync, an analytics SDK and, at best, a "privacy" toggle that ships off by default. The problem isn't that it uses the network. The problem is that you can't audit what leaves your machine, and without that there is no trust: there is faith.

I built the opposite. Aethernet is a local instrument to audit your home WiFi: passive by default, no cloud, no telemetry and honest when its hardware can't keep up. And what makes it local-first isn't a slogan on a landing page: it's a set of architecture decisions you can verify. In this post I reduce them to four criteria I apply before labelling any project local-first. If one fails, it isn't.

Who's writing this

I'm Ignacio Badenes (IgnicionDev), an IT technician from Castellón, Spain. I come from support and access control, where logging and minimal exposure aren't philosophy: they're the job. Aethernet was born there —auditing your own network without giving it away to anyone— and it's the first of the projects I use to explain how I design software you can read, run and undo. If that resonates, my previous post about my cheap agent setup is the context.

The thesis: "no cloud" is easy to say and expensive to sustain

Anyone can write privacy-first on a landing page. Sustaining it means giving up convenient shortcuts: the service that gives you DNS, the CDN for fonts, the cloud model for "the hard part", the cloud as an excuse not to design for degradation. Local-first isn't a switch you flip at the end; it's a constraint you accept at the beginning that shapes every layer.

My working definition fits in four criteria. They aren't opinions: they're things I can check in the repository.

The 4 criteria to decide whether a project can be local-first

1. No outbound network

The application works offline, not as a "demo mode": as the normal mode. No calls to third-party servers, no remote auth, no telemetry. In Aethernet the UI itself serves its fonts and icons from disk (/ae-fonts): it doesn't even request a typeface from Google. If something needs the network, it isn't local-first; it's cloud with good manners.

2. No keys and no provider dependency

If starting up requires an API_KEY or a sign-up, your core function is someone else's service and you're just the wrapper. Local-first means the project owns its function: Aethernet asks for no key, its runtime dependencies are empty, and what it delivers (measure, analyze, report) happens on your machine.

3. Graceful degradation (and honesty)

Everything is optional and the system stays alive when something is missing. Without iw there's no monitor mode; without scapy or root, no active ARP; without nmcli, no scan. Instead of failing as a whole, it scales back and tells the truth: if a value can't be measured, it's marked n/d instead of invented. Honesty is architecture too.

4. Your data, in your paths

Data lives on your machine, under your paths, in a format you can inspect. In Aethernet: config in ~/.config/aethernet/config.toml, SQLite database in ~/.local/share/aethernet/aethernet.db and reports exportable to Markdown, JSON, CSV or PDF. No data hostage-taking and no lock-in.

The real case: what it looks like in layers

Aethernet isn't a script with glued-on buttons. It's a layered architecture where the CLI, the local API and the "AETHERNET" UI consume exactly the same services:

Layer	Package	Responsibility
Core	`aethernet.core`	Pure, testable logic: `nmcli`/`iw` parsing, ARP, rules, health, spectrum, OUI.
Data	`aethernet.data`	SQLite with WAL, migrations and history.
Service	`aethernet.service`	Watch daemon; never draws.
Alerts	`aethernet.alerts`	Queue, dedup, filters and `notify-send`.
Reports	`aethernet.report`	Markdown / JSON / CSV / PDF exporters.
API	`aethernet.api`	Optional local FastAPI, token-protected.
UI	`aethernet.ui`	NiceGUI UI; only reads the DB and consumes services.

Two decisions make this verifiable:

Parsers are pure functions. They're tested against real nmcli and iw output without hardware. That's why I can develop on any machine and trust CI.
Heavy dependencies are optional extras. pyproject.toml declares dependencies = []; scapy, fastapi, reportlab, nicegui are installed only if you want them (pip install -e '.[lan,api,reports,ui]'). The core runs with nothing.

The default flow is passive: it listens without injecting traffic or cutting your WiFi. Active ARP scanning (scapy) and capture require root and are enabled on purpose. The project itself gives you an honest verdict of what your gear can and can't do:

aethernet doctor        # honest verdict of your hardware
aethernet scan --no-lan # passive scan
aethernet analyze       # rule engine over the last scan
aethernet networks --open
aethernet daemon start  # continuous watch
aethernet api           # optional local API (its own token)

And the ethical limit is written into the architecture, not the FAQs: active mode targets your network, and auditing networks you don't own is, besides a bad idea, illegal.

The quality gate (why I trust it)

Local-first without engineering is a mockup. So the project passes a hard gate before it counts as done: ruff + mypy --strict (0 errors) + vulture + pytest, with 150+ tests and GitHub Actions CI on Python 3.11 and 3.12. There's also a headless end-to-end UI smoke test over its main routes.

./scripts/ci.sh      # ruff + mypy --strict + vulture + pytest
./scripts/smoke.sh   # headless E2E UI

Strict typing isn't decoration: the parsers take text that may come from a thousand versions of nmcli, and the type system forces me to handle the odd cases before running anything. Less faith, more contract.

The honest part: what I gain and what I lose with local-first

I gain sovereignty and auditability: full control of my data, zero telemetry, zero lock-in and the peace of mind of a system I can read and undo. I can measure, export and delete without asking anyone.

I lose convenience and a feature ceiling: keeping pure parsers, graceful degradation and optional extras is more work than calling a service. What would be a fetch in the cloud is here layer design, tests and append-only migrations. And some features only make sense with a server (aggregated history, cross-user comparison) and I give them up.

For me the trade is worth it: I'd rather have a modest instrument I understand than a powerful black box I can't audit. It's the same underlying discipline as the rest of my work: if I can't read it, run it and test it, it's no good to me.

Takeaway

Local-first isn't declared on a landing page; it's proven in the architecture. No outbound network, no third-party keys, graceful degradation and your data in your paths. If your app can't boot without a connection, it isn't local-first: it's cloud with good manners.

So what about you? Which criterion would you add to decide whether a project can be local-first? What was the last network tool you opened just to see where it was sending your data? Tell me in the comments; I read and reply to everyone.

_{Licencia de los proyectos mencionados: MIT · Sin secretos ni claves en este post. · Proyectos: github.com/yosoyignicion · Código de Aethernet: github.com/yosoyignicion/Aethernet}

We Promise Transparency. Not the "Liquid Glass" Kind.

Tue, 06 Oct 2026 11:10:46 +0000

Let's get the joke out of the way first, because I can already see someone's fingers hovering over the comment box: no, when we talk about "transparency" here, we are not launching a translucent UI skin with rounded corners and a marketing deck about "depth" and "light." Nobody's redesigning your icons to look like they're floating in a glass of water. Apple can keep that one. Transparency, as we mean it, isn't about making things look like glass. It's about making sure there's nothing opaque left to hide behind in the first place.

Transparency Is the Rarest Feature in Modern Software

Here's the uncomfortable observation that started all of this: almost nothing you run today will actually tell you what it's doing. You call a function, and underneath it, a dozen layers you never asked for quietly make decisions on your behalf — a runtime schedules something, an allocator decides where your data actually lives, a framework "helpfully" retries a failed call you didn't know could fail, a standard library wraps three other standard libraries you've never heard of. Most of the time that's a perfectly reasonable trade. Most software genuinely benefits from not making every engineer re-derive memory management from first principles on a Tuesday.

But somewhere along the way, "we abstracted this for your convenience" quietly turned into "we abstracted this so thoroughly that nobody on the team, including us, can tell you with certainty what your program actually does when it touches the kernel." That's not convenience anymore. That's a black box with a changelog. And an entire generation of developers has been trained to treat "it works, don't ask why" as an acceptable final answer, because asking why usually means descending through four more layers of someone else's unexamined assumptions.

Developer transparency, the version we actually care about, is the opposite stance, stated plainly: no hidden magic, no invisible runtime quietly squatting on your CPU cycles like a tenant you never agreed to lease to, and no stack of "convenience" layers standing between your code and the hardware that's supposed to be running it. You should be able to point at any behaviour your program exhibits and trace it to a decision — yours, specifically — not to an abstraction that made the call for you somewhere you'll never see.

This is where Gloria comes in, because it's the sharpest, most literal expression of that idea we've built so far.

What Transparency Actually Looks Like in Gloria

When you write something in Gloria, you know exactly what instruction goes to the CPU, exactly what memory gets mapped, and exactly which register is holding your data at any given moment. You are not down on one knee, hat in hand, begging a heavyweight framework or a sprawling C standard library to please do the thing for you. You own the execution, start to finish, with nobody else's fingerprints on it.

From a Linux perspective, Gloria treats the kernel as its one and only direct interface. No linking against glibc. No standard C startup routine quietly initializing half a universe of state before your main function has even had the decency to run. Gloria generates self-contained, raw ELF64 binaries for AMD64, and that's genuinely all that's in there.

When your code needs to open a socket, allocate memory, or spin up a bit of lightweight concurrency, it doesn't go politely knocking on some third-party wrapper function's door and waiting to be let in. It loads the syscall number straight into RAX, lays out the arguments exactly per the System V AMD64 ABI, and hits the kernel directly with a syscall instruction. No chaperone. No translation layer quietly editorializing your request on the way through. The resulting binaries stay under 9KB, because there is precisely zero runtime bloat riding along for the trip. Put that next to the multi-megabyte "hello world" some modern frameworks ship by default, and you start to get an honest sense of exactly how much weight we've actually cut.

Why This Needed to Exist at All

Here's the pitch, cynicism included at no extra charge: modern systems engineering has gone soft. Not incompetent — soft. Comfortable. Padded on every side with abstractions that exist specifically to protect you from having to understand what your own program is doing. Most software doesn't need to care which register holds a value. This project exists for the software that does, and for the engineers who'd rather know than be protected from knowing.

We wanted something that gives you the raw control and speed of C, the type expressiveness and memory-safety thinking of Rust, and the dead-simple concurrency model of Go — minus the overhead each of those languages still quietly carries around. This is built for the specific kind of developer who needs to wring every last drop of performance out of a box, who's writing ultra-fast microservices, custom network infrastructure, or logic that has to survive on genuinely minimal resources, where every kilobyte and every CPU cycle is a line item somebody's actually tracking, not an abstraction nobody bothers to measure.

The Roadmap, Stated Without the Usual Hedging

Our self-hosting plan is straightforward and, I'll admit, a little uncompromising. Right now, the ForgeZero compiler, fz, is written in Go. That's a deliberate choice, not a compromise we're quietly hoping nobody notices — Go let us bootstrap the language fast, iterate on syntax without a chicken-and-egg problem slowing every decision down, and shake the remaining edge cases out of the lexer, parser, and semantic checker while the ground was still allowed to move under our feet.

But Go is a bridge, not a destination. The actual milestone the entire Gloria ecosystem is being built toward is full self-hosting. We're building out the language constructs, inline assembly support, and memory primitives specifically so that Gloria can eventually compile its own compiler, from scratch, with nothing borrowed. The day fz is rewritten in pure Gloria is the day we cut the last external dependency loose entirely — and the day this architecture stops being "an interesting idea with training wheels" and starts being something you can point at and say, flatly, that it's ready for serious production.

That's the whole philosophy, really, scaled up from one register to an entire compiler: nothing in this stack should exist that we can't fully explain, and nothing should run that isn't accountable to someone who actually understands it.

Watch It Happen Instead of Reading About It Later

If any of this is the kind of problem that genuinely interests you — not the polished retrospective six months from now, but the actual process, bugs included — we post it all in close to real time on our Telegram channel, @forgezeroteam. Build updates, broken things, fixed things, syntax decisions argued out loud before they're final. It's faster and considerably more honest than waiting for the cleaned-up version to show up here.

No liquid glass. No rounded corners pretending to be depth. Just a binary you can actually read, a register you can actually name, and a compiler that, one day soon, won't owe its existence to anything but itself.

ForgeZero and Gloria: A Honest Look at a New Systems Language

Mon, 05 Oct 2026 19:59:23 +0000

Hi everyone. In this article I want to talk about ForgeZero and their own programming language, Gloria. I'll keep the review honest, with no exaggeration in either direction.
Before getting into it, I want to say a separate thank you to my mentor and teacher, Alex Voste, who introduced me to platforms like CoderLegion and has given me an enormous amount of knowledge along the way. It's largely thanks to him that I learned Linux properly and finally settled on my path in IT.
Why this project stands out
If you assumed that building your own systems language in 2026 is either a romantic exercise or a waste of time, ForgeZero is worth a second look. Gloria isn't another toy DSL bolted on top of Python. It's a serious, fully self-hosted compiler that emits native AMD64 binaries only a few hundred bytes in size, with no dependency on a Go runtime or libc.
What actually caught my attention

Zero-allocation by default.
There's no bloated heap sitting behind the scenes. Gloria talks to the kernel directly through syscalls (mmap, sys_open, write), which gives you tight, explicit control over memory from the very first line.
Deliberate architectural choices.
A few design decisions here show real engineering taste: >> chaining with register passing, built-in |? guard operators for safe short-circuiting, native vectors implemented with REP MOVSQ, and hash tables built on open addressing. None of this feels bolted on — it reads like a language designed around how the hardware actually works.
Coroutines written in pure assembly.
The project natively supports cooperative green threads (fibers), complete with its own register-level context switching and 4KB mmap-backed stacks. That's not a small feat to get right, and it shows a level of commitment most "systems-adjacent" languages don't bother with.
My verdict
ForgeZero and Gloria represent a genuinely substantial piece of work for anyone who still cares about true bare-metal systems programming. The language addresses a real pain point for engineers: it offers a clean, readable syntax while preserving full hardware predictability and extremely compact binaries. You don't often get both at once.
This is a project worth following for anyone who misses the days when code was written for speed, not for how many gigabytes of RAM it could comfortably consume.

Mi setup de agente barato: OpenCode + DeepSeek por céntimos (feat. IgnicionDev)

Mon, 05 Oct 2026 15:40:22 +0000

Mi setup de agente barato: OpenCode + DeepSeek por céntimos (feat. IgnicionDev)

Serie: My cheap Setup feat IgnicionDev — Post 00
Read time: ~8 min · Etiquetas: ai aiagents devtools mcp

Abrí un agente que cuesta céntimos y me devolvió control, no ruido

La mayoría de la conversación sobre agentes de código empieza por la potencia: el modelo más grande, el benchmark más alto, la demo más vistosa. Mi problema era el contrario. Yo no necesitaba más inteligencia: necesitaba algo que costara céntimos, que no inundara la terminal y cuyo resultado pudiera auditar línea a línea. Si no puedo leer y ejecutar lo que el agente produce, no me sirve: trabajo con dinero, facturas y datos que deben cuadrar.

Así que me monté un agente barato —OpenCode + DeepSeek Flash— y lo rodeé de disciplina: memoria persistente, reglas de gasto de tokens, permisos estrictos y verificaciones reales. Este post es el "cómo", con números, y termina con diez cosas concretas que puedes hacer hoy con un setup así. No es magia; es ingeniería honesta.

Quién escribe esto

Soy Ignacio Badenes (IgnicionDev), técnico de sistemas e informática aplicada desde Castellón, España. Vengo del soporte y del control de accesos: protocolos, registros, sangre fría cuando algo falla. Ese hábito lo aplico ahora al software que construyo y publico —Aethernet (auditoría WiFi local, 146 tests), LocalGrant-Finder (subvenciones del BOE con búsqueda híbrida), SystemBridge-AI (facturas a libro contable, dinero en Decimal) y AssetShrink (C++17, imágenes en local)—. Todos con tests, CI y licencia. Si una herramienta no es auditable, no la publico. Con mi agente, igual.

La tesis: la disciplina sustituye a la potencia

Un modelo barato no te obliga a obtener resultados baratos. Te obliga a dejar de improvisar. El truco no está en el modelo: está en gastar pocos tokens sin perder precisión. En DeepSeek Flash el precio se reparte así:

coste = input_fresco × $0,14/M  +  input_cacheado × $0,0028/M  +  output × $0,28/M

El input cacheado cuesta 50 veces menos que el fresco, y el output es la partida más cara. Por eso ataqué los tres frentes:

System prompt y herramientas mínimas (menos tokens fijos por petición).
Máximo reúso de caché (mismo prefijo, sin UUIDs aleatorios que la rompen).
Output controlado (respuestas cortas o JSON, nada de párrafos de relleno).

En mi escenario de trabajo, esto reduce el gasto ~82 %; una vez la caché está caliente, el coste marginal por petición cae a una fracción de céntimo. No es "gratis", pero se acerca. Y lo importante: sigue siendo correcto porque yo pongo la disciplina donde el modelo no llega.

El setup: OpenCode + DeepSeek

Mi modelo es deepseek/deepseek-v4-flash, servido por un proveedor compatible con OpenAI y con la caché activada:

{
  "model": "deepseek/deepseek-v4-flash",
  "provider": {
    "deepseek": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "setCacheKey": true },
      "models": {
        "deepseek-v4-flash": {
          "reasoning": true,
          "interleaved": { "field": "reasoning_content" }
        }
      }
    }
  }
}

Tres decisiones que marcan la diferencia a lo largo del día:

Compactación automática (auto, prune, reserved: 5000): la conversación se poda sola y no arrastro historial gigante.
Límite de salida de herramientas (max_lines: 200, max_bytes: 8192): un npm install no me escupe 200 líneas a la cara; si trunca, reejecuto acotado.
Permisos estrictos (webfetch: deny, plan en solo lectura): el agente no navega ni escribe donde no debe sin que yo lo apruebe.

Sobre todo esto manda un archivo: mi AGENTS.md. No es una lista de deseos, es un router de trabajo con protocolo (entender → planear → cambio pequeño → verificar → revisar), una Definition of Done honesta (typecheck, tests, lint, diff revisado) y reglas de gasto. El modelo es barato; el criterio no.

Memoria y contexto: que no repita lo que ya sabe

Un agente sin memoria es un becario con amnesia: cada sesión empieza de cero y vuelve a pagar por lo mismo. Yo uso el plugin engram + zerotoken: memoria tipada en SQLite con FTS5, auto-guardado de errores→solución, decisiones de arquitectura y compactaciones, e inyección de solo 2 memorias / 600 tokens en cada arranque. Traducido: en vez de arrastrar 50 000 tokens de historial, inyecto lo justo.

A eso le sumo Context7: cuando pregunto por una API o versión concreta, trae la documentación real y la cacheo como memoria. La próxima vez no vuelvo a consultarla ni el modelo la alucina. Documentación viva, cero repetición.

My.OpenCode.Conf: el proyecto privado que da forma a todo

Aquí está la pieza que mucha gente no ve. Mi configuración no es un opencode.json suelto: es un proyecto de GitHub privado llamado My.OpenCode.Conf, parte de mi aprendizaje y mi forma de trabajar. Es un bundle de tres subproyectos independientes que se hablan por un protocolo abierto (MCP):

Subproyecto	Qué aporta	Hecho con
`skill-matrix`	+240 skills en formato `SKILL.md` (técnicas y de diseño) que el agente carga bajo demanda por triggers	Markdown
`second-termux-v2`	Servidor MCP que lanza jobs en background y devuelve una sola línea de estado en vez de inundar la TUI	TypeScript (ESM)
`engram+zerotoken`	El plugin de memoria persistente (FTS5) y la política de ahorro de tokens	TypeScript (Bun)

Los une un prompt maestro: en vez de mantener un install.sh frágil, el propio agente se autoconfigura (detecta el sistema operativo y adapta los comandos). Y, para mí, lo mejor de su diseño: es reversible. Se desinstala limpio, sin lock-in, sin telemetría y sin tocar lo que ya tenías. El repo es privado por ahora —lo enseño, lo explico y respondo dudas—, pero la lección es pública: una buena config es código que se puede leer, verificar y deshacer.

Las herramientas que lo conectan (MCP y plugins)

chrome-devtools (headless) — un navegador real que el agente maneja: navegar, extraer, y hacer auditorías Lighthouse sin abrir una ventana.
github — issues, PRs y acciones desde la propia conversación.
sqlite — consultas sobre mi base de datos local de trabajo.
context7 — documentación de librerías en vivo.
human-followup.ts — plugin propio que usa notify-send: cuando el agente pide datos, necesita un permiso o termina una navegación, me salta una notificación de escritorio. Puedo dejar de mirar la terminal.
Subagentes (explore, general) — para repartir exploración y trabajo pesado sin contaminar mi contexto.

Crear tu propio MCP para publicar sin salir del agente

El ejemplo más honesto de "herramienta propia" es este mismo post. En vez de copiar y pegar texto en el navegador, escribí un MCP local para Coder Legion en Node ESM sin dependencias (~300 líneas): una conversación JSON-RPC por stdio contra la API REST de la plataforma. El agente lista, busca, comenta y redacta en borrador desde la misma sesión en la que programa.

Lo interesante no es el camino feliz, son los bordes:

La API no tiene campo draft. El borrador se implementa con POST /posts seguido de POST /posts/{id}/hide: el post nace invisible salvo para el autor y los mods. Publicar es POST /posts/{id}/reshow.
El MCP nunca publica solo. cl_create_post valida y crea siempre oculto; si el hide falla, devuelve el id y avisa de que el post quedó público para corregirlo de inmediato. La publicación real solo ocurre con cl_publish_post, y esa llamada la decido yo.
Edición incremental. cl_edit_post hace read-modify-write en servidor: append, prepend, insert_before, insert_after o replace sobre un ancla literal. Añado una sección sin reenviar 19 KB de markdown, con dry_run para previsualizar antes de guardar.

Es el patrón que repito en todo: la API hace lo mínimo, el MCP añade la disciplina (draft-first, revisión humana) y el agente se queda con lo mecánico. Si algo no lo puedo auditar o deshacer, no lo automatizo.

De la TUI al Desktop en Linux (ya migrado)

Hasta hace poco corría todo en la TUI (v1.18.34). Acabo de dar el salto a la versión Desktop en Linux Mint 22.3, instalando el .deb de la release oficial. En Linux no hay cask de Homebrew —eso es solo macOS—; lo correcto aquí son los paquetes de la release (.deb, .rpm o .AppImage). El binario de escritorio registra su lanzador en el menú de aplicaciones, así que paso de "abrir una terminal y teclear" a "abrir una app". Misma configuración, misma memoria, mismo agente; solo cambia el envoltorio. Si tienes dudas con la instalación en Linux, te lo cuento con detalle en los comentarios.

Diez cosas que mi agente barato hace hoy

Ejemplos reales, no humo:

Diagnosticar un repo: señalarlo, que reproduzca, minimice y proponga un plan de fallos con la skill diagnose.
Escribir tests primero: ciclo red-green-refactor con tdd, no tests de relleno.
Revisar un diff: auditoría en paralelo de estándares y de especificación con review.
Auditoría web real: levantar el navegador headless y ejecutar un Lighthouse sobre mi página.
Consultar docs actualizadas con Context7 y guardarlas en Engram para no repetir la consulta.
Recordar un fix entre sesiones: "esto ya me falló", y el error→solución está ahí.
Lanzar un build largo en background y recibir una sola línea de estado (done) en vez de 200 líneas.
Refactorizar con plan: request-refactor-plan descompone en commits pequeños y seguros.
Crear una skill propia con write-a-skill cuando repito un patrón.
Delegar exploración de un codebase desconocido a un subagente mientras sigo trabajando.

Lo honesto: qué gano y qué pierdo

Gano: coste de céntimos, memoria que persiste, permisos que respeto, cero telemetría y la tranquilidad de un sistema que puedo auditar y deshacer. Pierdo: techo de razonamiento —un modelo Flash no es un modelo de frontera— y comodidad. Un agente barato no piensa por ti; te obliga a decirle exactamente qué quieres y a verificar el resultado. Para mí, ese intercambio es una ventaja: es la diferencia entre "confío porque lo leí" y "confío porque me lo dijo un modelo caro".

Takeaway

No necesitas el modelo más potente para producir software serio: necesitas economía de tokens, memoria y disciplina. Con un modelo barato bien dirigido, el límite deja de ser el precio y pasa a ser tu criterio.

¿Y tú? ¿Qué modelo barato usas —o usarías— y cómo compensas sus límites? Cuéntamelo en los comentarios; leo y respondo a todo.

_{English version below · The original is in Spanish. If you're an English speaker, jump to the translation and let me know your setup in the discussion. I reply to everyone.}

My cheap Setup: running OpenCode + DeepSeek for cents (feat. IgnicionDev)

Series: My cheap Setup feat IgnicionDev — Post 00
Read time: ~8 min · Tags: ai aiagents devtools mcp

I built an agent that costs cents and gave me control back, not noise

Most talk about coding agents starts with raw power: the biggest model, the highest benchmark, the flashiest demo. My problem was the opposite. I didn't need more intelligence — I needed something that costs cents, doesn't flood my terminal, and produces output I can audit line by line. If I can't read and run what the agent produces, it's useless to me: I work with money, invoices and data that has to add up.

So I built a cheap agent —OpenCode + DeepSeek Flash— and wrapped it in discipline: persistent memory, token-spend rules, strict permissions and real verification. This post is the "how", with numbers, and it ends with ten concrete things you can do today with a setup like this. No magic; just honest engineering.

Who's writing this

I'm Ignacio Badenes (IgnicionDev), an IT technician from Castellón, Spain. I come from support and access control: protocols, logs, staying calm when things break. I now apply that habit to the software I build and publish —Aethernet (local WiFi auditing, 146 tests), LocalGrant-Finder (Spanish official-gazette grants with hybrid search), SystemBridge-AI (invoices into a balanced ledger, money as Decimal) and AssetShrink (C++17, local image processing)—. All with tests, CI and a licence. If a tool isn't auditable, I don't ship it. Same goes for my agent.

The thesis: discipline replaces raw power

A cheap model doesn't force cheap results. It forces you to stop improvising. The trick isn't the model: it's spending few tokens without losing accuracy. With DeepSeek Flash the cost splits like this:

cost = fresh_input × $0.14/M  +  cached_input × $0.0028/M  +  output × $0.28/M

Cached input is 50× cheaper than fresh input, and output is the priciest line. So I attacked all three:

Minimal system prompt and tools (fewer fixed tokens per request).
Maximum cache reuse (same prefix, no random UUIDs to break it).
Controlled output (short answers or JSON, no filler paragraphs).

In my working scenario that cuts spend by ~82%; once the cache is warm, marginal cost per request drops to a fraction of a cent. It's not "free", but it gets close. And it stays correct because I supply the discipline where the model can't.

The setup: OpenCode + DeepSeek

My model is deepseek/deepseek-v4-flash, served through an OpenAI-compatible provider with caching enabled:

{
  "model": "deepseek/deepseek-v4-flash",
  "provider": {
    "deepseek": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "setCacheKey": true },
      "models": {
        "deepseek-v4-flash": {
          "reasoning": true,
          "interleaved": { "field": "reasoning_content" }
        }
      }
    }
  }
}

Three decisions that matter all day:

Automatic compaction (auto, prune, reserved: 5000): the conversation prunes itself; I don't drag a huge history.
Tool output limits (max_lines: 200, max_bytes: 8192): an npm install doesn't dump 200 lines in my face; if it truncates, I re-run it scoped.
Strict permissions (webfetch: deny, read-only plan mode): the agent can't browse or write outside its lane without my approval.

Above all of this sits one file: my AGENTS.md. It isn't a wish list; it's a work router with a protocol (understand → plan → small change → verify → review), an honest Definition of Done (typecheck, tests, lint, reviewed diff) and spending rules. The model is cheap; the judgement isn't.

Memory and context: stop repeating what it already knows

An agent without memory is an intern with amnesia: every session starts from zero and pays twice. I use the engram + zerotoken plugin: typed memory in SQLite with FTS5, auto-saving error→fix, architecture decisions and compactions, and injecting only 2 memories / 600 tokens at startup. In short: instead of dragging 50,000 tokens of history, I inject just enough.

On top of that I add Context7: when I ask about a specific API or version, it pulls the real documentation and caches it as a memory. Next time I don't re-query it and the model doesn't hallucinate it. Live docs, zero repetition.

My.OpenCode.Conf: the private project that shapes it all

Here's the part most people miss. My config isn't a loose opencode.json: it's a private GitHub project called My.OpenCode.Conf, part of my learning and the way I work. It's a bundle of three independent subprojects that talk to each other through an open protocol (MCP):

Subproject	What it brings	Built with
`skill-matrix`	240+ skills in `SKILL.md` format (technical and design) the agent loads on demand via triggers	Markdown
`second-termux-v2`	An MCP server that runs background jobs and returns a single status line instead of flooding the TUI	TypeScript (ESM)
`engram+zerotoken`	The persistent-memory plugin (FTS5) and the token-saving policy	TypeScript (Bun)

A master prompt ties them together: instead of maintaining a fragile install.sh, the agent configures itself (detects the OS, adapts commands). And, to me, the best part of its design: it's reversible. It uninstalls cleanly, with no lock-in, no telemetry and without touching what you already had. The repo is private for now —I show it, explain it and answer questions— but the lesson is public: a good config is code you can read, verify and undo.

The tools that wire it together (MCP and plugins)

chrome-devtools (headless) — a real browser the agent drives: navigate, extract, and run Lighthouse audits without opening a window.
github — issues, PRs and actions from the conversation itself.
sqlite — queries against my local work database.
context7 — live library documentation.
human-followup.ts — my own plugin using notify-send: when the agent asks for input, needs a permission, or finishes a navigation, I get a desktop notification. I can stop staring at the terminal.
Subagents (explore, general) — to split exploration and heavy work without polluting my context.

Building your own MCP to publish without leaving the agent

The most honest example of a "tool of my own" is this very post. Instead of copy-pasting into a browser, I wrote a local MCP for Coder Legion in dependency-free Node ESM (~300 lines): a JSON-RPC conversation over stdio against the platform's REST API. The agent lists, searches, comments and drafts from the same session where it codes.

What's interesting isn't the happy path, it's the edges:

The API has no draft field. The draft is implemented with POST /posts followed by POST /posts/{id}/hide: the post is born invisible to everyone but the author and mods. Publishing is POST /posts/{id}/reshow.
The MCP never publishes on its own. cl_create_post validates and creates always hidden; if the hide fails it returns the id and warns that the post went public so I fix it immediately. The real publish only happens through cl_publish_post, and that call is mine.
Incremental editing. cl_edit_post does a server-side read-modify-write: append, prepend, insert_before, insert_after or replace against a literal anchor. I add a section without resending 19 KB of markdown, with dry_run to preview before saving.

It's the pattern I keep repeating: the API does the bare minimum, the MCP adds the discipline (draft-first, human review) and the agent keeps the mechanical part. If I can't audit or undo it, I don't automate it.

From TUI to Desktop on Linux (already migrated)

Until recently I ran everything in the TUI (v1.18.34). I've just moved to the Desktop version on Linux Mint 22.3, installing the official release .deb. There's no Homebrew cask on Linux —that's macOS only—; here the right choice is the release packages (.deb, .rpm or .AppImage). The desktop binary registers its launcher in the application menu, so I go from "open a terminal and type" to "open an app". Same config, same memory, same agent; only the wrapper changes. If you're stuck installing it on Linux, I'll walk you through it in the comments.

Ten things my cheap agent does today

Real examples, no hype:

Diagnose a repo: point at it, and it reproduces, minimises and proposes a fix plan using the diagnose skill.
Write tests first: red-green-refactor with tdd, not filler tests.
Review a diff: a parallel audit of standards and spec with review.
Real web audit: spin up the headless browser and run Lighthouse on my site.
Pull up-to-date docs with Context7 and store them in Engram so the query isn't repeated.
Remember a fix across sessions: "this broke before", and the error→fix is there.
Run a long build in the background and get a single done status line instead of 200.
Refactor with a plan: request-refactor-plan breaks it into small, safe commits.
Create its own skill with write-a-skill when I repeat a pattern.
Delegate exploration of an unknown codebase to a subagent while I keep working.

The honest part: what I gain and what I lose

I gain: cents-level cost, memory that persists, permissions I respect, zero telemetry, and the peace of mind of a system I can audit and undo. I lose: a reasoning ceiling —a Flash model isn't a frontier model— and convenience. A cheap agent doesn't think for you; it forces you to say exactly what you want and to verify the result. To me, that trade is an advantage: it's the difference between "I trust it because I read it" and "I trust it because an expensive model said so".

Takeaway

You don't need the most powerful model to produce serious software: you need token economy, memory and discipline. With a cheap model well directed, the limit stops being the price and becomes your judgement.

So what about you? Which cheap model do you use —or would you use— and how do you compensate for its limits? Tell me in the comments; I read and reply to everyone.

_{Licencia de los proyectos mencionados: MIT · Sin secretos ni claves en este post. · Proyectos: github.com/yosoyignicion}

Coder Legion - Recent Discussions

Answered: How Much Detail Belongs in an Error Message?

Answered: OPEN-SOURCE ATTENDNACE SYSTEM FOR AN SME

Answered: What Should a Permission Error Explain?

Answered: Should Exact Search Matches Always Come First?

Answered: Which Time Zone Is This Export Using?

Answered: When should an AI agent stop acting?

Answered: AI Gives the Right Answer. But Does It Actually Save Time?

Answered: Senior Engineers Are Paid to Say No

Answered: Should a Failed Upload Clear the Form?

Answered: Build an AI Ops Dashboard with FSCSS modules (ai-ui, st-core, circle-progress, overlapui)

Answered: I’m back, and this time we’re coming out of the casino, not the mine! 😎

Answered: What Does an Empty Dashboard Mean?

Answered: When Should Delete Offer Undo?

Answered: What part of debugging does AI still struggle with most?

Answered: 💬 Developers: Would you ship AI-generated code without reviewing it first?

Answered: Help, where do I start? Animated Character videos

The Practical 3-Step Pipeline

Key Advice Before You Spend

Answered: AI Is Not Going to Save You. It Might Not Replace You Either.

Answered: I'm Still Figuring This Out

Answered: What evidence should an AI coding assistant provide before saying a bug is fixed?

Answered: When Is a Progress Bar Misleading?

Answered: When Should a Client Preview Link Expire?

Answered: Can You Belong to a Community Without Finding Your Audience?

Answered: Building in Public From a Solo Gamedev Perspective (credits to @Karol Modelski for the post idea)

Answered: Should a Resized Image Export Need a Fresh Visual Review?

Answered: When an AI Image Job Times Out, Should Retry Create a New Job?

Answered: php2shell: how are you confirming which PHP your web traffic actually runs on?

Answered: Mapping 32k+ MCP Servers: How we are handling tool discovery without schema drift

Introducing The Startup Café: A Community for People Building Startups ☕

What do I have in mind?

It's just getting started

Interested in joining?

Should an AI Listing Draft Be Allowed to Overwrite Newer Agent Edits?

Can a Keyboard-Only User Finish Your App’s Main Task?

Would an independent final-email rule check earn a place beside your existing tests?

Digital Masquerade: How Deepfakes Turn Social Engineering Into Fucking Hell

"Seeing Is Believing" Has Been Deprecated

The Anatomy of a Deepfake Heist (Defender's Edition)

Why "Just Detect the Deepfake" Isn't a Plan

Zero Trust, Translated for Humans

The Verification Stack

Make It Socially Safe to Say "I'll Call You Back"

What About Reducing the Source Material?

The Checklist

The Point

Interconnected Growth: A Community Begins with Each of Us

What habits daily make you a really great software engineer?

Good debugging starts with better questions

Discussion: What does it take to make an MCP server production-ready?

Why Does Code Work Locally but Fail in Production?

Where do squared error and cross-entropy actually come from?

Stop setting your dark mode background to #000000 and text to #FFFFFF

Would you use free assets in your games?

The rendering of markdown for code block is not working well in CoderLegion?

Angular Example

I turned strings into letter arrays and started rebuilding URLs with index ranges

The core idea

Why bother?

Extra powers

plan – find the ranges that rebuild a target

scatter / gather – seeded shuffle + reconstruct

Install

Links

I Taught AI to Review My Code So I Never Miss Leg Day Again

First, an Honest Word About the Title

Why Your Evenings Are Disappearing (It's the Volume, Not You)

The Four Layers (a.k.a. How I Get to Leg Day)

Layer 0: Don't Review What a Machine Can Reject

Layer 1: The AI First Pass (Your Tireless, Slightly Overconfident Junior)

Layer 2: Humans Review Intent, Not Syntax

Layer 3: Merge Policy, a.k.a. Where the Five-Second Merge Becomes Legal

Discipline Is a Pipeline

Where This Goes Wrong (Because Something Always Does)

Steal This Setup

The Point

the evolution of software development since the emergence of AI

Mi Definition of Done: 5 gates que convierten "creo que funciona" en "puedo demostrarlo"

Mi Definition of Done: 5 gates que convierten "creo que funciona" en "puedo demostrarlo"

`plan` – find the ranges that rebuild a target

`scatter` / `gather` – seeded shuffle + reconstruct

Tu backup no sirve si no puedes restaurarlo: el `-wal` que vació mi base

2) Copia consistente (y por qué no un `cp`)

El bug: el `-wal` que vació mi base restaurada

Your backup is worthless if you can't restore it: the `-wal` that wiped my database

2) A consistent copy (and why not `cp`)

The bug: the `-wal` that wiped my restored database