Notes
Most of my shorter writing happens on X. These are selected notes I want to keep easier to find. I have lightly edited them so they make sense outside the original thread. They are dated because the tools change quickly, and so does my thinking.
Experienced engineers still matter
I am an old-school software engineer: design patterns, domain-driven design, TDD, all the things. I loved the craft for a long time and still do. I miss writing code, and I also understand that the role has completely changed.
All of it still matters, but in a different way. You do not need to read every line of code now, but you do need to make sure the tools reflect your experience and preferences.
I still believe the people who benefit most from AI coding tools are the people with experience and battle scars. They also seem to be among the hardest to convince that this is real.
Write the important context yourself
It is easy to ask a model to write every skill and instruction. The result is often generic because the model only knows what you gave it.
If you are building something you plan to use repeatedly, do you want the model filling in the blanks with an average set of instructions?
I like to open a text editor and write the instructions myself. I pretend I am giving instructions to a new employee. I do not need to specify every step. I need to explain the context, constraints, and goal that come from knowing the work.
Use deterministic tools for deterministic work
Break what you are trying to do into smaller steps. If code can handle a step reliably, write that code and give it to the agent as a tool. Do not ask a model to imitate a process that ordinary software can do reliably.
Look for problems you can test
Many narrow fields have outcomes you can check, or at least check well enough to be useful. Very few people have built that checking into an agent yet.
If an agent can try an answer, test it against a useful signal, and try again, the pattern can work outside math, code, and benchmarks.
Domain expertise still matters
If you know a field well and can write down what you know, you can get a lot from language models. Learning these tools is easier than learning your field.
Prompting tricks are not the important part. You need to write down what you know, decide where judgment belongs, and give the model that information in a form it can use.
Write the content before building the presentation
One of my favorite things to do now is focus entirely on the content in text. I open a text editor and work through the exact message, organization, and flow I want.
Once the thinking is there, I ask Claude to turn it into an interactive website. Separating the thinking from the presentation makes both parts better.
Production agents need more visibility
Claude Code and Codex work very well interactively. But when an agent moves into production, it matters more that you can see what the harness is doing. The model is already nondeterministic. Adding another layer you cannot inspect makes the system harder to understand.
I still use general-purpose harnesses for most interactive coding and many background jobs. For mature projects and agents inside products, a smaller custom harness can give you more control over context, models, cost, and correctness.
The right level of instruction has changed
What models need from instructions has changed. A year ago, context often meant specific steps, guardrails, and a long list of things not to do. Now, too many rules can get in the way.
Spend time outside the agent writing down what you want, what information is available, and what a good result looks like. Do not prescribe every step. Some of my best recent sessions started with instructions I wrote myself.
Build systems that keep improving the work
One useful version of compound engineering is to use agents, automations, callbacks, and scheduled jobs to make a process a little better without remembering to do everything manually.
In some codebases, I run a weekly job that inspects recent changes and produces an architecture overview, a changes summary, and a map of how the services fit together. Future agents can use that context directly. The same material also becomes a small interactive site that the team can explore.
I now ask what small system I can build once that will keep improving the process. Not everything needs to be a chat interaction.
Companies need people to implement AI
Even if the tools stopped improving today, it would take companies a long time to use what is already possible. In my work with teams, access is not the main problem. Companies need people who understand the work, know how to use the tools, and have time to change the process.
Most employees are busy doing their actual jobs. Few people are responsible for figuring out how AI changes a role, how work moves between teams, or how to put those changes into practice.
Adopting AI means changing how work gets done
These tools make you reconsider how work gets done, how it moves through a company, which roles do what, who works with whom, and which systems need to exist.
You cannot simply add AI to the current process and expect it to work. You have to step back and decide how the process itself should change.
Give the model a filesystem, not a blank chat
A lot of people still open a blank chat, paste in context, ask a question, and start over next time. That works, but it forces the model to rebuild its understanding in every session.
Tools with filesystem access can list directories, read files, search across them, follow links, and work out where the useful context lives. This works outside code too. A well-organized folder can become a map of the work.
Small markdown files can provide project context, constraints, preferences, examples, and links to deeper material. What belongs in those files and how they stay current require judgment, but the starting point is simple: point the model at a real body of work instead of an empty box.
Leaders need to learn by doing
Leaders cannot delegate all of this. Find the people inside the company who already understand the tools, watch how they work, and then use the tools yourself. You will learn more from doing that than from a presentation.
People also need time and permission to learn. Most employees already have a job, and that job does not include rethinking it with AI. Telling people to learn is not enough. Leaders need to give them space to experiment on real work.
Practical habits for coding with agents
Distill useful session history into markdown. Maintain a compact project map with progressive links. Run more than one code review, including reviews with fresh context. Automate recurring checks and documentation updates when the process is stable enough.
Do not skip planning. You still need to describe clearly what you want to build. That thinking matters more than pressing the button quickly.
Connect the harness to the work
Teams can get a lot done by connecting an agent harness to their data sources and giving it a well-designed skills library. Those connections and instructions have to be reliable enough to use.
When a needed system has an API but no existing connector, a small custom tool is often enough. The building blocks already exist. The work is choosing the right abstractions, writing clear tool definitions, handling authentication, and testing the whole path.
The first version can become the specification
For some projects, the first version of the software is a way to discover the requirements. Build it quickly, try multiple approaches, and see whether it creates value. At that stage, the lessons matter more than the shape of the code.
When the idea is ready to ship, distill what you built and what you learned into a specification another agent can use. Rebuilding from that clearer specification can be better than preserving and gradually refactoring the exploratory version.
Make skills work together
Turn something into a skill when you have done it repeatedly and it has real steps. A useful skill reads the relevant context before it asks a question, shows proposed changes before writing, and cites the information it used.
The output of one skill should become useful context for the next. Over time, the skills and files form a map the agent can follow without making you explain the project again. That is when a collection of commands becomes a workflow.
Skills drift as the collection grows. Audit them for inconsistent conventions, overlapping responsibilities, and missing steps. Not every task should become a skill. Keep them for work you want done consistently.
Build for change, not stability
The right way to build AI-enabled products can change within a few months. Sometimes rebuilding is more sensible than adapting a system designed around assumptions that no longer hold. The same tools creating the change also make rebuilding cheaper.
You cannot wait for everything to stabilize. Build something useful, keep the underlying knowledge portable, and design the process so that replacing a component does not mean losing what the team learned.
Carry improvements across the company
The same idea behind compound engineering can apply across a company. Useful context, repeatable workflows, and review practices can be written down once and reused by other teams.
Some companies will use AI as a limited assistant. Others will change how information and work move through the business. Access to the models will be common. How the company organizes the work around them will matter more.
Agentic engineering is not vibe coding
Agentic engineering requires systems thinking, architectural knowledge, testing discipline, and the ability to describe in technical detail what you want. You also need to recognize what good work looks like.
The work includes choosing an incremental approach, deciding what the agent should build first, defining the right unit of work, and creating feedback loops that make the process more reliable over time.
A voice memo is enough to get started
Open Voice Memo and talk through everything you want to accomplish. Keep talking after you think you are done. Transcribe the recording, give it to the model, and ask the model to question you until it understands the goal.
The point is not a perfect prompt. It is getting your real context out of your head and into a form the model can work with. Curiosity and persistence matter more than knowing the tools in advance.
Update: The original workflow used plan mode. I no longer use plan mode regularly. The durable part is speaking your goals, providing real context, and learning by using the tools. Read the newer note on X.
Read the original and replies on X →We need better ways to direct many agents
A useful development environment now needs to coordinate many agents, support different models and harnesses, and connect them to an actual backlog. The human is directing the work instead of operating on one file at a time.
Opening more terminals is easy. The real problem is giving many agents clear work and pulling their output back together without creating more overhead.
Ask whether the work has a measurable signal
Any metric that can be evaluated efficiently creates the possibility of an automated improvement loop. Agents can try changes, measure the result, keep what works, and repeat.
For any domain, ask whether you can test the outcome reliably enough. If you can, this pattern can work outside code and model training.
Give agents a map of the territory
Give agents a map of the territory, distilled into as few tokens as you can. The first context they load matters. A clear, dense map lets them explore with tools instead of starting from one long, messy document.
For larger codebases, I often include an architecture file with a Mermaid diagram of the system. It is token-efficient and usually puts the agent on the right path.
More work will start inside model tools
People are starting to do the work itself inside tools from the model companies. Software companies should assume customers will want to bring their data and product capabilities into those tools.
Trying to reproduce every model capability inside an application may become a losing race. In many cases, it will make more sense to let the model tools use the product's data and actions directly.
Today's tools contain yesterday's hard work
At one of my first software jobs, I had a coworker who was a wizard with grep, sed, awk, regular expressions, xargs, and tail. He would pipe them together to solve a problem while I wrote a hundred-line Java program.
I sometimes think about how his hard work, and the work of people like him who shared what they learned, is one of the main reasons we can just do things now.
Start with what the model builders publish
The teams building the models know a great deal about how to use them. Some of that knowledge is published as skills, examples, and tools that help write instructions. You can use those directly.
Before writing a complex instruction set from scratch, look for a strong existing starting point. Then adapt it to your work and apply your own judgment. The reusable context is valuable, but taste and domain knowledge still determine whether the result is good.
Use normal work as feedback
To improve an agent, you need a record of what it did, a way to tell whether the result was correct, enough examples to spot patterns, and a process for changing its context or tools.
The best feedback already happens inside the work. A code change being accepted or rejected is more useful than asking someone to complete a separate evaluation task. Collect the signal without giving people another job to do.
Use the tools before hiring someone to implement them
If you have not spent real time using the tools, you will have a weak filter for deciding whether someone else knows what they are doing. Before hiring outside help, use an agent on a problem from your own job for at least a week.
You do not need to become an expert first. You need to see what the tools do well and where they fail so you can ask better questions and recognize practical advice.
Classical machine learning still matters
Classical machine learning remains useful. Many business problems need classification or regression, not a generative model.
Language models can now help people explore data, write the surrounding code, test approaches, and learn the underlying methods. Better AI tools make conventional machine learning more accessible; they do not make it irrelevant.