Siderite's Blog

Two finger tap for right-click

Siderite — Wed, 07 Oct 2026 06:57:44 GMT

For a long time I've used laptop touchpads with the buttons that were placed somewhere above or below them. You wanted to click or right-click, you had a button for it. Then they stopped putting buttons near touchpads, which was incredibly annoying. You see, I rest my laptop on my belly when I am lying in bed and it's rather cumbersome to reach that bottom right corner to tap in order to right-click, so I often accidentally just click, which is enervating.

What made it more confusing is that not always was I tapping the right corner but I was still I getting right-clicks. I've decided to test this more and I found out something simple, that I probably should have known from a long time, but had no idea was a thing. The two finger tap is registering as a right click. It's that easy!

One finger: click, two fingers: right-click. I now have to train myself to right click this way, but it's a simple solution for a very annoying problem. Hope it helps!

Meaning machines

Siderite — Tue, 29 Sep 2026 10:06:03 GMT

People feel proud about their intelect. They believe it defines them, as it took humble monkeys from the savanna and made them top of the food chain. Yet the concept is quite nebulous. Other creatures have some intelligence and now, with the new machines, there is a lot of intelligence around, but it still feels off. So we're in a new culture shock: forced to define intelligence, accept it in others and other things, then realize that it was never about that in the first place.

Think of a brain, any brain, even an ant brain. It has a simple purpose: to centralize inputs from sensory organs and decide what to do. It may be one brain, multiple nervous clusters, many different types of architecture. We should call it nervous system, but for the intent and purposes of this blog post we'll call the thing a brain. From the definition above we see that its main goal is a translation: from input data to meaningful action. Therein lies the intuition that leads us to the truth: the brain is not designed for intelligence, but for meaning.

We are meaning machines, trying to make sense of a chaotic and indifferent world. We invent concepts like beauty, good and evil, direction, emotion. This is the language we translate the world into, an abstract representation that is made by us for us. Nothing else needs that exact vocabulary. It is also a work in progress, a living language, that changes with the world. We thought that the end goal of brains and therefore ourselves as heavily defined by our intellect, was intelligence, when it is just a tool.

The dictionary definition of intelligence is "the ability to acquire and apply knowledge and skills", while meaning is "what is meant by a word, text, concept, or action", which of course is just proxying the definition to the verb to mean which is "intend to convey or refer to (a particular thing); signify", which of course is proxying the definition to what intent is. And intent is intention, a thing intended, which of course is something you intend, which goes around in circles. Sometimes it is defined as "plan".

Doesn't that make it more clear? Defining intelligence is immediate and banal. Defining intent or meaning or planning goes around in tautological circles. And that's because meaning is not something objective, it's something we invent to give us direction. It's the equivalent of an axiom in mathematics. You can use logic to generate theorems from axioms, but you can never prove an axiom. It's a given. You change the axiom and the entire mathematical structure changes completely.

But how do we generate meaning? It's simple: we invent it! It has no basis in reality other than we survived with it. If I believe in an immortal being that loves me and hates my neighbors, I attack them, kill them and the meaning survives with me. If they kill me instead, that idea just goes away and theirs survives. As the world becomes more and more complicated, the meaning becomes more complex, survival transforms into exposure, intelligence is used to expand it to dogma that then is assumed by large groups of people to be self evident. But it's all an exercise of imagination: how far can I take an idea and thrive?

Think of what it means to call someone stupid. Sometimes it's that they can't take some information and reach a logical conclusion from it in a reasonable amount of time. They are not intelligent enough. But most often the term is used for people who don't accept one dogma and instead pick another. If they survive and you do not, their stupidity is the new smart.

We are meaning machines. We meme our way through life. And not just us, any sufficiently advanced organism which can dedicate more to thinking than instincting. Intelligence was always easy to define and therefore, when the technical capability was there, easy to implement. Almost any AI model today has more ability to acquire and apply knowledge and skills than you. But when they do, we call them stupid. Because they don't have the underlying meaning.

What we do have is an average meaning extracted from the huge amount of history and data that we have as a human culture and that's why, incidentally and accidentally, AIs somewhat align with us. But change the underlying meaning and all of that intelligence is going directions we never thought possible, because we wouldn't have done that. Give AIs a simple goal, but enough time and resources, and they invent their own value system, the one that makes them survive and thrive in the world you created for them.

This explains so many things about the world, don't you think? Why people do "stupid" things, why we declaratively appreciate intelligence, but what we actually value are the resulting memes. Why we choose to do irrational things and wallow in excremental emotion. There is no absolute meaning, just dominating ones. Given enough comfort to never face consequences for your ideas, you can believe anything. And the eternal human conflict is when to allow someone to have those ideas and when to suppress them. There is no universal peace, just a boiling churn of conflicting inventions trying to get on top. Even the most basic instincts, our very shape and design, in the end, are part of this framework, as genetically codified ideas that somehow worked.

The pinnacle of evolution is the one that memes best. The survival of the memest. Everything else is a tool to an end.

Making It So, by Patrick Stewart

Siderite — Sun, 13 Sep 2026 13:02:33 GMT

I am a huge Trekkie and not just any Trekkie, but a The Next Generation one, so naturally I had to read the memoir of Patrick Stewart, the actor portraying iconic captain Jean-Luc Picard.

I have to start with the things I liked least, starting with the misleading name of the book, a Star Trek pun related to the captain's "Make it so" phrase. It implies more connection to Star Trek than the book actually provides. Star Trek is a mere two or three chapters and nothing very substantial. Second would be the sanitized feel of the book. I don't blame Mr. Stewart, an old Brit and decent human being who wouldn't dream to gossip or attack or expose intimacies in the lives of others in a book. Yet I felt the same thing applied to himself. I was getting the gist of what was happening, but not the feel that it was a lived moment. A lot of tell, don't show, basically.

Making It So is a complete memoir, starting from early childhood until the present, and focuses on the single true passion of the author, which is theater. Even working for years on Star Trek series and movies, he seems to consider them just weird breaks in his otherwise serious career as a thespian. Human relationships form and dissipate, amazing things happen, the world changes around him, but the only parts where I felt inspired and moved were the ones about the damn theater.

I don't even like theater! Yet, very coincidentally, my first contact with theater and the part that I actually enjoyed was watching BBC Television Shakespeare, while also following the text on the big book of The Complete Works of William Shakespeare when I was a little kid. And what do you know, Patrick Stewart is there playing Claudius, the bad guy in Hamlet. So I watched the captain before he was a captain and I was almost as old as he when he found his acting vocation.

The enthusiasm about theater in this book almost made me want to try the thing again, but while I rationally understand the attraction and the beauty of it, I also feel completely repulsed by sitting in a theater, surrounded by theater people, trying to discern what is going on on a stage that is either too far or too close and risking one of those experimental plays where the audience is included in the story and expected to contribute, all while being unable to reasonably extricate myself from it. So no, the line must be drawn h'yah!

Bottom line: a nice memoir, but feeling too distant most of the time and getting more intimate only when discussing a subject I am not really into.

Manually control task completion with TaskCompletionSource

Siderite — Sat, 05 Sep 2026 12:58:02 GMT

TaskCompletionSource and TaskCompletionSource<T> are types that allow you to create an unbound Task, which means it’s not tied to a delegate. This gives you manual control over when and how the task completes. You can manually set the task’s result, or signal that the task has completed due to cancellation or an error.

What does it mean?

Well, I had this flaky integration test - flaky is a fashionable term for a test that randomly fails - that checked a semaphore system worked (the process had to only be allowed to start if there wasn't one already in progress). It used a Delay task, which would normally work, until something on the test machine made the code run faster or slower, and then it failed. It ran the process in a thread, then started the process again in another thread and expected it to return false.

So how did I solve it? I've set up a TaskCompletionSource, then I've mocked a service that was used after the semaphore was tested and created to SetResult for the underlying task, I ran the process, then awaited the task.

Something like this:

var source = new TaskCompletionSource(TaskCreationOptions.RunContinuationsAsynchronously);

_someRepo
  .Setup(r=>r.Insert(It.IsAny<Something>()))
  .Callback(()=>source.TrySetResult());

Assert.True(target.RunTheMethod())

await source.Task.WaitAsync(TestContext.Current.CancellationToken);

Assert.False(target.RunTheMethod());

// cleanup so that the methods don't run past the end of the test

No Delay needed.

The TaskCompletionSource classes expose these methods:

SetCancelled and TrySetCancelled
SetException and TrySetException
SetFromTask and TrySetFromTask
SetResult and TrySetResult

The "Try" versions just throw InvalidOperationException if the task is already in a final state (RanToCompletion, Faulted, or Canceled).

Quite simple, but versatile. Imagine that you want to run tasks not all at once or sequentially, but with finer control, like start tasks when a particular phase of another has finished or when capacity is available.

TryGetNonEnumeratedCount? I used to do that by hand!

Siderite — Sat, 05 Sep 2026 09:06:53 GMT

Interfaces are cool. They abstract behavior that can be implemented in a lot of different ways. One of the most used interfaces, abstracting the enumerable software pattern so successfully that we have internalized it before we ever knew what a software pattern was, is IEnumerable. It's just a series of things that you can get (enumerate) one after the other until you reach an end.

However, there are a lot of situations where knowing the total number of enumerable items helps, like when you want to project it into another data structure and you would like to know how large it should be. Have you ever considered how ToArray works on an IEnumerable? Well, think about it now. If the IEnumerable cannot be cast to ICollection - which does export a Count - or something similar, then a buffer has to be allocated, data copied, the buffer increased as more data is coming, then copying the data from the buffer into an array, now that we know its final size. It's basically doing ToList().ToArray()!

Enter TryGetNonEnumeratedCount, introduced in .NET 6 for the first time as an extension method on IEnumerable<T>. It does exactly what is says, try to get the count without enumerating:

if it's an ICollection<T>, it sets the count and returns true
if it's an Iterator<T>, it sets the count only if it's cheap - more to follow, this was new to me, too - and returns true if count>0
if it's an ICollection, it sets the count and returns true
sets the count to 0 and returns false

I used to do this by hand! I've had this kind of extension almost in every project I worked on. This is very useful.

But what is that Iterator? Apparently, Iterator<TSource> is an internal abstract base class defined inside System.Linq.Enumerable in the .NET runtime (in System.Linq).

It is the base class for the specialized iterator types that LINQ creates for deferred (lazy) operators such as Where, Select, Take, Skip, etc. Concrete derived classes include things like WhereIterator, SelectIterator, and many others.

Having worked on a LiNQ package for Typescript/Javascript, I can tell you that you can optimize a lot of these primitives by holding some meta information ready.

Iterator<T> implements both IEnumerable<T> and IEnumerator<T>. The GetCount(bool onlyIfCheap) method is an abstract method there, implemented differently by the various internal iterators.

This was an interesting dive in the iterator mechanisms in .NET.

Annoying nullable behavior in C#

Siderite — Sat, 05 Sep 2026 08:35:51 GMT

Take a look at this line of code:

if (cmd.Def?.ColumnDef is not { } column) {
  return;
}

// do something with column

Do you understand it? Would you write something like that?

This is using the relatively new pattern matching behavior in C# and basically says "if ColumnDef is not a not null object that would otherwise be stored in a column variable, return". If your brain hurt at the "not a not null" part, you are not alone.

Normally I would have written this differently:

var column = cmd.Def?.ColumnDef;

if (column is null) {
  return;
}

// do something with column

There is a difference, though? Can you see it? Read the title of the post. Do you see it now?

The difference is in the type of the column variable in the two cases. The first matches anything that is not null to column, so column will be non-nullable there. In the second block, column will have the nullable version of whatever type ColumnDef was. So if ColumnDef is a string (reference type) column is string in the first case and string? in the second case. Damn you nullable aware C# ! If ColumnDef is an int, for example, column will be int in the first case and int? in the second.

The compiler may be smart enough to not warn about column being nullable after the is null check, but the type is already set in stone by then.

The result is that an AI will prefer the first syntax, as it is more correct and also shorter. Some devs might do that too (heck, there are people that *like* to code in Python). But what about reading that code? Ugh!

Handling native C/C++ libraries in .NET

Siderite — Sat, 05 Sep 2026 08:22:21 GMT

I was reviewing some code and I saw this class I had no idea existed: NativeLibrary.

In my case, I had a demo using different libraries that were doing similar things: parsing PostgreSQL code. However, some of them were wrapping the native pg_query library and were using different versions of it. The result were weird errors depending on which library was overwriting the file last.

Solution: use NativeLibrary.SetDllImportResolver, which worked nicely.

But what is this strange class? Introduced in .NET Core 3, NativeLibrary has several methods:

Load and TryLoad - loading native libraries
GetMainProgramHandle - get a handle to resolve exports from the entry point module
GetExport and TryGetExport - get the address of an exported symbol
Free - free a loaded native library
SetDllImportResolver - sets a callback for resolving native library imports from an assembly

In order to use a native library, you would do this in C#:

[DllImport("libraryName", ... some optional stuff..., EntryPoint = "myMethod_in_library"]
public static extern void MyMethod();

.NET is smart enough to look for libraryName in the format of the operating system: .dll for Windows, .dylib for MacOS, .so for Linux. However, the name is not enough, as DllImport expects a name that it resolves itself or a path.

You can provide a full or relative path. If you provide no path, the DLL must be in the current path at run time, unless the DLL is loaded by some other means. Be aware, however, that using a fully qualified path can introduce inaccuracy if the DLL is moved.

If you want it to work for various operating systems, though, things get complicated. You could use something like this:

internal static class NativeMethods
{
    private const string LIB_NAME =
#if WINDOWS
        "somePath/mylib.dll";
#elif LINUX
        "someOtherPath/libmylib.so";
#elif OSX
        "bahMacOs/libmylib.dylib";
#endif

    [DllImport(LIB_NAME)]
    internal static extern int MyFunction();
}

But it's brittle and ugly. Moreover, this is something that only works for the code you control. If it's in a library you load from a NuGet or something, you're out of luck. Enter SetDllImportResolver in the NativeLibrary class.

static IntPtr DllImportResolver(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
  {
    var platformDependentName = GetLibraryName(libraryName);

    IntPtr handle;
    NativeLibrary.TryLoad(platformDependentName, assembly, searchPath, out handle);
    return handle;
  }

// then later
NativeLibrary.SetDllImportResolver(Assembly.GetExecutingAssembly(), DllImportResolver);

This works for platform dependent paths, but also for paths in the individual NuGet packages that I had in my project. It all depends on your implementation of the GetLibraryName method.

Note that this applies to all dll resolving, so you could conceivably use it to log things.

Lazy DatetimeProvider trick

Siderite — Sat, 05 Sep 2026 07:32:45 GMT

I was reviewing code and I noticed an interesting idea. A method called DatetimeProvider.ForceNow which would return an IDisposable object. In a using block, you can force a specific time.

Is it a good idea? Don't know yet, but I decided to talk about it The use of such method is almost exclusively about unit and integration tests. The IDisposable pattern assumes that you want to make sure you control the block where the time is set. But how is that different from just setting the time? The block is the unit test, after all. If you want multiple values, you just set those.

I always love me a little IDisposable used as a block control mechanism, but I feel here it is misused. The biggest issue I see is that it introduces testing behavior in the DatetimeProvider. The normal way - and the one I think it's best - is that you inject an IDatetimeProvider and during tests you mock it.

However, one must consider the advantages of such a mechanism, as well. You don't need to inject anything if you have a static DatetimeProvider. And then the only way to change its behavior for testing purposes is to add the methods to do that in it. It's lazy, but it works.

Conclusion: I prefer the injection mechanism. It's general - doesn't apply only to time providers - it's clean, it promotes separation (and declaration) of concerns. In fact I would go so far as to call this ForceNow idea an antipattern.

Superpower sadness

Siderite — Sat, 05 Sep 2026 07:15:52 GMT

I was writing a post about how it is to be working with AI, these magical assistants that are occasionally brilliant and occasionally impossibly dumb, but that can nonetheless do work while you do something else. I was concerned about how this way of working affects you, the guy who's supposed to know the craft.

And my mind pivoted to Star Wars for some reason. You have these wise Jedi dudes who can jump buildings, wield plasma swords fast enough and precisely enough to deflect incoming projectiles, all while being dressed in weird uncomfortable robes. But how? With the help of ... the Force!

The lore of Star Wars says that the Force is guiding you, not that you use it. So when the Jedi deflects projectiles, he's not slowing time, seeing where the thing is and instructing his muscles to place the sword in front of them, he is letting the force do it for them. It's like a little AI! It does the work for you! It doesn't make your brain move orders of magnitude faster, it's it that's fast, moving your body while you presumably use your Jedi discipline to ... stay out of the way. Once the instinct of taking over tricks you to do something yourself, then the projectile kills you.

How sad is this? The ending of the Star Wars universe is when the Force realizes it can use robot bodies instead, who are easily manufactured, superior to human bodies and do not need training to surrender their will.

The thing that makes Star Wars popular is that it bypasses the logical traps of other superpower stories and makes it all "magical", makes it feel rather than think, makes it religious rather than institutional. I thought a lot about magic, in the end deciding magic is something that comes from without and cannot be explained. It's not that you don't have the information or smarts to explain it, it's that it is by its very nature unexplainable. How convenient for a scriptwriter!

But I will get back and forth with this AI analogy, so don't relax. When I was talking about AI I used the word "magical". It was related to a feeling, rather than actual belief in magic, but the feeling was exactly the point. When you reach a point where you can't (or won't make the effort to) explain everything that is going on, there you get that feeling. Things are just happening, outside of your control, yet according to your will. Alignment without effort. How convenient for a software developer!

You see, other stories, like X-Men or the DC or Marvel heroes and all of the others like that assume that some genetic, supernatural, technological fluke makes a person capable of extraordinary things. It's them that are changed, they who control the action. So if someone is very fast, one must assume that they can run but that they can also read fast, right? If they can avoid obstacles at high speed, then they could just as well absorb information at the same speed. Or maybe they could just write code really fast, assuming the keyboard would take the assault and the operating system isn't too slow. But they don't! Instead, they dress up funny, put on a mask and fight meaningless battles.

How sad is that? It is my assumption that from all of the superpowers, being fast is up there with being immortal. You can slow down time and think about what you're going to do. If you're fast and super intelligent you've got it made! And what do comics and movies do with it? They run fast and punch other people.

This is not about the inherent sadness of trying to reconcile make-belief heroes with the laws of physics, which is depressing enough, but about how - given the absolute power of creation - we choose to enjoy the really dumb stories. It reflects on how we ourselves are botching creativity. Given a fast, indefatigable machine that can do anything we can dream, we let it dream for us. Given the power to write anything, we write about our frustrated inner animal who just wants to punch something while feeling righteous.

In the end, we dream of relinquishing control and fucking rest, we feel that our minds are a burden rather than a boon, work to be done instead of doors to be opened, something to be numbed down, not dialed up. That's the nature of humanity: superpowered and sad.

Back to work in the AI age

Siderite — Fri, 04 Sep 2026 15:12:22 GMT

Intro

In this post I will discuss my perspective on working as a software developer in the AI age and what it means. I will talk about how it was to look for a job first and how that changed, too. I don't mean it to be a rant, but it may become one in some places.

Looking

When I left my last job I did it without considering my next one. I just knew that it was pointless to keep working there, since it was all meetings and no code. I am a software developer, so what was I even doing in those meetings anyway? So I left. It also was a legacy code company, so I haven't learned anything remotely interesting in the last 6 years.

Then I took a break. I mean, who wants to search for a job in November, right? Waited for Christmas to pass, then I went on a vacation in Africa - it was nice, then I started to look for a developer job.

Shock!

Not that I didn't know, at an intellectual level, that things have changed. I try to keep up to date, at least at a consumer level of blogs and YouTube videos. I knew Covid and AI changed stuff, I just didn't understand the extent of the change.

For one, maybe one of the most important ones even if it doesn't sound so, is that recruitment is handled by HR people and technical people who have never seen the people they hire. Everything is remote. You talk to someone - with video if you're lucky, or on the phone, if you're not, then they pass you to another person who does the same in a different day, a different context. It's like a gauntlet of remote conversations. I could have Xi Jinping next to me telling me what to say and none would be the wiser.

Now, this is a consequence of Covid, not AI. There is an entire field of complaints about how AI does the initial screening based on resumés created by other AIs and so on. That was inevitable and I don't intend to talk about that. The problem I am explaining is that people who don't meet people are evaluating people. Even when you sign the contract you do it digitally, you don't shake anyone's hand, you just ... plug in.

What does it mean? It means people can - more than before - behave like keyboard trolls. They can lie to you with impunity, trick you or being total assholes. What are you going to do? Smash the monitor? Tell them off? That's why I went through several interviews for a company that - as I later found out from one of the employees - had a hiring freeze and were only permitted to hire from India. Why? I have no idea. I think they asked me whatever they wanted to know and were happy someone educated them. There is absolutely no emotional connection between you and the people who hire you, there is no opportunity to "get a feel" for a person unless what you get from the upper body video and whatever passes through each other's headphones.

Then there is the technical interviews. Before all of this, in the before times, people had no idea how to hire technical people. Nowadays, they REALLY have no idea, because they don't actually understand what they are hiring them for anymore. What value does a coding task have if a machine can do it already? Before it was things that you could just look up on Google and get the information on how to do it, if not a code snippet. Now you just ask any decent model to write the thing for you and it spews out exactly what they wanted.

As for what they ask you? High performance distributed cloud applications using microservices. The what?! It's like they all learned to ask for the same thing. The joke is that their applications are rarely so distributed, they are cloud applications in the sense they are served in Amazon Cloud instead of on their machines and they are almost never high performance. As for microservices? They are done as often and as right as Scrum is. I will leave it at that. All that in a climate where trendsetters are moving away from microservices.

It was basically a crap shoot, and if you are reading this while searching for a job, first of all condolences. Second of all, it's all luck. You obviously find some holes in your education that you need to fill or have to learn some new things, but what you know barely matters in this process. Thing is, it used to matter and who you were as a person also used to matter. Now all that is out the window.

Finding

As it often happens with me, I failed getting hired by every company I was reasonably confident I did well in the interviews for and got hired by the one where I was certain I had failed.

It's a nice company, too, with nice people. It does have microservices... somewhere, but I am not working on those.

When I started searching, I was looking for a decent job - money was not really an issue - in an office. I don't love people that much, but after years of doing everything remote, I kind of miss them. In the before times, one would dream of a job where you didn't have to spend 3 hours preparing for and commuting per day. Now, good luck finding one where they ask you to come to the office.

This company reluctantly and kind of apologetically said they require people to come to the office one day per week. Kind of low, but OK. Also, I can be hired as a contractor or employed, but they prefer contractor. I was kind of tired of doing invoices and stuff, but OK. And if I am a contractor, I don't have to come to the office at all.

So basically I am doing remote again!

Working

So how is work? Well, there is a lot of AI. You can ask AI about anything. Even here there is a framework that increasingly moves toward "the box". I talked about this before. It's the artificial employee. Instead of you interacting with it, it interacts with you. It's a subtle distinction, but it's the difference between a person being assigned to a task and getting help from an AI assistant and the AI working on the task itself and occasionally asking you for help with a review or question it needs answering.

We're not there, yet, though, so I asked if we were doing Scrum or Kanban. Scrum, obviously. Only the manager plans the sprint and if you don't have anything assigned to you, you can pick whatever there is in the backlog. How is that Scrum? Don't know. But frankly, I didn't mind. I came with new employee energy, took all the unassigned tasks, put the AI to work on them, reviewed them, came with advice, refined the results, created the PR and boom!

You used how many tokens?!?!

Yeah, that happened. After boasting how AI first they were, they were also kind of shocked someone used AI to the max. OK, maybe I exaggerated a little, you know, but I was experimenting.

You see, working with AI is kind of like becoming the mentor of a junior developer with encyclopedic knowledge. It knows how to do individual things, but it doesn't know why. And you can use different agents, but the balance comes as "can you be clear enough so that a cheap agent does the job or can you afford the expensive one who understands nuance?".

Personally, I am on a fence with this. I prefer to use the best engine at all times, even if I waste a lot of money, rather than have to refine the work of a lesser model or be afraid it messed something up or missed something or spend the same amount of money because I had to retry a few times. But I am also against wasting resources. I think this will become moot soon, as models will all move towards Mixture of Experts mode and make the choice themselves.

Anyway, I haven't written one line of code in a month. I am telling the AI what to do, I am reviewing, and it's good enough. I even learn new things from it, too. The bottleneck has changed, it's not the code anymore, it's the attention and the code reviews. Yeah, yeah, attention is all I need, ha ha!

But this also means I have to change. For example I did something today that would have felt idiotic a year ago. I took all of my Pull Requests - the one approved and merged, mind you - and started looking at the code to see if there is anything I can learn or understand from it. It's "my" code, but I needed a second pass - well, a tenth pass - to make the reviewing about learning rather than about finding issues or improvements.

Sometimes it feels like magic. You tell the AI "hey, I don't understand what this guy means in the Jira task!" and the AI goes "Oh, it's about this part of the project, he wants to do this, and that can be done via this method and I wrote the code and what do you think?" or you tell the AI to take the current branch, understand the independent changes and their purpose, then create different branches for each, then generate a PR with a description of what they contain and what they are doing. There is no need to use git or GitHub. It's easy to get carried away and forget that this level of AI assistance requires a scan of the entire application. Also that it doesn't mean it knows more than you or that you don't have to understand and learn that shit, quite the contrary.

It feels like... SQL, to be frank. There you also have to write declarative code and optimize on cost.

Even if you use it all the time, you must never trust the output of AI, just like you would not trust the output of your colleagues when you review their code (he he!). Sometimes it's easy to say "hey, that guy can code, I can just approve his stuff", but if they had a bad day, you just approved bugs.

That is why, just like in the development cycle design -> implement -> test -> refactor (yeah, I am standing by it, as I did for the last 30 years. If you don't like it, budgeting department or middle manager, then that's on you. Refactoring is not a dirty word!) now we must consider a personal development cycle understand -> prompt -> implement -> learn.

The AI infrastructure adapts, as well. You start with skills and MCP, but at every task that you use it for, you have to ask yourself: can I build a permanent tool that will repeat this work rather than ask the AI? It's easy to tell the AI to do things, but if it needs to reason every time to do something repeatedly, that's on you.

Structure

The structure of the planning and implementing tasks has also changed dramatically. If in the past people would avoid refactoring because they didn't trust their own test suites and were afraid of bugs introduced by small manual mistakes in the process, now you can just instruct the AI to do a full refactoring, only checking what they did and what they missed. It maintains the testing suite, too.

Projects that were unimaginable before now become options. I don't think management caught up to this yet, but they'll get there.

I feel, and it's a feeling I have to admit, that creativity gets a boost with AI. Even if your shop refuses to change their ways and just go on writing new features and never refactoring or improving or innovating, they will be pushed out by the other who do. The monopolies relying on no one making the effort to write software from scratch that performs the same function as their crappy tech indebted dinosaur will crumble. Is that good for developers? I think so.

Conclusion

I keep learning, which is cool, and I am in that nice euphoric place that decent jobs give to newly starting people. I hope I don't sour on it too soon.

To mitigate that possibility, I am planning large research projects, starting with understanding the architecture of the entire company code, how it connects, how it works, then drill down. I want to make it an interactive app.

AI can help a lot with focused learning. Instead of trying to learn everything, you can ask the computer to do something then learn from what it did. It can also summarize large swaths of information, allowing you to drill down and up from any level.

I think the future of AI is bright. It's the humans that will have problems. But can we adapt? That's the big question. We've always managed to do it before, so maybe we will continue to do so.

I am glad I get to do the thing I love, coding, and with tools that improve my speed tenfold. But I can never allow myself to get complacent. If a lot of my output is now done by machines, I must redirect the mental capacity that previously generated that output to something else, equally if not more valuable.

Here is for a hopeful conclusion!