Darko Mesaros on Vintage Computing, Kiro, and Agent Attention

Top-Line Summary

Darko Mesaros joined us the week he became a Distinguished Developer Advocate at AWS, and the conversation split cleanly in two: forty years of computing history sitting behind him on camera, and the AI workflow he uses today. The thread connecting them is attention. Every constraint of 1970s computing forced focus, and most conveniences of 2026 computing remove it, which is why Darko’s most productive sessions with an agent happen in a coffee shop with nothing else to look at.

Show Video

The “Pre-Show” Context

Darko came on fresh off a title change to Distinguished Developer Advocate, a role he describes as spending less time talking at people and more time listening to them. To that end he built pingdarko.com, where anyone can leave him anonymous messages. He is also wiring up a receipt printer so every message physically prints in his office, which he has throttled, presumably after imagining 3 a.m. spooling. Physical proof of things people say on the internet anonymously. What could go wrong.

The Engineering Rundown

• From Windows Support to Distinguished Developer Advocate (02:52)

  Darko joined AWS in 2016 as a level four premium support engineer in the Windows pod, supporting customers running Windows on EC2. Two years in support led to a solution architect role in Berlin, which led to speaking at customer events and internal hackathons, which led the technical evangelist team (as DevRel was called in 2018) to start inviting him to speak on AWS’s behalf. He took the developer advocate job in 2019, planned a life of airports and conference stages, and then 2020 happened. The live streams and video content he built at home during lockdown are how he and Brett met, and they became the foundation of everything since. The detail worth sitting with is that he got all the way here without ever writing code for money, which is not the route anyone would draw on a whiteboard toward a distinguished technical title at AWS.

• The AIX Server Brett Gave Away (07:34)

  Darko came up as a sysadmin across Windows, Linux, AIX, and Solaris, which set Brett off on his own IBM Global Services story. A former employer was scrapping their AIX inventory systems, Brett’s boss said it was cheaper to give them away than dispose of them, and a rack went into his basement. The good part was calling IBM for a license: they could not process a request with no business attached to it, until the right person picked up, heard “it’s just running in my basement,” and mailed him the full stack of AIX CDs. He ran it for years and then donated the server, which his wife had to remind him of when he went looking for it. Darko has Silicon Graphics, HP workstations, and Sparc gear, but no AIX.

• A 1974 Minicomputer That Needs a 60-Amp Circuit (10:55)

  Behind Darko sits a Sun Ultra 60, a dual 450 MHz workstation from the turn of the century that draws roughly 600 watts sitting idle. Then he swung his phone camera around to a Data General Eclipse S/230 minicomputer from 1974, formerly owned by NOAA. Its two 76 MB hard drives pull 700 watts just spinning, and the full rack wants a 60-amp circuit at 120 volts, which is not a thing that exists in a normal house. So it does not get turned on. The machine has no CPU in any modern sense, just a bank of arithmetic logic units, and it measures memory in words rather than bytes: 512 kilowords, which lands somewhere around a megabyte.

• Growing Up With a Commodore 64 and Nothing Else (13:53)

  Darko’s answer to why the gear lives in his house rather than a museum is that he grew up, in his words, “in a third world country,” and until 2001 his only computer was a Commodore 64 with no games, no software, and no floppy drive because floppy drives were too expensive. He had a tape drive, a book, and time. So he wrote his own games in BASIC, and because he could not always save to tape, he would leave the machine powered on for days rather than lose two days of work. He was born in 1988, so he did not live through the era he collects. What he has is an appreciation for a period when nothing was interoperable and every architecture was genuinely different, versus today’s computing, which he flatly calls boring. He showed off an eight-inch hard-sectored floppy that will not work in anything except the one drive it was cut for. Moving to the US five years ago turned collecting from difficult into a spending problem.

• Typing Games In From Magazines (17:30)

  Darko pulled out a 1980 issue of Microcomputing with full program listings printed in it, the kind of thing you sat down and typed by hand. Brett’s mother was a typist, and he remembers her sitting at the Commodore 64 for hours entering games line by line, running a checker on each one, saving them to tape for him and his cousin. Darko has a friend whose family disconnected the TV cable during the day, so he would type listings blind into the Commodore with no display, then plug the TV back in at night and debug whatever he had gotten wrong. Darko’s read on it is that computing back then was a hobby more than a job, and the enthusiasm has not survived the transition. The old man hat, as he put it, was firmly on.

• RollerCoaster Tycoon Was Written in Assembly (21:43)

  Darko has written a lot of 6502 assembly for the Commodore 64, and his point about it is counterintuitive: assembly for a Z80 or a 6502 is dead simple, and everything you need to know fits in a five page booklet. The difficulty was never the language, it was being creative inside the limits. His example is Chris Sawyer writing RollerCoaster Tycoon almost entirely in x86 assembly in 1999, which is why the thing runs the way it does.

• Where Darko Draws the Line With Agents (22:47)

  Travers asked where Darko will and will not delegate, and the answer starts with language choice. He delegates most of his coding now, but he writes Rust, specifically because the borrow checker and the compiler are unforgiving enough to catch LLM mistakes before anything becomes a binary. Not Python, not JavaScript. He does not read all of his code, which he considers a reasonable position, but security, data sovereignty, and data privacy get read every time. There is no fixed percentage; it depends on whether the thing is a home data entry toy or something exposed to the internet.

• A Machine Can Never Be Held Accountable (26:30)

  Darko pulled the 1979 IBM line out and applied it directly: a machine cannot be held accountable for a management decision, and an LLM cannot be held accountable for your mistakes. If you decide not to read the code, that was your decision and you own the result. Then he turned it on himself. With agents able to just go and do things, he says he does not pay as much attention as he should: kick off a build, wander off, come back, accept. He has scrapped commits and pull requests because he could not tell whether they were any good. Brett’s immediate response was that it is not just him, and that this is the thing the show ends up circling week after week. Both hosts had pushed away from their desks recently for exactly this reason, and Brett owned up to eight Herdr panes open at once, each getting a fragment of his attention. The transformer revolution came out of a paper called “Attention Is All You Need,” and the irony was not lost on anyone.

• Personalized Software Is Back (28:25)

  Brett’s favourite segment of the show is the middle one, where he and Travers talk about personal projects, because both of them keep building small bespoke tools for their own workflows. Darko sees the same thing and frames it as a return to the early days, when people wrote their own helper scripts because software was simple enough to write. Then software got complex, everyone started buying off the shelf, and now the bottleneck is gone again. His words: “I build a lot of stupid stuff now.” Including his own curl, for no reason at all.

• Code Generation Is Solved, Software Engineering Is Not (30:18)

  This is the take of the episode. Darko thinks code generation is largely a solved problem and the code coming out is fine. What has not been solved is software engineering, and conflating the two is where people end up with slop. He spends extra time on demo code specifically so he does not embarrass himself showing it. Travers sharpened it: producing good code was never the critical part of software engineering, and you can be a bad engineer while writing perfectly good code. Code was as much a blocker as an output, and removing the blocker does not hand you the skill.

• Reading the Output Is a Skill (34:00)

  Brett’s counter-practice to the attention problem is forcing himself to read the model’s reasoning, including the wordy stuff, and calling BS on it. Asking “are you absolutely sure that’s the right way to do it” does two things: it teaches him something, and it slows him down. Being able to generate 50,000 lines of code in an afternoon is not an argument for doing it. Darko’s version is a note-taking system: his agent writes extensive notes into Obsidian markdown as it builds, so when his attention lapses he can go back and read what it thought it was doing. With Kiro he uses specs, spending an extra thirty minutes planning so that when he lets it run, he already understands the engineering decisions being made. His most productive sessions are in a coffee shop with a laptop and nothing else, because he cannot be distracted there.

• Racing the Beam on an Atari 2600 (39:42)

  Darko’s recommendation for anyone who wants their focus back is to learn assembly for something completely impractical, and his pick is the Atari 2600. There is no framebuffer and no “draw a pixel at X,Y.” You count television scanlines as the beam sweeps top to bottom sixty times a second, wait for the right line, then burn a precise number of CPU cycles to land the horizontal position, because each line is roughly 170 cycles. The entire language fits on three pages and you can learn the syntax in an afternoon. The console shipped in 1977 with 128 bytes of RAM and no ROM at all, since the only ROM in the system lives on the cartridge. Brett’s contribution to Atari history was destroying joystick after joystick playing Summer Games, and the running cost of buying replacements.

• Where a Skeptic Should Actually Start (44:32)

  Brett asked what he would tell someone who has been holding out and is now curious. Darko gave two paths. Build the project that has been rattling around your head for years, which will probably land 95% of the way there and impress you. Or take a codebase you know intimately and have the agent add a feature, which is the better option, because the thing that scared him early on was the loss of control. Working somewhere you already know the language and the domain means you can recognise the specific mistakes the model makes. Brett’s cautionary tale is letting an LLM decide to write TypeScript for him, a language he can identify by file extension and not much else. The advice holds: staying inside your domain expertise removes most of the fear.

• The Gap Between Veterans and Newcomers (48:56)

  Darko named the uncomfortable part directly. There is a real gap between people already embedded in the industry and people who spent the last four or five years in school and now feel their skills have been steamrolled. He thinks the feeling is valid and the conclusion is wrong, because what they actually have is a box that can saturate their curiosity indefinitely. For the first year and a half after LLMs arrived, he used them exclusively to learn, telling them not to write his code. That is how he learned Rust while hand-writing BedRust, a Bedrock CLI he built on stream. He would ask it to teach him parallelism in Rust and it would set him daily challenges. Brett’s framing: a tireless tutor you should not fully trust, which is the same relationship everyone already has with Google and Stack Overflow.

• Terminals, tmux, and Whether IDEs Are Dying (52:01)

  Darko lives on Linux, uses a Mac only for work, and runs a window manager, tmux, and Neovim on a ThinkPad, navigating with the little red nub. He has not used an IDE in a long time and never got the VS Code Vim bindings working because he would just use Vim. Brett raised the hot take going around that using an IDE means you are falling behind, and Darko was not having it. JetBrains makes excellent tools, and for Java or C++ that is where you will be. IDEs are evolving rather than dying, and he still keeps Neovim open beside the agent to read what it wrote, even when he is not typing.

• Kiro Across Four Surfaces (54:53)

  Kiro is not just the IDE, which is the VS Code fork most people have seen. There is the Kiro CLI, which Darko calls his favourite of the bunch and which Brett says he would be lost without, mostly for AWS CLI command autocomplete. There is app.kiro.dev, a web interface that is not an IDE at all: you point it at a repo, tell it what to do, and it opens a pull request. And there is Kiro mobile, a phone front end to the web version doing the same job. Darko’s pitch for what makes Kiro different is correctness rather than speed. Spec-driven development produces a requirements doc, a design doc, and a task list before any code exists. Property-based testing verifies each property in the requirements doc is actually met. It also runs neurosymbolic checks to catch conflicting or vague requirements before the first byte is written. It is a paid AWS product, and it turned one year old a couple of weeks ago.

• Kiro on a 1977 Dumb Terminal (1:00:32)

  The Kiro CLI supports ACP, which means you can build your own client against Kiro’s harness. Darko is using that to hook Kiro up to the Heathkit H9 dumb terminal sitting in his office, which he bought broken and repaired. A serial connection is the easy part. The problem is that modern CLI tools are heavy, full of colour escape sequences and rendering that a 1977 terminal has no idea what to do with. So he wrote his own shell in Rust that talks to Kiro over ACP and strips all of it out, leaving text and nothing else. He plans to show it in the next few weeks. He also flagged that the CLI runs headless with an API key, so Kiro can run inside a CI/CD pipeline.

• Herdr Versus tmux (1:03:30)

  Brett came to Herdr reluctantly, installed it on a Discord recommendation, ignored it, and it has since become his primary tool. He arrived via Ghostty, tried Cmux and disliked the heavy sidebar, and finds Herdr sits somewhere between the two. Travers is at a roughly 50/50 split between Herdr and tmux, and rates it mainly as a grouping system for specific projects. Darko has not tried it and is interested, with the caveat that he values simplicity in a multiplexer and will bail if it is too much. He also pointed out that Herdr runs inside a terminal, which Brett confirmed: he fires up Ghostty and runs Herdr in it. Both hosts also owned up to the failure mode, which is fourteen tabs open and no idea what any of them are doing.

Off-the-Clock Recommendations

• The Bobiverse series — Darko’s pick, and Brett has read it twice. Hard sci-fi by Dennis E. Taylor, a software developer, about a man whose consciousness is uploaded into a Von Neumann probe. Brett found book three a bit of a dip before it picked back up, but could not put the first one down.
• Cold Storage (2026) — Brett’s pick via his wife Karen, with Liam Neeson and Joe Keery (Steve from Stranger Things). A fungus infects people, and the infected either spread it or explode. He has only seen the last 45 minutes because he was working on side projects, so the beginning is a weekend job.
• American Ninja (1985) — Travers’s pick. Does exactly what it says on the tin. Good if you like schlocky action.
• Learning Atari 2600 assembly — Darko’s genuine recommendation for a weekend, filed under “fun for me, possibly not for you.”