DEV Community: Grant B

I have a theory about AI (just like everyone else)

Grant B — Tue, 24 Mar 2026 01:34:10 +0000

As someone who has used an absolute shit ton of AI, I'm not going to tell you that it's not impressive. It is. It is so impressive sometimes it scares me. There are times it's not impressive, and times it's sheer idiotic. All of that is true too.

AI is great at solving well defined problems. It's great at it, and I think what we don't realize, or at least what I haven't realized, is how well defined most work actually is. Not to say that work is easy or that the designs are obvious, but that usually you can build processes around most work to make it somewhat routine. As a person who makes generators and focuses on the meta, I think it becomes apparent that if you use well defined structures you can configure them into all sorts of unique and programmatically solvable, generatable designs. The outcomes can be quite impressive, so great that they boggle the mind. Common pieces become more than their parts. But my question is this: are truly unique problems always directly built on what came before? My argument for humanity is that this is not always true. That sometimes what we see is not an extrapolation but a rupture that destroys a false peak. This is my honest to goodness hope for what humanity has to offer.

At any rate, my theory is that while AI is great at solving many problems, that is because many problems are composed of many smaller problems that can be individually defined and solved by common patterns, extrapolations upon what existed before. What I think is possibly the truth is that AI does not participate in that rupture of the norm. Rather, it is deeply entrenched in it. It can get so good that it can solve problems with many layers of defined patterns, at least eventually, not saying that's where we are today. Which leads to my theory: we will not get the new technology we were promised. We will just get optimization and an abundance of the same. Which in some cases, where we do have a shortage, will be good for some but not most. I think we will have some great problems solved, composed of many common shapes. But that will be it. And that will be good enough to kill most knowledge work, or at least convince everyone that it's not worthwhile. Then forever we will have abundance of what is, but never more than that. No boom. Nothing new. Just the same shapes we know today, sometimes in spectacular configurations.

I want to be wrong. And if you say I'm exaggerating, I want you to be right. Someday maybe even today I hope to be ridiculed for my opinion because I am so obviously wrong. I'm scared. I think everyone is, or they should be at some level. My hope is that we see something in humanity, the spark of what is new, and we realize that it's worthwhile. That we don't cheapen ourselves by saying the same is all we can ever hope for just because it can be created at cost or at great speed.

Now I hit publish and here comes a potential torpedo for my career. I hope when I go to my luddite farm they can at least accept me there. Good luck everyone and happy coding.

Generators in the Age of AI (Saving 4 Person-Years)

Grant B — Thu, 26 Feb 2026 23:41:41 +0000

One of the things that we are doing at my company is we are retiring our SSRS reports. Reporting is very important to our company as it is to many companies and with 64 different SSRS reports to convert to another system, the amount of work is a daunting task.

One of the cool things we have at our company is a dynamic JSON based dashboard building system. Lots of fun, but another post to describe it and what it looks like. Safe to say the general idea is that we need to convert these SSRS reports to our modern reporting system. So essentially a variety of table widgets with varying filters to different stored procedures in various databases and Snowflake.

So there was a constraint imposed that we needed to do as much of this on the frontend as possible. I promise I would have preferred a bit more backend involvement, but it was a direction handed down from my director. So the question was how to handle this in as short an amount of time as possible.

My director originally estimated this as around 4 person-years of development.
That is where I got to build something pretty cool. As a developer I have always been about creating tools to make a developer's life easier. One of my favorite things is to use Nx generators to do this. It is especially useful if you are using a strategy pattern or really any pre-established or codified pattern.

What I did was take each SSRS report, parse it for the query parameters and the stored procedure, classify the data inside of that to various common mappings, and generate most of the table and filtering work automatically. The idea was that if I could get a developer 80 percent of the way there we could achieve some real time savings.

For the next 2 weeks I spent time analyzing various RDL files, which are essentially an XML format, and with a mixture of using AI and my own generator know-how, created a generator that would take these files and generate full blown tables. We are now closing out week 3 and are finished with all but 3 of the 64 reports.

What I am trying to say is that deterministic tools and AI can be complementary. AI is great for getting something out fast but the quality can be unreliable. One of the great things about writing generators is that you can guarantee output and codify your standards as you build them. My argument is that using AI in tandem with generation tools gives you the best of both worlds. You can hand AI tools that guarantee your codebase looks like you actually wrote it. The output is fast and it is yours.

Five weeks in, 61 of 64 reports done. I believe this more than ever.

The battle for time

Grant B — Thu, 26 Feb 2026 17:50:55 +0000

One of the hardships I'm sure many here have faced is how tricky it is to battle timezones even when you have good libs and even when you have smart people working on the problem.

When I started at my company we had diffuse time usages implemented differently in different situations. We had some good shared utilities we had made, but the testing was narrow and our under the hood moment library was something that had just lost support. It was time to switch to a new library and to be honest we ended up doing it poorly. This is a story about fixing that and what it took to be successful in doing so.

So first off we ended up picking dayjs because that is what one of our external libraries used and it was similar in terms of functionality to moment. It was well used and that was the decision. We simply had a dev convert it because moment had lost support.

The problem we encountered was a multitude of things. We hadn't properly tested every area so we were replacing blind. Moment to dayjs conversions may have had similar contracts but they weren't the same thing in practice or most importantly in output. This led to some pretty significant regression through the application.

After all was said and done we learned how disastrous this approach was. Not just to swap, but to have not had proper unit tests and how daunting a task converting to a new time library could be especially when you are given two seemingly similar inputs and getting two very distinct outputs.

The solution I decided upon was one that I think many would decide upon. For something as important as date handling you need a wrapper. But more importantly you should write it in such a way that you are not bound to the underlying library's input or output structure. In our case we used dayjs, but the rule was that we could neither return dayjs objects nor accept them as inputs and nothing tied strictly to their API. Lastly we needed unit tests for everything with good examples especially around formatting. We solidified date formats into an enumerable to ensure consistency. Took the manipulations we would need and codified them with verifiable outputs tested in Jest. Various timezone tests aligned with our biggest customers to ensure times would be correct regardless of area.

The result: we are now decoupled from a singular library that could lose support. We have the unit tests to back up our assessment that we converted correctly. And we know going forward that we will be consistent.

The lesson isn't which library you pick. It's that you should never let that decision matter.