After a while, it became clear that the industry needs this; forecasting future values for any given data will eventually occur, so instead of coding everything manually, we could have created an app that would make it possible for us, and even for others who are not proficient code writers, to get results using machine learning and AI in general. So I did that. There was already a similar ongoing project called DTReg, which was basic, only limited to Windows, and, of course, paid, and not free. Being a fresh young developer, I have made terrible mistakes, design choices, and engineering that will shoot me in the foot several times in the future. One bad decision was to use tkinter for the UI, since DTReg was already using it, so I went with the same approach. Don't get me wrong, I am not against Tkinter, but it didn't look good at all, and we weren't in 1980; it was the 2020s. Looking at it now, I could have used QT instead of Tkinter, which would have looked much better. Not stopping there, I didn't separate ui and logic from each other; it was one giant Python class where everything was tied together, mutable state everywhere, functions not returning, and changing the state itself, methods calling methods, no private functions, everything is one giant code. All of these could have been avoided if we had also been taught functional programming alongside object-oriented programming in our education, but that is a topic for another time. It started as a one-page LSTM-based time series tool and became a giant app that packed a bunch of algorithms together with no modularity, separation of concerns, or anything along those lines taken into consideration. As I said, I was fresh blood. But we used it well: for every client, I had to delete some places on one page, some on others, and maybe add a little something to serve more than 30 customers. I always had the thought of restructuring it, but I was telling myself, we won't get any more customers, of course, I was wrong, people had too many problems to solve.

After a while, I started getting work that is not just predictive modeling. Times are changing, people have learned what ML/DL can do, and they want that. I had started working with Datakod, which has a large volume of customer data. They wanted to understand customer behavior, so I studied and implemented systems such as customer segmentation, campaign recommendation, churn prediction, association rule mining, and even anomaly detection on customer data.

From One Model to Understanding Customers

The demand-forecasting approach I'd built for Sefamerve, matching new products to older ones by image similarity and borrowing their sales history, never worked as well as I wanted it to. By this point I'd learned to be more upfront with clients about what a model could and couldn't promise, instead of just shipping the cleverest idea I had.

Datakod ended up being one of the broadest engagements I've had, running from January 2022 to December 2024, and it's the one that pushed me from "build me a forecast" to "tell me who my customers are." Alongside segmentation and campaign recommendation, I built association rule mining with FP-growth and Apriori for their market-basket data, RFM scoring, and anomaly detection, packaged as BI and intelligence reports rather than another Tkinter screen.

Albert Solino, a consultancy firm, kept me busy from May 2021 to January 2023. The core deliverable was a churn and lifetime value system wired directly into their CRM, but the part I remember best is mentoring two of their mid-level engineers, who ended up rebuilding the MLStudio idea from scratch in Flask, a framework I'd never touched myself. Watching someone take the concept and remake it cleanly was a good sign that the idea itself, even if my implementation of it was a mess, had been sound the whole time.

Two more from this stretch are worth a mention. Unsped Customs Consultancy got funded through Tübitak 1511, the same government R&D grant track from the intro, off a churn and CLTV model I built for them, which is the kind of validation that matters more to me than any accuracy number. And HepsiEmlak, the real estate marketplace, had me spend most of my hours writing R&D Center registration and Tübitak proposal material rather than shipping models, with recommendation and duplicate-photo-detection work happening underneath.

Teaching Others to Fish

Somewhere in this stretch the work started changing shape again. I wasn't just being hired to build something anymore, I was being hired to teach other people how to build it.

Protel, the hospitality and restaurant-tech company, had me lead and mentor five people, from juniors to seniors plus one MSc student, on demand forecasting using ARIMA, LightGBM, XGBoost, and Random Forest — the first time I was responsible for other people's output instead of just my own. At Nano I taught ML/DL fundamentals and guided the team toward building their own MLStudio equivalent, except in C#, which proved the idea wasn't tied to my stack at all, it was tied to the workflow. Gtech, CukurovaMakine, and JForce rounded out this period: three more data scientists mentored into their own forecasting interface at Gtech, and straightforward ML/DL courses for engineering teams at the other two, one eight modules long, the other reaching more than ten engineers.

Taking a Real Job While Still Consulting

While all of this was going on, I also started taking on work that wasn't consulting at all. OxyAI brought me on as a contractor from May 2021 to January 2023 to build recommender systems for their clients. For Collectors, an online art gallery, I built a hybrid multi-modal recommender that combined a user's text preferences with CNN-extracted visual features from the artwork itself. For Dinlebi, an Audible-style audiobook app, I built collaborative filtering with matrix factorization, plus an onboarding data-collection flow specifically designed to take the edge off the cold-start problem. Both are apparently still running in production.

In April 2021 I joined Universal Software full time, a company that builds software for municipalities, ministries, and the utility companies that work closely with them, like water administrations and energy providers. This is where the work stopped being purely about a single client's forecast and started touching physical infrastructure. The two projects that stuck with me most: a route optimization system for municipal garbage trucks, built on IoT sensors mounted on the bins themselves reporting fullness and flagging fire or flood events, routed through heuristic algorithms instead of a fixed schedule; and a real-time object detector for Enerjisa, the country's largest electricity provider, that ran on the phones field workers used to photograph inventory, so blurry, duplicate, or empty shots never made it into the database in the first place. Around the same time I also built a predictive maintenance classifier for a client's CNC assembly line, LSTM forecasting pipelines for electricity and gas consumption under a project called GAM-GAD (short for Geographic Analysis Modules and Geographic Analysis Tools), and an LSTM pipeline forecasting future water demand for the Istanbul Water Administration.

Leading a Team and Chasing Grants

Universal Yazılım also runs the support software a lot of municipalities use, and two of the projects I'm most proud of came out of that side of the business. The first is a ticketing classifier that uses TF-IDF and sentiment embeddings to route incoming citizen complaints to the right department automatically, now running across every municipality the company works with and fully replacing the person whose job it used to be to read and route those tickets by hand. The second is a support-ticket system for the municipalities themselves — when something breaks or needs adding in the software we've deployed to them, or they just have a reproducible support question or an event to log, they open a ticket here. It was generating fifty to a hundred messages a day, many of them repeats of questions already answered, buried in typos and miscategorization. I shipped a first version that uses embeddings and clustering to find the underlying topics, an LLM to clean the raw text into something legible, and a sentence-similarity layer to auto-answer anything already solved before. It cut response time by roughly half, and it's still one of the most exhausting and most satisfying projects I've shipped.

I'm still on it, too. I've since been handed years more of that same ticket history, profiled it properly, and sketched out nine more directions worth building on top of version one — category prediction, time-to-resolution, SLA risk, routing, duplicate detection, clustering, process mining, response suggestion, anomaly detection. Haven't committed to which one's next.

In January 2024 I was promoted to lead Universal's AI R&D team. Since then I've been the technical lead on two Horizon Europe consortium proposals: FloodGuard, a flood prediction project Universal manages end-to-end, and Pre-act, a fire prediction project Universal only participates in. FloodGuard alone was a 3.5 million euro consortium. Neither was funded in the end, but putting them together taught me more about scoping a multinational research project than a funded one probably would have.

Around the same time, I picked up a project funded under Tübitak's 1832 program: forecasting future river discharge across Turkey. I started with the obvious approaches first, supervised regression models, then autoregressive deep learning models, and all of them performed badly. What ended up working was a custom seq2seq LSTM with attention built in, which is now running across eight regions and sixteen river basins around the country. I'm leading the project together with our hydraulics engineer, which has been its own kind of education, explaining to a domain expert why the model is doing what it's doing, and learning enough hydrology from him to know which features were worth engineering in the first place.

In the middle of all this I also went back to school. I started a master's at Çukurova University in August 2023 and finished in February 2026, with a thesis on estimating an object's length from a photo without any physical reference point in frame, using depth estimation and attention-driven vision models. It's a narrower, more academic kind of problem than anything I'd been paid to solve, which was exactly the point of doing it.

Where the Consultancy Work Stands Today

The consultancy side never stopped while all of this was happening, it just kept compounding. Four engagements are still active as I'm writing this. Inveon, an e-commerce technology company, has me building product search that works off titles and descriptions without needing exact matches, a mixture-of-experts-style image classifier across more than fifty product subcategories, and similarity and recommendation systems that can take an image, a description, or a title as input, all shipped through Tkinter, Streamlit, and FastAPI. Ikas, an e-commerce SaaS platform, is running the full three-route pattern I eventually settled on for app delivery — Tkinter for model-building, Streamlit for people who need to use a model without touching code, an API for everything that needs to live inside their own systems — all deployed and actually in use, which is a long way from the single overloaded Tkinter file I was patching by hand for Comdata six years earlier. Moka, a fintech and payments company, has me on price prediction, churn, lifetime value, and forecasting, deployed on Azure with Docker and Kubernetes, working inside an actual team with git pull requests instead of being the only name on the commit log, which still feels new after years of working alone. Robokobi, a CRM platform for SMEs, has me on financial forecasting using the same Tkinter-plus-Streamlit pattern.

Smartiks, a software company, was a similarly long-running consultancy: three years working with their R&D center, eventually leading a small team of three there. Most of that time went into writing and leading the technical side of ITEA consortium proposals, the same kind of grant-scoping work I was doing for Universal, just for a different company's portfolio. Underneath that sat a handful of smaller deliverables — a Basal Metabolic Rate model for a health client, e-commerce customer segmentation, a bird-detection model for drone safety. That engagement wrapped up in May 2026.

Underneath those is a long tail of shorter, narrower engagements. Badem is the one with the most history — regression and churn/LTV models since 2022 for a company serving more than a thousand doctor-customers. Past that, it's a dozen more SME, fintech, and energy clients running the same handful of recurring problems: forecasting, churn, fraud, feasibility. The full roster, with dates and tech stacks, is on the /work page if you want the long version.

Looking back at all of it, the throughline isn't really the algorithms, it's that I started out as one person patching a single overgrown Tkinter file by hand for every new client, and somewhere along the way that turned into leading teams, writing European grant consortium proposals, and mentoring other engineers into building their own versions of the same idea in languages I don't even write. I'd still rewrite that first app from scratch if I had the time. I'm not sure I'd change much else.

What really interests me is the kind of experience Linux gives over time. After enough years of using it, tinkering with it, breaking things and fixing them again, you start to carry a certain instinct with you. You begin to feel that most things on a computer are not fixed objects to be accepted as they are, but systems that can be questioned, inspected, and maybe bent a little.

That instinct matters more than any single tool. It changes not only what you know how to do, but what you think to try in the first place. This article is really about that, and the monitor is only the example that reminded me of it.

What Other Systems Taught Me

Like everybody in the world I was introduced to computing through Windows. Due to my interests in computers, I became proficient in it but not at a Windows system admin level. Like every old school PC user, I’ve played games, cracked applications, and used Internet Download Manager. I learned that if something isn’t working, fix the .dll issue; it’s fixable but not magical. When I discovered Linux in my first year of bachelor’s, I switched immediately. I became attached to it. The freedom, the customization, the shell, and even Vim all added up to the kind of ecosystem I wanted. Using and tinkering with Linux taught me a special way of thinking, which I’ll discuss after my OS timeline.

After spending a long time with Linux, I needed a new device around the time Apple’s M1 machines were getting attention. They were impressive, had literal infinite battery life, great hardware, and were solid. So I bought one, and for many things, it was a great device.

Still, using macOS gave me a very different relationship with the machine. By that point, Linux had already taught me enough of the Unix side of things that using a shell on macOS did not feel new or revealing. What stood out to me instead were the inconsistencies, the keyboard shortcuts that felt arbitrary, and the general feeling that the system did not want me to change too much. It was polished, but also distant. MacOS did not make me feel incapable, but it did make me feel like the machine was no longer open to negotiation. It presented the device as a finished object rather than something I could interrogate. Because of that, even after three years on a Mac, my old computer, ancient as it was, still called back to me. On macOS, I often felt that I had lost the freedom to shape the machine around the way I actually wanted to use it.

I think the same is often true of Windows as well, even if I cannot say that with complete certainty. My impression is that these systems usually do not teach the user to think in that direction. They may allow certain things, but they do not cultivate the habit of asking whether deeper control is possible.

The Actual Problem

Meanwhile, I had a small but surprisingly persistent problem: The brightness of my external monitor. Like any sensible software person, I eventually bought myself an external monitor, though it came with one annoying quirk. I use my computer both in the mornings and at night which of course gave me the need to change the brightness of my devices constantly. For the laptop it was fine, just push a key and voila it changed, but the only way to do for the external monitor was through the monitor’s physical controls.

That meant getting up, reaching for the little control dongle, pushing it in one direction, waiting for the brightness to move, then pushing again, and repeating that process until the screen was finally where I wanted it. Then I would do it all over again later in the day. Sometimes, at night, I would even reset the monitor back to a more neutral state just so I would not have to think about it as much the next morning. Even that brought a small but real amount of mental overhead.

The Dongle!!

It was not a dramatic problem, but it was exactly the kind of repetitive friction that slowly makes a setup feel worse than it should.

What Linux Taught Me

Eventually, I bought a PC, installed Arch Linux immediately, and returned to the environment I had missed. The monitor problem was still there, but Linux had already taught me something important over the years: Easy or hard, but there is always a solution, if you are willing to investigate enough you can always find that solution.

That belief did not come from a single discovery, but from years of tinkering across Linux distributions, desktop environments, and window managers. [^1]

Over time, that kind of experience teaches patience, curiosity, and a deeper instinct: that almost everything in Linux can be inspected, configured, or scripted. After a while, possibility stops feeling exceptional and starts feeling expected.

That is the real point. Linux did not just give me a tool. It gave me the mindset to ask the question in the first place.

Finding the Tool

Once I started thinking that way again, the solution was not far away. I searched a bit and found ddcutil. I did not even need to build something from scratch. The tool already did exactly what I needed: it let me control my external monitor directly through software.

That changed the whole experience immediately. Instead of standing up and working through physical controls every morning and every night, I could script brightness and RGB adjustments precisely the way I wanted. Some people might mention the backlight utility, but that is not really the same thing because it adjusts the system backlight rather than controlling an external monitor itself.

Why It Matters

Now I have a setup that responds to me instead of forcing me into awkward little rituals throughout the day. I can change brightness and color settings without touching the monitor at all. The problem itself was small, but solving it reminded me of something much bigger.

Experience does more than help you solve problems. It shapes what kinds of solutions you are even capable of imagining. On macOS, and maybe on Windows too, I lived with the monitor as though its buttons were the only option. Linux, and years of tinkering with it, had taught me otherwise.

To be fair, this problem can probably be solved on macOS or Windows as well. The difference is not pure capability, but what each system teaches you to imagine. On Linux, it feels natural to ask where the system exposes the device[^2], how to talk to it, and whether it can be scripted. After enough time in that environment, exploration becomes instinct.

That is why this matters to me. The value of Linux is not only that it gives you control. It is that, after enough time with it, it teaches you to see control as something that might exist everywhere, even in places where most people would never think to look. It shapes your life as well. After enough time with Linux, that way of thinking does not stay confined to the computer. You begin to carry it into other parts of life too: the sense that things are not always as fixed as they first appear, that constraints can be questioned, and that with enough patience and effort, more is possible than you initially assumed.

[^1]: I used Mint, Ubuntu, Debian, Fedora, PopOS, Manjaro, Arch, NixOS, and even one distribution that marketed itself as very close to macOS, though I cannot remember its name now. On the desktop and window-manager side, I went through GNOME, KDE, LXQt, Deepin, Xfce, i3, bspwm, Qtile, Awesome, something written by Haskell, Suckless Stuff and eventually Hyprland.

[^2]: As a literal file under directory /dev.

Since leaderboards can't be trusted completely when I want to choose a model to work with, the only real solution to select correctly is to test them myself extensively. But that's as you have probably done it before knows is very tedious. New models drop weekly, each with different pricing, latency, and capabilities, and keeping up feels impossible. So we tend to stick with what we know, like Opus or Codex models.

Now of course, there is the opinions of other people, and it constantly changes but you can get the general idea following others and understand which models are good for which tasks. For example, you might know that Gemini is pretty good in generating UI than other models, and in the past Opus models was very bad at generating UIs especially compared with Codex, but now it is swapped, when followed general knowledge, it seems the roles reversed, for UI Opus is better and for engineering tasks Codex is better.

What is great about going with collective ideas of humans is that they are much more trustable than leaderboards because the knowledge comes from real life, but those real life usages biased towards vibe-coding. What I mean by this is, people use and have most of their ideas come from using models in one-shot or vibe coding scenarious, where understanding of the codebase has no value at all, because they are always telling AI to do any of the job. But this is very overhyped, in a case of losing an access to big models or cleaning the context would create much much more work to do, because it should understand all the codebase from very beginning because you don't know what the codebase looks like and it grow bigger much faster than you expected.

So evaluations should come from humans yes, but it should be done in a way that it is not biased towards vibe-coding. The real strength of the models can be understood if it is really used as a pair programmer, where you have the absolute idea of what the code does and you don't want to write every bit of the code for reasons like repeating, or knowing the logic but having the ai write it will be much faster etc. This should be the form of benchmarking of these models, this way they can't be bechmaxed and would have a real impact of helping people.

To showcase what I am talking about in a practical sense, I want to talk about a problem, and laziness of mine, which is redesigning my personal website, and really start publishing some content this time. There is some steps to this:

1. Use AI (Gemini) to generate the CSS of the website.
2. Use some sort of static site generator (Soupault) to generate the HTML of the website.
   • Create the basic template of the site to make AI understand the structure of the website. Because soupault is very odd and unused site generator, AI's are not happy about it, they just know its name, and don't know how to operate it.
3. Get the raw code of the design file from AI as HTML.
4. Prompt the agentic framework using the template and the raw HTML to generate the final project.

This is actually very easy, and this idea came to me in the middle of doing things manually so I have a pretty good template for AI to work with. And I have a design too.

The example

Soupault uses a soupault.toml file to configure the site. It creates some index pages based on the template you provide in that file. It is that easy.

My problem is that, I want to implement a blog-entry, and project-card component for my indexes, as entry points to real pages, and I have the design as HTML code. And like I said before, I have a already created the template for blog entry and I just want AI to copy the exact same thing for project-card.

Here is the template for blog-entry in soupault.toml:

[index.views.writing]
  index_selector = ".writing-list"
  section = "writing/"
  include_subsections = true
  exclude_page = "writing/index.html"
  sort_by = "date"
  sort_type = "calendar"
  sort_descending = true
  index_template = """
    {% for e in entries %}
    <a href=\"{{e.url}}\">
      <article class="blog-post">
        <div class="blog-meta">
          <span>{{e.date_display}}</span>
          <div class="dot"></div>
          <span class="reading-time">{{e.reading_time}}</span>
        </div>
        <h3>{{e.title}}</h3>
        {% if e.excerpt %}<p>{{e.excerpt}}</p>{% endif %}
        <div class="read-more">Read Log
          <svg><use href="#icon-arrow-right"></use></svg>
        </div>
      </article>
    </a>
    {% endfor %}
  """

I don't want to repeat myself, but this above code ensures that the AI agent have some example that it can work with. The thing that I want to do is pretty much the same thing, but I don't want to copy and paste the code by hand, AI should be able to generate the code for me.

Also in the template code above, there some variables like {{e.title}}, and if I needs to understand it, can just look the other parts of the file and understand easily. This is the separation between copying the code to web app, pasting answer to the editor and agentic AI. It should just do it automatically.

Let's stay on the topic, so here is the example design of the project card:

And here is the code for that example project card:

<div class="project-card">
  <div class="project-header">
    <h3>Causal Inference Engine</h3>
    <a href="#">
      <svg>
        <use href="#icon-arrow-right"></use>
      </svg>
    </a>
  </div>
  <p>A distributed system designed to separate correlation from causation in massive datasets. Built to strip
    away
    noise and reveal underlying truths.</p>
  <div class="tech-tags">
    <span>Python</span><span>PyTorch</span><span>C++</span><span>CUDA</span>
  </div>
</div>

It is pretty basic stuff, what the llms have to do is to extract the code and insert it as a template.

Here there is already a toml entries for the project view, the AI only needs to write the template and nothing more.

[index.views.projects]
  index_selector = ".projects-grid"
  section = "projects/"
  include_subsections = true
  exclude_page = "projects/index.html"
  sort_by = "title"
  sort_type = "lexicographic"
  sort_descending = false

There are some catches that will make us to evaluate the llms.

• It has to figure out how will it get the tags from soupualts internal variables. (They do not know it and have to figure it out.)
  • Example of {{e.title}} in the above example.
• They should not generate unknown template codes thing of the air.

I will not give them any documentation to understand how it is done, this can be done just by looking at the example code.

The results

The prompt is pretty simple: I want you to take a look at @soupault.toml and create a project view inside it based on the design in @site/projects/index.html. You can use the template of writing view as an example of how templating language works. Don't create meaningles syntax.

All the agents are used within Opencode.

Codex 5.3

{% for e in entries %}
<div class="project-card">
  <div class="project-header">
    <h3>{{e.title}}</h3>
    <a href="{{e.url}}">
      <svg><use href="#icon-arrow-right"></use></svg>
    </a>
  </div>
  {% if e.excerpt %}<p>{{e.excerpt}}</p>{% endif %}
  {% if e.project_tags %}
  <div class="tech-tags">
    <span>{{e.project_tag}}</span>
  </div>
  {% endif %}
</div>
{% endfor %}

• It finely did what it needs to do, but went over its head to manipulate the code outside of the templates a bit, not too much but a bit.
• It took too much for this basic task in my opinion.

Gemini 3.1 Pro

Empty

Minimax M2.5

• It did create perfectly, did go overboard, but I have one more index page that I will prompt eventualy to do it, it already have done it, didn't change anything other than templates.
• It was fast enough.

{% for e in entries %}
<div class="project-card">
  <div class="project-header">
    <h3>{{e.title}}</h3>
    <a href="{{e.url}}">
      <svg><use href="#icon-arrow-right"></use></svg>
    </a>
  </div>
  {% if e.excerpt %}<p>{{e.excerpt}}</p>{% endif %}
  {% if e.project_tags %}
  <div class="tech-tags">
    <span>{{e.project_tag}}</span>
  </div>
  {% endif %}
</div>
{% endfor %}

GLM5

Empty

{% for e in entries %}
<div class="project-card">
  <div class="project-header">
    <h3>{{e.title}}</h3>
    <a href="{{e.url}}">
      <svg><use href="#icon-arrow-right"></use></svg>
    </a>
  </div>
  {% if e.excerpt %}<p>{{e.excerpt}}</p>{% endif %}
  {% if e.project_tags %}
  <div class="tech-tags">
    {% for tag in e.project_tags:split(",") %}
    <span>{{tag}}</span>
    {% endfor %}
  </div>
  {% endif %}
</div>
{% endfor %}

GLM coulnd't do it the first time, because eventhough I stated it it created a syntax from thing air project_tags:split(",") which there is a zero evidence that code will work but GLM went ahead and did it. It tried to be smart about project tags, and yes the end results should really be like that, split by commas maybe, it could work out but the syntax is wrong. There is no :split in the template that I am using and Soupalt screaming that it can't build, I make it work in the second time because I know where the error is. I just told it the split can't be used here and it fixed itself but it is really baffling to see the AI create a syntax eventhough it is said to not do it.

This shows that when working with niche projects and tools that are not React or Next.js or Javascript or even Python, the AI may not be able to create the best results immediately. At my examples AI's didn't need to know how soupault worked because the example is already solveable if you have a knowledge of coding, because there are immediate examples to follow. And there may come a time wherethe big companies will not be able to provide cheap coding plans and you might have to use open source ones, or this may not happen but in the end, a little bit of smart model, can do the things you want to do, we just need to know how smart are they and not how they can one shot a website or app or anything. Don't buy the benchmaxing and don't try to create using that way, this will be the optimal usage of AI, and our benchmarks need to be able align with real use cases like these ones.