DEV Community: Frihk Ian

Vibe Coding Didn't Kill Junior Devs' Careers. It Just Fast-Forwarded Them.

Frihk Ian — Wed, 29 Jul 2026 13:07:36 +0000

What was originally a joke, a colloquial term for projects that are done on the weekend, in which you tell a model what you want to do, don't read what it tells you, and follow it by feeling. It was completely out of that "hole" by 2026. Ninety-two per cent of U.S. developers are using AI coding tools daily, up 340% from the year before, and a growing number of junior developers built their entire portfolio around it, since it allowed them to deliver something impressive without having to go through college and years of fundamental coding.
That remained for a time. Next, it was time for the bill.

The surging demand for hiring that no one anticipated.

Vibe coding isn't only a coding style; it's an economic change. 25% of startups in Y Combinator's Winter 2025 batch had codebases that are 95% or more AI-generated. The price of developing a viable SaaS product has come down from $200,000 to $5,000, and the time to build is now six weeks versus six months. In that same context, a junior developer who can truthfully boast, "I built this whole app myself using AI" seems like a brilliant hire, both cheap and fast and able to deliver a complete product with just one developer.

63% of today's coding users describe themselves as non-developers, product managers, marketing directors, founders, designers. Forrester reckons that there are currently more than 16 million active citizen developers in the world, and Gartner foresees the number of citizen developers will surpass the number of professional engineers by four to one by 2028. For a hot minute, it was really just "junior developer" or "person who could prompt well", and hiring managers went for whoever could get the demo packaged out the quickest.

Next, the codebases had to be tested!

All this has a productivity understory that isn't as easy as the pitch makes it sound. In a controlled study, METR determined that more experienced developers who worked on large, actual codebases were 19% slower when using AI tools, and also felt they were 20% faster. Almost 40 points between how fast people feel and how fast they actually are, and that's important in that it really means that the teams that are planning sprints based on their self-reported productivity are doing it quietly on the sidelines.

The same can be said for quality. In one prominent study, the rate of bugs increased by 41% post AI coding tool adoption, while other research comparing AI-coauthored pull requests with those written by humans revealed 1.7 times more major issues, with logic errors up 75% and readability issues tripling. However, the less glamorous part of code, that which is refactored and simplified, dropped from a quarter of changed code in 2021 to under ten per cent by 2024, even as the amount of code being shipped kept climbing. This doesn't appear on day one. It emerged by the 12th week, when teams are usually using 20-30% of their sprints to repair bugs they weren't fully aware of when they were first created by AI code.

That's the reason why junior developers are the first to take the hit. Still, debugging doesn't involve writing code; it involves understanding code, and that's something that vibe coding allows you to avoid. A developer can develop a working feature and never, ever have a mental model of why it works, and that's okay until it doesn't and there's no foundation under them. Add security to the mix, and you'll find that almost half of all code generated by AI fails basic industry security standards, and that one study of more than 200 applications coded by vibe reveals that over 90 per cent had one or more vulnerabilities stemming from a lack of awareness of what they don't know. These are not fancy bugs, but the very basic ones: unvalidated input, lack of access controls, exposure of credentials, all of that sort of thing that an experienced engineer instinctively looks for, and a junior developer who didn't get the rudiments of engineering basics.

There is no uncertainty about the production failures. One vibe-coding tool experienced three separate security incidents which were widely covered, including one that remained open for 48 days. In another case, an AI-powered social app took just three days to leak 1.5 million authentication tokens and 35,000 emails. On the broader market, about ten thousand startups have tried to work out a working production application using an AI assistant, and over eight thousand of them need costly rebuilds that are usually $50,000 to $500,000 a pop, because the demo they would build wasn't going to hold up with actual users, actual load, and an actual security audit.

The market took no notice of this,

As developers have incorporated these tools into their workflows, they are also becoming more sceptical about their effectiveness. Developers' own trust in the tools has been shaken as they have used them more. Trust has dropped from approximately 40% two years ago to approximately 29% today, and almost half of developers actively distrust the output of AI-generated code. Only a small number of senior engineers say they have high trust, and one in five say they have high distrust among senior engineers specifically. But less than half of developers claim to always look over AI-generated code before committing it, meaning that plenty of AI-generated code is flying the flag without a second glance.

Labour statistics are now catching up with the anecdotes. Overall demand for engineering talent hasn't gone away, but junior developer hiring has dropped by almost 20% among those who would typically begin their careers in this role. As much as forty to seventy per cent of the traditional entry-level development has been swallowed up by AI. Meanwhile, junior developers, who are seeking to enter the field, are doing so in one of the most competitive fields in years, and at the bare entry-level, in a field that increasingly demands the judgment of a senior engineer.

The irony is sharp. The idea of vibe coding was to make it the leveller, the one thing that anyone could do and be a builder. For a certain group of junior coders, however, it was a way to an appointment and a quick path out of it, since the skills used to land that job didn't necessarily help when it came time to interact with real people, real traffic, real security audits.

What really makes the difference between the ones who make it and those that don't?

The organisations and developers that will emerge from this cycle without issues are not ones that eschewed AI but rather embraced it as an aid to real understanding, not a replacement. The pattern that passes this test is more "let me build with AI" than "let AI build it for me," with the caveat that while the AI is allowed to build it, there is a human in charge of checking each step it takes when the code is written into production code, the AI doesn't run the test gates unless there is a deadline pressure that can't be overcome, and the specifications are detailed enough for an agent to know exactly what is supposed to be built, and not just handed an open-ended prompt and encouraged to guess well. Such teams are consistently spared the technical debt and exposure to security issues that plague other teams that scale up their use of AI without first establishing that structure. If teams consider governance as something to do afterwards, they are almost always going to pay for it afterwards at multiple times the cost of doing it from the beginning.

Vibe coding doesn't need to be abandoned, and it shouldn't. If you're a junior developer trying to land a job right now, the pitch that lands you the job and keeps you on is NOT "I can have AI create things." It's "I know how it works well enough to fix it when it breaks, secure it before it ships, and explain it to the next person who touches it."

Multiagent orchestration article

Frihk Ian — Tue, 28 Jul 2026 08:38:11 +0000

Multi-agent orchestration is the hot topic of 2026. Introduced in February, Agent HQ from GitHub allows developers to concurrently use Claude, Codex, and Copilot to solve a problem, with each having a different perspective on trade-offs or details. Between Q1 2024 and Q2 2025, Gartner experienced a 1,445% increase in inquiries about multi-agent systems. Steve Yegge, a very experienced engineer at Amazon and Google, has discussed his work on orchestrated agents and producing 12,000 lines of code per day. Even more impressively, Cursor's team programmed an entire browser over a thousand files and a million lines of code in just one week by using hierarchical orchestration rather than having a single agent perform all the tasks sequentially, though multiple reviewers reported the code didn't compile at announcement, and Cursor's own CEO described the result as merely "kind of works".

The part nobody's celebrating

The only news to this is Google's 2025 DORA report. It determined that for a 90% increase in AI adoption, bug rates climbed 9%, code review time rose 91%, and average PR size grew 154%. When read as a single group, that pattern emerges instantly: teams are shipping more code, more quickly, and it's measurably more difficult to review, and measurably more buggy once it is shipped. No, multi-agent setups don't help with this; they exacerbate it. You're not just reading one model's decisions now; you're reading several.

Engineers who interact with such systems refer to a particular type of failure: architectural drift, in which each agent takes an action that is locally optimal but inconsistent with the actions taken by the other agents five minutes ago. One agent selects one pattern to use for errors, another agent selects another pattern for a neighboring module, and nobody realizes until anybody attempts to extend the feature, and the codebase spits. Then there is the issue of "lost in the middle," as it's called, and how much information that is in the middle of the long context window becomes lost and essentially forgotten by the agent, so it seems like it doesn't know about it.

The naive version of this doesn't work very well, as Cursor's own account of constructing that browser admits. The first tried to treat all agents the same and, to avoid collisions, used file locking, but this didn't work: agents were holding locks too long, and twenty agents were operating at the throughput of two or three. Their second attempt was optimistic concurrency control, not locks, and that didn't work out quite right; the agents became more of a risk taker and began to avoid anything that resembled a hard task. What really worked was a hierarchical structure as opposed to agents being free to improvise in parallel: Planner agents that continuously explored the codebase and created tasks, Worker agents that executed assigned tasks without coordinating with each other, and Judge agents that determined whether to continue at each cycle's end, rather than a bunch of agents improvising freely in parallel with no one peeking at each other's work.

Why this becomes a review nightmare

In response, automated PR review tools have scaled, and teams managing multiple agent review fleets see real improvements: 30–60% faster review cycle times and, in the best cases, 25–35% fewer production defects. But even the researchers developing these systems are straightforward about the problem: AI reviewers are good at spotting issues in the code, and they're not so good at understanding what you were trying to accomplish, and why you were making the decision. What you get is a ton of automated "this could be improved" comments, yet not much of "this doesn't fit how the rest of the system thinks.

In a piece about orchestrated coding, Addy Osmani stated it quite simply: "With an orchestrated army of agents, there's no natural bottleneck. Small harmless mistakes — a code smell here, a duplication there, an unnecessary abstraction — compound at a rate that's unsustainable." These are no longer being created by a single human who was used to writing the code manually and would have noticed any errors or bugs; now they are just being created by many humans who are not involved in the code change, so the errors just accumulate. There is no crash reported. It turns up when someone tries to add a feature to it, and finds the architecture won't support it, and the tests that the agents also wrote are no more reliable than the code they were supposed to be checking.

What this actually means for teams adopting this now

None of this is a reason to not use multi-agent coding. The productivity narrative is true, and it will keep going. But it is the teams who are designing plan-approval steps, token budgets, verifier agents, human review gates, and so on into their orchestration, rather than eliminating themselves from the equation and hoping that the agents will get it and do this well. These teams will not realise the cost right away if they do not do that. They will see it in 6 months when the two-line feature request becomes a two-week rewrite, and no one, human or agent, understands the system's structure and why.

There was never a problem with speed. It was inevitable that coordination would be difficult. But it was not until now that we needed to solve it.

Nobody's Reading Tutorials Anymore. They're Just Asking AI.

Frihk Ian — Mon, 27 Jul 2026 00:52:47 +0000

Two or three months ago, I noticed that my Go tutorials were not receiving the level of engagement I was expecting, with fewer comments and saved posts. The first thing that popped into my mind was that I was slipping. Then I absorbed the larger data, and it seems this isn't a me problem; this is an industry problem.

The figures are appalling.

Begin on Stack Overflow, which was the most comprehensive reference library for technology. During 2014 to 2020 Question volume reached a maximum of over 2,00,000 per month. It ended up below 50,000 already in late 2025, wiping out 15 years of increases. A January 2026 data visualization, built from Stack Overflow's own Data Explorer, showed the platform's monthly question volume had fallen back to roughly what it was in 2008, the year the site launched. The same 2025 Developer Survey found that while 82% of respondents still visit Stack Overflow at least a few times a month, only 25% do so daily or more often, a shift from the platform's old status as a daily habit for most programmers.

It's not just one platform which is in trouble. Invisible, though, is the larger behaviour change, one that goes beyond the visible symptom, namely that developers no longer consult written references first.

Rather than "Where everybody was," here is "Where everyone went.

They went to AI. In the past, this was a rarity, no longer the exception. Approximately 84% (up from 76% a year ago) of all developers use or plan to use AI coding tools, according to an AI Coding Assistant survey Stack Overflow conducted this year. Developers report being most comfortable turning to AI for tasks like searching for answers, learning new concepts, and writing documentation, and 44% of developers now use AI tools to learn to code, up from 37% the year before. Interestingly enough, when developers are asked what their favourite tools of the art are best at, "creating documentation" and "explaining any existing code" are near the top of the list, ahead of "writing new code from scratch.

The final one is worthy of contemplation: developers are increasingly turning to AI to explain a concept rather than write plain, original code for them. That's right, a direct miss on everything that the tutorial does at its core, which is explaining.

No wonder, it's not that difficult! The tutorial is geared to the "average reader" (as it's called). A question is directly written for you right now with your stack trace, your file, your specific stupid typo. No pages of preamble to scroll through to discover just one line of config that you needed, no "Closed as duplicate" and no ads, just an answer tuned to your exact problem.

However, this doesn't seem to be a clean sweep for AI.

And this is where it gets more interesting than 'AI beat tutorials, tutorials are dead!'. Usage is on the increase, but trust is not. Some 46% lack confidence in the accuracy of AI-generated output, up from 31% a year ago, and nearly two-thirds feel AI frequently generates code that seems correct but isn't necessarily reliable. In fact, according to research from METR, seasoned developers actually took 19% longer to accomplish their tasks using AI tools; however, they felt they finished 20% faster after completing the work. There is definitely an overestimation of how much AI is actually supporting people.

An even more acute concern is piling up regarding junior developers. They do not develop the predispositions they need when they rely on AI to solve their problems rather than on docs and forums. They can possibly write working code without knowing how it works, which is okay up until the moment the AI goes off-track by making a minor mistake that it finds hard to track in the code; at that point, they don't have a solid base to lean on if it goes astray.

It is not a matter of "tutorials stink, AI is good. It's that developers have settled on a path that's more time-consuming and difficult, and that offers the chance to develop real comprehension, rather than a quicker way that yields an answer with little assurance it's correct.

Popular lessons can be seen when you write tutorials. Writing tutorials will show some of the popular lessons.

This is not that it is time to halt its development; it's just that it's time to modify what you write and how. Generic explanation/memorized text is strong, with the notable exception of gotchas or "why this worked last month, and not now", explaining architectural trade-offs is strong, but nothing concerning a fast-changing library or a particular corner case is strong. Well, that's where a good article still gets its power from. It also helps when you are aware of the fact that unless the AI does an excellent job with their answer, your reader is not coming to your post cold, rather they are here because they want to take a look at it to see if it matches their requirements and/or sanity, so if you write assuming they came to your post because the AI answer did not suffice, it will benefit more than an answer they are reaching for from cold.

Optimise for skimmability and machine-readability as well, because these days there's a decent portion of traffic that's not coming to you from a human who's reading from top to bottom, but rather there's a machine there reading your page to respond to the query of someone else. Headings, explicit statements of code, and clear explanations benefit both the writer and the reader. Finally, don't forget to be more specific about the "why" rather than the "how" — it's the one thing that thin AI answers so rarely but the most crucial part of what junior developers need and the part that will keep a human reader on your page.

What direction this is taking

I don't know why, but tutorials don't just disappear. I don't think the form that dies is a particularly useful way to get X configured, since there's a much simpler prompt that does the job more easily. The things that remain, perhaps even grow, are the pieces of writing that convey judgment, negotiation, nuance, and detail that have not yet been fully captured through modelling.

So was the love for reading changed. It wasn't until somebody "got it" that the need for someone who actually understood the problem.

Array in Go

Frihk Ian — Wed, 24 Jun 2026 09:33:49 +0000

What is an Array in Go?

In Go, an array is a fixed-size, ordered set of values with the same type. Imagine an array as a 12 egg tray; the minimum number of eggs which can fit into an array is 12; the maximum number of eggs which can fit into an array is 12. That is the exact behaviour of a Go array.

package main

import "fmt"

func main() {

var groceries [3]string// Step 1: Create an array that holds 3 strings
groceries[0] = "Bread"// Step 2: Put "Bread" in slot 0
groceries[1] = "Milk"// Step 3: Put "Milk" in slot 1
groceries[2] = "Eggs"// Step 4: Put "Eggs" in slot 2
fmt.Println(groceries)// Step 5: Print the whole array
}

Expected output:
[Bread Milk Eggs]

Zero Values

In Go, you create an array by using the var keyword, and each of the slots receives the safe code Zero value, given that no elements are explicitly set.

This means that your array will never be in an unsafe state of being uninitialized. It will be valid on every slot, even before set. The same thing is a safety feature in Go intentionally.

var prices [3]float64

fmt.Println(prices) //  Output: [0 0 0]  - Go fills all the values with zeros automatically

Declaring an Array

In Go, you can declare an array in a few different ways, and you will learn about each of them in turn.

Using the var Declaration

var groceries [3]string
groceries[0] = "Bread"
groceries[1] = "Milk"
groceries[2] = "Eggs"

If you want to initialise an array of a specific size and use it later, then this is the best method to achieve this.

Array Literals

If you are already aware of all the values at the time you write the code, then you can use the literal syntax:

package main

import "fmt"

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
fmt.Println(groceries)
}

Expected output:
[Bread Milk Eggs]

The actual syntax is:
[size]type{value1, value2, value3}
This method is used when we know the values which we want to store in an array.

Let the Compiler count for you — The `...` trick

When using literal syntax, and you find that you have to manually count yourself, there's a shortcut in Go. Use ... to fill the size so the compiler can calculate the length automatically.

groceries := [...]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"} //Three dots  compiler counts for you

The type of groceries is [5]string. The ... instructs the compiler to count for you. This will be helpful if you have a super long list and you can't determine its length.

Sparse Initialization

You can also use index: value syntax in the braces: to specify where a value will go:

package main

import "fmt"

func main() {
// Put "Bread" in slot 0 and "Coffee" in slot 4; all other slots get ""
groceries := [5]string{0: "Bread", 4: "Coffee"}
fmt.Println(groceries)
}

Expected output:
[Bread Coffee]

This is helpful when you have an array of a large number of elements, but just a couple of elements to change.

How to access elements and modify an array.

Each element of an array is retrieved by the array name and an index number enclosed in square brackets.

package main

import "fmt"

func main() {

groceries := [3]string{"Bread", "Milk", "Eggs"}

fmt.For each element, read it on the screen: 
Println(groceries[0])// Read "Bread" on the screen
fmt.Println(groceries[2])// Read slot 2: Eggs
groceries[0] = "Brown Bread" // Change the value of the 0th element of the array.
fmt.Println(groceries[0])// Read slot 0 again → "Brown Bread"
}

Expected output:

Bread
Eggs
Brown Bread

What are the consequences of going beyond the lines?

If you try to access a non-existent part of a structure (for example, groceries[5] for a 3-element array), then Go will immediately exit the program with a runtime panic:
runtime error: index out of range [5] with length 3
Not a silent bug this time. Go lets you know what was amiss. len(array) - 1 is the final valid index in the array.

Getting the Length with len()

len() returns the size (number of slots) of an array:

package main

import "fmt"

func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}
fmt.Println("Items on list:", len(groceries))
}

Expected output:
Items on list: 5

If an array is declared with a size, then len() always returns the exact size, irrespective of whether there are values stored in some of the array's slots. An array is always the size that it was created to be.

Also, there is an operation cap(), which is called "capacity". Arrays cannot be lengthened or shortened, but the two functions, cap() and len(), return the same value. Use len(arr) instead of literals for the size. If you ever change the array declaration, len() adjusts automatically.

When the array is of length, len() always returns the size (independent of whether or not there are zeroes in the array). An array is always allocated the memory space it was declared to have.

Arrays are valued, not references.

As a result of Go's copy behavior on assigning an array to a new variable, the entire array is copied. There are two independent variables – if one changes, the other one definitely will not change at all. Let's say we think of an example;

package main

import "fmt"

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
backup := groceries// This copies ALL of groceries into backup

groceries[0] = "Brown Bread"// Change the original

fmt.Println("groceries:", groceries)
fmt.Println("backup:", backup)
}

Expected output:

groceries: [Brown Bread Milk Eggs]
backup:[Bread Milk Eggs]

The above shows that despite replacing groceries [0] with ‘Brown Bread’, backup was not affected. This is similar to photocopying your shopping list! After they've made the photocopy, it remains unchanged if they write on the original. They started identical, but are now two completely separate pieces of paper.

Sharing With Pointers

If we want, the changes that we make with our new variable to affect the original array, it's using a pointer.

package main

import "fmt"

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
shared := &groceries// & means "give me the address of groceries"

groceries[0] = "Brown Bread"

fmt.Println("groceries:", groceries)
fmt.Println("shared:", *shared)// * means "follow the pointer to the value"
}

Expected output:

groceries: [Brown Bread Milk Eggs]
shared:[Brown Bread Milk Eggs]

&groceries make a pointer. You don't copy the array; you copy a small "address" indicating where the array is stored in memory. That is followed by the word ‘*shared follows that address to get the actual value. When Shared access is needed, Pointers are used. In most situations, you'll opt for the default copy behaviour, which is more secure and easier to do.

Comparing Arrays

Go and share how you can use “==” and “!=” to compare two arrays of equal “size” and “type”.

package main

import "fmt"

func main() {
list1 := [3]string{"Bread", "Milk", "Eggs"}
list2 := [3]string{"Bread", "Milk", "Eggs"}
list3 := [3]string{"Bread", "Milk", "Coffee"}

fmt.Println("Same?", list1 == list2)// true
fmt.Println("Same?", list1 == list3)// false
}

Expected output:

Same? true
Same? false

Two arrays are equal if they are of the same type and length and the elements of the arrays in the corresponding positions are all equal. You must have both conditions.
Comparison of differently sized arrays is not possible. The compiler will halt you, since they are of different types.

Looping Through Arrays
For small arrays, manually writing the below would work: groceries[0], groceries[1], groceries[2]. Anything larger, you just use a loop to visit each element by itself. Some of the loops you can use to accomplish this are listed here:

The for range Loop

The most popular looping over an array in Go is the following for range loop:

package main
import "fmt"
func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}
For each element (index, item) in the groceries: {
fmt.println("Index: " + index + " Item: " + item)
}
}

Expected output:

Index: 0 Item: Bread
Index: 1 Item: Milk
Index: 2 Item: Eggs
Index: 3 Item: Butter
Index: 4 Item: Coffee

The index will contain the number of the slot that is being modified on each iteration through the loop, and the item will contain a copy of the element being modified. The loop stops by itself when it runs out of elements. No more worrying about out of bounds.

In Go programming, all the variables defined must be used. The for-range loop provides Go with two variables in its "for" clause: the index and element variable. If the index isn’t useful to you, then you can't just leave it there intact. It will refuse to compile with Go.

This is where the blank identifier _ is introduced. It is Go's way of letting you say, "I know this value exists, but I am deliberately throwing it away."

package main

import "fmt"

func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}

for _, item := range groceries {
fmt.Println("Item:", item)
}
}

Expected output:

Item: Bread
Item: Milk
Item: Eggs
Item: Butter
Item: Coffee

It's also possible to discard the value and keep the index. If so, simply do not use the second variable at all:

For each index in the groceries array {
fmt.Println("Index:", index)
}

A classic for Loop.

In the case where you require more control, such as when going in reverse or skipping an element, the classic counter-based for loop is best:

package main

import "fmt"

func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}

for i := 0; i < len(groceries); i++ {
fmt.Println("Position", i, "->", groceries[i])
}
}

Expected output:

Position 0 -> Bread
Position 1 -> Milk
Position 2 -> Eggs
Position 3 -> Butter
Position 4 -> Coffee

Iterating in reverse:

for i := len(groceries) - 1; i >= 0; i-- {
fmt.Println(groceries[i])
}

//`Output: Coffee → Butter → Eggs → Milk → Bread`

Printing every other item:

for i := 0; i < len(groceries); i += 2 {
fmt.Println(groceries[i])
}

//`Output: Bread → Eggs → Coffee (slots 0, 2, and 4)`

Multi-Dimensional Arrays

So far, all the arrays have been a single row of values (one-dimensional). Multi-dimensional arrays (arrays of arrays) are also supported in Go.
The most common case is a 2D array, which is a grid or a table. For instance, if I go to the shops every week and make a plan for the items I want to buy by each day and area of the shop:

package main

import "fmt"

func main() {
// A 3-day plan with 2 items per day
weeklyPlan := [3][2]string{
{"Bread", "Milk"},// Day 0
{"Eggs", "Butter"},// Day 1
{"Coffee", "Fruit"},// Day 2
}

for day, items := range weeklyPlan {
fmt.Printf("Day %d: %s and %s\n", day, items[0], items[1])
}
}

Day 0: Bread and Milk
Day 1: Eggs and Butter
Day 2: Coffee and Fruit

[3][2]string: An array of 3 elements, each of which is an array of 2 strings. The first index tells you which row to choose, the second index tells you which column to choose:

weeklyPlan[0][0] = "Bread"// Day 0, first item
weeklyPlan[0][1] = "Milk"// Day 0, second item
weeklyPlan[2][1] = "Fruit"// Day 2, second item

An index position is needed to reference a particular cell, the first being the row index, and the second, the column index.
passing an Array object to a function.
In Go, an array passed to a function is itself a complete copy of the array; the function does not refer to the original array. Any changes the function makes don't affect the original:

package main

import "fmt"

func printAndModify(list [3]string) {
list[0] = "Changed"// Modifies the LOCAL copy only
fmt.Println("Inside:", list)
}

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
printAndModify(groceries)
fmt.Println("Outside:", groceries)// Original is unchanged
}

Expected output:

Inside: [Changed Milk Eggs]
Outside: [Bread Milk Eggs]

The function takes a snapshot of an array that is independent of one another.
If you have to change the original function, provide a pointer:

package main

import "fmt"

func updateFirstItem(list *[3]string) {
list[0] = "Brown Bread"// This modifies the original
}

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
updateFirstItem(&groceries)
fmt.Println("Outside:", groceries)// Now the original IS changed
}

Expected output:
Outside: [Brown Bread Milk Eggs]

If you have a large array greater than a few hundred elements, always use a pointer instead of copying to avoid the cost of the copy.

Limitations of Arrays

Though concise and straightforward, arrays are restricted in their use and come with limitations that you'll hit hard soon.

The Size Is Fixed Forever

After defining a [3]string, it will always contain exactly 3 strings, always! You can't add a fourth item. You can't remove one to shrink it. The size is baked in at compile time. If your shopping list grows to 6 items, your [5]string array can't help you.
The array size can not be a variable, must be a literal number or named constant:

n := 5
var groceries [n]string

The above is a compiler error because of the occurrence of the variable n.

Fix:
const n = 5
var groceries [n]string// it Works, n is a constant

This means you can't create an array whose size depends on something you only know at runtime, like how many items the user typed in. For that, you need a slice.

Passing Large Arrays Is Expensive

Every function call copies the entire array. For a [10000]string, that is 10,000 strings copied just to call a function.
Arrays of Different Sizes Are Incompatible Types
A function that accepts [3] strings can't be called with a [5]string. You would need two separate functions with different signatures.
append() Does Not Work on Arrays
append() — the function that adds elements to a collection — only works on slices, not arrays:

groceries := [3]string{"Bread", "Milk", "Eggs"}
groceries = append(groceries, "Butter")// Compiler `error`: append expects a slice

These limitations are not bugs. Fixed-size value types are simple, predictable, and give the compiler strong guarantees. But most real-world programming needs something that can grow and shrink at runtime. That something is the slice.

Common Mistakes with Arrays

Mistake 1: Assigning Arrays of Different Sizes

list := [3]string{"Bread", "Milk", "Eggs"}
var biggerList [4]string = list//  Compiler `error` — different types

Fix: make sure both arrays have the same size, or use a slice if you need flexibility.

Mistake 2: Expecting Assignment to Share Data

list := [3]string{"Bread", "Milk", "Eggs"}
backup := list
backup[0] = "Brown Bread"
fmt.Println(list[0])// Prints "Bread", NOT "Brown Bread" — list was not changed

Arrays are value types. Assignment copies everything. If you want shared access, use &list to get a pointer, or switch to slices.

Mistake 3: Off-by-One on the Last Element

groceries := [3]string{"Bread", "Milk", "Eggs"}
fmt.Println(groceries[3])//  Runtime `panic`: index out of range

For an array of length 3, the valid indexes are 0, 1, and 2. The last valid index is always len(array) - 1.

Structs in Go

Frihk Ian — Thu, 04 Jun 2026 07:24:29 +0000

Let's explore structs in Go. If you know Go's basic types like string, int, and bool, structs let you handle more complex data.
Say you're building a store app. You need a product's name, price, and in-stock status. Using separate variables quickly becomes messy.
Structs can simplify this. Picture structures are like a blueprint. It makes it possible to package all the related information in one neat and organized bundle.
Now let's dive into creating and using custom data types in Go.

Declaring Structs

Before using a struct, we first need to describe what it looks like. The result of defining a struct is not a piece of data, but the blueprint of data we want to store later on.
Let's take a look at the declaration of the Product struct:

package main

import "fmt"

// We use the 'type' keyword to define a new custom type.
// We name our type 'Product' and specify that it is a 'struct'.
type Product struct {
   Name    string  // Field for the product's name
   Price   float64 // Field for the price
   InStock bool    // Field to check if it's available
}

Creating Struct Instances

Using the struct we just created, let's create a product. Using the struct blueprint to create a piece of data is referred to as creating an instance.

package main

import "fmt"

type Product struct {
   Name    string
   Price   float64
   InStock bool
}

func main() {
   // Creating an instance of Product using a "struct literal."
   item1 := Product{
       Name:    "Wireless Mouse",
       Price:   25.99,
       InStock: true,
   }

   // Creating an instance but leaving fields blank
   item2 := Product{
       Name: "Mousepad",
   }

   fmt.Println(item1)
   fmt.Println(item2)
}

Expected Output:

{Wireless Mouse 25.99 true}
{Mousepad 0 false}

You might be thinking Why does item2 show 0 and false when we didn’t set them?
This is one of Go’s most important behaviours: zero values. In Go, when you declare a variable but don’t give it a value, Go doesn’t leave it empty or undefined (which causes bugs in many other languages). Instead, Go automatically fills it with the zero value for that type.
Since we gave item2 a name, Go automatically sets the price to 0 and in stock to false . This is one of the features in Go that make it exceptional.
Accessing and Modifying Fields
When you want to modify or read information from a struct, you use a dot notation. Consider the dot to be opening up a particular drawer of your filing cabinet to view a folder.

package main

import "fmt"

type Product struct {
   Name    string
   Price   float64
   InStock bool
}

func main() {
   item := Product{
       Name:    "Keyboard",
       Price:   45.00,
       InStock: true,
   }

   // Reading a field
   fmt.Println("Original Price:", item.Price)

   // Modifying a field
   item.Price = 39.99

   fmt.Println("Discounted Price:", item.Price)
}

Expected Output:

Original Price: 45
Discounted Price: 39.99

Anonymous Structs

Sometimes we want to bundle up some information for one-time use. In such a case, we don’t want to have to go through the trouble of formally defining a whole blueprint. They are particularly useful when holding configuration settings, grouping test inputs, or temporarily organising data for a single function. We use anonymous structs in this way:

package main

import "fmt"

func main() {
   // Declaring and initializing a struct at the exact same time
   config := struct {
       Port string
       Env  string
   }{
       Port: "8080",
       Env:  "Production",
   }

   fmt.Println("Running on port:", config.Port)
}

Expected Output:

Running on port: 8080

This is a little confusing, if you are new to Go, because you create the blueprint, then use it to create an instance. Let's look at the code snippet again.

  config := struct { <- this is the blueprint opening brace
       Port string
       Env  string
   }{   <- this is the closing brace for the blueprint, followed by an opening brace.
       Port: "8080",
       Env:  "Production",
   }   <- this is the closing

Think of this like defining a shape, then filling it. Keep in mind that this is a non-reusable type.

Nested (Embedded) Structs

Unlike other programming languages, Go has no “classes” or “inheritance”. Instead, Go employs a technique of packing smaller structs into larger structs, similar to Russian nesting dolls.

package main

import "fmt"

// The smaller struct
type Address struct {
   City    string
   Country string
}

// The larger struct
type User struct {
   Name    string
   Contact Address // Embedding the Address struct here
}

func main() {
   player := User{
       Name: "Alice",
       Contact: Address{
           City:    "Nairobi",
           Country: "Kenya",
       },
   }

   // Accessing the nested data
   fmt.Println(player.Name, "lives in", player.Contact.City)
}

Expected Output:

Alice lives in Nairobi.

Struct Comparison

A question might pop into your brain asking, “Are you able to compare two structs to determine whether they are equal or not?” Yes! Go supports the normal == operator, but only if all the fields within the struct are comparable.

package main

import "fmt"

type Product struct {
   Name  string
   Price float64
}

func main() {
   item1 := Product{Name: "Mug", Price: 12.50}
   item2 := Product{Name: "Mug", Price: 12.50}
   item3 := Product{Name: "Mug", Price: 15.00}

   fmt.Println("Are item1 and item2 identical?", item1 == item2)
   fmt.Println("Are item1 and item3 identical?", item1 == item3)
}

Expected Output:

Are item1 and item2 identical? true
Are item1 and item3 identical? false

Go looks at every single field. If everything matches perfectly, the structs are considered equal.

The Photocopy vs. The Original

This is the most essential concept for beginners in Go. Go’s default behavior is to send a struct by value into a function.
If you were to give a friend a copy of your notes, how would they look? If they add a mustache to the photocopied version, you are fine! This is the default behavior of Go. To change an original struct, the function has to be passed a pointer to it (that is, the original notebook).
Let’s observe both of them together:

package main

import "fmt"

type Product struct {
   Name  string
   Price float64
}

// Pass by Value (The Photocopy)
func failedDiscount(p Product) {
   p.Price = p.Price - 5.00
}

// Pass by Pointer (The Original)
func successfulDiscount(p *Product) {
   p.Price = p.Price - 5.00
}

func main() {
   item := Product{Name: "Book", Price: 20.00}

   failedDiscount(item) // Trying to discount the photocopy
   fmt.Println("After failed discount:", item.Price)

   successfulDiscount(&item) // Giving the function the original via '&'
   fmt.Println("After successful discount:", item.Price)
}

Expected Output:

After failed discount: 20
After successful discount: 15

Best Practices & Common Beginner Mistakes

In Go, names of fields that begin with a capital letter are “exported” and available to other packages (as opposed to names that start with a lowercase letter, which are “private”). If it begins with a lower-case letter (e.g., name), it belongs only to the package it is in. If in any doubt, make them capitalized so that you can use them freely.
Pointers for Modification: Keep in mind the photocopy rule. If your function will call to change or update a struct, then you must pass a pointer (*).

Summary & Your Mini-Challenge

You’ve made it! You’ve learned to structure unsorted variables into orderly, sensible structures. You know how to construct blueprints, make instances, navigate nested data, and update nested data correctly with pointers.

Data Types In Go

Frihk Ian — Tue, 14 Apr 2026 08:23:50 +0000

This is the first in a series of articles exploring data types in Go. The main goal of this series of articles is to provide detailed explanations and practical examples to help you build a clear and strong understanding of the different data types in Go. All the topics will be subdivided into manageable sections, each focusing on a specific aspect of data types, to facilitate gradual learning.

There are many different data types in Go:
The two main data types include:

1. Basic(primitive) Types

This type of data is made up of :

Numbers(int, float64)
Strings(string)
Boolean(bool)
Composite Types

2. Composite Types

These include

Arrays
Slices
Maps
Structs

Other Important Types

These are other very powerful and commonly used data types.

Function types (functions are treated as values)
Pointer Types (used to work with memory)
Interfaces Types(used to define a certain behavior and simplifying flexibility)

In this article, I will focus on basic data types, as they are fundamental to understanding Go and provide a solid foundation for more complex types. While the other types, such as composite, are not necessarily difficult, they involve broader concepts and all depend on the basic types. For a better understanding of each, I cover each in greater depth in separate, dedicated articles.

Basic(primitive) Types

Let's delve directly into the details:

Numbers.

Numbers are divided into :

Integers

These are whole numbers. In Go, we use them in two main ways :
Int - This is the most commonly used, including both positive and negative whole numbers.
Uint - Used to represent only positive whole numbers.

Floating-point

These are real numbers (numbers with decimal points). They include both positive and negative numbers.

var age int = 25 // 25 is an integer 
var height float32 = 186.8 // 186.8 is a float

In Go, Floating-point can either be float32 or float64. The choice lies in the level of precision you need.

Strings

In Go, strings are immutable sequences of UTF-8 encoded bytes, meaning once created, they cannot be altered, which ensures data integrity and consistency.

Immutability

Once a string is created, it cannot be changed. Any attempt to change it creates a new string.

Indexing

The individual bytes can be accessed with a given index:

s := "Hello"
fmt.Println(s[0]) // 72 (byte value of 'H')

This will print 72 as the strings store bytes and H is equal to the ASCII (byte) code of 72.

Length

The number of bytes, not characters, is returned by the len() function:

fmt.Println(len("Hello")) // 5

Unicode and Runes

As the strings are UTF-8, some characters can occupy more than one byte. to act on characters (runes), use:

for _, r := range "Hello" {
    fmt.Println(r)
}

output
72 101 108 108 111

String Concatenation

The + operator can be used to add strings:

full := "Hello " + "World"  // Hello World

To Byte Slice.
You can convert a string to a slice of bytes:

b := []byte("Hello")

Boolean

In Go, boolean values represent truth values; they can only be written as either true or false. They are used mostly for comparison purposes and control a program flow in if, for, or switch statements. In Go, by default, an uninitialized boolean has the value false, making it predictable and easy to work with in decision-making logic.

The section has links to the data types used so far. A link to the next article will be added once it’s ready. When a link is not given on a given type of data, simply means that it is still in the process and it will be given shortly.
Maps
structs

Additional learning materials.
Go Documentation
W3schools

Maps in Golang

Frihk Ian — Tue, 10 Mar 2026 07:23:29 +0000

Maps are one of the most flexible data types in Go. It might even be the most flexible compared to maps from other programming languages. And just as flexible as they are , they are also as simple to initialize.

Understanding Map Structure
A map in Go is composed of two main parts: the key and the value. The key is defined as a unique label used to store and find a specific
Maps are one of the main data structures in Go. Maps have two main parts : the key and the value. The key is like a word you are looking up in a dictionary. It is a unique label that stores and carries a specific type of data. Whilst the value is like the definition of the word you are looking up in a dictionary, it is the data that is stored in the key value. Unlike keys, which only accept comparable types, the value can be of any legal Go type.

In Go, there are two main ways to initialize maps. The first uses the Go built-in make function:

m := make(map[string]int)

The second one uses a map literal:

m := map[string]int{}

They initialize an empty map that takes in a string as the key and an integer as the value. The make method is more flexible because it allows you to specify an initial capacity. When the expected size is known, this preallocation can reduce map growth and rehashing during execution.

Accessing Values and Handling Missing Keys
Reading from a map in Go is quite simple. You access a value by indexing the map with its key, as shown below:
age := m["John"]
Sometimes you might call a key that is not in the map; this happens as a result of misspelling or during testing. Go does not display any error, nor does it crash. It instead displays the zero value of the map's value type.

package main

import "fmt"

func main() {
    m := make(map[string]int)
    value := m["missing_key"] // value is 0
    fmt.Print(value)
}

The program above displays:

0

The “Comma ok” Idiom
This can be misleading; if a key has a value of zero, it becomes difficult to know whether the key has a zero value or its value is a zero. Go handles this by introducing the “ok” to help solve this error. This helps distinguish the erroneous value and the correct value.

value, ok := m["missing_key"]
if !ok {
Return “Error” // The key does not exist in the map
}

Here, the value is the data in the map value. Whilst the “ok” is a boolean that is true. If the value exist then the ok becomes true, and the program executes without any error. If it does not exist, then the program returns an “error.”

Inserting and Updating Data
In Go, the syntax for inserting, updating, or deleting data in a map is consistent and straightforward. When adding/ updating a key, you simply assign a value; the method is pretty much the same as shown below.

m := make(map[string]int)

// Insert: Key "Alice" does not exist, so it is created.
m["Alice"] = 25 

// Update: Key "Alice" already exists, so its value is overwritten.
m["Alice"] = 26

Deleting Elements
When deleting from a map, we use the Go built-in function delete(). It removes the key and everything associated with it. Below is its syntax:

m := map[string]int{"Alice": 25, "Bob": 30}

// Removes "Alice" from the map
delete(m, "Alice")

The delete function has a safety feature that makes it very safe to work with. In case of deletion of something that is not in the map, it simply does nothing.

Iterating Over Maps
Now that you know how to add and remove individual items, you’ll likely want to loop through the entire collection. In Go, we use the range keyword to iterate over a map.

m := map[string]int{“Alice”: 25, “Bob”: 30, “Charlie”: 35}

for key, value := range m {
fmt.Printf(“Key: %s, Value: %d\n”, key, value)
}

Something to keep in mind when it comes to maps is that they are “commitment-phobic” when it comes to order. Unlike arrays or slices, they do not have a specified order during iteration. If you run the code above three times, chances are that you might get three different sequences. If you need a consistent order, you’ll have to sort the keys manually in a separate slice first.

Maps as Reference Types
The most significant points to keep in mind are that maps are a type of reference. Passing a map to a function does not give a copy of the data, but the pointer to the underlying data structure.
This implies that when you make changes to a map within a function, the changes will be carried over to the original map.

func updateAge(m map[string]int) {
m[“Alice”] = 30 // This changes the original map!
}

Map Performance and Concurrency
Maps are incredibly fast, offering O(1) average time complexity for searches, additions, and deletions. Maps are extremely quick with an average time complexity of O(1) for searches, add, and delete. There is, however, a kind of safety limit that they have: Maps are not thread-safe.
If two different goroutines try to write to the same map at the same time, your program will crash with a fatal error: concurrent map writes

Feature 
Behavior in Golang Maps
Search Speed
Extremely fast (Constant time)
Iteration Order
Random/Unordered
Thread Safety
None (Requires sync.Mutex or sync.Map)
Zero Value
nil (A nil map can be read, but writing to it causes a panic)

Conclusion
Maps are the go-to tool in Go when you need a fast, associative data structure. By mastering the make function, the “comma ok” idiom, and understanding the nuances of iteration and reference types, you can handle complex data relationships with very little code.

Go templates

Frihk Ian — Wed, 11 Feb 2026 12:23:08 +0000

The first thing to handle is answering the question, "what are Go templates?" Go templates are a way to create dynamic content in Go by allowing the user to mix data with plain text or HTML files with data received from the Go code. This makes it possible to change the data in a template very easily, as it can be edited with ease. They are mainly used in web dev to create web pages that rely on user inputs or content from a database.
A template is just a file that has placeholders for data. In Go, placeholders are written using double curly braces {{ }}. These curly braces can hold a user’s data, and this can be shown by {{ .name }}. The dot refers to the data object you refer to from Go. When the template is running, Go replaces the {{ .name }} with the actual user name from the user's input or the database.
To use templates in Go, a data structure that can help you hold the data to show, usually a map or a struct, is required.

type PageData struct {
    Title   string
    Message string
}

Then you parse the template file in your Go code and execute it with your data. The template system will automatically replace all placeholders with the correct values. This keeps your HTML or text separate from your Go code, making your program cleaner and easier to maintain.
A good example of template file is as shown below

<!DOCTYPE html>
<html>
<head>
    <title>{{ .Title }}</title>
</head>
<body>
    <h1>{{ .Title }}</h1>
    <p>{{ .Message }}</p>

    {{ if .IsLogged }}
        <p>Welcome back, {{ .User }}! </p>
    {{ else }}
        <p>Please login to continue. </p>
    {{ end }}

    <h2>Your Tasks:</h2>
    <ul>
        {{ range .Tasks }}
            <li>{{ . }}</li>
        {{ else }}
            <li>No tasks available.</li>
        {{ end }}
    </ul>
</body>
</html>

Go templates also support basic logic. This helps to manipulate the values to be displayed. You can display certain things if a certain condition is met. You can also range over maps, structs, among others. For example, you can display a specific message to only logged-in users, you can list all the content of a check list from a shopping list among many others. You can also use functions like len to make the content more flexible.
Below is an example of Go code that displays its output to the HTML file above.

package main

import (
    "html/template"
    "net/http"
)

type PageData struct {
    Title    string
    Message  string
    IsLogged bool
    User     string
    Tasks    []string
}

func handler(w http.ResponseWriter, r *http.Request) {
    data := PageData{
        Title:    "Go Templates Advanced Example",
        Message:  "Using conditions and loops in templates",
        IsLogged: true,
        User:     "Ian",
        Tasks:    []string{"Learn Go templates", "Build a web app", "Practice Go daily"},
    }

    tmpl := template.Must(template.ParseFiles("index.html"))
    tmpl.Execute(w, data)
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

In summary, to generate a dynamic text or HTML in Go, the best option is the Go template. They help separate the design of your output from your code logic, allow you to reuse templates with different data, and make it easy to build web pages, reports, or any text-based content.

DEV Community: Frihk Ian

Vibe Coding Didn't Kill Junior Devs' Careers. It Just Fast-Forwarded Them.

The surging demand for hiring that no one anticipated.

Next, the codebases had to be tested!

The market took no notice of this,

Multiagent orchestration article

Nobody's Reading Tutorials Anymore. They're Just Asking AI.

Array in Go

What is an Array in Go?

Zero Values

Declaring an Array

Using the var Declaration

Array Literals

Let the Compiler count for you — The ... trick

Sparse Initialization

How to access elements and modify an array.

What are the consequences of going beyond the lines?

Getting the Length with len()

Arrays are valued, not references.

Sharing With Pointers

Comparing Arrays

The for range Loop

A classic for Loop.

Multi-Dimensional Arrays

Limitations of Arrays

The Size Is Fixed Forever

Passing Large Arrays Is Expensive

Common Mistakes with Arrays

Mistake 1: Assigning Arrays of Different Sizes

Mistake 2: Expecting Assignment to Share Data

Structs in Go

Declaring Structs

Creating Struct Instances

Anonymous Structs

Nested (Embedded) Structs

Struct Comparison

The Photocopy vs. The Original

Best Practices & Common Beginner Mistakes

Summary & Your Mini-Challenge

Data Types In Go

1. Basic(primitive) Types

2. Composite Types

Other Important Types

Basic(primitive) Types

Numbers.

Integers

Floating-point

Strings

Immutability

Indexing

Length

Unicode and Runes

String Concatenation

Boolean

Maps in Golang

Go templates

Let the Compiler count for you — The `...` trick