Yes, I've got the keys to the castle, so to speak. And, even after 12 years of working on the site, I'll admit I'm a little overwhelmed and nervous about that.
CSS-Tricks has a new owner! originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.
Last weekend I watched four people desperately trying to get a laptop to connect to a screen. I was happily observing their efforts, with zero intent to join in.
But someone nudged me: can't you have a look at it?
My reply: "Haha sorry no! My experience is that adding more people will not solve this problem any quicker".
I was of course -- indirectly -- referring to Brooks's Law:
"Adding manpower to a late software project makes it later."
It was formulated by computer scientist Frederick P. Brooks Jr. in his 1975 book The Mythical Man-Month, based on his experience managing the IBM OS/360 project.
However I got to thinking. Does this still hold up in the age of AI agents and LLMs?
At first glance, youâd think no. The traditional bottlenecks -- onboarding time, endless stand-ups, and office politics -- disappear overnight. An AI agent is up to speed in milliseconds and doesn't demand a coffee break.
But when you look closer, and the law hasn't vanished. It just mutated.
The famous "Baby Problem" remains: nine agents still canât deliver a baby in one month. Sequential tasks are still sequential.
Overhead hasn't disappeared; it shifted: instead of managing people, you are now managing agents. Someone still needs to define "done", review the code, catch hallucinations, and stitch the pieces together.
That someone is you.
Throw nine autonomous agents at a single codebase without crystal-clear orchestration, and they will happily rewrite each other's work in a high-speed loop.
Maybe the 2026 update to Brooksâs Law should be:
"Adding agents to a project with unclear requirements gets you the wrong answer faster."
You've probably already seen this common pattern in action: blurry versions of the images of a site appear immediately and, moments later, their full versions replace them.
This pattern has become so common that many image CDNs, frameworks, and libraries support it out of the box. But every implementation has to do the same thing:
Below is an example of the effect, which shows a blurry preview image. Click the button below to load and display the final image:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum volutpat accumsan tristique. Phasellus sit amet mauris odio. Aenean urna felis, laoreet vel ipsum ut, dignissim fermentum mi. Fusce posuere efficitur laoreet. Donec lacinia massa cursus eros ultrices maximus. Proin sit amet vestibulum nibh. Nulla luctus eleifend nisl. Aliquam vel orci a nisl maximus bibendum ut sit amet turpis. Curabitur sodales risus placerat nulla congue bibendum. Aliquam ut mi et dui efficitur semper. Donec tempus nibh eget est aliquet bibendum. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.
We are proposing to make this a built-in capability of the web, and we'd love to know if this is worth pursuing and what the exact scope should be.
Before diving into the proposal, let's take a look at how this pattern is typically implemented today.
There's currently no standard way to provide a preview for an image, so the solution depends on the framework or library you're using.
For example, Next.js can generate a blurred placeholder when an image is imported, by using the placeholder=blur property:
import mountain from "./mountain.jpg";
<Image src={mountain} alt="A mountain" placeholder="blur" />
Libraries such as blurhash encode a tiny preview as a short string, which your application can then decode to show the preview while the real image is loading:
// First, create blurhash strings for your images.
import { encode } from "blurhash";
async function encodeImageToBlurhash(width, height, imagePixelData) {
return encode(imagePixelData, width, height, 4, 4);
};
// At runtime, while the image is loading, decode the string to display a preview.
import { decode } from "blurhash";
const pixels = decode("<the blurhash string>", 32, 32);
const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");
const imageData = ctx.createImageData(width, height);
imageData.data.set(pixels);
ctx.putImageData(imageData, 0, 0);
document.body.append(canvas);
You can also use write your own custom implementation, for example by creating image previews at build-time, and sending them as data URLs used in CSS background images, while the final image is loading:
<div class="image" style="background-image: url(data:image/png;base64,....)">
<img src="image.jpg" alt="A mountain">
</div>
These approaches differ, but they all have to coordinate the preview and final image themselves.
This preview effect is well established, and for good reasons. It allows your UI to come to life much sooner, giving the impression of a more responsive site which lets users access the rest of the content while images are still loading.
We don't want to change this pattern, but instead implement it in the browser so that you don't need to write, maintain, and run as much code. With a solution that's built-in, you let the browser handle most of the complexity.
For now, our proposal focuses only on loading, displaying, and replacing the preview image. To achieve this, we propose to introduce a new attribute for the <img> element called previewsrc:
<img previewsrc="tiny-blurry-preview.png" src="full-image.avif">
With the previewsrc attribute, the browser would:
This already simplifies the process of handling image previews a lot because you don't need to use or write code to load the preview, handle cases where the preview doesn't exist or fails to load before the final image is ready, and handle the image swap yourself.
We'd love your feedback on this initial proposal: do you consider this a valuable addition to the web platform? Is it enough on its own for you to use it?
If you're using a library or framework to handle previews today, your solution might also support the following features:
Our initial proposal doesn't support these features. When the final image becomes ready to paint, the browser directly replaces the preview with the final image, with no customizable transition. Also, it doesn't natively support compact formats such as blurhash.
We're currently considering them as optional enhancements that could be added in the future, but your feedback on their importance would help us prioritize them: would you use previewsrc alone or would you require support for these optional enhancements (and if so, which ones) before adopting it?
Let us know how you feel about this proposal.
Is the problem worth solving at the web platform level? What would consitute the minimal viable solution for you to adopt the API?
Please send your feedback by opening a new issue on our GitHub repository.
You might be wondering about the following questions, so let me provide some answers below.
Sure, if you set previewsrc to another image URL, then an additional network request will be made, which potentially will consume bandwidth. However, consider this:
It's important to keep in mind that this is not a replacement for proper image optimization, and not a performance feature.
It doesn't. There is actually no enforcement mechanism in the proposal for ensuring that developers use the previewsrc attribute responsibly.
The proposal depends on developer discipline, the same discipline they apply when using existing image preview techniques.
However, this is important: the browser may skip the preview altogether if it determines that it is unlikely to be useful before the final image is loaded or if resources are constrained. That's definitely a plus compared to today's solutions.
JPEG images can be progressively delivered, whereby the image is loaded in multiple passes, gradually increasing in quality. This allows users to see a low-quality version of the image almost immediately, while waiting for the full-quality image to load.
In the end, this depends on your use case. A progressive JPEG may be preferable for sites where more fidelity is required, where seeing the real image, even if in low quality, is more important than having an instant, but very blurry preview.
Generally speaking, blurred placeholders seem to be favored for providing a quick visual indication, responsiveness, and layout stability. I feel like developers have mostly moved away from progressive images.
But also, not all sites generate progressive image versions at all.
They keep working as before.
An <img> inside a <picture> element can still use the previewsrc attribute. The existing <picture>, srcset, and sizes algorithms continue selecting the final image.
Using CSS to paint a background-image on the <img> element while it loads is a common technique, as described in How to fake Progressive WebP Images.
The advantage of a browser-provided previewsrc attribute over this are:
<img> element.previewsrc attribute would get reflected as an HTMLImageElement property.This is a quick note on how the industryâs reaction to Jev reveals the desperate state of AI. Iâll dissect:
What is Jev, how was it hyped and why it spread like mass hysteria? Jev isnât dead but its hype cycle is. Decision models are on the rise.
What are the noteworthy innovations since ChatGPT brought âAIâ to the mainstream?
Why is the industry starved from real innovation and what high impact problems are still unsolved after 4 years of revolution incremental improvements?
The point is to use Jevâs hype cycle to call out the manipulative marketing that are too familiar with at this point.
You probably donât need an intro to Jev at this time because since its introduction 33 days ago, it has been all the rage!
But if you were clever enough to ignore it, hereâs what actually matters:
Jev is basically a general purpose classifier (e.g. quick judgement). What makes it interesting is that you donât have to train it with a lot of data (although that lack of special-purpose training negatively impacts its utility).
Calling it a âdecision modelâ is a bit far fetched especially since it cannot even see (rival open-weight models have multi-modal features) or reason (thatâs how itâs so cheap).
The idea behind Jev isnât new! The idea of non-autoregressive decision models with RL goes back more than a year ago. The original author is pissed but as weâll see drama is an inseparable part of AI hype.
I want to walk you through the emotional roller-coaster I went through when I read their announcement via hackernews:
At OpenAI, I helped build the methods that made language models useful at following instructions and talking with people. That work ended up as the research behind ChatGPT.
đ So the founder was behind ChatGPT, one of the fastest-growing products in history. Iâm listeningâŠ
At the time, I thought maybe chat models would lead to AGI, but despite the hype it became obvious to me that there was something really big missing.
đ Oh, my god! This is it! ChatGPT is missing something big and heâs about to reveal it! Weâre one step closer to AGI if we havenât reached it already! Iâm thrilled to read moreâŠ
After two years in stealth, countless technical challenges, and research breakthroughs⊠I am beyond excited to announce
đ± Spit it out! Iâm beyond excited to read thisâŠ
TypeSafe AI is releasing our first System One Model
đŻ Wait what?!! âSystem oneâ?
Do you understand what youâre talking about? Hereâs my recollection of how Daniel Kahneman defined the two systems:
System one: fast, cheap (in terms of computational power), emotional, unconscious and judgmental.
System two: slow, expensive (takes more brain power), logical, conscious, and more elaborate.
If Jev is system one then LM is system two? It canât even handle logical reasoning!
Most importantly Jev came with another interesting framing:
canât hallucinate
Hallucination is one of the biggest problems with the current generation of language models but no hallucination doesnât mean the response is logically correct. In Jevâs context, it just means that the output matches the schema.
Technically conventional language models can gain this ability by bolting a control loop (e.g., type checker, JSON schema parser) on top. Jev does this much faster and without reasoning. Itâs in the name:
We named Jev after William Stanley Jevons. We expect machine intelligence to follow a similar path to coal, after steam-engine efficiency led to an increase in demand.
I donât know Jevâs architecture because in the true ex-"OpenâAI employee tradition, not much is released (probably in the name of âsafetyâ or âmoatâ). But that doesnât stop them from dropping jargons:
We built a new [âŠ] training method we call Reinforcement Learning for Calibrated Decisions (RLCD).
Note: RLCD rhymes with the âtraditionalâ methods:
RLHF: Reinforcement Learning with Human Feedback
RLVR: Reinforcement Learning with Verifiable Rewards
They even claim:
Jev is neither small nor an LLM, hence being off the intelligence Pareto curve.
Fortunately, thereâs no shortage of similar models, some of them with even better performance (Laya, Kev, Nimble, NanoJev, etc.)
So let me sum up the marketing strategy:
Name dropping: former ChatGPT creator, Jevonsâ paradox, Pareto curve, System one
Big claim: cannot hallucinate, exponentially faster and cheaper, entirely new stack, amazing benchmarks and demos
Ambiguity and jargon: no useful implementation details on the ânew training algorithmâ or RLCD dataset
Drama: Laya showed this idea in 1.5 years prior to Jevâs launch
OK, I think at this point weâve seen this pattern enough to recognize it. I actually think Jevâs team kicked it up a notch to a comical level. Whether their marketing is written by LLM or not, they nailed it.
Fortunately, Jevâs initial noise died off almost at the same speed that it blew up. I can only speculate that as more people experimented with it, we realized:
It cannot hallucinate, but it can still be wrong. It is even more wrong than conventional language models, and in that sense âsystem oneâ is the right naming. Although I consider all current generations of language models system one (even the reasoning models) because they do not really reason in the sense thatâs expected of system two.
It is cheaper, but there are open-weight models that beat it in performance/cost ratio (depending on the task). What makes Jev different than frontier-level LLMs is the fact that you can actually run it at the edge (e.g. locally) with matching quality.
Jev is not completely hype, we just went from âPeak of Inflated Expectationsâ to the âTrough of Disillusionmentâ in record time:
Itâs not dead. Some companies use it while I believe the majority of use cases are addressed by open-weight rivals.
I really donât want to bash Jev. Instead I want to use it as an example of where we are, as an industry.
I was one of the lucky few who got access to GPT-2 when it was invitation-only.
As a senior tech lead, I allocate part of my time to scout new tech and experiment in order to stay relevant. Prior to that, I had experienced IBM Watson and a bunch of other products so it wasnât a big deal for me personally.
I was actually underwhelmed by GPT-2 because at the time it could:
Summarize text
Predict what comes after a piece of text
⊠that was it really! đ I donât remember more than that. So I moved onâŠ
Then I saw someone create a turn-based dialogue from one of these models and to spice it up, they added an avatar to it. I thought it was creepy and funny.
Then Blake Lemoine came out claiming Googleâs language model named LaMDA was conscious. Unsurprisingly, this started a philosophical discussion thatâs still ongoing on the side. Again, I didnât give it too much thought.
BUT, Sam Altman, having spent a few years at the startup accelerator (Y Combinator), saw an opportunity. Specifically the chat application seems to have got his attention and soon ChatGPT was announced.
At the time, I thought it was a cool way to turn their token prediction model into a user-friendly product for the masses.
Personally, I couldnât use it seriously because:
Poor quality: it didnât know what it didnât know, so it just winged it (AKA hallucination). Although the rise of âprompt engineeringâ and âreasoning modelsâ promised to reduce this issue.
Privacy: I had been working with computers for 2+ decades at the time and live by the mantra that âif itâs possible, assume it happenedâ. Meaning if OpenAI is technically capable of storing my conversation, I cannot trust it enough to share any company IP or private information with it.
I vividly remember the backlash Google got for their multi-modal demo when people realized it wasnât recorded in real-time! Those were the days when even a small deception would be a conspiracy.
When llama.cpp came out I got a gaming machine with an NVIDIA card (AI machines werenât a thing back then) to build with AI.
Meanwhile people discovered that language models can generate code It was tedious to copy/paste it so we got the early versions of a harness.
Quickly after, we got âfunction callsâ which allowed the models to do stuff!
I was using VS Code at the time and the hype was hard to ignore even though my company at the time had a strict policy against using AI tools (yes! hard to believe that just 3-4 years ago companies prioritized IP over velocity).
I remember paying for a Copilot subscription out of pocket and using VS Code insider on my open source projects.
I was so frustrated that I shared this meme on the company Slack:
Meanwhile there was drama at OpenAI (Ilya was part of a coup that fired their CEO, then Satya was playing 4D chess while Elon was lawyering up). It was a sh*tshow which is exactly how it managed to capture the interest of non-techies, a trend that continues to today with âalmighty rogue AIâ hacking others while whistle-blowers and alarmists rise speak of existential threat!
Simultaneously premature AI products were creating dramas of their own (assisting crimes, cheating, etc.) and AI bros anthropomorphize the tool as if it had desires of its own (my read: they want to judge accountability).
Thereâs also circular investment, pentagon drama, chip wars, autonomous killer drones, etc. but in the spirit of brevity, letâs stick to the technical side of things.
Then Peter Steinberger, a veteran developer who was away from computers due to burnout, created an AI companion, which brought the Agents (LM that can do stuff) to the mainstream.
So far Iâve covered:
Instruction-tuned models
Function calls
Coding harnesses
AI agents
Letâs speed through the other incremental improvements:
Larger parameter size unlocks emergent properties that are hard to explain by analyzing the micro level architecture (mostly leading to sophisticated perceived behavior but also jagged alignment).
Larger context windows improve accuracy (although the practical limit is much smaller than the theoretical size).
Multimodal models enable generating voice, music, pictures, and videos while increasingly more models can understand these modalities.
MCP abstracts away the implementation and enables different AI products to use the tools needed to do productive work.
ACP, sub-agents and various orchestration techniques allow larger tasks to be planned and broken into smaller pieces.
Sandboxes help improve security and isolate unwanted side effects of agentic workflows and when they fall short, thereâs HITL (but we still havenât solved the approval fatigue).
Skills, web search and web access allow agents to access information thatâs outside their training data or knowledge cut-off date.
Various memory architectures and consolidation techniques enable the models to recall what they learn.
Chinese labs showed us more efficient ways to train and run the models.
Feedback loops and scratchpads improve the modelâs perceived quality by running part of the verification closer to the model.
This is good progress, no question about it. But I think a part of the reason AI is a hot topic is all the drama surrounding it:
Geopolitics: unlike the US economy which is primarily service-based, China is a manufacturing behemoth. Up until DeepSeek discovered that it can manipulate stock and AI investment by diffusing the compute equation, I donât think China had a solid AI plan. Now they do. Good old American sanctions target their chip import but China (being run by engineers) made huge strides recently both in chip manufacturing but also in model architecture. Meanwhile AI is used in warfare from drones to intelligence (and mass surveillance back home). In the best seller How the mighty falls, Collins lists 5 stages of demise: a) Hubris Born of Success, b) Undisciplined Pursuit of More, c) Denial of Risk and Peril, d) Grasping for Salvation, e) Capitulation to Irrelevance or Death. Those same stages apply to a falling empires and in this case US has bet big on AI while China diffuses USâs massive bet with open-weight models. Consumers win for now.
Debt bubble: You can read more on Bloomberg but it basically boils down to a series of interdependent bets that is so large it impacts the national GDP. It has to work regardless of how much IP has to be stolen and how many lies have to be told. The stakes are too high at this point.
Safety: we got used to the ârogue AIâ narrative where the AI vendors arenât held accountable for breaking into other companies and government institutes. Why would we? Itâs an open secret that the training data wasnât legally obtained anyway (and there are multiple class action lawsuits to prove that). On top of it, there have been multiple cases where people lost their lives due to AI â and Iâm not even counting âvibe warâ. (yes, I actually put an em-dash there!) đ
Impact on jobs: software engineering is low-hanging fruit for AI automation due to its nature (thereâs plenty of training data, and the tools are often on a language modelâs home turf). There have been discussions of UBI (universal basic income) and UHI (universal high income) but looking at the benevolence of the billionaires running the show, I donât buy it at all.
AI is hot, because it can potentially impact all of us. But we have to remember one simple fact:
Humans are fundamentally flawed when it comes to predicting the future.
Most notoriously, we have difficulty understanding the S-curve (meaning the pace of change is slow at the beginning and end).
And with prominent scientists leaving their lucrative positions to slow down the pace of development, we really cannot be sure about how long it will take for AI to really manifest the changes, if ever.
With all the incremental improvements of the past few years, we still havenât solved some fundamental problems.
Hereâs a short list of what I consider truly game changing:
Abstract reasoning: neural networks (not just language models) are prone to making stuff up (hallucination). The state of the industry has improved a lot since hands had 5+ fingers and videos were easy to detect, but the closest weâve come to a true system 2 is to pair the models with code and still the feedback loops and human intervention are necessary.
Continuous learning: auxiliary context (e.g. skills, grounding, search and various model architectures) has come a long way but weâre far from the state where the models learn in real time. By extension, the next generation of AI should learn from fewer samples, data and repetitions.
Embodiment: while there have been great improvements in robotic body form factor, weâre still not at a point where AI is rapid and efficient enough to be put in a robot body and react to the sensory stimuli in real time or expose fine motoric control and navigate the 3D world with enough prevision to take over âsimpleâ human chores.
Economics of running AI: Jensen Huang talks about installing âGigawattsâ of compute as if itâs normal to measure temperature in kilometers/hour!!! The truth is: our brain delivers AGI level intelligence at 20 Watts and until we solve that problem, there is not enough water, power and data centers that can realistically make massive change in workforce. Unfortunately, we live in a post-truth world where hysteria, personalized propaganda and mass psychosis have an oversized impact on the dominant discourse so weâre all supposed to be scared and distracted. The economics makes even less sense if we expect embodied AI (robots) to replace even a fraction of human population. Unlike bots, our organic bodies return to nature and participate in the natureâs recycling system much faster than metals and plastic that build a robot. Sometimes I feel we forgot that weâre living on a tiny rock with finite resources which get increasingly harder to extract.
All of this, is not to say that AI wonât be used to:
Robosoldiers and robocops
Generate new diseases
Connect mass surveillance to personalized propaganda
Corporate espionage and mass penetration into computer systems
etc.
The truth is: you donât need AGI-level of intelligence to cause destruction. The current generation of AI, paired with harness, tools and skills is plenty capable of causing damage in the wrong hands.
And if you think this is not happening already, I know a guy who gives free ice cream in his basement! đ
I think Jev is a good example of how great marketing fizzed out in the face of reality.
Is it useful? Yes.
Is it relevant? Yes.
Is it dead? Just its hype.
Is it revolutionary? Depends on your cost, quality, speed triangle.
Is it as big as it was claimed? I hope you have the answer by now.
If I had a magic wand, I would want us all to step back and see the holistic arc of recent events and calm down a little. The red flags are easy to see:
Name dropping: builds a bridge between the new unknown to the trusted known.
Jargon: makes you feel stupid for not having the context.
Ambiguity: lets your brain fill in the blanks and if youâre an optimist, youâre at risk of getting overly excited and eventually disappointed
Inflate expectations: big claims require big evidence. Donât trust the isolated benchmarks that do not resemble how YOU would actually use it, especially if the benchmark is coming from the same entity that has a conflict of interest.
Drama: engages human emotion to what would otherwise be a logical technical decision. âAll publicity is good publicityâ.
Unfortunately, I think that ship might have already sailed and in the age of mass-produced synthetic content and personalized propaganda, maybe weâre too stressed to think straight.
Maybe LLMs are âsystem twoâ, after all, if we collectively lose our critical thinking and let our emotions be manipulated with the kind of marketing and manipulation weâve seen too much lately.
Someone shared this on Hackernews (thank you đ) and it went all the way up to 2nd position. The early comments came at agentic speed but apparently didnât bother to read through.
Generally I find HN comments to be quite useful but there seems to be a botnet actively trying to take it personal and derail the conversation to marketing Jev even further. Weird. đ€
If you found this piece insightful, please share it in your circles and on social media to inspire others.
My monetization strategy is to give away most content for free but these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends. The simplest way to support this work is to like, subscribe and share it. If you really want to support me in lifting our community, you can consider a paid subscription. If you want to save, you can get 20% off via this link. As a token of appreciation, subscribers get full access to the Pro-Tips sections and my online book Reliability Engineering Mindset. Your contribution also funds my open-source products like Service Level Calculator. You can also invite your friends to gain free access or save via a group subscription.
And to those of you who already support me, thank you for sponsoring this content for the others. đ If you have questions or feedback, or you want me to dig deeper into something, please let me know in the comments.
Hereâs a little sideproject Iâve been spending my tokens on: https://gtajs.wtf/
Itâs a reimplementation of the 1997 Grand Theft Auto engine in JavaScript and WebGL.
The project is not entirely finished, but since I am leaving on vacation right now (I am currently at the airport), I might as well just publish what I have â and it’s already quite a lot I think đ
Note that because this is a reimplementation (itâs not a DOSBox wrapper / emulator / decompiled version / âŠ) there are differences compared to the original 1997 game in certain physics behaviors, animations, etc.
The mission engine is accurate though, as that is publicly documented (the almighty mtd.doc) đ
And yes, I totally asked Gemini to implement most things, referring Gemini to open source reimplementations, public documentation and community notes, or by simply telling it how I recall the game from playing it (and editing it!) a lot back in the day.
Still a lot of things to do (cops!) but itâs already playable. Enjoy!