Frontend Engineering

Architecture answers important questions.

It helps us define boundaries, distribute responsibilities, and shape systems so they remain changeable over time.

But architecture alone does not create good software engineering.

A well-structured system can still be poorly tested. A sound design can be undermined by an unreliable delivery process. A team can make sensible architectural decisions and still approach every release with unnecessary uncertainty.

And even excellent code becomes difficult to work with when nobody knows how to change it safely.

That is where Frontend Engineering begins.

More than writing code

Frontend Engineering is not only about how we implement features.

It is about the engineering practice surrounding real frontend systems: how we build them, verify them, deliver them, observe them, change them, and keep them reliable over time.

That includes software quality, testing, quality gates, code reviews, CI/CD, tooling, technical governance, and development processes. It also includes roles, collaboration, and the way teams make decisions and share knowledge.

Many of these topics are less exciting than a new framework or a clever architectural pattern.

In day-to-day development, they often matter just as much.

The engineering around the architecture

Strategic and tactical design primarily look at the system itself.

Strategic Frontend Design asks where boundaries should exist and which parts of a system should evolve together or independently.

Tactical Frontend Design asks how those boundaries and responsibilities take shape in actual code.

Frontend Engineering looks at the environment in which those decisions have to keep working.

How do we know that a change is actually correct? What level of quality do we want to achieve? Which rules should be automated? Where is a code review enough, and where do we need mechanical verification? How do we prevent important knowledge from existing only in a few people’s heads?

And, of course, which tools genuinely help us?

Tooling becomes interesting when it improves the work, not simply because it is new.

Professional software engineering is a system

Software quality rarely comes from a single measure.

One test does not make a test strategy. A linter cannot replace architectural understanding. A pipeline does not automatically make a team faster, and a quality gate is of limited value if nobody understands why the rule exists.

Professional engineering emerges from the interaction of many smaller practices.

Good tools help. Clear processes help as well. Automation can expose problems early. Reviews can spread knowledge. Documentation can preserve the reasoning behind important decisions.

And sometimes the most valuable improvement is neither a new tool nor a new pattern, but simply clearer ownership.

That interaction is what Frontend Engineering is interested in.

Roles are part of engineering too

Software development is not made up only of technical artifacts.

People take on different roles, bring different strengths, and look at the same system from different perspectives.

A Senior Developer is not automatically a Software Architect. An Architect is not automatically the strongest developer on the team. A Tech Lead, Staff Engineer, or Solution Architect may again have a different focus and a different scope of responsibility.

Those distinctions are more than job titles.

They influence which decisions someone is expected to make, which perspective they are supposed to bring, and how responsibility is distributed across a team.

That is why roles, responsibilities, and collaboration will also have a place in this area over time.

Not as organizational theory for its own sake, but from the perspective of real engineering work.

And then AI arrived

LLMs and Coding Agents have become an important part of my own work.

I do not see them as a separate architectural layer, and I do not see them as a passing side topic either.

They are tools within software engineering.

Very capable tools, but still tools.

They change how quickly code can be produced, how we search for information, how we analyze requirements, and how much work can be automated. At the same time, they increase the importance of verification, explicit knowledge, and clear technical boundaries.

That makes them a natural fit for this area.

Not as a hype topic, but as another part of the engineering toolbox that has to prove itself in real work.

Series

Agentic Work in Real Life

The first larger series in this area looks at LLMs, Coding Agents, and Agentic Work from the perspective of professional software engineering.

It starts with the foundations of LLMs and benchmarks and then moves increasingly toward practical work with Coding Agents. The series covers context, memory, requirements, architecture, data protection, verification, AI-friendly software, and the economics of agentic work.

By the end, the interesting question is no longer which model happens to lead a benchmark today.

It is what changes when producing code becomes easier and other parts of software engineering become more important.

The series therefore neither celebrates AI nor dismisses it.

It looks at the tool, its capabilities, and its limitations where they ultimately matter: in real software development.

What belongs in this area

Frontend Engineering is intended to cover the topics that sit between an architecture diagram and a production system.

Quality and verification. Delivery and tooling. Development processes. Large-scale applications. Technical governance. Roles and responsibilities. New tools, and the question of which ones actually improve the work.

Not every topic needs a grand theory.

Sometimes a good method is enough.

Sometimes a reliable process.

And sometimes the best tool is simply one that does its job without trying to become a new religion.