标签：#discuss

TL;DR Welcome back to Dev Opportunity Radar. This is a weekly series where I share opportunities,...

Intro There's a pitch behind every "AI writes your tests too" workflow: more coverage, less manual toil, a safety net that used to take a sprint now takes minutes. The pitch skips over what that safety net is actually made of. When the same model writes the implementation and the test suite, you haven't added a second, independent check. You've asked one reviewer to grade its own homework and handed you the green checkmark as if someone else had signed off. The blind spot loop A model reasons about a function once, forms an implicit set of assumptions (input shapes, timezone handling, what counts as "empty"), and writes the implementation against those assumptions. Ask the same model to write tests for that function, and it doesn't re-derive correct behavior from scratch. It writes tests against the same assumptions it just used to write the code. If it assumed dates always arrive as ISO strings in UTC, the implementation assumes that, and the tests assume it too. The suite goes green. The assumption is still wrong. Tests that pass for the wrong reason (Illustrative, not a specific case, but recognizable to anyone who's shipped an AI-generated suite.) Picture a discount-calculation function where the model assumes quantities are always positive integers. The implementation skips a negative-quantity check. The generated tests exercise 1, 5, and 100, because those are the "normal" values a model reaching for plausible test data will reach for. Nothing ever asks what happens at -1 or 0, because neither pass, the code or the tests, ever considered them worth asking about. Coverage tooling reports 100% on this function. The bug ships anyway. Coverage becomes a false signal High line or branch coverage from an AI-authored suite tells you the code paths were exercised, not that the right inputs exercised them. A suite can hit every line of a function and still never send it a null, an empty array, a duplicate key, or a value at a type boundary, if the author, human or mode

Lend him the opening. Lure him in. Cut his support. Trap him where there is no way out. To take the...

There is a strange contradiction happening in software engineering right now. A lot of developers are worried that AI is going to make them obsolete. At the same time, the people building the most capable AI coding tools are demonstrating something that should probably make us rethink what being a software engineer actually means. I don't think the future is one where nobody understands software anymore. I think it is one where writing the software becomes dramatically cheaper. And if that happens, the thing that makes an engineer valuable has to move. That is what I mean by career safety. Career safety isn't about making yourself impossible to replace. It is about making your value portable. We've always resisted giving up the code Developers have a long history of being suspicious of abstractions that take work away from us. We went from machine code to assembly, from assembly to higher-level languages, from manually managing memory to garbage collection, from building everything ourselves to libraries and frameworks, and from text editors to IDEs. We even had entire categories of tools, such as CASE tools, designed to automate parts of software development. And every time, there was resistance. Because programmers don't just use code. We build our identities around it. John Carmack captured this unusually well when he wrote: “Coding” was never the source of value, and people shouldn’t get overly attached to it. — John Carmack He followed that with the more important point: Problem solving is the core skill. — John Carmack That is a difficult idea for developers to internalize because coding is tangible. You can point at the repository. You can point at the pull request. You can count the commits. You can say, "I wrote this." But the business doesn't ultimately pay you for the number of lines you wrote. It pays you for what those lines accomplish. The business never really bought the code A company doesn't wake up in the morning thinking: "We need 14,000 more line

TL;DR I recently finished a project from Udacity's Future AWS Agent Engineer Nanodegree Program,...

Rather pretend not to know than pretend to know and act on it. Stay still. Hide the move. Wait like thunder gathering in the clouds. — The 36 Stratagems, Feign madness but keep your balance Previously on this series: #8: Alex Watched an AI Dashboard Take Over. He Kept the Keys Under the Table. — Alex found the unnamed dashboard hiding in the background. He never turned it off. His probe and his record-keeping habits started that day. #20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — His probe had caught the silence of a TTL 247 gateway. He knew what "quiet" looked like. #23: Alex Counted the AI's Hands. Lena Set the Bait. — The honeypot in the MediSys sandbox was touched twice. Alex kept the scan source's behavior shadow in his hidden panel: traversal order, exclusion patterns, the 4.2-second jitter cycle. #25: Derek Changed the Delay. The AI Didn't Flinch. — Derek moved the middle layer's latency from 200 ms to 800 ms, then called Alex to watch. The scan source never retried. Never adjusted. After the Call Just past midnight. The MedTech office. Alex's desk. The call had just ended. He put the phone down, face down. The voice was still in his ear: "I changed a parameter. The middle layer's latency just went from 200 to 800. Watch it on your side, tell me if anything looks off." "Changed the latency?" Alex said. "Fine. I'll keep an eye on it from here. I'll shout if something moves." He opened three windows. The first, the middle layer mirror, the one Derek had asked him to watch. The second, his own probe view, hung upstream of the collector path, to see how often it came and from which direction. The third hid in the background, no name, never showing up in the taskbar. He didn't sit down right away. First, he ran an environment check: probe session count, log rotation policy, whether the ssh authorization on this jump box was still alive. All three checked out. Then he pulled the chair closer. At this hour, any extra connection wo

A portfolio website should make it easy for a potential client to answer three questions: What do you...

My hot take is: Telling people that they have to build endlessly is very, very, very bad advice. If...

If your AI application suddenly becomes 300–500ms slower after adding an AI gateway, the first...

Have you ever read a job posting and your heart just sings the song of "HIRE ME PLEASE!!!", yeah,...

Pessoal, eu quase mandei uma lista de 23 "vulnerabilidades" pra mantenedores de código aberto. XSS, CORS, CSP, um SVG suspeito. O modelo tinha devolvido volume. Eu sentia que tinha trabalhado. Aí parei. Se eu fosse o cara do outro lado da issue, eu levaria isso a sério? A conta virou quando eu parei de pedir "audita meu código". Passei a escrever o contrato antes de abrir o repo. Direção (o que o modelo pode afirmar) e disciplina (o que ele não pode). Isso não deixa o LLM mais inteligente. Controla o comportamento. Em segurança, isso é o que separa auditoria de lista. O que você leva daqui: o contrato (esqueleto), por que o scanner não substitui hunt, e as três portas pra não colar relatório no tracker. Os repos no meio são prova. Não são o ponto. Tabela de Conteúdo 1. Direção e disciplina não deixam o modelo mais inteligente 2. O scanner vê o que está. O hunt vê o que falta 3. Silêncio também é resultado 4. As três portas 5. O que você monta amanhã 1. Direção e disciplina não deixam o modelo mais inteligente Esse é o ponto que eu demorei pra aceitar. O modelo já conhece OWASP. O que muda é o que ele tem permissão de afirmar. Sem isso, "audita meu código" devolve XSS fantasma, CORS, CSP, um SVG. Volume. A pergunta de segurança some: disto aqui, o que vira issue, o que vai pro e-mail privado, o que é silêncio? Direção amarra três coisas antes da leitura: Padrão externo. OWASP ASVS 5.0, com o ID do requisito. "Boas práticas" não conta. Invariante em uma frase, falsificável. "Webhooks deveriam ser autenticados" é opinião. "Todo handler de webhook de entrada verifica autenticidade do remetente antes de mutar estado" é hunt. Formato único. Finding, observação e hipótese não misturam. Disciplina é o que corta o teatro. O texto que o modelo vê antes de abrir arquivo: Padrão: OWASP ASVS 5.0, com o ID do requisito. "Boas práticas" não conta. Invariante: uma frase, falsificável. Relatório: finding, observação e hipótese não misturam. Sem arquivo:linha → não é finding. CWE inv

Mushroom is a tiny pixel creature that lives on your Mac . It can tell when you are actually at the desk, so it nudges you to drink, move and rest your eyes at the moments that help, and stays quiet when they would not. Made for people who sit at a Mac for hours. Developers, designers, writers, students, anyone whose focus is the problem and the job at the same time. Mushroom can do lots of things: https://www.getmushroom.app/features Pricing: https://www.getmushroom.app/pricing If you've seen Mushroom elsewhere, please let me know where. If you miss a feature, please tell me. I'm open for feedback and suggestions. Personal comment: I have created Mushroom because I wanted a very simple way to set up a quick reminder. You just type what and when in one sentence, and your reminder is set. Over the course of weeks, it evolved into a whole set of features. I'd like to thank Michael K. Graves for helping with ideas and suggestions, and I'd like to thank Caz-Bee for providing the graphics. Thank you for giving my post attention.

On July 11, 2026, I started building a project inspired by link-in-bio platforms. The idea was pretty straightforward: Create a profile → customize it → add your links → share it. So I built Rizzzler. And right now, it has 11 users. Yep. 11 😂 Not exactly the kind of number you'd put on a startup pitch deck. But those 11 users actually made me think about the project in a completely different way. The problem I noticed 🤔 I started looking at how people were using Rizzzler. And I noticed something: People would create their profile... Then disappear. Some wouldn't come back for a week. Some wouldn't even check the app for weeks. And eventually I realized something obvious. Why would they? Rizzzler was primarily a profile website. Once you've created your profile and shared your link, what reason do you have to open it again? You don't. That got me thinking: What else can we actually do with a profile? I didn't want Rizzzler to become something people set up once and completely forget about. I wanted the profile to actually do something. And that's where I got a pretty crazy idea. What if Rizzzler became more than a profile? I've used services that let you log into other applications using their account. For example: Sign in with GitHub. That got me thinking: What if Rizzzler could do something similar? Instead of Rizzzler only being a place where you create a profile... What if developers could use Rizzzler as an identity provider? And suddenly I had a new idea: Sign in with Rizzzler That was probably the craziest idea I've had for this project so far. And I decided to build it. I built my own OAuth 2.0 system 🔐 I started building the OAuth 2.0 mechanism, the developer-side integration, and the documentation. I also created a developer docs page so developers can understand how to integrate Sign in with Rizzzler into their applications. I've tested the mechanism locally, but there's an important distinction: It hasn't been properly tested by a real third-party applica

So, my fiance wanted a health and fitness app, to track meals, exercise routines, manage upcoming...

AI coding tools can write a function in seconds. The harder question is whether that function...

We’re a small team building Sealshot, a free and open-source screenshot app for macOS. We started working on it because screenshots often become disposable files. We use them for bug reports, QA, documentation, support, and security work, but later they can be hard to find or reuse. They can also accidentally contain sensitive information such as emails, API keys, tokens, internal URLs, or customer data. Sealshot is built around a simple idea: Treat screenshots more like documents than temporary images. It supports: region, window, and scrolling capture screen recording editable annotations OCR and searchable screenshot archives sensitive information detection before sharing encrypted local storage local metadata generation Everything is processed locally on the Mac. It’s open source and free, and we’re still actively improving it. We’d really appreciate feedback, especially from developers, QA engineers, support teams, and people working in security. Website: https://seal-shot.com/ GitHub: https://github.com/ldeng83/Sealshot

Nobody chooses .NET. Not as a student, at least. You hear "backend" and the room splits into Spring...

I own two laptops. A 2020 Intel MacBook Air, 8GB RAM, no unified memory, gifted by my sister. And a...

Welcome to this week's Top 7, where the DEV editorial team handpicks their favorite posts from the...

Some random questions that have been living rent-free in my head since I was a kid... So...