DEV Community: forbit

recent thoughts about gen-ai

forbit — Mon, 24 Nov 2025 12:45:37 +0000

i feel robbed of my own progress when i rely solely on AI to code for me. there has been, over the past 4 years since i started working as a software engineer, a clear increase in my skills as a programmer. at my latest new job - i am surrounded by people more talented & experienced than me, and i feel like i rob myself of the opportunity to actually learn & grow by trying to force AI to write the code for me, rather than do it myself.

i have aspirations, too many projects, that i felt the need to go to vibe coding as a crux. i was able to alt-tab between 4 different projects, just being a code reviewer & prompter, and i felt a similar flow state to original coding. but after a 2 month break and trying to get back into it (mycelia), im left with the consequences of my own haste.

the projects aren't laid out in the way i would in my head, so im searching for things that i thought would exist where they should - but don't. the code isn't of a high quality - it's verbose and over-fitted to edge cases & bugs that the ai managed to pickup, but has holes that it would've missed. ironically - it fills up it's own context window as if it gets a prize for writing large files.

part of what i've learnt at my current job (one of the faang ones) is the benefits of writing less. functional-style programming that favours composition of base building blocks in order to structure higher-level business logic with ease is something that i'll likely spend the next 10,000 hours of my career mastering. im robbing myself of that opportunity to ask "how could i write this better" when i don't go through the motions of typing that text out myself.

the cracked engineers aren't using ai to save time coding. they're using it to save time identifying areas in the code. i almost want a "read-only" mode for the ai. getting llm's on the device through things like copilot, and then cursor & now claude-cli and codex (and opencode, which i use) - have been a great advancement. i think giving these cli-based tools write access was a mistake.

ai is at it's most powerful when summarizing - that's why i started working on chamber, i always knew this. it isn't great at creation, it's not really generative, it's transformative. no wonder the discovery that kicked off the llm cold war was the transformer. i'll probably spend some time now investing in how to get the most out of a read-only AI. i can see a couple uses, but it has some pre-reqs:

indexing a code project
understanding how the project went from spec -> implementation (git timeline)
updating with tips on how to code better after each commit (pr bot but in terminal, not on a UI somewhere in the cloud.)
agent baked with knowledge of how i want to write code
- functional
- concise
- composition over inheritance
- multi-faceted
- favour easy testability (in-memory representations of all logic)
what to work on next (ingests todo lists, project spec, and current progress)

let's see where this goes.

How to fix glossy selects in webkit (Safari)

forbit — Sun, 12 Jan 2025 08:18:41 +0000

Making sure your application works the same across all the different browser engines can be a major pain. Recently, I encountered a new battle in one of my projects devpad. This project I decided to not use any UI framework/library, and to rely on the base html elements as much as possible. The <select> element is probably one we're all familiar with, but it's got some weird behaviour in Safari.

So there I was, happily building using Arc, a chromium-based browser, when I decided (luckily) to check how things looked in Safari:

For comparison, here's the exact same elements on chromium vs safari:

Why did these select elements have this weird, 2008, original iOS look? They looked perfectly fine in my usual browser, what was going on here? After some stack overflow and chatgpt digging around, I finally landed on a solution, but it was quite the tricky road.

The top answer on stack overflow is to use something like this:

select {
    -webkit-appearance: none;
}

However, you'll soon find out this removes the little arrow icon, which indicates to your user that it is a dropdown select menu, so not the best thing to remove.

The answer underneath that offers the first little insight into the solution: use a background-image svg, however this is a bit tricky to get to work if you already want to set a background-colour on the element, which I imagine most people do.

Now, I love using lucide.dev icons, so I grabbed the svg with the 'Copy SVG' button, pasted it in, and hey look at that it works! All that you need to change is the stroke colour to whatever you need.

But that when I came across my first issue, changing the colour scheme didn't change the colour of the svg, and you can't use CSS variables in the background-image value. So I tried to put a @media clause within the select element:

select {
  /* disable the gloss effect on safari */
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
  background: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="black" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-chevron-down"><path d="m6 9 6 6 6-6"/></svg>') no-repeat;
  background-size: 18px;
  background-position: calc(100% - 3px) 50%;
  background-repeat: no-repeat;
  background-color: var(--input-background);
  padding-right: 24px;
}

@media (prefers-color-scheme: dark) {
 select {
    background-image: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-chevron-down"><path d="m6 9 6 6 6-6"/></svg>') no-repeat !important;
  }
}

I 100% thought this would work, and then I went to the page, set my theme to dark mode... the arrow was still black. Inspecting the element shows the class is being applied to the element, but there is some "Invalid property value" error, despite it being the exact same string as the one that is being shown (in the wrong colour). The only difference is the stroke="white" instead of stroke="black".

No worries, this is where ChatGPT comes in to save the day. By some stroke of genius, it managed to fix it by URL encoding the svg string. Here's the final (working) css classes:

select {
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
  background: url('data:image/svg+xml,%3Csvg%20xmlns=%22http://www.w3.org/2000/svg%22%20width=%2224%22%20height=%2224%22%20viewBox=%220%200%2024%2024%22%20fill=%22none%22%20stroke=%22black%22%20stroke-width=%222%22%20stroke-linecap=%22round%22%20stroke-linejoin=%22round%22%3E%3Cpath%20d=%22M6%209%2012%2015%2018%209%22/%3E%3C/svg%3E') no-repeat;
  background-size: 18px;
  background-position: calc(100% - 3px) 50%;
  background-repeat: no-repeat;
  background-color: var(--input-background);
  padding-right: 24px;
}

@media (prefers-color-scheme: dark) {
  select {
    background-image: url('data:image/svg+xml,%3Csvg%20xmlns=%22http://www.w3.org/2000/svg%22%20width=%2224%22%20height=%2224%22%20viewBox=%220%200%2024%2024%22%20fill=%22none%22%20stroke=%22white%22%20stroke-width=%222%22%20stroke-linecap=%22round%22%20stroke-linejoin=%22round%22%3E%3Cpath%20d=%22M6%209%2012%2015%2018%209%22/%3E%3C/svg%3E') !important;
  }
}

Hopefully, this post can help at least one other person that comes across the same issue and save them a bit of time messing around.

The final product, perfect cross-browser select elements with dark/light mode variants:

If you're interested in the project (devpad) that inspired this, check out my latest blog post

5 Things I Would Teach Myself 10 Years Ago

forbit — Tue, 18 Oct 2022 10:39:12 +0000

Lesssons

Show Off Your Work
Force Yourself To Finish
Stick to one stack
Document your progress
Install Linux

1. Show off your work - even if it's horrible

I often reflect and think back on my journey as a programmer. I started in primary school with scratch, and due to my fondness for games, found enjoyment creating games for myself and showing them to my friends. Then, I wanted to write more complex games and one of my teachers from school suggested GameMaker. This engine took me from a drag and drop coder into someone who could actually write code, I felt like a "coder".

However, my games were never any good, and I was embarrassed to show my friends some of the things I had worked on. The motivation that I had received from showing my friends and them saying "this is really cool" had been the driving force for me to keep learning, but once that pipeline had been taken away, I suddenly found myself unmotivated.

This is why this lesson would be number one for me. Especially as a younger person, it's sometimes hard to show off things you're passionate about in fear of rejection. So biting the bullet and getting feedback is one of the best things you can do, and it will also set you up for later in your life knowing how to deal with constructive criticism / rejection.

2. Force yourself to finish

Shiny Object Syndrome often gets the best of us, especially when we're just starting out coding. We learn new technologies and techniques so fast that our old code quickly becomes outdated, and often throwing away everything and starting again might be faster than finishing a project. However this is a quick trap to fall into. For me, one of the most motivating forces that got me to keep coding was imagining my portfolio page, and it being full of projects that I could be proud of and consider completed. However, after about 4 years of coding games with GameMaker, I had no finished and published games.

This feeling was extremely disheartening, and I realised that I had trouble finishing anything. I had trouble with commitment. Everytime I got to something difficult in the creation of a game; creating assets or dialogue, or a tutorial or a nice UI - I would give up and move onto my next big idea. I would try and explain the idea of a new game to my friends and I was always met with the same response - "what about that other game you were working on".

When that question was asked my stomach always sank a little bit. Because I knew that the game had defeated me - I lost the battle of discipline. It got too hard and I just quit - I was a quitter. It pained me everytime to come up with some excuse that wasn't "I'm lazy and quit".

Getting into the habit of finishing projects is exponentially good for your development as a programmer. You learn specific skills about publishing - when to consider something "done", cutting down on scope, minimum viable product etc. Also, having something that you can add to your portfolio or resume as something you're proud of is especially beneficial.

3. Stick to one stack

During my time making games I mostly stuck with GameMaker. However I was aware of the technical limitations and wanted to experiment with something that I thought would be more "powerful", like Java or C++, or Unity and Godot. However, I spent about 6 months trying to make a simple game with these 4 technologies (or tech "stacks"), and had gotten no further than I was currently at with GameMaker. GameMaker was perfectly able to do what I wanted, and I was simply wasting time with the other languages. Sure, I was learning some abstraction ideas and learning other languages never hurts, but in terms of finishing a game - getting something concrete that I could show off - I was wasting my time.

This is sometimes a lesson I have to tell myself again and again today. The current webdev landscape is full of fresh new frameworks every week it feels like, and everytime I see one I think to myself, "Wow this could do x so much better than what I'm using now". And so I'll do a bit of research into the new framework but then have to stop myself.

You get to a point where any language or framework can do what you want too with enough code and determination. This is a lesson that should be shouted into new programmers. Sure, some languages may be better at some things than others - but if you're just learning the new languages, there's no way you're going to be comfortable enough to utilise the specific features of each language that makes them better. Understanding the core fundamentals of a tech stack or language is exponentially more important than learning lots of languages.

One quote - I don't know where it came from - stuck with me. "A beginner programmer will say they know 2 languages, a novice programmer will say they know 10, and an expert will say they know 2."

4. Document your progress

This one is especially useful for when it comes to creating your portfolio and resume, but is also extremely useful for finding motivation when things get tough and you're on the edge of burnout. There are many different tools for this: Pen and Paper, A Blog, or GitHub repos even. Just something to track your projects, what you've learnt from something, and a little description on why this project has furthered your skills is enough to count any project as a "success".

Everyone has those little side projects that you might have spent one week and then got blocked by some implementation that you couldn't get - but even failures like this can be useful. You now know what you don't know, and for those keen on becoming a better programmer, this knowledge is more valuable than knowing what you do know.

To be able to look back from where you started, from your first for loop to your first public GitHub project, to your first PR, to your first public API - to be able to look at your progress is soul fulfilling. Being able to see the progress you made is reassuring that you're at the right level - and it will help fight the inevitable imposter syndrome.

5. Install Linux

Now, this may seem like a pretty opinionated lesson, and it very much is. Programming in Linux is just much nicer than the Windows workflow. Being able to do everything via a terminal is so much nicer than having to install 3 different apps just to edit a project on git. The customisation of linux distros (especially Arch 💙) allows for some more programming learning opportunities. If you spend the time to learn linux, you will eventually come across many concepts in computer hardware that are important to know for when it comes to programming later on - especially low-level programming. Linux is the #1 OS for programmers for a reason; switching earlier will be exponentially beneficial.