Frontend Feeds

Today

Front-end, in one read.

The latest from the sources worth following, newest first.

  • DEV CommunityThe Giantsread at source

    CCAR-F vs CCAR-P: what each Claude Architect exam actually tests (from building 700+ practice questions)

    Over the last few weeks I built original practice exams for both Claude Certified Architect exams, working only from Anthropic's public exam guides. Claude drafted the questions, and a separate blind pass re-answered every item with the key hidden; anything that disagreed got fixed or cut. Here's the format side by side, plus the patterns that kept showing up. Format at a glance CCAR-F (Foundations) CCAR-P (Professional) Questions 60 63 Time 120 min 120 min (~1.9 min per item) Pass mark 720/1000 scaled 720/1000 scaled Structure 4 of 6 scenarios per sitting 7 domains, Integration heaviest (19%) Heaviest domain Agentic Architecture (27%) Integration (19%) Patterns that trip people up The bigger-model answer. Options that fix an architecture problem by upgrading the model or stuffing more context are usually distractors. The exam rewards fixing the design. Prompt vs. hook. If a rule has to hold every time (a refund cap, a required check), the right answer is a deterministic control such as a hook or gate, not an extra instruction. Scope boundaries. The CCAR-F guide explicitly excludes topics like fine-tuning, embeddings, vision and computer use. An answer that depends on them is a red flag. Multi-response items. Each tells you how many answers to pick. Count before you eliminate. Where config belongs (CCAR-F, Claude Code domain, 20%). User-level vs. project-level vs. path-scoped rules. "Put it in your user config" is wrong when a whole team needs it. How to study Take one full timed mock as a diagnostic. Pacing matters, especially on CCAR-P. Read your per-domain results and drill the weakest domain, not your favourite. For every miss, write down why the tempting option was wrong. That's the skill the exam tests. Tell me where these are wrong The most common complaint about existing practice banks is that they test recall instead of judgment between two close options. I wrote these to fix that, but I'd rather hear where I missed now than in a review later. So the first 13 people per course can get in free. Take a full mock and post in the comments whatever is off: a wrong key, an ambiguous question, a domain that feels over- or under-weighted, or a mock that was easier than the real thing. You don't need to leave a review to use a code. If you do rate it on Udemy, make it honest, good or bad. Disclosure: I sell these on Udemy. They're unofficial and not affiliated with Anthropic. Each course has 6 full timed mocks with every option explained. CCAR-F: free with code CCARF-EARLY (first 13), otherwise $9.99 with SIGMA999 through Nov 10: https://www.udemy.com/course/claude-architect-foundations-ccar-f-practice-exams/?couponCode=SIGMA999 CCAR-P Vol. 1: free with CCARP-EARLY (first 13), otherwise $9.99 with SIGMA999 : https://www.udemy.com/course/claude-architect-professional-ccar-p-practice-exams/?couponCode=SIGMA999 CCAR-P Vol. 2: free with CCARP2-EARLY (first 13), otherwise $9.99 with SIGMA999 : https://www.udemy.com/course/claude-architect-professional-ccar-p-practice-exams-vol-2/?couponCode=SIGMA999 To use a free code, open the link and swap the code in at checkout. Questions about the format are welcome in the comments too.

  • DEV CommunityThe Giantsread at source

    Prove Your Characterization Test Can Fail Before You Refactor

    A characterization test that passes on old and new code proves nothing. It only proves the code changed in ways your assertion cannot see. My rule now: every characterization test must go red on a deliberate behavior change first. Here is the gate I run before touching a messy repo. It records real behavior, freezes it into tests, then probes those tests with small forced changes. A test that survives a probe gets fixed or deleted. Never trusted. The failure mode: green tests, silent behavior change Picture a function that totals report rows. Your test asserts one number: the grand total. # tests/test_rows.py def test_total (): assert total_for ( " fixtures/report.csv " ) == 1842.50 Now refactor the row ordering, or swap rounding from half-even to half-up. The total may shift by a cent, or stay identical while row order changes. Either way your gate is blind to the change you just made. The fix is not more assertions written in advance. You do not yet know which behaviors matter. So measure sensitivity instead: inject a known change, watch the test react. Step 1 — Record real behavior before you reason about it Do not invent fixtures from reading source code. Run the code and capture arguments plus outputs. # trace_capture.py import functools , json , pathlib TRACE = pathlib . Path ( " traces/rows.jsonl " ) def traced ( fn ): @functools.wraps ( fn ) def wrapper ( * args , ** kwargs ): out = fn ( * args , ** kwargs ) record = { " fn " : fn . __name__ , " args " : list ( args ), " kwargs " : kwargs , " out_repr " : repr ( out )} with TRACE . open ( " a " ) as fh : fh . write ( json . dumps ( record ) + " \n " ) return out return wrapper Wrap the entry point, run the existing test suite or a scripted job, then unwrap. Twenty to fifty traces usually beat two hundred hand-written cases. Two honest caveats. First, repr for floats is stable enough for comparison but ugly for reading. Second, scrub anything sensitive in args before the file leaves your machine. Step 2 — Freeze traces into characterization tests Convert each trace line into one parameterized test. The test asserts today's behavior, bugs included. # tests/test_rows_frozen.py import json , pathlib , pytest from report.rows import total_for LINES = pathlib . Path ( " traces/rows.jsonl " ). read_text (). splitlines () CASES = [ json . loads ( line ) for line in LINES if line . strip ()] @pytest.mark.parametrize ( " case " , CASES , ids = lambda c : f " trace- { c [ ' args ' ][ 0 ] } " ) def test_frozen_behavior ( case ): got = total_for ( * case [ " args " ], ** case [ " kwargs " ]) assert repr ( got ) == case [ " out_repr " ] Run it once. Every case should pass, because you recorded the same code. If a case fails here, your trace is stale or nondeterministic. Stop and fix that before any refactor. A flaky gate is not a gate. Step 3 — Write probes, not more assertions A probe is a tiny patch that must change observable behavior. Keep each probe to one line where possible. Probe class Example change What it should catch Constant shift + 0.01 on a total Numeric blindness Boundary swap >= becomes > Edge cases at thresholds Ordering change sorted(...) removed Tests asserting only aggregates Error path change raise becomes return None Missing failure assertions Format change str(x) becomes f"{x:.2f}" Type and shape blindness Store probes as data, not as scattered branches in your test file. # probes.py PROBES = [ { " name " : " half_up_drift " , " file " : " report/rows.py " , " old " : " return round(total, 2) " , " new " : " return round(total, 2) + 0.01 " , " test " : " tests/test_rows_frozen.py " }, { " name " : " threshold_swap " , " file " : " report/rows.py " , " old " : " if qty >= 10: " , " new " : " if qty > 10: " , " test " : " tests/test_rows_frozen.py " }, ] Step 4 — Run the sensitivity harness Never patch your working tree. Copy the repo, apply one probe, run one test file, record the outcome. # sensitivity.py import pathlib , shutil , subprocess , sys , tempfile from probes import PROBES IGNORE = shutil . ignore_patterns ( " .git " , " __pycache__ " , " *.pyc " , " .venv " ) def run_test ( repo : pathlib . Path , test : str ): cmd = [ sys . executable , " -m " , " pytest " , test , " -x " , " -q " , " -p " , " no:cacheprovider " ] return subprocess . run ( cmd , cwd = repo , capture_output = True , text = True ) def probe ( repo : pathlib . Path , p : dict ) -> str : with tempfile . TemporaryDirectory () as tmp : work = pathlib . Path ( tmp ) / " repo " shutil . copytree ( repo , work , ignore = IGNORE ) target = work / p [ " file " ] src = target . read_text () if p [ " old " ] not in src : return " INVALID: anchor not found " target . write_text ( src . replace ( p [ " old " ], p [ " new " ], 1 )) r = run_test ( work , p [ " test " ]) if r . returncode == 0 : return " GREEN: test is blind to this change " if r . returncode == 2 : return " INVALID: collection or usage error " return " RED: expected " if __name__ == " __main__ " : root = pathlib . Path ( " . " ). resolve () for p in PROBES : print ( f " { p [ ' name ' ] : 20 s } { probe ( root , p ) } " ) python sensitivity.py Exit code 2 matters here. A broken patch or import error looks like a failure but proves nothing. Treat it as INVALID, not as success. This one distinction prevents most false confidence. Step 5 — Read the report with a decision table Do not just count red results. Classify each test. Observed Meaning Action RED on its intended probe Test is sensitive Keep as gate GREEN on every probe Blind test Add an assertion or delete it RED on unrelated probes Over-fitted test Loosen brittle exact-match assertions INVALID Probe or fixture broken Fix before trusting anything RED before the patch Stale trace Re-record, then re-run Keep a small table in the PR description. Fill it honestly. Test file Probes run RED GREEN INVALID tests/test_rows_frozen.py 2 1 1 0 One green cell is a finding, not a delay. It tells you exactly where the refactor can go wrong. Step 6 — Make the smallest safe change Only now edit production code. One behavior per commit. Re-run the frozen tests and the sensitivity harness after each commit. git diff --stat main...HEAD python -m pytest tests/test_rows_frozen.py -q python sensitivity.py If a frozen test goes red during the refactor, stop. Either the refactor changed behavior on purpose or it broke something. Both cases need a written decision, not a re-recorded trace. Re-recording mid-refactor destroys the gate. Where a free model and a free server genuinely help Two parts of this workflow are tedious and untrusted at the same time. Probe authoring is tedious: reading a diff to find one-line mutations takes minutes per probe. Probe execution is untrusted: model-drafted patches run real code on a real filesystem. MonkeyCode's free model access is a reasonable source for probe candidates and extra fixture cases. You paste a function and ask for behavior-changing one-liners, then review each one. MonkeyCode's free server option is a reasonable place to run the harness, because a throwaway machine keeps experimental patches off your laptop. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Keep one rule: the model proposes, the harness decides. A probe is credible only when it turns a real test red. Do not claim the server isolates anything you have not checked yourself. Verify the environment before running private code there. Limitations and who should skip this This gate needs a deterministic entry point. Code that hits a live database, a clock, or a third-party API will produce unstable traces. Freeze those dependencies first, or skip the approach for that module. Skip it too if the code is safety-critical and freezing bugs needs product sign-off. Characterization tests preserve current behavior, including behavior nobody wants. Also skip it for one-file scripts. Two hours of harness work for a thirty-line file is a bad trade. A useful refactor gate is one that has been seen failing. Break your tests on purpose, in a copy, before you trust them. If you want to try the harness without touching your machine, the free server option is a fair place to start.

  • DEV CommunityThe Giantsread at source

    Stop Letting the Worker Rewrite the Checklist

    TL;DR: When an AI agent works for days across many sessions, the failure is rarely that the model was not smart enough. In Anthropic's own controlled experiments — same model, only the harness changed — agents failed because the state file let them quietly redefine what "done" meant, because each new session started building before checking whether the last session had broken something, and because the worker graded its own work and, predictably, praised it. The fixes are embarrassingly structural: a checklist the worker can only tick, a startup ritual that verifies the baseline first, and a separate evaluator whose only job is to be picky. I run a personal AI operation that hands work between sessions and agent generations every day. For a long time I treated handoffs as a writing problem: if the next agent got confused, the handoff document had not been detailed enough. Anthropic's two long-running-agent studies, published in November 2025 and March 2026, convinced me that is backwards. The problem is not how much the checklist says. It is how much of it the worker is allowed to change. In the first study, an initializer agent expanded a one-line prompt into a feature list of more than 200 items, stored as JSON, every item starting as failing. Each following coding session was allowed to do exactly one thing to that file: flip an item's passes field, with evidence. Deleting items or rewriting the tests was explicitly unacceptable. The authors chose JSON over Markdown because, in their observation, a model is less likely to inappropriately rewrite or overwrite it — a qualitative observation, not a measured guarantee, and I am treating it that way. The principle underneath it does not depend on the format: narrow the writable surface. If progress, evidence, and the definition of done all live in one free-form document the executor edits, then the executor is both athlete and rulebook. Fake completion does not need dishonesty. It just needs editing privileges. The same study names the second failure I kept seeing in my own fleet: a new session walks in, looks around, sees progress, and either declares victory or starts stacking new work on a half-broken base. The prescribed ritual is fixed and boring. Confirm the workspace. Read the progress log and recent commits. Take the single highest-priority unfinished item. Then run a basic end-to-end test before writing anything new — and if the baseline is red, fix the baseline and build nothing. One feature per session, and leave a clean state behind. Boring is the point. Handoffs lose information by design; rituals are how you stop paying for that loss repeatedly. The grader cannot be the worker The March follow-up adds the finding I now consider non-negotiable. Left to evaluate itself, an agent will confidently praise its own work even when a human can see it is mediocre — and, the authors note, tuning a separate evaluator to be skeptical is far easier than teaching a generator to criticize itself honestly. So they split the roles: a planner that expands the brief into a spec, a generator that builds one sprint at a time, and an evaluator that clicks through the running application like a user and fails the whole sprint if any dimension falls below a hard threshold agreed in advance, in a written sprint contract, before code is written. That separation is not free, and pretending otherwise would be dishonest. In one example the full harness cost more than twenty times a single agent — and the single agent's version had a core feature that simply did not respond to input, while the harness version was actually playable. In another, roughly four hours and about $124 in tokens still left an evaluator catching real gaps on its second pass. My reading, following the authors, is conditional: an independent evaluator earns its cost only when a task sits beyond what the current model can reliably complete alone. Inside that boundary it is pure overhead. Small, short, reversible tasks should not wear the full harness. Scaffolding expires The most useful line in the follow-up is the one most teams will skip. Every harness component encodes an assumption that the model cannot do something. When the model improves, that assumption expires — silently. The authors stopped guessing and started removing one component at a time. When a newer model arrived, sprint decomposition, once load-bearing, could be removed entirely without a drop; the planner and evaluator still carried weight, so they stayed. A parallel result from JetBrains Research points the same way on context: simply masking old tool outputs cost about half as much as running raw and matched or slightly beat elaborate LLM summarization on solve rate, while summarization actually lengthened trajectories by 13 to 15 percent. The cheapest structural move first; complexity has to prove it beats the simple version. So here is the standard I am applying to my own operation, and I would argue it belongs in yours. Write state as a checklist the worker can tick and attach evidence to, never rewrite. Start every session by proving the baseline still works. Let someone who did not do the work decide whether it is done, against a contract written before the work began. And once per model generation, take your scaffolding apart one piece at a time and keep only the pieces that still carry weight. Reliability over days is not a smarter model. It is a narrower pen, a fixed ritual, a separate grader — and the discipline to retire the scaffolding that last year's model needed and this year's does not. — Jiahui Miao, founder of vertciti, building a personal AI operating system for one.

  • DEV CommunityThe Giantsread at source

    Outgrowing My First Data Pipeline

    not affiliated with or endorsed by the NBA. In short: a daily pipeline that pulls NBA game, roster and player data, loads it into Google BigQuery, models it with dbt into tables and metrics, and serves them on a Grafana dashboard. The NBA's API blocks cloud servers, so Airflow in the cloud tells a worker on my home network to do the extraction. Stack: Apache Airflow, FastAPI, Tailscale, Google BigQuery, dbt (with Astronomer Cosmos), Grafana, Azure, Docker, GitHub Actions. Results: about 550 player API calls on the first run against 0 to 5 on a typical day (over 99% fewer), transient API failures recover through retries with no manual steps and three real failure modes found and fixed, a firewall block, a dbt test race and a service crash loop. The Business Context This project started with a clear analytics goal, answering performance questions such as how a player's True Shooting Percentage changes before and after a mid-season trade, or what a team's true home-court win rate is. To answer them reliably, I needed a daily refreshed dimensional model and a semantic layer ready for BI dashboards. For scale, a regular season has 1,230 games, so fact_game_stats gains 2,460 rows per season (one per team per game) and fact_player_stats roughly 25,000 to 30,000 (about 20 to 26 player rows per game). This is small data. The two archived seasons hold 4,920 team-game rows and 52,957 player-game rows, and as of 6 November the current season added 2,729 player-game rows. The challenges in this project came from the network and the API, not from volume. The first obstacle appeared as soon as I moved orchestration to the cloud. The NBA's stats API sits behind a Firewall that blocks traffic from cloud data-center IP ranges. In v1 of this project, I split the system into two: Apache Airflow in an Azure VM, and extraction on a local Ubuntu machine (edge worker) with residential connection. The two talk over a Tailscale mesh VPN, so the worker does not need its ports opened to the public internet. The full breakdown is in the v1 case study . v1 architecture: a synchronous trigger over Tailscale, loading into Snowflake. v1 solved extraction, but running it day to day exposed new problems such as: synchronous timeouts, overlapping runs, and storage that grew every day on a Snowflake trial that was about to expire. v2 is the response. Controlling Storage Growth In the original Snowflake design, each daily load appended the full season-to-date payload to the warehouse, so the same games were stored again every day, bloating the warehouse with duplicates. v2 moves the warehouse to Google BigQuery and splits storage into two: Static archives: completed seasons live in _history tables that are written once, at season rollover. Active season: the current season is loaded with WRITE_TRUNCATE , so each daily run replaces the previous one instead of adding to it. Downstream, fact_player_stats is partitioned by game_date and clustered by team_key and player_key . At roughly 25,000 to 30,000 rows per season, the table is tiny. With a 10 MB billing minimum, partitioning this table is purely for practice, clustering alone would be enough at this size. From Synchronous Calls to Asynchronous Trigger-and-Poll In v1, the synchronous design caused timeouts during long extractions due to aggressive rate-limiting from the API, failing Airflow tasks even when the worker eventually succeeded. v2 replaces this with an asynchronous "trigger-and-poll" pattern. Think of it like ordering food. Instead of waiting at the counter, tying up resources and causing timeouts, Airflow drops off a POST request, receives a tracking number (an HTTP 202 Accepted response with a task ID), and steps aside. The local FastAPI worker does the heavy lifting in the background, tracking its own state in a local SQLite database. Airflow simply checks a status endpoint every 10 seconds to see if the job is done. Splitting a job across two machines creates new failures, however, this is how the worker handles them: Duplicate triggers: if a task of the same type is already running, the API returns the existing task ID instead of starting a second extraction. An Airflow retry can never cause two concurrent runs. Crash recovery: on startup, the worker marks any task left pending or running as failed: worker restarted , so Airflow retries instead of polling a dead task. Timeouts and retries: each extraction task has a two-hour execution_timeout , and the DAG retries failed tasks three times at 10-minute intervals. Checkpointing the Slowest Extraction Player biographies ( player_info ) need one API call per player, making them the slowest and most failure-prone extraction. On extraction failure, the script is designed to resume from the last record instead of restarting from scratch. Before making any API requests, the script queries BigQuery to see which players are already in the warehouse, then it fetches only the missing IDs. If it hits a hard API block (five consecutive failures), it doesn't just crash. A finally block saves every player extracted to BigQuery, before the task fails completely. When Airflow retries 10 minutes later, the script resumes where it left off, and staging keeps only the latest row per player, so there are no duplicates downstream. The dbt Test Race Condition I use Astronomer Cosmos to run dbt because it turns each model into its own Airflow task. By default it also creates a test sub-task per model, and that caused a failure I did not expect. After building dim_game , Cosmos ran dbt test --select dim_game . Because this command selects every test referencing dim_game , it executed the relationships check on fact_game_stats.game_key before the downstream fact_game_stats table had even been rebuilt. The result: Failure in test relationships_fact_game_stats_game_key__game_key__ref_dim_game_ Got 4930 results, configured to fail if != 0 The numbers explained the failure. raw_team_game_results_history held exactly 4,920 team-game rows, which is two full regular seasons, and the 4,930 orphans are those rows plus 10 more from the current season. At the time, the DAG ran against the dev target, whose rolling 7-day filter stripped the history out of staging. The freshly rebuilt dim_game had lost the history while the not-yet-rebuilt fact table still contained it, so every historical game looked orphaned. I have since changed the dev filter to keep the history tables and moved the scheduled run to the prod target. I fixed the race itself with RenderConfig(test_behavior=TestBehavior.AFTER_ALL) , which builds every model first and then runs all tests together. The trade-off is that tests no longer stop downstream models from building. A failing test now fails the DAG after the marts are already built. The v2 DAG in Airflow: three extraction tasks, then the dbt task group, with one run task per model and a single nba_analytics_test task at the end. Infrastructure Hurdles Memory Limits Concurrent dbt compilations pushed RAM above 90%, and Airflow tasks were killed with SIGTERM . I limited concurrency through docker-compose ( PARALLELISM=2 ) and set max_active_runs=1 on the DAG. API Schema Drift When the NBA API added a column to the roster payload, 17 columns became 18, the static UNION ALL between history and daily tables broke. The dbt_utils.union_relations macro now aligns the columns and pads missing ones with NULL s. Separately, append loads pass ALLOW_FIELD_ADDITION , so a new column does not fail a load into an existing table. The Silent Data Drop When migrating to BigQuery, I partitioned fact_player_stats by game_date to optimize query costs. During a full refresh in prod , dbt reported successfully scanning 11.8 MiB of historical staging data, but it only inserted 2,700 rows into the final mart, exactly matching the current season. No errors were thrown. The culprit was the BigQuery Sandbox's mandatory 60-day expiration policy. When a table is partitioned by a date column, BigQuery calculates expiration against the partition's date, not the execution date. Because my historical data was from 2024 and 2025, BigQuery accepted the inserts and then instantly, silently dropped them for being older than 60 days. Removing the partitioning config forced BigQuery to treat the table as a single block expiring 60 days from the run date, successfully recovering all 55,000+ historical rows. Data Modeling Trade-offs To track players changing teams, dim_player is a Slowly Changing Dimension (Type 2). My first version built this team history from daily roster snapshots. Then, to save BigQuery storage in v2, I started overwriting the active roster table every day. Because the truncated table is re-stamped with today's snapshot_date on every run, a traded player's effective_start_date on the new team moved forward to "today" on every run. I rebuilt the history from stg_player_game_logs instead. That anchors each team change to the date of the player's first game for the new team, a date that never moves. The trade-off is a known edge case. Because history is derived from games played, a player who signs with a new team in July keeps his old team in dim_player until his first game with the new team.Since the goal is tracking in-game performance, this is acceptable. From Warehouse to Dashboard To close the loop, I connected Grafana to the marts. The "NBA Overview" dashboard answers the questions this project started with: Who is playing efficiently? In the dashboard's seven-day window, Luka Dončić leads with an average Game Score of 30.5 and a True Shooting percentage of 68.5%. Victor Wembanyama follows at 25.9, and Stephen Curry's 68.2% is the other elite shooting mark. Does home court matter? Home teams won 62 of 121 games (51%) in the same window. Which teams are trending? The 7-game rolling point differential panel separates the strongest and weakest teams at a glance. These are small samples, a few games per player, so the point here is the plumbing rather than basketball analysis. The dashboard is provisioned as code from the repository. Docker Compose installs the BigQuery plugin, a provisioning file defines the data source, and the dashboard JSON is committed, so a fresh deployment needs no manual setup in the UI. I reach Grafana and Airflow over Tailscale, and the scheduled DAG builds the marts with the prod target. The Live Dashboard can be found here: http://100.96.130.48:3000/ Results Far fewer API calls: the first player_info run makes about 550 calls to cover every active player on a roster. A typical daily run makes 0 to 5, for newly signed players or call-ups, which cuts the daily load on that endpoint by more than 99%. Resumable extraction: after a failure, player_info continues from the missing players instead of starting over, and the active-season tables are replaced on each run rather than appended to. Retries in practice: on 4 November the first game_logs request was dropped by the API within milliseconds ( Remote end closed connection without response ). The failure reached Airflow, and the retry ten minutes later loaded 2,413 player rows and 214 team rows without any manual step. No concurrent duplicate runs: the duplicate-trigger guard, crash recovery and timeouts mean a retry or a worker restart should not leave Airflow polling forever or running two extractions at once. A dashboard on the marts: a Grafana dashboard, provisioned from the repository, reads the production tables. What I'd Do Next Alerting: SMTP is not configured, so a failed run only shows in the Airflow UI. A webhook on_failure_callback and a health check on the worker would have caught the crash loop on day one. Season rollover: archiving a season currently means editing configuration files by hand. Passing the season and an archive mode as API parameters would remove that step. Github Link: https://github.com/Cliffe16/NBA-Analytics-Pipeline

  • DEV CommunityThe Giantsread at source

    Cosa fa Local Model di osFoundry, dalla scelta di un modello open alla sua messa a punto sul tuo computer

    Sono le 16:40 di un giovedì e in una finestra c'è aperta la bozza di un contratto. Vorresti che un'IA sistemasse la formulazione, ma il documento non può uscire dal tuo portatile, e non sai quale dei cento modelli open su Hugging Face riuscirebbe anche solo a caricarsi con 16 GB di memoria. E non hai voglia di passare la serata in un terminale per scoprirlo. Un unico gruppo nella sidebar per tutto quello che fai con i modelli open Local Model è la parte di osFoundry che si occupa dei modelli open-weight in esecuzione su hardware che controlli tu. Nella sidebar dell'app desktop è una categoria a sé, divisa in tre sottosezioni: Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks) e Measure (Eval, Benchmarks, Safety). Se hai usato Ollama o LM Studio, la parte Run ti sembrerà familiare: trovi un modello, lo scarichi, ci parli. La differenza è che lo stesso gruppo ti permette anche di ridurre un modello, fare fine-tuning sui tuoi esempi e testarlo con le tue domande, così l'intera vita di un modello resta in un'unica app. L'inferenza sul dispositivo usa un server llama.cpp incluso, quindi non serve installare nient'altro. Questa guida copre le nove schermate più usate: Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval e Benchmarks. Un primo sguardo a Explore Quasi tutti iniziano da Explore, e il suo layout mostra come ragiona l'intera categoria: prima la tua macchina, poi i modelli. Il pannello Filters a sinistra raggruppa i task di Hugging Face (Text Generation, Summarization, Translation, Embeddings, più i gruppi Multimodal, Vision e Audio) e ha una casella di ricerca. Il banner in alto legge la tua macchina prima di mostrare qualsiasi cosa. Nell'esempio sopra indica 16 GB di memoria unificata, circa 12 GB utilizzabili per un modello, circa 9 GB liberi in quel momento, e che le stime presuppongono Q4_K_M e un contesto di 4K. Ogni scheda ha un badge di compatibilità: verde Fits, ambra Tight, rosso Too big, ciascuno con una stima della memoria. Non viene nascosto nulla; i modelli che ci stanno sono semplicemente elencati per primi. I pulsanti Providers e My Registry in alto a destra portano ai fornitori di API cloud e ai modelli che hai già. Cliccando su una scheda si apre il dettaglio, dove Install Locally scarica una versione del modello, di solito un GGUF quantizzato che corrisponde al badge. Tre persone, tre modi di usarlo Una sviluppatrice indipendente con un solo portatile Maya sviluppa progetti personali su un MacBook da 16 GB. Vuole un modello locale per scrivere messaggi di commit e brevi note, soprattutto per lavorare offline in treno. Apre Explore, filtra per Text Generation e salta tutto ciò che ha il badge rosso. Due candidati sono verdi, quindi li installa entrambi con Install Locally. Poi apre Playground, scrive un prompt e aggiunge i due modelli come pannelli. Playground invia lo stesso prompt a due-quattro modelli contemporaneamente e mostra le risposte affiancate, con il tempo al primo token e il numero di parole sotto ogni pannello. Più tardi trova un modello che le piace, ma che esiste solo come file F16 a piena precisione. Sono circa 15 GB, troppi per il suo portatile. In Quantize lo seleziona sotto "The model to shrink", sceglie Q4_K_M, il livello che l'app consiglia alla maggior parte delle persone, e avvia. Il llama-quantize incluso riscrive il file sulla sua macchina; non viene caricato niente. Nell'esempio sopra il risultato è di 4.58 GiB, 3.3 volte più piccolo dell'originale. Prima di fidarsi, clicca Measure quality, che confronta il nuovo file con l'originale e compila le colonne "same top token" e KLD medio nella tabella Compare, poi Measure speed per i token al secondo. Un clic su Try it in Playground lo rimette accanto agli altri due. Chiude la serata con un modello che ci sta, numeri che mostrano quanto è costata la riduzione e nessuna cronologia del terminale. Un piccolo team con un desktop potente Un'agenzia di quattro persone ha in ufficio un desktop con molta memoria e diversi portatili leggeri. I modelli grandi stanno solo sul desktop, ma tutti vogliono usarli. Sul desktop qualcuno apre Servers, seleziona This Mac e va nella scheda Access. Spunta "Allow access from other devices on the local network (LAN)" e attiva Remote Access. Il pannello elenca allora tutti i modelli locali che la macchina servirà. Sotto Device keys clicca New key, le dà il nome del portatile di un collega e clicca Create key; ogni chiave si può revocare singolarmente, e una chiave solo per l'inferenza può eseguire modelli ma non accedere alle sessioni degli agenti. Su ogni portatile il collega apre Servers, clicca Add Server, inserisce l'indirizzo del desktop, incolla la chiave e usa Test Connection. Appena si collega, i modelli del desktop compaiono nel selettore dei modelli del portatile come qualsiasi altro modello. L'app stessa avverte che questo traffico è HTTP in chiaro, quindi è pensato per reti di cui ti fidi, come la LAN dell'ufficio. Poi qualcuno apre Benchmarks, clicca New Benchmark, sceglie il modello e lascia la suite Quick. L'esecuzione registra token al secondo, tempo al primo token e latenza, così il team capisce se il modello condiviso è abbastanza veloce da usare durante le chiamate o solo per i batch notturni. Se sembra lento, Servers ha anche una scheda Config dove si può impostare un piccolo modello bozza sotto Speculative Decoding, poi Restart now, e rilanciare il benchmark per confrontare. Il team si ritrova con una macchina che fa il lavoro pesante, una chiave per portatile che si può ritirare senza disturbare gli altri e una risposta misurata a "è abbastanza veloce?". Un responsabile operativo che non scrive codice Ken gestisce l'assistenza clienti di un piccolo negozio online. Ha due domande: quale modello legge correttamente i totali delle fatture, e un modello può imparare a rispondere con il tono del negozio? Per la prima va in Eval e clicca Custom Benchmark. Gli dà un nome, incolla dieci fatture con il totale che si aspetta per ciascuna, lascia Exact Match e clicca Create Benchmark. Poi New Eval Run: spunta due modelli sul suo computer, spunta il suo benchmark e clicca Start Evaluation. Le domande vanno a ciascun modello sulla sua macchina. In questo esempio un modello ottiene 90 e l'altro 70, e la colonna Diff mostra il distacco di 20 punti. È un risultato sui suoi documenti, non la classifica di qualcun altro. Per la questione del tono raccoglie qualche centinaio di vecchi messaggi dei clienti con le risposte che il team ha davvero inviato, una coppia per riga. In Datasets può importare quel file, oppure cercare dati pubblici nella scheda Hub, e usare "Use for Training" per passarlo. In Training clicca New Job e segue i quattro passaggi: Base Model, Dataset, Config e Review. Sotto Training Target sceglie Local (This Device), che la schermata descrive come esecuzione sulla GPU del dispositivo e gratuita, con LoRA come metodo. Dopo Start Training, il job mostra la loss mentre gira. Quando finisce, l'adapter addestrato compare in My Models accanto al modello base da cui deriva, e "Chat with your model" sull'esecuzione completata lo prepara per il runtime sul dispositivo, così può fargli una domanda in Playground. Alla fine ha un modello piccolo e privato e un benchmark da rilanciare ogni volta che valuta un nuovo modello. Dove Local Model passa il testimone La categoria non vive da sola. I modelli che installi o colleghi compaiono nella stessa lista di modelli usata dalla chat, quindi un modello locale può rispondere a una normale conversazione o essere confrontato in Playground con un modello cloud che hai aggiunto in Providers. Da Explore, "Use in Notebook" apre un notebook JupyterLab già configurato per quel modello, in locale o su un'istanza ospitata. Quando un modello ha bisogno di una vera GPU invece del tuo portatile, Deployments e Cloud GPU subentrano e lo mettono su un endpoint gestito. Prima che un modello arrivi ai clienti, Safety esegue suite di test red team su un modello deployato. La pagina sull'inferenza locale approfondisce il motore sul dispositivo, e la pagina sul fine-tuning LoRA copre la parte di addestramento. Le prime domande che si fanno Mi serve una GPU o un PC da gaming? No. Un portatile recente basta per modelli piccoli e medi; i badge di Explore ti dicono cosa può reggere la tua macchina prima di scaricare. Un desktop più potente o un server remoto allargano semplicemente l'elenco. Viene inviato qualcosa al cloud? L'inferenza locale, Quantize e l'addestramento locale girano sulla tua macchina. L'addestramento su Cloud GPU, gli endpoint Cloud GPU e Providers sono le parti che usano servizi esterni, e le schermate lo indicano, per esempio con "Managed cloud GPU · needs credits" nella finestra di addestramento. Che differenza c'è tra Eval e Benchmarks? Eval valuta la qualità delle risposte rispetto a domande definite da te. Benchmarks misura velocità e memoria: token al secondo, tempo al primo token e latenza. Dove trovo l'app? Local Model funziona nell'app desktop, che puoi scaricare da osfoundry.io/it/download .

  • HeyDesignerDeveloper/Designer Newsread at source

    On borrowing Apple's type scale

    How a designer/founder wins by their own rules (video), Taming typography: Building a modern CSS reset, Introducing Adaptive Dark Mode.

  • Hacker News Front PageThe Giantsread at source

    University libraries are being swarmed by AI bots, putting public access at risk

  • Frontend Masters BlogMore Front-end Bloggers5 min read

    true or false in CSS

    CSS doesn’t have a boolean type, but it does have the true and false keywords. Register a custom property that only accepts them, flip it with :has(), and container style queries turn messy :checked selector combinations into readable conditions.

  • Hacker News Front PageThe Giantsread at source

    Gemini Omni 1.2 Flash

  • Hacker News Front PageThe Giantsread at source

    Tesla winds down Cybertruck production after years of poor sales in few markets

  • Net NinjaYouTube ChannelsVideoWatch on YouTube

    GitHub Copilot App Tutorial #9 - Using the Rubber Duck Agent

  • Hacker News: Show HNLibraries, Frameworks, etc.read at source

    Show HN: UUMit – turn idle machines into model endpoints

    Comments

  • Hacker News Front PageThe Giantsread at source

    Mbodi AI (YC P25) Is Hiring Research and Robotic Engineers

  • Hacker News: Show HNLibraries, Frameworks, etc.read at source

    Show HN: Ueddit.com – Reddit Without Logging In

    Comments

  • Hacker News Front PageThe Giantsread at source

    We've built an open-source feature flag server for 11 years

  • Hacker News: Show HNLibraries, Frameworks, etc.read at source

    Show HN: Rindraw – drawing and animation app for iPad, iPhone and Mac

    Comments

  • Hacker News: Show HNLibraries, Frameworks, etc.read at source

    Show HN: Black Pixel – 69-byte inverse of the Million Dollar Homepage

    Comments

  • Flavio CopesMore Front-end Bloggersread at source

    Tailscale tutorial: your Mac and a server on one private network

    Install Tailscale on a Mac and a VPS, SSH by name, serve a page only you can open, close every public port, and use the server as an exit node.

  • QuirksBlogTop Front-end Bloggersread at source

    The Valley bubble breaks

    I expected something to happen around the AI hype after the US elections. I didn’t expect it to happen so soon . Too early to tell yaddah yaddah, and the hype could very well continue for another few months, but did any AI-related stock ever tumble before now? To me, Silicon Valley exists solely in its own reality. Hell, the entire US tech scene appears to move in a bubble of relentless self-flagellation. (Then again, the US is fundamentally a Calvinist country.) Sanity prevails only outside the US. Sometimes. For now I’ll stick to my idea : the Valley is creating something with the appeal of a 19th-century factory, complete with oppressed and estranged workers, without delivering the sole benefit of such factories: cheaper IT and other services. They want to get rid of the middle classes whose salaries they have to pay so badly that they forgot to create an appealing product. The Valley doesn’t understand how fed up normal people are with AI. This is the first time ever a technological advance is so cordially disliked, and the Valley is not equipped to detect that. It has no experience with being disliked by normal people. Also, so far many of the Valley’s consumer tech innovations were free . AI isn’t free, or even cheap, as we’ll see in the coming months, once credit dries up. The Valley’s position will be damaged permanently, and tech will lose its centre of gravity, its global Schwerpunkt . I don’t think there will be a replacement, and I think that’s a good development. Sure, inertia will keep the Valley important for decades to come, but it’s lost its natural dominance of the hearts and minds of the world. Permanently. None of this is a judgement on AI itself. I refuse to do anything about it until its true costs are known, after the hundreds of billions per year (month?) of free money from clueless investors dry up. All the while I acknowledge that there is something there that will change programming — just not as radically as the US-based doomsayers think. AI can copy, it cannot innovate.

  • Hacker News: Show HNLibraries, Frameworks, etc.read at source

    Show HN: Overhead – the planes overhead, painted on an e-ink frame

    Comments

  • Smashing MagazineThe Giants4 min read

    A New Community For In-House UX People

    We’ve been working on something new! We’ve teamed up for a **new small community** for people doing UX-inside organizations — with weekly calls and a shared library of the business cases, templates, and research plans that have actually worked for other folks. [Jump to details](https://uxinsiders.boagworld.com/).

  • PiccalilliMore Front-end Bloggersread at source

    The Index: Issue #205

    Poznote In our endless search for a Notion replacement, this one is showing real promise. Fixing illustrations on a dark background with CSS The drop-shadow property is so overlooked considering how useful it is. This is a great use of it! Death comes for XSLT It's so frustrating that browsers are ignoring the one main rule: don't break the web . How to quit Spotify and improve your life in the process This one weird trick to improve your life. (We recommend TIDAL or Qobuz) Introducing adaptive dark mode It's interesting to see this concept back — this time from Safari — considering how much of a dreadful job Google did half a decade ago in Chrome. We'll see how it goes! CSS nesting: use with caution Here's one from the Piccalilli archives that you might have missed to wrap up this issue. P.S. this is a good website . Sponsor message When anyone can make anything, we can make you stand out. AI technologies have given anyone the ability to bring their ideas to life, but to produce a high quality service that actually works for the people it needs to work for requires experience, specialist skills and creativity. We’ve got heaps of all of that here at Set Studio and we've got availability starting in 2027, so check us out and see what we're about. Check out our work

  • Chris HawkesYouTube ChannelsVideoWatch on YouTube

    I Made a Fake 1980s AI Commercial (Step by Step)

  • Hidde's blogMore Front-end Bloggers4 min read

    Reflections from TPAC 2026

    TPAC is W3C's yearly work week. A large part of the Working Groups and all sorts of committees get together to collaborate in person (mostly hybrid). This post has some things I got out of it this year. Some of my week had been slightly overbooked, as is the faith of most TPAC…

  • AbduzeedoMulti Author Blogsread at source

    Inside Téléfilm Canada: Brand Identity by Caserne

    Montreal studio Caserne builds Téléfilm Canada’s brand identity around a 30°–70° projector-beam grid, SN Skandia type, and die-cut print. Supporting Canadian and Indigenous cinema from early script de...

  • AdactioTop Front-end Bloggersread at source

    Thursday session

  • Mux BlogCompany/Startup Blogs11 min read

    How I built a video sharing site with Claude Code and Mux after years away from coding

    See how Eric built ScubaTube with Claude Code, using Video.js v10 for a dive data overlay and TV mode, Mux Robots for chapters, and Mux Data for engagement.

  • AbduzeedoMulti Author Blogsread at source

    Editorial Design: GridType Vol. 1 by Slanted Publishers

    Slanted Publishers pairs open-spine editorial design with ten grid-type.com stencil typefaces in GridType Vol. 1: Type & Tools. On the uncoated cover of GridType Vol. 1: Type & Tools, stepped ...

  • AbduzeedoMulti Author Blogsread at source

    Packaging: The CVS Store Brand by Pearlfisher

    Pearlfisher rebuilt the CVS store brand as one disciplined system, a single heart and flat colour blocks across 3,000 products in 9,000 stores. Stack 3,000 products on one wall and the idea lands in a...

  • SitePointThe Giantsread at source

    Best Static Website Hosting Providers in 2027: Free and Paid Options Compared

    null Continue reading Best Static Website Hosting Providers in 2027: Free and Paid Options Compared on SitePoint .

  • Flavio CopesMore Front-end Bloggersread at source

    GPT-Live 1 tutorial: build a voice agent you can interrupt

    How OpenAI's full-duplex voice model works, how to use it in ChatGPT, and how to build with gpt-live-1 in the API: delegation, web search, function tools, voices and real costs.

  • Microsoft Edge BlogBrowsers, engines, etc.3 min read

    Discover more of what matters, every time you open a new tab in Microsoft Edge

    A new browser tab is full of possibilities. It can be the start of something you set out to do—or a chance to discover something you didn't know. As the amount of content online has grown, Edge users have told us they want more help cutting through The post Discover more of what matters, every time you open a new tab in Microsoft Edge appeared first on Microsoft Edge Blog .

  • Adam ArgyleTop Front-end Bloggers2 min read

    Bye Deno, Hello Cloudflare

    and wassup Astro

  • AbduzeedoMulti Author Blogsread at source

    Purple Garden Branding: Inside Mother Design's New Identity

    Mother Design gives psychic readings a new visual language in the Purple Garden branding, built on a living glyph, growing type and dawn colour. The project started with a séance. Mother Design sat wi...

  • Web Tools WeeklyMulti Author Blogsread at source

    Web Tools Weekly Issue #694

    React Tools, AI Tools, Text Editors

  • CSS-TricksThe Giantsread at source

    Taming Typography: Building a Modern CSS Reset

    Stu created tidy-typography.css: a style reset for taming typography with modern CSS features for everything from fluid typography and vertical rhythm, to hyphens and variable fonts. Taming Typography: Building a Modern CSS Reset originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.

  • Level AccessCompany/Startup Blogs10 min read

    A Guide to PDF Accessibility

    PDF accessibility means people with disabilities can read, navigate, and use a PDF, including with a screen reader, keyboard, or magnification. Among other The post A Guide to PDF Accessibility appeared first on Level Access .

  • AbduzeedoMulti Author Blogsread at source

    Etter Studio: Playful Web Design and Selected Works

    Etter Studio crafts an uncompromising web design portfolio featuring generative character animations and diverse interactive projects. Zurich-based Etter Studio approaches the web with a stripped-back...

  • AbduzeedoMulti Author Blogsread at source

    Zed by Typotheque: 500-Style Global Typography System

    Inside Zed by Typotheque: Peter Bilak turns low-vision legibility trials into a 500-style global typography system on TYPE01. Peter Bilak started Zed at independent foundry Typotheque with a blunt typ...

  • HeyDesignerDeveloper/Designer Newsread at source

    Fortune telling and speculative design

    Modern CSS might make your front-end more complex, Blossom carousel.

  • DigitalOcean BlogMulti Author Blogs4 min read

    Introducing DigitalOcean Cuttlefish: Get more done with agents on the go

    Your agent has been refactoring for two hours. It’s deep in the codebase, making real progress, and then it stops: “Can I run this migration?” Nothing happens until you answer. And you’re not at your desk. You’re in line at the grocery store, or waiting at school pickup.…

  • Smashing MagazineThe Giants20 min read

    Making Immersive LLM Chat Experiences More Accessible

    As LLM chat patterns become more widespread, making them accessible is essential to ensuring everyone can access the information, tools, and opportunities they offer. Drawing on his work improving these interfaces, Eric Bailey shares practical ways to make chat-based experiences on the web more accessible and usable for people who rely on assistive technology.

  • SitePointThe Giantsread at source

    Top 6 AI YouTube Transcript Generators: Features, Accuracy, and Limits

    null Continue reading Top 6 AI YouTube Transcript Generators: Features, Accuracy, and Limits on SitePoint .

  • W3C BlogBrowsers, engines, etc.6 min read

    W3C Newsletter - October 2026

    W3C President and Interim CEO Dominique Hazaël-Massieux shares timely and notable highlights and information selected from the busy and prolific work last month at W3C such as TPAC 2026, AI @ W3C, progress on Identity and Credentials, further improvements to W3C infrastructure for standardization and more.

  • SitePointThe Giantsread at source

    7 E-commerce UX Tips for Selling Car Accessories and Home & Kitchen Products Online

    null Continue reading 7 E-commerce UX Tips for Selling Car Accessories and Home & Kitchen Products Online on SitePoint .

  • Flavio CopesMore Front-end Bloggersread at source

    Conductor alternatives after the Meta acquisition

    Conductor alternatives compared: Orca, Paradev, Paseo, T3 Code, Emdash, boxes.dev, Grok Bot and the agent apps from Anthropic, OpenAI and Cursor, with prices and how to move your workspaces.

  • SitePointThe Giantsread at source

    Top 6 AI Video Generators in 2026: Features, Strengths, and Limits

    null Continue reading Top 6 AI Video Generators in 2026: Features, Strengths, and Limits on SitePoint .

  • Flavio CopesMore Front-end Bloggersread at source

    The complete guide to the Chrome DevTools Protocol

    Learn to drive Chrome with the DevTools Protocol from Node.js with zero dependencies: pages, clicks, screenshots, PDFs, network, and replacing Puppeteer.

  • AbduzeedoMulti Author Blogsread at source

    Typography: Shuffle Variable by Local Type Co.

    Local Type Co. explores expressive typography with Shuffle Variable, blending bouncy curves and sharp geometry across twelve weights. Most contemporary sans serifs aim for cold mechanical neutrality, ...

  • Ahmad ShadeedMore Front-end Bloggersread at source

    Beyond the viewport: Introducing Site Seeing

  • HeydonWorksMore Front-end Bloggersread at source

    I am not a developer or an accessibility specialist. Hire me?

    About being a so-called unicorn and its value.

  • Twilio BlogMulti Author Blogsread at source

    Why We Expanded our Internship Program this Year

    Discover why Twilio expanded our intern program in 2026, highlighting impactful intern projects, in-person onboarding, and early-career talent growth.

  • Twilio BlogMulti Author Blogsread at source

    How to audit what your AI agent knows about a customer

    Learn how to audit what your AI agent stored about a customer, trace each memory to its source, and show agents why a suggestion was made.

  • Twilio BlogMulti Author Blogsread at source

    How brands start trusted conversations on Apple Messages for Business

    We explained in our previous blog, how the grey bubble, Apple Messages for Business (AMB), gives brands a verified presence in the thread and an experience where iOS consumers can pay, book, or get help without leaving the native Messages app. This post covers what brands ask next: how do customers get there in the first place?

  • AbduzeedoMulti Author Blogsread at source

    Studio Dumbar’s Personal OS Branding for Wabi

    Studio Dumbar/DEPT builds the personal OS branding for Eugenia Kuyda’s Wabi app generator around glass orbits and a five-dot W mark. Launched by Replika founder Eugenia Kuyda, Wabi lets people generat...

  • AdactioTop Front-end Bloggersread at source

    Wednesday session

  • Jim Nielsen’s BlogMore Front-end Bloggersread at source

    “It Gives Great Demo”

    There’s that famous video of Steve Jobs explaining why they don’t didn’t make touchscreen MacBooks: We thought about [a touch screen MacBook] years ago. We’ve done tons of user testing on this and it turns out it doesn’t work! Touch surfaces don’t want to be vertical. It gives great demo. But after a short period of time, you start to fatigue. And after an extended period of time, your arm wants to fall off. It doesn’t work. It’s ergonomically terrible. Touch surfaces want to be horizontal […] that’s why we’ve perfected our multitouch trackpads over the years. I’m not going to weigh in on the new MacBooks. But what I find specifically intriguing in this video — and broadly relevant — is that phrase: “It gives great demo.” Damn, that is a great line for so much of technology. “It gives great demo.” Something that looks amazing when it’s presented to you, but in practical day-to-day use you discover, “Actually this is kinda terrible.” Demo is everything nowadays. Whatever can garner attention. Who cares if it works in practice, does it give great demo? Because demo time is sale time. The purpose of a demo is to get your attention. To make you think about the product and that it exists. But a great product often makes you forget it exists at all. It seems like a paradox: we’re attracted to what stands out, but we become enamored with what disappears. Of course, this doesn’t just apply to products. People can give great demo, too. You can make a whole career out of just giving great demo. Reply via: Email · Mastodon · Bluesky

  • Flavio CopesMore Front-end Bloggersread at source

    I want my coding agent to do what I ask

    Claude Code got a rule against recreating existing games, it misfired, and Anthropic narrowed it. I'd rather the tool did what I ask and left the legal side to me.

  • CSS-TricksThe Giantsread at source

    Smashing AI Conference

    The AI 2027 Conference is a live online day for designers and engineers on where AI stands today, what to expect in 2027, and where teams are getting it right. Smashing AI Conference originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.

  • DequeMulti Author Blogs7 min read

    How to choose the right VPAT approach for your organization (and whether you should use AI to complete your ACR!)

    In this post, I’m going to discuss why accuracy matters for digital accessibility in an era of evolving global standards and increased regulatory scrutiny. I’ll explain where and how VPATs and ACRs fit into your accessibility strategies, and what you need to know before making any decisions about AI use. The post How to choose the right VPAT approach for your organization (and whether you should use AI to complete your ACR!) appeared first on Deque .

See everything from the last 30 days →