tinthedev

I've found a bit less fun, but similar, way to present for the CLI. `curl -L tinthe.dev` is HTML, don't see why to mess with the default.

But, I did put in `<link rel="alternate" type="text/markdown" href="/home.md" title="...">` as a hint for using `Accept: text/markdown` on the same URL. Or going to .md versions of pages. Did it in a "sprint" of optimizing for other devices, screen readers, and LLMs. It is supported on the full page, posts included. Same point as the draft preview, less color.

Gets you 95% of the way there. The agents can take the .md and skip the layout. And I think `curl -LH "Accept: text/markdown" tinthe.dev` is pretty readable, too.

Yeah, I love this. We can't manage what we don't measure, and adjusting the mesurement to be on the abstract syntax level removes an entire layer of "mess" that comes from comments and formatting.

I'll bookmark it and probably adjust the measurement methods for future review purposes. I've often found my LLM workflows to produce inane and overly complex code, and allowing me to see a single figure will allow me to more easily eval generated code.

I'd love to hear people's lived experience, though. I think heuristics in this space still allow for a lot of optimizations of code generation and pipelining.

Yes and no (but mainly no).

Software Engineering is in this weird limbo where a whole subsection of the industry thinks it can be a blue-collar "I just code" type of contributor... those types are going to slowly be eliminated.

But for the majority of us, the job always was more involved than just code. And that's white-collar work, through and through.

Civil engineers never could scale to pouring concrete themselves, thus the blue/white collar split. Software doesn't have that problem.

I feel a lot of these tools are barking up the wrong tree. Solving problems that are just symptoms of a deeper root cause. Index because my codebase is too big to grep. Index to paraphrase hard_decline via card retries. Reduce tool calling to save my agent YOLO search loops. etc. etc.

It feels like trying to overcome bad codebase hygiene by throwing more tools at it, and wallpapering the mold over. I've found that codebases left entirely to LLMs suffer from this gravely, but with even a bit of effort - you'll get outsized returns. Don't let the agent smosh up everything into a giant ball of code. Separate concerns, build services, do the architecture step of the software design with a bit more care than vibe coding.

A bit of a rant, yeah, but I don't see why tools like this exist (and ask you to curl a script into bash, no less). You're doing stuff a bit wrong if grepping is the bottleneck.

Well explained. That's why I put scare quotes around "amplify" - but I couldn't find a better way to state it.

How about you compare like to like? Hmmm.

Like using a calculator. I use one, but I still use paper math too, and calculate manageable sums/multiplications in my head. I'd feel dull otherwise.

GPS. I use one, but I still pay attention to the route and keep a sense of direction. “Why bother knowing where you are when the machine can tell you?” isn't really an argument for outsourcing your own brain.

I don't like AI coding, but I can't say it's not useful. Most of the arguments in this article can be disarmed by taking the abstraction "one step up". LLM generated modules and software, microservices, whatever your level of abstraction... now need to be composited together. You go and deal with higher order problems, factories, generation, etc.

Is it a way to develop critical bits of code, depths of your business logic? Absolutely not. Can it solve a lot of boilerplate and support logic? Absolutely yes.

Seeing "AI Companies as Bad Actors"... can't fully disagree there. There's far too many far too dodgy things about these businesses, and I trust them as far as I can audit them (not very far). And the missing argument's the cognitive decline of using these things to think for us. I try to keep myself sharp by still manually doing a fair amount of things in my life. I refuse to automate _everything_ - especially the stuff I do for fun. Having an LLM manage hobby-adjacent stuff is a quick trip to burnout land, especially once fixing the thing becomes "the hobby"... and it does.

Using Jev for SRE seems like such a backwards prospect. You don't need split-second velocity, you don't need costs savings. What you DO need and Jev provides not at all - is auditability. You want to know WHY and HOW the calls were made, as with humans so with AI. Adding a black box in there seems incredibly misguided, no?

The same way I'd not trust an SRE when they've "got a feeling", I don't intend to start trusting Jev. The audit of process doesn't allow audit of reasoning.

Wonderful article. Reminds me of my experience scuba diving in Croatia. My group and I were doing a seabed waste-collection dive, and part of it was an obligatory training on ordnance. The sea there has had a fair few wars and conflicts.

I remember being astounded by how the water "amplifies" the explosions - so while a hand grenade blast is very dangerous on the surface, under the sea it becomes far more horrific prospect, due to the water transferring the blast more efficiently. Nerve wracking stuff, when you're thinking about diving down there - imagining that a bomb dozens of meters away could pulverize you.

Still pretty rare, thankfully. I applaud the diver bomb disposal squads - some of the most dangerous work there is.

Looks pretty cool, although I'm not sure I see the advantage over a skill using something like a private git repo / file store / server?

So far, I've used that, a UNIX-socket inspired approach to push/pull with a remote git (hosted on my server) that the branches/files can be tossed to, and pulled via other agent. Skill instructs them to make a copy-paste ready instruction for the other prompt.

Why'd Jotbus be worth the overhead?

Software engineer / engineering lead. I've run teams (Kiwi, ~20, payments and refunds) and I've been the person who owns the hard system - NBA real-time stats on Kafka + Flink, Semgrep Series B public API auth and RBAC. Looking for freelance, contract, or a full-time seat where I can own a surface - not a backlog.

  Location: Brno, EU (UTC+1)
  Remote: Yes, 100%. On-site travel possible.
  Willing to relocate: No
  Technologies: Python, TypeScript, Go, PostgreSQL, Redis, Kafka, Flink, ClickHouse, AWS (Lambda, Cognito), Docker, CI/CD. Flexible on the rest.
  Résumé/CV: https://www.tinthe.dev/
  Email: tinmarkoviccs (at) gmail.com

Comfortable across backend and the data layer. Frontend when it serves the product (TypeScript / React), not as a specialty. I use LLMs. I don't outsource the thinking to them. If the product grew faster than the architecture, that's the job.

Not a cog-in-the-machine hire. Happy to start on a scoped piece of work if you'd rather test that than interview.

https://www.linkedin.com/in/tin-markovic

https://www.tinthe.dev/

Software engineer / engineering lead. I've run teams (Kiwi, ~20, payments and refunds) and I've been the person who owns the hard system - NBA real-time stats on Kafka + Flink, Semgrep Series B public API auth and RBAC. Looking for freelance, contract, or a full-time seat where I can own a surface - not a backlog.

  Location: Brno, EU (UTC+1)
  Remote: Yes, 100%. On-site travel possible.
  Willing to relocate: No
  Technologies: Python, TypeScript, Go, PostgreSQL, Redis, Kafka, Flink, ClickHouse, AWS (Lambda, Cognito), Docker, CI/CD. Flexible on the rest.
  Résumé/CV: https://www.tinthe.dev/
  Email: tinmarkoviccs (at) gmail.com

Comfortable across backend and the data layer. Frontend when it serves the product (TypeScript / React), not as a specialty. I use LLMs. I don't outsource the thinking to them. If the product grew faster than the architecture, that's the job.

Not a cog-in-the-machine hire. Happy to start on a scoped piece of work if you'd rather test that than interview.

https://www.linkedin.com/in/tin-markovic

https://www.tinthe.dev/

You misunderstand the "test" here to mean programming, rather than test against the model's capabilities.

This is just nonsense.

Handling errors this way is possible in only very brittle and simplistic software.

I mean, you're contradicting your very own argument. If this was the primary/idiomatic way of handling errors... then Go should just go the way of most languages with Try/Catch blocks. If there's no valuable information or control flow to managing errors... then what's the point of forcing that paradigm to be so verbose and explicit in control flow?

None.

Well, but you don't have `markdown -> PDF/HTML`

Also, if you don't need the python bits, you just skip Python :)

I'm not quite sure who this is for.

Markdown is for keeping things simple.

There's plenty of of "proper" markup languages and full programming languages to actually write code in.

Why do we need a hybrid program like this, which is not as simple as pure markup, and is not as powerful as a proper templating language?

I personally just run markdown -> HTML/CSS -> python templating (Jinja or something) -> PDF/HTML

As a dev, I find this works the best for me. But I also cannot imagine that learning Quarkdown would improve my workflow meaningfully, and I also cannot imagine recommending someone learn such a niche product instead of having them learn HTML/CSS and Python (Jinja if they need fancy). Seems like a comparable amount of effort.

You can always try to categorize your target audience, and figure out their preferences.

The main thing to focus on here, however, is that this offering would not be for your usual audience. If that's all you expect from it, I would rather not bother. It's a separate market, and while there's some bleedover, I think you'll be surprised how different they are.

You can always try to play it safe and put in a contact form for discounted quotes (nonprofits, individuals, etc). This depends a lot on your capacities, but it could quickly tell you if you're pricing out desirable customers.

SEEKING WORK | 100% REMOTE (on-site travel possible) | Central Europe, timezone independent but living in UTC+1

Email: tinmarkoviccs (at) gmail.com

I'm a software engineer who helps media and research organizations turn their internal knowledge into external-facing APIs. Whether your data lives in spreadsheets, PDFs, Airtable, or Jira, I'll help you extract it, build an API around it, and integrate it with platforms your customers already use.

- Fixed pricing (no surprise bills, no scope creep)

- Results guaranteed - or you don't pay

- Autonomous delivery - I take care of the details so you can focus on what matters

- Used by orgs like the NBA, Kiwi.com, and Redfolder Research

Let's chat! Reach out to me:

- via email at tinmarkoviccs (at) gmail.com

- via linkedin https://www.linkedin.com/in/tin-markovic

Feel free to browse my web to learn more about me at https://tinthe.dev/ :)

Location: 100% REMOTE (travel possible) | EU, timezone independent (UTC+1) | No relocation

Email: tinmarkoviccs (at) gmail.com

Tech/Resume/CV:

I'm a software engineer who specializes in turning internal knowledge into well-documented, external-facing APIs. I’ve worked with teams at the NBA, Kiwi.com, and Redfolder Research to help them expose structured data from sources like Airtable, spreadsheets, PDFs, and Jira — with minimal lift on their side.

I’m open to freelance, contract, or full-time roles where I can lead API design and delivery, particularly in media, publishing, or research-focused teams.

- Production-ready APIs from messy data

- Fixed-scope freelance projects or long-term roles

- Async-native, autonomous, results-focused (can run self-managed)

- Worked in stacks based on [Python, JavaScript/TypeScript, Golang] but I'm flexible on technology choices

Reach out to me:

- email at tinmarkoviccs (at) gmail.com

Browse my web at https://tinthe.dev/

I think you're thinking of it a bit backwards.

Why limit your price to LTV for the offline-only version? Think of it as a full blooded product, instead of trying to squeeze it into the SaaS thinking model you've got already.

Plenty of enterprise (and such) clients wouldn't balk at all at a $500 fee. Brainstorm your target market and price accordingly. In other comments, you're mentioning the support burden - I don't think you should sell the offline version if you're not ready to lift that burden, and thus should price it in a way where this is attractive to you.

Offline versions are usually used by more demanding customers in the current day and age - the web is where you go for the user-friendly version.

Practical AI vs hype AI is what I see the biggest distinction on.

I haven't seen people negatively comment on simple AI tooling, or cases where AI creates real output.

I do see a lot of hate on hype-trains and, for what it's worth, I wouldn't say it's undeserved. LLMs are currently oversold as this be-all end-all AI, while there's still a lot of "all" to conquer.

Oh, lovely. Thanks for the share. Failed to find it.

Location: 100% REMOTE (travel possible) | EU, timezone independent (UTC+1) | No relocation

Email: tinmarkoviccs (at) gmail.com

Tech/Resume/CV:

I'm a software engineer who specializes in turning internal knowledge into well-documented, external-facing APIs. I’ve worked with teams at the NBA, Kiwi.com, and Redfolder Research to help them expose structured data from sources like Airtable, spreadsheets, PDFs, and Jira — with minimal lift on their side.

I’m open to freelance, contract, or full-time roles where I can lead API design and delivery, particularly in media, publishing, or research-focused teams.

- Production-ready APIs from messy data

- Fixed-scope freelance projects or long-term roles

- Async-native, autonomous, results-focused (can run self-managed)

- Worked in stacks based on [Python, JavaScript/TypeScript, Golang] but I'm flexible on technology choices

Reach out to me:

- email at tinmarkoviccs (at) gmail.com

Browse my web at https://tinthe.dev/

SEEKING WORK | 100% REMOTE (on-site travel possible) | Central Europe, timezone independent but living in UTC+1

Email: tinmarkoviccs (at) gmail.com

I'm a software engineer who helps media and research organizations turn their internal knowledge into external-facing APIs. Whether your data lives in spreadsheets, PDFs, Airtable, or Jira, I'll help you extract it, build an API around it, and integrate it with platforms your customers already use.

- Fixed pricing (no surprise bills, no scope creep)

- Results guaranteed - or you don't pay

- Autonomous delivery - I take care of the details so you can focus on what matters

- Used by orgs like the NBA, Kiwi.com, and Redfolder Research

Let's chat! Reach out to me:

- via email at tinmarkoviccs (at) gmail.com

- via linkedin https://www.linkedin.com/in/tin-markovic

Feel free to browse my web to learn more about me at https://tinthe.dev/ :)