↓ Skip to main content
Experiment, Fail, Learn, Repeat
  1. Posts/

Learnings from building agents

··370 words·2 mins
Automation Automation
Author
Hairizuan Noorazman
Software engineering experiments, implementation notes, and lessons learned.
Table of Contents

I’ve tried to build a bunch of AI agents at work for a variety of purpose and with that, learnt a couple of interesting properties out of it:

Should it even be an agent?
#

Agents are definitely an exciting piece of tech and various media outlets and blogs make it seem like its the silver bullet to solve almost everything. However, as with all things in tech - this as with all the supposedly proclaimed “silver bullets” - building agents is not the silver bullet that people think it is. At the end of the day, whether one should implement it as a agent depends on the problem set.

The most important factor to take note is this: Do we need an absolute deterministic result at the end of the process. If yes, then it’s best to use plain old programming languages and write a script for that. One can use AI to generate said script but with a script - we will have a deterministtic result (i’m ignore side effect that could happen when running the scripts - e.g. timing issues etc - that’ll result in flaky results but its still somewhat deterministic at the end of day)

If the problem is more probalistic in nature - e.g. debugging a issue where there could be multiple issues and solutions, having and building an agent could help with this. The agent could be tasked to dig through the various pieces of information and with the right set of instructions, it could be used to summarize the results in a useful manner for an engineer to review. It serves well as the first pass for debugging an issue.

Where will this thing run? Who will run it?
#

If the agent thing will be run by a human, maybe can consider to just run use just use the coding harness such as Open Code or Claude Code. The coding agents is able do a whole variety of activies such as calling endpoints or running scripts (assuming you’re giving it permission).

There is a benefit to make it accessible from Claude Code - we can combine multi workflows into one and this combination of instructions makes the tool interesting and powerful.

Related

Learnings from using Claude Code

··1398 words·7 mins
Automation Automation
Here are some of the learnings for using Claude Code. This will be a running document of learnings as we go along for the ride of using this tool Last update: 26 January 2026

Yaml linting and auto completion in Visual Studio Code

··871 words·5 mins
Automation Automation
When dealing with applications - in terms of configuration work or even deploying the application to production, there is high possibility that we would need to deal with plenty of yaml. Yaml is a somewhat popular markup language (as of now) to do configuration work - other types of markup language/tools that are available and also used are ini files, toml files and json files but we won’t be focusing on those for this post.

Best practices for Python scripting - Building Reliable Data Science Workflows

··3269 words·16 mins
Python Automation Python Automation
Data engineering work usually serves to be fundamentally one of the important bits when it comes to report generation in the business. The act of connecting of understanding the data that goes through the business and the need to maintain all the scripts that handle the pulling and merging all of such data makes the job way harder than one can expect. You are not expected to just be a script junkie; you are expected to be an expert at your domain, understanding the different nuances and assumption each line of script imposes on the processing of such data.

Triggering analytics via Serverless Functions Part 2

··703 words·4 mins
Python Automation Google Cloud Python Google Cloud
This is a continuation of previous blog post. To summarize the previous related blog post. Too painful to have people respond and react to report generation and compilation Too expensive to have machine lying around to pick up the slack and automate the reports; serverless solutions (pay on use) could be a useful model to use when running automated reports. Scenario presented for example purposes: 3 reports generated which are to be compiled to a single report. Previously mentioned 3 reports would be processed on the condition when the data files are dropped into the storage buckets. Event generated from it would automatically run the report Compilating reports # The next part of resolving our above mentioned situation (read previous blog post - part 1 for more details on this) is to compile the report. There are several ways to handle, each with their own advantages and drawbacks respectively. We would use the terms subreport to refer to reports for the initial set of reports that would then need to be compiled into a final report. These are just possible solutions; the combination of products that can be used to achieve the final goal of checking subreports and then compiling into the final report.
← Learnings from using Claude Code Building a dictation app with Swift →
comments powered by Disqus