标签：#dev

Signed upload sessions expire. Event contribution windows close. Storage reservations are reclaimed. These are normal lifecycle events, but many interfaces reduce all of them to “Upload failed.” A better protocol makes expiration explicit and recoverable where policy allows it. Distinguish three clocks An upload workflow usually has at least three deadlines: the event contribution window; the server-side upload intent expiry; the short-lived storage credential expiry. They should not share one timestamp. The event may accept contributions until midnight while a credential lasts five minutes and an intent can be renewed for an hour. Return the clocks in the session response with server time: { "serverNow" : "2026-07-17T18:00:00Z" , "eventClosesAt" : "2026-07-18T00:00:00Z" , "intentExpiresAt" : "2026-07-17T19:00:00Z" , "credentialExpiresAt" : "2026-07-17T18:05:00Z" } The client can display useful warnings without trusting its own clock for authorization. Model expiration by state A credential expiring during transfer is different from an intent expiring before completion. Use stable reasons: credential_expired -> request renewal intent_expired -> reconcile committed parts, then renew or restart event_closed -> stop new work, preserve local recovery guidance Do not automatically restart from byte zero. First ask the control plane which parts were committed and whether the original object key remains valid. Renew narrowly A renewal endpoint should accept the upload ID and prove continuity with the guest session. It rechecks event state, file policy, rate limits, and committed size. The response returns a new credential for the same object. Do not let the browser extend an intent indefinitely. Define a maximum session age and a bounded number of renewals. Long uploads may receive a larger initial policy based on file size and observed throughput. Handle the closing boundary fairly Decide what happens to an upload already transferring when the event window closes. Reasona

A PageSpeed Insights run flags a high Time to First Byte. The ticket lands on the theme backlog. Hosting gets upgraded. A CDN is added. The next lab run still shows a slow first byte on the same priority URL. In our experience the miss is often earlier in the path: DNS, TLS, HTTP version, connection reuse, edge routing, or cache policy. Theme and plugin work still matter, but they sit after the network and delivery stack has done its job. If first byte is already late, paint and interactivity inherit that delay. What follows walks that request in order for teams who need to reduce TTFB before another theme rewrite. We stay on the network and delivery layers. For WordPress cases where code on the stack beats a bigger hosting plan, see Why Your WordPress Site Is Slow (It Is Not Always Hosting) . For LCP levers once first byte is under control, see A Quick Way to Fix LCP: Four Changes That Cut Time to Paint . What TTFB includes when you measure first byte in lab tools Time to First Byte (TTFB) measures how long the browser waits from the start of the navigation request until the first byte of the response arrives. In PageSpeed Insights and Lighthouse, it appears as a diagnostic timing. In WebPageTest and similar waterfall tools, you can split the same wait into DNS, TCP connect, TLS, and waiting (server or edge processing). That split is what makes network work actionable for delivery teams. TTFB is not a Core Web Vital , but it feeds Largest Contentful Paint and overall load feel. A page that spends 800 ms waiting for first byte has already used a large share of a mobile LCP budget before the hero image or heading can paint. Field data from Chrome UX Report may show Time to First Byte as a supporting metric. Lab tools remain the fastest way to prove a DNS or CDN change after a release, because you control the URL, location, and cache state of the run. When you read TTFB in a report, ask which hop dominated. Resolver delay looks different from a cold TLS handshake. A c

Client-side media preflight can improve an upload experience, but it can also crash the page before the network request begins. A twelve-megapixel JPEG may be only four megabytes on disk and tens of megabytes after decoding. Creating several full-size canvases at once is enough to exhaust memory on older phones. Preflight is policy, not editing Decide what the browser must prove before transfer. Useful checks include file count, compressed byte size, declared type, readable dimensions, and a conservative duration limit for video. Avoid mandatory re-encoding unless the product truly needs it. Every transformation adds CPU time, memory pressure, battery use, and another failure mode. Process one file at a time A file picker may return twenty items. Do not decode all of them to build previews. Maintain a queue with one active decode on constrained devices and at most two on stronger ones. for ( const file of files ) { const result = await inspect ( file ); renderResult ( result ); await yieldToMainThread (); } The UI can list filenames immediately while dimensions and thumbnails arrive progressively. Prefer metadata over full pixels Use createImageBitmap with resize hints when supported. It can decode away from the main rendering path and avoid a full-resolution canvas for a small preview. const bitmap = await createImageBitmap ( file , { resizeWidth : 640 , resizeQuality : ' medium ' }); Always close bitmaps after drawing. Revoke object URLs when the component unmounts. Small leaks become large when guests select and remove files repeatedly. Handle orientation and color carefully Modern browsers generally honor EXIF orientation when decoding, but behavior differs across APIs and older engines. Test portrait photographs from real iOS and Android devices. Do not strip metadata silently if the original is supposed to remain untouched; upload the source file and treat the preview as disposable UI. Color differences between the preview and exported original are usually les

Event uploads fail differently from normal office uploads. A wedding guest may move between venue Wi-Fi and mobile data, lock the phone while a video is transferring, or close the browser as soon as the progress bar reaches 100%. Hundreds of devices can share one access point, and users rarely wait around to diagnose an error. The usual POST request plus optimistic success toast is not enough. A reliable browser flow needs a small protocol that distinguishes local preparation, network transfer, server acceptance, media processing, and final availability. This article describes a platform-neutral design for that protocol. The five states users actually experience Model each file as a durable state machine: selected -> preparing -> transferring -> accepted -> processing -> ready Add terminal or recoverable branches: preparing -> rejected_local transferring -> paused | retryable_error | expired accepted -> processing_error processing -> ready | processing_error The key distinction is between transferring and accepted . The browser may have sent every byte while the server has not yet committed the upload. Showing “done” at that boundary creates the most frustrating failure: the guest deletes the original, but the organizer never receives it. Give every file a client-generated identity Create an upload ID before the first network request. A UUID is sufficient when combined with the event identifier: const uploadId = crypto . randomUUID (); const uploadIntent = { uploadId , eventId , name : file . name , size : file . size , type : file . type , lastModified : file . lastModified , }; Send that identity when creating the server-side upload session. If the browser retries after a timeout, the server returns the existing session instead of creating a duplicate. This is idempotency at the workflow level. A guest can tap “retry” without having to understand whether the first request reached the server. Separate the control plane from file bytes Use a small JSON API for sessi

The cost of writing code dropped; the cost of owning it didn't. A framework for deciding which changes are actually cheap in the AI era. The post The cost of saying yes has changed appeared first on The GitHub Blog .

I've been tuning Codenames AI , a small web game where an LLM plays Codenames with you. Clue generation is tightly constrained: one word, a count, optional intended targets, JSON on the wire, then deterministic validation before anything reaches the board. As the project started attracting regular players, I wanted to improve the gameplay experience without blowing out costs. Moving one model generation from gpt-4o-mini to gpt-5-mini was my first instinct. The default reasoning setting made responses an order of magnitude slower for this workload. Minimal reasoning looked like the obvious compromise: newer model, responsive gameplay. I expected to compare clue quality, latency, and cost while the surrounding prompt, validator, and consumer contracts stayed put. That last part was wrong. The experiment stopped behaving like an A/B test What showed up was structural, and it showed up in places that had been stable for months. Validation failures started rising. Retries started rising. Entire candidate batches started failing before the game ever saw a clue. The sharpest signal came from a clue-selection path that had run untouched for months, and it hard-failed for the first time. They weren't latency regressions so much as architectural ones. It is easy to read that as "minimal reasoning made the model worse." More often, the failures were exposing gaps in contracts that had looked fine under the previous model. What each failure actually invalidated Eventually every failure traced back to one of three layers: Prompt contracts ask for exactly count targets and, in batch mode, several distinct candidates. Deterministic validators reject target/count mismatches and filter invalid candidates before anything downstream runs. Downstream consumers only see survivors. Empty batches retry with rejection feedback, then fall back if needed. Those layers share one job: enforce the same invariants. The failures below cut across all three rather than mapping one to one. Side comm

TL;DR I checked 50 AI-generated login endpoints. Zero had rate limiting. Attackers can brute-force credentials at full speed against these routes. Adding a rate limiter takes four lines and one npm install. I asked Cursor to build a login route for a side project last month. Email, password, JWT back on success. It worked first try, passed my manual tests, and I moved on to the next feature. Three weeks later I ran a load test against it out of curiosity and hit the endpoint two thousand times in under a minute. Not one request got throttled. That's when I started pulling apart every AI-generated auth route I could find, mine and other people's open source side projects, and the pattern held everywhere I looked. The models write correct authentication logic and completely skip rate limiting, because rate limiting isn't part of "does this login work," it's part of "does this login survive contact with an attacker." The vulnerable code (CWE-307) Here's roughly what Cursor and Claude Code hand you when you ask for a login route: // ❌ No rate limiting - CWE-307: Improper Restriction of Excessive Authentication Attempts app . post ( ' /api/login ' , async ( req , res ) => { const { email , password } = req . body ; const user = await User . findOne ({ email }); if ( ! user || ! ( await bcrypt . compare ( password , user . passwordHash ))) { return res . status ( 401 ). json ({ error : ' Invalid credentials ' }); } const token = jwt . sign ({ id : user . id }, process . env . JWT_SECRET , { expiresIn : ' 1h ' }); res . json ({ token }); }); Password hashing is fine. JWT signing is fine. But nothing stops a script from hitting this route as fast as the network allows. No lockout, no delay, no cap on attempts per IP or per account. A credential-stuffing list with ten thousand leaked passwords runs against this endpoint in seconds. Why this keeps happening Rate limiting lives outside the function the model was asked to write. The prompt is "build a login endpoint," and it re

a local, Claude-powered brain-assistant for solopreneurs I kept losing good ideas — not because I forgot to write them down, but because nothing ever went back and connected them. A task on Monday, an idea on Wednesday that was secretly the same problem, a question on Friday that contradicted something I'd decided two weeks earlier. All of it just... sat there. So I built Dot Connector : a small local app where every capture is a "dot," and every few captures, Claude reviews the stream against a standing memory and surfaces three things — non-obvious connections between notes, contradictions with what you said before, and open loops you haven't closed yet. The architecture is deliberately simple. It's Express + vanilla JS, no build step, no account system. Every capture gets a cheap, fast Claude call for auto-tagging. Every 3rd capture triggers a deeper "sweep" — a second Claude call that looks at recent captures alongside standing memory and open loops, and returns structured updates: new memory facts, dot-connects, contradictions, and open-loop resolutions. Why local-first. no server of my own, notes never leave your machine except the direct calls to Anthropic's API, bring-your-own API key so there's no subscription — you pay Anthropic directly, typically well under $1/month for personal use.] Its just a steal one-time $29 download All info and download get it here: https://dot-connector.eu

✍️ This post was written with two hands. The story — the first part — is Murilo's, lived and told by the person who was there. The technical manual , at the end, was written with AI. The split is intentional and marked in the text. Nothing hidden about the seam: part is human, part is machine, and the reader sees both. If you've ever managed or logged into a web server and never set up SSH keys, it's because you don't yet know the real risks of a break-in — and that's okay. Until you find out what can happen. Logging into a server over SSH with a username and password is like locking the front door of a house that faces the street, with nobody keeping watch. Anyone can try as many combinations as they want, freely. And setting this up takes almost as much time as typing a username and password — and it makes getting into the server much faster and easier afterwards. Ignorant of best practices, I managed my servers for a long time by typing: ssh user@server-ip password That nearly cost me dearly, the day I found out my server had been broken into. After that incident, I realized just how vulnerable a username and password are on SSH. Today I can't say I sleep soundly — no system is completely break-in proof — but I sleep a lot better (and honestly, I always slept well, until I started managing servers). Waking up on a fine Sunday morning to do some maintenance on the server, and finding out it was broken into through the front door because you left a combination padlock facing the street — that is not the kind of surprise I'd wish on anyone. I have a degree in Law. I worked for 15 years in the legal field at a public institution, until I decided to venture into the world of programming. And where did I end up? Managing systems at the institution I work for, after spending some time building automations in Python. Managing systems wasn't exactly what I had in mind when I wanted to learn to code and understand the world of programming. But that opportunity ended up tea

GIT AND GITHUB Git is a distributed version control tool that track changes into files or code and we can say it works offline. A version control is system used to track and manage changes to a remote file in git. Git Bash is born again shell or basically a command prompt window which emulates UNIX and LINUX environments. Git hub is a website that stores your Git repositories in the cloud so we can say it exist online.It stores your project's version history online and adds collaboration tools like pull requests, issue tracking, and code review." _A repository _in GitHub is similar to a folder in your local machine so any changes are tracked. How to create a repository in GitHub do a simple README.md(markdown) then commit the file and write a massage inside to describe the changes done,then we will need to download a visual code eg VScode where you are able to access the terminals. Git is used to push changes** to git hub or pull a repo from GitHub** There are 3 states that every files lives in; Working Directory -You have made changes but git has not recorded them yet.(it's still on our machine) Staging Area -You have told Git about the changes. Not saved yet. git add filename thus we git add Repository (.git)-Changes are permanently saved in history. git commit -m "message" * Basic Commands/key terms used * git config allows git to know who you are by using your username and user email e.g. your GitHub account name and email address this is an important info when you want to commit changes as it will tell you who made the changes there are different levels but we will use global Global- applies to all repositories for the current user > Syntax: git config --global user.name or user.email. - mkdir (make directory) name – creates a new directories for example: my_project in your machine. - git init this tells Git to start tracking this folder,it initializes git on the folder,the .git folder is where all the history, settings, and saved snapshots lives. It's hidden s

A practical introduction to WebGPU, WGSL, render pipelines, compute shaders, and the future of high-performance graphics on the web. Your browser can stream 4K video, run a complete code editor, render complex 3D scenes, and host multiplayer games. But for years, web developers accessed the GPU through an API based on an older generation of graphics programming. WebGPU changes that contract. WebGPU is not simply a faster version of WebGL. It is a new approach to graphics and parallel computation on the web—one built around explicit pipelines, modern GPU architecture, compute shaders, predictable resource management, and a shader language designed specifically for the browser. This article expands on the progression presented in the uploaded High Performance Graphics: Introduction to WebGPU material: why WebGPU matters, how it differs from WebGL, how WGSL works, how the rendering pipeline is constructed, and how compute shaders extend the GPU beyond graphics. WebGPU is not WebGL 3.0 This is the first mental model to correct. WebGPU does not build on WebGL. WebGL exposes a browser-friendly version of the OpenGL ES programming model. WebGPU instead uses concepts associated with modern GPU APIs and provides a portable abstraction over the graphics capabilities available on the user’s system. WebGPU and WGSL are W3C standards for accessing GPU acceleration from web applications. The API supports both graphics rendering and general-purpose parallel computation. ( W3C ) WebGL │ └── OpenGL ES-style state machine WebGPU │ ├── Explicit pipelines ├── Explicit resource bindings ├── Command encoding ├── Compute shaders └── Modern GPU execution model The difference is architectural, not cosmetic. In WebGL, you frequently change global rendering state and then issue a draw call. In WebGPU, you describe the pipeline and resources more explicitly, record commands, and submit those commands to the GPU. WebGL mental model Change state ↓ Change more state ↓ Bind resources ↓ Draw WebGPU

Uber explained how it keeps its OpenSearch deployments running during a zone outage. It does this by using OpenSearch's built-in shard allocation and its own isolation-group system, which relies on the Odin container orchestration platform. This way, it maintains both query and ingestion capabilities. By Claudio Masolo

Ask ten AI developers what tools they use, and you'll probably get ten different answers. The AI ecosystem is evolving so quickly that it's easy to believe you need every new framework, model, and application to stay productive. I don't think that's true. Over the past year, I've experimented with dozens of AI tools while building products, writing technical content, managing prompt libraries, and developing AI workflows. Along the way, my stack has become surprisingly simple. It's not built around the "best" tools. It's built around the tools that work well together. Here's the AI stack I rely on in 2026 and, more importantly, why each tool has earned its place. 1. ChatGPT: My Primary Thinking Partner ChatGPT is where most of my work begins. Not because it can do everything, but because it helps me think faster. I use it for: Brainstorming ideas Structuring articles Reviewing technical concepts Exploring architectural trade-offs Refining prompts Research assistance I rarely expect the first response to be perfect. Instead, I treat it like collaborating with a knowledgeable teammate who accelerates my thinking. 2. Cursor: My AI-Powered Development Environment When it's time to write code, I move into Cursor. Its strength isn't just code generation. It's understanding the context of an entire project. Whether I'm building a FastAPI backend, integrating APIs, or refactoring an existing codebase, having AI directly inside the editor removes a huge amount of friction. The less I switch between applications, the more productive I become. In fact, one of the biggest lessons I've learned is that adding more AI tools doesn't automatically improve productivity. Sometimes it has the opposite effect. I explored this idea in The Hidden Cost of Using Too Many AI Tools , where I explain why a smaller, well-integrated stack often outperforms a collection of disconnected applications. 3. GitHub: The Source of Truth Every project eventually ends up in GitHub. Not just source code. I

A few months ago, a founder posted about the SaaS he'd just shipped — built entirely with an AI coding assistant, not a line of it typed by hand. He was proud of it, and he had every right to be. Within days of launch, someone found the API key sitting in plain sight in the client-side code. It got used to bypass the paywall, spam the backend, and write garbage into the database. The founder spent the next stretch rotating every key, moving secrets into environment variables, and locking down the API endpoints that should have been locked down before anyone ever saw the site. Nothing about that story is about the AI being bad at its job. The AI did exactly what it was asked: build a working product, fast. Nobody asked it to think about what happens when a stranger opens dev tools. In the replies, someone made a simple point: AI is a great research aid, but shipping a large application still means understanding the code — copying and pasting isn't programming. The founder didn't push back. He agreed: he'd learned it the hard way. The same story, over and over Swap the platform and the same shape of story repeats. Here's the WordPress version — three separate, ordinary launches, three separate silent failures. A site goes live and Google never finds it. Somewhere in Settings → Reading, "Discourage search engines from indexing this site" got left checked — a setting every staging environment needs and every production site must not have. Nobody notices until weeks later, when someone asks why the brand-new site isn't showing up in search at all. A debug log sits in a predictable place, readable by anyone. wp-content/debug.log collects whatever errors WordPress throws — database credentials, API keys, fragments of user data — in plain text, at a URL automated scanners check within hours of a new site going live. Turning debug mode off doesn't delete the file it already wrote. The admin username is still admin . It's the default nobody bothered to change, and it happens

A tutorial series, DEV.to blog series — from your first HTML element to production-grade User Interfaces, all in pure Python. Modern Python web frameworks force developers into a split workflow: business logic lives in Python files with full IDE support, while presentation logic is exiled to template files that offer none of it. Template languages like Jinja2 introduce their own syntax for conditionals, loops, and variable access — syntax that your linter cannot check, your type checker cannot verify, and your debugger cannot step through. Every context variable passed across that boundary is a potential KeyError waiting to surface at runtime. Probo eliminates this divide entirely by making HTML a native Python construct — written, validated, and refactored with the same tools you already use for the rest of your codebase. PART 1: Introduction to Probo — Write HTML Entirely in Python What is Probo? Probo is a Python-first, declarative UI rendering framework . Instead of writing HTML in .html files or using template languages like Jinja2, you write everything in pure Python. No template files. No string concatenation. No f-strings full of angle brackets. Just Python functions and classes that are your HTML. The Two Flavors of Every Tag Every HTML tag in Probo comes in two forms: Flavor Example Returns Use Case Function (lowercase) div() , h1() , p() Rendered HTML Quick rendering, lightweight Class (uppercase) DIV() , H1() , P() SSDOM tree node Tree manipulation, streaming from probo import div , DIV # Function: returns a string immediately # return_list=True html_string = div ( " Hello World " ,) # → "<div>Hello World</div>" # Class: returns a tree node, call .render() to get the string node = DIV ( " Hello World " , Id = " main-title " ) # Because it's a Node, you can manipulate it dynamically node . add ( div ( " Subtitle added later! " )) html_string = node . render () # → '<div id="main-title">Hello World<div>Subtitle added later!</div></div>' Note: by adding ret

This button passes every automated accessibility scan we've thrown at it: <button class= "btn-primary" type= "button" > Check availability </button> And it breaks every AI agent that tries to book a room through it. The markup is clean: a real <button> , a proper accessible name from its text content, an explicit type . Nothing to flag. The failure isn't in the button, it's in what happens after the click. And no static scanner ever clicks. What a scanner actually sees Static accessibility scanners evaluate the DOM at a point in time. Usually the initial render: HTML parsed, framework hydrated, nothing interacted with. They check that state against WCAG rules, missing alt text, contrast ratios, label associations, heading order. That's genuinely useful. It's also a photograph of a lobby, when the task happens in the hallways. Here's what never appears in the initial DOM of a typical booking flow: The date picker that mounts when the check-in field receives focus The error message injected after a failed form submit The room-selection modal that opens on "Check availability" The loading state between "Book now" and the confirmation A scanner reports zero issues on all of these, for the simple reason that at scan time, none of them exist. What an agent actually traverses An AI agent completing a booking doesn't evaluate a snapshot. It walks the flow: reads the accessibility tree, decides on an action, performs it, waits for the interface to respond, reads the tree again. Every state transition is a place where the tree can lie to it. Let's look at three patterns we keep finding in real audits. All three pass static scans. All three stop an agent. 1. The modal that exists on screen but not in the tree { isOpen && ( < div className = "modal-overlay" > < div className = "modal" > < h2 > Select your room </ h2 > < RoomList rooms = { available } /> </ div > </ div > )} Visually: a modal. In the accessibility tree: a div soup appended somewhere in the body, with no role="di

Users are creating accounts on your new Saas. Yay (and not just family and friends or bots). Yay! Now comes the next step from every marketing handbook: capturing newsletter subscriptions. This article builds on Add Sign Up to Rails 8’ Authentication . Add a simple checkbox to let users opt in to product updates during signup. Store their preference using Rails Vault and manage the subscription with Rails Courrier . First, add Rails Vault and Rails Courrier to your Gemfile: gem "rails_vault" gem "rails_courrier" Rails Vault adds simple and easy settings, preferences and so on to any ActiveRecord model (I recently pushed 1.0.0). Courrier is API-powered email delivery for Ruby apps with support for Mailgun, Postmark, Resend and more. Rails Courrier is the Rails “wrapper” for Courrier. These two gems work really nicely together for this feature. Run bundle install and generate the Rails Vault migration: rails generate rails_vault:install rails db:migrate It creates a new file app/models/user/subscriptions.rb : class User::Subscriptions < Vault vault_attribute :product_emails_subscribed_at , :datetime # Add more subscription types as needed: # vault_attribute :marketing_emails_subscribed_at, :datetime # vault_attribute :weekly_digest_subscribed_at, :datetime end And updates your User model to use this vault: # app/models/user.rb class User < ApplicationRecord + vault :subscriptions has_secure_password has_many :sessions , dependent: :destroy end This keeps subscription data organized without cluttering your User table. More subscription types can be added later without database migrations. Now the plumbing is done, add a checkbox to your signup form in app/views/signups/new.html.erb : <%= form . check_box :product_emails %> <%= form . label :product_emails , "Subscribe to product updates" %> Update the Signup model to accept this parameter: # app/models/signup.rb class Signup include ActiveModel :: Model include ActiveModel :: Attributes attribute :email_address , :stri

A week ago I put a rough, honestly-a-bit-thin version of PulseWatch in front of real people for the first time. Within days, two different strangers — independently, unprompted — found two real gaps in it. Neither was catastrophic. Both were exactly the kind of thing you only find by watching someone else use the thing you built. This is the story of both, and the fixes. Bug one: the run that never ends This first bug came from a friend testing it on a real script. His question was simple: "What happens if start fires twice before end ?" Good question. At the time: nothing good. Here's why. PulseWatch works on two pings — a job calls /start when it begins and /success (or /fail ) when it's done. The server tracks whichever run is currently "open" for a monitor. The bug: if a job's process restarts mid-run — a crash-and-retry, a redeploy that catches it mid-flight, a scheduler firing twice — you get a second /start before the first run ever closes. The old run just sits there, open forever, an orphan with no ending. Worse, because the watchdog was still waiting on that run's expected finish time, it could fire a false "still running" alert for a run that was, for all practical purposes, dead and abandoned. The fix is a small rule with an outsized effect: a new /start supersedes whatever run is currently open. The old run gets marked superseded — a terminal, non-alerting status — and a fresh run begins clean. The watchdog was updated to treat superseded as a dead end: nothing to wait on, nothing to alert about, and it never shows up in a user's run history. It's not a failure and it's not a success. It's just "this run doesn't matter anymore, a newer one replaced it." The logic, roughly: def handle_start ( monitor ): open_run = monitor . get_open_run () if open_run is not None : open_run . status = " superseded " open_run . finished_at = now () new_run = Run ( monitor = monitor , status = " running " , started_at = now ()) db . session . add ( new_run ) db . session .

This is the next big thing! I've been working on Moonlight AI for almost 6 months now and today I have big news. Automated Applications . That's right, Moonlight AI will have automated applications for the 2.0 version! What is Moonlight AI? Moonlight AI at first, was a project that was aimed to compete with Upwork. That definitely didn't work out even at the development phase so I had to pivot to another project. A month after the conception of the original version, I met a potential co-founder for a new initiative. Moonlight has been repurposed to be a capabilities mapping engine based on worker experience. We used a resume parser and a local LLM to map the capabiities based on skills and job experience alongside Github integration to use as proof of work. The project ultimately didn't work out, the potential cofounder was MIA so my only recourse was to rewrite Moonlight AI to be another thing, which ended up being a glorified job board which is how it works now. The Development Process Moonlight AI was vibe-coded in a night. Modifications were done the same way with different LLM models. LLMs today are what I call an automated entry-level developer since juniors is the wrong term because juniors at least have from 1-3 years of experience in the professional landscape and are more than just coding monkeys, where as entry-levels are just that, developers with 0 years of experience. Today, Moonlight AI should be done the correct way: reading the code and writing it too. Why let an LLM to do my job as well as think for me? DO YOU WANT ME TO GET ALZHEIMER? BECAUSE THAT'S HOW YOU GET ALZHEIMER! Anyways, exercising the mind is very important, that's what make us humans. People today have an obsession with automating their lives completely and end up like the humans in WALL-E. End of rant. The Future (Conclusion) I don't know the future, but I envision Moonlight AI to be a tool to make unemployed people lives a little less unbearable. I know how frustrating is to use a jo

Hi everyone! I’m a developer at the beginning of my journey, and I’ve just finished working on a small project that brought me a lot of joy: Capybara Game. It’s a cute game where you feed your capybara and improve her happiness level. You can choose between 5 different types of food or pick your own snack. If the capybara likes the snack, her happiness level rises; if she doesn't like it, the happiness level falls. Your progress is saved automatically. Keep in mind that your capybara gets hungry over time, so make sure to check back and feed her regularly! I went for a minimalist, cozy design. The interface is clean and intuitive, focusing on a relaxing user experience that lets the player focus entirely on the capybara. I built this project using HTML, CSS, and JavaScript. Hope you're interested in playing! You can do it here: Play the game here I’d love to hear your thoughts! If you have any ideas for new features or if you find any bugs, feel free to let me know in the comments.