The Agentic Engineering Myth - 1 Year of Coding with AI

Updated: 08/09/26 | Published: 08/09/26

We have a video on our YouTube channel about what used to be my default work environment setup: OhMyZsh and Janus: Set up productive work environment in 10 minutes or less. For many years, and I mean literally for around a decade of my career, this setup did not change. It didn't have to. Every now and then I tried different editors, different terminals, different tools - but nothing brought even a single percentage point improvement over what I already had.

The essential, core part of what I am doing happened inside my head, while the less essential part - typing out the texts, the code or issuing commands - did not really need much of optimizing, despite many people trying to sell the idea that it did. Then ChatGPT arrived and everything changed.

Like most of us, I've started chatting to ChatGPT to generate some snippets of code. I later switched to GitHub Copilot, to get that sweet auto-complete - since this point, I did not write a single one-file script by hand, and I do produce a lot of scripts for many different purposes, from data analysis to migrations to just small useful automations wrapped in a CI/CD system.

It took GitHub a minute to add an AI chat side panel to the VS Code, so I switched to Cursor, that offered us both the auto-complete within a file, as well as a sidebar to keep the conversation with AI going.

Cursor added more and more sophisticated multi-file agentic editing capabilities, and the work shifted even further from having AI assisting me with the less critical, less essential part of writing the code. I could focus more and more on my ideas, on the architecture, on planning systems, and less on fighting with using the correct bash parameter or crafting a Terraform state migration statements. And, as time went by, I could even bring to life the ideas for which I was previously not going to be productive enough to bring them to life without sacrificing everything else I was working on.

Eventually, Claude Code arrived, powered by a model powerful enough to stop merely enhancing my existing processes. Instead, it completely re-defined how I work. Almost a decade of just using Vim via Terminal feels like a stone age. In the last 3 years I changed the tools I use for the core of my brain-to-world work perhaps on a monthly basis. I will keep changing them, as long as the pace stays as high as it is right now. I did change them while working on this article, and I am going to talk more about which tools I am using today in a bit.

For the period of around 6 months I was collecting links to the articles written by people, who were much ahead of me in the agentic engineering game. I thought that at some point I will be able to publish them as a list of things for others to learn from. I realized, that most of those articles are now obsolete, and their authors kept refining and changing their processes to the point that their original writings look like something from the last century now. What stays is that they keep sharing their work - so as an appendix to this text I will provide both the names of people I think you should follow, as well as that original list of articles that they wrote.

For the remainder of this text, I will share my established processes, favorite tools and approaches for productive agentic engineering, as well as some of the thoughts on where it's going in general and what you should care about. I will also share some of the things I built that I can share publicly - a lot of my work is a consultant work, so there are many details I can't share, but the details don't matter that much anyway.

The Brain on and the Assembly Line: is AI replacing us?

The biggest question everyone is asking - and should be asking - is whether AI is replacing us and what the hell is going to happen to our jobs.

My dear co-founder Pablo predicts that there will be no developers, no DevOps guys, no infrastructure people, no designers and no one at all within the next 1 to 2 years. Unfortunately for Pablo, he did this prediction in 2022, 2023, 2024 and 2025. I say unfortunately, because I see how hard Pablo still has to work every day despite being equipped with all the AI tools available - and I know from my own experience, that within the last 4 years I started working way more and there are just so many more things to do.

I can't say Pablo is wrong and AI is not going to make lots of people jobless. If US billionaires say that governments will need to pay unemploment money to the people due to jobs lost to AI, then we should be worried of whats to come. We will (probably, really, I don't know) reach a point where the governments will have to do something with more and more people losing their jobs.

But I do feel like this whole topic is a bit like that fusion energy joke, that it’s only five years away, and we hear that for the last 50 years. AI is going to take all of our jobs in the next 1-2 years, and we hear this now for 4 years. Yes, fusion energy will arrive. And AI is going to take all of our jobs. Probably before fusion energy arrives.

As of today, I like to think that my brain is still worthy. My thinking shifted a layer up, and I mostly think about what needs to be done and how, do the research and analysis, come up with improvements and review the code. Most likely reviewing the code part will become less and less relevant. I see it a bit like the introduction of the assembly line at Ford factories:

Elements of mass production, such as part standardization, were in use before the Model T. And the move in 1910 of production to Ford’s new Highland Park plant led to a rapid series of improvements culminating in 1913 with the novel use of a moving assembly line (Nevins Reference Nevins1954, chap. XVIII). The assembly line saved many labor hours. In summer 1913, for instance, before an assembly line was installed, it took 12.5 hours of labor to construct a Model T chassis. In December 1913, after the installation of a system in which the chassis moved continuously (an assembly line), labor time per chassis had fallen almost 80 percent, to 2 hours and 38 minutes (Nevins Reference Nevins1954, p. 473). As a result of improvements like these, in 1914 Ford made 260,722 cars with 13,000 employees; all other U.S. car companies combined made 286,770 cars with 66,350 employees (Nevins Reference Nevins1954, p. 488). - The Model T

I still design the car, and I have to continuously improve my assembly line (more on this later), and I can assemble my ideas much faster. I am still responsible that this idea doesn't fall apart, malfunction and kill someone. Software is a bit of a more flexible and chaotic thing than a mass-produced road car, so sometimes it's probably closer to a Ferrari factory - ideas and craft go hand in hand with modern tools to produce, ideally, something exceptionally well. Though let's be honest, most of the work is and was, in any case, more resembling of a million of units per year regular car factory. With AI, you can do both, more of both, faster - produce millions of units of relatively standard and boring, but required work, while also finally having capacity and freedom to build something you always dreamed about building.

Expensive Tools and Expensive Tokens

Regardless which model or harness you are using, you need to invest money for AI to be truly useful for your work. You can't afford thinking about tokens and limits too much. I am not suggesting you to actually pay API prices for the tokens - this is outside of the budget for most of us, it's even outside of the budget of companies like Uber.

We are lucky (as of September 2026), that AI companies still offer the subscriptions that don't seem to make financial sense for them to offer: it's estimated, that $200 Claude Max 20x subscription plan gives you in total $6,000 worth of tokens to burn through, not taking into an account sporadic limit resets both Antrophic and OpenAI regularly do to either apologize for some fuck up, or just as a marketing technique to pull more users from competitors to their harness - press the button again, Tibo!

At the same time, telling most people that they are lucky they can spend "just" $200 a month on a new subscription feels stupid. $200 a month is not a negligible amount of money. For most of the world, it is, truly, an investment. If you can make your company do this investment for you, do this. If you can afford it yourself, do it too. And if not, then opt-in for the cheaper subscription tier, of course - you will accelerate yourself by 2x instead of 10x, and that's still a good ROI. You can probably deduct that from taxes as an expense; at least in Germany you can.

I've started with a $20 Copilot subscription, moved to a $80 Cursor subscription, got my first $500-600 monthly bill from Cursor and instantly switched to $200 Claude Max 20x plan. At some point, I could not ignore the fact, that OpenAI models and Codex are on a very similar level, so I also got a $200 ChatGPT Pro plan. With Grok being back in the game, I might end up also getting their top-tier plan, or Cursor Ultra perhaps - if I will figure out how to scale the real bottleneck - my brain - even further.

If this sounds excessive, I recommend reading The Shape of Things to Come :

My solution has been to create a token tap on $200 Max accounts, which for me work out to ~30x the list-price equivalent. So in reality I'm only spending about $2800/month out of pocket for my $87k "worth" of tokens. Though that number keeps growing alarmingly. ... In order to sustain my pace of development, I pay for currently twelve extra Max accounts, in addition to my personal one. Each account is tied to a dedicated named Google Workspace user in my domain (another $17/month per account).

Whenever you read an article about someone from OpenAI or Antrophic doing some crazy loop or graph engineering with an army of agents working on a thousand things at the same time, keep in mind that these people have an unlimited token capacity on their hands. Some companies also have huge budgets and are ready to burn them and make every employee tokenmax like tomorrow will never come. But for the rest of us, the best we can do is get those subscriptions, maybe many of them if you can justify the cost, and make sure you burn your weekly limits, ideally couple of days before the week ends, so that you can have a break too.

I can't tell you which provider is the best at the time when you read this. Today, Fable is the king when you need some real smart companion, but both Opus 5 and GPT-5.6 Sol bring similar results, though with a different character of its own and quirks/preferences. As mentioned, Grok 4.6 seems great in benchmarks, and 4.7 is coming any time. Open Weight models are so close to the frontier ones that you might consider using them - though I am not sure if using open weight models via some cloud hosted API/subscription and through some harness (than can also be configured to use frontier models) is a real win. I guess if you spend thousands of dollars on your own hardware, you can get a better ROI, but I really doubt that.

Skills, MCPs, Plugins, CLIs

On top of the expensive tools that do the work, there is a huge and ever-growing collection of open source tools, utilities, skills collections and plugins that promise to make your coding agents even smarter. I keep trying them and I keep finding out that most of them are rather a distraction for the simple reason of models just getting better and faster on their own.

Only private project-specific skills make sense

Some open source Skills are great, if they are written by the people who develop your harness and models. This is why I mostly trust the skills that come bundled with Claude Code and Codex. But when it comes to third party collections of skills, I am yet to find something that would make things better and not just confuse my agents.

Take famous Compound Engineering, which has 33 Skills and growing. I have to trust the community, that this collection is excellent, but I can't stop thinking, that this collection being public and all, Antrophic and OpenAI won't just use them in their next training cycle, thus making these skills just the way the model works out of the box.

I have a theory, that the better models we get, the less we need to wrap it with dozens of huge skills. Claude 5 family of models shows that I might be right: most of system prompt was removed when these models are in use by the harness. There are numerous reports on Fable 5 working worse if you give it huge prompts and instructions. The model became smart enough to require less guidance. This trend will likely continue, meaning that a comprehensive skills collection will eventually become a liability and not a competitive advantage, simply because the model will work better on it's own.

I still write lots of (relatively small) skills, but all of them are extremely task-specific, or even project specific. The model won't learn how to properly open a PR in a particular private code base, or how to orchestrate the deployment of a concrete service in a custom environment. In such cases, having repo-local or organization-local skills like deploy-service, open-a-pr, analyze-resource-usage etc will save you some tokens and ensure AI follows your process.

MCPs vs CLIs debate is pointless

I trust my agents to use whichever CLI they need to get the job done, but I also use plenty of MCPs all the time. The reason to use MCPs, despite them wasting way more tokens, is a product reason. I want to be able to do some work regardless if it's my laptop, or my iphone, or a Slack message. In many cases, it means that I don't have a compute environment where CLI is installed and available. The way AI companies solved it is by letting you configure MCPs (or Plugins, or Connectors, or whichever word they use today) once and use them in any environment AI company provides.

So if I want to be able to access my emails or track time via claimora, the most reliable way is to configure MCPs in Claude, and then it will work in Claude Code Cloud, local Claude Code, local and cloud Claude Cowork and even (though with much worse quality) regular Claude Chat. Same goes for Codex. At the same time, if I am at my laptop, there is no reason not to rely on local CLIs to do the work.

Sometimes MCPs work better, sometimes CLIs work better, some environments allow you to install any possible tools and CLIs, others only work via connecting external tools via MCP protocol, so discussing what is best and what is worse is pointless - you have to give your agents any tools it needs, regardless of the implementation.

Context Engineering and Management by Abdication

While it's tempting to let AI Agent pick it's own technical stack and just vibe it, this is the approach that let me down most often. Owning the technical stack and architecture decisions, or, at least, being proactive in working with AI on these decisions is critical to the long-term project success. Short term, and even to some extent mid-term, AI can make all the decisions for you. Eventually comes the moment, where you realize that these decisions were none-sensical and you spend days refactoring and migrating the data to make your product work again.

I'll give you a recent example where I once again made a mistake of not thinking the architecture through myself and just trusting GPT 5.6 Sol to do it for me. At one mkdev-internal project, I needed to use OpenAI Batch API, to analyze lots of content and not to spend a fortune on it. The way Batch API works is simple: you bundle lots of requests into a batch, and submit it to OpenAI. Within 24 hours maximum, all the requests in the batch will be processed, and you can pull the results via a Batch ID.

The task I gave to AI was simple: switch to using Batch API to reduce the costs. What AI did looked correct during the initial tests - batches were created and processed, results were pulled by the system and used inside the app. Satisfied with initial small test, I've submitted a huge ingestion campaign. What I saw in a couple of hours is the amount of batches that did not make any sense even for the campaign of this size, as well as over a million of Lambda executions and rate limit errors from OpenAI, telling me that I can't query Batch API so often.

Confused, I checked what Codex did for me. What it did was some crazy pulling implementation, where a scheduled trigger would make API call to OpenAI if batch was complete and if not, it would re-scheduled itself to SQS. At some point, OpenAI started throwing rate limits for checking the batch status, which further increased the amount of re-schedules on my application side, which further increased the amount of requests.

This was the moment I realized, that AI didn't even consider using webhooks to process batch processing results. OpenAI can send a webhook as soon as batch is complete, which is a clear signal for our application to pull and use the results. It's the most obvious, clean way to handle these batches, with no pulling required and no cloud resource waste. I thought AI will do this most obvious architecture, but instead it came up with a monster that just wasted money and processed things in the slowest possible way.

Another example is our OpenAI Terraform Provider. The first version did not use the correct Provider SDK, because we did not do the required research and just vibed it. It did cost us a full re-write of the whole thing, which did not take that much time, but could have been avoided entirely.

In management, this "approach", or rather a leadership pitfall, is called Management by Abdication - which, among other things, involves delegating tasks without providing the necessary context, resources, or follow-up. Every time I've delegated big architecture changes to AI without providing the context and without pairing with it for a plan phase, it ended up creating another beautiful mess, that seemed to be working, but was deeply broken and dysfunctional.

The Agentic Engineer Myth

I've heard about the idea of "Management by Abdication" from the famous entrepreneurship book The E-Myth. It's fascinating, how different concepts around management, product engineering, leadership, legal and other "soft" areas translate directly to how we work with AI. This particular book might be one of the best conceptual guidebooks for you on how to use AI Agents effectively, so you will have to excuse me for doing a little de-tour into some of the main ideas from this book.

According to "The E-Myth", most businesses are started by Technicians. The book itself gives an example of a lady named Sarah that really likes to bake, and decides it's a reason good enough to open her own bakery. Most of her time initially goes into the actual process of baking, with little time left on fulfilling two other roles - the ones of The Entrepreneur (the visionary and creative mind behind the business) and The Manager (pragmatic person that likes to organize everything, make systems, have predictable plans etc).

There is a moment in this book, when Sarah, the owner of the bakery, decides to just hire whoever she finds to do all the accounting and bookkeeping, without ever looking into it herself. She then repeats this process by filling in couple of other roles. Nothing good comes out of it, because all the new hires lack the context and the rules to do the good job. This is used as an example of Management by Abdication, and I think this is how we often start using our AI Agents. This goes beyond just agentic engineering and is applicable to any AI agents, which is a good topic to cover in a separate article. For now, let's get back to the main focus of this article: coding with AI.

Engineers start coding with AI as Technicians, and none-Engineers start it as Entrepreneurs. The first group ends up doing way more lower-level work than what AI enables them to do, while the second group tends to abdicate themselves from anything but just vibing through The Vision. Unfortunately for both groups, they need the skills of each other, as well as learning how to be a good Manager - Manager of AI Agents, which might not be too far away from being a Manager in general.

Now, all of this is to essentially say that to be a good agentic engineer, to truly 10x yourself without risking building an unfixable mess, you need to be both good and experienced engineer to start with, as well as to be ready to manage AI, by giving it the rules, the context, the direction, but not giving it the lowest implementation details possible. With this, in my opinion essential conceptual background, let’s go back to how I actually plan and assign tasks to AI.

How I assign tasks to AI Agents

When the big idea comes

When I have a new idea for a new "thing", I typically try to one-shot it. The best way to do it is to take the mightiest model, switch the harness to Ultracode mode (or at least some Max level of effort) and just explain to it what you want to have. At this moment, you can already give it some technical boundaries, but it's also not necessary just yet.

When I built Apex Copilot app - a little weekend passion project for Forza Horizon 6 video game - I just explained to Claude Code, that this video game is able to emit telemetry data during every race to any IP address, and that I want some cool iOS-native app that can receive this data and show to me some bad-ass HUD. I hit enter, and went back to playing the game. 40 minutes later, Claude told me I can test the app on my phone. I sent the build to my iPhone, connected it to the game and, more or less, it already looked like a ready to use app.

The only boundary I set initially is that I wanted a Swift native app. Even though I never did iOS development professionally, I kind of prefer my iOS apps to be as native as possible.

When you decide the idea needs a proper MVP

If some quick PoC looks like I might be able to make something useful out of it, I start setting boundaries and defining a technical stack. For example, when it comes to new web applications, I know that I want Ruby on Rails, TailwindCSS, Hotwire and Stimulus, as well as the code base that in general is following Rails-way (that also happens to be a really good path for AI agents). This kind of boundary is easy to hand over to AI and it will be happy to follow it, as long as it's documented in AGENTS.md.

This is also the moment where I start planning more than coding. I start lots of parallel sessions, again with the smartest model out there, asking it to do the deep research and then asking it follow up questions. I want to spend as many tokens as possible at this phase, to make sure I fully understand what kind of architecture is going to be built for the feature, which components are involved and connect to each other. While I don't care too much on how every particular line of code will be written, I need to know that I will be able to read this code, trace how it works if the hard debugging session arrives, and I need to know how it works conceptually.

For example, if I am building something with vector search, I will ask AI to evaluate sqlite, pgvector, S3 Vectors, DynamoDB Vectors and so on; I will ask it to check the prices and analyze how it might scale, which features each option has and how it fits to our domain.

Usually I learn a lot of new things in this process myself - which is a good sign, or at least a better sign than if AI would just pick some random vector store for me and I would have to re-factor it 3 times later on to use the one that actually makes sense. This is also the phase where I am reading a lot myself, in case that I am building on top of something that I never worked with before. Even if AI will write all the code for me, I want to have an idea of what it is doing and why.

When you have a small task at hand

Expand our hugo web to highlight that Caimora works with AI and has an MCP for timetracing (do also in a SEO-friendly way)

Not every task requires this whole procedure with the long planning, interviewing AI and so on. Sometimes you just have a small idea or a task, and either you feel confident AI will get it right, or you know just the right words for AI to get it right. I am talking about small things like Add a new link to this page, but also about a bit bigger things like Create a Lambda function that processes webhooks from OpenAI BatchAPI and saves the result to the database.

When you just know something ain't right

I want you to perform proper deep research on how to optimize our DynamoDB usage in all aspects, reading online sources, docs and so on. We need this to be ready to grow much much further without crazy costs so we need to do this right. Current production data is already important so migrations / changes need to be done carefully.

Finally, quite often there is no obvious task, but you just know that something in your codebase ain't right. I like asking AI to just analyze whole codebase and find what can be better - either I ask it to remove all the dead code, or check if performance or costs of some parts of the system could be improved, or just some general clean up. Tasks like this can be easily put in a loop. Sometimes AI finds nothing, sometimes it finds something. Maintenance, dependency upgrades, refactorings - modern AI agents are quite good at it and you should totally use them to help you out with this.

Beads, Context and Memory

Unless it's already done, we need to document our design system and branding, to make sure all AI agents follow this and dont diverge. We currently have fantastic design so we need to be sure its followed going forward

I used to ask AI to write down as many things as possible in docs/ folder. There are many different ways to approach this, including some quite comprehensive solutions like llm-wiki.

So far just simple markdown files, regularly groomed to remove any obsolete info, worked quite well without adding extra tools. I try to keep these files small and focused, so that they give just enough context for the agent to do the right thing - how our API is structured, how our data is structured, what is the core idea of the app, what are some of the nuanced implementation details. I read this doucments myself quite a lot, and it’s important for me to agree with them. If I see that the agent needs even more info, I might add another folder with a bit more info. Naturally, most of the docs are written by the agent itself, and I just review it.

Recently, I've started adding Beads to all the projects where I could add them, primarily the ones where I am working alone - I am yet to try working with Beads with a team. I won't explain too much about how beads work, except that it's a minimal AI-focused, fully-local, git-backed issues/tasks manager, that is used more or less automatically by your coding harness after you go through a one-command init process. I am also using Beadbox, to have some visual overview of the issues, though I am not a huge fun of it. I highly recommend reading the introduction article and just give it a try. You could probably get a similar result by using any project tracker out there, but this one is local, open source and is built by a person who is arguably one of the post productive agentic engineers out there.

Once I started using beads, my workflow changed a bit. When I plan new tasks, I wrap it up by telling AI to create either an epic or just regular beads/issues for this task. Then I open a new session and I just say implement projectA-xxx issue. It does feel like Beads gave my agents some extra cognitive boost, as they seem to know much better what happened, what need to be done, what is blocking what and so on. Also, the backlog constantly gets new items without my involvement - the agent just decides to park some bug fixes into an issue instead of just jumping on them.

At the same time, I also see that every harness expands the way its memory works. It becomes more and more automatic and behind the scenes, with the obvious goal of just knowing your project without all this extra markdown files and open source tools (and probably locking you into a particular harness). Just as the better models make complex prompts and skills less necessary, better harnesses will probably make all this markdown files management and agentic issues tracking obsolete / part of the harness itself.

What I also realized at some point, is that mono-repos are the winners. They were insanely attractive long before AI, but with AI having everything in a single repo just gives the agent way more power. If you have your mobile client and your backend API and your marketing website all in a single repository, then AI has way more context and is able to implement new API endpoint, new feature in iOS app and adjust a marketing copy to mention this feature all in one go. Don't sleep on mono-repos.

As I already mentioned before, what I think will still make sense doing even after the model and the harness can seemingly do it all, is to create context and skills for your particular specific processes, workflows and designs.

For design in particular, given how sloppy AI design still looks and how easy it is for AI to diverge from the original, I found creating a separate static website with the branding quite useful. For mkdev projects, we have https://design.mkdev.me/ - we can then instruct AI to design everything by following this design system. As a result, all of our products will look like they are part of the same brand.

Shipping your work

If we talk about working on your own products, the next bottleneck you will hit once optimizing how your agents pick up work and how work is structured is how to ship your work. If you did everything right, at any given moment you will have a dozen agents working on different tasks, with new tasks getting done every 20-30 minutes or so.

My current approach for making sure all of this can be shipped safely is to have a separate agent, that runs in a loop and delivers PRs one by one. When the task is "finished", it means it will open a PR and label it with "ship". If automatic code review has some comments, the label will be removed and the agent will need to address the comments.

Meanwhile, the release agent finds all PRs with "ship" label, merges them and deploys, one by one, whole day, as long as there are things to ship. It uses in-project skill that knows how to deploy this particular project, and each project has its own release agent.

I am still experimenting with setting agents running in a loop, but release agent in particular proved to be an extremely useful colleague for day to day operations.

For mobile apps, my approach is to use Fastlane with lots of custom workflows inside - to generate release notes and new screenshots, for example. When I am ready to cut a new release, it's typically a single command, that takes up to 40 minutes to run (due to build process and screenshot generation) and I end up with a new build waiting for AppStore Review.

The Real World

What I described so far will definitely sound like something that can't work for an engineer that operates in a big team and doesn't work on their own project. This is fair, and introducing Agentic Engineering as well as AI Agents across whole organization is a different topic, one where you should totally hire mkdev to help you with this.

At the same time, I believe that many of the tips and practices I shared so far can be applied as-is even if you do not have the same freedom to vibe like it's your own product. I do hope that your company embraces the future and gives you all the required AI licenses, which means you can use many of the tips from above.

The key to remember is that now you have a freedom to do more. The technical debt projects, the clean ups, the refactorings, small improvements and internal tools, bigger projects that didn't get a priority due to limited resources - now you can work on all of this.

If you do it right, what used to take weeks will take a short after lunch session. You've been in the organization long enough to have all the context, which is all you need with the modern AI coding agents. You will find yourself just throwing new tasks at GitHub Copilot (if you have it) only because you had a quick idea - and you will find yourself shipping these quick ideas many times per day.

It's true, that in a real big company the limit of using AI is not your brain anymore, but the policies and the rules of the company. It's a separate task to find how to operate within these rules, and how to slowly change them for better.

Staying sane

Arguably the hardest part of all of this is to stay sane and calm.

At first, all of this feels like I got the power clip. Then you realize, that this seemingly unlimited power is not only hard to organize into a productive process, but is also hard to resist.

I find myself working more than ever before, just throwing more tasks at this AI coding slot machine. I am almost happy when I hit my weekly token limits, as I can finally reset, write this article, read a book, get a life.

It could be this issue is not applicable to everyone, but only to those who are cursed with a brain that always comes up with more and more ideas to work on.

I can't say I found the perfect system and the balance, and this constant feeling of "I can also do A, B and even C today" is at times exhausting.

One thing that helps is to focus on just a handful of projects and tasks. While you certainly can release 200 apps per month, you can't make all of them succeed and become truly useful if you are always working on another idea.

Another thing that helps is to organize your work into loops, automations, workflows. If you have an idea, file it as an issue together with AI, start prioritizing them instead of just doing them all at once (beads, again, is quite useful here).

Your output, the mount of things you can do now, is almost limitless, but it's a whole job to make sure this jetpack on your back pushes you towards the right direction.

What's next?

Most likely half of what I wrote is obsolete by the time we publish this article, and another half will be obsolete within a month - at least this is what I see happening to the most articles on this topic. It's a crazy journey for the whole industry, and we are all going through it together. Perhaps, I will try to update this article on a quarterly basis with new learnings and unlearnings. If not, I sure hope I will see more of those experiences and tips shared elsewhere.

Additional Reading

As promised, here is the collection of links that helped me in my first year and a half of agentic engineering: