DEV Community: Owen Far

Introducing DebugBundle, and why I'm building it

Owen Far — Fri, 18 Sep 2026 12:27:53 +0000

Hi, it's been a while since I wrote an article. It feels great to be looking at this blank canvas and typing in the middle of the night. Brings back a lot of nice memories :)

For the first time, I'm building a developer tool, and I'm really curious to hear your thoughts on this one.

So, let's jump right in.

There are already plenty of tools for tracking errors and understanding what happens in production. So why build another one?

For me, it comes down to how I think development is changing.

Coding agents are taking on more of the work, and I expect that to continue. But being able to read an entire repository and write a patch is only part of the job.

When something goes wrong in production, the agent also needs a useful way to find out what actually happened around that failure.

Which request failed? What was logged before it? Which release was running? Was something deployed a few minutes earlier?

The challenge, at least to me, isn't giving an agent access to as much data as possible. It's giving it the right evidence in a form that is simple, structured, and reliable.

That is the part I want to work on with DebugBundle.

The code is only part of the picture

An agent might understand a function perfectly and still have no idea why it failed in production.

A stack trace gives you one piece of the story, but the useful context is often spread across different places: request data, logs, release information, environment details, and whatever else happened around the error.

Someone usually has to connect those pieces before the investigation can really begin.

I don't think the answer is simply to give an agent access to everything.

More data can mean more noise, more sensitive information to handle, and more opportunities to interpret something incorrectly. I would rather give the agent a bounded set of useful evidence, while making it clear what is available and what is still missing.

The idea behind DebugBundle is to capture a production error and bring the relevant context together into a structured debug bundle.

A developer can inspect it, and a coding agent can retrieve the same bundle through tools such as a CLI or MCP, alongside the code it is already working on.

The bundle doesn't tell the agent that its proposed fix is correct. It gives it a much better starting point, and gives the person reviewing the fix something concrete to check.

Assuming you're still doing that :)

Why build in a crowded space?

I don't think existing tools are suddenly irrelevant, or that nobody else is thinking about agents. There is already a lot of good work happening here.

What interests me is building around the agent workflow from the beginning.

An agent needs to detect a problem, inspect the available evidence, understand what is missing, and work toward a fix that can actually be tested.

To me, that is slightly different from taking an existing observability product and adding an AI interface on top of it.

I want the main artifact to be something deliberately small enough to reason about: a bundle of production evidence that both an agent and a human can inspect and understand.

Then, if more context is needed, the agent can deliberately go and retrieve it.

That is the direction I'm taking with DebugBundle.

Production debugging for coding agents, without hiding everything behind a complicated dashboard or requiring a large setup before it becomes useful.

The goal is a flow that can increasingly be handled by AI: from initial integration, to detecting an incident, retrieving its context, investigating it, and helping work toward a tested fix.

Not a promise that every incident can be reproduced.

Not a promise that every proposed fix is correct.

And definitely not a promise that every fix should be deployed automatically.

Where I think this could go

I expect agents to take on more of the development loop, including more of the work that happens after code reaches production.

That makes the boundary between evidence and action increasingly important.

Retrieving a failed request is one thing.

Replaying it against a live system is another.

Suggesting a fix is different from deploying it.

I want those distinctions to remain clear even as the tools become more capable.

There are also some interesting questions around what should actually belong inside a debug bundle.

Request and release context are already part of the idea, but how much further should that go?

Would rollout history help explain when a problem started?

Should feature flag changes be part of it?

Should related requests be included directly, or should the agent retrieve them separately when it has a reason to look?

I don't want a useful bundle to slowly become a copy of the entire production environment.

The interesting problem, to me, is choosing what evidence is useful by default, making the gaps visible, and keeping access to additional context deliberate.

That is the future I'm interested in building toward: agents doing more of the work, with tools that help them investigate production issues quickly while still giving us a clear way to understand and review what they found.

I'd really like feedback from people building with coding agents or maintaining applications in production.

What do you still have to gather manually before an agent can actually help with a production issue?

And where would you take this idea: deeper rollout context, related requests, feature flags, something else entirely?

P.S. These thoughts are my own. Proofread by AI.

How do we setup a proper development workflow?

Owen Far — Thu, 31 Jan 2019 14:09:35 +0000

When I built my first website, I remember I had only a few files and a couple of folders in my development project. These were mostly single-page websites, everything was neat and quickly accessible. Later on, I started building websites with their own content management system (CMS), containing hundreds of files, from markup to scripts, libraries and stylesheets, to different sorts of media files, back-end services, and more. How do we organize and properly maintain larger projects?

At first, I had no clue how to structure an architecture that can adapt fluently to changes and future updates. I didn’t yet understand how everything works, so I automatically thought that setting up a performant website was very complicated. In fact, the more I searched on the Internet, the more I was discouraged to move forward. I kept hearing about new frameworks and about new techniques, and tons of other methods that different web developers persisted that I should use as well. Instead of confirming what I thought is clean, simple, and right, I was confronted with many buzz words that I didn’t yet understand or heard of. From my research, by reading quality books and well-curated articles, I noticed that I didn’t know if what I choose would be the right decision, and I kept insisting with myself that I wasn’t ready yet — or so I thought. I was wrong.

The problem is that right or wrong doesn’t exist in web development, it is not defined in some Internet “mastery” book. The core architecture and the development structure of every website can differ completely from one another, but the basic construction of a website is very simple and straightforward. Different web browsers and web servers work in their own unique ways, and your challenge will always be to keep testing your products against new updates that might affect your website on these platforms. Browser vendors, network protocols, and web servers — as long as your website plays nicely around these three technologies, you can literally do whatever you want. At the same time, this doesn’t mean that certain standards and methodologies do not exist. As years passed by, web developers have come up with a few methods and techniques that paved their way as the industry standard. This is because they make technical sense, and following these defined and robust methods can help you build a proper structure and an architecture that you can easily maintain and adapt.

In this chapter, we’ll be looking at various ways web developers apply strategic methods to continue improving their web development workflow, and to easily keep their websites updatable and future maintainable. Setting up the right workflow is also very crucial to reach the best productive outcome, and whether we talk about the front-end presentation or the back-end services, everything starts from the local environment you set up on your personal computer. That’s what we’ll start talking about first.

Creating a robust local environment

When you design and develop your website, you should always try to apply the same behavior on your local development environment to match that of the live web server you will use. This will range, for example, from the type of web server you choose (e.g. the Apache HTTP version) to the back-end language version that you have installed on both your remote server and your local computer. By using this method, you can heavily reduce the chance that something will go wrong once you publish your website live. It’s usually also crucial that if the project is a long-term project, you keep notice that if some updates are done on the server, you apply the same updates on your local environment before you start any work. This lets you revisit the project several years later, apply certain updates or patches, and deploy to the live server resting assured that you don’t break the live production.

Some web developers recommend that you install a virtual machine (VM) for every individual project on your computer, so that it behaves the same as your live server. While this is a powerful and versatile solution, the downside is that it will drain the resources of your host machine — your computer. My own preferred way of dealing with this was to always have a staging (testing ground) version of the website on the live server.

This means that if a project I worked on was running live on the URL ‘example.com’, I created a sub-domain with ‘test.example.com’, and I deployed the updates on the staging area first to make sure that nothing breaks. This can be in any other directory, as long as it runs on the same server environment. Personally, this gave me the right confidence to deploy any changes or updates on the live server, as from my experience, your local environment will never behave the exact same way, even if you think so.

If you keep this in mind from the very start, you’ll be able to apply the right strategies, since the way you structure your website on your local environment will be the same way you’ll have to maintain the structure of your production version running on your server. The simpler the structure of your local environment is, the easier it will be to maintain both. For now, keep in mind that you will always have two environments of the same development, one living on your local computer, and the other on the web server.

This article is a section taken from Chapter 4 of the eBook ‘Mastering Web Development’. If you would like to read more, you can also download the free Sample Chapter from the website here.

Thank you for reading!

I would really love to hear your comments and thoughts — critics are always welcome around here too. Which are some of the best strategies you use to maintain a proper development workflow?

Until next time,
Owen Far

What annoys you the most about the Web?

Owen Far — Sat, 22 Dec 2018 10:03:19 +0000

I would love to hear your thoughts about things that annoy you the most around the Web platform.

Personally, these are some of the few things that keep getting on my nerves:

1) Frameworks

The fact that most jobs look for experience and "strong" skills in React or Angular. It annoys me that companies don't seem to understand that some developers simply use the vanilla approach.

2) Quality

There can be a big misconception between the quality of one website from the other. It annoys me that there is no easy way to know the quality, security, and user-privacy policies of the websites I'm using. For me, HTTPS just won't cut it.

3) Titles

It seems to me that everyone is becoming a CEO or a founder lately. There's no way of distinguishing the legitimacy of people and their work.

Please share with us, which are some of the main pain points you face when working on web development?

All the best,
Owen

Dream team != (is not equal to) success

Owen Far — Fri, 07 Dec 2018 18:24:21 +0000

I keep seeing companies bringing unnecessary complexities in web development for the simple reason of following the standard “corporate” hierarchy team-structure. I have recently experienced in person how a company can be brought up to keep such focus on the old fashioned standards, while leaving the coding environment to be poorly built. It made me wonder how much value they brought into building a dream team in a company, while completely ignoring the importance of advancing developments in areas such as the Internet and its ongoing technologies.

All the ambitions I ever had towards building “our” visionary product drifted away, as I was deciding to depart the company “ship” again. I saw what I’m inevitably always prone to see in many web companies. A company driven foremost by their financial successes, goals, deadlines, and building a cult of the complex. They implement so many strategies and unnecessary complexities that it takes them years or more to have the first stable version of their web-app running online. Throughout this time, they also get lost in minor details which make them blind from the real complexities that come after shipping and maintaining an online version of their product — be it successful. As long as there is a means for cash-flow, anyone has the opportunity to create anything they dream of. Unfortunately some of us aren’t as privileged as others.

Web development — if done by those who really understand it — should allow teams to build and update features simultaneously and effortlessly. Forget about how others are doing it. Discuss what we — as a team — can do to make things better. There will never be a single definition of a particular standard, as things will always keep changing.

We need to continuously find ways that fit the product’s best needs, and keep adapting to these changes. We have to start building less complicated cults and focus on what matters the most.

Look beyond the impossible and make a difference

Developers don’t always need a design to start implementing the basic architecture of a website. If we’re to be invited in more meetings about the stories and ideas behind the proposed future implementations, we (developers) can understand better how the development will evolve, and how it should change or adapt future changes. This is always helpful to us developers that care about maintaining a performant website online. It should never only be about the ship, ship, ship! It’s more about reliability, security, accessibility, and privacy.

Never get locked to one single web culture or “micro” ecosystem.
I just left a company were the primary focus was still based on back-end implementations first. After a year and a half, I couldn’t handle this front-end non-sense anymore. I was to be a lead front-end developer (and potentially a company “partner”), working with just two more front-end fellows, but more than twenty Java developers. Yes, you read that right. It was ridiculous to see the amount of wasted time it took for us to finish a feature. In its simplest explanation possible, here is how a feature workflow carried on:

Design
Markup & JS — My role
Copy, edit, paste markup into a back-end framework of choice
Help developers understand certain functionalities — My role
Compile and generate Web resources and files
Perform and run tests
Evaluate bugs — My role
Fix and re-touch markup — My role
Update design if necessary and hit repeat

I could never understand such a workflow. Perform and run tests aren’t tests after publishing a beta-version online. These are bugs that come out when the front-end structure is generated by the back-end framework. The steps from line three onward can be eliminated if you build a proper front-end architecture. The back-end should be mostly used to handle services through AJAX requests (depending what you build). It’s highly inadvisable that the front-end is maintained by the back-end.

I kept trying my best to move things forward to — at least — a leaner and more modern front-end workflow (no, don’t even mention React). Later on they brought a professional SCRUM master and the first thing he mentioned was that we have to get rid of this legacy environment (JSF anyone?). Their approach, while ignoring my advice towards no adaptations of complex frameworks, went towards the future implementation of AngularJS. Don’t get me wrong, I’m not comparing the above mentioned frameworks together. I would rather say to strive for no frameworks altogether. Check out last years’ statistics about the use of front-end frameworks.

After this, it’s been a month of a personal roller-coaster. For who knows how many times I did this by now, I decided to move on and stick more towards building my own visions and continue teaching online.

Let’s embrace the “vanilla” side of life

I studied computer engineering prior to enrolling to a more software based course, and this might be the reason why I quickly understood the JavaScript language during that time. I always chose to embrace the vanilla languages themselves, while taking a step backwards from the use of frameworks, platforms, and other form of huge libraries. I always believed that the complexity of learning these “code-stacks” rises by a factor of 10x or more. Since eight years ago, I knew that JavaScript at its core is the language I should strive to become the most familiar with, and I only keep proving myself right. A lot of these arguments come from the same ideas and research which will also be found in the book I’m currently finalizing.

Web development at the core is a pretty straightforward architecture — yes, standards. It is more the ecosystems and the complex cultures that had developed by time, which are making everything seem so complex and impossible to achieve. You have to understand that these frameworks and services are there to ease your development — and only that. It is not a requirement, nor is it possible to keep up with all the new Web packages released today. This is why I think we should embrace a little bit more the main web-languages that made the Web how it is today.

I would tell you right now to forget about the hundreds of available frameworks online and learn the standards instead. If you get stuck on something, use a friendly search engine to find your answers. Maybe find a smaller library that provides you only the functionality you require, instead of requesting a bigger library (e.g. jQuery), or a bigger framework (e.g. Bootstrap) simply to use a couple of functions.

Try to embrace the vanilla language first, and be careful what kind of packages you use and find online. Don’t always trust everyone straightaway. Try to be more cautious but also curious about building things with your own hands. If you want to invest time for growth, than dismiss or ignore the continuous use of frameworks and libraries. The Web is simpler than you might think, and by learning the standards you invest in yourself.

You should know that all the front-end libraries, platforms, and frameworks built today run behind the same technologies that make anything possible on the Internet. These technologies sum up our three front-end family languages: HTML, CSS, and JS. As simple as counting one, two, and three. Right? Jokes aside, things are becoming much simpler now more than ever. When you put the effort and try to understand how these languages work together, and everything behaves nicely on all the browsers, you will realize that it isn’t so hard after all — you only need to look for time and patience.

Closing thoughts

There are two main kinds of developers: You either come from the world of programming languages or not. Both of them may also lead towards different development pathways, but the easiest way to get started is to learn and understand the standards — do not create unnecessary complexities.

Sometimes we all prefer to choose the “fastest” or the “easiest” way of development, maybe because we lack time or money, but this doesn’t always result the way we expect it to be either. Sometimes it can get worse. I hear a lot of frustrations and other misfortunes arising simply because of the poor judgment and lack of proper organization behind the web development technologies chosen.

If you follow the standards and try to understand how everything works, you don’t have much to worry about. The term “from scratch” shouldn’t scare you either. If you’re patient enough, you will find anything you need online. Even if you don’t find the solution, you can always ask for help and get answers.

There’s a lot more we can discuss about the subject from today’s article. Let me know in the comments what you think, and if there’s anything you want me to discuss on coming articles.

Thank you for reading!

Until next time,
Owen Far

P.S. This article was originally published on Medium, but since I've discovered DEV.to, I'm looking forward to publish original content here depending on the feedback I get. I encourage you to leave yours below 🙂

How do I remove twitter from my DEV.to account?

Owen Far — Fri, 30 Nov 2018 19:15:08 +0000

I can't seem to find how to remove my twitter account. Anyone?