Categories
Tech

Experiments in building code with AI

Generative AI, agents, and tools designed to turbo-charge your software development productivity are everywhere.

A lot of it might be empty buzz and only time will tell what kind of a disruption this will all turn out to be. But, as you’ll see in this article, in the past year or so, the tools have matured and are starting to make a real difference, and we as Software Developers need to start paying attention.

So, wanting to stay up to date on the developments, in the past months, I’ve been pushing myself to test the AI tools in real world scenarios, with a critical yet open mind1.

Note: Despite my AI experiments, I never use AI for writing. All my typos and imperfect sentences are mine. But I like it that way: to me writing is a way to think.

What is it like to build an app with AI?

The newest side project I’m building with AI is a tool few hours in the making — and I’m already using it.

Let’s start with some back story.

I’ve been using Obsidian to organize my notes for many years, but every now and then, I feel that it’s not matching my usage patterns 100%. So, couple days ago, I started again looking into alternatives.

As I was browsing the web, nothing looked just right… and my developer itch of building something of my own started raising its head. As I’ve gained experience, I’ve taught myself to fight back, knowing that nothing is as quick to build as I first think…

But now, with AI there to help me, maybe time won’t be a blocker anymore?

So, I opened a new Cursor project, and in it, created a simple README.md file describing how the app should work. In another folder, I created a sample markdown note to show an example of how my notes will be like.

Then I wrote the first prompt2:

Cursor got to work, installing npm packages, creating folder structures, and implementing core functionality. When it needed to access to command line, it checked with me if the command is OK to run, but otherwise, I didn’t need to get involved.

And two minutes later, I had an app ready to be run.

It was still quite rough around the edges (I didn’t think to take a screen shot, unfortunately, so you’ll need to take my word for it), but already had the basic functionality you’d expect in a note taking app.

I shared my opinion to the agent: “Very nice, now let’s polish things up a bit. Please update the notes app to use Material UI”

And it went right back to work:

…and so on.

When I saw errors trying to run the app, I copy-pasted them to the chat and Cursor was always enthusiastic in fixing them:

“I see the issue! The error is occurring because Material UI’s theme object contains functions that can’t be passed directly to client components. This is a common issue when using Material UI with Next.js 15’s strict server/client component boundaries.Let me fix this by creating a proper client-side theme provider: […]”

Getting to the first, functional, Material UI based version of the app took about 10 minutes (as I didn’t really check any of its code output, or even read through it’s replies — most of the time).

And then I started tweaking it by asking for different features:

  • “Let’s modify the note listing on the left side of the app to only contain the titles of the notes in a folder hierarchy displayed as a foldable tree.”
  • “Add a button for creating a new folder”
  • “Something’s wrong with the nested notes: when I click on them, nothing happens”
  • “Now, add support for dragging notes between folders”
  • …and so on.

When something wasn’t working, I typed: “it’s not working.”

And usually, that was enough to get Cursor to find a solution and fix issues.

Only on few occasions, when the AI agent wasn’t finding a solution on its own, I took some time to think about the issue myself and suggest a solution. For example, when it got stuck trying to make nested folder paths working with a regular path separator (“/”), I suggested using “|” instead. It did, and it worked.

Soon, I started moving my notes into the app, and the development became driven by the needs of my real world notes.

When I added a to do list and realized that I want to have check boxes just like in Obsidian, I prompted that feature.

When I wanted my daily notes to be sorted with the latest note first, I asked AI to change the code.

And this is where I am now, roughly four hours later:

Screen shot of the note taking app after few hours of development and use.

Everything is functional, changes are saved reliably, and it all looks alright. Most of my notes are there, and while it’s not perfect yet, it already does the job.

And it’s getting better the more I’m using it.

How good is the outcome?

So, as a user who got a custom app in just a few hours, I am mind blown.

But how good is it from a software engineering standpoint? Let’s take a look at the code.

First, I can see that it’s a Single Page App, with a clean (standard) Next.js folder structure. The functionality of creating and modifying notes is handled through server-side API definitions, which in turn call domain logic functions in a lib directory.

The UI is split into components in a logical way that makes sense to me. There’s some unused code from different attempts left behind, but those are easy to spot and delete.

External dependencies used seem smart and safe. And once I told it to set up a testing suite, in the following prompts it always wrote unit tests, and ran them to verify that things are working correctly. If tests fail, the recent version of Cursor doesn’t stop there but actually makes a fix and tries again until tests pass!

And finally, the README.md it wrote is clean and informational both for the user and the developer of the tool.

If this was code from a developer in my team, I can see myself approving the pull request without many requests for changes — except for maybe some uses of deprecated functions… I’m sure Cursor will fix those just fine when I ask, though.

So, what to make of it?

So, what do I think…

My first impression is one of awe: creating working software has never been this easy.

Maybe in a few months, the more technical users of apps can prompt the tools they need. A future where game designers or product managers create their own helper tools is probably already here3.

Or then, software engineers will get more done, quicker, and can spend more time polishing the work and bringing the quality up?

Or maybe even work a bit less — and still be very productive?

Whatever the future, I’m sure for programming4, this can be great.

Something feels off, though…

When prompting my note taking tool, I realized something I hadn’t thought of before.

As a programmer for the past 30+ years (I started when I was 10 and I’m turning 45 this year), I’ve always enjoyed the state of flow working on code takes me to.

I use coding for thinking, just the same way I do with writing: I think of a solution, work on it, get feedback from my tests and from looking at the results and iterate. All the time, I am focused and immersed in what I’m doing.

Breaks in the flow comes in the moments where I need to wait for things to compile. For example, when working on server code, if I need to wait for the CI process to complete a build so I can see the results in the remote setup, or when waiting for a game build to complete so I can try it on a device.

Today, for the first time ever, I’m feeling the same while my code is being written.

“It’s compiling, from https://xkcd.com/303/“

For example, while writing the paragraphs above, the AI agent was busy adding in-place editing support for my notes.

The agent moves fast (a lot faster than I would) and I have not yet read the codebase, so there’s nothing for me to do there. The level of abstraction I am working at is one of an architect, or maybe a product or UX designer thinking about how the app should function (actually, it’s probably a combination of all of them… I will need to process this thought and come back to it in a later post).

And now, funnily enough, even though the AI is coding way faster than I would be (most of the time, when it’s not making silly mistakes), it feels too slow for this new abstraction level I am at.

And so, I lose the flow.

So now, I’m finding myself constantly context-switching between giving the AI more instructions and doing something else while waiting. Like writing this article.

That’s kind of cool, but I miss the fully engaged thought process of coding myself. Or being 100% focused in writing a blog post.

Maybe this will change though, as the agents become still faster.

Or maybe we’ll need to find ways to stay engaged with the code. That could happen by becoming still more intentional and clear with the prompts to reduce the surprises and back and forth needed to be done with the tool…

What’s next?

In this article, I’ve only scratched the surface in exploring how AI tools can change the face of our craft and what to make of it.

I have many more questions (how does one learn to code in the world of AI agents, what will programmers be doing if users prompt their own tools, who creates the code for AI agents to learn from in the future, why the code I prompted doesn’t feel like mine for sharing in GitHub, …), but as my answers to them are just as tentative as these, I will leave them for later.

Let’s all keep experimenting, and sharing our tentative answers and the new questions that come up!

It’s much more interesting than just passively waiting for the future to unfold.

Footnotes:

  1. As I write these words, my Cursor Agent is pumping out code in the background. To be honest, the whole reason I started writing this post was to find something to do while the code was being generated! ↩︎
  2. I picked Next.js as a framework for the app as I have some experience with it from an internal admin dashboard we’ve built at work, and I thought it could be a nice and simple solution for handling both the backend and frontend. ↩︎
  3. This is one of the questions I want to address next: I want to put a non-programmer at the steering wheel, and see how they work with Cursor to create their own tool. When I do, I’ll report my takeaways on the blog, so stay tuned! ↩︎
  4. I have a fair share of reservations for the use of AI in creative work. I already mentioned writing, and I’ve been thinking about music a lot recently… There’s another blog post in the making for that. For programming, I’m mostly fine. ↩︎

Categories
Work

How to help me notice your job application

A part of my job as tech lead1 is to help my team find the right new people to work with us.

That process always starts with reading and, to put it bluntly, ranking applications.

While doing that, and going through hundreds of applications, I have made some observations which, looking back to my earlier days as a Software Engineer, I think might be helpful for others too in getting through the hardest part of applying for a job: standing out and having your application noticed.

You can’t gain work experience overnight, but many of the things you can do are rather straightforward and available to everyone.2

Here we go.

1. Most job applications are carbon copies of each other

If you want to stand out, this is great news for you. 

I’m not exaggerating a lot if I say that 90% of job applications start with the same greetings, and are then followed by the same description of how the candidate is excited to work at our company and how they are passionate about our games. 

Don’t get me wrong: I am happy that you to be excited.

But I don’t need you to sell me my workplace. I already like it here.

The applications that catch my attention have a human feel and show something true about you.

So, here’s my first tip: I want to see the real you. If we hire you, that’s the you we’ll be working with, after all.

What does that mean in practice? 

  1. Write like you speak. Avoid fancy words, unless they are part of your everyday vocabulary and that’s how you always communicate. 
  2. Don’t outsource the writing to AI. Using AI tools like Grammarly3 to correct your spelling and to make your text more readable is fine and even recommended. But the text should be still in your voice, just polished.
  3. Don’t hide behind your words, use them to show us who you are.

Those reading your application are people just like you. And humans love connecting with other humans. So, write like you would to a friend or a colleague. That will keep us reading.

“Hello” is better than “Dear hiring manager.” 

“Also” is better than “Additionally.”

“I’d like to join your company” is better than “I am excited to express my interest in joining your dynamic and creative team.”

2. A cover letter is your chance to explain yourself

If your career path has been one straight line from one well-known company (= known by the person reading the application) to the other, working in roles that match the one you are applying for one-to-one, by all means, skip the cover letter and just send in your CV. 

We are not picky, and don’t need a cover letter “just because.”

If the CV says it all and what’s there matches with the job, sure, I’ll want to talk to you. 

But that’s not the case with most CVs.

Let’s say that all your previous workplaces were in a different industry from ours. We don’t have the time to ask you questions, so at the back of my mind, I will have a nagging feeling that there is more to the story — but I will still discard your application.

It doesn’t have to be like that.

You have a tool for handling this scenario: the cover letter. 

Use it (in your voice, following the tips above) to openly share your career path.

Maybe you are a career switcher and have only recently found out that game programming is the best path for the next step in your work life. Tell me how what you’ve learned in your previous work experience will help in this new line of work and what you are doing to make the transition.

Maybe you’ve been perfecting your game programming skills while working other jobs, as there hasn’t been a suitable position available for you in the past. Tell me how you’ve practiced in your free time, and what you’ve learned through it.

I love the idea of someone trying different things (I’ve done some of that myself), but as a professional, I am responsible for hiring someone who can do this job and ace it. 

If you are that person, I need you to convince me.

If you don’t, we both lose!

Which brings me to the next point:

3. Be as clear as you can about your selling points and how they match the role

In other words, do your homework.

Every role has its own set of requirements, and it saves everyone’s time (yours, mine, our hiring team’s, and so on) if we can quickly judge whether there’s a match this time or not.

This works both ways: We are looking for a person who will thrive in the role, accomplish great things, and have a good time doing so. And you are looking for a workplace where you can do just that — I hope.

In practice, it all starts with knowing who you are and what sets you apart.4

So, before updating your CV and writing your cover letter, ask yourself:

  • What am I good at?
  • What proof do I have for that? (= What have I done so far? Go deeper than just listing job titles. Think about what you did in those jobs, what you learned, and so on…)
  • What do I want to do next?
  • In what areas do I want to grow?

Then, look at the job application again, this time more carefully, and compare your notes with what the team is asking for. 

No, you don’t need to tick all the boxes (hiring teams are greedy, and we tend to list all kinds of nice-to-haves), but everything in the list is there for a reason. It tells you about us. From our job ads, you can see what we value and what it might be like to work with us.

If you don’t like what you see, don’t apply. You’d be miserable.

If you like what you see but are still very far from the description, don’t apply. Wait for a different role to open up, or send an open application explaining where you are currently and what kind of work you are looking for.

If you like what you see and tick the boxes at the top of the job ad’s requirements (we put the most important stuff first), it’s time to go through your CV, polish it, write a cover letter (points 1 and 2), and finally send them over.

So, in your CV and cover letter, what do I look for?

Like I said above, my goal is to find someone who can not only do the job but also be happy in it.

And to save time and stay happy myself, I look for shortcuts that tell me you might have the skills and attitude.

When hiring for a mid-level role (e.g., “3+ years of Unity experience”), the number one shortcut is your work experience. Tell me the companies you’ve worked for, what you (not your team, but you as a part of the team) have done in those roles, and what you learned from those positions.

Also, remember that I’m looking for skills relevant to the job, so you don’t need to list everything. Just the relevant positions. If there’s anything unclear, remember what I said about the cover letter — it’s a great place for explaining unclear things, such as:

  • holes in your career progress,
  • why you have been working two roles at the same time (…maybe you have your own side business, in which case I will be curious to hear if you’ll be able to fully commit to us or not),
  • why you are applying for a role that, based on your CV, looks like a step back (e.g., going from CTO to programmer)

For a more entry-level programmer position, the principle is the same: I’m looking for a quick way to assess your skills and attitude. However, as you can’t have the work experience, I’ll be looking for other shortcuts.

Projects you’ve worked on yourself are great.

These can be school projects that you are particularly proud of, hobby projects, or open-source contributions, as long as you clearly explain what you did, and what you learned from it.

Education matters, but mostly as just another shortcut. To put it bluntly, if I see that you have a Computer Science diploma, I am more likely to assume you know your design patterns, the principles of object-oriented programming, and so on.

If you don’t have the education, other shortcuts need to be stronger to compensate. It’s not a blocker.

4. Send good great code samples

Job ads might not explicitly ask for code samples. Send them anyway, because we’ll want to see them.

Also, don’t say things like “I can send code samples if you like.” Someone else will send us a link to their code samples right away, and we won’t ask for yours.

Code, for a programmer, is what an art portfolio is for an artist.

If your resume reads as a straight progression of relevant work in big, well-known companies in the same industry as the job you are applying for, you might be able to skip this. But if I don’t know those companies by name, I will need to see your code. 

In the games industry (with the game engines we have today, such as Unity), this is especially true. 

My 17-year-old son is making amazing-looking games in Unity without any coding background. He mostly copies tips and tricks from YouTube and then tweaks them to do what he needs. He is smart, but I wouldn’t hire him — yet. I’ve seen his code.

That’s why video reels, screenshots of your games, or even links to published ones don’t tell me anything about your programming skills. Show me the code.

But hold it just for a bit…

Everything I’ve said in the previous points also applies to your code samples.

The people checking your code are busy. We are humans. We look for shortcuts.

That’s your chance to stand out.

Make your code not just good but great. And make it easy to access.

Let’s get practical:

First, if possible, use GitHub. We all know how to navigate the service, so it’s easiest for the potential recruiters to find your code there.5

How to make your GitHub account stand out?

Go back to your GitHub profile and look at it, asking yourself this question:

If someone has 5-10 minutes to look at this page, how likely is it that they will look at the code I want them to see? And if they do, will it look the way I think it does?

Most GitHub accounts just show the repos the owner has been active in recently. Those may not be the best ones for showcasing your skills! 

Don’t expect me to go through all of your code.

Send me straight to your best work.

In GitHub, a nice way to do this is through a profile README file where you introduce yourself and point the visitor to the relevant code. And by relevant, I mean code that shows something interesting about you.

Then, do the same in each project, describing what they are about, why you wrote them, and how to navigate through the codebases6.

If you can’t do that straight in GitHub, use the cover letter.

“Here’s a direct link to the code in my GitHub repo I’m most proud of,” followed by some context to explain why you think that code is relevant will make me read your work. 

Finally, I’ve noticed that first impressions matter also when it comes to code. Bad formatting, leaving in a lot of commented-out code, and small (?) things like that will get in the way of me noticing the better qualities of your code.

I do my best to look beyond the first impressions. But by making sure the code samples you share are as good as you are capable of making them, you again have a chance to stand out!

  • Organize your classes in a logical directory and package / namespace / … structure
  • Follow a style guide (for Unity, Microsoft’s C# Coding Conventions are a good starting point)
  • Comment what needs to be explained, but not more
  • Don’t leave in extra line breaks or commented-out code
  • Always use braces on if-then7

With all these superficial things out of the way, what’s left is making sure your code is actually good. And that’s what our profession is about, so I trust you’ll know what to do8.

And a bonus. If you are a Unity developer and your code example contains unit tests, I can guarantee I will look more closely!

Finally

After all the tips, you might feel discouraged and ask yourself: “Does it make sense to apply at all?”

Don’t stop there.

If there’s a job opening that matches your interests and you believe you can excel in it, companies want to hear from you.

I’d love to see you get hired in a role that’s well-suited for you. Maybe at some point, it’s with us, and we get to work together.

Also, remember that there are always more good candidates than we can hire. So, if my team doesn’t pick you, take the lessons learned and try again in your next application — and remember that it doesn’t mean there’s anything wrong with you. There’s always next time!

Hopefully, these tips will help you get noticed and improve your chances of getting hired. Every application is a chance to practice, as is every job.

Never stop learning.

Footnotes

  1. I work at a very nice Finnish game studio called Futureplay, check us out. ↩︎
  2. One caveat: as I say in the title, these tips will help you get me to notice your application. I can’t claim that they work universally. But with that in mind, take a look and see what makes sense to you. Apply that, and best of luck! ↩︎
  3. Don’t accept everything Grammarly suggests. I used it with this text, for example, but intentionally decided against some of the improvements as they would have changed my tone too much. ↩︎
  4. Pro tip: it’s not your passion for games and game development (at least if I trust what job applications say). ↩︎
  5. If you have nothing good, or new enough, to post on GitHub (for example, it’s common for more senior programmers that all of their recent code was written at work), use some other means of sharing code. Do you have even short samples you can send through Google Drive? Can you make some? ↩︎
  6. This is a friendly gesture towards every reader of your public code, not just recruiters, actually. ↩︎
  7. This depends on language (as not every language uses curly braces), and there’s a lot of debate on the question. Personally, in languages like C# or Java, I find this an important practice. ↩︎
  8. If you don’t, don’t apply yet. Practice and then come back! ↩︎

Categories
Writing

On Blogging

Do you remember the time before Facebook and social media took over, when we would gather at people’s personal web spaces to read each other’s thoughts and discuss them?

For quite a while already, I’ve found myself longing those years when we got quite close to having the perfect online platforms: the personal website and the blog.

And as a matter of fact, they never went anywhere. The tools are better than ever.

Some never stopped using them either.

Many did.

I did.

Now, I want to be back.

This is the start of a new blog, a place for my thoughts, with no grander goals than going a bit deeper than social media and thinking about things a bit more.

Maybe we can talk. Maybe these thoughts matter.

Let’s see.