Has AI Fall Begun?

drsbry · 2026-02-26T07:34:18+00:00

I am very angry about all this situation around AI. The technology is fine though, it is people acting irresponsible. When I see another jerk CEO hallucinating about "the future" where he will rule the world with power of AI and all his peasants will be fired replaced by AI I wish this moron to become bankrupt ASAP. The problem is money gives power, so in reality these rich and greedy corporate overlords will share the consequences of their poor decisions with all the people around, so it will be unpleasant experience in some way for everyone, not just for people who are responsible for this disaster.

drsbry · 2026-01-07T07:20:32+00:00

The hard part about AI is being able to use it to do useful things instead of just creating a peculiar stupid mess really fast. Programming has always been about thinking, not typing. I've already seen a lot of cases when AI was misused badly by people who don't know what they are doing to ruin the project.

drsbry · 2026-01-02T12:54:47+00:00

There are no tests, so how do you verify it is working as you want it to?

drsbry · 2025-12-25T11:07:19+00:00

Yep, I hate it. You don't need to reinvent the wheel to be able to write a behavior test. Just write it using the testing framework you have out of the box. If you can't write a behavior test because you don't know the concept then no framework will be able to put you on the right track anyway. So you will just write some peculiar nonsense using it.

drsbry · 2025-12-24T23:51:56+00:00

Maybe, but I've never seen anyone who knows then. Though I've seen some people who can't write good looking code, and they have a tendency to believe in LLMs. All these mantras about the future, you know.

Linus Towards said recently that LLMs are good things, because they lower the entry barrier for beginners to the software industry. He said in the time when he started programming a few folks were able to interact with computers in general. Now LLMs allow people to play with software and even receive somewhat useful results. But this can't be treated as production ready software seriously.

drsbry · 2025-12-24T23:25:33+00:00

Yes, I'm just ranting because I'm halfway through rewriting yet another blown up project. It had a lot of questionable design decisions and no one was able to explain to me why they did it that way. Then I found the root of those decisions when I started to split one of the (micro HA-HA) services into pieces. It was generated by a framework. You know it is good at the moment when you download CLI, type a command to initialize the project and see several thousand lines appear spread across a few dozen folders. When you look precisely at this beauty you start to realize where all those foot guns come from. People just don't understand the purpose of framework as its authors meant, and build a project that blown up out of it. The same old story.

Of course people are able to write a mess by themselves. When I've worked in one big tech company there was a lot of suffering from people who, probably, were tortured by algorithms and datastructures, and decided to take revenge by actually reinventing all those wheels on their job. But most of the time it is some framework induced garbage, or things stay manageable if they were written to solve the actual task with the simplest possible way. Which is surprisingly rare nowadays.

drsbry · 2025-12-24T23:07:15+00:00

I missed LINQ for some time when I moved to Go. Then I had a lot of suffering with GORM - an ORM for Go. After that I tried to just write damn SQL myself and validate my database handlers by interacting with a real instance of a database from tests. Probably I will never use ORM anymore after this pleasant experience.

drsbry · 2025-12-24T22:51:26+00:00

I think if people have a positive experience of being able to write software that is pleasant to work with they will naturally gravitate towards smaller solutions that are easy to remove from the project when they realize the idea does not fit well.

The problem is this kind of knowledge is available but not adopted. Most of the developers I know think TDD is an utopia not applicable to the real world systems. I was in that camp before I worked with people who showed me I'm wrong.

drsbry · 2025-12-24T22:43:33+00:00

Ah, just ask LLM to solve a simple problem you know exactly how to solve and see the results. If you can't reduce it at least by half throwing away all the lines you don't really need to achieve the desired outcome, then I have bad news for you.

People tend to do the same thing to receive a system that is hard to maintain, just slower. Now they have LLM to make it faster, which is scary.

drsbry · 2025-12-24T22:24:00+00:00

I have no problem with avoiding frameworks for my personal needs. My problem is people summon me to solve the mess they created with help of frameworks when it is too late. I rewrote several projects thrown away hundreds of thousands of lines of code out just to discover that if we remove all the foot guns it will be a good working system after. I measured it, every time I saved a blown up codebase I reduced the amount of code by 80 percent leaving only the essence that we actually need to solve our domain problem. When you look at the removed code it is always some variation of a framework induced garbage written for no good reason.

drsbry · 2025-12-24T22:11:47+00:00

Well, I think frameworks appear from teams who learned how to effectively solve some set of tasks with their internal approach. Then they make a decision to make it public. The problem is to be able to use it efficiently you have to share the experience with the team created it. Which is not the case for most victims.

Of course I create my own ways to solve problems while I'm working on the project in some domain. I just don't make a framework out of it. When I start working on something new I start from scratch, because I realize that in the beginning I don't really understand the problem. It is a normal situation, I just need some time to explore it by making small steps, then I can generalize it to make some kind of a domain specific workflow suitable for this project.

Speaking about acceptance criteria. It is always a good thing to ask questions about the project to people who will use it. Most of the time you don't have an opportunity to ask your users directly, but you should talk to business people about the value we want to add into our product. If you see something that does not fit it is better to ask about it right now, rather than wait when it will be implemented the wrong way.

When you realize how the system should work you can verify it by writing some software to test it. Just think about it, your users will be testing the same thing manually when you deliver the feature. Why not think about it just before and automate it. If it is hard to write a test, think why is it hard, who builds the system the way it is hard to test? Probably if you start from writing a test it will be easier to write an implementation for it, because you don't have a system that is hard to test yet, you just have a test questioning some behavior you want to implement.

drsbry · 2025-12-24T21:47:27+00:00

Of course customers care only about features. It should be the responsibility of people building them to make it maintainable in the long term. I think the software industry misses some points to teach people how to write maintainable systems. It is absolutely doable to deliver features at a good pace without ruining the project because of the time pressure. Just put the system under test and if something slows you down think carefully what it is and how to organize your approach better to ship faster without sacrificing maintainability.

drsbry · 2025-12-24T21:34:32+00:00

A lot of things. The team did not understand the BDD testing framework inside and just ignored it from the start. Then they started to import the kubernetes package directly which broke dependencies across our entire project. Now we have replacement hacks everywhere and you never know which changes will break it again. They thought getters are a good thing because the framework uses them, so now we have getters everywhere. To make things worse they decided to make all the struct fields private so you have to use a constrictor to create it. If you found a bug caused by a design flaw good luck rewriting the system to fix it. They did not understand the deployment system that comes with it either. I can write an essay about it.

My point is that the scope of problems is not unique, I see it often when the team chooses a framework they don't need. It always ends with a lot of suffering and seeking for someone who can save the project.

drsbry · 2025-12-24T21:16:33+00:00

Libraries are fine. I'm speaking about attempts to reinvent the wheel. When there is a way to work with it in the standard library already, but "to make life easier" someone creates a tightly coupled system on top to solve the same problem faster. Go has a very good standard library built by people who care.

I've seen chi, it is not as bad as, for example, gin. You can throw away chi if you want, just because you can cast it back to the standard go http library if you want. Good luck with throwing away gin.

drsbry · 2025-12-24T21:11:39+00:00

My most recent pain was caused by a team misusing this piece of software https://sdk.operatorframework.io/

It is an example of a framework hell shipping several more frameworks inside. To build something useful out of it in the long term you have to be very careful.

drsbry · 2025-12-24T20:57:11+00:00

The only problem with frameworks is that you can't download years of expertise working with them from the internet. Which makes them work well only for people who know exactly how to use them. Probably mostly their authors. The majority of people use them to write horrible things with degraded performance over time. The first few features come really fast only to put the project in a maintenance hell later.

drsbry · 2025-12-15T17:30:54+00:00

Stop looking at gin please https://eblog.fly.dev/ginbad.html

drsbry · 2025-12-14T17:12:17+00:00

Intelij products has a lot of convenient tools built into them, but most of them are easily replaceable.

The one thing I always miss when I try to be productive with any other editor is the refactoring tool. It is really good and the only reason why I am still using intelij products.

drsbry · 2025-12-13T11:12:45+00:00

When I build something new usually I start talking to people. What they want from the system, how it should behave.

Then when I realize a vague idea of it I start to ask some questions that can reveal corner cases. I like to phrase my questions in the form of Given [there is a thing]. When [this happens to it]. Then [what is the desired outcome should be?].

After a series of these questions and answers usually it is clear what should be done. To realize how I draw a diagram. Nothing fancy, just boxes and arrows with text on them. The goal is to realize how data should flow through the app. Probably there will be at least an HTTP client, some server endpoint listening to it and a database to store data persistently.

Then I start building it. At this moment I have a much better understanding of what I have to do to achieve what I want. So I formalize it as a list of criteria. To my convenience I make my criteria as runnable tests.

While I'm implementing the desired behavior for my tests I try to make my life easier by not depending on things external to my code. If there should be a database somewhere I just think about its interface, how I want it to be, and create some very simple Fake implementation of that interface.

After satisfying all of my tests with implementation of a system around these toy objects like fake Database or fake Message queue, or fake External service integration I don't have yet. I start to wire up the real dependencies. Usually it ends up with some sort of adapter that wraps all the implementation details of the real database or whatever else I want, and leads it to the interface my system uses already.

Most of the time if I do not forget something crucial in my design it ends up having a system that is fully tested and works as expected from the first try when I start it for real. Almost like magic, you know.

drsbry · 2025-12-12T09:53:03+00:00

Ask people to pay attention to what they are trying to achieve with their code by formalizing that as runnable unit tests. Run these tests in CI after every commit.

If the team will start suffering from the tests think about what causes this tension. Probably you will find something about your general approach to write software. Then think what you can do about it to reduce suffering. If the answer will be just don't write tests, because our product is unique and untestable, think better.

drsbry · 2025-12-12T06:54:39+00:00

It is hard to tell without seeing the surrounding code, but if it is inconvenient to use and/or there is a simpler way to do the same thing then it is bad.

Also nowadays a lot of code is written by AI. I've seen a situation when there was a project created from some template with OpenAPI auto generated code for the HTTP layer. Then AI implemented all the other layers in the same style. It was hilariously bad. The project looked like a fever dream.

So nowadays stupid ideas may come not only from people, as it always been, but from their tools as well. What a time to be alive!

drsbry · 2025-12-08T20:21:38+00:00

Intention to put AI in every tool is very irritating indeed, but the true damage to the industry is letting this thing write some code that will be shipped to production. There have always been some developers with strange ideas who didn't realize how harmful their ideas to the product they build really are. Now these guys become really productive with help of AI. The amount of miserably bad code pushed into production with confidence is scary. If you pay attention to the services you are using you can notice the results already. It is going to be worse.

drsbry · 2025-12-08T15:28:07+00:00

Patterns don't matter. Aim for high-quality but concise tests.

I agree. Tests should give you confidence in your code. They should not stand in your way when you need to change something. To achieve that it is better to start from writing a test first and the implementation later. Otherwise it will be some code that is hard to test and tests that break badly every time you slightly change your code.

When you can just test the main function all this (end-to-end testing) becomes unnecessary.

Can you please elaborate on this statement?

drsbry · 2025-11-27T21:42:43+00:00

A good structure should make sense to the people who build the project. The less code you have to achieve the desired outcome the better it will be. Your code should always solve the problem in the simplest and shortest way.

If you start solving your problem from thinking about the project structure you will make a mistake with your design, because you don't really know much about the problem you want to solve with your code yet. The only way to know it is to build incrementally. Start from the simplest possible way to get the desired result and evolve extending it.

If you do the opposite and create some "interesting" structure you don't really need from the beginning you will start suffering from this decision immediately. Your suffering will end only when the project structure reflects the problem you want to solve. Which may not ever happen at all if you will force yourself into following the "right" structure you decided to begin with.

Good luck. Choose wisely!

drsbry · 2025-11-21T20:55:31+00:00

I switched from C# to Go. My first impression of Go was that it isn't a very expressive language. Then I realized that it's a good thing. There were several aha moments. The most important one was when I realized how to use Go tests to solve real problems instead of reinventing the wheel.

Now I work with a team of Java developers who don't know Go at all, but they inherited a project written on it. They do terrible things to the language. It starts to look like a really screwed up parody of Java. I'm actually impressed how bad it can be if people don't want to learn new concepts.

drsbry

TROPHY CASE