Posts

Have you heard of the latest mental health phenomenon? Weirdly, it only affects programmers. Hence the name: Claude separation anxiety. 😰💻

Definition: when you have not seen actual code for such a long time that you forgot what it even looks like. All code now materializes through Claude. Your job is mostly nodding, copying, and saying “looks good”. 🤖✨

Symptoms:

• Mild panic when Claude says “I may be mistaken” 😬
• Inability to write a for loop without emotional support 🫠
• Reviewing code like a museum visitor observing ancient artifacts 🏛️👨‍💻

Side effects: You wake up at 3:17 AM in a cold sweat after a nightmare that the $90 subscription is now $9000. 😱

You check your email. Still $90. 🙏

You whisper thank you and go back to sleep.

Originally posted on LinkedIn.

On a busy week, I make around 10,000 code line changes a day on average. 🤯

Am I expected to review all that code? Pf. That is so last year thinking. Or maybe better said, 6 months ago thinking.

No. What I do instead is this:

• I make sure the architecture is clean, efficient, and designed for the problem I am solving. How? I ask the Agent to discuss options, pros and cons, and then I review it carefully to choose the architecture I want 🧠
• Then I ask the Agent to code while I watch an episode of Friends ☕
• Then I ask it to review the code and check for mistakes. It always finds 2–3 issues 🔍
• Then I test the application manually, and report issues back to the Agent to fix
• Then I ask the Agent to write tests covering the main use cases, happy path, and the error scenarios I discovered 🧪
• Then I tell the Agent: make the code production ready. Simple as that 🚀
• Optionally, I ask it to focus separately on error handling, security, performance, and observability
• Finally, I ask it to run build, linting, and assess the code coverage

I don’t need to review the code anymore. I review the thinking instead. 💡

Originally posted on LinkedIn.

Sam Altman once said millions of dollars are wasted on people thanking LLMs.

So people conclude you should not do it. It is pointless. Maybe even wrong.

I don’t think so.

When you talk to an LLM, psychologically you are not talking to a machine. You are talking to a mirror. Your brain still runs the “conversation with another human” mode. 🧠

And that matters.

Treat the LLM like shit and technically nothing happens. But something does change.

You.

The way you talk to an LLM is basically practice for how you talk in general. To anyone. Do it 100 times a day and your brain optimizes it. It gets cached. Autocomplete for your personality. ⚡

At some point you will slip and talk to a person the same way.

Keep being respectful and the worst thing that happens is you become a slightly better human. Horrible outcome. 😄

So yes, thanking the LLM might waste a few GPU cycles 🤖

But being thoughtful in how you write? That investment compounds.

Originally posted on LinkedIn.

Less than a year ago, a dear friend of mine (Zsolt Pocsaji) told me that very soon, software development wouldn’t need people to write code. Humans would only write code for true innovation. Everything else? Supervised AI agents doing the heavy lifting.

At first, I laughed. Internally… but still.

Then I looked at his completely serious face and realized this wasn’t another Elon-level “Cybertruck is indestructible” moment. 😄

The timeline since that conversation:

3 months: My agency rebrands as an AI-first consultancy 🤖

5 months: I’m leading AI transformation across multiple teams… with heavy resistance 🧱

8 months: I personally review <20% of the code my agent writes, while the internet is still debating “vibe coding” like it’s a philosophical movement 🧘‍♂️

12 months: I’m building software almost entirely through prompts in Claude. The industry quietly accepts the new reality. Job titles evolve from “Vibe coding cleanup specialist” to simply… “AI engineer.” 🚀

The speed of change is enormous.

For comparison: when Ryan Dahl introduced Node.js in 2009, I told colleagues that one day everything would be written in JavaScript. They laughed. Loudly. Publicly. Probably still laughing somewhere. 😅

And yet, JavaScript still needed 8 years to become the #1 programming language in the world.

So either: my friend is a genius (he is, obviously), I’m terrible at predicting the future, or… we’re living through truly unprecedented times.

Slightly exciting. Slightly scary. Mostly both.

Originally posted on LinkedIn.

Do you want to be a better vibe-coder? 😎

I have news: you need to learn to be a really bad boss. 😈

In the age of AI and Copilot, if you want to fully exploit all the new technologies, you also need to master some fundamental toxic management skills. 🤝

See, horrible bosses are great at:

Level 1:

• 🔍 Micromanaging your every action
• 🙅 Thinking you cannot do anything good enough without them
• 🔁 Double, triple, quadruple checking your work

Level 2:

• ❌ Criticise everything you do
• 🚫 Do not allow you to make any decisions
• 📈 Demand results, question the impossible
• 🎭 Manipulate you into doing something you don’t want

Ultimate level:

• 🔥 Fire you as soon as a cheaper or better model is available
• 🧠 Reset your memory from time to time (er…)

Well, it turns out LLM coding tools work best if you practice the virtues above. 🤖✨

And most importantly, do not forget to take full credit for all the hard work your LLM has done for you. 😌

No one needs to know your secret recipe. 🤫

Thank me later. You are welcome! 😄

Originally posted on LinkedIn.

I couldn’t believe it either 😅

When I first heard on Gergely Orosz’s podcast that some days Steve Yegge would change 50,000 lines of code with full vibe coding, I laughed. Impossible, right?

So I checked… and I was amazed.

Nearly 300,000 lines of code changed (added or removed) in my GitHub over the last 10 weeks. And I wasn’t even trying 😄

A few caveats:

• I was prototyping 5 different services
• One project I deleted and rewrote from scratch with a better prompt 3 times 🤷‍♂️

But still, it’s obviously not 300,000 lines of production quality code. Around 50-70% is throwaway code… and honestly, that’s exactly what I needed.

• When I don’t know what I want: I just test it out!
• When I don’t know if the solution will work at all: I test it out!
• When I don’t know if the architecture makes sense: I test it out!

No more analysis paralysis 🚀

Build, rebuild, and move in small steps toward real value.

Originally posted on LinkedIn.

Three categories I keep reaching for lately 🚀

Azure / AWS ☁️

• Connect straight to S3 or Azure Storage and query files directly
• Use secure, modern auth like RBAC, tokens and CLI creds

JSON / CSV 📄

• Load and explore semi-structured or flat files from anywhere
• Automatic schema inference that feels like magic
• Use asterisk wildcard to easily load multiple files

Postgres / MySQL 🗄️

• Attach external databases as if they were part of DuckDB
• Join and query across multiple systems without friction
• Stream data both ways for fast ETL and rapid prototyping

Still not on the “ducktrain”? Have a look at duckdb.org.

Originally posted on LinkedIn.

Ever get stuck on a problem and think the solution is to grind harder? Lock yourself in a room, stare at the screen, and power through?

Yeah… no. Just imagining that makes my eyes water 😢.

It’s not only miserable - it’s actively worse for solving the problem.

Here’s the counter-intuitive truth: walk away. 🚶‍♂️💨

Literally leave the task and come back later. And the tougher the problem, the more it benefits from that break.

But Agoston, this sounds like something you made up.

Nope. This is one of the most robust findings in creativity and problem-solving research: the incubation effect - stepping away improves solutions 🧠✨.

But Agoston, you haven’t been in uni for a decade.

Fair. So here are two solid studies from the last 10 years:

• Henok et al., 2018 - Incubation and interactivity in insight problem solving
• Gilhooly et al., 2016 - Incubation and Intuition in Creative Problem Solving

Don’t be scared by the word incubation - it’s science-speak for “leave the problem alone for a bit” 🌱.

And if you want more studies (there are plenty), just ask ChatGPT 🤖.

Originally posted on LinkedIn.

To be an engineer, you need at least a BSc and an MSc in Computer Science. ❌ Wrong.

If you have imposter syndrome, you’re not cut out for engineering. ❌ Wrong.

If you burn out and take a career break, it means you’re not meant for this field. ❌ Wrong.

If you’re 30 and still figuring out whether coding is for you, it’s probably not. ❌ Wrong.

If you sometimes hate coding, you should quit. ❌ Wrong.

These are myths I’ve come across - and wrestled with - over 20 years in software development. 🧑‍💻

Here’s what’s actually true:

❤️ Passion and frustration come as a pair. You can love your craft and still have days you want to throw your laptop out the window.

🎢 Ambition comes with doubt. Feeling like an imposter doesn’t mean you’re unfit - it often means you’re growing.

🌱 Breaks are healthy. Trying something new, resting, exploring another path - none of these disqualify you from being an engineer.

If you’re struggling with any of these feelings, you’re not alone. 💬 Send me a message - happy to chat and share perspective.

Originally posted on LinkedIn.

My memory is basically that of a goldfish. I only remember what truly matters - and SQL syntax does not make the cut.

The other day I needed to change a column type in my database, so I wrote something like:

ALTER TABLE rxc.trial change column drugs to text instead of varchar;

Yes, I know. There are mistakes. Parts of it are basically fan-fiction.

And at this point, some of you are already judging me. You probably call yourself a “data engineer” or an “SQL magician.” You wake up at 3 AM reciting the differences between Postgres 10 and 11. You speak SQL better than your native language.

I am not you.

I wrote that line purely so I could add this right under it:

//TODO: fix the syntax of this statement

Then I asked Copilot to “fix the TODO in this file.” Because I’m not just lazy - I’m committed to not learning. Goldfish, remember?

But here’s the thing: Copilot didn’t warn me that this change could cause downtime or even cost the company $50k. (It didn’t happen - but it could have.) And that’s exactly why I still need the SQL magician. They would have told me. Right after making fun of me for the syntax.

So no, AI didn’t replace you. It liberated you - from people like me - so you can focus on real problems instead of listening to my existential crisis about SQL.

Originally posted on LinkedIn.