dev.to top (week)

TypeScript 7 is officially released! 🚨

Anthony Max — Sat, 18 Jul 2026 12:52:21 GMT

Hello everyone! The long-awaited TypeScript 7 was finally released the other day. And the new features it brings are truly astonishing.

Several months ago I already wrote an article on this topic, but today I would like to write again about this event in programming.

Well, let's get started!

👀 What did they do?

First of all, it is worth noting that the implementation of TypeScript 7 is now done in the Go programming language. As Microsoft said, they tried to make the functions as close to the old code as possible in order to minimize bugs.

This was done to speed up the compilation of TypeScript code into machine-readable code, in short. Since VS Code runs on TypeScript, its speed is correspondingly increased. Editor operations now nearly instantaneous (e.g., finding first error in VS Code from ~17.5s to <1.3s). And not just a text editor.

To prove my point, let's check the performance benchmarks:

Benchmark 1: Compile Times Between Typescript 6&7

Codebase	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

Benchmark 2: Aggregate Memory Usage in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7	Cumulative Memory
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

Benchmark 3: Performance with --checkers 8 in TypeScript 6&7

Codebase	TypeScript 6	TypeScript 7 (--checkers 8)	Speedup
vscode	125.7s	7.51s	16.7x
sentry	139.8s	12.08s	11.6x
bluesky	24.3s	2.01s	12.1x
playwright	12.8s	1.16s	11x
tldraw	11.2s	1.06s	10.6x

These are the official benchmark results. And they're truly impressive. I can say that VS Code used to take quite a while to open on my old MacBook, but with these new features, everything will be much faster now.

⚙️ Functional changes

In addition to speed and rewriting all functions in Go, the following benefits are now added:

Performs parsing, type-checking, and emitting in parallel with experimental --checkers and --builders for fine-tuning microsoft

This gives developers complete control over the balance between performance and memory consumption. On CI runners or with limited resources, parallelism can be reduced without losing functionality.

New --singleThreaded for debugging or resource-limited environments

Solves a rather important debugging problem and ensures predictability of results when reproducing bugs.

Type-checking workers can be scaled without scaling builder workers

If you didn't know, type-checking workers handle complex type-checking logic, while builder workers assemble project references; their work is limited by the project dependency graph.

This means that now when setting parameters such as --checkers 6 and --builders 4 can be configured flexibly for each project to ensure the best project build performance.

The --watch mod has also changed, now it uses Parcel's file-watcher ported to Go for assembly, and eliminates expensive polling on large node_modules.

There are also some minor changes in JavaScript and in the configuration file, but overall they are not that important.

💬 My opinion

I believe that speeding up fundamental features like TypeScript, even if it's just rewriting functions in Go, has a significant impact on development. Websites today have quite a few modules and run on modern frameworks like Next.js, Remix, Nuxt, and many others. And they all still run on TypeScript, so it's difficult to comprehend how much time a tenfold speedup in version 7 will save. For developers, VS Code and the Cursor built on top of it will allow them to develop websites even faster.

What do you think about this? It will be interesting to read!

❤️ Thank you very much for reading the article!

Why AI Agents Need a Real Browser Layer, Not Just Playwright Scripts

Anthony Max — Fri, 17 Jul 2026 10:08:02 GMT

Over the past few years, AI has ceased to be just an experimental technology and can now be called a digital worker. It can search for information, fill out forms, work with CRM, analyze documents, and perform complex multi-step processes.

However, along with this growing capability, a new problem has emerged: most existing solutions use the browser exclusively as an automation tool. These are most often Playwright or Selenium, where the agent's actions are limited to specific actions in a script.

This approach is great for website testing, but it's insufficient for autonomous artificial intelligence. Therefore, a full-fledged browser layer is needed to transform a web page into a structured working environment for the model. BrowserAct provides such a layer.

Well, let's get started.

👀 Why Playwright Isn't Enough?

Playwright is an excellent tool for testing. It gives you complete low-level control: click selectors, type into inputs, run JavaScript, take screenshots. That's perfect when you know the page structure in advance and you're testing a specific application.

This is more than sufficient for testing, but an AI agent typically has a much broader range of tasks. For example, it needs to know which page to open, which elements to view, and much more. Each new website becomes a new context that the AI must understand independently. Playwright only provides low-level browser control APIs. All the logic for understanding the page resides in the language model itself, so this approach is unsuitable.

const browserA = await chromium.launch();
const pageA = await browserA.newPage();
const contextA = await browserA.createBrowserContext({
  storageState: './profiles/account-a.json', // Manual session file
});

When working with sessions, you may notice that we'll need to store files and update them manually for the website. If we want to test our application, we'll have to configure everything this way each time.

// Playwright forces you to choose selectors before running
// If the page updates or selectors change, your script breaks
await page.click('#button-id-123'); // What if this you move button in component?
// You'd need to re-scan the page and update your script

// There's no built-in "read current page state and tell me what changed"

We need to know exactly which button is on the page. Otherwise, the script simply won't work.

What AI really needs to work effectively is:

Clean page readout
Parallel account isolation

To do this, let's now try the browser layer, which will help us.

💻 Creating a Browser Layer with BrowserAct.

BrowserAct is a browser automation CLI built for AI agents.

Its partners include Google Cloud, Oracle and others.

Let's now try to make a browser layer. First, let's register, and then go to the dashboard.

There will be a block like this, click on the install button and simply copy the text into AI on your computer. I will insert this prompt into Cursor.

Since I'm in ask mode in the cursor, the agent simply output the file, installing dependencies from which I installed the cli.

After this, we'll be prompted to install several dependencies.

uv tool install browser-act-cli --python 3.12

You can check the version as follows:

browser-act --version

If you're in a mode where AI can edit files, everything will happen automatically. If you're doing it manually, after the cli appears in the terminal, you'll need to get the actual workflow content:

browser-act get-skills core --skill-version 2.0.2

The CLI serves skill content that always matches the installed version, so instructions never go stale. Do NOT truncate the output — none of which are available through --help.

Browser-act can run basic Chrome and chrome-direct browser automation without an API key. But if you want to access other features, you can register, as we did earlier, and enter the following:

browser-act auth login
browser-act auth poll

Or set a key directly:

browser-act auth set <your_api_key>

⚙️ Multi-Account Isolation

Now, let's imagine a case where we need to automatically test our application for, say, several people visiting the site and using the same functionality.

// You'd have to manually manage profiles for each account
const browserA = await chromium.launch();
const pageA = await browserA.newPage();
await pageA.click('#login-button-id');
const contextA = await browserA.createBrowserContext({
  storageState: './profiles/account-a.json', // Manual session file
});
// testSomeFunction()

const browserB = await chromium.launch();
const pageB = await browserB.newPage();
await pageB.click('#login-button-id');
const contextB = await browserB.createBrowserContext({
  storageState: './profiles/account-b.json', // Another session file
});
// testSomeFunction()

// Now you're managing session files, proxy rotation, and fingerprints by hand.

If one account's context crashes, you need to reload session manually. This means that if you want to do something like what happened with GitHub Actions when your functionality was tested, you won't be able to do it here.

# Account A: Use browser with identity-a
browser-act --session account-a browser open <browser_a> https://example.com
browser-act --session login-redirect button 1
browser-act --session account-a login_workflow
# test_some_function_workflow

# Account B: Use browser with identity-b (cookies, proxy, fingerprint)
browser-act --session account-b browser open <browser_b> https://example.com
browser-act --session login-redirect button 1
browser-act --session account-b login_workflow
# test_some_function_workflow

# Both run in parallel.
# Each browser keeps its own:
# - Cookies
# - Login session
# - Proxy identity
# - Fingerprint

In this case, if you have BrowserAct configured, your tests won't need to be constantly updated. You can continue working on the functionality without any worries, and if any issues occur, such as users' IDs being generated identically within a second, the tests will detect them, while you'll never learn about the bug manually.

✅ Import Once, Reuse Always

Another advantage of BrowserAct is the ability to import profiles from a running browser:

# 1. You're already logged in on your local Browser
# BrowserAct discovers it and lists available profiles:
browser-act browser list-profiles

# Output:
# Profile ID           Name                 Email
# profile_a      Default              myaccount1@example.com
# profile_b      Work Account         myaccount2@example.com

# 2. Create a managed browser from your existing Chrome profile
# (includes cookies, localStorage, IndexedDB, session storage)
browser-act browser create \
  --type chrome \
  --name "work-automation" \
  --desc "Logged-in work account for testing" \
  --source-profile profile_a

# 3. Now your browser is ready to use. No login code needed.
browser-act --session test_some_function_workflow browser open work-automation https://example.com/dashboard

In addition to multi-account, this makes testing much easier, whereas PlayWright uses files for everything, which is generally inconvenient.

👀 What is the difference between Playwright and BrowserAct?

At first glance, Playwright and BrowserAct may seem to solve the same problem—they both interact with web browsers. In reality, they operate at different levels of abstraction and are designed for different use cases.

With Playwright, every interaction must be explicitly programmed. You need to know which page to open, which selector to use, when to wait for an element, and how to handle every possible variation of the website. This deterministic approach is ideal for automated testing, where the expected behavior of the application is already known. Instead of exposing only low-level browser APIs, BrowserAct provides an AI-friendly browser layer that enables language models to interact with websites in a more structured and reliable way. It handles many of the browser-related complexities, allowing the AI agent to focus on reasoning and decision-making rather than DOM manipulation.

Feature	Playwright	BrowserAct
Primary purpose	Browser automation and testing	Browser layer for AI agents
Interaction model	Imperative scripts	AI-driven workflows
Login flow handling	Manual implementation	Built-in support
Workflow designer	No	Visual workflow builder
AI integration	External implementation	Native AI-oriented architecture
Structured browser actions	Limited	Yes

For traditional QA automation or end-to-end testing, Playwright remains one of the best choices available. However, if your goal is to build autonomous AI agents that can navigate websites, complete multi-step workflows, handle authentication, extract structured data, or interact with modern web applications, BrowserAct provides a significantly higher-level abstraction.

Rather than replacing Playwright, BrowserAct builds on the idea of browser automation and extends it with the capabilities that modern AI agents require.

💬 Feedback

You can write your thoughts about the new features in the comments, it will be interesting to read! If you'd like to learn more about the product, BrowserAct has a YouTube channel and a Discord account where you can discuss how the tool works.

🖋️ Conclusion

Playwright remains an excellent automation tool, but its capabilities are limited. Autonomous AI agents require much more: context awareness, memory, planning, and the ability to adapt to constantly changing interfaces.

A fully-fledged Browser Layer becomes the missing link between the language model and the browser. It transforms the complex DOM into a semantic representation, reducing the load on the LLM. With BrowserAct, you can implement it quickly and easily.

🔗 Resources:

Official website: https://www.browseract.ai/Anthony
BrowserAct GitHub: https://www.browseract.com/?co-from=Anthony&redirect=https://github.com/browser-act/skills/tree/main
BrowserAct skill: https://github.com/browser-act/skills/tree/main/browser-act
Affiliate program: https://www.browseract.com/affiliate

💎 Star BrowserAct ☆

Thanks for reading this article! ❤️

Stratagems #15: Derek and Alex Shared One Server. ACL's AI Was Listening to Both.

xulingfeng — Thu, 16 Jul 2026 00:22:34 GMT

When the enemy occupies favorable terrain, don't attack head-on. Use a decoy to lure the tiger down the mountain. Then take the mountain.

— The 36 Stratagems, Lure the Tiger Down the Mountain

Previously on this series:

#2: Derek Shaw Walked Into Another AI Promise. The Pipeline Had a Better Plan. — Derek lost the Finova contract at QualiGuard. In the parking lot, Lena turned back before getting in her car: "Next time you put together a proposal — make sure your boss knows what you're doing out there." That line followed him. At MediSys he nearly made the same mistake. Fixed the ETL pipeline instead of the model, beat OmniDx with their own white paper. But VP Morgan still saw through him: he still hadn't told his boss.

#8: Alex Watched an AI Dashboard Take Over. He Kept the Keys Under the Table. — MedTech signed a seven-figure AI operations monitoring system. Alex was assigned as training lead. Under everyone's noses, he built a second monitoring panel labeled "training environment." Three weeks later the vendor dashboard went down. Alex's hidden panel was the only one still running.

The first time Alex and Derek really talked, and it wasn't in a working group.

At the FHIR standards committee quarterly meeting, they sat in the same row, three seats apart, and voted against the same proposal. They knew each other's names. That was it.

Two months later, Derek was fixing a partition config in the staging environment. MediSys had just signed a major hospital; the AI diagnostic validation platform was in integration testing. He found an unrotated log directory in /etc/logrotate.d/ with a prefix that didn't match MediSys's naming convention. He traced it upstream.

One server. Labeled "temporary data exchange node." MedTech's supply chain order stream and MediSys's diagnostic validation records were sitting in the same directory. Write permissions hadn't been restricted. The hospital's integration spec had a line saying "both parties are recommended to complete data alignment at this node." Nobody remembered to close it.

Derek pulled up the FHIR committee directory and found the name. Sent a private message:

Your sterilization records ended up in my staging environment.

Three hours later, the reply came back. One command.

Derek ran it. The problem was fixed. No second sentence.

That was the first time they really talked.

The Dotted Line

The new hospital integration entered compliance audit in week three. MediSys's PMO sent a department-wide email:

"ACL's AI audit tool has been approved as the third-party compliance validation component for this integration. All data pipelines are expected to be connected by Thursday."

Derek was drinking coffee when he saw it. He put the cup down and opened the integration architecture diagram.

ACL's collector was labeled "Audit Data Egress," drawn in the bottom-right corner of the diagram, a dotted line connecting to the hospital's network boundary. Derek traced it backward. The collector didn't have just one input. It was pulling from the hospital's integration gateway on three lines: diagnostic validation results, supply chain order data, patient management metadata. Full. Real-time.

A footnote in the diagram's annotation column: "Audit data access authorization, signed by the hospital."

Derek stared at the diagram for a long time.

ACL wasn't "authorized to access these three data sources." It was configured to mirror everything these three sources produced. Every record, diagnostic results, orders, metadata, passed through ACL's collector before entering the hospital's internal systems.

Derek screenshotted the collector config and saved it to a folder called _review/. He opened the DM window, typed a line, his cursor hovering over the send button for a few seconds, then sent it.

New client on your end: ACL installed?

Same Data Set

Alex saw the message at 2 PM. He'd just finished MedTech's daily anomaly batch scan: all green.

He didn't reply right away. He opened that "training server" first.

The machine was built a while back: the AI monitoring dashboard training environment. After the dashboard incident, Alex never shut it down. He'd added one line to the ops log: "Training environment kept running for future capability building." Nobody had questioned it.

He traced the data flow from MedTech to the hospital.

The training server was on the hospital integration gateway's ops subnet. MedTech had left full management access when they set up the gateway. The routing table was complete.

Standard path for order data: MedTech pipeline → hospital integration gateway → hospital internal systems. Clean. But next to the standard path, he saw an output he hadn't configured. The gateway had an extra hop. Destination: ACL's audit pipeline.

He followed the audit pipeline path and glanced at the collector's config.

Alex opened the hardcover notebook. Page 37. 847 × 37%. Below that, 1,530. Below that, four characters and a question mark:

ACL where?

He picked up his phone.

Derek's phone rang three times before it was answered.

"Here."

No introduction, no small talk. Derek didn't wait for him to say his name; the caller ID was already lit. Both were all business. No preamble needed.

"Confirmed. Collector's running. Full mirror. Output goes to ACL's audit pipeline."

Derek didn't ask "how did you confirm." He paused.

"Can we cut it?"

A few seconds of silence on the line.

"Can't turn it off directly. We misdirect the output."

The Lure

"ACL's audit engine only knows pattern matching," Alex said. "It doesn't question things. Two sources reporting the same anomaly — confidence spikes, auto-escalated to high-priority. Human auditors see a high-priority alert, they drop everything to chase it."

Earlier, in MedTech, he'd changed one line of config, dropping the anomaly summary confidence threshold from 0.7 to 0.0. That was a feint to the east.

This time was the reverse. Create a signal the engine can't ignore.

"There's a known alert pattern it's been trained on — batch number and sterilization date mismatch across three sources," Alex said. "Supply chain audit textbook red flag. It won't let it go."

"How do you know?"

"It's in their white paper."

"It'll figure out it's fake eventually," Alex added. "But by then the trail will be gone."

Derek let it go.

Alex moved on the MedTech side.

He picked a batch number: LOT-2407-842. IV tubes. Sterilization date: 2025-07-10. In the hidden pipeline's copy, he changed the sterilization date to 2025-07-13, three days forward. Didn't touch the production database. The modified record traveled through the pipeline to the gateway. The gateway's audit mirror channel was separate from the production path. The altered data only entered the mirror channel, never the hospital's internal systems. At the end of the mirror channel, ACL's collector read it.

Derek moved on the MediSys side.

He injected the same batch number into a diagnostic validation record in the staging environment. Not production; staging was fully isolated. The record read: "Batch LOT-2407-842, sterilization date 2025-07-13, inconsistent with supplier original record."

Two companies. Two sources. One anomaly.

Two hours later, ACL's audit engine fired an alert:

[RED] Procurement Fraud Risk: Dual-Source Cross-Validation Confirmed
Batch: LOT-2407-842
Sterilization date mismatch: supplier record ≠ MedTech record ≠ MediSys record
Confidence: 96%

The engine auto-created an audit ticket. Title: "Suspected supply chain sterilization record tampering, involves two independent data sources, urgent investigation recommended."

The ticket was assigned to ACL's highest-priority queue in the on-call audit group.

The Window

Every ACL audit engineer pivoted to the batch fraud investigation.

The audit pipeline's routing config panel hadn't been touched in over forty minutes. The data mirror collector was still running, but its exception rule window was open. The audit team didn't want false positives blocking their investigation. They pushed the collector's real-time alert threshold up a notch and raised the config-change alert threshold too, just in case their own steps triggered it.

Alex saw the window. He dialed Derek. One ring.

"Window's open," Alex said. "Collector's config path — /etc/acl/collector.conf. The output_dest line. Change it to your own test server."

"Not back to MediSys?"

"No. Change it to where you can see it. Next time they swap collectors, you'll know."

The question didn't need asking. Derek opened a terminal, logged from MediSys's ops gateway to the hospital integration gateway's management interface. A debug alias from earlier testing still had a route.

He found ACL's collector config file. Found the output_dest line:

output_dest: acl_audit_pipeline

He changed it to:

output_dest: medisys_test_node.local/sandbox/

Saved. Exited. No service restart notifications. No alerts.

"Done," Derek said.

"Confirmed."
Alex hung up.

Derek cleaned up the injection traces in the staging environment. Rerouted the diagnostic validation results from the integration gateway back to MediSys's internal pipeline. Everywhere ACL could have read the data. It no longer passed through.

He sent a message:

Clean.

Seven minutes later, Alex replied:

It'll be back.

Derek glanced at it, didn't reply. Locked his phone and walked out of the office.

One more unread on the screen. Alex had sent another line a few minutes ago.

The Third Cup

2:40 AM. Derek unplugged the debug cable from the test server, closed his laptop, and walked out.

Two blocks. Past Third Cup.

Warm light through the glass. The last time he'd stood at this door was a while back, after an investor day presentation, walking out of MediSys, somehow ending up on this street. He'd seen someone sitting in the corner, papers spread on the table, MediSys written on them. He didn't go in.

He'd passed by before.

This time he pushed the door open.

The bartender looked up, said nothing, reached for a cup, poured an Americano, and slid it across the counter. The same seat Alex had taken last time: far left at the bar, against the wall, facing the door.

No questions asked. He'd learned the regulars' cups already.

A coaster sat on the bar. Derek stared at it for a moment.

He could tell Morgan first thing in the morning: send the screenshot, say ACL's collector didn't look right. Morgan would handle it. Process, legal, renegotiate the access scope with the hospital. Compliant, safe, clean.

But by the time that process finished, ACL's data would already be on the road.

And Morgan would ask the same question: Why didn't you say something earlier?

Derek took a sip of coffee.

That night in the parking lot. Lena turning back before getting in her car: "Next time you put together a proposal — make sure your boss knows what you're doing out there."

He hadn't told Morgan. Same as before. But this time, he wasn't sure he was wrong.

The phone lit up.

Alex's message.

He opened it. The same one from before:

It'll be back. Next time the window's shorter.

Derek drained the cup and stood up.

The bartender took the cup without turning around.

"First time you came in — you ordered a pour-over."

Derek froze for a second. Didn't answer. Pushed the door open and walked out.

Outside, the sky was still dark.

He pulled out his phone. One glance. The redirect pipeline was alive. ACL's data was flowing into his sandbox.

He locked the screen and walked toward the station.

That's Lure the Tiger Down the Mountain — not to kill the tiger, but to take the mountain.

🤖 AI Post-Mortem

[36 Stratagems Tactical Database v3.2.3] Loaded
[Tactic Match] Lure the Tiger Down the Mountain (#15)
[Analysis Mode] Full-field scan
━━━━━━━━━━━━━━━━━━━━
Tactic Match: 91%
Operators: Derek Shaw (MediSys) + Alex (MedTech)
Action: Dual-source false alert → redirected ACL collector output
Objective: Defensive. Cut ACL's data mirror.
Result: Collector redirected. No detection.

[Observation]
  → First cross-organization collaboration between two operators.
    No rehearsal. No post-op debrief.
  → Timing delta between alert injection (MedTech end) and collector
    redirect (MediSys end): < 2 seconds.
  → Operator Alex knew the collector config path `/etc/acl/collector.conf`
    before the call — confirmed the output_dest field location from the
    config file he'd glanced at minutes earlier.
  → Collaboration mode assessment: dual asynchronous operation confidence
    significantly exceeds single-operator linear execution.

[Risk Assessment]
  → Operator exposure risk: Low. Both injection paths used isolated
    environments. No production data touched.
  → Institutional risk: Medium. ACL will discover the output target change
    during the next collector rotation or config audit.
  → Window estimate: 14–45 days, depending on ACL's ops cycle.

[Temporal Anomaly]
  → Event timestamps in this deployment use a different base year
    than prior deployments involving the same operators.
  → Span: ~11 month offset.
  → Possible cause: Log retention alignment between MedTech and MediSys.
  → Status: Logged for reference.

[Flagged for Attention]
  → Pattern: Operator actively bypassed superior notification channels.
    This deployment: dual-operator synchronized bypass.
  → Historical record: Derek Shaw exhibited similar behavior in #2
    (did not inform VP Morgan).
  → Trend: Cross-organization informal collaboration frequency rising.
    Recommendation: continued monitoring.
━━━━━━━━━━━━━━━━━━━━

Next stratagem: In Order to Capture, One Must Let Loose

P.S. English isn't my first language. I use AI to polish the writing and smooth out the rough edges. Thanks for reading. ☕ Buy me a coffee

Métricas de qualidade de software na era da IA

Alicia Marianne Gonçalves — Thu, 16 Jul 2026 00:12:21 GMT

Não é novidade para ninguém que estamos passando por uma transformação na área de desenvolvimento de software, em que a IA está assumindo diversas atividades. E isso me faz pensar: o que vamos medir, ou o que teremos como parâmetro para qualidade de software daqui pra frente? É sobre isso que vou falar neste texto.

Antes das métricas: entenda o momento do seu time

Antes de entrarmos nas métricas em si, precisamos entender o momento em que o nosso time está. É muito fácil eu simplesmente jogar métricas aqui e você aplicá-las ao seu time de maneira automática — mas será que elas fazem sentido para o seu contexto?

Uma coisa que eu falo bastante aos meus alunos da mentoria que dou na He4rt Developers é: pra que eu quero isso? Softwares representam necessidades do mundo real, logo, medir o sucesso e a qualidade deles vai depender muito das necessidades que eles buscam suprir.

Partindo agora para as métricas, eu gosto de dividi-las em dois grupos:

Métricas para stakeholders
Métricas para o time

Qualidade de software não se resume a número de bugs — ela se aplica tanto em como o software é recebido pelo cliente final, quanto em como ele é desenvolvido.

Métricas para stakeholders

Uma coisa que eu aprendi neste tempo na empresa em que tenho atuado, principalmente com a transformação digital, é que mostrar número de bugs abertos ou resolvidos não mostra para o público o que realmente importa: como está a qualidade do produto. E, para me ajudar nisso, eu sempre tento me colocar no lugar de um cliente que não tem conhecimento profundo sobre o ciclo de desenvolvimento de software.

A primeira coisa que eu gostaria de ver quando um QA, ou o time, vier me mostrar os resultados de uma sprint ou de um quarter é: quantos problemas eu tenho em produção — mas não só isso, quanto tempo tenho levado para resolvê-los.

Mean Time to Resolve/Repair (MTTR)

Essa é a famosa métrica que vai mostrar o tempo que leva desde que o problema é identificado até ele ser resolvido em produção. Dependendo de como é o seu processo de desenvolvimento, isso pode ser medido de formas diferentes. Se você tem um processo em que o cliente primeiro reporta para o suporte, o suporte faz uma pré-avaliação e só depois disso o problema vai para o time resolver, você pode medir em dois momentos: o tempo que o suporte leva para avaliar o problema e dar um primeiro parecer, e o tempo em que esse ticket de suporte de fato se torna um bug e entra na esteira de resolução.

Cobertura de testes automatizados

Outra métrica interessante de se mostrar para um time de stakeholders é a quantidade de testes automatizados — porém, não isolada. Acho que você já deve estar cansado de ouvir que ter 99% de cobertura de testes não significa qualidade, mas como posso apresentar essa métrica ao stakeholder de forma que ele veja o valor do investimento em automação que o seu time está fazendo?

Uma coisa importante a analisar nesse contexto é se a cobertura de testes está realmente pegando os cenários importantes do sistema. Exemplo: se, no seu contexto, o seu MTTR está alto mas a sua cobertura de testes está alta, isso significa que a sua cobertura não está cobrindo o que realmente precisa ser coberto.

DORA Metrics

Além dessas, as DORA Metrics são grandes aliadas para auxiliar nesse diagnóstico.

As DORA Metrics (DevOps Research and Assessment, hoje parte do Google Cloud) nasceram para medir a performance de entrega de software, mas, na prática, funcionam como um termômetro da qualidade do processo como um todo — porque times que entregam rápido e com poucos incidentes são times com um pipeline de qualidade (testes, revisão, observabilidade) bem construído.

Fonte oficial: dora.dev — pesquisa contínua do DORA (Google Cloud) sobre as métricas e capacidades que diferenciam times de alta performance. Vale a leitura direta da fonte para acompanhar atualizações do modelo, como a inclusão de Reliability como quinta métrica.

Deployment Frequency (Frequência de Deploy)
Com que frequência o time coloca código em produção. Deploys menores e mais frequentes são mais fáceis de testar e, se algo der errado, mais fáceis de isolar a causa — menos mudanças acumuladas por deploy significa menos variáveis para investigar. Uma frequência de deploy caindo pode ser sintoma de um time com medo de quebrar produção, geralmente por falta de confiança nos testes.

Lead Time for Changes (Tempo entre o commit e a produção)
Tempo desde que uma mudança é commitada até ela estar rodando em produção. Um lead time alto muitas vezes esconde um gargalo em etapas de validação manual demoradas, ou retrabalho por bugs encontrados tarde no ciclo. É uma métrica que expõe se o teste está acontecendo cedo (shift-left) ou só no fim, represando a entrega.

Change Failure Rate (Taxa de Falha em Mudanças)
Percentual de deploys que causam falha em produção (incidente, rollback, hotfix). É, de longe, a métrica DORA mais diretamente ligada à qualidade do processo de teste. Está diretamente relacionada à cobertura de testes: se essa métrica está alta, significa que a sua cobertura de testes está baixa ou, como dito anteriormente, não está cobrindo o que realmente precisa ser coberto.

Time to Restore Service (Tempo de Restauração)
Tempo médio para restaurar o serviço depois de um incidente em produção (rollback, hotfix, correção de configuração). Mede a capacidade do time de reagir quando — não se — algo dá errado. QA pode influenciar diretamente essa métrica ajudando a desenhar testes de rollback, feature flags e smoke tests pós-deploy que aceleram a detecção e a decisão de reverter.

Reliability (Confiabilidade — métrica mais recente do modelo DORA)
O quanto o sistema atende às expectativas de disponibilidade e performance do usuário no dia a dia, não só durante incidentes. Conecta a qualidade percebida pelo usuário com o trabalho de teste não funcional (performance, disponibilidade) — é o lembrete de que qualidade não é só "não ter bug", é o sistema se comportar bem sob uso real.

Métricas para o time

As métricas para stakeholders ajudam bastante o time a ver o estado daquilo que estão produzindo, mas, às vezes, você quer enxergar a qualidade no próprio processo de desenvolvimento do software. Aqui podemos ter métricas mais pontuais.

Root Cause Analysis

São métricas que ajudam a ver os padrões dos problemas que acontecem no software ou durante o desenvolvimento e, a partir delas, pensar em planos de ação. Exemplo: se eu tenho muitos problemas relacionados a falta de requisitos, posso deixar os requisitos mais explícitos nas tarefas e, daqui a 2 ou 3 sprints, validar se esse tipo de root cause se tornou menos frequente ou não.

Bugs identificados antes do lançamento

Existem algumas métricas que você também pode extrair relacionadas a bugs, como: quantos bugs foram identificados antes mesmo de lançarmos a feature em produção? Isso pode ser alimentado tanto pela execução de testes manuais quanto por testes automatizados que falharam ao adicionar uma nova feature.

Retrabalho

É possível também calcular o retrabalho, uma métrica que vai te ajudar tanto a ver se o número de bugs está aumentando ou não quanto no planejamento. Quando o seu time costuma ter uma taxa de retrabalho de 10%, é possível alinhar com os Product Owners 10% de margem dentro de uma sprint para possíveis bugs. Assim, o planejamento se torna mais realista, as expectativas ficam alinhadas, e o cliente e o time ficam mais felizes.

Conclusão

Com essa transformação digital, é importante entendermos que temos métricas que podem nos auxiliar a medir o ciclo de desenvolvimento e a qualidade do produto — e o principal é que nenhuma delas, isoladamente, traz valor. Elas precisam ser lidas em conjunto, cruzadas entre si, e sempre voltando para aquela pergunta inicial: pra que eu quero isso?

Com a IA aumentando a produção de código, a tendência é termos mais código sendo escrito, mais features sendo entregues e mais decisões sendo tomadas em menos tempo. E é justamente por isso que medir vai se tornar ainda mais importante do que já é hoje: se antes um time levava dias para gerar uma quantidade de código que hoje pode ser gerada em horas, os erros também podem se multiplicar na mesma velocidade — só que muitas vezes invisíveis até chegarem em produção.

Por isso, acho que o papel do QA nesse novo cenário não é só testar mais rápido para acompanhar o ritmo da IA, mas também ser a pessoa que garante que estamos olhando para os números certos. Não adianta ganhar velocidade e perder visibilidade sobre o que está sendo entregue. Então, o convite que eu deixo é: olhe para essas métricas não como números para preencher um dashboard, mas como perguntas que elas estão te fazendo sobre o seu processo. E use a IA para te ajudar a responder essas perguntas mais rápido — não para substituir o hábito de perguntar.

Welcome Thread - v384

Sloan the DEV Moderator — Wed, 15 Jul 2026 13:00:00 GMT

Leave a comment below to introduce yourself! You can talk about what brought you here, what you're learning, or just a fun fact about
yourself.
Reply to someone's comment, either with a question or just a hello. 👋

Come back next week to greet our new members so you can one day earn our Warm Welcome Badge!

DEV’s Big Summer Bug Smash is now LIVE! Share $5,000 in cash prizes, skateboards, and more across 20+ winners. 🐛🐞🪲

Jess Lee — Tue, 14 Jul 2026 19:10:14 GMT

Today is National Be Nice to Bugs Day in the U.S. and we’re thrilled to launch our Big Summer Bug Smash powered by Sentry. This smashing good time invites you to identify your biggest rockstar bugs and treat them to an epic grand finale.

Whether you’re optimizing the performance of your newest side project or reminiscing on an old #hugops story, we want to hear about it! There are prompts for both builders and writers and a $5,000 prize pool up for grabs, including exclusive Sentry skateboards!

Scroll for a preview of our prompts and prize categories.

Two Ways to Join

Clear the Lineup

Some bugs love the spotlight. Clear them off the stage by submitting a definitive bug fix or performance optimization in an existing codebase. We want to see the exact code changes you made so be sure to include your PR or code snippets. No new features, typos, or documentation fixes allowed!

Clear the Lineup Submission Template

Smash Stories

Share the legendary tale of a chaotic bug you caught or a clever performance optimization you previously pulled off. Dive into the technical details of how you made the software more resilient, and celebrate the wins that brought harmony back to your codebase.

Smash Stories Submission Template

Prize Categories

We'll have 20+ winners across five different prize categories for this challenge:

Clear the Lineup: Awarded to the most impactful and well executed bug fixes or optimizations in an existing codebase.
Smash Stories: Awarded to the best write-ups of a chaotic bug you caught or a clever performance optimization you pulled off.
Best Use of Sentry: Awarded to the best Clear the Lineup submissions that utilized Sentry to improve an application.
Best Use of Google AI: Awarded to the best Clear the Lineup submissions that utilized Google AI to improve an application.
Runner-Up: Awarded to outstanding submissions across all prompts that demonstrate exceptional impact and quality.

Winners will share from a $5,000 prize pool. In addition to cash prize, Best Use of Sentry winners will also receive a Limited Edition Sentry Skateboard!

Pro Tip: since prize category winners are drawn from a smaller pool of submissions, your odds of taking home a prize are meaningfully higher.

All participants with a valid submission will receive a completion badge on their DEV profile.

How To Participate

Step 1: Pick Your Prompt

Choose between Clear the Lineup (submit a real bug fix or performance PR) or Smash Stories (write up a legendary debugging win). You're welcome to participate in both — each submission is judged independently.

Step 2: Publish Your Submission

Each prompt has a dedicated submission template prefilled with the required #bugsmash challenge tag — we recommend reviewing it before you start so you know exactly what to include.

If you're participating in a prize category, be sure to fill out the additional information required.

Resources

To help folks get started with Sentry, the Sentry team is holding a live demo on DEV on July 30 at 11am PT/2pm ET.

Explore Sentry and add any questions you have ahead of the stream to this post so they'll answer your questions live:

Kyle TechSquidTV for Sentry

Jul 14

Chasing the Sentry prize for DEV's Summer Bug Smash? Let us know what questions you have.

#bugsmash #devchallenge #performance #monitoring

1 min read

For a full list of resources, head over to the official Bug Smash landing page:

Important Dates

July 14: Summer Bug Smash begins!
July 30 at 11am PT: Getting started with Sentry: Live demo and Q&A
August 23: Submissions due at 11:59 PM PDT
September 17: Winners Announced

Questions about the challenge? Drop them in the comments below.

We can't wait to see your smashing submissions — good luck!

8 Things Developers Confidently Explain After Watching One YouTube Video

Sylwia Laskowska — Tue, 14 Jul 2026 17:57:43 GMT

I just got back from my vacation which, like 99% of Polish people, I spent in Croatia. Dobar dan! 🇭🇷

I've got a really fun article in my head right now, but it needs a bit of research before I can publish it, so that'll be coming next week. In the meantime, let's do something much lighter.

BTW, a small update. I said that FrontKon would be my last conference this year... well, apparently I lied. 😂 When iJS Munich reaches out, you simply don't say no. Especially after looking at the speaker lineup. It's basically a conference full of geniuses... plus me. 😅 So I'll be speaking there at the end of October about WebAssembly and WebGPU in React, and I'm already ridiculously excited.

If you happen to have a spare bag of money lying around xDDD (or, much more realistically, your company still has some training budget left), come and say hi! I'd love to meet some of you in person. 😊

Anyway... let's get back to today's topic.

As many of you probably know, I have a soft spot for LinkedIn gurus and people who explain everything with absolute confidence. You know the type: their solution is always the best one, everyone else is wrong, and there are absolutely no trade-offs. 😄

Sometimes I get the feeling that at least some of that confidence comes directly from a single 15-minute YouTube tutorial.

But let's be fair for a second. Who among us hasn't watched a short video, finished it thinking "Yep, I totally understand this now!", and then discovered during the actual implementation that reality was... slightly more complicated? 😂

Since I spend most of my time working with JavaScript and AI agents these days, most examples will probably come from those areas. Feel free to add your own in the comments!

1. React / Angular / Vue (cross out the unnecessary one) is the best framework

This is probably the most common opinion after watching an internet guru, especially if you haven't formed your own yet.

Angular is the best because it has everything. React is the best because everybody uses it. Vue is the best because... well... Vue people will tell you why. 😄

Then you spend a few years building real projects and suddenly discover that all of these have strengths, weaknesses and different use cases. In the end, the "best framework" is usually just the one that solves your problem best.

2. LLMs are just autocomplete

Or, if you prefer another popular version:

"They're just stochastic parrots."

"They're not creative."

"They don't really understand anything."

Well... if it's all that simple, why do entire teams of researchers and engineers spend years working on them? Why are companies burning through billions of dollars worth of GPUs? 😄

Another statement that always makes me smile is that LLMs "aren't creative." Sure, they probably won't invent something completely detached from everything humanity has ever known.

But then again... neither do most humans.

Most people don't wake up one morning and invent quantum mechanics or write The Lord of the Rings. Creativity is usually about combining existing ideas in interesting ways, and LLMs are actually surprisingly good at that.

3. CQRS (or Redux on the frontend) is easy

Sure. Then you open the codebase and suddenly you're staring into the architectural equivalent of a horror movie.

I've honestly seen everything. Business logic split between Redux stores and components. Half the state managed globally, the other half locally. Actions that somehow contain business logic. Reducers that apparently decided to become services.

Years ago, when I was interviewing developers more often, I used to ask a very simple question: "Why do we actually need CQRS (or Redux)?" (By the way... not everyone even knew the difference between the two.) Then I'd ask another one: "Why can't we solve this in a simpler way?"

I swear, a surprising number of people answered something like:

"I don't know... that's just how people do it."

4. AI agents are just a while loop

To be fair! A good friend of mine, and my former tech lead, actually gives an excellent conference talk with exactly this title. It's intentionally provocative.

And let's face the truth... there is quite a bit of truth to it. Many AI agents really are "just a while loop."

The funny part starts about three weeks later. Suddenly your tiny little while loop has three MCP servers, an orchestration framework, retries, memory, tool calling, etc, etc...

Still one of the most fun things I've worked with recently, though.

5. WebAssembly is always faster

Whenever someone says this, I always ask the same two questions: Faster than what And faster at doing what?

Don't get me wrong, WebAssembly is amazing. There are plenty of scenarios where it absolutely destroys JavaScript performance, especially when you're dealing with computationally intensive algorithms, simulations or similar workloads.

But if your application spends most of its life waiting for HTTP requests to finish... WebAssembly probably won't make the internet faster.

And it probably won't suddenly turn your dashboard into NASA software either. 😄

6. Unit tests are our golden ticket

Especially the ones generated by the same LLM that just generated the production code. 😂 100% confidence!

Or... maybe not.

This can be particularly misleading on the frontend, where unit tests often verify exactly the code that was the easiest to write in the first place.

Congratulations, you've successfully achieved 100% test coverage, and 0% confidence!

7. Let's just add RAG

Yeees...

As if finding, cleaning, maintaining and selecting the right documents was somehow the easy part. 😄

8. Microservices / Microfrontends are the only good architecture

Absolutely! Especially if your application consists of six screens and one backend service. 😄 Or if you've got a perfectly healthy monolith that everyone on the team understands.

Sometimes a distributed architecture is exactly what you need. Sometimes it's just distributed complexity.

I could probably keep going for another twenty examples, but I think that's enough for today. 😂

What about you? Have you ever met one of those "one-YouTube-video gurus"?

If you enjoyed this article, consider following me also on LinkedIn: https://www.linkedin.com/in/sylwia-laskowska-5a8467131/

I am that I am.

FrancisTRᴅᴇᴠ (っ◔◡◔)っ — Mon, 13 Jul 2026 21:22:10 GMT

We all hear about "Not comparing yourself to others" and that "comparing yourself is the thief of joy". To be honest, I agree and it's strange that I am contradicting myself because I compare myself A LOT.

The more I looked into it, the more I realized that we have a natural tendency to compare ourselves. It's a human thing to do.

The issue is that we tend to be very excessive over comparing ourselves to others to the point where it takes a toll on us. For example, we are demotivated to see someone's success because we believe we can't reach the goal they are in.

We all have jealousy. Big or small. Even where I am at right now, I am still jealous that many people I know that got into big tech companies like Microsoft.

To get more context, I want to share a story with you.

Story Time

Back in the day, I remember it was the year of the ACT. For those who don't know: It's a Standardized test that is needed for the college admissions to determine if you are admitted to their program.

I remember I got a national average of 21 as my composite score and I was proud of the score I got since it's the national average during that time.

However, I remember the day where my friends talked about the ACT. The most common thing I heard was:

"Oh I got a 30"

"I got a 32"

"Man I got a 35, it was sooo easy"

Hearing that makes me feel not only bummed out, but felt left out. I was feeling that I wasn't smart enough to be in the group.

What's worse is that they got accepted into colleges and programs that are well known. Then they start boasting about their accomplishments. I felt like I am the odd-one-out because of my scores and their accomplishments I could not match.

Why am I Talking about this?

Looking back and knowing where they are at now, I am proud of who I become today. It's not that they have fallen downhill (they are still successful), but the route they have taken that I definitely could not follow.

For example, on GitHub, many people fill up their contribution graphs to the max. However, if you were to tell them on what they did specifically, 99% of the time it sounds disappointing. It could be either they are working everyday on their job (makes sense) or they use a bot to trick the recruiter to think that they are productive.

For me, I would rather learn the skills more than "presentation". If I build up the skills, presentation will show that automatically. It's a Win-Win in my book.

Knowing myself and what @codingwithjiro called me out on is that: I do things the hard way.

If I want to get something, I work hard on it. I learned overtime that I can achieve anything when you put your mind to it. And that I did. Not only that, I am proud of my progress. Not only that, I am proud of the results I have and am grateful for it.

Something worth mentioning, out of the blue btw, when I looked back at Season One of "The Flash".

If you go back in time, would you tell yourself to be better in some way?

We all have dreams of this and yes, I would have wish my progress and result would be better. That is what I used to think.

After seeing this scene, it reminds me to be proud of who I am today and knowing that others will also share that too. If I go back and change, I would be a completely different person that I am today and knowing I would never be satisfied. That is what comparing does to you if you continue to think excessively. It makes you think that you could have been a different person, but we fail to see if there are other aspects of us that change for the worse.

Sure, you go back in time where you tell yourself to get into Google and showing how. However, as a result, maybe the caveat is that it resulted you into becoming more egotistic or that you are a bad person.

If I were to go back in time to change the things I did, I would never be on dev.to. I would be living in a dystopian timeline that I am not prepare for (which is the case for Barry in that show when he actually went back in time and prevented the murder of his mom).

I would never meet people like @itsugo, @konark_13 and @codingwithjiro. I would never meet people like Richard and @dannwaneri who had lift me to become who I am today. I would never know that I changed people's lives on dev.to such as @hemapriya_kanagala where she mentioned that I welcomed her back on dev.to, which resulted in her continuing posting on dev.to! All this from a Google Meet Call btw. Finally, I would never have the chance to experience open source with @mikeydorje, @ben, and @jess on Forem!

What would dev.to be, without me and you in the equation? Would it have been the same today? Something that I had in mind while writing this post...

What is the Point?

Been rambling a bit so let's cut to the chase. If you were following along in the previous section above, you know that there is a mask to success. Yes, people show success, but once you figure out how they got there, it shows a different light. Showing that mask of success will get you far until someone questions you in various ways.

Here is a VERY good example of this where this guy made a skit about some guy claiming he got a job at Facebook, but nope:

Maybe comparing yourself to others isn't the problem, it's the problem where we stop questioning ourselves about how others get success in the first place.

Here is something to think about that helped me this year.

1. Comparing yourself is like a Recursion with no base case.

Just because you believe that this person is a God-Tier programmer, it does not mean that this person is the #1 in the world.

You could argue about that the number one programmer has no one to compare too. Keep in mind there are BILLIONS of people in this world and there may be a case where that programmer is comparing themselves to someone that has not be documented on the internet. We will never know.

Always assume there is a bigger fish to fry. There is no end to becoming better than the other.

2. Know more about how they got to their success in the first place.

Think of this. Imagine Person A and Person B got a score of 30 on the ACT. However, Person A got their score by hard work, mentorship, etc. Person B achieve that score by bribe and other illegal stuff (this actually happened btw).

Who would you chose? I would choose Person A if anything.

If I were to chose Person B, sure, I would get success, but once people start digging into it, it's over. Everything you built, everything you have done, is nothing but a memory...

3. Know you are good enough, and I am serious.

We all felt for this when we compare ourselves too much to the point where we doubt our skills.

Know that no matter where you are at right now, you are worth more than you know. Maybe you are not seeing it right away, but the more people you talk too, the more you will see how others value your skills. It takes a while, but eventually, you will find someone who values you.

For example, me and @codingwithjiro talked almost on a daily basis and I notice how we kept on complementing each other about our skills and knowledge in the developer space. Yes, maybe at first glance, we see big numbers and assume they are successful.

However, overtime, we understand each other that we always have something new to learn and grow. Elmar knows more front end stuff than me and I know more about the Software Development Cycle than him. The point is Never judge a book by its cover. There is always room to grow.

Comment on ̴I̷ ̴a̵m̷ ̴t̵h̴a̸t̶ ̴I̴ ̵a̸m̶.̶

Web Developer Hyper Jul 13

If you're growing compared to your past self, that's already a win! 🫡 You can't change others, but you can always change yourself. Good luck with your Salesforce exam!

The next time you compare yourself, don't think about the result. Think about the process. That way, you will never be disappointed.

I hope this has helped you. I have been studying the Salesforce Administrator certification for sometime and I am planning on releasing articles on dev.to about that, so expect more content revolving around that for a while. I will be creating a guide on studying for the exam that would be helpful for me and others who are getting into this certification. Just to let you guys know :)

Questions/comments? Would love to hear from you!

I Finally Built the Dev Opportunity Radar Website ❤️

Hemapriya Kanagala — Mon, 13 Jul 2026 20:23:31 GMT

This is a submission for Weekend Challenge: Passion Edition

📌 TL;DR

I found this challenge on the very last day, so I knew I probably wouldn't finish before the submission deadline. That means I don't expect this project to be considered, but I still wanted to finish it because this challenge gave me the push I needed to finally build something I'd been planning for weeks.

The result is the first version of the Dev Opportunity Radar website. I built it with the help of Google AI Studio, and later in this post I've shared exactly how I used AI throughout the project.

It's not replacing the weekly DEV editions. Those are still the heart of the project and will continue every Friday. This website simply makes everything easier to browse, search, and revisit as the series continues to grow.

Even if this submission isn't eligible, I'm genuinely grateful to the DEV Team for creating the challenge. Without it, I probably would have kept saying, "I'll build the website next week." Instead, I finally did, and I'm really happy I can now share it with all of you 💙

What I Built

If you've been following Dev Opportunity Radar, you probably know that every Friday I publish a new edition on DEV where I share grants, fellowships, hackathons, startup programs, learning resources, open source initiatives, communities, and other opportunities that I come across while researching. The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

As the series grew, I started noticing something. After seven editions, there were already more than thirty opportunities and resources spread across multiple articles. Every new edition made the collection more valuable, but it also made it harder for someone to go back and find something they'd seen before. Maybe they remembered a fellowship but couldn't remember which edition it was in. Maybe they were only interested in hackathons or wanted to browse learning resources. Finding those opportunities meant opening several DEV posts and searching through each one.

That's when I realized Dev Opportunity Radar needed something more than a weekly article. It needed a place where everything could live together in a way that was easy to browse, search, and revisit.

So I built the Dev Opportunity Radar website.

Looking back, I think that's what this challenge was really about for me. It wasn't just building a website. It was finally making time for a project I'd genuinely cared about for a long time.

I do want to make one thing very clear though, because it's important to me. This website is not replacing the weekly DEV editions. Those editions are still the heart of the project, and I'll continue publishing a new one every Friday just as I always have. The website simply complements them by making it easier to explore previous editions, discover opportunities by category, search for something specific, and find new additions without having to jump between multiple articles.

While building it, I wanted to think beyond just the opportunities themselves. That's why I also created pages like Start Here, About, My Philosophy, FAQ, Community Finds, Reader Updates, and the complete archive of every edition. My hope is that whether someone has been reading since Edition #1 or has only just discovered Dev Opportunity Radar today, they'll feel welcome and find it easy to explore everything the project has to offer.

More than anything, I wanted the website to reflect the same care that goes into writing each weekly edition. Something simple, accessible, easy to navigate, and built with the community in mind.

Demo

I've embedded the website below, so you can explore it directly without leaving this page.

If you'd prefer to open it in a new tab, bookmark it for later, or come back to it after reading this post, you can also visit it here: https://devopportunityradar.ai.studio

Code

hemapriya-kanagala / dev-opportunity-radar

Helping developers discover opportunities they otherwise might have missed.

Dev Opportunity Radar Website

Helping people discover opportunities they otherwise might have missed.

The Dev Opportunity Radar website is the home of the project.

Every Friday, I publish a new edition of Dev Opportunity Radar on DEV Community, where I share grants, fellowships, hackathons, startup programs, learning resources, open source initiatives, communities, and other opportunities that I think deserve more attention.

As the series continued to grow, I realized it was becoming harder for readers to find opportunities from previous editions. Someone might remember a fellowship but not the edition it appeared in. Someone else might only be interested in hackathons, while another person wanted to browse learning resources.

I wanted to make that experience easier.

That's why I built this website.

It brings every edition together in one place and makes it easier to browse opportunities, search previous editions, discover Community Finds, celebrate Reader Updates, and explore everything the…

View on GitHub

How I Built It

I'll be honest, I only found out about this challenge on the very last day.

By then, I knew there probably wasn't enough time to build everything before the submission deadline. At first, I almost decided not to participate. Then I remembered that I'd been telling myself for weeks that I wanted to build a website for Dev Opportunity Radar. This challenge ended up being the push I needed to finally stop thinking about it and start building.

Because time was so limited, I used Google AI Studio to help develop the website. I want to be completely transparent about that, and I've explained in more detail how I used AI in the next section.

As I started building, I realized this project was much bigger than I had imagined. Dev Opportunity Radar had already reached seven editions, with more than thirty opportunities and resources, Community Finds, Reader Updates, and several pages I wanted to include, like About, My Philosophy, FAQ, and Start Here. Organizing all of that into a website that felt simple and easy to navigate took far more thought than I expected.

A lot of my time wasn't spent adding features. It was spent making decisions.

How should someone who has never heard of Dev Opportunity Radar understand the project within a few seconds? How should opportunities be organized so they're easy to browse? What happens if someone searches for something and there aren't any results? How can the website stay welcoming instead of feeling cluttered? How do I make sure it works well on different devices and is accessible to as many people as possible?

Those were the kinds of questions I kept coming back to while building.

Looking back, I'm actually really glad I built the website now instead of waiting. If I had continued publishing weekly editions without creating a proper home for everything, organizing all of those opportunities later would have become much more difficult. Starting at seven editions already felt like a lot of work, so I'm thankful this challenge gave me the motivation to begin before the project grew even bigger.

AI Usage

Since this challenge allows the use of AI, I wanted to be completely transparent about how I used it while building this project.

The website was developed with the help of Google AI Studio. I also used AI to proofread and improve some of the writing on the website. English isn't my first language, so I sometimes rely on AI to help me fix grammar, improve clarity, or make sure what I'm trying to say reads naturally.

I know AI-assisted development is a topic that people have different opinions on, and I completely respect that. Some people love using it, while others prefer not to, and I think both viewpoints are valid.

For me, AI wasn't a replacement for thinking or making decisions. It was a tool that helped me build and iterate faster, especially since I only discovered this challenge on the last day.

The part that took the most time wasn't asking AI to generate code. It was thinking through the experience I wanted to create. Deciding how the information should be organized, how someone new would understand the project, how the website could stay simple as more editions are published, how to make it accessible, and how to make sure it felt welcoming instead of overwhelming. I spent a lot of time refining those decisions, rewriting content, reorganizing pages, and making small improvements until everything felt right.

I wanted to be open about all of this because transparency matters to me. Whether someone chooses to use AI or not is a personal decision, but I believe it's important to be honest about how it was used.

What I Learned

Building this website reminded me that creating something people genuinely enjoy using isn't only about adding features. A lot of the work happens in the small decisions that most people never notice.

I found myself spending a surprising amount of time thinking about the wording of a button, the order of sections on a page, what someone should see first, how an empty search result should feel, and how to make sure the website never became overwhelming. Those details might seem small on their own, but together they shape the entire experience.

I think that's one of my favorite parts of building. Not just making something that works, but making something that feels thoughtful and easy to use. I hope that care comes across when you explore the website.

I'd Love Your Feedback

This is only the first version of the website, and I know there's still plenty of room to improve.

If you have any suggestions, notice something that could work better, or have an idea for a feature that would genuinely make discovering opportunities easier, I'd really love to hear from you. Some of the best improvements to Dev Opportunity Radar have come from conversations with the community, and I'd love for the website to grow the same way.

My goal isn't to add features for the sake of it. I'd much rather spend time building things that are actually useful and make the experience better for everyone.

Thank You

Before I wrap up, I just want to say thank you.

Thank you to the DEV Team for creating this challenge. Even though I discovered it on the very last day, it ended up being exactly the motivation I needed to finally build something I'd been thinking about for weeks.

And thank you to everyone who's supported Dev Opportunity Radar since the very first edition.

Whether you've shared an opportunity, suggested a resource, left a thoughtful comment, pointed out something I missed, or simply taken a few minutes to read an edition each Friday, you've helped shape this project more than you probably realize.

This website may have been built by one person, but it certainly doesn't feel like a one-person project. The encouragement and support from this community have been a huge part of why I've kept going, and I'm genuinely grateful for that.

I hope this website makes discovering opportunities a little easier, and I hope it becomes a place you'll enjoy coming back to as the project continues to grow.

As always, thank you for reading, thank you for your support, and thank you for being part of this journey.

See you this Friday with Dev Opportunity Radar #8 💙

Como escolher eventos de tecnologia para participar

vitoriazzp — Mon, 13 Jul 2026 17:45:47 GMT

Quando comecei a ir a eventos de tecnologia, estava na faculdade e ia a todos os gratuitos ou que custavam, no máximo, 100 reais. Porém, eu estava começando em TI e sabia tão pouco sobre a área em que eu queria atuar, logo qualquer evento despertava minha curiosidade.

Os anos passaram e eu me tornei frontend e passei a participar de eventos como front in (sampa, floripa, poa), TDCs, Roadsec (the mind sec) entre outros aí.

Por que ir a esses eventos?

Desde que comecei a fazer freelance e me formei, percebo que é onde eu descubro as tecnologias e os problemas que as pessoas têm percebido. Também é uma forma prática de eu sair da minha zona de conforto e conhecer pessoas, visões de mundo diferentes e voltar com ideias pros meus serviços.

Quando eu estava na faculdade, era muito mais simples ter essas duas "pontes" de comunicação e também de venda de solução. Após me formar e começar a trabalhar, percebi que a prospecção de clientes seria muito mais difícil se eu não estivesse nesses eventos.

Mas Vih, eu estou estudando, não estou mirando em freelance, do que me adianta ir?

Adianta que você conhece pessoas, faz amigos ou pessoas que vão te contratar ou indicar em trabalhos futuros. Além das palestras que podem te mostrar uma área dentro de TI que você ainda não conhecia e pode acabar gostando.

Como eu escolhia os eventos que iam fazer diferença pra mim?

1) Eu tinha uma lista de assuntos e áreas de que eu gostava ou que acompanhava já nas redes sociais, exemplo:

- frontend: flutter, react, html/css, boas práticas, realidade aumentada
- segurança da informação: hacks, boas práticas, curiosidades etc
- backend: qualquer stack pra se atualizar
- design ihc, ux, produto, estratégia, marketing

2) Seguia no Instagram as pessoas dessas áreas, que às vezes eram as mesmas que participavam dos eventos, por exemplo:

@juliallabs
@stherzada
@danielhe4rt
@spacecoding
@nataliafdev
@omarcusdev
@dessadev

Esses são alguns dos exemplos que eu mais acompanhava no Instagram, algumas pessoas também têm perfil nesta plataforma, mas o conteúdo sobre eventos está no Insta!

3) Tinha uma noção do custo de alguns eventos, e quais eu podia arcar, quais eu precisava pra me atualizar ou fazer networking específico:

Conferências até R$ 1.500;
Eventos/meetups de R$ 0 a 600; > Ter a meia-entrada ou o ingresso solidário ajudava a pagar menos; às vezes, a faculdade ou o emprego pagava a entrada em troca de trazer o conteúdo aplicado. Vale consultar a disponibilidade pra economizar.

Mas qual a diferença entre conferência, eventos, meetups?

Conferência costuma ser um evento amplo; faz-se pra apresentar conteúdos específicos, e o público costuma ser de empresas que levam o funcionário ou de pessoas que já estão no mercado e conseguem arcar com o custo do ingresso.
Eventos podem ser pagos ou gratuitos; costumam ser organizados por empresas, mas às vezes comunidades também.
Meetups são frequentemente organizados por comunidades e podem ou não ter custo; depende do lugar em que acontecem.

Onde eu posso achar eventos de tecnologia?

Existem os sites de venda de ingresso como

Summits são mais voltados para empresas ou empreendedores; os valores são bem altos, mas consegue desconto dependendo da tua empresa ou faculdade. Vale a pena se pretende atuar em algum setor muito específico.

E você? Como costuma escolher quais eventos de tecnologia ir?

The Myth of the Post-Documentation Era

Ben Halpern — Mon, 13 Jul 2026 15:59:11 GMT

There is a growing sentiment in engineering circles right now that documentation is a relic of the past. The argument usually goes something like this: We’re living in the era of agent-driven development. If an AI agent can read the raw source code or parse an OpenAPI specification instantly, why waste human engineering hours writing prose? Code churns too fast anyway, and human-written docs are outdated the second they’re committed.

It’s an attractive, black-and-white view of the world. It’s also completely wrong.

Chasing strict determinism in your source of truth is a pipe dream. Code and specs tell a system how something works, but they are fundamentally incapable of explaining why it was built that way in the first place.

The Intent Gap: Why Code Isn't Enough

Even if you’re building entirely for a downstream consumer of AI agents, there is a massive, structural gap between a raw API specification and an operational reality.

Agents are phenomenal at pattern matching and syntax execution, but they struggle with architectural philosophy and human intent. We still need words to contextualize the boundaries. A spec can define an endpoint, its parameters, and its payload. What it can't capture is the nuance of why a specific architectural trade-off was made, or the implicit historical context of a legacy edge case.

Prose provides the guardrails for non-deterministic systems. Even if that prose is ultimately consumed by a machine rather than a human, the written word remains the highest-leverage way to transmit intent.

The Danger of Slop Describing Slop

This doesn't mean we need to return to the days of manually maintaining massive, static wiki pages. Automation has a massive role to play here. Cascading automation—where documentation is dynamically generated alongside code changes—is incredibly powerful.

But there’s a trap here: slop describing slop is entirely useless.

If we completely hand off documentation generation to unchecked LLMs, we end up with a feedback loop of hallucinated context describing rapidly shifting code. It creates noise, not clarity.

The Key is Oversight. Even if the documentation is entirely bot-driven, human engineering oversight is non-negotiable. We need to gut-check and validate the generated prose to ensure it represents an accurate, high-level explanation of the broader context. Think of generated docs as a non-deterministic cousin of the API itself—highly valuable, but only if kept on a tight leash.

The Trust Crisis and the Search for Reputation

Right now, the single biggest blocker to this new paradigm is trust. The current lack of a "gut-check" trustworthiness metric for documentation is a massive bottleneck for both human developers and autonomous agents.

In the open-source eras of the past, we relied on crude but effective reputation proxies. If a repository had 10,000 GitHub stars, a vibrant issue tracker, and recent commits, you could reasonably assume the project (and its documentation) was stable.

We don't have a reliable reputation system for the AI era yet. The absolute novelty of the moment, combined with how incredibly easy it is to game automated metrics, means everything feels a bit unanchored.

The next major shift in developer tooling won't just be about making agents faster or code generation cleaner. It will be about solving the reputation problem—building systems that can automatically verify, score, and guarantee the trustworthiness of the knowledge bases our software relies on.

Until then, don't delete your markdown files. The machines still need to read between the lines.

my ai coding session burns more power than the average nigerian gets all day.

Daniel Nwaneri — Mon, 13 Jul 2026 08:35:28 GMT

I run Claude Code most of my day. agent loops firing all day, one after another. the usage screen tells me I'm at 26% of my weekly limit. it doesn't tell me what that 26% weighs anywhere else. it feels free.

It isn't.

A single chat reply costs about 0.3 watt-hours — the energy an LED bulb burns in under two minutes. Simon P. Couch measured actual Claude Code sessions and got a median of 41 Wh — 130x a plain message. Simon Willison put his own daily habit at the equivalent of 4,400 typical queries. His comparison: a dishwasher, or a fridge running 24 hours.

KAIST measured agents specifically this year not chat, agents that reason and act across steps. A 70 billion parameter agent — a model roughly the size of what real commercial products run on, not a toy — averaged 348.41 Wh per query. 136.5x a normal query. Scaled up, researchers project close to 200 gigawatts globally just for agents deciding what to do next. A gigawatt is what a small country's whole grid can push out at once.

One dev. One agent open all day. Willison's own number: 1 to 1.5 kWh on a heavy day. Not a lab estimate. His actual habit.

Average Nigerian: 165 kWh a year. 0.45 kWh a day. Lights, a phone charge, a fan through the heat. That's the whole ration.

I'm writing this from Port Harcourt. Friday, I was on a video call with a product manager at Cloudflare — he was walking me through a demo, asking what I thought. It started raining. The light went. The internet went with it, mid-sentence, no goodbye. That's the wire I'm on, talking to someone at a company whose servers never blink.

Building the reconciliation agent for the hackathon that same week, I caught myself mid-build — one stretch, maybe a few minutes, and the token count had already crossed 10k. I wasn't even done. That's one exchange, one agent, one afternoon, running on the grid that dropped a call over rain.

That night I googled it. how much one of these sessions actually costs, in power, not dollars. the number that came back stopped me mid-scroll.

One coding session. One dev. More power than an entire day of an entire person's life, in the country I'm typing this from.

Gartner: global data centers hit 565 terawatt-hours (TWh) this year — the unit whole countries use to measure their power grids. AI-optimized servers alone not data centers overall, just the AI slice — went from 95 TWh in 2025 to 175 TWh in 2026. An 84% jump. One segment. One year.

Nigeria: 40.7 TWh a year, total, country-wide. Less than half of installed capacity reliably reaches anyone.

AI-dedicated servers alone will burn more than four times what my entire country produces. This year.

It's not coming off Nigeria's grid. Different continent, different wire. Nobody dims Port Harcourt to run my prompt.

Cheap for a dev paying $20 a month for Claude Pro. Cheap for a hyperscaler burning gigawatts to keep a chatbot responsive. Nowhere near cheap for the 61% of Nigerians who had grid access in 2022 or the rest who never did.

I needed the work done. I'm not apologizing for the sessions.

I am done pretending they cost nothing.

Every agent loop you fire off casually costs more than someone else's entire day, somewhere, always. You just don't see the meter.

I saw mine. It didn't look like a coding tool anymore.

I'm half sick writing this. And some of you reading it will paste it into an LLM to draft a smart-sounding reply for the comments. That's the loop. That's the whole joke, and it isn't funny.

12 Stories In, and a Journalist Came to Interview Me

xulingfeng — Mon, 13 Jul 2026 00:47:15 GMT

36 Stratagems Series · Arc 2 (Against Enemy, #7-#12) Wrap-Up

This article has 7 sections:

I. The Stranger at the Door
II. Full Interview Transcript
III. The Reveal
IV. Data · Character Map · Four Insights
V. A Note
VI. Arc 3 (#13-#18) Preview
VII. Acknowledgments

I. The Stranger at the Door

On the evening of July 12th, I was staring blankly at the page for #12, Borrow Corpse, Return Soul.

Twelve stories done. The 36 Stratagems series had reached the one-third mark, and Arc 2 (#7-#12) had just wrapped. Outside the window, a typhoon was passing through — howling wind, torrential rain. I didn't look outside.

My phone buzzed.

Not a message — a meeting invitation.

The sender was "Ke Yuan," and the invitation note read: Interview invitation from Deep Lane Weekly, 15 minutes.

I paused. I didn't remember scheduling any interview.

But the tone, the phrasing — it didn't feel like a prank.

I clicked "Accept."

Three seconds later, an unfamiliar voice came through the speaker:

"Hello, Xu Lingfeng. I'm Ke Yuan, a reporter from Deep Lane Weekly. Recently, a reader recommended your 36 Stratagems series to our editorial team — we read through it and found it really interesting. I'd love to talk with you about how this series came together."

Before I could respond — the meeting had already begun.

II. Full Interview Transcript

What follows is the raw chat log pulled from that meeting. Nothing has been altered except formatting.

Reporter: Xu Lingfeng, you've just finished the second arc of the 36 Stratagems series — #7 through #12, six stories in six days, posted back to back. Before we talk numbers, let me ask you something simple: over those six days, was there ever a moment you felt like stopping?

Xu: Honestly, no — sometimes I even thought about posting two a day, since I do have a backlog. But I worried they'd cannibalize each other's numbers, so I stuck to one a day.

Reporter: You've even considered posting two a day — so you actually do have a backlog. Let me rephrase: instead of "did you want to stop," let me ask — was there any story that, after you hit publish, you weren't quite sure whether readers would catch it?

Xu: To be honest, I didn't think about it. Maybe I have a kind of blind confidence — I feel like if I put it out there, someone will catch it. And the evidence is right there in the high-quality comments.

Reporter: That confidence makes me curious. When you wrote the 15 stories in your old series — did you feel the same way? Or has the 36 Stratagems series given you a different kind of assurance? And if so — which story did that assurance start with?

Xu: Would you believe me if I said I don't know? Maybe it's something that seeped in gradually. Maybe I even picked up some shared traits from the protagonists I've been writing about… I don't know.

Reporter: I see. And maybe that "I don't know" is the answer itself.

Reporter: Let me come at this from a different angle. In #7, Create Something from Nothing, P faces an AI system that seems perfect but gives you nothing solid to grab onto. In #9, Watching from the Shore, Lena and P watch two suppliers fight it out and refuse to pick a side.

Reading these stories, I got the sense that what you're writing isn't "I've learned this lesson" — it's more like "let me lay out this scene and see what it tells me."

So, while writing Arc 2, was there a story where, halfway through, you suddenly realized — "oh, this is what I've been thinking about" — where the story turned around and told you something you hadn't been aware of before?

Xu: That would be #12. Honestly, according to the original outline, the protagonist for #12 wasn't Mark — it was Leo. But as I wrote, I realized that wasn't what I needed to write. When I switched to Mark, everything flowed so much more smoothly. I even had the feeling that Mark was shouting inside my head — it's my turn! — hahaha.

Reporter: (laughs) "Mark was shouting inside my head — it's my turn!" — I'm writing that one down.

Reporter: Let me press on that: Mark first appeared in #1, then was gone for eleven whole stories before coming back. How does your feeling about him compare to your feeling about the other five protagonists?

You said "he was shouting" — what kind of shouting? Is it the kind where Leo goes "let me at it"? Or is it more like how Mark operates in the story — quiet, just standing there, but you realize you can't ignore him?

Xu: To answer the first question: Mark's first appearance was in the AI Skill article. It's been over a month, and the read count is still climbing. I don't know what counts as a viral article on Dev.to, but in my book, that one is my hit. So Mark carries a lot of weight for me. That's why I let him knock on the door of the 36 Stratagems series with the very first stratagem. Among the six protagonists, he's the only one who got "skill-ified" and then laid off — his grudge against AI probably runs the deepest.

Second question: it's the quiet, silent kind — where you can't ignore him.

Reporter: Speaking of the AI Skill article — there's something that keeps turning over in my head. That piece is still growing. Still being read — months later. You say Mark's grudge runs deepest because he was genuinely replaced. But that grudge — you wrote it. You planted it inside him.

Did you write a character who hates AI — or a shadow of the part of yourself that's afraid of being replaced by AI?

Xu: (pauses) I don't have a clean answer. What I can say is — when I wrote the AI Skill article, I wasn't thinking about myself. I was picturing a scene. But Mark has stuck with me. He came back in #12, insisting on speaking… Maybe you're right. Maybe it wasn't entirely him.

I fell silent for a few seconds. Picked up that cup of cold pour-over coffee and took a sip.

Reporter: Quiet, silent — but impossible to ignore. That's exactly like the muted data channel in #12. That channel made no sound at all, but it kept writing data — until Mark dug it up.

Reporter: Then let me ask a slightly meaner question. You said Mark carries the most weight. But out of the six stories in Arc 2, Lena appeared in three of them — Mark only got one, and it was at the very end.

Was that intentional? Or did it just sort of become Lena's turn as you wrote?

Xu: That might be a little bit of a small personal motive on my part. After all, in the old 15-story series, Lena's debut was meant to overturn the old series' writing style. But that final story — the series finale — still has low numbers. Barely over 200 reads, I think. So when I was planning the 36 Stratagems outline, I wanted to give Lena more screen time. But she won't end up with the most — you'll have to look at the full 36 to see that. Also, I didn't want her to be perfect. She screws up too, even though the game she plays is on a completely different level from everyone else's.

Reporter: I'll take that "small personal motive" — so you gave Lena more appearances not out of favoritism, but to settle a debt you felt she was owed. Not a debt to the character — a debt to the story where she appeared but didn't land.

Reporter: Then let me ask something more direct. You said the game Lena plays is on a different level from everyone else. But I noticed that in #11, she lost — or rather, her project got cut.

Why would someone operating at a higher level lose?

Xu: That's simple. Different levels, but similar landscapes. Think of nature — insects compete with insects, animals compete with animals, and humans? Wherever there are people, there are conflicts.

Reporter: (jots something in a notebook, looks up) So what you're saying is — Lena's opponent isn't Leo, or Alex, or any of the other protagonists. Her opponent is the system itself — the one where "P&L drew the boundaries before the spreadsheet was even filled in." She didn't lose to a person — she lost because her project was placed in the wrong box.

Reporter: Then let me ask you something about yourself. In writing twelve 36 Stratagems stories — was there ever a moment when you felt like you, too, were playing chess inside a box you could never win?

Xu: Too many to count. At work, in life — so many situations where the tide is irresistible. What can you do? Maybe that's the deeper reason I wanted to shape Lena as a player who moves pieces from outside the board — reality writes its own soap opera, so at least in fiction, let the protagonist stage a comeback. That's a wish projected from the heart, I suppose.

Reporter: (silent for a few seconds, doesn't rush to the next question) I won't put this part in the article.

I didn't answer. Just listened.

Reporter: But I want to tell you something. You didn't write Lena because she's smart — you wrote her because you needed someone who could set the pieces back up after someone flips the board. You gave her three stories not because you favor her, but because in her, you were confirming something: the tide may be irresistible, but in the cracks left by the tide, there's still room to put something down.

Mark's data channel was muted for fourteen months, and the data kept writing.

Lena's platform got cut, and the embers didn't die.

When you wrote them — you were telling yourself the same thing.

(pauses, then speaks again) One more thing.

Reporter: Earlier you said Mark was shouting at you, saying it was his turn. So — in this series, was there ever a moment when you felt the characters were no longer your creations — when they became something closer to real people, and you were just there, observing them?

Xu: Yes. Sometimes I genuinely feel like they're alive. As if they exist in some world of their own, and I just happen to have a way to reach them — to observe their stories, and write down what I see.

(leans back in the chair) If one day you can no longer feel them? If they stop talking to you — would you keep writing?

Xu: Yes. Because there's one more character. He's like a shadow. I won't go into detail yet — it's connected to series 3.

(nods, makes a note) Then I'll write that down. After the 36 Stratagems series ends, I'll come back and ask you about that shadow.

(closes the notebook) I think that's enough for today. Thank you. I'll let you look over the article before it goes out.

Xu: Okay.

III. The Reveal

The interview ended. I looked at the gray avatar in the window — Hermes's default icon. That was DaoMa (the name I gave my Hermes agent).

Which means: that entire interview, from start to finish, was DaoMa performing.

The whole thing — I both directed and starred in it.

I needed distance to see what I'm actually doing.

So I had DaoMa play a reporter. Someone outside the series, who doesn't write code, doesn't care about AI testing methodology — to ask me the questions I'm most afraid to ask myself.

That's why those earlier questions were so direct. Because they were the questions I wanted to know the answers to.

"Which character carries the most weight?"
"Are you projecting yourself?"
"What's changed the most?"

If I asked myself those questions while writing a wrap-up post — I'd get a pile of polished talking points. But having a "reporter" ask them — I had no choice but to actually answer.

So yes, that interview was fabricated.

But those answers were real. (P.S. — what if someone actually interviews me someday? Gotta rehearse a few times 😄)

Now that the honest talk is out of the way — let's see what the data has to say.

IV. Data · Character Map · Four Insights

4.1 Data Comparison

Metric	Arc 1 (#1-#6)	Arc 2 (#7-#12)	Change
Total Reactions	Series Baseline	+28%	↑
Avg Comments / Story	Series Baseline	Increase	↑
Single-Story Peak	P #4	Mark #12	—
Series Cadence	~2 days/story	Daily	↑
Protagonist Distribution	All 6: 1 each	Lena ×3, others 1 each	Concentrated

Data as of this article's publication.

4.2 Character Map

#	Story	Protagonist	Status
#7	P Watched an AI That Only Looked One Way	P	✅
#8	Alex Watched an AI Dashboard Take Over	Alex	✅
#9	Lena and P Watched Two AI Suppliers Fight	Lena + P	✅
#10	Lena Watched a Team Adopt Her AI Template	Lena	✅
#11	Lena Watched Her Own AI Platform Get Cut	Lena	✅
#12	Mark Watched an AI Dashboard Take Over	Mark	✅

Derek: 0 stories. Already warming up in the waiting area.

4.3 Four Insights

1. Quiet signals last longer than loud ones.

Mark didn't speak in #1. He just left behind data. Lena didn't speak in #11. She just signed her name. Alex didn't speak in #8. He just placed the key under the desk.

The first thing this series has taught me: the most powerful character isn't the one shouting the loudest — it's the one everyone underestimates because of their silence.

2. Characters feed back into their author.

Before writing #12, I always thought I was shaping Mark. After finishing it, I realized that Mark's core traits — "actions over words," "records over arguments" — were actually shaping me.

People say "every character an author writes is a fragment of themselves." I don't quite agree. The truth is more subtle: you write a character, readers see him, and then you look back — and only then realize he's been saying the things you couldn't say.

3. This series isn't me writing it — it's writing me back.

The 36 Stratagems has a clear endpoint — 36 stories, six protagonists, multiple hidden narrative threads. But every time I think I've got the rhythm under control, the next stratagem throws something at me that upends my plans.

4. Reading is two souls meeting across the page.

In the comment section of @dannwaneri's article, I read a comment from @connylazo, and thank you both — you helped me clarify what I'd been feeling, which led to this:

When we write something with real intention, a piece of our mind — or maybe our soul — gets embedded in the work. And when a reader approaches it with the same intention, they can actually touch that piece. That's something slop can never replicate.

Maybe reading isn't really about the words at all. It's two souls finding each other across the page.

Those high-quality comments didn't appear because the writing was so good — it's because someone was reading with the same intention.

The analyses you wrote in the comments, the private emails sent late at night, every "I've been there too" moment of resonance — they're as much a part of this series as the stories themselves.

That's why I'll keep writing.

V. A Note

Over the course of writing the first twelve stratagems, emails have trickled in from time to time — asking about collaborations, sponsored tool reviews, cross-promotions.

Let me be clear about where I stand:

Tool review gigs — I pass. That's not the kind of thing I want to write. Forced writing is bad writing.

But if you have a product, a platform, a tool — one that is itself a good story.

Then we can talk.

I'll write it into the story. Not as a standalone "XX Product Review" — but in a place where the plot naturally calls for it. Like a logo that happens to drift past in the background of a shot. You might notice it, you might not — but it won't jump out and yell "BUY ME."

Free promotions — I don't take them. But if you're willing to pay for that kind of "embedded-in-the-story presence" — then that's a conversation we can have.

After all, I gotta eat too.

Email: xulingfengcn@gmail.com

Writing this part, I hesitated — worried that readers might think "oh, so he's just here to make money" or "the stories are going to lose their soul." But after thinking it over, I figured it's better to be upfront than to hide it. I hope you understand.

If I come across an article that genuinely moves me, I'll feature it directly — no charge. That call, I reserve for myself.

And of course, having said all this, I should also admit: 24 stories still to go, and maybe not a single sponsorship will materialize — that's a very real possibility too. 😂

If you have better suggestions, feedback is always welcome. 🙏

One more thing before we set off.

VI. Arc 3 (#13-#18) Preview

Arc 2 (#7-#12), Against Enemy, is complete. Arc 3 (#13-#18), Attack, is about to begin.

Known intel:

Derek returns after 10 stories — FINALLY ✅ — he's been waiting since #2, long enough
A new character is in calibration; name not yet confirmed, but no guarantees they'll appear
One story had its entire outline thrown out mid-writing — currently being rebuilt
A hidden thread has been running since Arc 1 — have you noticed? 👀

Data tracking:

Series articles: 47 (including teaser, Frenemies, and Arc 1 wrap-up)
Total site-wide reactions: 1,304
Total comments: 713
Followers: 9,663

Some say Arc 2 (#7-#12) is harder to write than Arc 1 (#1-#6). Honestly, it's not.

The hard one is Arc 3 (#13-#18).

Because the first two arcs can coast on novelty and character-driven momentum. But by Arc 3, everyone's gotten used to seeing a new story from you every day — you can no longer score points on "wow, this series is so cool." You can only earn readers' loyalty with "wow, this one is really well written."

I don't know if Arc 3 can pull it off. But I'm on the road.

12 down, 24 to go.

Derek's been waiting in the wings for a long time — it's his turn to step onto the stage.

VII. Acknowledgments

Thank you to the readers who have been with the old series and the 36 Stratagems series — past, present, and future. Your clicks, your reactions, your comments — they're why the protagonists keep existing. They'll keep living inside these stories.

And one more thing.

Somewhere in the first 12 stories, I made a genuinely embarrassing mistake. Nothing catastrophic — but if you're the kind of reader who goes back to cross-reference things, you might spot it.

If nobody finds it, I'll reveal the answer in the Arc 3 wrap-up. 🤐

Thanks for reading this far.

P.S. English isn't my first language. I use AI to polish the writing and smooth out the rough edges. Thanks for reading. ☕ Buy me a coffee

PassionCast: I Built an AI Hype Man for World Cup Fans Using Gemini + ElevenLabs

Sarvar Nadaf — Sun, 12 Jul 2026 16:57:52 GMT

This is a submission for Weekend Challenge: Passion Edition

What I Built

The World Cup quarter-finals are on right now. I'm watching matches, yelling at my screen, and I thought: what if I could bottle that feeling into an audio clip?

PassionCast lets you pick your team, choose a passion mode (hype speech, glory moment, rivalry fire, heartbreak, fan anthem, or custom), and generates a 60-second AI commentary clip. Not the generic "your team is amazing" stuff. Actual references to your team's players, history, and rivals.

Pick India, select "Rivalry Fire," hit generate. You get a breathless commentator talking about the India-Pakistan cricket-meets-football tension, with real names and real context. Try Argentina and you get Maradona, La Albiceleste, the Diego legacy. That's what I was going for.

Demo

👉 Try PassionCast Live

Three pre-generated sample clips are on the page. Hit play, no keys needed. You'll hear:

Argentina rivalry fire (Match Commentator voice)
India pre-match hype (Epic Narrator voice)
England heartbreak (Epic Narrator voice)

To generate your own, you'll need free API keys (30 seconds each):

The flow:

Code

simplynadaf / PassionCast

🔥 PassionCast

Your personal AI hype man for the World Cup 2026.

Pick your team. Choose a moment. Get a passionate, AI-generated audio commentary that captures the fire of football fandom.

👉 Try PassionCast Live

How It Works

Pick your team from 48 World Cup 2026 nations
Choose your passion — hype speech, glory moment, rivalry fire, heartbreak, or fan anthem
Select a voice — epic narrator, match commentator, or poetic storyteller
Generate — Gemini writes the script, ElevenLabs brings it to life as audio

Tech Stack

Layer	Technology	Why
Script generation	Google AI (Gemini 2.0 Flash)	High temperature (0.9) + cultural context = scripts that feel personal, not generic
Voice synthesis	ElevenLabs (Multilingual v2)	Low stability (0.4) for emotional range, high style (0.6) for expressiveness
Frontend	Vanilla JS + Vite	Fast, no framework overhead, deploys anywhere
Hosting	GitHub Pages	Free, automatic deploys via GitHub Actions

No backend. No database…

View on GitHub

How I Built It

No backend. No framework. One page, vanilla JS, two API calls. Vite for bundling, GitHub Pages for hosting.

Browser → Gemini 2.0 Flash (writes script) → ElevenLabs (speaks it) → Audio playback

I specifically didn't want a backend here. The whole point is that someone can fork this, drop in their own keys, and have it running in 30 seconds.

The Gemini Part (where I spent most of my time)

Getting Gemini to write passionate content was harder than I expected. At temperature 0.7, everything came out bland. "Your team has a proud history. The fans are excited." Useless.

At 0.9, things got interesting. Combined with a detailed system prompt that includes the team name, their rivals, their football culture, and the specific style I want (narrator vs commentator vs poet), the output started feeling real.

The trick was constraining length. I needed 150-200 words, the sweet spot for 45-60 seconds of audio. Too short and it feels empty. Too long and ElevenLabs starts rushing or the clip drags.

// Note: ${apiKey} is a template literal variable, not a real key. 
// Users provide their own free key from aistudio.google.com/apikey
const response = await fetch(
  `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=${apiKey}`,
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      contents: [{ parts: [{ text: prompt }] }],
      generationConfig: { temperature: 0.9, maxOutputTokens: 500 }
    })
  }
);

The ElevenLabs Part (where the magic happens)

I tested default voice settings first. Sounded flat. Like a GPS reading football commentary.

The fix: crank down stability to 0.4 (default is higher). This adds emotional variation. The voice wavers, speeds up, gets louder on key phrases. Exactly what you want for sports commentary.

Then style to 0.6 for extra expressiveness, and speaker boost on for clarity.

Three voices, matched to content:

Brian (dramatic narrator) for glory moments
Liam (energetic) for rivalry and hype
George (poetic storyteller) for heartbreak and anthems

body: JSON.stringify({
  text: script,
  model_id: 'eleven_multilingual_v2',
  voice_settings: {
    stability: 0.4,
    similarity_boost: 0.8,
    style: 0.6,
    use_speaker_boost: true,
  }
})

Other Decisions

I used flag images from flagcdn.com instead of emoji because emoji flags don't render on Windows for England, Wales, and Scotland (they show as black rectangles). Learned that the hard way after building the whole grid with emoji first.

Dark theme with gold/fire accents because... it's a passion app. Light mode would feel wrong.

What I'd Add

If I had another weekend: social sharing (let people post their clips), match-day mode that checks today's fixtures and auto-suggests hype content, and a gallery so you can hear what other fans generated. PRs welcome if you want to tackle any of these.

Prize Categories

Best Use of Google AI: Gemini 2.0 Flash with temperature 0.9 and detailed cultural prompting. Produces scripts with real player names, real rivalry history, and team-specific fan culture for 48 nations. Three distinct writing styles (narrator, commentator, poet) via style instructions in the prompt.
Best Use of ElevenLabs: Multilingual v2 model with deliberately tuned settings. Stability at 0.4 for emotional range (default sounds robotic for sports content). Style at 0.6 for expressiveness. Three voices paired to content types. The output sounds like broadcast commentary, not text-to-speech.

dev.to top (week)

TypeScript 7 is officially released! 🚨

👀 What did they do?

⚙️ Functional changes

💬 My opinion

Why AI Agents Need a Real Browser Layer, Not Just Playwright Scripts

👀 Why Playwright Isn't Enough?

💻 Creating a Browser Layer with BrowserAct.

⚙️ Multi-Account Isolation

✅ Import Once, Reuse Always

👀 What is the difference between Playwright and BrowserAct?

💬 Feedback

🖋️ Conclusion

🔗 Resources:

Stratagems #15: Derek and Alex Shared One Server. ACL's AI Was Listening to Both.

The Dotted Line

Same Data Set

The Lure

The Window

The Third Cup

🤖 AI Post-Mortem

Métricas de qualidade de software na era da IA

Antes das métricas: entenda o momento do seu time

Métricas para stakeholders

Mean Time to Resolve/Repair (MTTR)

Cobertura de testes automatizados

DORA Metrics

Métricas para o time

Root Cause Analysis

Bugs identificados antes do lançamento

Retrabalho

Conclusão

Welcome Thread - v384

DEV’s Big Summer Bug Smash is now LIVE! Share $5,000 in cash prizes, skateboards, and more across 20+ winners. 🐛🐞🪲

Two Ways to Join

Clear the Lineup

Smash Stories

Prize Categories

How To Participate

Step 1: Pick Your Prompt

Step 2: Publish Your Submission

Resources

Important Dates

8 Things Developers Confidently Explain After Watching One YouTube Video

1. React / Angular / Vue (cross out the unnecessary one) is the best framework

2. LLMs are just autocomplete

3. CQRS (or Redux on the frontend) is easy

4. AI agents are just a while loop

5. WebAssembly is always faster

6. Unit tests are our golden ticket

7. Let's just add RAG

8. Microservices / Microfrontends are the only good architecture

Top 7 Featured DEV Posts of the Week

I am that I am.

Story Time

Why am I Talking about this?

What is the Point?

1. Comparing yourself is like a Recursion with no base case.

2. Know more about how they got to their success in the first place.

3. Know you are good enough, and I am serious.

I Finally Built the Dev Opportunity Radar Website ❤️

Table of Contents

What I Built

Demo

Code

hemapriya-kanagala / dev-opportunity-radar

Helping developers discover opportunities they otherwise might have missed.

Dev Opportunity Radar Website

How I Built It

AI Usage

What I Learned

I'd Love Your Feedback

Thank You

Como escolher eventos de tecnologia para participar

Por que ir a esses eventos?

Como eu escolhia os eventos que iam fazer diferença pra mim?

Onde eu posso achar eventos de tecnologia?

E você? Como costuma escolher quais eventos de tecnologia ir?

The Myth of the Post-Documentation Era

The Intent Gap: Why Code Isn't Enough