Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
16 hours ago in Device ID can go missing, and so can a cookie. An IP address almost never does, which doesn't make it any more stable.
An IP address is a routing address: a network location for delivering a packet, not an identity. It only has to be right long enough for one delivery, nothing about it was built to stay attached to a person over time.
NAT is the trick a router uses to let many devices share one address, and CGNAT is the same trick run by the carrier instead of your router. It's driven by plain IPv4 exhaustion, only about 4.3 billion IPv4 addresses exist and none are left to hand out, and it's standardized, not a workaround: internet technical standards require these devices to limit how many connections each subscriber gets. Ordinary office or cafe WiFi does the same sharing through plain NAT: one documented setup showed a single device supporting up to 8,000 people before its roughly 60,000 connection slots ran out. A VPN's exit server runs the same trick, just chosen by the user instead of assigned by a carrier. The address itself isn't fixed either. It changes on lease renewal, a router restart, or just moving networks, home WiFi to mobile data.
IPv6 has its own churn built in, and there's a real reason for it. Left alone, IPv6 can build a device's actual hardware address into the address itself, the same value on every network it joins, letting anyone who sees the traffic recognize it across networks and even read the manufacturer off part of it. Privacy extensions exist specifically to cover that up, swapping in a fresh, randomized address roughly every 24 hours instead, standard across every major modern operating system.
Some exchanges blur it further on purpose. IPv4 gets its last number zeroed before a buyer ever sees it, confirmed against real traffic. IPv6 gets wiped down to a fixed size too, and that doesn't reliably hide anyone. How much ground that covers depends on how the ISP handed the block out, and plenty give one household exactly that size on its own. So the wipe can look like it blurs several homes together when it is really just one house's address, untouched.
The same address also gets used to guess where someone is, and that guess was never precise either. The databases behind it describe a circle with a radius from 5km to hundreds of km, not a point, warning against reading it at street level. Starlink is a clear example: its own support documentation notes the IP-based location can be off by entire states, because the address reflects wherever the connection surfaces at one of its data center hookups, not the dish itself.
Cap on an IP address and you will almost always have something to count against. Sharing, churn, deliberate blurring, and geolocation that was never precise all mean it rarely points at the same person twice. It is part of why linking an IP to a specific person downstream is so hard too, because that work is built on a foundation that keeps shifting under it
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
18 hours ago in There are a hundred newsletters that will tell you about the "future of advertising." We decided to write one about the actual plumbing.
Together with our Damian Naglak and the team at Appliscale we launch our weekly Substack newsletter: The Frontier.
We have spent 11 years building RTB platforms, containerized bidders, agents and identity pipelines that process tens of billions of impressions a day. So we are writing it by ourselves and for ourselves.
The Frontier covers Ad Tech and the AI agents moving into it. No fluff. No trend takes. Just the exact engineering reality of what breaks when an LLM gets near a bid path.
Every week on Tuesday, you get four things:
1) A Deep Dive written by someone who actually built the system
2) 5 News Items that matter, with the technical mechanism explained
3) The Number: One specific industry stat, unpacked
4) The Signal: A slow-moving shift that might dictate your roadmap in six months
Sign up here: appliscale.substack.com
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
5 days ago in To count the same person twice, for a frequency cap or a retarget, you need one identifier that holds still across visits. The cookie was the original answer, and you have probably heard it is disappearing. Here is what that means: five separate places it can fail.
Quick refresher: a cookie is a key/value pair set through a Set-Cookie response header, stored in the browser, then sent back automatically on every later request to that domain. Netscape invented it in 1994 to remember a shopping cart between page loads, one small job. The industry built an entire identity layer on top of it anyway.
First gate: does the browser even allow it. Safari has blocked third-party cookies since 2017, Firefox since 2019. Chrome still allows them, and Chrome alone carries roughly 65% of global traffic this year, more than every other browser combined.
Second gate: does the law allow it. The EU, UK, Brazil and China run opt-in, nothing fires until the user says yes, and GDPR gives cookie storage no fallback to legitimate interest, only consent. The US runs opt-out instead: a cookie fires by default until the user objects. Twelve states now legally require honoring that objection when sent as a browser signal.
Third gate: this is called cookie syncing, buyer and seller platforms exchange their own cookie IDs with each other so they can recognize the same person under two different values. It isn't a standing connection, it has to keep re-happening: sync only completes when the seller's tag actually calls the buyer's sync pixel during that one page visit. Miss that call and nothing happens until it lines up again on a later visit.
Fourth gate: even synced, it dies fast, by design and by accident. Every cookie carries a built-in expiry, and Chrome caps it at 400 days no matter what's requested. Some carry no expiry at all, a session cookie, and vanish the moment the browser closes. Users clear browsing data.
Fifth: even alive, a cookie identifies a browser, never a person, in both directions. The same person on a phone, a laptop, and a work desktop becomes three unrelated IDs. A shared family or library computer collapses several people into one.
A less obvious version of the same problem, and a growing one given how much traffic now starts inside a social app: Instagram, TikTok and Facebook open links in their own isolated browser rather than the phone's, keeping the whole experience inside the app's own branded view instead of risking someone bouncing to the standard browser and not coming back. That isolated view keeps its own separate cookie jar, disconnected from the real browser's, so the same person looks like a stranger clicking from inside the app.
Cap on a cookie and you're only capping the slice that survived every gate: the browser, the law, the sync, the clock, or the device can each leave you counting a stranger.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
6 days ago in According to OpenRouter in February 2026, agentic token usage officially surpassed human usage. Fast forward to August, and human usage grew 2.8x. Agentic usage grew 14x (!) meaning agents are currently burning 7.3 trillion tokens / week just on this one platform.
One could say "The Internet is no longer for humans" or that "dead Internet theory" is not a theory anymore. But apart from that, it is clear that autonomous agents talking to other autonomous agents in endless loops, reading massive codebases, and parsing databases is not a distant vision anymore.
If your API rate limits are configured for human clicking speed -> these agents will DDoS your servers by lunchtime
If your database structure isn't optimized for machine-readable context -> agents will burn millions of tokens just trying to understand your schema
If you aren't strictly monitoring the cache read costs of your own internal coding agents -> your cloud bill is going to explode
At Appliscale , we tell our clients that building is no longer about writing better prompts but designing a strict agent harnesses" - if you don't put a leash on your agentic workflows, you are just funding that green line and tokenmaxxing is not always the best way (ask your CFO).
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
1 week ago in 100M monthly active users, 4M concurrent, 300K auth requests a minute at peak.
We don’t own any of these platforms. We modernised them, migrated them, and now help run them.
That’s what external development looks like when it works. You don’t see our name on any of it.
Adtech or gaming, the scale problems are similar. If you’re curious about our gaming case studies, check a dedicated section on the Appliscale website.
I’m happy to deep dive during the XDS.
#XDS2026 #ExternalDevelopment #GameDev
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in To count the same person twice, for a frequency cap or a retarget, you need one identifier that holds still across visits. Device ID looks like the cleanest option: no login, no cookie sync, generated automatically just from using the device. None of that guarantees it shows up.
The field exists because an app-capable operating system generates an ID and hands it to whatever app is running. A browser tab never gets one, on any operating system, phone or desktop. iOS calls it IDFA, Android calls it GAID, and CTV has five more names for the same idea: Roku's RIDA, Samsung's TIFA, Amazon Fire TV's AFAI, Vizio's VIDA, LG's LGUDID. Windows has one too, assigned to every Windows 10 and 11 install for apps bought through the Microsoft Store, and it stays invisible to a browser tab open on that same machine.
Inside an app that can generate the ID, two things still take it away. A user can decline tracking, and the field comes back as a defined placeholder: a string of all zeros, the exact same value on every device that declined. Apple started it on IDFA, Android matched it on GAID in 2022. It looks like an ID but means nothing, and it's the same nothing for millions of people at once. A user can also reset it from settings, any time, with no notice to anyone who was counting on it.
CTV works the same way, and adds two more problems. The ID exists at the platform level, but five unrelated names with no shared standard means a cross-device campaign is stitching together five different systems, not one. And even when the platform hands over a real ID, the ad often doesn't reach the viewer directly. Server-side ad insertion splices it into the stream on the publisher's own infrastructure, so the device ID has to be carried through that step by hand.
OpenRTB used to name the platform that issued the ID: idfa, aaid, rida, afai. That field is deprecated now. The replacement names how the ID was generated instead: by the device, by the publisher, or as a short-lived session value meant to be thrown away. That's what tells you whether an ID holds still. Cap on device ID and you're only capping the slice of traffic that carries one, never all of it: a browser tab, an opt-out, a reset, or a stitching step can each leave the field empty.
Bedrock Platform
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
1 week ago in The description of my XDS panel hosted by Summer O'Brien says policies, cost models, and risk frameworks are still catching up with the tools our teams already open every day. Accurate.
From the service provider perspective it’s no longer a question of if, but of how. Which model, which skills, how to optimize the toolkit and tokens you burn to get to the results you wanted. And who reviewed it before it went to the client’s codebase.
The model is the easy part. The harness around it is where the advantage sits. Craft problem, not a licensing one.
Max Wojczuk and Michal Niec have been publishing for months how Appliscale engineers experiment with it in internal and external projects - token usage, toolkit and agentic setup, what we tried and dropped. They go deeper than I’ll manage in a panel slot.
AI in External Development: Policy, Risk, and Reality. Vancouver, Sep 9, 11 am. I’m booking meetings around it if you want to chat more.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in tl;dr we're looking for Senior Data Engineer who can handle petabytes of data.
I write a lot about Ad Tech on LinkedIn, but that is only half the story at Appliscale .
The core of our DNA isn't advertising. It is scale. We build infrastructure for companies that generate data so fast it breaks normal cloud architectures.
Right now, we are hiring a Senior Data Engineer for one of our longest-standing partners: one of the largest game studios on earth, responsible for massive global MOBA and FPS franchises.
When millions of players log in concurrently to play an FPS, the data exhaust is staggering. You aren't just managing gigabytes of data; you are playing a vital role in building solutions capable of processing petabytes of information.
This role sits inside the Data Experiences and Automation team. The mission is to harness that massive data stream to power player-centric decisions, Machine Learning, and GenAI pipelines. You will be building the data foundation that insight analysts and ML engineers rely on to iterate fast.
We need a Senior Data Engineer who understands large-scale, globally distributed systems.
The details:
- B2B: 26,000 - 30,000 PLN net / mo.
- Remote / Krakow
- PST Overlap required (the core team is in LA and Seattle)
If you are tired of working on small datasets and want to manage petabyte-scale infrastructure for millions of players, you know the drill: https://www.appliscale.io/career/senior-data-engineer-pst-overlap-zbor
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in You get the same ad ten times in one evening. That campaign almost certainly had a frequency cap set well below ten. A cap counts an identifier, and you keep arriving as a different identifier.
In the bidder a cap is a lookup. A request comes in, the bidder reads a counter for this person and decides whether to bid. For that number to mean anything, the request has to carry something that points at the same person as yesterday, and the impression from an hour ago has to be in the count already. Both of those fail often enough to explain the ten.
Start with the identifier. A bid request can carry a person in four ways, and any of them can be missing. The exchange's own ID for you (user.id), usually taken from its cookie, which it may rotate under its own privacy policy. Your own ID, mapped for you by the exchange (user.buyeruid), which exists only where a cookie sync ran first. The advertising ID from the phone or TV operating system (device.ifa), which anyone can reset from settings, and which arrives as a string of zeros on iOS when the user declines tracking. And IDs from third party graphs like RampID, ID5 or UID2 (user.eids), which arrive encrypted and encoded for one specific buyer, readable only with an agreement and the keys.
Those graph IDs carry a note saying how the match was made. Some come from an email login. Some come from a cookie sync. One of the values means the match was inferred from IP address and user agent, so the ID is a guess about who this is. A cap counts against a guessed ID the same way it counts against a real one.
When none of them arrive, what is left is the IP address and the user agent string (device.ip, device.ua). An IP is rarely one person. A home router puts the whole family behind one address. Mobile operators run carrier grade NAT, where thousands of subscribers share a single public address. The address does not hold still either: a home lease runs from a day to a week and can change when it renews or the router restarts. The user agent stopped separating people too, because every Chrome on Android now reports the same made up device.
Then there is the delay. The counter moves when the impression is booked as spend, which happens after the ad renders, and rendering can wait. A video prefetched during a game level plays when the level ends. An ad stitched into a podcast sits in the file until someone reaches that minute. On the web that gap is short. On formats that get cached or stitched into a stream it runs far longer. Everything you bid in that window is decided on the old count.
A frequency cap is worth no more than the identifier it hangs on. The harder it gets to recognise a person, the more of the same ad that person potentially sees.
Bedrock Platform
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
1 week ago in On August 17, Activision reported a connectivity incident affecting multiple Call of Duty titles.
The incident started at 6:43 PM UTC, with players reporting problems connecting to the game and logging in. Activision marked it as under investigation. I haven't found a public post-mortem explaining what caused it yet.
That leaves an interesting question for anyone working on game backends: where did it actually fail?
A player pressing “Play” can trigger a surprisingly long chain of backend services:
authentication → verification → entitlements → player profile → matchmaking → session allocation → game server
A failure in any of these can prevent the player from getting into a game, even when the game servers themselves are healthy.
This is where game backend engineering starts looking very familiar to anyone who has worked on distributed systems. You deal with partial failures, retries, timeouts, inconsistent state, traffic spikes, queues and regional failures. The player just experiences it as “the game doesn't work.”
This is also the area my team at Appliscale specializes in. We build backend services for authentication, verification, player preferences, queueing, and session management at large scale.
At scale, game technology is distributed systems engineering. Authentication, session management and player state are all part of the system the player depends on before the game even starts.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in Really impressive AI parkour simulation by NVIDIA . The coolest part: all of that generated from just 30 seconds of reference material.
But looking under the hood, I think there's a fascinating tension robotics optimization vs. game realism I've been thinking about:
Robotics = optimization is king. We treat movement as a pure kinematic problem ("get from A->B via path C") to strictly minimize energy costs and wear-and-tear. The goal is always maximum efficiency.
However, to avoid the uncanny valley in characters, we actually need to inject somę “inefficiency”. If an AI/NPC moves with perfect thermodynamic optimization (like a robot), it feels… robotic. Humans don't move optimally - our actuators fatigue, joints stiffen, we run out of breath etc.
So to mirror human movement, we can't just optimize for the "best path" but rather “simulate the limits”: tired joints that fail under load, momentum that naturally drains speed, and recovery phases where efficiency drops.
For robots it’s ok to treat energy as infinite because they lack an explicit "battery" state or metabolic decay in their loss functions but that’s a different story for games.
(strongly recommed to follow Maksymilian Wojczuk from our Appliscale team who shares his deep dives into AI/gametech)
Paper: https://jiashunwang.github.io/HIL/static/mat/Hybrid_Imitation_Learning_TOG.pdf
Video: https://www.youtube.com/watch?v=8B05cy3UuSE
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in A sportsbook asks for the people most likely to bet on football. The closest match anywhere in the data lives in a state where the company holds no licence. The model was right and the answer is worthless.
The last two posts were about finding the closest people among billions. Nobody wrote down who belongs in the audience and no score makes somebody a member, so everybody scores something against the description. Comparing against everybody is too slow, so each person is stored next to a short list of their nearest neighbours, and the search hops from person to person, always towards somebody closer. A few hundred stops instead of a billion comparisons. What comes back is a ranking, and it says nothing about who you may advertise to.
A profile often says where someone lives, so the vector half knows. Pooling flattens a whole browsing history into one vector, so two words about a city sit among hundreds of others, and one state reads much like the next. The vector leans one way, it never certifies. And the conditions that disqualify a person were never in their browsing history at all. Whether the sportsbook holds a licence in that state sits in the company's records, and changes when a legislature votes. Whether they agreed to be advertised to sits in a consent record. Whether you can reach them depends on an ID you may bid on. Anyone who already opened an account is on the advertiser's exclusion list. A better model ranks people better and learns none of this.
The obvious way to combine them is to take the closest hundred and drop the ones you cannot use, which in a narrow market leaves nobody. So the licence check runs during the hopping instead. Every time the search reaches somebody it asks two things: are they close, and are they allowed. Only the allowed ones go on the shortlist, and the rest still get hopped over, because their neighbour lists are the route to everybody behind them. The search stops when nobody left to visit is closer than the worst person on the shortlist, so when few qualify it fills slowly and the search keeps running. If one person in twenty is allowed, the search stops at twenty of them for every usable name it collects. Removing a few people costs almost nothing. Requiring something rare is what stretches the search.
The way out is to split people in advance by a separate index per state, so everybody inside it is eligible. Licences, caps, budgets and exclusions change by the second, so those get checked as the search runs. When very few qualify, the better move is to stop hopping and compare against the eligible ones directly, which is what engines do below a size threshold. And the top of the ranking wears away as a campaign runs: the best matches get served first, so they cap out first, and the ones who sign up move to the exclusion list.
Search over vectors is quick because it never looks at most of the people. Every rule about who you may advertise to is a reason to look anyway.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in A cheaper and more efficient that Seedance 2.5 flow to generate game videos.
Instead of prompting a video model directly and relying on multiple rerolls to get the right shot, GMI Cloud used DeepSeek V4 Flash to write a raw Three.js scene (exact camera movement, character motion, timing etc.).
Once the sequence was correct, they fed that raw, low-poly footage into MiniMax H3 to generate the final realistic render in a single take.
Cost: 48 mins, $1.97 total, one H3 generation.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in Embedding targeting is usually explained as comparing two vectors. The step before that, picking which vectors to compare against at all, is where most of the work sits.
Last post: you cannot put vectors in order, and you cannot rule out a group without looking inside it. So whatever makes this fast has to be built before any request arrives. There are thirty years of methods for doing that. Trees, which cut the space into smaller and smaller boxes, stopped working above about ten numbers per vector. Hashing, which sorts vectors into buckets using random cuts, needs too many buckets to get accurate. Grouping, which clusters everything and opens only the nearest few clusters, survives underneath the others. And one approach won outright, a graph of neighbours called HNSW, for hierarchical navigable small world. Of the ready-made databases sold for storing and searching vectors, Qdrant offers nothing else at all, and Weaviate makes it the default.
It works like walking downhill in fog. You cannot see the valley, but from where you stand you can feel which way the ground drops, so you step that way and check again. You stop when every direction goes up. The structure is exactly that. Every vector gets a list of about sixteen of its nearest neighbours, stored right beside it, and that list is all it can see from where it stands. A request drops in somewhere, checks those neighbours, moves to whichever one sits closer to what it is looking for, and does the same again from there, until none of them is closer than where it already is. Then it stops. A few hundred steps out of a million, and everything it never walked past is never seen.
There is one shortcut on top of that. The map comes in layers: a sparse top layer where the few points sit far apart and every hop covers a lot of ground, then denser layers below with shorter hops. A request crosses the rough map first to get into the right region, then drops down and refines. Flights, then trains, then walking.
What goes wrong comes out of the same picture. You can end up at the bottom of a small dip with the ground rising in every direction, while the real valley sits over the ridge you never crossed. The fix is to walk several routes at once instead of one, and how many is a configurable number. Walk more of them and you land in the real valley more often, and it takes longer. None of this is free. Those sixteen links per vector get stored alongside them, so the structure takes up more room than the data it was built from, and assembling it for a million takes time. You are buying query time with space, paid once in advance, and in bidding query time is the one thing you cannot get more of.
That trade is what makes matching by meaning possible inside an auction at all. A bid response has about a hundred milliseconds. Comparing one vector against every stored one does not fit inside that but walking to a few hundred of them does.
Bedrock Platform
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in Segment targeting asks one question: is this user in list 12345. Embedding targeting asks which of my audiences this user is closest to. One of those is a lookup. The other is a search.
With segments somebody drew the line in advance, so a user is on the list or off it and the auction only has to check. With vectors there is no list and no line. Every user has some score against every audience, nothing is in or out, and the only way to decide is to rank everything and take the top few. So matching on meaning means finding the closest, and finding the closest is a different job from checking membership. Databases are fast on huge tables for two reasons. The rows are kept in order, so finding one is jumping straight to it. And they are grouped into chunks whose contents are known, so most chunks never get read at all: if a chunk holds only values between 10 and 20 and you asked for 50, it is thrown away untouched. A billion rows, and the database reads almost none of them.
Neither trick works on vectors. Keeping things in order needs something to order them by, and closest has nothing, because it depends on a question that arrives later and is different every time. Whatever order you pick, the next request wants another one. Skipping groups fails for its own reason: to throw a group away you have to be certain nothing inside it is closer than what you already found, and with hundreds of numbers per vector the distances all come out similar.
So you are left comparing against all of them. A million vectors at 3,072 numbers, four bytes each, is twelve gigabytes to read for one bid request. Nobody does that. Everyone gets around it the same way: group the vectors by closeness before any request arrives, then only look at the group the request lands in. That saves almost all the work, and it sometimes gives you the wrong answer. For bidding it lands somewhere specific. Today the hard part happened days earlier, when someone worked out who belongs in the audience and wrote it down, so the auction only reads the answer. Matching on meaning moves the finding into the auction itself, and what a bid costs stops being flat. Twice the audiences, twice the work, on every request.
Next: the three ways people organise vectors in advance, and what each one gets wrong.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in If you are not tired of AI content yet, congratulations, here is one more concept.
Agentic Software Factory. You stop writing code and start designing the factory that writes it. Nine stages, three kinds of actor. Agents implement, test, review and analyse incidents. Infrastructure sandboxes, ships and watches. Humans do four things: set intent, set priorities, own the architecture, and get paged when it breaks.
The pitch you will hear is that this removes the code review bottleneck. It does not. Ten agents opening forty pull requests an hour makes human review the bottleneck, harder than it has ever been.
What actually changes is where humans spend attention. Upstream, into the specification, because a vague spec used to cost you a day and now costs you forty confidently wrong diffs. And into the gates: tests, review agents, monitoring. Those are the only things that scale with the agents.
The factory does not remove the human. It removes the human from the middle and puts them at both ends.
So where is your bottleneck now: writing the code, or deciding what it should be?
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in I almost sent my team an update about a meeting that never happened.
I spent 30 minutes on that call with my friend Kamil talking about our content pipeline, in Polish, with Fireflies set to English by mistake. Out of half an hour it caught maybe ten sentences, mostly the English words that leak into any adtech conversation.
The transcript reads like this:
"Yes to die. Server CTV agency Programmatic in app advertising platform game advertising publisher data management. Varnish. What we shipped."
"No what good looks like. Just a call to action book the call. Solutions Boost TikTok Noitake cross platform cloud. No it is."
The summary built on top of it reads like this:
"AI Agent Development: Building scalable AI agents for programmatic in-app and streaming ads, integrating with publishers' data systems."
"Kamil highlighted the complexity of building AI agents in adtech, noting the challenge of aligning them with agency and publisher data management needs."
No he didn't, and every one of those bullets carries a timestamp pointing back at the noise it came from. With ten fragments and no way to say "I don't have enough here", the model simply wrote the meeting it assumed we'd had, and it happened to be a perfectly plausible one about the agentic advertising future.
I never opened that summary. Later the same day I asked Claude to pull the important updates from my client and partner meetings so I could keep the team in the loop, and the fake meeting made the list as one line about our PR process. I had my finger on send when the phrasing struck me as slightly off, and only then did I go digging.
That is what makes this worth writing about. The transcript is garbage that anyone would catch in a second, the summary is generic enough that you skim it and move on, and by the time it reaches a team update it is a single confident sentence nobody will ever question. Each layer launders the noise a little further from the evidence that would expose it.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in The media narrative: "Gen Z is lazy and doesn't want to work"
The actual data: Gen Z is starting businesses at a rate that dwarfs every other generation alive.
I hire engineers every week and my experience with Gen Z is the exact opposite: they want to work hard, they just don't want to work on boring tasks that a machine should be doing and if a job is boring, they just start their own company.
We see this at Appliscale that the only way to attract and retain the best young talent right now is to offer them massive, complex challenges - based on my experience, more students crave for a job that require deep architectural thinking than a cushy repetitive job (anyway, the latter would soon be automated).
So if you offer them a boring job, they won't take it. They will just go build something better on their own which seems the right way.
PS. Yes, we are hiring still hiring! Check latest jobs: https://www.appliscale.io/career
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in A page turns into a vector in 20 milliseconds. Eighteen times more text took 32 times longer, and asking the same card to read a 16,000 word history made it request 15 GiB in one block and give up.
Last week I timed one page and then priced it, both on page-length text. The long inputs are the interesting ones: a ninety day user history, a full CTV transcript. So this time I kept the model the same and made the text longer, on the same card. Long text costs more than its share. Take what 1,000 words cost: on the mid-sized model, 42ms inside a page, 40ms at 1,000 words, 44ms at 2,000, 54ms at 4,000, 76ms at 8,000. The 600M model went from 51ms per 1,000 words to 117ms at 32,000, where one text took 3.8 seconds. The same words cost nearly twice as much inside a long text as a short one.
A model does two jobs and their costs grow differently. Reading is the fair one: each word passes through the model's layers, so twice the words means twice the work. Comparing is the other: every word measures itself against every other word, which is how the model works out what each one means from those around it. Ten words means a hundred comparisons, a thousand words a million, so every time the text doubles, the comparing gets four times bigger. I opened a model up to check. Give it "the river bank was steep" and it builds a seven by seven grid of comparisons, every cell filled, twelve grids side by side at each of twelve layers. The comparisons run one way only: "steep" looking at "bank" scores 0.49, "bank" looking at "steep" scores 0.09.
On a page reading is the bigger cost, so the bill follows the length, as it did last week. Comparing overtakes it once the text passes about 768 words, this model's working width. The price per word climbed from 4,000 on. Memory suffers for the same reason: the whole grid of comparisons has to sit on the card at once. Sixteen thousand words squared, times sixteen grids, times four bytes a number, is 15.26 GiB in one lump on a card holding 22. Exactly what the crash asked for.
One way around it is to cut the text up and embed each piece on its own. The same 8,446 words cost 645ms in one go, 460ms as two halves, 374ms as four pieces and 336ms as eight. Half the price for the same words, and the result is a vector per session or scene instead of one for everything. It costs something: each piece is embedded blind to the others, so a reference in the last paragraph to something named in the first is lost.
Every model has a ceiling on how much text it will read. Getting near it costs more. The longer the text, the more every single word in it costs.
Bedrock Platform
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
3 weeks ago in "don't be a meat proxy" - 100% agree on this blog post from NIklas Gruhn
I can talk to Claude myself, don't need a human in the middle - copy-pasting a ticket to Claude, creating PR, pasting feedback back to Claude and repeat.
If you are just relaying prompt outputs, you are not the developer. The reviewer is - they are using the AI to build the system, using you as a proxy.
AI should amplify your intent, not remove it.
Link in comments.
View on LinkedIn
