Table of Contents
For the last twenty years, web developers have had a central role in the tech industry. We learned the DOM, wrestled with CSS frameworks, and built a lot of CRUD applications.
That role is changing as the routine parts of web development become easier to automate.
When implementation gets cheaper
Building a standard website is much easier than it used to be. Low-code platforms and AI coding assistants have lowered the barrier to entry. When a prompt can produce a functional React component in seconds, typing out the component carries less value. Deciding how the system should work carries more.
For engineers, that moves more of the work toward architecture and orchestration.
What the job market suggests
Recent analysis of engineering roles suggests that demand for traditional frontend engineers is shrinking.
As companies automate more interface work, frontend implementation becomes easier to buy. Higher-growth roles are moving upstream toward the systems that drive those interfaces. An engineer whose work consists entirely of translating Figma designs into HTML and CSS now competes with tools that can do much of that work quickly and cheaply.
From UI to agency
A website gives people a place to perform a task. An AI agent can take the user’s intent and carry out the workflow across several APIs. Booking a flight, for example, no longer has to begin with a user navigating through a series of menus.
That changes the engineering focus. Alongside pages and components, we increasingly have to define how a system reasons, uses tools, and recovers from errors.
A changing engineering role
I’ve felt this shift myself. The edit-refresh cycle of web development is familiar and satisfying. As automation takes over more routine implementation, though, engineers have an incentive to learn how agentic systems work.
The transition involves more than changing programming languages. It introduces a different set of engineering problems:
- Handling nondeterministic outputs that can change between runs
- Giving models safe access to tools and external systems
- Evaluating whether the system works reliably, rather than stopping when the code compiles
Why I started Practically Agents
There are plenty of tutorials on how to “chat with a PDF,” but far fewer explain how to build agents for production. Introductory examples rarely prepare you for messy data, failures, and edge cases.
I created Practically Agents to cover that gap. It focuses on the engineering behind agentic systems: how to build them, test them, and make them dependable. It is also the material I wanted while adapting my own skills to this changing market.
Websites will remain part of software products, while more of the interesting engineering work moves into the agents behind the interface.