The setup kept changing. The parts that survived are much more interesting.
I have been using AI heavily in my day-to-day work for roughly ten months now.
And by heavily, I really mean heavily.
It is involved in research, coding, understanding systems, comparing information, writing, validating changes, testing ideas, and quite a lot of the random work in between.
I originally started writing a technical series about how all of that works: agents, devcontainers, skills, scripts, safeguards, tooling.
The problem was that I was basically chasing my own tail. By the time I had written down how one part worked, I had already changed another part because I had found a better way to do it.
That is partly a me problem, because I keep tinkering with the setup, but it also says something about how quickly this space is moving.
After a while, the more interesting question became: which parts did I keep?
That is what this post is about.
This is not meant as a statement about where everyone should be with AI. The differences in adoption are enormous. Some people are pushing at the edge of what these systems can do, while others are still figuring out where AI fits at all.
I am also deliberately leaving the broader ethical and societal questions out of this series.
They definitely matter, but they are a different discussion, and one I am still working through myself.
In short
The biggest changes for me are not tied to one model or one tool.
- I try more ideas because the setup cost of exploring them dropped.
- I spend more of my own attention on architecture, evaluation, and steering.
- I move solved work into scripts, skills, configuration, and other deterministic pieces.
- I stopped treating prompts as hard boundaries.
- Reproducible and isolated environments became one of the biggest enablers.
- I care a lot about controlling the layers around the model.
- Speech-to-text unexpectedly became one of the biggest accelerators.
I spend less time on work I already know how to do
A lot of my work now starts with some version of: what if I try this?
That sounds more dramatic than it usually is. Sometimes it is simply: what if I compare these two tools properly? What if I contribute to this project? What if I connect these systems and see whether the result is useful?
The problem is that those questions often hide quite a lot of setup. A simple example was when I wanted to evaluate two options for central authentication in my homelab. Both needed a proper setup before I could actually compare them. Containers, configuration, dependencies, (not reading the) documentation, first-time setup, …
None of that is difficult in the sense that I do not know how to do it. I have been doing that kind of work for years.
It is just expensive in time.
If I have one evening after work, that setup can easily consume all that time before I even get to the part I care about. So I asked the agent to prepare both environments. Instead of spending my time on setup work I already understand, I could spend it actually using the tools, comparing them, breaking things, changing configuration, and deciding which one made sense.
That is probably a better description of the change than saying AI lets me do things I could not do before.
A lot of the time I absolutely could do it before. I just no longer want to spend my focus on the parts I already know how to do.
I still want to steer
That does not mean I want to hand everything over. I like setting out the architecture. I like evaluating what was proposed. I like pushing on something when it technically works but is not yet the solution I want. A Drupal 7 to Drupal 11 refactor is a good example.
The agent understood the broad modernisation work perfectly well, but in the details it still fell back to patterns I did not want. The result worked. That was exactly the problem. It was close enough that you could stop and say: good enough.
But I didn't want to stop there.
So I pushed it back towards how Drupal Core actually approaches the same problems. We refined the architecture, and once the decisions were clear, we captured them as ADRs so the next application would not have to start from the same conversation again.
That loop is much closer to how I see the relationship with an agent. It proposes. I evaluate. I push. We make decisions. The useful decisions become reusable.
I do not expect one prompt to produce my personal definition of quality at the other end.
I am still accountable for what comes out
This is also why I do not currently see full autonomy as the main goal. I know there are setups where an agent keeps looping until it decides the work is done. That is interesting, but it is not really how I want to work today. The main reason is simple: the result is still mine.
If a commit goes out under my name, it is my commit. If I post something, it is my message. If a technical decision turns out to be bad, I cannot really point at the agent and say it decided that.
So I want enough involvement that I still understand what happened and why. That does not mean I want to manually perform every step. Quite the opposite. The repetitive parts are exactly where I am happy to let the system move quickly.
I stopped trying to prompt my way to guarantees
My first reaction when an agent did something wrong was basically: make the instructions better.
Be more explicit. Add another rule. Explain the edge case.
At some point one of my commands had grown to almost 400 lines. And the model would still occasionally ignore something. That eventually pushed me towards a larger multi-agent setup, with different agents for research, planning, execution, writing, and orchestration.
That taught me a lot, but the lesson that survived was much simpler:
If a rule really matters, I do not want that rule to exist only because I wrote it in a prompt.
So now I make a distinction between local work and actions that leave my machine. Changing files, running tests, drafting text, creating a local commit: fine. Pushing a branch, posting a comment, triggering something external: different category. Those actions need explicit approval, and that is enforced structurally in the tooling rather than only through instructions to the model.
It is not some perfect security system. But it is already much better than hoping the model remembers one important sentence somewhere in its context.
My old obsession with reproducibility turned out to be very useful
Containers are not something I discovered because of AI. I have been slightly obsessive about automation and reproducibility for years. If I have to maintain something myself, I do not want it to depend on whatever happens to be installed on my laptop that day. So almost everything I work on is containerized. The host only gets the things that genuinely need to live there.
That principle turned out to fit AI-assisted work extremely well. Each project has its own environment and dependencies, while my own working layer gets added on top automatically. The agent runtime is there. The tools I use are there. My configuration is there. I can move between projects without rebuilding my working environment every time. And when something really does need to run locally, I try to keep the exception small.
How the Chrome bridge works
Chrome is a good example. I want the agent to be able to use a real browser, but I also want to see what it is doing. So Chrome runs locally in a sandboxed profile, and the container talks to it through a small bridge.
The principle stays the same even when the implementation has to bend a little.
I want to control the layers around the model
This is also where my preference for open source comes in. Not because I think closed software is automatically worse. There are excellent closed products, and open source projects can make bad decisions too. For me it is about both freedom and community.
I want the ability to inspect something, change it, contribute a fix, or adapt it to how I work. And I value the community side just as much: more people can look at a problem, challenge an approach, and improve something together.
AI makes that especially interesting because the barrier to producing a first contribution is getting lower. More people can describe a problem, work with an agent, and get to a merge request. That is powerful, but it also means the quality and review side becomes even more important.
The model itself is already one part of the stack I do not fully control. So I care even more about controlling the parts around it: the harness, skills, scripts, tools, context, environment, and execution boundaries.
Yes, MCP
Let’s have a chat about MCP. Because I have been going back and forth with it quite a bit, and I see others having the same struggle.
To be clear, I am not against MCP. I use it. But I stopped seeing it as the automatic answer to every integration problem.
These days I often start with a much more boring question:
If this were not AI, how would I automate it?
Very often the answer is a CLI or a small Python script. Fetch the data. Normalize it. Return what I need. Once that works, a skill can explain when and how the agent should use it. That gives me something I can test without the model, use from CI, run manually, and reuse later.
MCP still has a place. I just increasingly prefer deterministic building blocks when the task itself is deterministic.
Speech-to-text was the unexpected accelerator
This one was not planned at all. At some point I was already running several agent sessions in parallel and getting increasingly frustrated that I could not type fast enough to keep feeding useful input back into them. Then somebody pointed me to Handy, which runs speech-to-text locally on my machine. That changed the loop almost immediately.
I can speak fast (people who know me can acknowledge that), much faster than I can type. More importantly, I can get thoughts out closer to the speed at which I have them.
When I type, I compress.
When I speak, I naturally include more context: what I saw, what seems wrong, what I already tried, what I want checked, and what I do not want changed. I can also jump between related ideas much more naturally. Because the transcription runs locally, it also fits the rest of the way I want the system to work.
Speech-to-text turned out to be much more than a convenience.
It became an accelerator.
What surprised me most
One thing these ten months made very obvious is how uneven AI adoption actually is. If you spend enough time around people close to the front of the train, it is easy to feel like you are already behind. There is always somebody trying another model, another harness, another autonomous setup. Then you look somewhere else and realise there are teams and entire domains still figuring out where AI is useful in the first place.
The distance between those parts of the train is huge. I do not think that is automatically bad. It mostly reminds me that there is no single adoption curve here and no one speed everybody should be moving at.
That is also why I want to keep this series grounded in my own technical workflow rather than turn it into a prescription for how other people should work.
Where I ended up
If I look back at the last ten months, the interesting part is not really the tool stack.
That will change again.
The more durable part is how I now approach the work.
I try more things because getting to a first useful result became cheaper. I spend more of my own attention on architecture, evaluation, and steering. I let the model help heavily while a problem is unclear, and once something becomes known, I try to move that knowledge into scripts, skills, configuration, ADRs, validation, or other reusable pieces.
I no longer treat prompts as hard boundaries. I care a lot about reproducible and isolated environments. And I want enough control over the tooling around the model that I can inspect it, change it, contribute to it, and move away from it if I need to.
How this post was made
There is one last part of this story that feels important to mention.
This post was not written purely by me, and it was not written purely by AI either. The process was much closer to the way I now like to work in general.
I started by talking. Instead of trying to sit down and write the perfect article from a blank page, I used speech-to-text and answered questions about what actually happened over the last ten months.
Some of those answers were clean.
Most were not.
They had repetitions, half-finished sentences, jumps between ideas, corrections halfway through a thought, and all the other things that happen when I am speaking faster than I would ever type. But they also contained something I often lose when I try to write everything down myself: the nuance. The reasons why I changed my mind. The small caveats. The examples that only come up when somebody asks one more question. The difference between "I think this is the right way" and "this is simply what works for me today."
The AI did not invent those parts. It interviewed me, helped identify where the story was still too abstract, and kept asking for concrete examples. Then it helped turn those spoken answers into written language.
That part took several iterations as well.
The first versions were too polished. They sounded like a generic technical article. Short dramatic paragraphs, clean little conclusions, and sentences that were probably easier to quote than they were for me to recognise as something I would actually say.
So we changed the process. Instead of taking my thoughts and turning them into "professional writing", the goal became to keep the way I enter a topic, change direction, qualify something, and eventually arrive at the point. The short sentences and occasional pauses in this article are part of that.
They are not a transcript of how I speak. That would be terrible to read.
But they are also deliberately not cleaned up until all of the rough edges disappear.
That hybrid process is probably one of the things I find most interesting about using AI this way. I still have to provide the experience, opinions, examples, corrections, and direction. The AI helps me get those thoughts into a form that other people can actually read. And for somebody who can speak much faster than he can type, that turns out to be a pretty important difference.
In a slightly strange way, this post is therefore also one of the examples in the post. It is the result of the same loop: I provide the direction and judgment, the system helps with the work in between, and we keep iterating until I can stand behind the result.
What comes next
There is a lot hidden underneath the ideas in this post. The evolution from one agent to many and eventually back down again deserves its own explanation, especially because that is where I learned that instructions and structural boundaries are not the same thing. The devcontainer setup deserves one too. A lot of the speed I described here only works because the environment underneath it is predictable and reproducible.
The combination of skills, scripts, CLI tools, and MCP is another part I want to unpack properly, because my approach there changed quite a bit as well. And I want to write more about the "what if?" side of this. That is probably the part that changed which problems I am willing to start on in the first place.
Those technical posts make much more sense to me now because there is a story underneath them.
This is that story.