Fundamental Engineering Principles

You need to define progress. You need to verify that progress is made. You need to know when there is no progress and what to do when you are stuck. Everything else is just noise and distraction.

Pre-AI Era

In the pre-AI engineering era, the ability to engineer was strongly coupled with coding ability. Coding was the prerequisite for real engineering.

Talk is cheap. Show me the code.

Talking in natural language omits important details and invites ambiguity. It’s only when all details that matter are spelled out (most often in code or pseudo-code) that the solution can be validated and measured.

Coincidentally, by learning to master a coding language, you also happen to be exposed to important fundamental engineering principles. Sitting through technical lectures, working on coding projects, and even taking pen-and-paper-based CS tests present you with fundamental engineering principles.

Post-AI Era

Coding has been transformed by AI. The best analogy I saw is that coding has undergone a similar industrial revolution that manufacturing did: coding is no longer an artisan job; instead, it becomes mass-produced. In the foreseeable future, most code will be generated by AI, with little to no human supervision. The value of coding ability will diminish toward zero. However, the value of real engineering skill will remain high. Some may argue that in a post-AGI world, engineering skill will also be zero since the AI can do everything. Maybe. But for the sake of this blog, I will focus on the short to medium term where working with coding agents is the norm. Today, the best AI-assisted programmers run dozens of coding agents in parallel, multiplying their productivity. Peter’s Shipping at Inference-Speed is the SOTA of this paradigm today.

What’s still hard? Picking the right dependency and framework to set on is something I invest quite some time on. Is this well-maintained? How about peer dependencies? Is it popular = will have enough world knowledge so agents have an easy time? Equally, system design. Will we communicate via web sockets? HTML? What do I put into the server and what into the client? How and which data flows where to where? Often these are things that are a bit harder to explain to a model and where research and thinking pays off.

The hard things today (e.g. picking dependencies and system design) require real engineering skills to solve. And engineering skills demand solid core principles.

On the other hand, autonomous cloud-based coding agents like codex and devx are becoming better and more autonomous over longer horizons. The job of a human working with such strong autonomous coding agents is very different from the CLI-based agents, which are designed to be used interactively. From my experience working with codex and devx, the critical things are: setting up testing standards, specifying the problem and requirements, and, well, system design.

As AI gets deployed into the bits world, very much like automation gets deployed to the industrial world, companies will slowly adopt more and more AI, with varying degrees of automation. So it is very likely that many companies, even with a perfectly competent autonomous coding agent, will still choose to have human engineers working closely with AI agents. Some may argue that the companies that use autonomous coding agents will outpace the companies that do not. However, this is where the AI-agent vs. industrial-revolution analogy breaks. In the industrial revolution case, the more automation you have, the more products you can build, which ultimately creates more value. However, in the software engineering case, the same amount of code that powers a messaging system that can serve 10 people can scale perfectly fine to millions of people. Software already has zero-marginal-cost scaling built in for free, thanks to pre-deployed servers and hardware. So no, writing more code faster will not bring more value to the world ¹.

So until the god-in-a-box ASI future comes and humanity decides to give up collectively, learning to engineer becomes more critical than ever thanks to the additional leverage that this AI automation provides. Although they may manifest in skills or tasks that look drastically different from what you expect a programmer to do today, at their core, they require the same fundamental engineering principles. Without further ado, here is my list of fundamental engineering principles ².

Fundamental Engineering Principles

Verify the Solution

Imagine you have the solution at hand, presumably given by your coding agent. How do you verify if it is correct? Ultimately, you are the first customer and should know exactly how the product should behave. Verification comes in different flavors: it can be end-to-end automated tests using CLIs, or even tests that simulate real users clicking buttons. Most unit tests, however, are easy to cheat and don’t provide much value beyond regression testing and documentation. Always try to test the real thing as closely as possible. And automate it. It is important for you to understand what the tests are testing and how to interpret the test results. With reliable E2E test infrastructure, you and your agent can validate and self-correct the solution.

Divide Problems Into Smaller Problems Until It Can Be Solved

All the cool demos you see of AI one-shotting an end-to-end application are cherry-picked. If one thing can be one-shot so easily, then what is its value ¹? Ideally, the project that you want to build will be unique enough and impossible to one-shot with a single prompt.

It may be daunting to build something you have not built before. But as long as you can break down a big project into smaller sub-problems and you can verify the solution for each small problem, you can keep making incremental progress. Practically, the sub-problem should be around the size that one decent AI agent can tackle in one shot, along with your testing infrastructure and code context.

Of course, this is a moving goalpost: as you mature as an engineer or as a coding agent, your atomic solvable problem gets bigger and more ambitious. You start to notice patterns. Patterns where a problem starts to look like something you have solved before. One tricky problem gets decomposed into a few familiar base cases that can be done easily.

But don’t get too used to a certain way of solving a problem. In the engineering world, there are often multiple solutions for one problem. Treat it as a blessing. Be curious, be fearless.

Intellectual Fearlessness

Try absolutely everything. Try different programming languages, frameworks, and tools. Experiment with different architectures and algorithms. Spin up a bunch of agents and do parallel explorations.

AI has made this so much easier. The sunk cost has effectively evaporated. You can just throw away thousands of lines of code and spin up new agents to work on a completely new direction.

Granted, for many engineering projects, a vanilla good-enough solution just works. But what’s the fun in that? I challenge you, the engineer in you, to push the boundaries of what’s possible. Work on ambitious projects: invent a new programming language, create a new browser or even OS, or build and experiment with a new LLM architecture. The more ambitious you are, the farther away from the training data distribution you and your agent will be. You and your coding agent may struggle. That’s how you know you are on the right track to doing great things.

Unleash your mind. Think outside the box. Think about extreme cases and edge cases then reason about how they change your system design.

Keep Track of Things

Like a good physicist, you need an experimentation journal. It can be git with clear commit messages, or just some notes app. When you are stuck, this is your map: a landscape of issues, assumptions, experiments, and validation results. You know how to debug things when you are stuck. Control your variables, do different experiments, compare the results, then you will know what knob to tweak.

Patience

Great works in history are almost always the product of great patience. The more you stare at your work in progress and think about it, the more likely you can find something you may have missed.

Honesty

Sometimes, I wish engineering were more like science, where lies are easier to catch. Engineers, drowning in the sea of complexity, sometimes just give up. Remember that mysterious bug you never got to the bottom of? Or the “calculated risk” you took. Never fool yourself with made-up explanations.

Closing Thoughts

When I write this, it’s fun to think about the coding agents that will read and react to this. In fact, I am experimenting with feeding a short version of this to my AGENTS.md ².

As mentioned above, by learning to master one coding language, you also happen to be exposed to important fundamental engineering principles. I can’t help but recollect the journey of identifying these engineering principles. It was mostly through learning physics and programming. Learning to code gives me the opportunity to adopt a set of new languages, with which I can describe and reason about problems. A new language also forces my brain to abandon many of the unhelpful biases ³ and frees my brain to think from first principles. Learning to code is difficult and messy, which is precisely how I learnt to be patient with my experiments ⁴. I keep a journal with all the ideas, experiments, and configs, where I learnt the value of trying a lot of different things and identifying hidden connections.

Learning programming or physics ⁵, in my opinion, is still the best way to experience the engineering principles. As I identify and enumerate the list of fundamental engineering principles, a few candidates emerged but didn’t make the list, such as Understanding & Knowledge and Simplify. I struggle to justify them as fundamental, something still needed as better agentic AI gets deployed. They are, in my opinion, engineering skills, still important to help you finish your project faster. But they don’t matter as much in a post-AGI world. Maybe I will write about it someday.

LLM Usage Declaration

This post is meant to be a very opinionated take. I did not use an LLM at all. I put my final draft into my summarizer prompt for fun.