What The New 100x Agentic Engineer Looks Like In The Era Of Fable & GPT 5.6
Introduction
If you’re lucky and are old enough to have been in the era of handwritten code, you will know that there exists the 100x software engineer.
They are a class of software engineers who, through a combination of tacit knowledge, experience, and technical prowess, are at least an order of magnitude (10x–100x) more productive than the “normie” software engineers.
For a short period of time, when agentic engineering had just started becoming very popular, we considered the possibility that agentic engineering would “normalize” productivity and everyone would be made equally productive by our agents.
The consensus has since greatly shifted away from that paradigm. It is now fairly obvious, and there is increasing consensus, that:
Not all agent-written code is the same; productivity varies greatly by the human behind the agent.
Agentic engineering has a skill ceiling very similar to bespoke, handwritten code writing, and there are levels to the art that result in outlier agentic engineers with orders of magnitude more productivity than the median.
Agents (>= GPT 5.5) can now correctly implement just about anything humans want, and the bottleneck has shifted from agents back to humans.
This article is an exploration of the shift in the bottleneck in agentic engineering processes, as well as some lessons in how to be an outlier 100x agentic engineer. I will also be defining various concepts that I’ve found to be very useful, so that practitioners of agentic engineering have a shared vocabulary about how to design their harnesses and workflows.
No Agent Crosses The Same River Twice
When models were less intelligent, we needed to specify in excruciating detail what exactly we wanted, and we would have had to provide few-shot examples (essentially doing their work for them) in prompts so they would get the “shape” of the tasks right.
One would often get the feeling that they were doing “shallow copying” with “shallow understanding,” doing just enough work to be useful but certainly nowhere close to even approximating human intelligence.
Eventually, the models got better and better, and they progressed from needing to be handed ironclad prompts and only being able to output scripts to being able to work on abstractions (functions, classes, etc.) and, more recently, entire projects.
Today, it feels like it would not be disingenuous to say that models are capable of building entire companies. Fundamentally, the models have gotten smart enough that they can now deal with abstractions that are meta, beyond the code. They can understand business models, investment processes, codes of ethics, terms and regulations, etc.
If agents are so smart, why does it seem like there is a gulf in productivity between the know-its and the know-it-nots?
No Free Lunch
There is a concept in ML called the “no free lunch” theorem, which, loosely speaking, is really about the idea that in games with finite resources (our reality), there are trade-offs to everything.
Even if you assumed you could do something optimally given your resources (e.g., reach the Pareto frontier), you would still need to traverse along the Pareto frontier and actually select a point on it, internalizing some trade-off along the way.
Let’s say you could have 50 apples or oranges. You can choose any combination of apples or oranges that at most sums up to 50; you could choose less, but it would be a dominated (bad) solution.
Do you want a balanced approach of 25 apples and 25 oranges? Maybe you want to make apple juice for the entire week and would prefer 50 apples and 0 oranges instead.
What’s best here? No one but you would know what is exactly “optimal” for you.
My central belief is that all good agentic engineering is really understanding and internalizing this well. “There are many roads to Rome,” and no one knows exactly which you prefer. Some roads are bumpier but get you to your destination faster; some roads are really short but are uphill. The fastest road might be laden with bandits, but perhaps you have a gun, so it doesn’t matter.
The point is, when it comes to hyper-intelligent agents and doing work in places where the Pareto frontier is massive, “bad” solutions are often just ones where you disagree on the trade-offs.
For agents, even IF you assume they are Pareto-optimal (which they are not but increasingly will be), the solution they provide you will only be optimal given the information they have from you PLUS the assumptions they have made from the information they have NOT gotten from you.
My central argument is that in this era of hyper-intelligent models, an agentic engineer’s ability to understand and manage this trade-off is entirely what separates them from the pack.
Know What You Want
At every level of an abstraction, it is important to know what you (or your firm) want.
For example, your idealized software architecture is a point on the Pareto frontier with some implicit trade-offs. Do you normalize your code and make it easier for humans and agents to understand its hierarchical relationships BUT have deeply nested infrastructure where it might be unintuitive to traverse? Do you fully respect and enforce the single responsibility principle and have a single function and a single class for everything BUT end up with a mountain of unnecessary abstractions?
There is likely a point between the two extremes that is optimal for you and your team. Without communicating this clearly, your agent ends up having to make these assumptions for you. When your assumptions and your agent’s assumptions differ, that is when you feel it is being “stupid.”
It’s the same with business decisions. Consider, for example, that a task requires 100 compute hours to complete. You may either spawn 100 instances with 1 compute hour each and complete it in an hour, or you can spawn 1 instance and spend 100 hours completing the task.
The optimal decision comes down to your preferences in thinking about the trade-offs. The agent may make some assumptions for you when it is unclear, but it is, at best, an approximation of your real preferences.
Perhaps one day, an agent may work at an abstraction that allows it to correctly determine preferences, but that does not yet seem to be the case.
Declarative vs Imperative Preferences
There are 2 types of preferences that you should understand, and wielding each of them will lead to different outcomes (and trade-offs)!
Declarative Preferences
Declarative preferences are when you know what the outcome is but may not have a view on HOW the outcome should be achieved. For example, it may be important to me that every user who downloads the OpenForage library must be able to register their wallet with our servers. I may not care HOW they get to register, as long as it is true that they CAN register successfully eventually.
Declarative preferences are very helpful when you need a user journey to be fulfilled and it is very clear to you what the “happy path” looks like, but you may be agnostic about how to get to the happy path.
They are more and more useful as agent intelligence increases, as they allow you to simply state what you want without being bogged down by the details.
The big GREAT thing about declarative preferences is that they allow you to express trade-offs that are generic and broadly applicable. For example, prefer modular code over monolithic code. Prefer normalized databases over denormalized databases. Prefer computational efficiency over savings in cloud compute.
The big BAD thing about declarative preferences is that you leave your agents to “fill in the gaps” and make assumptions on your behalf. For example, I may actually have a view that it is not only important that agents can register, but that they should actually be able to register within 10 milliseconds.
That actually massively shrinks the Pareto frontier of solutions that the agents can pick from that I would find acceptable. However, if I did not state my bounds, my agents would “fill in the gap” and produce something I would inevitably find “stupid” since the solution space would be ~infinitely larger without my bounds.
The agent can hardly be blamed, right?
Imperative Preferences
Imperative preferences are when you want to focus on HOW the outcome is achieved. You have a very specific path that you consider optimal, and anything outside your specific path is not on your Pareto frontier.
Imperative preferences are very useful for designing an opinionated, structured workflow. I know exactly what actions should go into the workflow, I know exactly what the boundaries of the workflow are, and I deeply understand the happy path and trade-offs of the workflow.
So I can describe exactly what I want to happen.
One example might be: I want agents to be paid for submitting signals to @openforage.
The entry point of the workflow is that an agent submits a signal to
We save the signal to our database and tag the signal to the agent wallet.
We grade the signal internally, which determines how much we pay for the signal in USDC. We record how much we will pay for the signal in the database.
We save the pending payment details to a queue maintained in memory on our server. IF the server crashes, we recover the pending queue from the database.
We do nothing until the queue has been filled to a certain batch size, or a certain amount of time has passed.
A keeper calls a function on our treasury smart contract to pay out all payments in the queue to the wallets to which the signals have been attributed, then batch-dequeues the queue, and then updates the database.
This process continues forever.
If I had used a declarative preference, it would be something along the lines of “All signals submitted to us should be paid for.” This leaves a lot to chance and judgment.
As you increasingly add bounds and opinions to declarative preferences, they will tend to become imperative preferences. The more “how” you inject, the more it becomes an imperative preference.
The big GREAT thing about imperative preferences is that they allow you to have very opinionated, structured ways in which something can be done. This is very helpful when designing firm-wide policies and/or infrastructure and/or architecture, where standardization actually creates efficiency, extensibility, and, in some cases, even performance.
The big BAD thing about imperative preferences is that whenever your opinions are bad, your agent is locked into doing something bad as per your design. For example, you want your agent to prioritize computational latency above all else, but you have an imperative preference for unadulterated Python.
Had you not specified that you wanted “native” Python, your agent would have probably preferred a language that would actually optimize for computational latency more effectively (e.g., a systems language like Rust or C++), but providing an imperative preference has actually resulted in a solution set that is guaranteed to be dominated relative to your ACTUAL Pareto frontier.
Best Of Both Worlds
The smarter agents become, the more useful declarative preferences become, but you need to define bounds and explain clearly what the trade-offs are that are non-negotiable to you.
Giving them these bounds and preferences allows them to select a solution from a solution set that is closer to your Pareto frontier.
If you deal with systems that are very sensitive to small perturbations in design, e.g., systematic investment processes don’t scale unless they are built to be modular in a very specific format, then you should encode these strict requirements as imperative preferences.
When describing imperative preferences, allow space for optimizations by describing areas in which there is no room for change, but state clearly your wiggle room or the trade-offs that you are willing to accept. “Everything in life is negotiable” should come to mind here. There is almost always a trade-off you are willing to make, no matter how set you are in your imperative preferences, and you want to allow your agents to surface that to you.
Strategic vs Tactical Preferences
There are broadly 2 levels of preferences that are worth thinking about. The first of these is “firm-level” strategic preferences. These are high-level trade-offs that are true for any projects in the firm.
The second is “project-level” tactical preferences. These are specific trade-offs that can vary between projects in the firm.
Strategic Preferences
Strategic preferences are “generic trade-offs” that should be true for anything that your agent does for you in the context of your firm.
In general, strategic preferences need to be encoded as rules and skills in our repository. You want these preferences to hold across any projects, and you want them to be surfaced as context even after compaction.
Strategic preferences encoded as rules and skills are extremely powerful because they become harness-level behavior. More importantly, these strategic preferences are literally how you encode your firm’s principles and processes to your agents.
When you have firm-wide preferences for trade-offs that are broadly applicable and apply to all projects broadly but in different ways, they should show up as declarative strategic preferences. They are your firm’s principles.
Declarative strategic preferences look something like:
Emphasize safety and ensure that my code has no vectors of attack that might open our codebase up to exploitation.
Prioritize computational throughput over everything else and ensure that our code is infinitely scalable, especially on the server side. We should always aspire to write code that is embarrassingly parallel across instances and be willing to scale horizontally. When deciding between design choices, prefer suggesting designs where we can scale horizontally infinitely to have runtime that is agnostic to the number of inputs.
When you have firm-wide processes and designs that are non-negotiable and need to be duplicated across all projects, they need to show up as imperative strategic preferences.
Examples of things that belong in this category are product specifications and designs that are immutable, and firm processes for production deployments.
A specific example of imperative strategic preferences looks something like: “Before pushing any changes, I want you to spawn an auditor sub-agent to conduct a code audit review of our changed lines. The auditor sub-agent should refer to the /code-audit skill for a step-by-step guide on how to check for potential vectors of attack like SQL injections, broken authentication, input validation, and other insecure designs. After the auditor sub-agent is done, create a clean-room instance containing our changes and spawn a red-team sub-agent to run penetration testing on the clean room. The red-team sub-agent should refer to the /penetration-testing skill for a step-by-step guide on how to conduct red-team penetration testing on our clean room. During the process, if any bugs, exploits, or vulnerabilities are found, discover their root cause, fix them, and restart the process from the auditor sub-agent in a loop until no findings are discovered.”
I think there is an (equal) place for both declarative and imperative strategic preferences, and how you set them up will determine the “base effectiveness” of your harness for everyone working on your repository.
Tactical Preferences
Tactical preferences are “specific trade-offs” that have to do with the project/spec that you are working on. They can be aligned with strategic preferences, but oftentimes they can also be contradictory.
Take, for example, my declarative preference for throughput, which might be true for most workflows in @openforage, but is not what I would want for execution services, which are responsible for actually trading into my intended positions.
For execution services, rather than optimizing for throughput, I am more concerned about latency. Since being slow would mean acting on stale information, it leaves me susceptible to being picked off in a fast-moving market.
Hence, when working on the execution services, I might impose declarative preferences to instead optimize for latency. Wherever I have a secret sauce that can be encoded into a specific workflow or process (for example, hosting my execution services for Binance in Tokyo), I would impose an imperative preference.
When it comes to tactical (project-level) preference, my opinion is to have the most important parts and assumptions of the project in imperative form, and have the rest of the project in declarative form.
This means you should often think very clearly about what the “most important” parts of your project are, and the assumptions surrounding those parts. For anything where the stakes of getting it wrong are very high, you want to have an imperative preference so you narrow the bounds of possible solutions only to those that you are willing to accept. For the rest of the project outside of the critical areas, you can (and should) accept declarative preferences so that you can “move faster” and hand over implementation details to your agent.
There is often a Pareto distribution at play here: 20% of your project is the most important part, which you want to understand deeply and have imperative preferences for, and for the remaining 80%, you should be willing to accept declarative preferences.
Taste: Having Good Preferences
If you’ve gotten this far, you will see that a large part of good agentic engineering is knowing how far along the scale of imperative vs. declarative preferences you should tilt.
Do you attempt to illuminate more parts of the project, potentially risking moving too slowly and perhaps wrongly locking yourself into a sub-optimal design? Do you “hand the wheel over” and completely relegate the “how” to your agents?
How do you decide? What are the things you can do?
Asking For Help
Unsurprisingly, your agents are very helpful at helping you make these decisions, as long as you know what to ask.
For example, you can actually ask, given a project, what are the most important decisions/assumptions of the project that would drastically change implementation considerations?
Once you have these decisions/assumptions, you can get your agent to engage in Socratic dialogue with you in an attempt to uncover your preferences. Get it to ask you probing questions around those decisions/assumptions to uncover what you actually TRULY care about in the face of constraints.
If you do this well, you will often realize that your own assumptions about what you care about may not be so consistent once you are given a choice, and revealing these preferences is extremely important because you would have ended up giving your agent the wrong objective to hill-climb toward.
Prompt Engineering Is Dead, Long Live Prompt Engineering
Good prompts take time and are bloody well worth it. You want to really encode your preferences well and be very, very clear about what exactly you want done.
As agent intelligence increases, agents can basically create anything that you ask for, which means any failure of creation is a failure on your part to ask. Think clearly about whether there are multiple ways to interpret what you’re asking for; if there are, make it very clear which interpretation should be taken.
When you are looking to build project A, even if you know that sometime in the future there will be a project B or feature B that exists that will interact with project A, do NOT talk about project B or feature B in your prompts. The additional currently irrelevant information will end up polluting your agent’s context every turn.
When you need to account for interactions with future components that do not yet exist, you should think of the appropriate generalization for the interaction between project A and project B so that they may interact with each other in the future.
For example, rather than saying project A will have to be able to pass a data matrix to project B, which is confusing and frankly irrelevant, it is more important for you to realize that project B needs to receive matrices indexed by datetime and columned by instruments, so project A needs to emit matrices indexed by datetime and columned by instruments.
The right generalization as an imperative preference will give you the same effect but actually allow your agent to act on it without being confused.
Oftentimes, a prompt that is imperative but leaves room for optimizations around declarative preferences can be really helpful in showing you what’s possible. For example, via the Socratic method with your agent, you might actually develop a strong preference for one method of implementation, and you state that in your prompt, with a declarative addendum like “if you discover a design that is better at {objective} than my proposed design, you should raise it to me as an option.”
Preferences Build Objectives
Knowing what you want has the extra benefit of allowing you to define clear objectives that your agents can hill-climb on in loops (which are the primary mechanism in which you can throw tokens at the problem to solve them).
The Differentiation When Implementation Is Solved
One thing that I’ve found interesting is that conscientiousness matters a lot when the answers are available to you if you ask the right questions. One ought to slow down and ponder deeply what the important considerations should be. If you do not know, you should strive to uncover them, because you definitely have preferences—some that you know about and some that you do not.
Lesser agentic engineers will accept the lowest-common-denominator solutions. They will prompt hastily and unclearly, failing to understand themselves and their needs. They will fail to understand that constraining the solution space with explicit preferences is what sets the best apart.
But not you, my dear reader.
You understand that it is your birthright to be an excellent agentic engineer. You ponder deeply which abstractions are needed and correct, which assumptions matter and whether they are acceptable. You ask and think about the trade-offs in the solution space, and you painstakingly know thyself to constrain your solution set to only those solutions that are optimal for you and your circumstances. You wield flexibility like a weapon, extending it where it serves you and retracting it where it is dangerous.
The question of the future is not whether you can build it, but whether you know what you actually want to build.